Eliyahu Goldratt spent his career teaching a single idea: every system has one binding constraint, and improving anything that isn't the constraint is an illusion of progress. A factory with ten machines in sequence has one bottleneck. Speed up the other nine and all you get is a bigger pile of inventory in front of the one that's slow.
For most of software development's history, the binding constraint was implementation. How quickly can we turn a decision into working code? Teams optimized for this relentlessly: better languages, better frameworks, better tooling, faster CI pipelines. The whole industry organized around accelerating the act of writing software.
AI blew that constraint wide open. And the moment it did, the bottleneck moved.
What Happens When Implementation Gets Cheap
Over the summer I watched several teams discover something counterintuitive: AI tools made them so fast at generating solutions that the real constraint became making sure they were solving the right problem. The gap between "what if we tried this?" and "here, look at it running" shrank from days to minutes. Time-to-iteration collapsed.
That speed gave them something back they didn't expect: time with the people whose problems they were solving. More time validating. More time course-correcting before sinking a sprint into the wrong direction. The teams that leaned into this — that treated the freed-up time as an opportunity for deeper problem understanding rather than more feature output — produced genuinely better work.
But speed has a shadow side, and these teams found it fast.
The Repo Wars
A team decomposes the work. Person A takes the frontend. Person B takes the backend. Standard practice. Except now both are working with AI tools that move at machine speed, and those tools don't have the full context of what the other person is building.
So each tool does what tools do. It implements what's necessary to deliver a complete, working feature.
Person A's AI builds out API stubs to test against. Person B's AI builds a slightly different set of endpoints. Both are internally consistent, well-structured, and completely incompatible with each other.
These weren't merge conflicts. These were outright repo wars — two pieces of code implemented to do the same thing because when they were written, neither version existed yet. A 2026 study of over 142,000 AI-generated pull requests found that nearly 28% contained merge conflicts, yielding over 336,000 conflict regions. That's not a rounding error. That's a structural problem with how parallel AI-assisted work interacts.
The anguish in those conversations was real. Sometimes you want the tools to run free, explore the space, surprise you. But not when you're decomposing work between team members who need their pieces to fit together.
Our interns learned something this summer that usually doesn't hit until your first time on a large team with an older codebase: the only thing worse than a merge conflict is one that's too messy to untangle. But this isn't just an intern problem. At AI speed, you can diverge catastrophically between a morning coffee and lunch. The casual optimism that "things will sort themselves out" assumed human-speed development. That assumption no longer holds.
The Ratio Inverts
Here's the mental model shift: the planning-to-execution ratio inverts. The teams I see succeeding spend the majority of their time on design and validation, then let the tools handle the execution burst. The writing is cheap now. The deciding-what-to-write is the expensive part.
But "more time on planning" does not mean more time in requirements committees, compliance theater, or documentation-for-documentation's-sake. In government and regulated environments especially, the old model burned enormous human hours in process sinks that produced paperwork, not clarity. Twelve people debating requirement language that nobody will read once the system exists. Compliance reviews that verify adherence to a plan rather than fitness for purpose.
The inversion, properly architected, reduces time in those sinks. When you can prototype a solution in an afternoon and put it in front of the people who will use it, you don't need a six-week requirements phase to guess what they want. You show them. They tell you what's wrong. You iterate. The compliance artifact becomes a record of what you built and validated, not a speculative prediction of what you hope to build.
The answer is more time with people, not less. More time sitting with users. Less time in conference rooms negotiating abstract specifications that will be wrong by the time implementation starts anyway. The faster your tools execute, the more damage a wrong direction inflicts before anyone notices. Goldratt again: when you remove a constraint, the system doesn't become unconstrained. The constraint moves. You'd better be looking for where it went.
What Actually Works
Here's what I'm seeing work:
Centralize Your Architecture Documentation
This can be as simple as a team agreement that architecture decisions live in the repo, or as sophisticated as MCP interfaces between your AI tooling and your planning and documentation systems. Ensure that changes are documented and discussed before they're implemented. Give the team a moment to breathe before dropping decisions back into the rapid iteration cycle.
If your AI tools can read the architecture docs before generating code, they'll generate code that fits. If they can't, they'll fill the gaps with whatever seems reasonable — and "reasonable" without context is how repo wars start.
Treat Your Steering Like a Living System
The prompts that drive AI-assisted engineering fall into two categories, and conflating them is a common failure mode.
Stone decisions are constraints that should be durable. You're building on AWS? Well-Architected is a stone constraint. Your API uses REST with consistent resource naming? Stone. These rarely change and the AI should treat them as immovable.
Scaffolding decisions are constraints designed to come down. Implementing a first-round dashboard prototype? Experimenting with a new charting library? That's scaffolding. You put it up to get work done, with the full intention that it won't last. You move it along, you bring it back down, you change it — because it was never meant to be permanent.
Like agile teaming agreements, this is something I wish more teams spent time on. Not just writing the initial steering, but reviewing it. Is this still true? Is this still how we want to work? The moment your guidance goes stale, the tools start drifting — and at their speed, drift becomes divergence fast.
Be Explicit About What You Don't Know
You can't always plan every interface up front. But you can be explicit with your tools about what's undefined.
If you're working the frontend and the backend doesn't exist, say so. "Mock the API calls. We don't know what the endpoints look like yet. Don't implement them." That single constraint prevents the tool from inventing a backend that will be incompatible with whatever Person B actually builds.
This is where centralized docs and stone/scaffolding guidance compound. If the API contract is still undefined (scaffolding), every developer's steering should reflect that as a hard boundary: mock it, don't build it. The moment the contract solidifies (stone), update the guidance and let the tools work against the real thing.
The failure mode isn't insufficient planning. It's insufficient constraint.
Don't Fight the Tools
I've written before about how agentic development parallels managing high-performing teams. Set the outcomes, not the specifics. Define the constraints that matter and let the tools generate code under your supervision. Micromanaging the tools is like micromanaging a senior engineer. You'll get compliance, not quality.
Sometimes, Go Alone
"If you want to go fast, go alone; if you want to go far, go together." In an AI era, the first half has never been more true.
Sometimes the most effective move is to let one developer run a problem solo for a day while the rest of the team manages other work. One person with AI tools, unconstrained by coordination overhead, can produce a coherent end-to-end solution faster than a team can negotiate how to split it. That solution then becomes the shared artifact everyone works from — not a plan, but a working prototype that embodies the plan.
This is the exception that proves the rule. The coordination cost of parallel work at AI speed can exceed the productivity gain of parallelism. When that's the case, don't split the work. Let one person run, then converge.
Stop Wasting Human Cycles on Line-Level Review
If you set up the architecture docs, the steering, and the constraints correctly, your team should be spending minimal time in code review.
Avi Press, founder of Scarf and a member of the Haskell Stability Working Group, recently moved his company from Haskell to Python after seven years in production because AI tools now generate high-quality code faster than Haskell's type system can compile it. The tools caught up to the type checker.
The implication for review is direct. If you've done the upstream work, the generated code should be structurally sound. Review time should be spent talking about where architectural transitions happen between modules, not where the semicolons go. If your reviews are still catching syntax issues, you have a guidance problem, not a review problem.
The Constraint Moved
AI didn't remove constraints from the development process. It shifted them. The constraint used to be "how quickly can we generate a solution?" Now it's "how quickly can we agree on what the right solution looks like, and how do we keep everyone — human and AI — pointed at the same target?"
That's a coordination problem. A communication problem. A design problem. It was always those things. We just had the luxury of solving them slowly because implementation was slow too.
That luxury is gone. The teams that thrive at this new speed aren't the ones with the most powerful AI tools. They're the ones that figured out how to think clearly about what they're building before they let the tools build it.
But the problems are still human. The users are still human. The judgment about what's worth building is still human. Speed only matters if it's pointed at the right target, and the only way to know the target is right is to spend time with the people who feel the pain.
More time with people. That's where the freed-up hours should go. Not more features, not more process, not more documentation nobody reads. More time understanding. The tools handle the rest.