Coding with agents (1): where to put your attention

I code with AI every day. After GitHub Copilot and Cursor, I moved to Claude Code, with OpenRouter and OMP so I don't depend on a single model.

My keyboard wears out more slowly. What has changed the most is where my attention goes.

The bottleneck has moved

An agent writes in minutes what used to take me a day. It drinks a lot less coffee than I do. So it writes a lot more. And all of it has to be reviewed.

Code has become abundant. My attention hasn't. Where should I spend it? I tried two answers before finding mine.

Three ways to code with an AI

The first one scared me, the second one wore me out.

Delegate everything: vibe coding

flowchart LR
    v1["Me<br/>a wish"] --YOLO--> v2["The agent<br/>everything else"]
    classDef accent stroke-width:3px
    class v1 accent

You describe, you accept, you don't read. For a throwaway prototype, why not.

For code that has to live, it's a time bomb whose timer nobody has read. Nobody knows what the code does anymore. The tests check what the agent wrote, not what I wanted. Debt piles up quietly. In a team, it's worse: not reviewing your own code means handing the work to the colleagues who review it. And I learn nothing. For me, it's a no.

Control everything: micromanagement

flowchart LR
    m1["Me"] --> m2["The agent"] --> m3["Me"] --> m4["The agent"] --> m5["Me"] --> m6["…"]
    classDef accent stroke-width:3px
    class m1,m3,m5 accent

That's what I did for months: one instruction, one diff, I approve, next instruction. A bit like teaching someone to ride a bike without ever letting go of the saddle.

The control feels total, but it doesn't parallelise: two sessions, twice as many questions. I become the bottleneck. And my attention crumbles: I approve pieces without judging the whole, until the yes becomes automatic.

What I aim for: upstream I frame, downstream I judge

flowchart LR
    c1["Upstream<br/>I frame"] --> c2["The agent<br/>codes, tests, commits,<br/>gets reviewed"] --> c3["Downstream<br/>I judge"]
    classDef accent stroke-width:3px
    class c1,c3 accent

Quality is decided at two moments: upstream, when I decide what to build, and downstream, when I judge what was built. The middle I delegate, but within limits: tests first, and a review by an agent that didn't write the code.

Framing weighs more than it seems. Jovi De Croock puts it in one sentence¹: "If the intent is wrong, proving conformance to it gets you the wrong thing faster."

Why not let an agent review?

An agent doesn't get tired, reads everything to the end and never skims on a Friday at 6 pm.

Because it answers for nothing. When production breaks, it's my name on the commit, not the agent's. And it's not the one who gets the call. Even gittifacts, which pushes automation the furthest, records in every commit "which human is accountable for that agent".

And because reviewing covers several jobs. Each one catches different things.

Who	Best at	For example
Machines (CI, measuring tools)	what can be checked	a test that fails before the fix and passes after, coverage, mutation score2, a changed API or dependency
The reviewer agent	what can be read, fast and everywhere	a forgotten convention, an untested edge case, a gap between the plan and the diff
Me	what has to be judged	the right problem, the context (legacy, past incidents), a product trade-off

flowchart LR
    C["A change"] --> M["The machines<br/>what can be checked"]
    M --> A["The reviewer agent<br/>what can be read"]
    A --> H["Me<br/>what has to be judged"]
    H --> L["Shipped"]
    classDef accent stroke-width:3px
    class H accent

Each layer filters what it can see. By the time it reaches me, only what the others can't judge is left: that's where my attention is worth the most.

The article gives a rule I find fair: an agent can add doubt, never remove it. In gittifacts, a model's opinion can make a review stricter, never lighter. Same when a check is missing: "Unknown means escalate."

Two hats

If all I keep is the framing and the verdict, I have to carry the what and the why as much as the how. An agent does what it's asked. When the request is vague, it fills the gaps with whatever it finds. What it lacks is the domain context, the business perspective and experience.

A made-up and deliberately simplistic example:

