The Whole Pool: Who Actually Builds Software Now

Part 3 of 3 · The Time and Tokens series

This is the last of three. Part 1, “Time and Tokens” argued that building software collapsed to two elastic inputs; Part 2, “Value, Not Hours” asked what you charge for work that suddenly takes two weeks. This part asks who is in the driving seat.

“That’s not your swim lane.”

A project manager said it to me across a table, and the maddening part is that she was right; it wasn’t my lane. I was the technical consultant and the schedule was hers - there was just one problem. Her schedule said the project was on track, the project was not on track, and I could see the daylight between those two facts as plainly as I can see this page (I mean months of gap, not just days). I had tried to walk her through it (gently, I thought) and she told me, not unreasonably, to stay in my lane.

“I could see the whole board and I was not allowed to touch most of it.”

I have never forgotten the phrase, because it is the exact shape of the thing that made me a bad employee for my entire working life.

I should tell you who I think I am before we go further. I am a project manager at heart, but also a product person with a solid architectural understanding of the systems I work on, and I do not write code (I wrote Pascal at university, and I may have ‘borrowed’ someone’s code from the year above me to pass that unit!). For most of my career that combination meant one thing - I could see the whole board and I was not allowed to touch most of it. Nobody was unkind about it, the tooling simply demanded a skill I did not have, so the seeing was mine and the building was always somebody else’s. Which is most of why I spent most of my career as a business owner - I owned the board and I could touch it as often as I liked, except for the part that needed code.

The sentence I let slide

In Part 1 I wrote “a capable person who understands the business can direct AI tools to assemble working software in a fraction of the time” and moved on. It reads like a throwaway. It is actually the load-bearing claim of the entire series, and I never once said who that person is.

It is also, increasingly, a description of something that has already happened. In the 2026 AI Engineering Survey run by Notion, Amplify Partners and Vercel, 17% of respondents said non-developers at their company regularly ship full-size, customer-facing features. Not internal scripts; features. (1,053 responses, from three companies with an obvious commercial interest in the answer, so apply pink Himalayan salt generously.)

There are two obvious candidates, and most arguments on this pick one and defend it to the death. The first is the project and product person with real architectural understanding who cannot code (that is me, so keep that salt handy). The second is the senior engineer who has grown a genuine product mindset. Ask which of the two builds better now and you will get a confident answer from whichever camp you happened to ask.

Both camps are answering the wrong question

I think the framing is wrong, and I think that matters more than whichever side you would have picked. The axis isn’t product against engineering. It is whether you can tell when the machine is lying to you or, worse, enthusiastically agreeing with you.

Watch how each side fails, because the failures are mirror images.

The product person specifies beautifully and cannot verify. That sounds survivable until you remember what these tools are actually good at, which is producing something that looks solid and plausible. Developers report the same thing from the other side of the fence. In Stack Overflow’s 2025 developer survey the single most common frustration, at 66%, was AI solutions that are “almost right, but not quite”; 45% said debugging AI-generated code is more time-consuming than it should be. The thing demos perfectly. You cannot tell whether you are holding a working system or a convincing one; you find out under load, at two in the morning, or your customer finds out first, which is the worst possible time to learn that you never had a way of knowing the difference. I have a live example of my own and I will come to it, because it is also where my ceiling turned out to be.

The engineer has the opposite problem. They can check anything, and the instinct that lets them check is the same instinct that makes them want to rewrite. Hand them generated code and they read it, dislike it and redo it by hand; give them a clear spec and they build the interesting thing instead of the needed one. Either way the speed that was the entire point goes out of the window.

And do not assume the engineer is safe on the first count either, because the most unsettling evidence I have read points the other way. METR ran a randomized controlled trial with sixteen experienced open-source developers on 246 real issues, in repositories they had worked in for years. With AI tools allowed they took 19% longer. Afterwards they estimated that AI had made them 20% faster. These were experts, on their own code, wrong about their own speed by nearly forty points; whatever the ability to check your work is, it is not handed to you with the job title.

Neither failure is about talent, and I want to be fair here because it would be easy to tell this as a story where my side wins (and I am really quite competitive - ask my wife). Both failures are about what your instincts do when the output looks fine. The product person’s instinct is to accept it. The engineer’s instinct is to rebuild it. The person you actually want is the one whose instinct is to go and check.

