It stopped feeling futuristic
When Cursor made the agentic view its default, I remember thinking: I’m not there yet.
Not “I’m not ready for AI to write code.” That had already happened. What felt unfamiliar was the next shift: letting the agent move through the codebase while my attention moved up a level.
The resistance was muscle memory. I was still an IDE-native developer: file tree pinned open, jumping between files, holding the project structure in my head, watching the code change in place. That was what coding felt like.
The new loop asks a different question of you. Less “where is this file?” and more “what changed, why, and does the diff make sense?” The tools still give you trees and terminals and patches — but the default center of gravity moves. The diff becomes the surface you work on. The tree becomes context you consult.
The unit of work kept growing
This didn’t arrive all at once. Looking back, every wave of tooling handed the model a bigger unit of work — and asked me to trust it with a bigger one.
Copilot completed the next thing: a line, a function, a boring bit of glue. The mental model was still mine, the cursor was still mine, the open file was still the center. It sped up the typing without changing what I paid attention to.
ChatGPT reasoned over a bigger chunk of intent — but split across two windows. The IDE had the codebase; the browser had the conversation. I copied code out, explained what I wanted, pasted the answer back. Powerful, and clumsy: the context boundary was manual, and I was the integration layer.
Then the chat moved into the editor. Cursor made prompting feel attached to the codebase — point at a file, a selection, an error, and ask for the change in place. The unit was no longer the next line but a local transformation: refactor this path, update these tests, explain this flow.
But I was still inside an IDE loop. I prompted from the same place I navigated, inspected, edited, and organized the project in my head.
Then the agent stepped outside that loop. It moved through the codebase on its own — reading, editing, running, correcting — and the natural place for my attention was no longer the cursor. It was the result. That was the shift I hadn’t been ready for, and the one the opening interface was quietly asking me to make.
The map still matters
Attention on the result doesn’t mean the map disappears. If anything, architectural judgment matters more. You still have to know how the project is structured, where the boundaries are, and which decisions the codebase is already committed to.
What changes is what the map is for. Less manual navigation, more review: did the agent touch the right layer, preserve the right abstraction, make a change that belongs here?
The loop starts before code
Working this way, the loop starts earlier and ends later.
Earlier, because the real work begins before the agent writes anything: framing the task, naming the constraints, deciding which parts of the architecture matter, giving enough context that the agent doesn’t solve the wrong problem well. The prompt stops being an instruction and becomes a handoff — part brief, part constraint list, part review rubric. The better that handoff, the less the agent is merely generating code and the more it’s working inside a shaped problem.
Later, because the work doesn’t end when code appears. It ends when the diff has been read, the tests make sense, the design still holds, and the change can be explained as part of the project rather than as an isolated patch.
Described too quickly, that sounds passive — the agent writes, the developer watches. It isn’t. Human judgment shows up hard at both ends: before, in the grilling — what’s the business outcome, what’s the right scope, is this small enough for one pass or does it need splitting; and after, in review — did the implementation match the intent, did the agent stay inside the boundaries, does the change belong in the system.
Review became a scale
Matt Pocock put the real decision well:
The “should you read code” debate is dumb because the real decision isn’t binary, it’s a scale:
- Reading every line of every diff
- Scanning every diff, reviewing important lines
- Ignoring diffs but understanding the “why” of every PR
- Spot checking PRs instead of reading every one
- Ignoring PRs, but doing regular spot checks on the codebase
- Ignoring the code, but spot checking agent traces to help improve the system
- Ignoring both the code and the system, let models handle everything
Where are you on the scale?
The question isn’t whether code review disappears. It’s where you sit on that scale for this change — and you don’t have to sit in one place. My own loop borrows from his skills workflow — grilling, spec, tickets, implementation, review, and Wayfinder when the problem is too large or foggy for one session. I don’t follow it mechanically, but the shape holds: an idea gets pressure-tested before it becomes implementation.
Most days I’m somewhere around two and five: scanning diffs for intent, boundaries, naming, and tests, spot-checking the PRs that carry architectural risk, and doing regular passes to catch the system drifting. I am not reading every generated line with equal intensity, and I’ve stopped pretending that’s the goal.
The posture changed
This can feel less like coding only because our old picture of coding was so tied to direct manipulation. But the responsibility didn’t move away. The work is still design, judgment, and accountability for the shape of the system. One mode didn’t replace the other — the default posture changed.
So when I think back to that first reaction, I’m not there yet, I think it was true. I wasn’t there yet because the interface was asking me to work at a different altitude. Not above the code, exactly. More around it: shaping tasks, carrying the architecture in my head, reviewing diffs, deciding what kind of change the project can absorb.
The surprising thing is how quickly that stopped feeling futuristic.