Spec-driven development, or SDD, is not new. But it has recently come back into focus because of agentic programming. A good place to start is Martin Fowler’s website, Understanding Spec-Driven Development.
The core problem with agentic coding, or vibe coding if you prefer, is simple: AI can generate code faster than humans can responsibly review it. The amount of code becomes so high that the human developer turns into the bottleneck.
That is the polite version.
The more honest version is this: knowing our industry, a huge percentage of AI-generated code will probably go into production without proper review. People already approve pull requests without reading them carefully. Now imagine the PR is thousands of lines of code that nobody fully understands. We can tell developers, “You are responsible for this code,” and that is true. But in practice, many people will still trust the AI, run the tests, see that the app works, and move on.
Well, that is a problem.
The industry is changing. The forging power press is here, and nobody is going back to the hammer. So we need to investigate new processes that can help us guarantee product quality in a world where code is generated, regenerated, and sometimes barely read by humans.
What if the code is no longer the asset?
Do not panic. There is a good chance you already do not read all the code anyway. But for the sake of keeping face, let us say you are among the faithful 20% who carefully read every line, understand every implication, and fix everything before it gets merged.
Now think about compilation. When you compile your code, do you read the generated assembly?
Of course not.
You trust that the compiler generated what you asked for. If there is a bug, you normally do not fix the assembly. You fix your source code.
This is one direction the industry is exploring now: maybe application code becomes less like the source of truth and more like a generated artifact. The real asset becomes the specification, architecture, tests, constraints, and product intent. Code becomes a byproduct, much like assembly became a byproduct of source code.
The idea behind SDD is to write specs that are good and detailed enough that if you generate the codebase ten times, all ten attempts should result in a working product that follows the same intent.
The process is almost brutal: generate the codebase, or a chunk of it. If it is not good, delete it, improve the specs, and generate again.
This idea builds on the fact that LLM usage has been relatively cheap, and that generating an entire SaaS product can take a few hours of straight agentic work. That changes how we think about iteration.
Enter the Ralph Wiggum loop
The next question is obvious: how do you turn specs into code in a few hours?
One methodology people have been discussing recently is the “Ralph Wiggum loop”. It got more attention after Claude Code added a plugin for it, and after it appeared in the GitHub Copilot cookbook.
You can read Geoffrey Huntley’s explanation in his blog post, but the simple version is this: instead of asking an agent to do everything in one long session, you put the agent in a loop.
Why?
Because if you ask an agent to do too much at once, it eventually starts losing the important parts of the original prompt. The context fills up with files it generated, files it read, failed attempts, test output, and other noise. This is often called context rot.
The Ralph loop tries to keep the agent fresh by repeatedly starting from the same prompt. Each run reads the current state, picks one task, does it, commits it, and stops. Then the next run starts again.
I use opencode, so a very simple loop could look like this:
while true; do
cat prompt.md | opencode run --dangerously-skip-permissions
doneIn this example:
cat prompt.md | opencode runruns the prompt, and:
--dangerously-skip-permissionstells the agent that it can access everything it needs, such as search, Bash, and other tools.
A very simple prompt could look like this:
Goal:
Build the product described in /specs/index.md
Rules:
- Read index.md, architecture.md, and the codebase.
- Pick exactly one unfinished task.
- Implement it completely.
- Run relevant tests and linters.
- Fix failures.
- Commit your changes with a clear message.
- Stop.This basic version does not work perfectly, though. You need to get creative.
For example, you might alternate between a planning mode and a build mode, possibly using different models. You might keep a state file and a plan file. You might add stricter rules for testing, architecture, commit style, or task selection. You play with the loop until it works well for your codebase.
In a way, this is similar to how a human developer works. You pick something to do, plan it, build it, fix the errors, and commit. The difference is that in the Ralph loop there is no human testing each step and no CI checks before commit. There is a spoonful of positive-thinking sugar in it: you hope the agent is doing a good job – that’s why its called after Ralph Wiggum. But if it does not, the answer is not necessarily to fix the generated code manually. The SDD answer is to fix your specs. Tighten your acceptance criteria. Add more architecture. Improve the prompt. Then run again.
The software engineer’s job is moving up the stack
In the coming era, a software engineer’s job may be less about writing code line by line and more about writing documents, specs, architecture, constraints, test criteria, and quality gates.
And, honestly, you do not necessarily need to be a software engineer to do some of that.
In the long term, we may see software engineers creating templates for architecture, security, code quality, observability, integration tests, and business rules. These templates could help business people generate their own internal software. The industry may change in a way where hand-writing code becomes a niche job for very specific cases: embedded systems, performance-critical systems, security-sensitive systems, rocket science, and the kind of work where every detail still matters deeply.
Think about knife making. There are still blacksmiths and custom knife makers. But most kitchen knives are mass-produced. You buy one from IKEA. It does the job at a fraction of the price.
You get the idea.
The good
The good part is that we are finally admitting there is a real problem.
We cannot simply expect programmers to reliably read, understand, and fix huge amounts of AI-generated code. Please do not misunderstand me: I am not encouraging people to generate large amounts of code they do not understand at work. I still strongly believe we should keep AI-generated changes small enough that we can understand and review them properly.
But SDD and the Ralph loop open the door to experimenting with a different future, especially in side projects, prototypes, and internal tools.
And if you are skeptical, I understand. But this stuff does work in surprising ways.
The other day, my neighbor showed me a fully fledged internal platform he had built for around 50 people. It handled quite a lot: login, SMS, workflows, and more. I asked him what language it was written in. He said, “I’m not sure, maybe Python or PHP. Claude Code made a zip file, and I uploaded it to my hosting.”
Was it secure from a software-security point of view? I doubt it.
Can the 5,000-line codebase grow in a healthy way? I really doubt that.
Is performance good? Will it scale? Almost certainly not.
But it is proof that with good tooling, a non-programmer can already build useful software, at least for internal use. That is a big deal.
The bad
There is one small problem: for this to work well, specs need to be AI-friendly.
Let me rewind a little.
You are not necessarily supposed to write all the specs manually. You may have a special agent that writes specs for you. It can look at existing specs, technical documents, the current codebase, and related architecture, then generate a code-aware specification.
A good code-aware spec is precise. It helps the planning phase. It tells the agent what tasks should be done, what tests should be written, what systems are related, and what constraints matter.
Here is an example of such an agent from GitHub’s Awesome Copilot repository: awesome Copilot specification agent.
The problem is that specs generated this way can easily become 500 lines or more.
Now imagine a developer sitting down and reading all those specs word by word. That is not realistic either.
The idea I am playing with is a spec format that starts with an executive summary for developers, then continues with detailed sections for agents. Developers should still skim the whole document, but they need a fast way to understand the intent, the constraints, and the risks.
Actually, this is already one of the skills experienced software engineers have: reading documents quickly, finding the important parts, and understanding what matters. We should use that skill instead of pretending everyone will read every generated line with equal attention.
The ugly
The whole thing is promising, but it is not a silver bullet. In fact, it is still far from being a reliable default way of building software.
The hype reminds me of the hype around Docker, microservices, Kubernetes, and recently MCP servers for everything. These technologies are useful, but when the dust settles, they are usually useful for specific cases and specific users. They are not magic.
Going back to the knife-making example, we are still at the early automated-hammer stage. The machine can produce something that looks like a product, and sometimes it is useful. But it is not yet the kind of machine you blindly trust to mass production .
Still, I think the most important lesson is this: code itself may not be the main asset anymore. I wrote about this in another post, Code Is Worthless, Senior Developers Are Priceless.
Problems that are already visible
Some problems with the basic Ralph loop have already surfaced.
First, context rot is real, but agentic tools are also getting smarter at handling context. They summarize, compress, and use different techniques for memory. Some tools are trying to preserve high-level decisions, architecture, and original intent so the whole team can work from the same understanding.
Second, the idea depends partly on LLM usage being cheap. The free-trial era is ending. Major Western LLM providers are increasing prices or tightening limits. In practice, some large companies have been subsidizing our usage, and eventually they will want their money back.
The alternative is often cheaper Chinese LLMs, but that may only stay cheap until they win enough of the market. Betting on permanently cheap inference is not a strategy I would trust blindly.
Third, input-context caching matters. Most major LLM providers now support some form of context caching, which can reduce cost. But depending on your tools, a Ralph loop may not use caching efficiently. You might end up paying for the same codebase context again and again. Over time, that cost will be felt.
TL;DR (Yes, it got long!)
Spec-driven development is probably part of the way forward.
Software engineering is shifting dramatically. Coding may become a more niche skill, while specs, architecture, criteria, testing, and quality gates become more important.
We will probably see more small internal software built by business people. Some of it will be useful. Some of it will be functional enough. Some of it will be unsafe, fragile, and hard to maintain.
The Ralph loop is a smart innovation, and there is a lot to build on top of it before it becomes something we can safely use in daily professional work.
For now, as software developers, we should still generate small changes that we understand and can review. The future may be one where code is treated more like assembly: generated, trusted, and rarely inspected directly. But we are not fully there yet.
Until then, specs are becoming more important, code is becoming cheaper, and senior judgment is becoming more valuable than ever.