flowchart TD
    D["“We need<br/>an export<br/>of the orders”"]
    D -- "the agent alone" --> A1["Every order,<br/>synchronous, tested<br/>on 20 rows"] --> A2["In production:<br/>a big customer<br/>causes a timeout"]
    D -- "product hat" --> P["Who for?<br/>What for?"] --> P2["“For accounting,<br/>every month”<br/>so the month's export"]
    P2 -- "tech hat" --> T["We know the production constraint:<br/>one customer places<br/>200,000 orders a month"] --> T2["We suggest asynchronous<br/>jobs, in batches"]
    classDef accent stroke-width:3px
    class P,T accent

The product hat shrinks the need: the month's export, not the whole history. The tech hat knows what the code doesn't say: the real volume in production. Hence asynchronous jobs, in batches. The agent did exactly what it was asked, and its tests pass.

So I frame the product first, then the technical side. And I review the job to be done first: is the delivered behaviour the one that was asked for? Maintainability and performance come after.

Why I still review

Jovi De Croock goes further than I do: "Humans approve intent. Machines prove conformance." When automated checks (tests, coverage, mutations) show a change carries no risk, his platform merges it with no human involved. On two conditions: every change ships behind its own feature flag and can be undone in seconds, and the platform first has to show it classifies changes the way humans would have.

I still review. For four reasons.

• I answer for what I ship, and for what breaks.
• I want to understand before I ship. Code I haven't understood, I can neither defend nor fix in an emergency. And I can't build on it when we iterate: you need a base that the AI isn't the only one to know.
• I want to be able to challenge the agent. Why this query? Why not the method that already exists two files away?
• I want to keep learning. Reviewing is where I learn the most about the code and the product.

Understanding the code also matters away from the editor. When we shape a feature with the product manager and the team, you need to know what you're standing on. You're not going to open a chat with the AI in the middle of a meeting every time you have a doubt. To move forward, it really helps to know what's under the hood.

Where the human stops

I'm not the only one looking for the right setting. Here are the methods I looked at, from delegating everything to controlling everything. The gauge shows how much room the human has.

Method	Human share	Who approves the plan	Who reviews the code	Who merges
Vibe coding	○○○○○○	nobody	nobody	the agent
AI-Driven Dev (autonomous mode)	●○○○○○	the human, through a ticket	an agent	the team, following its process
gittifacts, by Jovi De Croock	●●○○○○	the human	machines and an agent, the human if it's risky	the merge queue, on its own when nothing is risky
killer-saas, by Mike Codeur	●●●○○○	the human	an agent, then the human	the agent
My workflow	●●●●○○	me	an agent, then me	me
Matt Pocock's skills	●●●●●○	the human, spec and tickets	the human at every commit, then an agent	the human
Micromanagement	●●●●●●	the human	the human, at every diff	the human

Everyone agrees on the core: a plan approved upstream, a judge who didn't write the code downstream. The methods differ on what comes next. killer-saas is the closest to mine, give or take one move: it lets the agent merge. It starts from a new product. I start from code that already exists and that a whole team maintains. The merge, I keep.

Where I put my attention

Not everywhere. On three things.

1. Upstream, on the intent. That's where a minute of attention pays off the most.
2. Downstream, on what has to be judged. What can be checked, machines do better than me. What can be read, the reviewer agent too. What's left for me is the right problem, the context and the product trade-off.
3. On enough of the code to answer for it. Enough to defend it, fix it in an emergency and discuss it with the team without asking the AI.

The rest I delegate: writing, testing, the first review. And I stop watching every diff as it goes by. My eyes thank me.

The questions that remain

The judgement you need to review a machine, we built by writing. If the agent writes for us, where do we practise? Juniors will feel it first. I don't have an answer yet.

And another question follows: how do you review a colleague's code? If they coded with an AI and already reviewed it themselves, does my review still add anything?

All this makes me want to dig into review between colleagues: what a human eye still brings when the author has already had their code reviewed by an agent, and how to share the work without reviewing the same thing twice.

And I owe you more details on the workflow I'm still iterating on: a plugin for Claude Code, four roles, two stops, a log that learns from one project to the next, and plenty of things that don't work yet. I won't promise which of the two notes comes out first. Whichever is ready, probably.

Update, October 28, 2026. Meanwhile, I've kept iterating on my workflow. But I don't want to reinvent the wheel either.

So I signed up for Software Factories for Real Engineers, Matt Pocock's course. I'm putting my workflow on hold while I take it, then I'll come back to what it taught me, and to what's left of mine.