I have never had an issue with Agile delivery—showing clients working software every 2-3 weeks is brilliant. My problem? The way many teams interpret Agile on the architecture side.
The Origins: Why Agile Made Sense for Startups
Agile emerged from Extreme Programming and the startup world. When you are an innovative tech company or startup in your early days, you genuinely do not know what your market wants. You make your best guess, quickly develop a solution, get it in front of clients, gather feedback, and iterate. This often requires refactoring your architecture as new requirements emerge that break your initial design.
In these contexts, accepting architectural refactoring makes sense. You do not (and cannot) have a substantial percentage of requirements on day one, so you expect to refactor as you discover what customers actually need. Since early-stage solutions are relatively small, refactoring does not carry the expense that larger and more mature solutions require.
Where Agile Orthodoxy Fails
The problem arose when Agile methodology became, well, dogmatic. Many practitioners extrapolated these startup principles to all organizations and solutions, regardless of context.
I have witnessed projects where the requirement was simply to recreate an existing solution on a modern technology stack. The first version was expected to have the same functionality as the legacy application. In theory, the team had 100% of requirements on day one.
Yet Agile orthodoxy dictated: take a subset of requirements, build a prototype, then add requirements sprint by sprint. The result? Projects that should have taken 6-8 months stretched to 2+ years, as each sprint required architectural refactoring to accommodate requirements that were already known from day one.
My Heretical Approach: Architecture First, Then Agile
On projects I have managed, I have required teams to analyze existing requirements, design the architecture that will support them, then slip into Agile sprint delivery. I often called these "architectural sprints" to fit the Agile vocabulary and avoid endless debates.
This approach saved substantial time and money by avoiding unnecessary refactoring. Yet I consistently faced pushback from teams who argued that upfront architecture was antithetical to Agile principles.
The House-Building Analogy
I often challenged strict Agile proponents: "Go build a house using pure Agile methodology."
Imagine a newly married couple needs a minimum viable product: kitchen, bedroom, bathroom, and garage for their sports car. You build this, they move in.
First dinner party? They realize guests need to walk through their bedroom to reach the bathroom. They need a powder room. Unfortunately, you must now rip up those beautiful hardwood floors to run new plumbing.
Next? They're expecting twins. Suddenly they need two more bedrooms and another bathroom. Good luck attaching those to your minimal viable product. And that garage? Tear it down—the minivan won't fit.
No one builds physical structures this way. A good architect designs the complete house upfront, accounting for known future needs. You can still deliver in phases—start with the minimum viable product—but on day one you know you will need that powder room. You just will not build it until nine months later. When you do, the plumbing is already in place thanks to thoughtful architectural design.
Why should software be different when we have comprehensive requirements from the start?
The Missing Piece: Distinguishing Architectural Requirements
For years, I have predicted that there are at least a couple computer science PhDs waiting for someone who creates a reliable method for separating architecture-dependent requirements from superficial ones.
In house design, architects instinctively know which requirements matter structurally. Electrical, plumbing, and HVAC frameworks are critical. Paint colors, countertop materials, and light fixtures are not—though appliance choices (gas vs. electric stove) can be.
We have lacked a generic methodology for this kind of requirements triage in software development... until now.
How AI Changes Everything
Here is the breakthrough: AI code generation fundamentally alters the economics of architectural refactoring.
What previously required weeks or months of developer time—analyzing the existing codebase, redesigning the architecture, manually rewriting affected components, testing integration points—can now happen through iterative prompting of AI tools.
Modern AI frameworks can:
- Take an expanded requirements set
- Analyze the optimal architecture for those requirements
- Generate the corresponding code with remarkable efficiency
- Refactor existing implementations when requirements evolve
The transformation that once consumed engineering sprints now happens in hours or even minutes. While the code still requires human review, testing, and validation, the mechanical work of architectural refactoring has become trivial.
What This Means for Software Development
This does not vindicate either side of the Agile architecture debate. Instead, it renders the entire argument obsolete.
The traditional objection to pure Agile—that architectural refactoring is prohibitively expensive—no longer holds. The cost has dropped by orders of magnitude.
Similarly, my insistence on upfront architecture, while still valuable for complex known-requirement scenarios, is no longer the only practical path forward.
AI has created a third way where rapid iteration and architectural refactoring can coexist affordably. Teams can genuinely start with incomplete requirements, evolve their understanding, and restructure their solutions without the traditional penalties.
The promise of Agile—deliver value quickly, respond to change, embrace uncertainty—is finally achievable without mortgaging the architectural future.
Important Caveats
This transformation isn't without considerations:
Human oversight remains critical. AI-generated code requires rigorous review, testing, and security validation. Blind acceptance of AI output is dangerous.
Architectural understanding still matters. Teams must understand the architectural implications of their choices, even if AI handles implementation. The ability to evaluate AI-proposed architectures is essential.
Not all refactoring is equal. While AI excels at code-level refactoring, fundamental architectural pivots (monolith to microservices, synchronous to event-driven) still require significant human judgment and system-wide coordination.
Looking Forward
I am relieved to no longer defend "architectural sprints" against Agile purists. More importantly, I am excited to explore what this AI-enabled flexibility means for how we plan and execute projects in 2026 and beyond.
The debate was never really about Agile versus architecture. It was about managing the cost of change. AI hasn't settled the philosophical argument—it's dissolved the economic constraint that created the conflict in the first place.
What does this mean for your development approach? Are you experimenting with AI-assisted refactoring? I would be curious to hear about your experiences.