AI ships features faster than your company can absorb them

One clear example we saw was a product team that shipped more in one quarter than they used to in half a year. Most of their work was AI-assisted, and most changes passed review and went live without any problems.

There were no obvious failures: fault rates and latency were normal, and the engineering dashboards looked good. But the real problem showed up in usage: people tried the new features but slowly stopped using them. Some features were changed, others were removed, and no one could point to a single mistake that caused it.

When something breaks, engineering teams usually respond by shipping a hotfix. A hotfix can fix the function, but it doesn't bring users back. If a feature works but nobody uses it, it has still failed. It just fails quietly, so the usual response never happens.

AI made writing code faster and less expensive, but it didn't make it any easier to understand a feature, check it, or take responsibility for it after release. Those steps still take as long as before.

When code gets produced faster but everything else stays the same, the gap doesn't go away. Instead, it builds up and eventually leads to rollbacks, features that quietly lose users, and code that nobody fully understands.

We don't think this is a tooling problem. We've seen teams with great observability and others with very little, but the same pattern appears in both. The real limit isn't measuring things, but whether the organization can notice the signals, make decisions, and act on them.

In the cases we have seen, the gap opens in four places.

The first gap is understanding: code now arrives faster than the team can keep up. Engineers jump between many features, and when AI writes most of the code, even the author might not remember how it handles edge cases. This isn't a skill issue; it's what happens when all the knowledge is only in the code. You notice it when someone asks, 'How does this work?' and the answer is, 'Let me check the code.'

The second gap is testing: building a feature might only take a day now, but testing still takes just as long as before. Teams ship more features with the same testing resources, so each feature gets less attention.

The third gap is experimentation: with more features being developed, teams often stop A/B tests early, choose the success metric after seeing the results, and accept results that seem good enough.

The fourth gap is ownership: developers own the code, and the product team is supposed to make sure the feature delivers value. But the product team can't keep up with every new feature. Each feature has someone in charge of its code, but many have no one tracking how they're actually used.

We don't think slowing down is the answer. The goal is to help the second half of the work keep up with the first.

Plan upfront

The most important change we suggest is to plan before building. When writing code took weeks, engineers did a lot of thinking as they built. Now, with AI, you can go from idea to pull request in just an afternoon, so the thinking that used to happen during coding needs to happen before it. If nobody decides something upfront, the model will decide for you, quietly, one guess at a time.

We break upfront planning into four layers. Each one answers a different question, catches a different type of problem, and narrows the focus for the next step. By the time anyone uses an AI assistant, the key decisions are already made.

1. Product review: what problem are we solving?

• The problem. Who has it, how they deal with it today, and why it is worth solving now.
• Desired behavior. What the user should be able to do, described from their side. Include the main flow, the edge cases, and what should not happen.
• Success and failure. The metric that should move, how it will be tracked, and what result would make you roll the feature back.
• Out of scope. What this feature deliberately does not do.

Many features that get rolled back aren't engineering failures. They do what they were built to do, but sometimes that's the wrong thing, or it's only right for a small group. Product review is the best place to catch this, and it's also where you set up tracking for later. Without a clear success metric here, no one can tell if the feature is working or quietly failing. A good check is whether the review explains the problem without mentioning the interface. If it can't, it's describing a solution, not a problem.

2. Architecture design: how does it fit into the system?

• System design. Which services and components are involved, what is new, what changes, and how data flows between them.
• Contracts. APIs, events, and messages between components, including versioning and backward compatibility.
• Data models. New entities, schema changes, migrations, and what happens to existing data.
• Constraints. Performance, security, privacy, cost, and how the feature will roll out and roll back.

AI can write good code when it has clear boundaries, but it doesn't set those boundaries well. It focuses on the prompt in front of it, not the whole system. Without decisions at this stage, each prompt leads to a local choice: a new table here, a duplicated field there, or a direct call that skips an existing service. Each choice seems fine on its own, but together they create a system no one planned. Contracts and data models need the most attention because they're the hardest to change later. You can rewrite code quickly, but changing a data model or a contract that other teams rely on is much harder.

3. Program design: how will the code be structured?

• Types and methods. The core domain types, interfaces, and signatures of the main methods, named in the same language as the product review.
• Dependency injection. How components obtain their dependencies, so you can replace each part in tests and change it later without a rewrite.
• Test approach. What gets unit tests, what needs integration or contract tests, and which edge cases from the product review become test cases.
• Error handling. What can fail, how failures surface, and what the user sees when they do.

This layer tackles the understanding problem directly. When an engineer designs the types and interfaces, and AI fills in the details, the code keeps a structure that someone chose and can explain. That structure lasts through context switches, so even months later, the interfaces show how the feature works without reading every line. It also gives AI a clear target, since an interface with clear types and agreed tests leads to better code than just a paragraph of intent. Tests written before implementation check for the behavior you want, not just what the code happens to do.

4. Vertical slices: in what order will we build and ship it?

• Order of implementation. Thin slices that work end to end, starting with the part with the most risk or uncertainty.
• Multi-repo coordination. Which repositories change, in what order, and how contracts get released before consumers depend on them.
• PR split. Each slice divided into pull requests small enough to review properly, one concern per pull request.
• Validation stages. What proves each slice works before the next one starts: tests, a demo, a check in staging, or an early metric.

AI makes it easy to create a huge change all at once, but reviewers rarely look closely at big changes. Reviewers can understand small, focused changes, but no one really reviews a pull request that rewrites half a module. Slices break a big release into small, testable steps, so if something goes wrong, you catch it after one slice instead of after everything ships. When the first slice reaches real users behind a feature flag, the product metric starts sending signals early, while it's still easy to change direction.

What this looks like in practice

This might sound like a lot of process, but for most features it's just a few pages and a couple of short conversations. AI can help draft each layer once the key decisions are made. Adjust the process to fit the change: a small fix might only need a few sentences per layer, while a bigger feature needs all four layers in detail. The result is a document that sits next to the code and answers, 'How does this work?' without anyone needing to read the code. It survives context switches, team changes, and months of other work. When code was expensive, planning was a small part of the job. Now that code is cheap, planning shapes most of the quality.

Beyond planning

Planning sets expectations, and the next step is to monitor it. Most teams check if a feature works, but fewer check if it actually does what it was meant to do. If the usage metric from the product review drops, it should trigger an alert just like an error rate would. This way, the product team doesn't have to watch every feature manually, because each feature reports on itself.

It's also helpful to use some of the time AI saves for verification. If AI makes building faster, spend some of that time on testing and designing experiments. Otherwise, all the saved time just goes into making more features, which only makes the problem worse.

Finally, every team has a limit on how much change it can absorb, and no number works for everyone. You can still tell when you have gone past yours: rollbacks become more frequent, usage decays quietly, and features live shorter lives before they are reworked or removed. Tracking how long features survive is a simple way to see this, and a shrinking lifespan is worth treating as a warning.

The companies that succeed with AI won't be the ones that ship the most, but the ones that can absorb what they ship, understand it, verify it, and know if it worked.