If you spend hours every day reading LinkedIn posts and Substacks about software engineering like I do you’ll notice everybody has decided that coding is no longer the bottleneck. I’ve read some version of that sentence a dozen times this month. What I haven’t seen is much agreement about what replaced it.

What folks are saying:

Problem-finding. Jensen Huang: “The purpose of a software engineer is to solve known problems and to find new problems to solve. Coding is one of the tasks.” He said nothing would give him more joy than if none of his engineers were coding at all.

Specification. Sean Grove of OpenAI, in “The New Code”: specs become the primary engineering artifact, and the new scarce skill is writing one that fully captures your intent.

Verification. Martin Fowler’s Thoughtworks in the April 2026 Technology Radar: code arrives faster than a team’s shared understanding of it. Most test suites, they point out, were built to validate code written at human speed.

Judgment. Pratima Arora, CPTO at Smartsheet, on how coding agents are giving everyone decision fatigue: “We had a software engineer producing 7X the code than anybody on her team…the other six people on the team were spending the majority of the time reviewing her code.”

Context. Sourcegraph studied 1,281 agent runs across more than 40 enterprise-scale repositories and found that past roughly 400,000 lines of code the ordinary local tools an agent reaches for stop working, and that agents finish the visible part of a task while missing the part living outside their context window.

Product management. Andrew Ng: “Engineers are 10x faster. Product managers haven’t sped up at the same rate. Now they’re the bottleneck.” His sharper point is about feedback latency. When a prototype took three weeks, waiting another week on users was fine. When it takes a day, that week hurts.

Everybody is right

My take is that everybody is right. The people and teams above list different bottlenecks because every code base, every company, every organization is different. They’re each describing the constraint in the system (or systems) they can see, which is fine, except that a system bottleneck isn’t a universal truth. A bottleneck is a specific property about one system, and there’s a whole body of work on how to find one. Goldratt laid it out in “The Goal” in 1984: every system has exactly one constraint that governs its throughput, and improving anything other than that constraint doesn’t make the system faster. You find the constraint, you get everything out of its way, and then you go find the next one, because relieving one always promotes another.

That’s the key engineering learning that these pieces dance around but miss. AI coding tools made one step in the pipeline dramatically faster. Assuming that step was your constraint you now have a new one and it’s different for different systems. Leonardo Stern at Agoda makes this point by way of Brooks: speeding up one part of the lifecycle produces diminishing returns for the whole. He cites research from Faros AI covering more than 10,000 developers across 1,255 teams. Teams with heavy AI adoption completed 21% more tasks and merged 98% more pull requests. Their pull request review time went up 91%. That’s a constraint moving to the next station, and somebody actually measured it.

Once again, I can’t just read an article and thoughtlessly apply it as a solution to my own situation. I have to do some work to understand my organization.

Has AI accelerated us?

Oh yes.

Sure, software productivity metrics are all flawed. Pull request counts reward small pull requests. Story points are invented. Lines of code reward bloat. None of those things guarantee the code you shipped has business value, but it’s what we have.

Right now my team at CloudZero is merging about three times as many pull requests as we were at the start of the year, and closing something closer to seven times as many epics. The epic number flatters us, because our epics have gotten more granular over that same period. Even discounting that, the acceleration is real and it’s not subtle. Individual devs are absolutely delivering more than they were.

Acceleration confirmed. Where is my new constraint? Has it even moved?

Finding my constraint

I backed into my current thinking on where CloudZero’s SDLC is constrained. I was trying to figure out how to make our organization more AI-Native and stumbled upon the RPI framework (research, plan, implement).

The idea is that a human stays “in the loop” for research and making a plan. You work with the model interactively to research the problem and produce a stout plan. Then, given good tools, the right context, and that plan, the agent should be able to implement autonomously with the human “on” the loop instead of “in” it. In the loop means working interactively with the agent. On the loop means you’re watching, and the agent iterates without you.

So I surveyed my engineers on how they’re working.

The results were lopsided. For over 90% of new work engineers research and plan with an agent. So that’s two thirds of RPI. But only about 15% of stories got implemented with the human on the loop. For the rest, engineers couldn’t, or didn’t want to, hand off the implementation.

Luckily the survey allowed for comments so I had some color on why the agent couldn’t implement on its own. When people wanted to hand off implementation to the agent and couldn’t it usually came down to some version of not trusting the output enough to walk away. It wasn’t that people hadn’t tried RPI. Even without ever having heard of the framework our engineers instinctively tried it and failed at autonomous implementation.

So why can’t an agent reliably execute a plan and achieve the intent of our developers? One clue lies in who IS successfully handing off implementation. Our front end team can hand off implementation to an agent because they can run the UI locally and poke at it. Everyone else has to deploy a version of the service they’re changing to our staging environment and test it there with real data and the other services in order to get feedback. Agents aren’t deploying services and poking at all, so they fall back on whatever feedback can be reached from local development: unit tests, static inspection, reading its own code and deciding it looks right.

You could try to make up for not having this feedback. Developers can write a plan so detailed that it pre-decides everything the agent would otherwise settle by experiment, or we can build and make available a ridiculous amount of context. Both are substitutes for a much simpler thing: let it run the code in a realistic way and poke it with a stick. That’s how engineers actually work, and we haven’t scaled verification to meet the demands of AI aided development. There are worse things than aligning to Martin Fowler.

My organization’s answer

So my answer isn’t judgment or specs or product management. For my organization, in August of 2026, the constraint is verification, and I think the best way to relieve it is to enable closed loop testing for our agents and back end developers. A safe sandbox to code, test, and iterate toward success is the next unlock, and until we have it, improving other parts of the system might not yield more output from our software development process.

It’s an unglamorous answer, a development environment problem that’s been sitting near the bottom of engineering backlogs since long before DALL-E started drawing eight-fingered people. Which is roughly what Goldratt would predict. The constraint is wherever it is, not wherever the interesting conversation is. Once we fix the current constraint it will no doubt shift elsewhere.