What If Agile Was the Detour?

A TechFabric Field Notes Deep Dive — Part 2 of 3

The Assumption Nobody Questions

We've all accepted the same origin story: Agile exists because Waterfall failed. And that's mostly right. Requirements gathered in January were obsolete by June, budgets ballooned, and teams delivered systems that technically matched the spec but missed the actual business need by a mile.

Agile addressed this by making iteration the default — ship something small, learn from it, adjust, and accept that the first version will be wrong. For twenty years, this has been gospel.

But that rests on an assumption that nobody revisits: the reason Waterfall failed was structural, not circumstantial. The prevailing belief is that upfront planning is inherently flawed because requirements always change, that iteration isn't just better, it's the only viable approach.

What if that assumption was wrong? What if Waterfall's real failure wasn't the philosophy of planning upfront — it was that the cost of executing a detailed plan was so high that any mistake in the plan was catastrophic?

What Actually Went Wrong With Waterfall

We've all seen the pattern that killed Waterfall projects. A team would spend three months gathering requirements, another two months on architecture, and then six to twelve months building it with twenty engineers who'd never touched the client's systems. By month eight, someone would discover that the data model didn't account for a constraint that operations had been working around for years, and reworking it meant reworking everything downstream.

The failure lay in the planning’s execution cost. When implementation takes twelve months and costs millions, an architectural mistake discovered in month eight is fatal. The budget to fix it doesn't exist. The timeline to recover doesn't exist. So teams shipped the flawed design and built workarounds on top of workarounds.

Agile's real innovation was risk management. By shipping in two-week increments, the cost of being wrong dropped dramatically. You didn't need to get the architecture right on day one because refactoring every few sprints was cheaper than getting it wrong once at scale.

But refactoring was never free. Every CTO we work with knows this. The "acceptable" cost of iterating from MVP to production is actually enormous — measured in months of rework, schema migrations, integration rewrites, and the organizational friction of telling the business that the thing you shipped last quarter needs to be rebuilt before it can handle the next use case.

Agile didn't eliminate the cost of architectural mistakes. It amortized them. And for twenty years, that amortization was the best deal available.

The Deal Just Changed

We wrote in our last article about Claude Opus 4.6 releasing with a 1M token context window and GPT-5.3-Codex dropping with 25% speed improvements. We focused on how those capabilities flipped the build vs. buy decision. But the deeper shift is in what these capabilities do to the planning-execution tradeoff.

When a senior engineer can load an entire codebase, legacy system documentation, and a complete set of business rules into a single session — and when purpose-built AI infrastructure handles implementation throughput at 4-5x the speed of a traditional team — the economics of upfront planning invert.

The math matters: If implementation takes twelve months, spending three months on planning feels risky because requirements might change before you're done building. But if implementation takes four weeks, spending two weeks on planning is the obvious play. You're not guessing what the business will need a year from now. You're describing what it needs right now, in full detail, and shipping it before the next board meeting.

The constraint that made Agile necessary — the prohibitive cost of detailed upfront execution — is collapsing.

The Data Model Problem

Every enterprise system starts with a data model. In Agile's iterative world, that model evolves sprint by sprint. You build the MVP schema, “good enough for now.” Then you refactor it for the next feature. Then again. Then again. A logistics client we're working with described their schema evolution: seven major migrations across eighteen months, each one requiring downstream changes to APIs, reports, and integrations.

The Agile defense is that you couldn't have known the right data model upfront. And five years ago, that was probably true. Discovery happens through building.

But our senior engineers — the ones with fifteen years of enterprise experience — could have designed 80% of the right data model from day one. They've built systems like this before. They know where schemas break at scale, which relationships become bottlenecks, and what compliance requirements will surface in month six. What held them back wasn't knowledge. It was time. Designing the ideal schema and building it was a six-month project. The business needed something in six weeks.

