Agentic Engineering: More Code Isn't Enough

In my last post using Kent Beck’s 3X Framework, I argued that agentic engineering is being perceived at different phases of maturity depending on where you sit. Executives believe the systems are mature, in Extract. Practitioners are doing the work of Expand. The practice, the tools, the workflows are still churning in Explore.

Underneath that churn, there are four foundations we know provide value:

• Context: What the agent needs to know about the situation — the codebase, the coding patterns, the how-tos for the frameworks and systems we already have.
• Intent: What we want the agent to do and why. The clarity of the intention drives the quality of the outcome. Garbage in, garbage out. So much of developer craft is moving to this process.
• Code generation: Turning context and intent into working code. The most obvious win, especially with developer-steered agentic coding sessions.
• Code review and approval: Checking that the generated code is correct, consistent, and safe to merge. Agentic code reviews are very good, but removing people from the process creates anxiety.

Each of those made it through Explore and these are the baseline for any engineering organization. Developers are definitely able to Extract value and deliver work faster using these foundations.

If you aren’t succeeding with developer-steered agentic coding sessions, you aren’t ready to move on to the next level. Even if you are successful at creating more code, you still need to figure out how to turn that increased code into increased value.

It’s tempting to head toward the “dark factory” model: agents running 24/7, writing more and more code. But ask the pre-agentic version of that question: if we hired three times as many developers and set them loose writing code, would that create three times the value? We already know it wouldn’t. Code production was always the easy part to blame for not increasing business value. Agents removed code production as the bottleneck, so now you more easily see how planning, decisions, judgement, and understanding are the real bottlenecks.

Get Good at the Basics

Getting good at the four pillars with developer-steered sessions — a human in the loop, driving — is a critical milestone and shouldn’t be skipped. Context that yields code matching your patterns. Intent sharp enough that the agent builds the right thing. Generation you can steer. Reviews, human and agent, that catch what your experts would.

It’s the org-level version of something from the last post: autonomy is earned, not granted. If developer-steered coding isn’t reliably producing work you’d actually ship, then dark factories and features-in-a-day are fantasies. You’d only be scaling something that doesn’t work yet and yields no value. You’re ready when a developer and an agent reliably turn a clear intent into shippable, reviewed work and the developer still understands what came out — not when the agent simply produced a lot. Once you hit this milestone, you’re able to separate the hype from the actual work needed to level-up.

The Part Agents Can’t Do

Say you’ve got all four pillars humming. An agent can now execute every one of them. It still won’t produce business or customer value on its own because the value was never purely in the code.

Writing code was always the smaller part of the job; one line of research puts developers at roughly 14% of the week actually writing code. Agents took over that slice and made it nearly free. Deciding what’s worth building, shaping why, judging whether the result is right and what it means for the next move — that is the part that turns code generation into value, and it’s the part that doesn’t really automate.

Three activities still depend on people, and they’re all the same shape:

• What to build. Direction. An agent optimizes toward a target it’s handed; it doesn’t decide the target is worth hitting.
• Driving intent. The clarity of the why drives the quality of the outcome. You don’t hand off authorship of intent, you participate in it.
• Understanding the result well enough to steer the next loop. Not a rubber stamp on generated code. A working model of the system, at the architectural level, good enough to decide what happens next.

Some people really want to ignore or downplay the importance of understanding. Geoffrey Litt describes understanding as a new bottleneck: there are two reasons to understand an agent’s code. You can understand it well enough to evaluate (thumbs up, thumbs down) or well enough to participate, to hold a model of the system that lets you decide what comes next. Agents are getting good at supporting evaluation. Participation is the part that keeps you valuable, because a project is never one loop, it’s many. Participation is what lets you consider feedback from the existing loop and drive the direction of the next one.

Evaluation-only comprehension feels like rigor and good process, but we know that it becomes mechanical especially when under time pressure or volume. You can approve a correctly compiling diff every day and understand the system a little less each time. Margaret-Anne Storey names what accrues an “accumulation of not knowing” — cognitive debt, and it’s the debt you can run up while every check stays green. The model in your head becomes less clear, and at some point you can’t drive intent anymore because intent is more than “is this correct,” it’s “why this approach should be used and not the alternatives.”

What This Sets Up

So “more code isn’t enough” is a constraint statement. Agents made generation nearly free, and none of the critical thinking parts got faster or easier. Don’t confuse moving code faster for progress if it doesn’t create value for the business or its customers. It’s just code churn.

Even the people whose job is measuring this draw the same line. DX frames the goal as capacity, not horsepower, and is careful to wall off engineering capacity from business value, noting the far side is often not an engineering question at all. This post is about that far side. The judgment that turns capacity into value is exactly what an agent can’t do for you.

That human work isn’t a tax on velocity. The output of the high-judgment work is what makes agent volume safe and valuable in the first place. The decision making, pattern creation, and system understanding have clearly become the true craft. Understanding compounds and builds into value throughput.

That leaves three questions: what qualifies for the fast path, what has to stay on the slow one, and what we owe the people who need to keep understanding a system they’re no longer reading line by line.