Attention consists of
all you have.

That paper changed software. But it also contained an accidental truth about the humans now using what it created.

Attention is all you have.

01The new bottleneck

The bottleneck in software development has shifted. For decades it was compute — cycles were expensive, memory was scarce, and the craft of programming was largely the craft of working within hard physical constraints. Then infrastructure became cheap and elastic, and the bottleneck moved to people. You could scale a system infinitely; you couldn’t scale the team that built it. The best engineering organizations were the ones that could attract, retain, and coordinate the most talented developers.

Now the bottleneck has moved again. Agents write code. They write it continuously, in parallel, without fatigue. The constraint is no longer who you can hire or how fast they can type. The constraint is how well you can direct the work — which problems you choose to solve, in what order, with what intent. The constraint is attention.

This is a more uncomfortable shift than it sounds. Attention is harder to scale than headcount. You can hire another engineer. You cannot hire another hour of your own focused judgment. And judgment — about what to build, what to defer, what to delete, what actually matters — is precisely what agents cannot supply.

02Leverage and failure modes

An agent with a well-defined task and clear constraints is extraordinarily capable. The same agent pointed at an ambiguous problem with vague success criteria will generate confident, plausible, wrong output. It will fill the space you gave it. The quality of what it produces is almost entirely a function of the quality of attention you brought to defining the work.

This creates a new kind of leverage — and a new kind of failure mode.

The leverage: a developer who is good at directing agents, who can decompose problems cleanly, define acceptance criteria precisely, and recognize when output diverges from intent — that developer is now operating at a multiplier that simply didn’t exist before. Not 2x. Meaningfully more.

The failure mode: the same developer, working too fast, context-switching too freely, accepting agent output without sufficient scrutiny, accumulates decisions they didn’t actually make. The codebase fills with code that is technically theirs and strategically nobody’s. It works until it doesn’t, and when it doesn’t, no one fully understands why.

03Allocating attention

The developers who will define this era are not the ones who can prompt most cleverly. They’re the ones who can sustain the kind of focused, structured attention that turns agent capability into working systems. That means knowing when to go deep and when to delegate. It means building systems that preserve context between sessions so attention compounds rather than resets. It means treating architectural decisions as first-class artifacts, not ephemera that live in a chat window and disappear.

The old question was: how good is this developer? How fast can they write code, how deeply do they understand the system, how well do they collaborate?

The new question is: how well does this developer allocate attention? What do they choose to understand deeply versus delegate entirely? How do they structure work so their judgment is applied where it matters most?

These are different skills. The transition is not automatic.

04The developer who wins

The irony is that the tool creating this constraint also offers the clearest path through it. Agents are good at executing within defined boundaries. They are not good at defining boundaries themselves. Structure, context, intent — these have to come from somewhere. The developer who builds systems to make that structure persistent, to make intent legible across sessions and to agents and to future selves — that developer gets to spend their attention on the decisions that actually matter.

Everyone else will spend it re-explaining the project.