What to Build vs How to Build: Agentic Loops Rewire Attention

For most of software’s history, the scarce resource was execution. The hard part was getting the code written, made correct, and shipped — so that’s where teams spent their best people and their attention. Agentic development loops break that assumption. When a fleet of agents can implement, test, and self-correct a change against a real environment, the cost of the how collapses — and the whole question of what to build vs how to build stops being rhetorical. The bottleneck moves, and if your team’s attention doesn’t move with it, you get very fast delivery of the wrong things.

This is the strategic follow-on to our explainer on the agentic development loop. That piece defined the loop as a control system; this one is about the consequence that actually shows up on a roadmap: where your engineers’ scarce attention should go once the loop owns most of the typing.

Attention shifting from writing code to deciding what to build — the what to build vs how to build reframe

📊 The Data: A Delegation Gap, Not a Delegation Cliff

Start with the numbers, and treat them as what they are — Anthropic’s own figures from its 2026 Agentic Coding Trends Report, directional rather than gospel. Developers now use AI in roughly 60% of their work, but can fully delegate only 0–20% of tasks end to end. That spread has a name worth remembering: the delegation gap.

The instinct is to read the gap as a limitation — “see, it still can’t really do the job.” That’s the wrong read. The gap is the shape of the human’s remaining job. The 60% is execution the loop can carry; the stubborn 80% that can’t be fully handed off is precisely the work that isn’t mechanically verifiable or hasn’t been specified clearly enough to delegate. That’s not a model deficiency you wait out. It’s judgment, and it’s where your people should be.

Two more figures from the same report frame the stakes. Roughly 27% of AI-assisted work is tasks that wouldn’t have existed otherwise — cheap execution expands the backlog rather than draining it. And in one cited run, a single agent implemented a complex feature across a 12.5-million-line codebase in one seven-hour session. Hold those two together: throughput is genuinely enormous, and the appetite for new work grows to consume it.

The delegation gap: AI touches most of the work but only a fraction is fully delegable

🪣 Cheap Execution Doesn’t Empty the Backlog — It Moves the Bottleneck

There’s an old economic pattern here. When something valuable gets dramatically cheaper, we don’t consume less of it — we find far more uses for it, and total demand goes up. Cheap code is the same. Every product idea that was “not worth the engineering time” is suddenly back on the table, which is why the backlog expands instead of clearing.

Anthropic’s report compresses the whole shift into one sentence worth pinning above the roadmap: “the bottleneck is no longer writing code — it’s clarity about what to build.” When execution was the constraint, fuzzy requirements were survivable because the slow part downstream hid the cost of the ambiguity. Now the downstream is fast. A vague spec doesn’t cause a slow build anymore; it causes a fast build of the wrong thing, delivered before anyone noticed the misunderstanding. Ambiguity used to leak out over weeks. Now it ships by lunch.

That is the real reason “what to build” matters more than “how to build” in an agentic shop. It isn’t a motivational poster. It’s that the cost of being unclear went up at exactly the moment the cost of building went down.

🧭 What “What to Build” Actually Means

“What to build” is doing a lot of work in that sentence, so break it into the three kinds of judgment that actually became scarce:

Product judgment — is this worth building at all? With execution cheap, the constraint is no longer “can we?” but “should we?” The ability to kill a plausible feature because it doesn’t move the thing that matters is now a high-leverage skill, not a manager’s afterthought.
Architectural judgment — does this fit, and can it be decomposed? Agents work best inside clear boundaries. Someone has to decide where a change belongs, how to carve work into scoped units an agent won’t hallucinate across, and which seams keep the system changeable. That’s design taste, and the loop can’t originate it.
Verification judgment — how will we know it’s right? Because verifiability is the precondition for autonomy, defining “done” mechanically — the acceptance criteria, the tests that can’t be faked — is now upstream design work, not a QA chore tacked on at the end.

Notice that all three are specification activities. They happen before and around the loop, not inside it. The engineer’s value migrates to the edges of the loop, where intent goes in and judgment comes out.

The three scarce judgments — product, architectural, and verification — that make up deciding what to build

🎯 The Attention Reallocation, Concretely