The tradeoff doesn't exist anymore. A senior engineer describing the long-term data model in full detail, with the right AI infrastructure handling implementation, ships the production-grade schema in the same window that used to produce an MVP. The seven migrations and eighteen months of rework never happen.

The Industry Is Moving Here

A methodology called Spec-Driven Development is formalizing what we've been doing intuitively — investing heavily in upfront specification, then using AI infrastructure to execute against that spec at speed.

Amazon built an experimental coding environment called Kiro that forces developers to choose between two modes: exploratory "vibe coding" and a specification-driven mode. Their finding: developers weren't giving AI enough detail to get high-quality results. The tool itself acts like a project manager, guiding teams to plan more before coding.

Teams adopting spec-driven approaches are reporting 50-80% reductions in implementation time for well-specified features. Engineering leaders are spending three times more effort on upfront design than they did two years ago — not because they're reverting to Waterfall, but because the return on planning has fundamentally changed when AI infrastructure can execute a detailed spec in days instead of months.

As one AI engineer put it, the agents we're working with today need what Waterfall provided even more than people did. AI is powerful at following exact instructions and terrible at reading minds. Exhaustive upfront specifications aren’t a bureaucratic relic but the ideal input format for the infrastructure responsible for building.

What This Actually Looks Like

Here's a recent engagement. A manufacturing client needed an inventory optimization system integrating with their ERP across twelve factories and 50,000 SKUs. Under the old model — iterative Agile sprints with a large team — this was a nine-to-twelve month initiative with a roadmap full of "we'll figure it out when we get there."

Our approach: two senior engineers spent two weeks embedded in the client's operations, mapping the real constraints — supplier minimum order quantities that vary by season, contractual inventory floors, production line changeover costs, the actual business logic that operations had been carrying in their heads for years. They described the ideal long-term data model, integration architecture, and optimization logic in full detail.

Then they built it. Six weeks. Production-grade. The system they shipped wasn’t an MVP that would need three rounds of refactoring. It was the system they would have built from day one if traditional development economics hadn’t forced the compromise.

This is the pattern we’re seeing across engagements. When implementation cost drops by 80%, the rational response isn’t to iterate faster. It’s to plan better and build right the first time.

The Forward-Deployed Advantage

There's a nuance to be understood. Upfront planning only works when the people doing the planning understand the real problem. Spec-driven development in the hands of a team working from a sanitized requirements document produces the same failure mode as 1990s Waterfall — a beautifully specified system that doesn't match operational reality.

This is why the forward-deployed model has it’s place. Our engineers don't write specs from a conference room. They embed in your operations, understand your actual constraints, and then describe the right system with the confidence that comes from having seen the data, met the people, and watched the workarounds happen at 7 AM.

The combination of senior engineers with deep embedded context, armed with AI infrastructure that executes detailed specifications at speed is what makes this work. It's what Waterfall was trying to be before the economics made it impossible.

In Part 3 of this series, we'll go deep on exactly how forward-deployed teams operate, what embedded context actually means in practice, and how this model is reshaping what enterprises can expect from engineering partners.

The Planning Premium

Agile isn't dead. We still see projects where iterative discovery is the right approach — genuinely novel products where nobody knows what "right" looks like, or R&D efforts where the point is exploration.

But for the enterprise systems our partners are bringing to us — inventory optimization, carrier selection, pricing engines, workflow automation — the problem space is well-understood by senior engineers who've built systems like these before. The architecture decisions are knowable. The data models are designable. The constraints are discoverable if you put the right people in the right place.

For twenty years, the industry treated iteration as a virtue. In reality, it was a workaround for a cost problem. AI infrastructure is solving the cost problem. The teams that recognize this are shipping production-grade systems in weeks, with data models and architectures that won't need reworking in six months.

The question isn't "Agile or Waterfall?" It never was. The real question is: given what your engineers can now execute in four weeks, is your planning keeping up?

Schedule a conversation to see how TechFabric’s forward-deployed teams plan and deliver, and what this approach could mean for your stuck initiative.

‍