AI Made Engineering Faster. Why Not The Business?

You can 10x engineering and still not 10x the business.

AI agents are getting very good at coding, debugging, test generation, documentation, and a lot of engineering activities. That is real in many organizations. But if engineering was not the constraint to begin with, or now stops being the constraint because of these improvements, faster engineering output may just create more work waiting somewhere else. The leadership question is changing from “how do we make teams faster?” to “where does this speed actually improve the flow to value?”

If you look at most AI programs out there, whether inside engineering organizations or beyond, they are still being managed as local productivity. Leaders are asking their teams to use AI and leverage it. We are seeing a lot of activity. We are giving people the tools. AI can save people time. People can produce more. That is a great start, but it is not really driving the results we want to see.

The promise AI brings to organizations is that AI should help humans scale. Organizations should achieve much more with the same number of people. We want to improve profit or EBITDA per person. We want to see people spending less time on toil and more time in their flow and genius zone. The translation from people having less waste and more leverage should be that every time we see a person use AI, it drives impact, because these people now have more time to provide judgment, creativity, and problem-solving. The ROI for AI starts with what humans stop wasting time on.

But the reality is that AI is asymmetric. It has a jagged impact on different areas of the organization.

One clear example is coding or engineering. AI coding assistants are great at coding because a big part of their training data is code that is available through open source, and also because code is a relatively deterministic activity. Even if you are not sure how to code something, you can try many times and there is a concrete target function. So AI is great at improving engineering output.

But when you look at the end-to-end lifecycle of development and product, this impact does not repeat in the same way, at least not right now, in other areas of the lifecycle. Engineering speed may improve significantly. You can argue whether it is 10x, 2x, or 3x depending on the environment. But the other activities needed to build awesome products and reach the point where customers or users are actually using them are not moving as fast. They are not moving as fast because AI is not as good at helping organizations there, and also because these areas are harder.

It is harder to get AI to help with product discovery or product adoption. The observability feedback loop is harder. So many organizations let people improve in the areas where improvement is easiest. That creates local productivity, which is simply not enough.

You can 10x engineering, but if engineering is no longer the constraint, that output will create congestion downstream. Or it may create an environment where engineering is starved, because it does not have enough well-shaped work to pull.

In the short term, that may be okay, because many teams have accumulated technical debt and gaps in test automation that they can spend quite a while addressing. So I would not be surprised if your organization is not fully seeing the impact of this starvation bottleneck yet.

One advantage of working on technical debt is that validating technical debt work is much easier than validating new functionality. You are not changing the behavior of the system. You are changing something internal that is observable internally. Even if you are fixing quality issues, that is relatively easy to validate against quality acceptance criteria. Validating value and outcomes is much harder.

So you might already be seeing the congestion. Or you might be seeing a situation where the congestion is hidden, developing, or avoided temporarily, because the engineering organization can use its improvements to catch up on things it has been struggling with for years. In any case, at a certain point, if your engineering organization is growing fast enough, it will stop being the constraint. It will stop being the bottleneck. The congestion will move elsewhere.

One useful thing to do is start visualizing this. Pay attention to where inventory is accumulating and where starvation is starting to appear. The classic way to look at this is to create the value stream flow for the entire lifecycle of features, products, and ideas that you are developing in your organization.

That is true whether you are using AI code assistance or spec-driven development or not. It is something you should already be doing. But it is even more important now to pay attention to end-to-end flow and the full value stream.

You may notice that things that were explored and built are starting to accumulate before shipping to production, depending on how automated that step is in your organization. Or maybe they are already shipped, you have continuous deployment, and the DORA metrics look good. But when you ask whether this work is actually adopted, used, and creating value for people, either it is not really used or you do not really know.

That is an observability gap. It affects your ability to say whether you are getting impact. It also has another effect: if your AI agents cannot know whether what they are building is being enjoyed and used, they cannot close feedback loops either. That is an even worse situation. Figuring out whether anything you are building is creating the expected impact and outcomes, connected eventually to business impact, is a huge move away from AI activity and toward AI value.

