What happens when AI makes Waterfall agile? 

A few weeks ago, I was sitting with one of our engineering VPs while he walked me through his workflow in Cursor. Before writing a single line of code, he spent a meaningful amount of time using Cursor to craft a feature specification, a detailed natural-language description of what he wanted to build. This included the constraints the solution needed to meet, the expected behavior at each step, and even the proposed work items to accomplish the goal. This wasn’t a single-prompt exchange, either; it took 10 exchanges over nearly 2 hours to get the specification right.  

I watched quietly for quite some time before it hit me. I had seen this before, just without the AI. It was requirements gathering. The old tradition, still alive in government contracting, where engineering spent weeks, if not months, gathering every conceivable combination of use cases to ensure the product worked exactly as expected, without fail. It was referred to as Waterfall development because the next group couldn’t start until the previous group finished their part.  

Now, the whiteboard session and the Word doc had been replaced by a prompt, but the discipline was the same. The engineer was defining intent with rigor upfront, before implementation began. 

Waterfall didn't die. It got a new interface.  

The Industry Spent Twenty Years Running From This 

To appreciate what's happening, it helps to remember why the industry ran from Waterfall in the first place. The problem was never the idea of documenting requirements. The problem was that doing it well was expensive, slow, and brittle. Writing a thorough specification took weeks. Getting stakeholders to agree on it took longer. By the time development began, the requirements were already drifting from reality. And when the market shifted mid-project, the whole structure had to be renegotiated. 

Agile didn't eliminate planning; it distributed it. Requirements became living stories, refined continuously through sprints and feedback loops. The upfront document was replaced by an ongoing conversation. "Working software over comprehensive documentation" became the industry's guiding principle, and for good reason. It worked. 

So why does it feel like we're winding the clock back?  

What Spec-Driven Development Actually Is in 2026 

The shift is subtle but significant. AI-assisted coding tools are producing better, more coherent output when developers invest time in articulating intent before they start generating code. The more structured and detailed the input, the more useful the output. Developers who resisted writing documentation for years are now willingly drafting structured specifications, not because anyone told them to, but because it makes the tool work better. 

The spec is no longer a document that lives in a wiki and gets ignored after kickoff. It is the prompt. It is the seed from which the code grows. And in that sense, it has more direct influence over the final product than any requirements document from the Waterfall era ever did. 

This is genuinely different from what came before. The cost of writing and revising a spec has collapsed dramatically. What took a team of business analysts two weeks to produce in 2004 can be drafted, refined, and versioned in an afternoon. The rigidity that made Waterfall so fragile is largely gone. Specs can be forked, regenerated, and updated in response to changing conditions without derailing a project. 

So this isn't Waterfall. But it carries a familiar risk, and the industry doesn't seem to have noticed yet.  

The Omission That Haunted Waterfall Is Back 

Waterfall's real failure wasn't the upfront planning. It was what consistently got left out of the plan. Security requirements were treated as non-functional requirements, which is a polite way of saying they were optional, underprioritized, and routinely dropped when schedules got tight. By the time a product reached testing, security was either a last-minute checklist or an unpleasant surprise. 

When I wrote about securing the Scaled Agile Framework in 2014, the core argument was that security couldn't be an afterthought bolted on at the end of the lifecycle. It had to be integrated at the requirements layer, at the design layer, at every sprint, not just reviewed before release. That argument is still correct. And now there's a new version of the same problem. 

When a developer prompts an AI to generate a specification, the AI reflects what it has been trained on. That training skews heavily toward functional requirements: what the system should do, how it should behave, what inputs and outputs are expected. Security requirements, things like threat surface identification, data classification, access control boundaries, failure modes, and abuse cases, are rarely part of the natural language prompt because most developers don't think in those terms by default. 

The spec becomes the source of truth for everything the AI generates downstream. If security intent isn't captured in the spec, it won't appear in the code. The system will be functional, well-structured, and potentially architecturally insecure, all at once. And it will have been built that way in minutes rather than months.  

The Spec as a Security Control Gate 

Here is the reframe that matters: the spec is not just a development artifact. It is the earliest available security control gate in the entire AI-assisted development lifecycle. 

This is significant because it shifts where security practitioners need to engage. In a traditional Agile model, security teams were most active during code review, penetration testing, and release gates. Those touchpoints still matter, but they are too late in an AI-assisted workflow. By the time a security engineer reviews a PR, the architecture has already been shaped by a spec that may never have considered a threat model. 

A security-aware spec should establish the threat surface early, identify which data the system touches and how sensitive it is, explicitly define authentication and authorization assumptions, and include failure scenarios and abuse cases alongside the happy path. None of this is new thinking; it is standard threat modeling practice. What is new is the leverage. A well-constructed spec now influences not just a design document but the actual code that gets generated from it. 

The role of the security practitioner in this environment needs to evolve accordingly. Reviewing the spec is as important as reviewing the code, perhaps more so, because the spec is where intent is set and where the most expensive mistakes are cheapest to fix. 

What Good Looks Like 

None of this requires slowing down. The speed advantage of AI-assisted development is real, and the goal is to be intentional about what goes into the spec so that what comes out is defensible, not just to recreate the bureaucracy of Waterfall with an AI veneer. 

A few practical starting points worth considering:  

1. Establish a security requirements template to incorporate as context or directly in prompts during spec generation.  
   In practice: We typically store this context as markdown files we include in new projects.  
2. Include abuse cases and known threat scenarios alongside functional use cases.  
   In practice: While this can feel like an ever-growing registry of potential vectors as you document them, you can feed your threat list back into the same spec prompt and ask the AI to prioritize by relevance to the system being built. 
3. Treat the AI-generated spec as a first draft rather than a final authority, applying human security context before moving forward.  
   In practice: This step is crucial; you can’t blame the AI for its mistakes; you are the driver; you are responsible for its results.  
4. Gate AI-generated code on a spec review that includes at least a lightweight security check. 
   In practice: This should be standard for all code, AI-generated or not. It becomes more important here, as the ease with which AI generates clean, coherent code creates a false sense of security.  

The teams that will move fastest in the long run are not the ones who skip this step. They are the ones who integrate it early enough that it costs almost nothing.  

Closing Thought: Intent-First Development, Security-First Intent 

The return of the spec is an opportunity. The industry shouldn't treat it as a regression or dismiss it as Waterfall nostalgia. Intent-first development, done well, is a meaningful maturity step. It forces clarity before complexity, and that is almost always a good thing. 

But Waterfall's legacy is a cautionary tale about what happens when rigor is applied selectively. Requirements were thorough. Security was not. The result was software that did exactly what it was designed to do, just not safely. 

We have a chance to break that pattern this time. The spec is back. The question is whether we're going to write a better one.