The Bottleneck Has Moved

This is part 1 of 4 in a series about Product Development teams with AI agents. The other parts are linked at the end.

Code is no longer scarce

The sophisticated teams I meet are not writing code by hand. (That wasn’t true in 2024. It is true in 2026.)

The practices for agent-written code are still highly experimental, but some patterns are starting to emerge. A prompt is written to describe a goal, some opinions about implementation are included, an agent (or multiple) writes the change. Another agent, or a person, reviews it and runs tests. The CI/CD pipeline re-runs the checks. A person decides whether it ships, or the agent is permitted to ship under specific conditions.

None of that is exotic anymore. It is ordinary work.

So here is my claim: Since Alan Turing’s first computer, the constraint that shaped entire product development organizations was the act of writing code. That constraint is gone. But many enterprises are still organized around it.

The common error: treating a team as a coding unit

You’ve seen it. A “team” of programmers. Another “team” of testers. A Product “team” orbiting around them, feeding them requirements. A Business Analyst feeding the Product Owner. Marketing, UX, release management, and strategy were kept at a distance. Everyone’s job was to keep the programmers busy writing code…because that was the slowest part.

Segregating upstream, build, and go-to-market felt like a necessary evil. But that was always a coping mechanism for the fact that software was expensive and slow. That was never optimal. We always knew it: for example, the Kanban strategy encourages skill-fluidity and the performance units described by Scrum are cross-functional teams. Here is what the Scrum guide says:

Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal. Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.

Read that again. All the skills necessary to create value. Let’s make that distinction clear:

Skills to produce code (pre-2026)

Programming, testing, reviewing, and merging changes to a codebase.

Example: - “Story complete, PR merged, tests green.”

Skills to create value

Everything required for a solution to reach real users and make their situation better, and for the team to learn whether it did.

Example: - “A new UI was rolled out to end users, and support calls about it dropped.”

People wrapped Scrum around the coders

The Scrum Guide never confused these. People did. Managers did. Their reason, I suppose, was that code was scarce. Developers were the slowest and most expensive input, so everything was arranged to keep them fully utilized. That seemed rational to many. (I never liked it, but I understood it.)

The theory of constraints: a metaphor

Picture a restaurant with one small oven. Every dish goes through it. The oven is slow. So the whole restaurant organizes around the oven. The menu is planned weeks ahead so the oven never sits idle. Prep cooks chop everything in advance. Servers take orders early and never leave the queue empty. The head chef’s greatest concern is the efficiency of the oven. The oven is the constraint, and everyone protects it.

Then someone installs ten ovens. Overnight.

The throughput of dishes is faster than the servers can carry them to the tables. The prep cooks cannot go fast enough. The restaurant has a limited number of tables and the diners can only eat so fast.

The head chef used to be concerned about the oven. But the new problems are:

• knowing what tonight’s diners want
• sourcing the ingredients just-in-time
• getting the plate to the table
• and finding out whether they liked it…and whether they’ll be repeat customers.

How the coding constraint manifested at work

The columns on a typical board

To Do, In Progress, Code Review, QA, Done.

Every column describes the oven.

Nothing describes the ingredient supply chain or the dining room.

The Definition of Done

“Code reviewed. Unit tests pass. Merged to main.”

Everything describes the quality of the dish as it comes out of the oven.

The chefs hardly notice if the diners actually enjoy the food. They hear only of defects: “there’s a bug in my soup!”

The metric

Velocity 🤮, or story points per Sprint 🤮🤮

Everything describes how many dishes come out of the oven.

Nothing about satisfaction of the diners or the rate of repeat customers.

The working agreements

“Pull requests reviewed within 24 hours.” “No more than two stories in progress per developer.”

All of them protect the oven.

The Sprint Review

A demo of merged stories.

The chef reports how many meals were cooked in the oven.

Nothing about how the meals were received by diners, and nothing about optimizing the menu based on their feedback.

Now add agents

Code just happens like it’s been willed into existence. Pull requests multiply. Three things to watch for:

1. The “Ready” column empties faster than anyone can fill it with good ideas. (It always contained plenty of bad ideas, but now there’s nothing holding them back.)
2. Stakeholders can’t keep up with what they’re shown, so they stop giving useful feedback.
3. The UI surface is changing faster than end users can absorb.

That is the kitchen with ten ovens. The meals are stacking up at the pass.

More important than ever

Technical discipline!

Agents write code fast. They can also write bad code fast. A significant portion of tokens must be spent on code linting, refactoring, and cleanup.

Automated tests, continuous integration, incremental changes, refactoring, and a strict Definition of Done still matter. They matter more. (A team that lets agents merge without all of those practices builds a mess at a speed nobody has seen before.)

And the oven still needs a skilled chef. Someone has to know what good code looks like. Someone with an eye for great architecture must help everyone to guide the agents.

What to do instead

Today

Draw your team’s workflow on the wall. If business strategy, ideating, and discovery is not already on the wall, add those. And if your workflow ends at “Code in Production” then add: “Gather User Feedback” and “What did we learn?” to the wall.

If those functions were performed by others outside your team:

• bring them into your team, or
• you and your teammates take over those functions.

Start measuring “time-to-learn”

Time-to-learn is described by the Evidence-Based Management Guide as:

The total time needed to sketch an idea or improvement, build it, deliver it to users, and learn from their usage.

Idea-to-learning. Measure how long your org takes from accepting an idea until the moment you’ve studied feedback from real users. Adjust the entire workflow with that metric in mind.

Stop measuring “velocity” and stop estimating immediately

Estimates were always wrong; now they are wrong by many orders of magnitude. Instead, use throughput data for forecasting. (See Kanban.)

Tomorrow

At the Daily Scrum, ask where work is waiting, and what it is waiting for, then take action to eliminate the obstacle. (Don’t just accommodate obstacle. Transform it. Get rid of it.)

This Week

Rewrite one line of your Definition of Done so that it mentions users. For example: “Available to the pilot group, and we are receiving usage telemetry.”

The outcome

Here is the outcome to watch for. Notice where the work waits in the flow. Those are the new bottlenecks. In the next articles in this series, we will discuss what to do with those new problems.

And maybe your context is unique. (Embedded hardware, safety-critical systems, and some heavily-regulated domains still have expensive code.) If writing code is still your constraint, tell me where and why. I’d like to hear it!