Software engineering has reinvented itself many times. Not because engineers changed - but because the economics of building software did.
For more than two decades, Agile has shaped how modern software is built. Organizations have organized teams around it, written books about it, and built careers around it. Today, another shift is underway.
Teams are writing specifications again. Architecture discussions are lasting longer. Documentation is becoming valuable again. Product owners are spending more time defining intent before development begins.
At first glance, it almost feels like software engineering is moving backwards.
Are we returning to Waterfall?
After all, many of the practices gaining attention in AI-assisted development i.e. clear specifications, explicit context, design before implementation - look surprisingly familiar.
But appearances can be deceptive. History suggests something else is happening.
To understand why, we need to step back and look at how software engineering has evolved over the last five decades.
Every generation believes it has discovered the right way to build software. History tells a different story.
Software engineering has always adapted
This isn't the first time our industry has changed the way it builds software. And it almost certainly won't be the last.
But we rarely talk about that change as adaptation. Instead, we treat methodologies like competing philosophies.
Waterfall versus Agile. Documentation versus working software. Planning versus iteration.
Each new methodology is presented as if it finally replaces everything that came before. Reality is much less dramatic. Every methodology solved a problem that had become too expensive to ignore. When that problem changed, engineering practices changed with it.
The interesting question isn't which methodology is "better." The interesting question is:
What problem was each methodology trying to solve?
Once we start looking through that lens, the evolution of software engineering becomes much easier to understand.
Before methodologies had names: Build & Fix
Long before software teams debated Scrum ceremonies or sprint planning, software development looked remarkably simple.
You built something → it broke → you fixed it. Then you repeated the process.
There wasn't much ceremony because there didn't need to be.
Projects were small. Teams were small. Requirements were often sitting in the same room as the people writing the code. The cost of making a mistake was usually manageable.
As software became more ambitious, however, the economics changed. Projects grew. Teams expanded. Systems became interconnected. Releases affected thousands, then millions, of users. The same informal process that once felt efficient gradually became expensive. The cost of coordination eventually became lower than the cost of chaos.
And software engineering responded the way it always has. It evolved.
Observation
Build & Fix didn't disappear because engineers became more disciplined. It disappeared because it stopped being economical.
Waterfall wasn't trying to slow teams down
Waterfall is often portrayed as the methodology that loved documentation and hated change. That's an oversimplification.
The engineers who developed structured lifecycle models weren't trying to create bureaucracy. They were responding to a very real economic problem.
Software had become expensive to change. Projects involved large teams. Requirements passed through multiple departments. Testing often happened months after development had begun.
If a fundamental assumption turned out to be wrong, correcting it could require months of rework.
Planning wasn't the goal. Reducing expensive mistakes was. The thinking was straightforward. If changing decisions later is expensive, spend more time making better decisions earlier.
Define the requirements. Design the architecture. Implement carefully. Test thoroughly. Release.
Waterfall wasn't optimizing documentation. It was optimizing predictability.
The trade-off, of course, was feedback.
Customers often saw working software only after significant effort had already been invested. By the time reality challenged the original assumptions, changing direction had become costly. That weakness eventually became the next problem software engineering needed to solve.
Waterfall didn't optimize planning because engineers loved documentation. It optimized planning because changing decisions was expensive.
Agile optimized a different question
Markets became faster. Customer expectations evolved more quickly. The internet shortened product cycles. Businesses could no longer afford to spend a year delivering something that users no longer wanted.
The biggest risk was no longer changing direction. The biggest risk was discovering too late that you were solving the wrong problem.
Software engineering adapted again. And this time, it optimized something completely different. Agile wasn't successful because it replaced Waterfall. It was successful because it optimized a different constraint.
Instead of asking,
"How do we avoid expensive mistakes?"
Agile asked,
"How do we learn sooner?"
That single shift changed almost everything. Rather than betting an entire project on one set of assumptions, teams delivered software in smaller increments. They gathered feedback earlier. Validated ideas continuously. Adjusted direction before mistakes became expensive.
It wasn't just a new process. It was a different optimization strategy. And for the next twenty years, it worked remarkably well.
Why? Because one constraint still dominated software engineering. Humans were the limiting factor. Every feature depended on engineers translating ideas into working software. Writing code was slow. Changing code required effort. Engineering capacity was scarce. Everything else revolved around that reality.
Then AI quietly changed the economics
Most discussions about AI start in the wrong place. They focus on what AI can do.
AI can generate code. Write tests. Explain documentation. Review pull requests. All of those capabilities matter.
But none of them explain why software engineering itself feels different.
The real change isn't technological. It's economic.
For the first time in decades, generating code is no longer the scarcest activity in the development process.
A feature that once required several days of implementation can now appear in an afternoon. Entire refactors can be proposed before the first coffee break. Boilerplate disappears. Routine implementation accelerates.
From a distance, this looks like a massive productivity gain. Up close, something more interesting happens. The code arrives faster. The questions arrive faster too.
We've seen the bottleneck move
This isn't a theory. It's something we've experienced repeatedly while building AI-assisted systems.
A pull request appears - hundreds of lines, sometimes thousands. The implementation is surprisingly good. Then the real work begins.
Does it match the architecture? Did the model misunderstand the business rules? Is this solving the right problem? Does it introduce subtle security risks? Will another engineer understand it six months from now? Should this code exist at all?
None of those questions are new. What's changed is where engineering time is spent.
Previously, implementation dominated the schedule. Now it's often the shortest part of the conversation. Understanding, review, validation, and evaluation have quietly become the new constraint.
Faster generation isn't faster delivery
AI can generate code dramatically faster. But software development is more than writing code. Requirements, design, architectural decisions, reviews, testing, and validation still take time and much of that work still requires human judgment. The overall process gets faster, but not in proportion to the speed of code generation.
Developers feel dramatically faster. Teams don't always ship dramatically faster.
Individual productivity and system productivity are not the same thing. Confidence doesn't scale at the same rate as generation.
Observation
AI accelerates generation. It doesn't automatically accelerate understanding.
Looking back, the evolution no longer looks random. Each generation optimized the biggest constraint of its time. The practices changed because the bottleneck changed.
Bottlenecks drive methodology.
Today's biggest constraint isn't writing code. It's shared understanding.
AI didn't remove the bottleneck. It moved it.
When shared understanding becomes scarce
Everything else starts to make sense.
Why are teams writing specifications again?
Because models can't infer intent that was never made explicit.
Why does documentation suddenly matter?
Because shared understanding has become a production dependency - across people, teams, and the AI tools they use.
Why are architecture discussions lasting longer?
Because changing intent after generation is still expensive.
Why are organizations investing in evaluation frameworks?
Because confidence - not code - is becoming the limiting factor.
None of these practices represent a return to Waterfall. They're responses to a new constraint - just as Agile responded to the constraints before it.
What comes after Agile?
Not another named framework to join the belief-system wars.
And not a retreat into Waterfall.
Waterfall tried to reduce uncertainty by delaying implementation until everything had been planned. Agile accepted uncertainty and learned continuously through working software. In the AI era, those strengths start to work together: Waterfall's discipline on intent, Agile's short loops, and AI's speed.
It's engineering rebuilt around shared understanding as the scarce resource - while keeping continuous shipping and fast feedback.
That understanding has to hold across more than one engineer with a sharp prompt. It has to travel between client teams and delivery teams, across product and engineering, and into whichever AI tools each person prefers. When those parties don't share the same intent, constraints, and decisions, faster generation just scales misunderstanding.
AI didn't bring Waterfall back.
It made shared understanding expensive to skip.
How we try to create and keep that shared understanding in practice - specs, documentation, and the loops we use with clients and AI tools - is the next article in this series.