Addy Osmani called this the 70% problem back in 2024 - the tools get you most of the way fast, and the last stretch, the part that separates a demo from something you can run in production, is where the knowledge sits. His line for it is that the more you know, the better you can guide the thing, and without that knowledge you end up “playing whack-a-mole with code you don’t fully understand”. Matt Wood, whom I leaned on in Part 1, makes the same point from the economics side in “The Cost of the Answer” - generation got cheap, and the judgment about whether the answer is any good is the part that compounds. Judgment and knowledge.

The strongest objection to all of this is the one I asked you to hold onto in Part 1 - Simon Willison’s rule that, for anything real, he will not commit code he could not explain. He is no sceptic about building with these tools, which is what makes the rule bite. Read literally, it says people like me should not be shipping anything, and I am wholly opposed to that.

Here is where I have landed, and weigh it knowing whose interest it serves. “Explain the code” is one implementation of knowing whether a thing is right; it is not the only one, and it is aimed at the developer camp. The other implementation is knowing the domain well enough that wrong output looks wrong to you - the reconciliation that balances when you know it cannot, the number that is plausible and impossible at the same time. That reflex, that muscle, is real, and I have watched it catch things a line-by-line review would have gone straight past.

The part that costs me something

A person who cannot code, arguing that people like me can and should be building things, owes you an explanation.

For most of my life, friction was the thing quietly holding me together. A scattered brain like mine does not lack for ideas; it produces them the way lightning strikes, urgently and randomly and with no particular regard for whether the thing it has just landed on should be set alight. The reason I did not act on all of them was never discipline, whether I think it was or not. It was cost. Every idea had to fight for a slot in a head already busy being a stressed business owner, a dad, a husband and a wanna-be author, and silently musing on whether I should have joined the SAS and how different my life would have been if I had. Most of those strikes came to nothing, because starting was expensive and there are only so many expensive things one person can begin.

ADHD isn’t a label I have been given, it’s one I am pretty sure I need; in the UK when I was a kid, those letters simply didn’t belong together. So without self-diagnosing, let’s call me scatter-brained, or unable to focus for more than a minute, and I do believe that as a PM and a business owner, it is the one place the way my brain works is an advantage instead of a defect, my own superpower. Thinking about 13 different work streams in a single hour meant I could spin and balance 13 plates at once. It was fun, and daunting and scary, all at the same time. One of those plates was payroll, and a team and their families depended on me not dropping it, which took its toll. I also knew that if I didn’t keep the marketing plate and the sales plate and the product plate spinning, the payroll plate dropped anyway.

I should be careful with this, because the research does not support the tidy version of this story. A 28-year study of 4,128 Americans, published in Applied Psychology, found no general ADHD advantage in entrepreneurship at all. The effect concentrated in one narrow group (highly intelligent men) and ran the other way for women with ADHD, who had the lowest rates of business ownership regardless of cognitive ability. I would sit inside the group it favors, which is a fact about my luck rather than my wiring. So take what follows as one man’s account of his own head, not a hypothesis with strong evidence behind it.

With Claude Code in my hands, I went from busy to overloaded. Right now, heavily assisted by AI, I am running three product builds and their QA, plus the go-to-market work to get them launched. A fourth product is at the requirements stage; I run two companies, one of them a non-profit, and I have no non-profit experience; and I am editing the final draft of a Young Adult fantasy novel, the first of five, that I am hoping will be on shelves this year. I am also trying to give more of myself to my family and my health.

On paper that reads like a humblebrag. It isn’t a boast; for a brain like mine it is a confession. It is invigorating and exhausting in roughly equal measure. A year ago, with little or no AI in the mix, that list had me stressed to the point of almost dying (I drove myself to the ER thinking I was having a heart attack - I lived somewhere remote, and driving was a much better option than waiting for an ambulance). The real danger now is that I end up invigorated but dead. Still the same end result.

Part 1 celebrated the collapse of the cost of starting and it was right to. It also missed that for a brain like mine, that cost was doing a job I never knew was being done.

And the AI tool does not help you hold the line, because the tool has no line. AI is tireless and endlessly willing (Max plan limits aside); it is, in its way, the perfect employee, and it will never once tell you that you have too much on. Ask it to help you start a sixth thing while five sit half-finished and it does not so much as raise an eyebrow. It never says look at the state of your plate. It says great idea, here’s a plan.

