AI and Software Engineering: Iteration Compression, Not Revolution
The Core Thesis#
The arrival of AI-assisted development has prompted a wave of declarations that software engineering has been fundamentally transformed, that the disciplines, principles, and practices the industry spent decades refining are now artifacts of a slower era. I think that’s wrong.
What AI has changed is the rate at which we can iterate. What it has not changed is the nature of the problem we are iterating against. Software development has always been a discipline of managing complexity, and the principles that govern complexity management were not derived from the speed of development. They were derived from the behavior of systems under change. That behavior has not changed.
The industry was already moving in the direction AI is now accelerating. Agile, continuous delivery, short feedback loops all expressed a single conviction that more iterations in less time produces better outcomes. AI does not disrupt that conviction. It is, at its best, a tailwind behind it. The question AI actually poses is not whether to move faster. It is whether your understanding can keep pace with your velocity. Understanding, defined precisely, means maximizing the optionality of your code while minimizing the impact of changes. It is the capacity to respond to what you learn without being held hostage by what you built.
Speed without understanding is not velocity. It is drift. The engineers and organizations that will gain genuine leverage from AI are not those who stop caring about the code. They are those who bring their understanding up to the new speed. That is not a disruption of software engineering discipline. It is its highest expression.
The Claim Worth Examining#
To engage this argument seriously, I need to first represent it fairly. The case for AI as a fundamental transformation of software engineering is not without substance, and dismissing it without examination would undermine what follows.
The strongest version of the claim goes something like this. Software development has historically been bottlenecked by the cost and time of writing code. AI has dramatically reduced both. When the primary constraint of a discipline is removed, the discipline itself must reorganize around a new reality. The practices, roles, and processes that existed to manage that constraint become overhead. The organizations that shed that overhead fastest will outcompete those that don’t. In this framing, engineering discipline is not just unnecessary, it is the thing slowing you down.
This is the claim worth taking seriously, because it is the claim that is actually influencing decisions. It is showing up in hiring conversations, in architectural decisions, and in how organizations are thinking about the role of the software engineer. It is the premise behind what has come to be called vibe coding, the practice of generating code through AI without deep concern for what the code actually does or how it is structured, trusting that future iterations can course correct.
The claim is coherent. It is also wrong, and it is wrong in a specific and consequential way. It misidentifies the constraint.
Eliyahu Goldratt’s Theory of Constraints holds that any system has exactly one constraint at any given time, and that constraint determines the throughput of the entire system. This has a precise and uncomfortable implication for how we think about AI. Improving a process before the constraint does not improve the system. It piles work up at the constraint. Improving a process after the constraint does not improve the system either. It simply means that things wait more efficiently. The only improvement that matters is an improvement to the constraint itself.
Writing code was never the constraint in software development. The constraint was, and remains, understanding. Understanding what to build, understanding the system you are building inside of, and understanding the consequences of the changes you are making. AI has made the process before the constraint dramatically faster. Code that once took days takes minutes. But that code now arrives at the constraint faster and in greater volume, and the constraint has not moved. The understanding required to make good decisions about that code, to validate it, to integrate it responsibly, to reason about its long term consequences, that work is still human work, and it still takes the time it takes.
An organization that optimizes for code production while neglecting the constraint is not moving faster. It is drifting faster.
What Actually Governs Software Engineering#
If the constraint has not changed, we should expect that the principles governing software engineering have not changed either. And that is precisely what I find.
Software engineering is unusual among technical disciplines in that it accumulated its foundational principles not through controlled experimentation but through failure. The same categories of failure, recurring across decades, across organizations, across technology stacks, across team sizes. Systems that became impossible to change. Architectures that reflected org charts no one had intentionally designed. Feedback that arrived so late it was indistinguishable from no feedback at all. The principles that govern our discipline are essentially a taxonomy of these failure modes, formalized so that future teams would not have to rediscover them at cost.
This is the lens through which we should evaluate AI’s impact on software engineering. The question is not whether AI is impressive. It is whether AI has retired any of these failure modes. Not made them cheaper to recover from. Not accelerated our way through them. Retired them. If a failure mode no longer applies, the principle guarding against it no longer applies either. If it still applies, the principle stands.
It is an open challenge to identify a single foundational principle of software engineering that AI has retired. Complexity still accumulates. Systems still reflect the communication structures of the teams that build them. Feedback that arrives late still costs more to act on than feedback that arrives early. Constraints still determine throughput. These are only a handful of examples drawn from a much larger body of knowledge, and the pattern holds across all of them. The failure modes that produced these principles are not only still possible under AI-assisted development, they are in some respects more likely, because the speed at which code is produced has increased while the speed at which understanding is acquired has not.
The principles of software engineering are not conventions the industry settled on out of habit or preference. They are load bearing. They exist because the problem demands them. Disciplines are not designed for the good times. They are built through years of hard won experience precisely so that when conditions become more demanding, more ambiguous, and higher stakes, there is something to fall back on. The moment to abandon engineering discipline is not when the pressure increases. That is exactly when it earns its keep.
The Vibe Coding Problem#
If the discipline still stands, we need a precise term for the practice of ignoring it. That term is vibe coding.
Vibe coding is not a pejorative. It is a description of a specific approach to AI-assisted development. Generating code through AI without substantive concern for what the code does, how it is structured, or what it will cost to change. The intent is to move fast by treating code as an implementation detail rather than an artifact that must be understood and owned. In the short term, this can look like productivity. Features appear quickly. Demos are impressive. Velocity metrics climb.
The problem is not the speed. The problem is that complexity does not care about the speed at which it was created.
Every system accumulates complexity over time. This is not a failure of effort or intention. It is a property of software that grows to meet real demands in a real world that changes unpredictably. The discipline of software engineering exists largely to manage this accumulation, to keep complexity from compounding faster than the team’s ability to understand and navigate it. When complexity exceeds that threshold, the system begins to resist change. Features become expensive. Bugs become harder to isolate. The codebase becomes something the team works around rather than works with. This is technical debt in its most consequential form, and it has nothing to do with whether the code was written by a person or generated by an AI.
Kent Beck, one of the original signatories of the Agile Manifesto and the author of Tidy First?, has spent decades arguing that software creates value in two ways. Through the features it delivers today and through the options it preserves for tomorrow. His framing is precise. Software design creates optionality, and optionality is not a luxury. It is the invisible half of maintainability. In his words, “I didn’t have to change the behavior of my system to make it more valuable. As soon as I added to the options of what it could do next, I had already made money.” Understanding, then, is not a philosophical preference for clean code. It is the mechanism by which a codebase remains capable of responding to what the business learns. A system with high optionality can change cheaply. A system without it cannot change at all, regardless of how quickly it was built.
What vibe coding introduces is not a solution to this problem. It is an acceleration of it. And crucially, the AI itself is not immune. A large language model operating inside a complex, poorly structured codebase does not transcend that complexity. It inherits it. The model’s ability to reason about the system, to generate relevant and coherent additions, degrades as the entropy of the codebase grows. Beck puts it plainly in the context of AI, don’t let the AI eat your seed corn through poor design choices. The tool that promised to make engineering discipline unnecessary becomes the clearest argument for why it was never optional. You do not escape the complexity. You arrive at it faster, with less understanding of how you got there, and fewer options for how to respond.
Augmented coding is the alternative. It is not a rejection of AI assistance. It is an insistence that the engineer remains the author, not just the reviewer of AI output. That the code is understood, not just generated. That quality is treated as a precondition for continued velocity, not a tax on it. The distinction matters because optionality matters. A codebase that is well understood and well structured is one that can change in response to what the business learns. A codebase that is not is one that will eventually hold the business hostage, regardless of how quickly it was assembled.
AI as Iteration Compression, Not Transformation#
The industry did not need AI to tell it that faster iteration produces better outcomes. That conviction was already the organizing principle behind decades of practice. Agile methodologies, continuous delivery, test-driven development, short feedback loops all of it was already pointed in the same direction. More iterations in less time means more opportunities to learn, and more opportunities to learn means better software. This was not a hypothesis. It was hard won knowledge, encoded into the way serious engineering organizations had been working for years before AI arrived.
What AI has done is compress the iteration. Not change its direction. Not change its purpose. Compress it.
This distinction matters more than it might appear. Compression is not transformation. When the industry adopted version control, the discipline of software engineering did not change. When continuous integration became standard practice, the discipline did not change. When cloud infrastructure made deployment a matter of minutes rather than weeks, the discipline did not change. In each case, the mechanics of delivery changed while the principles governing what we were delivering remained intact. AI belongs in this lineage. It is the most powerful compression we have seen, but it is compression nonetheless.
The shift AI introduces is not in what engineers do. It is in where they spend their time. The work of writing code has given way, in large part, to the work of making AI write code well. Crafting precise specifications, establishing architectural constraints, building robust test coverage, reviewing and validating output. These are not lesser forms of engineering. They are engineering applied upstream. The judgment required is the same. The understanding required is greater, because the engineer is now responsible not only for the code but for the context that produced it.
This is where the real opportunity lives, and it is also where the real risk concentrates. AI has raised the velocity ceiling dramatically. But velocity without understanding is not an asset. It is a liability that compounds. The gap between how fast we can now produce code and how deeply we understand what we are producing is the defining challenge of this moment. Organizations that close that gap will have genuine leverage. They will be able to move fast and respond to what they learn, because their systems will be structured to support change. Organizations that do not close that gap will drift. They will accumulate complexity at a speed that no future AI will be able to unwind cheaply, because the risk of large changes to existing systems does not decrease when AI is doing the changing. It remains exactly what it has always been.
The goal, then, is not velocity. It was never velocity. The goal is bringing understanding up to the new speed. Understanding defined precisely as maximizing the optionality of the code while minimizing the impact of changes, the capacity to respond to what the business learns without being held hostage by what the codebase has become. That has always been the point. AI has made it more urgent, more achievable, and more consequential to get wrong.
The Risk of Getting This Wrong#
The risks of abandoning engineering discipline under the pressure of AI acceleration are not abstract. They are structural, and they compound.
The most immediate risk is complexity at speed. Vibe coding does not eliminate technical debt. It generates it faster than any team in history has been capable of generating it. The same systems that once took years to become unmaintainable can now reach that threshold in months. And the consequences are identical regardless of the path taken to get there. A codebase that resists change, a team that spends more time working around the system than building on top of it, and a business that has lost the ability to respond to what it learns. The speed of accumulation does not change the nature of the problem. It only shortens the runway.
The second risk is more existential. If the best your organization can produce is what any team with an API key can generate, you have not built a capability. You have rented one. Your output becomes indistinguishable from your competitors, produced at the same speed, with the same tools, reflecting the same absence of deeper judgment. Competitive advantage in software has never come from the ability to write code. It has come from the ability to understand a problem more precisely, make better decisions under uncertainty, and build systems that can continue to evolve as the problem changes. AI does not commoditize that ability. It makes it more valuable, because it is now the only thing that differentiates you.
These risks share a common root. They are all expressions of the same failure, prioritizing the output of AI over the understanding of the engineers working with it. The output is visible. It is fast. It is easy to demonstrate in a meeting. The understanding is invisible, slow to build, and nearly impossible to measure until it is gone. That asymmetry is what makes this moment genuinely dangerous for organizations that are not paying attention. The cost does not announce itself. It accumulates quietly, in the same way it always has, only faster.
What Should Change#
The goal was never to move fast. It was always to learn fast. Those two things can look identical in the short term and diverge catastrophically over time. The difference between them is understanding, and closing the gap between the velocity AI now makes possible and the understanding required to use it well is the most important engineering challenge of this moment.
The industry has always wanted more iterations in the same timeframe. That desire predates AI by decades. Every methodology the industry invested in, from agile to continuous delivery to test-driven development, was an attempt to compress the distance between a decision and its consequences. To learn faster. To course correct earlier. To make the feedback loop short enough that mistakes were recoverable and discoveries were actionable. AI does not change that ambition. It is the most powerful instrument for achieving it that the industry has ever had.
But the ambition was never raw speed. It was always informed speed. The value of a short feedback loop is not that it moves fast. It is that it produces understanding faster. An iteration that concludes without the team knowing more than when it started is not a compressed cycle. It is just motion. The engineers and organizations that will gain genuine leverage from AI are those who treat the new velocity not as the goal but as the instrument, and who invest the time that AI saves them not in producing more output but in deepening their understanding of what the output means.
In practice this means that the engineer’s role does not diminish under AI-assisted development. It concentrates. The work moves upstream into the precision of specifications, the integrity of architectural decisions, the quality of tests that make AI output trustworthy, and the discipline of review that keeps optionality intact. These are not bureaucratic checkpoints on the way to delivery. They are the mechanism by which velocity becomes leverage rather than drift. They are how an organization ensures that the code it is producing at AI speed is code it can still understand, change, and trust at human speed.
The organizations that close the gap between accelerated velocity and understanding will have something their competitors cannot easily replicate. A system that can respond to what the business learns. Not just a system that was built quickly, but a system that can keep changing quickly, because it was built to be understood. That is the competitive position that engineering discipline makes possible. And it is only available to organizations that never stopped caring about the code.
Conclusion#
The arrival of AI in software development is significant. That much is not in dispute. The ability to generate code at a speed that would have been unimaginable a decade ago is a genuine shift in the mechanics of how software gets built. The question I have examined is not whether AI is powerful. It is whether that power changes the nature of the discipline required to use it well.
It does not.
The principles that govern software engineering were not derived from the slowness of development. They were derived from the behavior of systems under change, from the way complexity accumulates, from the way communication shapes architecture, from the way feedback delayed becomes learning lost. None of that behavior has changed. The failure modes that produced our discipline are not only still possible under AI-assisted development. They are more accessible than ever, because the speed at which we can now create problems has increased while the speed at which we acquire understanding has not.
What AI has given us is the thing the industry was already reaching for, more iterations in less time. That is not a disruption of the engineering mission. At its best, it is a fulfillment of it. But iteration without understanding is not progress. Speed without understanding is not velocity. It is drift. And an organization that drifts at AI speed will arrive at the consequences faster than any previous generation of software teams, with less understanding of how it got there and fewer options for how to respond.
The engineers who will define this moment are not those who abandon the code to the machine. They are those who bring their understanding up to the new speed. Who treat AI as the instrument of compression it is, and engineering discipline as the precondition for making that compression valuable. Who recognize that the gap between velocity and understanding is not a technical problem to be solved by a better model. It is a human problem, answered by the same commitment to craft that has always separated software that lasts from software that merely ships.
The discipline has not been disrupted. It has been called upon. And disciplines, built through years of hard won experience, exist precisely for moments like this one.