Abstractions are easy to nod along to, so here’s what the shift looks like on an actual calendar. Time that used to go into typing implementations moves into:

Writing the spec the agents work against. A precise acceptance-criteria document is now a primary engineering artifact — the shared source of truth every agent in the loop reads and the verifier grades against. Sloppy specs are the new sloppy code, and they fail more expensively.
Reading diffs instead of writing them. When agents produce the changes, the scarce skill is evaluating code fast and well. We argue this is the defining engineer skill of the era in Reading Code Is the New Superpower — the read/write ratio inverts, and reading wins.
Reviewing for design, not syntax. With a reviewer agent doing the first pass, human review rises in altitude: does this diff express the right design, does it belong here, is this a pattern we want to live with for five years. The PR becomes the steering wheel, not a rubber stamp.

The tell that a team has made this transition is measurable: review comments trend away from “this will NPE” and toward “this doesn’t belong in this bounded context.” The attention has moved up the stack.

🏋️ What Elite Engineers Should Practice Now

If the leverage is at the edges of the loop, deliberate practice should point there too. Four skills compound:

Reading code fluently and critically — the single highest-return investment, because every downstream judgment depends on evaluating agent output quickly.
Decomposition into agent-legible work-units — carving a problem into bounded, independently verifiable tasks. This is design-for-change thinking, and it’s what lets you fan work out without it collapsing into mush.
Spec and acceptance-criteria authorship — writing intent precisely enough that a capable agent, and a strict verifier, both hit the same target.
Architectural taste — the accumulated judgment about coupling, boundaries, and what will hurt later. It’s the one thing on this list the model genuinely can’t hand you, and it’s now your primary product.

None of these is new. What’s new is that they moved from “senior nice-to-haves” to the core of the job, while raw implementation speed — the thing we used to screen for — became the part you delegate.

⚠️ The Trap: “Cheap to Build” Is Not “Worth Building”

The failure mode of this whole shift is seductive, so name it plainly. When building gets cheap, the backlog explodes — remember the 27% of net-new work. A team that hasn’t relocated its attention will happily point the loop at all of it and ship a mountain of plausible, well-tested, unnecessary software. Fast delivery of things that shouldn’t exist is still waste; it’s just expensive waste that looks like productivity.

The discipline that protects you isn’t a better model. It’s the judgment to say no — to spend the newly-freed attention deciding what not to build, and to treat “we could ship this by Friday” as the beginning of the question, not the end of it. Cheap execution raises the value of taste; it doesn’t replace it.

❓ Frequently Asked Questions

Does “what to build over how to build” mean engineers stop needing to understand implementation? No — the opposite. You can’t evaluate a diff, write a verifiable spec, or judge an architecture without deep implementation understanding. The shift is that you apply that understanding to judgment and review rather than to typing.

Isn’t the delegation gap just a temporary limitation that better models will close? Partly, but the durable part isn’t a model limitation at all — it’s that ambiguous, hard-to-verify decisions (what’s worth building, what “correct” means) are human judgment by nature. Better models widen what’s delegable; they don’t remove the need to decide.

How do I actually move my team’s attention up the stack? Make specs and acceptance criteria a reviewed deliverable, put a reviewer agent in front of human review so people spend their time on design, and measure whether review comments are trending toward architecture. Structure the incentives, don’t just exhort.

Won’t cheaper building just let us ship more good things? Some, yes — but only if the “what to build” judgment keeps pace. Without it, cheaper building mostly lets you ship more things, good and bad alike. The expanded backlog is an opportunity and a hazard in equal measure.

📚 Further Reading

The Agentic Development Loop, Explained for Engineers — the control-system mental model this piece builds on (start here).
Reading Code Is the New Superpower — the concrete skill that replaces typing as your highest-leverage practice.
The Orchestrator-Worker Pattern for AI Coding Agents — how the reviewer/verifier roles that raise human attention are actually wired.
Anthropic, 2026 Agentic Coding Trends Report — the delegation-gap, net-new-work, and “clarity about what to build” figures cited above (the numbers are Anthropic’s own).

📚 Recommended Resources

Disclosure: some links below are Amazon affiliate links. If you buy through them, I earn a small commission — at no extra cost to you — which helps keep this site running.