Attention is the bottleneck

What “productive” means in software engineering has shifted, and I think a lot of us feel it without having named it:

The right unit of productivity for agentic development isn’t output per hour. It’s accepted progress per hour of human attention.

The underlying idea isn’t new, but AI has made it impossible to ignore.

I do a lot of development outside work. At any given time, I have several projects in motion and a backlog that never seems to get shorter. I put in time most nights and on weekends, and every one of those projects stalls at the same point: waiting for me to sit down and give it attention.

That got me asking: how can I keep moving these projects forward while minimizing the amount of active attention they require?

The answer came from recognizing that my personal projects have a different set of constraints from most professional software projects. I have:

Tokens included with subscriptions that would otherwise go unused (read: “free”)
No hard delivery deadlines
Plenty of wall-clock time between when I can dedicate attention

So that became the experiment: spend the two cheap resources to conserve the expensive one, and find out what it costs.

The attention trade-off

AI output and human supervision have a complicated relationship.

With close supervision, AI-generated output stays aligned with what I want. I can answer questions, correct misunderstandings, and catch integration problems as they appear.

As I reduce that supervision, an agent can work for longer without me, but also has a higher risk of drift. Small misunderstandings compound, and components that look complete in isolation may not integrate as expected.

The trade-off: attention falls as autonomy rises; drift risk climbs to meet it.

Producing more code isn’t the goal. The metric I care about is:

Attention-adjusted throughputAccepted progress per hour of active human involvement

The workflow I’m testing

Traditional development already occupies the high-supervision end of the spectrum, so I’ve been deliberately experimenting at the other extreme.

After I have an idea for a feature or application, I:

Write a spec
Do a deep dive “grilling” session to solidify my design and get all my ideas down on paper
Turn the work into a dependency graph of stories
Dispatch an agent anytime a story becomes unblocked

The grilling session is exactly what it sounds like: an agent interrogates my spec, trying to find holes in the plan and clear up any ambiguity before a line of code gets written.

That setup takes an hour or two. Once the work is running, though, it can continue for most of a day with little attention from me.

So when is a feature complete?

A feature isn’t complete simply because an agent produced an implementation or closed every ticket. It’s complete when it satisfies its acceptance criteria, integrates with the rest of the system, and passes its quality checks. Some of the attention saved during implementation gets spent here instead.

Long-running, minimally supervised work tends to drift. In my experience, the individual components are often implemented well enough. What’s missing is usually whatever lives between them: inconsistent assumptions, incomplete integration, mismatched interfaces, or behavior that no single ticket explicitly covered.

So I begin another cycle.

I run a thorough review from several perspectives, including an adversarial pass: assume the feature is broken, then hunt for evidence. I turn the findings into a new spec, grill and break it down, rebuild the dependencies, and start the system again.

One iteration: each pass around the loop covers less ground than the last.

Each cycle moves the project closer to satisfying the system-level behavior I actually wanted. In practice it takes two or three, and the scope gets smaller each time.

I can still inspect pull requests and check progress along the way. The important difference is that I don’t always have to. Instead, I concentrate my attention where it has the most leverage: defining the work, being opinionated about design foundations, and evaluating the integrated result.

Trading tokens for attention

I’m not claiming that an hour of planning reliably produces a 100% complete feature.

This process takes multiple passes. It uses substantially more tokens than I would use if I closely supervised every step. It may also take longer on the wall clock.

But tokens and wall-clock time aren’t my bottlenecks. Attention is.

That changes what “efficient” means.

After work, I can review a few cycles and move several projects toward their next milestone, all on a subscription I’m already paying for. More importantly, I can preserve my limited time for the parts of engineering I find most interesting: shaping ideas, making architectural decisions, and solving the problems that actually require my judgment.

Case study · A small developer library

Here’s what that looked like on a recent side project, a small developer library.

Evening one — Spec, grill, dispatch

I wrote the spec, grilled it, and broke it down into fourteen stories with a dependency graph. Then I dispatched the whole iteration and walked away. Agents picked up stories as their dependencies unblocked, and by the time I checked back in, all of it had merged with tests passing. By the letter of the tickets, the feature was done, and I hadn’t watched any of it happen.

Evening two — The adversarial pass

The review surfaced eight findings, and the best one was pure connective tissue: one story had built a “preview what will run” feature by inspecting the system’s compiled output, while two other stories added dynamic branching that hides its targets from that same output by design. Each component was correct in isolation. Together, the preview silently stopped at the first branch and reported a fragment of the plan as if it were the whole thing. No error, no warning. The interaction simply wasn’t in any ticket. The review only caught it by assuming the feature was broken and hunting for proof.

Later that evening — Iteration two

So I did it again. I turned the findings into a new spec, grilled it, rebuilt the dependencies, and queued the second iteration. It added roughly a third more code to a feature that had already looked “done.” Much of that additional work wasn’t implementation code at all. It was tests pinning down the corrected behavior so it couldn’t regress. Once again, nearly all of it completed without me.

Overnight — The stall

Nearly. One finding was a semantics call, labeled ready-for-human, and the system did exactly what it was supposed to do: it stopped and waited. For eight hours nothing moved. Not because the work was hard, but because I was asleep.

One repo’s history, and the whole thesis is right there:

Tokens and elapsed time were never the constraint. The only thing the work ever waited on was attention.

I’m moving faster than I ever have solo. I’m shipping progress on multiple projects in parallel, on attention I used to spend babysitting a single one.

Tuning supervision

Supervision isn’t one-size-fits-all, and it isn’t set-and-forget either. It is a runtime control: high for foundational design decisions, low for well-specified implementation work, and high again when evaluating the integrated result. We’re just starting to figure out how to tune it, and I think it’s one of the most interesting knobs in engineering right now.

The agents will keep getting more capable whether I watch or not. What I’m still learning is where my attention actually changes the outcome, and how to walk away everywhere it doesn’t.