One tool I really like for this is the cumulative flow diagram. A cumulative flow diagram shows, over time, how much work is in each stage of your product development lifecycle. In these cases, you may see good flow of work into the system, but then one stage starts piling work onto the next pile over time.

You might see that working-tested software is growing 10 times faster than it used to, but that does not automatically result in improvement in the next stage. It opens a gap between working-tested software, shipped software, and enjoyed-impact software. That is a good sign that the bottleneck has moved and you need to do something about it.

Once you recognize that your AI activity is turning into AI output, which is great progress, the next question is how to shift toward AI impact. Awareness is the first step, but then you need to use this view of end-to-end flow to focus on the bottleneck.

After you find the bottleneck, you can apply principles like the theory of constraints. Subordinate the focus and capabilities of both humans and AI to the current bottleneck.

If the bottleneck is adoption of features you are building, or training users on those features, then your AI effort should not focus on accelerating coding. It should focus on how to use AI to drive adoption. How can we use AI to make it easier for people to use our features? At a minimum, make sure the features you are building are easy to use and do not require a lot of training and change management effort. Maybe use AI inside the feature itself to train, onboard, and activate usage.

Product management has focused on activating users for a while, especially in product-led growth. It is less common when you look at internal systems and internal capabilities, but it is just as important. Adoption is an issue whether you are building B2B SaaS, enterprise software, internal systems, AI capabilities delivered through MCPs and skills, or internal skills shared across the organization. Are people aware of them? Are people using them? Are people actually leveraging what you built for them? That is the question you want to ask.

Ask: where is our bottleneck, and how can we help the bottleneck scale? One interesting way to do that is to give your favorite AI all of this context about the bottleneck and what is flowing through the system. Assuming it is a smart one, ask it to come up with ideas. Do not just tell it what to automate or what agents to create. Ask it what it thinks is going on and what interventions might elevate the constraint.

Let’s go back to the premise for AI. If the high-level premise is to help people move from toil to genius, to help people move from constant multitasking and routine work into flow mode where they can focus on creative work, autonomy, mastery, and purpose, that is a positive premise. But we need to apply even this asymmetrically.

It is not that some people matter less than others. But if we want impact in the organization, there are people we should prioritize helping first: the people currently in the bottleneck. If engineers are not the bottleneck, maybe they are not the first people we should focus on with the deepest enablement effort. Maybe the bottleneck is product professionals. Maybe it is operations. Maybe it is users. We need to look.

Do not just help everybody scale. Focus on helping the constraint scale. You will get to everybody at some point. That does not mean you should not give AI tools to everybody. You should. But when you look at enablement, guidance, support, and focus, the current bottleneck should be one of the criteria.

Once you start actively managing the bottleneck, working around it, and subordinating other areas around it, the bottleneck becomes more effective. That might mean improving the quality of what feeds into the bottleneck. It might mean using spare capacity elsewhere to automate work that needs to happen at the bottleneck. As the bottleneck improves, flow and throughput improve throughout the entire pipeline, whether that is the engineering pipeline or any important value stream in your organization.

At that point, you are shifting from AI activity anywhere in the cycle to actual impact and actual value. You are seeing overall throughput of value improve. And then, of course, there will still be a bottleneck. It might stay in the same place or move elsewhere, so you need to go through this cycle continuously.

AI by itself does not necessarily create new value. It can create new speed. But that speed only matters when it improves end-to-end flow and achieves impact. That is not automatic. You need to use flow thinking, flow metrics, and end-to-end systemic thinking to get your AI investments to the point where they actually improve business outcomes.

The winners in the race to shift from AI activity to bottom-line impact will be the companies and leaders that pay attention to how AI moved their bottleneck, then focus their best human and AI investments in those areas.

Related: Using Flow To Manage Testing Bottlenecks and Flow Metrics Still Matter In Agentic AI Development.