RAD's ~34-Year-Old Playbook for AI Coding

In 1982, a computer scientist named James Martin published a book called Application Development Without Programmers. The title reads less like a historical artifact and more like a pitch deck someone submitted to a VC last Tuesday.

Martin went on to formalize the ideas in that book into an actual software development methodology in 1991. He called it Rapid Application Development — RAD — and it was built around a then-radical premise: stop planning everything to death before you write a single line of code. Get something in front of users fast, let their reactions reshape the thing, and iterate your way to a real product. IBM's Martin Keen recently made the case, in a video for IBM Technology, that this ~34-year-old framework maps onto AI-assisted development almost perfectly. The argument is more interesting than the premise sounds, and the part where it breaks down is the most interesting bit of all.

Four Phases That Have Aged Surprisingly Well

RAD runs in four stages. Phase one: lightweight requirements planning. Not a hundred-page spec — just enough to define the problem, the users, the features you want, and the constraints you're working within. The philosophy behind keeping it light is almost Socratic: users don't actually know what they want until they can see something and react to it. So stop trying to predict their preferences in a vacuum.

Phase two: user design. A team builds a clickable prototype — something real people can actually interact with — and puts it in front of those real people as fast as possible. Bad assumptions surface early, while they're still cheap to fix. The prototype isn't a throwaway mockup, either. In RAD, it's a keeper. You keep building on it until it becomes the actual product.

Phase three is construction: building out the real functionality in short cycles, with testing and feedback happening continuously. And phase four — cutover — is deployment, data migration, and getting users trained on the finished thing.

Keen describes Martin's original ambition as "small teams delivering working systems in time boxes of roughly 90 days," which was borderline radical in an era when typical corporate software projects ran for years.

Here's the thing: that framework almost exactly describes what happens when someone vibe codes an app with an AI agent today. You type a prompt — the lightweight requirements document. The agent generates a working prototype in minutes. Users click through it, complain that the approval screen is confusing or that the purple background looks like AI slop, the feedback goes back to the agent, and the agent regenerates. Construction is already happening in the background as the agent wires up data schemas, workflow logic, email notifications. And eventually, someone senior looks at the demo and asks when the whole company can have it.

Why RAD Faded (And Why That's Complicated)

If this methodology was so sensible, why wasn't everyone using it? Keen's answer is that the code-generation tools of RAD's era — the computer-aided software engineering tools that were supposed to be its engine — couldn't produce anything sophisticated enough to be genuinely useful. That's one credible reading. But it's worth flagging that it's not the only one. The early 2000s brought Agile, Scrum, and Extreme Programming, frameworks that absorbed many of RAD's core instincts — iteration, continuous feedback, short cycles — while solving some of its organizational problems. RAD may have faded partly because better-operationalized successors swallowed its best ideas. The history is messier than any single explanation covers.

What's different now is the prototyping speed. Agile still assumes developers are doing the coding; RAD's original promise was that the tools would do it. AI agents are the first technology that's actually made good on that promise at a meaningful level of sophistication. The bottleneck that originally sank RAD has, more or less, been removed.

The Part Where the Prototype Lies to You

This is where it gets genuinely interesting — and where I want to linger, because the failure mode here is specific and it stings in a particular way.

Keen's example: an AI-generated expense approval app. The demo looks great. The finance team loves it. Someone asks when they can ship it. And then someone else asks a question that the prototype's happy path never surfaced: what stops an employee from approving their own expenses?

Nobody's prompt said they couldn't. So the agent never wrote a rule requiring a second sign-off. A $900 expense, filed and approved by the same person. Keen's delivery on this — "Delightful." — is pitch-perfect. It's funny until it isn't.

Here's the thing about that gap, though: it doesn't announce itself. The prototype works. It does what you asked it to do. The problem isn't what's broken; it's what's missing. And what's missing doesn't show up in a demo because you can't click on a rule that was never written.

I've spent enough time sitting with AI-generated prototypes — including a content-tagging tool I had a coding agent spin up for internal use, which worked beautifully in testing and turned out to have no meaningful permissions logic whatsoever — to know this feeling intimately: the thing looks done, and it is done, and it is also missing something you didn't think to want until someone asked an obvious question you hadn't asked. The prototype didn't fail. It succeeded at exactly what you specified. The specification was the problem.

That's not a small distinction. It changes what "done" means.

The Spec Is the Actual Product

James Martin's original RAD framework, Keen points out, always had two halves: a precise description of what the system needed to do, and the code that got generated from that description. In the original CASE tool era, an analyst fed the generator a spec — data models, business rules, acceptance criteria — and the tool produced code from it. The spec was the control.

AI agents have rebuilt the code-generation half of that equation at a scale Martin couldn't have imagined. But the description half — the spec — is what the vibe coding movement tends to skip. The prompt is not the spec. The prompt gets you to the prototype. The spec is what you write after the prototype has taught you things, capturing the business rules the agent didn't know to implement and the security requirements that don't surface in demos.

This is what spec-driven development actually means in this context: treating the prototype as a learning instrument rather than a finished product, and documenting what you learned in a form that can be tested against. Once "nobody can approve their own expenses" is in the spec, it becomes a test. The generated code either passes it or it doesn't.

This doesn't make vibe coding a bad idea. It makes the spec the thing that turns vibe coding into something you can actually ship. Keen's framing is clean: "What actually goes into production is everything the prototype taught us, which is captured in that spec."

The programmer's job didn't disappear. It relocated. Specification writing and verification are not lesser activities than implementation — they're just different ones. Whether that reallocation is good for the people who used to do implementation is a separate and genuinely open question.

What RAD Got Right Before the Tools Did

Keen closes with Martin's 1982 title — Application Development Without Programmers — and offers a dry verdict: "That particular request is still waiting on its second sign-off because the programmers, they are still very much here. They've just moved in the direction of writing the spec and verifying the result."

That's a tidy ending. Maybe a little too tidy. The more unsettled version of this story is that spec-writing and verification are skills that have to be developed and taught and valued organizationally, and right now the loudest part of the vibe coding discourse is about how fast you can skip to the prototype. RAD's framework has held up — plan lightly, prototype early, build in short cycles, verify before you ship — but frameworks only hold up when the people using them understand why each phase exists.

The phase people are currently most tempted to skip is the one that matters most. That's not new. It wasn't new in 1991, either.

---

Yuki Okonkwo is Buzzrag's AI & Machine Learning correspondent.