Software Development Methodologies in the AI Era: Where Spec-Driven Fits

Every list of software development methodologies you can find right now was written for a world that no longer exists. Search the term and you get the same eight entries in a slightly different order: Waterfall, Agile, Scrum, Kanban, Lean, Feature-Driven Development, DevOps, Spiral. Solid history. None of it accounts for the single biggest change to how software gets built in twenty years.

The methodologies were all designed to answer one question: how do humans coordinate the work of writing code? That question is quietly becoming the wrong one. When an agent writes most of the code, coordinating humans matters less than telling the agent what to build and proving it did. The methodology question moved, and the listicles didn't follow it.

Here is the hypothesis worth testing: every methodology in the canon is an answer to "how do we manage the people writing the code," and the AI era introduces a methodology that answers a different question entirely, namely "what does the agent build against, and how do you know it's done." Spec-driven development is not the ninth item on the list. It is a different kind of item.

#A Short, Honest History of the Methodologies

Take the canon seriously before you argue with it, because each entry solved a real problem of its time.

Waterfall came first because hardware was expensive and changes were catastrophic. You gathered every requirement up front, designed the whole system, built it, tested it, then shipped, each phase finishing before the next began. It gets mocked now, but it was rational when a mistake meant re-cutting tape. Its weakness is obvious in hindsight: it assumes you know everything before you start, and you never do.

Agile was the rebellion against that assumption. The 2001 manifesto valued working software over comprehensive documentation and responding to change over following a plan. Scrum and Kanban are the two most common ways teams actually run Agile: Scrum boxes work into fixed sprints with defined roles, Kanban runs a continuous flow with limits on how much is in progress at once. Lean borrowed from Toyota's factory floor, eliminating waste and deferring decisions until the last responsible moment.

Feature-Driven Development (still a low-difficulty search term, which tells you it never died) organizes everything around a list of small, client-valued features you build one at a time. DevOps collapsed the wall between building software and running it, so the team that writes the code also owns the deploy. Spiral wrapped the whole thing in repeated risk assessment for projects too large to fail.

Strip away the vocabulary and a pattern shows up. Every one of these is a coordination protocol. Who does what, in what order, with what handoffs, reviewed by whom. They differ on how sequential the phases are and how much ceremony surrounds them, but they share an unspoken premise: the scarce, expensive, error-prone resource is the humans writing the code, so the methodology exists to organize those humans.

That premise held for fifty years. It is the part that broke.

#What Actually Changed

The scarce resource moved. Writing code is no longer the bottleneck, and the people noticing it are not marketers.

Across r/cscareers and r/dataengineering the same line keeps surfacing, said with a mix of awe and grief: "software is now disposable." One engineer in the same thread put the new shape of the work precisely:

"The big picture creative, architectural decisions is what AI excels at. You can regenerate 10 plans in a matter of seconds and pick the best parts of them. AI's weakness is getting details right, making lots of little mistakes."

Read that carefully, because it inverts the entire premise of the canon. The expensive part used to be producing the code. Now you can regenerate ten attempts in the time it takes to read this paragraph. The expensive part is deciding which one is right and confirming it actually works. The bottleneck moved from typing to judgment.

This is why a coordination protocol, on its own, no longer answers the whole question. Scrum can tell you whose sprint a feature belongs to. It cannot tell an agent what "done" means for that feature, and it cannot check the agent's output against your intent. The old methodologies assumed a human on the other end who already knew what good looked like and would catch the mistakes by hand. Hand the same vague ticket to an agent and it will produce something that compiles, demos, and is subtly wrong in a way no sane human would have written. The ceremony around the work is intact. The thing being coordinated changed underneath it.

#The Methodology the Canon Is Missing

Here is the reframe. Spec-driven development is not a better way to coordinate people. It is a way to make intent legible to a machine that will build against it and be checked against it.

A spec-driven approach answers the two questions the older methodologies never had to: what exactly should the agent build, and how will you know it succeeded. The first is a requirement with enough precision that an agent cannot wander, including the edge cases, the data shape, and the constraints. The second is a set of acceptance criteria, written before the build, that define done as something you can verify rather than something you eyeball.

The difference is concrete. Watch what happens to the same feature under the old frame and the new one.

Agile ticket: "As a user, I want to reset my password so that I can regain access to my account." (Estimated: 3 points. Assigned to a sprint.)

Spec with acceptance criteria: "Authenticated and unauthenticated users can request a reset from /login. The system sends a single-use token valid for 30 minutes. Reused or expired tokens show 'This link has expired, request a new one.' On success, all existing sessions are invalidated and the user is redirected to /login with a confirmation banner. Rate limit: 3 requests per email per hour."

