The paper that started all of this is called “Attention Is All You Need.” That’s the 2017 Google paper that gave us the transformer, which gave us GPT, which gave us Claude Code, which gave us the glorious mess I’m about to confess to.
And the joke that keeps rattling around in my head is this: the thing that makes the models work is attention. And the thing I’m fresh out of is attention. Mine. The human kind.
The confession
Here’s where my head is at. For a stretch there I had six, sometimes eight agents going at once. Different projects, spread across virtual desktops like a cockpit. One desktop grinding on a Go refactor. One writing tests. One spiking a feature I’d been putting off for a month. One answering a question about a codebase I hadn’t opened in a year.
It felt amazing. It felt like I’d finally cracked it. Look at me go.
And then I’d flip to desktop 3 and the agent had been sitting there for four hours waiting on me to answer a question. So I’d read half the question, say “yeah do that,” and flip to desktop 5. Which was also waiting. Repeat for an hour. I ended those sessions more tired than a day of actual coding, and I couldn’t tell you with a straight face what any of the eight agents had actually done.
That’s the tell. I wasn’t in flow. I was a human message broker between eight processes, and I was dropping packets.
What I stopped doing first
Here’s the part that bothers me. When you overload yourself, you don’t stop reading everything at once. You keep your eyes moving over the words. What you quietly stop doing is understanding them. Reading and understanding are two different verbs, and under load I was doing the first and skipping the second — across the board.
And here’s the uncomfortable bit: the thing I skimmed hardest was the stuff I’d told myself was safe.
I’ve said before that tests are the real spec, and I still believe it. But watch what that belief turns into when you’re tired: “tests are the spec” quietly becomes “I glanced at the green checkmark.” Those are not the same thing. A passing suite I didn’t actually read is not verification — it’s a little green light I decided to trust. The gap between the tests passed and I understand what the tests prove is exactly where an agent gets away with murder.
So let me talk about the two places skimming bites you: the prose, and the design-and-tests.
Read the prose for what it isn’t saying
The prose is the plan the agent writes before it starts, the “here’s what I changed and why” at the end, the PR description, the commit message, the paragraph where it lays out its reasoning. It’s the one place the agent tells you what it thinks it’s doing, as opposed to what it actually did.
Skimming it gets you the words. Understanding it gets you two things, and the second one is the one that matters:
- What it’s actually claiming — the explicit story.
- What it’s conspicuously not saying — the hole in the story.
That second one is the whole game, and it’s invisible to a skim. An agent that “cleaned up the function” and cheerfully lists six things it tidied, but never once mentions the retry semantics it quietly rewrote, is telling you something by omission. The dangerous change is almost never the one it brags about. It’s the one that didn’t make the summary. You only catch that if you’re reading for the gap — asking “what would I expect to see here that isn’t here?” — instead of nodding along to the parts that are present and well-written.
And AI prose is very well-written. That’s the trap. It reads confident and complete, so your brain files it as confident and complete and moves on. The absence doesn’t announce itself. You have to go looking.
Code got cheap. Attention didn’t.
I’m not the only one circling this. There’s a line from a talk at the AI Engineer conference that’s been quoted a bunch and it nails it: “code got cheap, attention didn’t.” That’s the whole ballgame right there. We 10x’d the production of code and the production of plausible-sounding English about code, and we did exactly nothing to increase the number of hours a human can actually pay attention in a day.
Simon Willison — who is about as far from an AI naysayer as you can get, the guy coined “vibe coding” — keeps hammering the same nail: you are responsible for the code you ship, full stop. The model can’t be held accountable for a defect. You can. He warns specifically about normalization of deviance — the way repeated success makes you trust the thing a little more each time until you’re deploying stuff nobody read. That’s not a model problem. That’s an attention problem wearing a model costume.
And there’s a nasty wrinkle specific to the prose. Sinclair Target wrote a sharp piece on the negative externalities of gen-AI on software teams and one of his points stuck with me: AI-written PR descriptions are long. Dense, thorough, redundant, no hierarchy, everything weighted the same. It reads like it respects your time and it absolutely does not. A human writing that same description would’ve put the one scary sentence in bold. The agent buries it in paragraph six next to a note about renaming a variable.
So the prose is simultaneously the most important thing to understand and the most exhausting thing to understand. BOTH are true. Of course it’s the first thing to go.
A green checkmark is not understanding
Now the harder one, the one I had to be honest with myself about: the design and the tests.
“Tests are the real spec” is doing a lot of load-bearing work in how I justify not reading every diff, so let me say where it breaks. Tests are the spec only if you understand what they assert. A dozen passing tests that all walk the happy path and never touch the edge case you actually care about is a green checkmark lying to your face — and an agent optimizing to turn the bar green will write exactly that suite if you let it. That’s not malice. It’s just gradient descent toward “tests pass.” Point a system at a metric and it will satisfy the letter of the metric, every time.
Which means the tests now need the same real attention the code used to get. Not “did they pass” — what do they actually pin down, and what did they leave wide open? And you can’t answer that by reading the tests in isolation. You have to hold the design in your head: what is this thing supposed to do, what are the invariants that must never break, where are the sharp edges. Skim the tests and you’re trusting the agent’s idea of “correct.” Understand them against the design and you’re checking the agent’s idea of correct against yours. That difference is the entire value I add now.
Think about that for a minute. The agent can write the tests in thirty seconds. Deciding whether they’re the right tests — whether they encode the design you actually meant — is design work, and design work runs at human speed. It does not get faster because the typing got faster.
This is also the honest patch to my own “let the AI write code without line-by-line review” position. The review I’m skipping is the line-by-line review. The review I am absolutely not allowed to skip is understanding the design and reading the tests closely enough to know they guard it. Skip that, and “tests are the spec” is just a comforting thing I say while shipping code nobody understood.
The WIP limit was never about the machines
Here’s where I think a lot of us (me included) made a category error.
We looked at the agents and thought: these things are cheap, they run in parallel, there’s no reason to limit how many I spin up. And that’s true — for the agents. The constraint was never the agents. The constraint is the single human in the middle whose job is to actually understand what came back.
This is old, old wisdom and we keep re-learning it. Jerry Weinberg, in Quality Software Management back in 1992, put a number on context switching: split your attention across two projects and you lose roughly 20% of your time to the switching itself. Add a third and you’re bleeding something like 40%. The lines on that chart are brutal, and — this is the important bit — they don’t care that your workers are robots. The switching tax is levied on you, the one doing the switching. Eight agents means you are basically not paying attention to any of them.
Kanban people have been shouting about WIP limits for twenty years for exactly this reason. Limiting work-in-progress isn’t about the capacity of the workers. It’s about the capacity of the system to finish things well. And a pile of half-attended-to agent output isn’t finished. It’s inventory. Expensive, unread, possibly-wrong inventory.
I wrote a while back about managing cognitive load in DevOps. Turns out I was describing my own future problem and didn’t know it yet. Geesh.
The nuclear navy had a rule for this
I keep coming back to the submarine. (You knew I would. But I digress — no, actually, I don’t, this one fits.)
In Rickover’s nuclear navy you did not operate the plant faster than you could watch it. Ever. The whole culture was built on the idea that the limiting factor is the watchstander’s ability to understand the state of the system in real time — not the equipment’s ability to go faster. You want to know why the program never had a reactor accident? Partly because nobody was allowed to run ahead of their own attention. You verify. You repeat back. You escalate the weird thing instead of skimming past it.
That’s the discipline I lost somewhere around desktop 3.
The fix isn’t to go back to typing everything by hand like a caveman — don’t get me wrong, I’m not doing that, the agents are a genuine sea change and I’ve said so loudly. The fix is to match the throttle to what I can actually watch. Which, it turns out, is a lot fewer than eight.
So, slow down?
Kind of. And I hate that, because “slow down” is the kind of advice that sounds like a mug on a manager’s desk.
The agents are capable of a breakneck pace. That’s real. But “capable of” is not “optimal for the human in the loop,” and quality lives in the loop. So here’s what I actually changed:
- Two agents, maybe three. That’s it. Past three I’m not supervising, I’m pretending to.
- Understand the prose, don’t skim it — especially for what it leaves out. The plan before it runs, the summary after. Read for the hole in the story, not just the parts that are there.
- Read the tests like they’re the spec, because they are. Green isn’t the question. The question is what they actually pin down and what they left wide open — and you can only answer that if you’re holding the design in your head.
- When the summary is a wall of text, that’s a smell, not a courtesy. I need to make the agent tell me the one thing I need to worry about. If it can’t, I don’t trust the change yet.
- Queue work instead of parallelizing it. A tight prioritized list beats eight simultaneous things, every time. Finish, understand, next.
Am I shipping fewer agent-hours per day? Yep. Am I shipping more done done work that I actually understand and would put my name on? Also yep. Both can be true, and the second one is the only one that matters.
The design review doesn’t disappear. It moves.
Here’s where this stops being a me-problem and becomes an org problem, and it’s the part I most want other engineering leaders to sit with.
When a human engineer writes a design doc, what do we do with it? We don’t rubber-stamp it. We gather. We get three or four people in a room — or a thread — and we critique it. We poke the assumptions, name the failure modes, argue about the tradeoffs. That ritual is one of the highest-leverage things a good engineering org does, because the entire point is to find the expensive mistake while it’s still cheap — while it’s still words, before it’s ten thousand lines of code and a database migration.
Yes, writing code is cheap. It’s easy think that “if the design is wrong, we can just have the agent rewrite it.” But *HOW will you know the design is wrong after it’s written? When all the tests pass because they came from the design? Probably next quarter when you need to add something and it blows up in your face.
We need to optimize for CYCLE TIME - not CODING TIME. There’s a difference, and a bad design will end up costing you more in the long run.
Which leads me to the thing I actually want to propose.
We all have this gate now: two reviews and approvals of code before you can merge to main. We hang it on the pull request. On the code. And I’m starting to think that’s the wrong place for it — or at least no longer the only place for it. By the time it’s a PR, the expensive decision is already made; the design is baked in. Two humans scanning a green, agent-written diff at 4pm is theater compared to two humans actually arguing about the design before a line got written.
So maybe that’s where the two-reviewer gate needs to move: onto the design. Make the expensive artifact — the one that decides whether the next ten thousand lines are even pointed in the right direction — the thing that requires two humans who understood it and signed their names to it. Keep a gate on the code too, sure. But stop pretending the PR is where the real review happens. For agent-authored work, the real review is at the design, and right now that gate mostly doesn’t exist (at least in shop I hear about).
Conclusion
The models are named after attention because attention is the magic. The irony is that they’ve made our attention the scarce resource, and then handed us a slot machine that pays out in dopamine every time we spin up one more parallel agent. Six projects grinding away across six desktops feels like leverage. A lot of the time it’s just a very expensive way to not-read six things at once.
Code is cheap now. Understanding isn’t, and it never will be, because understanding is the one thing you can’t delegate to the thing you’re trying to check. Spend your attention where it counts: on the prose — what it says and, louder, what it doesn’t — and on the design and the tests, read closely enough that you actually know what they guarantee instead of trusting a green light you glanced at on your way to the next desktop.
And if you run a team, spend the org’s attention upstream. The cheapest place to catch a bad idea is in the design doc, with two humans who read it and argued about it — not in a green diff at 4pm. Move the gate to where the thinking happens.
I could be wrong about where the line sits — maybe the right number is four agents, maybe tooling gets good enough to watch them for us and this whole post ages like milk. (Today’s models are the worst we’ll ever use, after all.) But I don’t think the core thing ages: you can’t own what you didn’t understand, and you can’t understand eight things at once.
If you’re running a trenchcoat full of agents and quietly suspect you’ve stopped understanding what they hand back — or if you think I’ve got this exactly wrong and parallel-everything is the future — drop me a note on LinkedIn and tell me. I’ll read it. Slowly, and all the way through.