The job AI didn't shrink

AI has collapsed the cost of building software. It has done almost nothing to reduce how many people you need on the business side to decide what gets built. Most headcount plans I've seen for 2026 assume both numbers came down together. They didn't, and that assumption is going to cost somebody a very bad Q4.

A large client needed to replace a large legacy internal portal. Their IT lead had scoped it the way you'd have scoped it in 2021: four or five engineers, plus support staff, plus a project manager to keep it moving. That's the estimate I'd have given four years ago too.

Two people built it in 4 months. Not over three years. Two people, running several other projects for the same client at the same time.

The IT lead wasn't skeptical about the quality. He'd seen it work. What he couldn't shake was a kind of vertigo about his own planning: if this took two, what did that mean for the twelve other things in his backlog with staffing estimates attached?

The build estimate was never the one to worry about. It was the estimate he'd never written down.

Any internal software project has two costs people habitually merge into one line item.

Build cost is what it takes to turn a requirement into working software: writing the code, wiring the integrations, handling the situations nobody planned for, deploying it, fixing what breaks. This cost has fallen off a cliff. On one client platform we shipped a hundred updates in a single week. Not a hundred tickets closed. A hundred live updates to the system people actually use, in five business days.

Ownership cost is what it takes for someone on the business side to know what should exist, decide what it should do, answer the fifty questions that surface during the build, notice when the built thing is wrong, and keep steering it for the next three years. This cost has not moved. It cannot be prompted. It requires someone who understands the business well enough to have opinions, and holds enough authority that the opinions stick.

For twenty years, build cost dominated so completely that ownership cost was invisible, hidden inside the project manager's job, inside someone nominally in charge for a day a week, or inside whichever director happened to care. The engineers were the bottleneck, and the owner just had to keep up with them.

Flip the ratio and the hidden cost becomes the whole problem.

The same distinction applies if you buy the software, hire a vendor to build it, or configure an AI tool yourself. AI can shrink the setup work in all three cases. None of it touches who decides what the thing should do. That owner still comes from your side of the table, whether or not you've ever hired an engineer.

The build went fine. What slowed us down, repeatedly, was waiting on decisions.

Not big architectural calls. Small ones. Should this field be required. Does this workflow apply to the pilot group or everyone else. When a request gets rejected, who sees it. Nobody had written these rules down; the legacy portal encoded them by accident twenty years ago, and everyone had adapted around whatever it did.

Two engineers generate more of those questions in a week than one part-time business owner can answer in a month. That's the actual bottleneck now, and it's not a technology problem. Nobody planned for it, because the original build would have surfaced those questions over months instead of days.

I told a different client team something that would have sounded absurd two years ago: we can build features faster than you can test them. Their instinct was to ration requests so they didn't "tax" the developers. I keep telling them to fire away. The constraint moved. It's sitting on their side of the table now, and they haven't noticed.

I didn't spot this cleanly at the start. On an earlier engagement I scoped the engineering side carefully, priced it honestly, and wrote something vague in the proposal like "client provides a business point of contact." That contact was a director with a full-time job, thrilled about the project, with roughly four hours a week for it.

We shipped. It took longer than it should have, and about a third of the elapsed time was us waiting. The build cost estimate was accurate. The ownership cost estimate was zero, because I hadn't made one.

I now scope the owner role explicitly and put a number of hours next to it. Two clients have pushed back on that line specifically. It reads as overhead. It looks like the thing you cut.

Read the confident takes about AI shrinking headcount and notice what they're describing. Almost all of them are stories about production getting cheaper: one engineer doing the work of five, a contract review that took a week now taking an hour, an engineering team that stopped maintaining its own internal systems and bought something for ten thousand a year instead, relieved rather than diminished by it.

But every one of those is a build-cost story wearing a headcount-planning costume. None of them say how many people you need to define, prioritize, and own the work. The confident takes quietly assume that number falls too. It doesn't. If anything it rises, because you can now attempt fifteen internal projects a year instead of three, and each one needs an owner.

If build capacity goes up 5x and ownership capacity stays flat, you don't get 5x the output. You get roughly the same output, plus queued decisions nobody's answering fast enough, and a growing pile of delivered features nobody's validated. That's the same reason AI seat licenses haven't cut costs for a single client where I've looked closely. Capacity that nobody directs isn't a return. It's just capacity.

Three things I'd change in a headcount plan built on the assumption that AI reduces people.

Stop scoping build teams and start scoping owner coverage. For each internal project on your 2026 list, name the person on the business side who will make decisions, and write down how many hours a week they have. A name plus "as needed" isn't an owner. It's a hope.

Recognize that ownership doesn't end at launch. The build is finite. The roadmap isn't. Somebody has to field requests, decide what's worth doing, and say no, for as long as the tool exists. People forget this entirely when they compare a build to buying off the shelf.

Assume validation is now a staffed job. Whatever we build, the client owns the testing, because they're the domain experts. Testing only the case where everything goes right and calling it done is how you accumulate a hundred shipped updates that nobody trusts.

The IT lead ended up in a better place than he started, but not the one he expected. He didn't get to cut those four or five planned hires from the budget and pocket the savings. He needed to fill two or three different roles instead, for people who understood the operations deeply enough to define what should exist and had the standing to decide. Those roles were harder to fill than the technical ones he'd planned for. Those are the hires that determine whether any of this works.

If you were never going to hire engineers, the lesson aims the same way. Whatever you buy, whatever a vendor builds for you, whatever AI tool you configure this year, it doesn't come with the thinking included. Somebody on your side still has to decide what it should do, catch it when it's wrong, and keep steering it.

Your homework: Take your top three internal software or automation projects for 2026. For each one, write two names: who builds it, and who owns it after it's built. If the second name is blank, matches the first, or belongs to someone whose calendar is already full, you've found the actual constraint on that project. Fix that before you touch the build estimate.

Two things I'd like back from you. First, hit Reply and tell me which part of this matches what you're seeing. Second, if there's someone in your world who should be on this list, forward it to them.

- Robbie