The Agile ticket is a coordination artifact. It tells a human which sprint the work lives in and roughly how big it is, then trusts that human to fill in everything that matters. The spec is a build-and-verify artifact. It tells an agent precisely what to construct and gives you a checklist to confirm it did. One organizes people. The other defines done.

Notice what spec-driven development does not replace. You still need Agile's iteration, DevOps's ownership of the deploy, Kanban's limit on work in progress. Spec-driven development is not a rival coordination protocol. It is the missing layer underneath whichever one you already use, the part that survives when the agent, not the engineer, is holding the keyboard. It is also the foundation of what people are starting to call agentic engineering: the practice of running agents against a written standard instead of supervising them line by line.

This is the gap BrainGrid was built to close. You describe the feature you want, and the Planning Agent turns it into a requirement with explicit acceptance criteria, asking the questions you didn't think to answer before any code is written. The Builder Agent then builds against that spec, in BrainGrid Cloud or in your own GitHub repo with Claude Code, Cursor, or Codex over MCP. Nothing is marked done until every criterion is verified with evidence. The loop is Plan, Build, Verify, Repeat, and it runs the same way for every feature. You can't verify if you don't have a plan.

#Why the Spec Outlives the Method

The deeper reason spec-driven development belongs on the list is that it changes which artifact is durable.

In the Waterfall era, the durable artifact was the code, and a thick requirements document that mostly went stale on a shelf. In the Agile era, the durable artifact was still the code, plus a backlog of tickets that meant little once closed. In the AI era, the code is the cheap, regenerable, partly-disposable part. The plan and the acceptance criteria are the thing that lasts. They are what let you regenerate the code next month against a better model and still know it does what you intended. They are the record that explains, six months from now, why the system behaves the way it does, when nobody, human or agent, can reconstruct it from the source alone.

That is the test of a real methodology in this era: does it produce an artifact that survives the code? Waterfall's spec was too rigid and too early. Agile threw out the comprehensive document for good reasons that no longer fully apply. Spec-driven development keeps the precision Waterfall wanted and the iteration Agile won, and attaches it to the one thing the older methods treated as disposable: a written, verifiable definition of what you are building and what done means.

Be honest about the trade-off, though. Spec-driven development front-loads work that vibe coding skips entirely. If you are throwing together a weekend prototype or a single-use internal script, writing acceptance criteria first is overkill, and you should just build. The discipline earns its keep the moment the software starts to matter, the moment other people depend on it, the moment "it demos fine" stops being good enough. Vibe tools are fast until your app matters. That is the line where the methodology question becomes real again.

#FAQ

#What are the five software development methodologies?

The five most commonly cited are Waterfall, Agile, Spiral, Rapid Application Development, and Incremental (sometimes listed as iterative). They differ mainly in how sequential versus iterative the phases are: Waterfall finishes each phase before the next, while Agile and incremental approaches build and refine in repeated cycles. Spec-driven development is a newer addition that sits underneath whichever of these you use, defining what the code should do and how to verify it.

#What is a methodology in software development?

A software development methodology is a structured approach for planning, managing, and executing the work of building software. It defines the phases, the order they happen in, who is responsible for what, and how the team handles change. Most classic methodologies were designed to coordinate the humans writing the code. Spec-driven development extends that idea to the AI era by defining what an agent should build and how you confirm it succeeded.

#What are the 7 models of the SDLC?

The software development lifecycle (SDLC) is commonly described with seven models: Waterfall, V-model, Agile, Lean, Iterative, Spiral, and Big Bang. Some lists add Rapid Application Development as well. These are templates for sequencing the lifecycle phases, planning, design, development, testing, deployment, and maintenance, with each model trading off predictability against flexibility.

#What are the four types of Agile methodology?

The four most common Agile frameworks are Scrum, Kanban, Extreme Programming (XP), and Lean. Scrum organizes work into fixed-length sprints, Kanban runs a continuous flow with work-in-progress limits, XP emphasizes engineering practices like pair programming and test-first development, and Lean focuses on eliminating waste. All four share the goal of delivering value iteratively rather than in one large release.

#Where does spec-driven development fit among these methodologies?

Spec-driven development is not a replacement for Agile, Scrum, or DevOps. It is a layer underneath them. The older methodologies coordinate the people doing the work; spec-driven development defines what the agent builds against and how you verify it is done. You keep your existing coordination method and add a precise spec with acceptance criteria for each feature, which is what survives when an agent, not a human, writes most of the code.

BrainGrid is the plan-first app-building platform that plans before it builds, then proves every change against its acceptance criteria. Try it at braingrid.ai.