The sharpest cost isn’t the unfinished list, though, it is the question I wake up to. Half a dozen live things, one of me, and the first problem of the day is which one gets me; that question, every single morning, is exhausting before I have done a minute of real work. Here is the part I am least proud of. Too often I pick the thing that is easiest, not the thing that matters most; I do A instead of B, knowing full well B is the higher priority, purely because A is the one I can start without friction. AI stripped the friction out of starting things. It did nothing for the friction of choosing well, and if anything it made choosing harder, because now there is always something easier I am allowed to do instead. Wood’s point again, it turns out - the judgment is the part that compounds, and that includes the judgment about what to work on.

So the honest correction to Part 1 is that removing the constraint was not a free win. It was a win with a cost attached, and that’s paid by whoever was leaning on the constraint without knowing it. It’s the high-agency people who pay most, the ones who never waited for permission to start; the tool multiplies agency, and for a brain like mine agency was never the thing in short supply. Check, now and then, whether what you are producing is high value or just high output.

Where the ceiling actually is

None of that nullifies the argument. The gate is genuinely gone; I can now spec, direct and ship a system I could never have written a line of, and it works, and it is used. What I have learned is that the ceiling did not disappear along with the gate. It moved, and it is worth knowing exactly where it sits before you find it by accident.

Here is where I found mine. Each of the three products I mentioned has its own Claude Code session. One of those sessions built something I really liked, an automated documentation and release-notes repository with guardrails so that internal documents could never leak to customers, a good-sized epic with several features in it. Claude designed it with my input (he, not it, and yes I mean that; I say please and thank you and good work to Claude often - if he is going to take over the world, I at least want him to know I was kind). I liked it enough that I asked him to templatize it so the other two apps could reuse it. I expected the design and build to have been nailed, and when he asked the other sessions to review it I was expecting them to congratulate him on a job well done.

Instead there was a lot of pushback. This won’t work here; there is a serious gap there. The to and fro was honestly great and it honed a better product, but that is not the point. The point is that I could not have found one of those gaps on my own, nor could one instance of Claude. I had looked at the thing and liked it, and liking it was the whole of my verification, based on an assumption that Claude would do the rest.

Here is exactly where the line sits for me. I can tell you when a product should sit on DynamoDB and when it needs Aurora, and I know row-level security is the right way to keep one customer’s data away from another’s. What I cannot do is look at what Claude built and tell you whether that row-level security is actually enforced everywhere it needs to be. I know what good and bad architecture look like; I do not know what good implementation looks like, and the gap between those two is the whole of my ceiling. That time it cost me a to and fro, because a review was in the loop. The version that worries me is the one where nobody thinks to ask. That’s Willison’s point.

That is the honest shape of it. I go much further than I ever could, and I stop somewhere specific, and knowing where I stop is the difference between building something real and building something that demos. That line is always changing too, just to make things more complicated!

The gate moved

The old way in to building software was writing code. It still works, it is just no longer the only way in, and the interesting mistake now is to think it is that black and white. Producing code and building software were never the same skill; the first one got cheap, and the second one is exactly the judgment Part 1 said never did.

Which is why I would not hire for the job title, from either side. I would hire for the instinct to check. A product person who has learned what “I can’t verify this” feels like, or an engineer who has learned to let the fast thing stay fast, are far closer to each other than either is to the confident version of themselves.

So the swim lane finally opened, for me and I hope for you, and it turns out the pool was the point. Just keep checking which end of it you can’t yet touch the bottom in.

---

Previously in this series: Part 1, “Time and Tokens: When Software Stops Being Something You Buy”; Part 2, “Value, Not Hours: Pricing Services When the Work Takes Two Weeks”.

Further reading: METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”; Stack Overflow, “2025 Developer Survey: AI”; Notion, Amplify Partners and Vercel, “2026 AI Engineering Survey”; Addy Osmani, “The 70% problem: Hard truths about AI-assisted coding”, on why the last stretch is where the knowledge has to come from you; Matt Wood, “The Cost of the Answer”, on why judgment, not cheap generation, is the input that compounds; and Eric W. Dolan’s write-up of the ADHD entrepreneurship study, “The ‘ADHD advantage’ in entrepreneurship applies mostly to intelligent men” (PsyPost).