AI is reshaping how software gets built. Engineers are writing more code, more tests, and more documentation than ever before. The tools are genuinely impressive and the individual productivity gains are real. I have seen it firsthand on teams I have led and in the work I do with clients today.
And yet, something is not adding up at the organizational level.
Companies are not moving proportionally faster. Roadmaps are not clearing. Delivery timelines are not compressing in the ways executives expected when they bet on AI tooling. Several prominent voices in the industry have noted this same tension: engineering is becoming more efficient, but companies are not. That observation deserves a serious unpacking, because the reasons are real, they are structural, and they are not going away on their own.
The Efficiency Paradox
There is a well-documented gap between individual productivity and system throughput. Thinkers in lean manufacturing and software delivery theory have pointed to this for decades. When one part of a system speeds up, the constraint shifts; it does not disappear. You do not get a faster factory by running one station at double speed while everything downstream stays the same. You get a bigger pile in front of the next bottleneck.
Queue theory gives us a rigorous way to think about this. In any system where work flows through multiple stages, from idea to shipped feature, throughput is governed by the slowest constraint, not by the fastest participant. If engineers can now produce twice the output, but review cycles, product sign-off, QA coordination, deployment pipelines, and stakeholder alignment have not scaled accordingly, the queue simply moves. Work accumulates at a different stage. The system as a whole does not accelerate. In many cases, it actually becomes harder to manage because there is more work in flight at any given moment.
This is not a criticism of the tools. It is a structural reality that every leader driving AI transformation needs to account for.
More Is Also More: The Cognitive Load Problem
Engineers today are doing more than their counterparts from five years ago. More tests. More documentation. More code review commentary. More integration checks, security scans, accessibility audits, and compliance annotations. Many others in the industry have pointed this out: the scope of what a good engineer is expected to produce has expanded dramatically.
This is genuinely good. Higher test coverage means more confidence. Better documentation means faster onboarding. Automated checks mean fewer manual oversights. I am not here to argue against any of it.
But there is a cost that gets underappreciated: as the output grows, so does the weight of everything that has been created. Codebases are larger. Documentation stacks are deeper. Configuration surfaces are wider. And all of that accumulated work needs to be held in the minds of the humans responsible for it.
There is a natural ceiling to how much the human mind can actively hold and process at once. The total demand placed on working memory by a system, all of its code, its configuration, its dependencies, its history of decisions, is what researchers call cognitive load. That load grows with every layer added to the system. Right now AI is dramatically increasing the volume of what teams produce, and the cognitive burden of keeping up with all of it is rising just as fast.
Debugging in a World You Did Not Build
Human-scale work has a natural limit, and AI is helping teams exceed it faster than ever. That stress surfaces most clearly when something breaks. In a codebase built gradually, by hand, with shared context, experienced engineers have intuition about where to look. They remember the decisions. They know the trade-offs that were made.
That institutional intuition erodes quickly in AI-augmented environments. When significant portions of a codebase were generated at speed, even by skilled engineers using good prompts, the depth of internalized understanding is shallower. Debugging becomes slower, not faster. Root cause analysis requires more context-gathering. The cost of a production incident climbs because the investigative work takes longer.
This is not hypothetical. It is a pattern I see in practice. Teams that move fast with AI assistance and do not invest in mechanisms for building genuine understanding find themselves in a brittle position when things go wrong, and things always go wrong.
Continuity Is Moving from Humans to Systems
Here is the shift I want you to think seriously about. We are in the middle of a quiet but profound change in where institutional knowledge lives.
For most of software history, the primary vessel of continuity was the experienced human. The senior engineer who knew why the authentication module was built the way it was. The product manager who remembered the customer research behind the original design decision. The architect who had carried the system's load-bearing assumptions in their head for years.
That knowledge is migrating. It is moving into source code, documentation, runbooks, procedures, architecture decision records, and test suites. On the surface, this looks like an improvement, and it often is. Written knowledge does not quit, does not burn out, and does not leave for a competitor.
But there is a trap here. If the volume and complexity of that electronic record grows faster than any human can meaningfully absorb, then the only entity capable of holding, navigating, and synthesizing all of it is an AI model. You will end up with systems whose continuity is effectively maintained by AI, not because you designed it that way, but because that is where the drift takes you.
Teams need to build explicit processes, review mechanisms, and culture norms to ensure that human understanding keeps pace with what they produce. Not just that it exists in a file somewhere, but that real people genuinely understand it well enough to make decisions, explain it to others, and defend it in a conversation. If you cannot do that, you have not shipped a product; you have shipped a liability.
Product Management and Operations Feel It Too
It would be a mistake to frame this as purely an engineering challenge. Product managers have traditionally had a natural buffer created by longer engineering cycles. That time was not idle; it was when they ran customer discovery, synthesized research, mapped edge cases, and got ahead of the next phase of work. Those are fundamentally human-scale processes. They require real conversations, time to reflect, and space to think. When engineering accelerates dramatically, that buffer shrinks. Product managers are now expected to keep pace with a delivery cadence that their human-scale research process was never designed to match.
Operations teams are managing more automation, more infrastructure components, more pipeline stages, and more alert noise than ever before. The tools are more capable, but the operational complexity they introduce is real. Runbooks multiply. Dependencies deepen. The blast radius of a misconfiguration grows alongside the system it configures.
Everyone in the delivery chain is doing more. The AI transformation conversation needs to take that seriously, not as a reason to slow down, but as a reason to invest in the organizational systems that absorb and manage that load.
Do More With the Same, Not the Same With Less
A common reaction I am watching play out at companies right now is headcount reductions in engineering. On the surface the logic seems sound: if engineers are significantly more productive with AI tools, you can do the same work with fewer of them. The cost savings are real and the org chart gets leaner.
But this is the efficiency paradox in action again. If engineering is no longer the constraint, cutting it does not help. The constraint has moved downstream. Product managers are overwhelmed. GTM teams cannot absorb the pace of releases. Operations is stretched thin. Reducing the one function that just got faster does not accelerate overall delivery.
The better framing is not "do the same with less" but "do more with the same." Use the efficiency gains engineering has unlocked to grow the rest of the system. Invest in product management capacity. Build out DevOps. Give your GTM and customer success teams the support they need to keep pace with what engineering is now capable of shipping. A strong engineering team is a force multiplier, but only if the rest of the organization can absorb and act on what it produces.
Do not weaken a strong component in a system. Build up the system around it.
Compliance: A Quiet Risk
Compliance deserves a mention here, though I will save the full treatment for a future post. Whether your organization operates under SOC 2, HIPAA, PCI-DSS, or another framework, audits remain largely human processes. The people responding to auditors need to genuinely understand the controls being reviewed. When your compliance posture was largely AI-assisted and the team has shallow internalized understanding of it, audits become fragile. This risk is real, it is growing, and it is not yet on most transformation roadmaps.
Telemetry: The Drum I Will Keep Beating
If there is one thing I will return to again and again, it is this: telemetry is more important now than it has ever been. In a world where systems are larger, more AI-assisted, and harder for any individual to fully internalize, your ability to see what is actually happening is the foundation of everything else. Debugging, incident response, compliance evidence, product decisions, operational confidence: all of it depends on real, trustworthy observability. You cannot become an AI-native organization without also becoming a telemetry-native organization. I will dedicate a full post to this, but the short version is: invest in it now, before the system grows faster than your ability to see inside it.
What This Means for Leaders
AI transformation is not just a tooling upgrade. It is a change to the fundamental relationship between humans and the systems they build. That change brings real gains. I have seen them and I am excited by what is possible. But it also brings structural challenges that require intentional leadership to navigate.
The teams that come out ahead will be the ones that do three things well. First, they will treat organizational throughput as a distinct problem from individual productivity and invest in removing the systemic constraints. Second, they will build mechanisms (reviews, learning practices, knowledge accountability) that ensure genuine human understanding keeps pace with what they produce. Third, they will invest heavily in observability, because telemetry is the connective tissue that holds everything together when scale and complexity exceed what any person can hold in their head.
If your organization is navigating this transition and you are not sure whether the whole system is keeping pace, that is exactly the kind of challenge I work through with leadership teams in a fractional capacity. A fresh perspective from someone who has seen these patterns across companies can accelerate clarity and help the whole org move together. I would enjoy the conversation.
