Coding With AI That Survives Review

The working pattern for coding with AI is small enough to review and specific enough to repeat. Give the agent a named task and only the context it needs, then tie the result to a check you can rerun. The table below breaks that into moves.

Each of those moves fails in its own particular way, and the order they come in is doing more work than it looks like it is. Skip the boundary and you get a diff nobody wants to read, because the agent has quietly rewritten files you never meant to open. Thin context fails more quietly: the code compiles, the tests pass, and it ignores every pattern the rest of the repo follows. Then there's the check, which to me is the real one, because it's the whole difference between a result you verified and a result you're taking someone's word for.

The step people skip is the plan. I think it's because it feels like overhead, thirty seconds of nothing visibly happening while you're trying to get work done. Actually, that's not quite the reason. It's that the cost of skipping it lands much later, so it never registers as the mistake it was. If the plan names files you didn't expect, you've learned something for free. If it names the right ones, you've got a reference to check the diff against when it arrives. And once there are four hundred lines on the screen, changing the approach means throwing that work away, which nobody is good at.

Running coding with AI as a team comes down to one habit: leave a trail the next reviewer can follow. The steps below keep the prompt and its proof attached to the change, so nobody has to reverse-engineer what the agent did.

1. 1Pick one real backlog item with a clear owner and expected result.
2. 2Add only the context the agent needs: files, failing output, constraints and done state.
3. 3Ask for a plan before code when the task touches more than one file.
4. 4Run checks that match the risk: unit test, typecheck, visual pass or review checklist.
5. 5Capture the prompt, diff, result and reviewer note so the workflow can be repeated.

Keep whatever lets you rerun the work or hand it to someone else. A finished task is the merged code plus the short trail that explains how it got there.

• The prompt or plan that shaped the work.
• The files changed and the reason each file changed.
• The command, screenshot or review note that proved the result.
• The rule, checklist or template you would reuse next time.

Cursor ships often, so here is the current state of the surfaces this page touches. Each row links to the source where you can confirm the detail.

Yes, and the shape stays the same. The same loop that turns an issue into a reviewable diff turns a fuzzy knowledge-work problem into a working tool: Problem, then context-dump, iterate on the approach, test on a few examples, refine.

What changes is the division of labor, not the steps. You stay the domain expert who knows what good output looks like and where the edge cases hide. The agent does the repetitive execution. You stay in the loop because you're the one who can tell whether a result is actually right.

Route by how you will verify the result, not by how big the task looks. If the output is something you can watch or read afterwards, send it to a cloud agent and judge the artifact it hands back. If you expect to redirect it halfway through, keep it local and in front of you.

The costs make that split concrete. A cloud run takes roughly 10-15 minutes minimum end to end and you can have about 3-5 going at once, each on its own branch. That shape is wrong for a two-minute edit and right for work you can hand off and come back to, which is also why the delegation question is really a question about your own attention rather than the agent's capability.

Automations sit one step further out. An automation is a cloud agent with a trigger, an instruction and a deliberately narrow set of tools, and probably the most common misstep is building one for a workflow nobody has run by hand yet. Run it manually a few times first. You want to know what the output looks like before a schedule starts producing it every morning, because a bad automation does not fail, it just quietly ships something nobody reads.

The SDK is for when the caller is your own code rather than a person.

In the context window far more often than in the model choice. Quality drops steeply as the window fills, noticeably by 70-80% and definitely before 90%, so the working ceiling is somewhere around 60-65% and plenty of practitioners move on nearer 50%.

What makes running to the limit worse than it sounds is compaction. Near the limit the agent compresses what came before, then behaves as though it never had the detail, while you keep paying for all those tokens. Both halves of that trade go against you.

The fix is not a bigger window. Before you get close, ask the agent to summarise what it has done and paste that summary into a fresh agent. The context the next one needs was never the conversation anyway. It is the codebase, the commits and the code the last agent left behind, and all of that is still sitting there whether the chat survives or not.

One more mechanical cost is worth knowing about. Switching models mid-session breaks the cache, so an unplanned swap costs you the cached context on top of the time. Decide up front where you reasonably can.

The measurement problem arrives. A University of Chicago study of 1,000 organisations adopting Cursor reported a 39% increase in org-level output, with teams merging 39% more pull requests once Agent became the default mode. Merged PRs are the easiest thing on that list to count and the furthest from the thing anyone wanted.

Hold velocity and quality side by side or the number will lie to you. Velocity on its own rewards shipping code that gets rewritten next week; quality on its own rewards shipping nothing at all. The pair that reads honest is time-to-marketHow fast a feature actually reaches customers; the outcome metric the velocity and quality pillars ultimately serve. Press Enter for the full definition. against the customer-facing defect trend, and if you can only watch one, watch whether features reach customers faster while defects stay flat.

And the two metrics most dashboards lead with predict close to nothing. Lines of AI-written code is just more code to review and maintain. Active users counts the person who opens the agent weekly the same as the person who rebuilt their week around it.

Cursor's own instrumentation probably beats whatever you would assemble by hand. Conversation InsightsA Cursor analytics view that passively categorises what agents are doing (new features, bug fixes, refactors) so leaders can see where engineering time goes. Press Enter for the full definition. categorises work as new feature, bug fix or refactor and can flag under-specified agent turns that would have gone better through Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition. first. Cursor BlameAn augmented git blame that records line-level human and agent co-authorship, so you can trace which code was written by AI versus a person. Press Enter for the full definition. adds line-level agent co-authorship, which is what turns "does agent-written code churn faster" from a debate into a query you can run.

Often, yes. Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition. and a saved trail are priced for work that spans more than one file, and on a genuinely quick change that ceremony is overhead. People who use this daily skip it, and the guides that pretend otherwise are the reason the advice reads as bureaucracy.

Where is the line? The usual advice is anything non-trivial, which is vague, and I am not sure it sharpens much past "more than one file, or code you do not already know." One security engineer who started out skeptical of plan mode now defaults to it for anything net-new, because in plan the agent finds the relevant injection points up front rather than discovering them mid-edit. For quick changes he still skips it.

If you keep one habit from all of this on small work, make it a fresh agent per new topic. Continuing yesterday's chat drags every bit of yesterday into today's request, and starting over costs nothing.