Four levels of working with a coding agent (and where the value actually is)

You have to find the line between what the human does and what the agent does - that’s the whole art of this right now. There isn’t one right answer, but there are a few recognisable failure modes on either side of it, and it’s worth knowing which one you’re closest to.

L0: “Build this, now build this, now build this”

The vibe-coder pattern. No planning, no human judgement applied to the output, just relying on the agent to make a long chain of correct guesses in a row. This reliably fails for anything that has to survive in production, because both architectural and implementation errors compound silently until the whole thing is unrecoverable. Very 2025. Rare these days, but still out there.

L1: “You’re so smart, do everything”

Mostly experienced developers the first time they seriously try an agent. The feeling is: if the hype is even half true, it should be able to just do the thing. So you give it a couple of sentences, go make a coffee, come back, and see what happened.

This is really a challenge dressed up as delegation - and the result is usually a post-mortem: “AI is overhyped, look at this terrible thing it did.” Which is true, as far as it goes, but it’s not actually informative. Almost nothing works well when handed two sentences and no context. Humans don’t either.

L2: Tiny pieces, no joined-up thinking

The opposite failure. This is what it looks like when you don’t trust the agent, so you hand it work the way you’d hand tasks to an offshore team you don’t trust either: “create a component which renders a header with an optional subheader and breadcrumbs, here are the styles.” Tiny, tightly-specified cards, no one holding the full picture.

It reminds me of 2001 - huge waterfall plans, nobody with the whole system in their head. Same problem here. If the agent isn’t given enough context about the plan and the intention behind it, it can’t add any value beyond typing. This works, in the sense that it produces correct code, but it’s dramatically slower than what’s actually possible, because you’ve thrown away the agent’s ability to make any judgement calls at all.

L3: Building without learning

This is the subtler failure, and the one I think is most worth watching for. It’s what happens once developers start trusting the agent for everything and stop building their own mental model of the codebase alongside it. The tools are tuned for getting work done - they’re great at making progress in the short term, at the cost of the human quietly losing the grain of the codebase.

When you’re working on something directly, you notice the bumps: the ergonomic issues, the missing abstractions, the way pieces fit together well or badly. That accumulated feel is what lets you answer questions like “how hard will this actually be?” or “should we fix this now or defer it?” or “does this genuinely need restructuring, or is that just how it looks?” An agent won’t answer those for you, because it doesn’t carry that long-term feel between sessions - it’s relearning the codebase from close to scratch every time, however good your documentation is.

The fix isn’t to stop using the agent for building. It’s to deliberately keep forming your own hypotheses about the codebase and checking them against what the agent finds, rather than letting the agent’s confidence substitute for your own understanding.

The actual job now

None of these levels is “correct” for every task - L2’s tiny well-specified tickets are sometimes exactly right, and full delegation is sometimes fine for genuinely disposable code. The job isn’t picking one level and living there. It’s calibrating, task by task, which parts of the work the human needs to hold and which parts the agent can safely carry - and noticing when you’ve drifted further toward L1 or L3 than the task actually warrants.