A workflow change used to mean mockups, a handoff, and a place in a build queue. That wait is mostly gone. A small team with an agent can put a working version on the table before the old process would have booked the review.
The wait that replaced it is harder to see, because the work already looks finished. The queue is no longer “when can engineering build this?” It is “should this exist, and how would we know?”
Building got cheap
Bain’s Technology Report 2026 describes the half of this change you can see on an org chart. In their survey of software companies, teams have shrunk to pods of three to five people. Organizations reporting a traditional pyramid fell from 66% to 29%. Product managers build prototypes. Designers write front-end code. Developers expect to spend about a third of their time directing agents within two years. The figures come from Bain’s AI Org Assessment Survey, 2026, with 155 respondents, as reported by Jonathan Frick, Purna Doddapaneni, and Arun Ganti on September 29, 2026.
A second study asked the people who own the product, not the engineering managers. Bulb Studios and Intelligent People surveyed UK product, design, and leadership roles and got 2,251 responses. 62% said they had used AI to build a working application or product feature. A further 9% were experimenting. The authors are explicit that these percentages describe their respondents, not every product manager in the country (The AI Product Builder Study (Bulb Studios), September 2026). I still read the number as a warning. When that many people in product, design, and leadership have already produced a working feature, “engineering is the bottleneck” is an old sentence.
Enterprise products show the same shift, with less of the demo magic. A clinician’s tool, a lab interface, a production-monitoring screen, a controls workflow in finance: the pixels arrive fast. The argument about whether the workflow is the right one does not.
A bottleneck does not disappear
I learned system dynamics before I learned interfaces. The useful idea here is ordinary. In a system of stocks and flows, a bottleneck does not vanish when you speed up one stage. It moves. Eliyahu Goldratt’s theory of constraints says the same thing in factory language: the throughput of the line is the throughput of the slowest stage. Speed up a stage that is not the constraint and you do not get a faster line. You get a pile of inventory in front of the stage that still cannot keep up.
Software teams are doing that, and calling it velocity. Building was the constraint. We threw agents, smaller pods, and fewer handoffs at it. Building sped up. Deciding did not. Bain’s sharper point is that most companies redesigned the team and left the decisions where they were. The same article says 70% of companies still make decisions centrally, pointing at Bain’s brief on operating models for an AI-accelerated world. Code ships faster. The approvals and escalations around it have not moved. Bain’s warning is that a flatter chart just relocates the old bottlenecks if accountability does not follow the structure.
The inventory changes shape. It used to be tickets waiting on engineers. Now it is features waiting on a decision nobody put on the calendar. Unvalidated flows. AI features that demo well and die in the real job. Prototypes that were cheap to make and are now awkward to delete, because someone already showed them to a stakeholder.
On a monitoring product, a generated dashboard can arrive quickly and then sit while operations, safety, and the data owner argue about what a red state means. The screen was not the scarce resource. Agreement was. In a clinical product the same pattern is a tidy task list that does not match how a nurse hands work to the next shift. In a lab tool it is a flow that ignores gloves, glare, and the fact that a wrong step is a safety problem, not a visual one. In finance it is a screen that looks done and still cannot survive an audit trail. The build was the easy part. The constraint was the decision about the work.
If you only watch the stage you just sped up, the pile in front of the next stage looks like productivity. It is inventory.
What to do when the constraint is a decision
You do not clear a decision bottleneck by generating more options. You raise the throughput of decisions: fewer choices, made faster, by people who will live with the outcome. Four practices are enough, especially where a wrong workflow costs more than a wrong color.
Frame the problem before you generate
The expensive mistake is a wrong model of the work. The wrong object. The wrong state. The wrong handoff between two roles. I would rather spend a day on the job and the data than a day prompting variants of a screen that assumes the wrong job. Agents are excellent at the second day. They are obedient on the first, which means they will build the misunderstanding as happily as the right thing.
Match discovery to the build speed
A quarterly research plan made sense when a release took a quarter. It is theater when a pod can ship a slice in a few days. The cadence I trust is short and repetitive. One real workflow. A few users, operators, or clinicians. A decision at the end of the week: continue, change, or stop. That decision is the valve. If the week ends with more screens and no decision, the stock grew.
Kill work on purpose
This is the unfashionable half of speed. If a feature has no owner for the outcome, or no path to a person who can show that the job got easier, it should leave the backlog. Cheap to build is not a reason to keep. The features that linger are the ones everyone is too polite to delete after the demo. Politeness is how inventory becomes a product.
Measure the job, not the screen
“We shipped the AI feature” is an output. “The operator finishes the job with fewer wrong states” is an outcome. “The clinician finds the next task without a workaround” is an outcome. If you cannot name the outcome before you generate the interface, you are adding to the pile. A review can celebrate a generated flow while nobody can say which number in the business would move if users loved it. That meeting is the bottleneck, wearing a sprint costume.
Designers do not get a pass. When building is cheap, the senior part of the job moves with the bottleneck. Less time painting screens. More time on the problem frame, the structure of the information, and the moment someone has to say no. I still care about the interface. I care about it after we know which interface is worth having.
The half you can still waste
Bain calls the current state a half-finished redesign. The visible part is done: smaller teams, blurred roles, agents in the build. The part they say most companies skipped is who decides, and who owns the result. Bulb’s study shows a cousin of the same gap. People can build. Far fewer trust that build in production: 15% of their respondents felt confident deploying AI-generated software, and 27% had already shipped some without an engineering review. Capability arrived first. The decision rights did not.
If you run a product team in 2026, treat build speed as a local problem you may already have solved, and go count the stock in front of your decisions. Features that exist and have not met a user. Features nobody can kill. AI features that are “in the product” and unused in the workflow. That count is your constraint. Everything you do to make building even faster, before that count comes down, is how the pile grows.
Sources
- The Half-Finished Redesign: How AI Reshapes Software Organizations (Bain & Company), September 2026
- The AI Product Builder Study (Bulb Studios), September 2026