RAD and AI Coding Agents: Why Fast Prototypes Fail at the Cutover

In 1982, a computer scientist named James Martin published a book with a title that could pass for a headline today: Application Development Without Programmers. Nine years later he turned that idea into a formal methodology, Rapid Application Development ( RAD ), built around a simple bet: users don’t know what they want until they can click on something real.

That bet is exactly what happens every time someone describes an app to an AI coding agent and watches a working version appear in minutes. The tools changed. The underlying problem, how do you get from “here’s roughly what I want” to software you can trust in production, did not.

RAD, a methodology formalized more than three decades ago that many developers now encounter mainly as historical context, turns out to be a surprisingly good map for it.

This article walks through what RAD actually says, where it maps cleanly onto agentic coding, where the mapping breaks in a way that matters, and what the current research and vendor data actually support versus what they don’t.

What Rapid Application Development (RAD) Actually Is

James Martin's 1982 book argued that the growing backlog of business software requests couldn't be cleared with the programming languages and processes of the time, and that development had to move away from a small number of specialist programmers doing everything by hand. He turned that argument into a formal methodology in his 1991 book, Rapid Application Development, published while he was working at IBM.

IBM's current explainer on the methodology describes RAD as prioritizing speed and iterative development over the long, document-heavy planning phases that waterfall projects required, with prototypes that are tested continuously and often evolve directly into the shipped product.

Waterfall assumes you can specify a system correctly on paper before building it. RAD assumes the opposite: most users can't fully articulate what they want until they can react to something tangible, so the fastest path to the right system is to build a rough version quickly and let real feedback shape it.

RAD's four phases

Martin's model runs in four stages, and the terminology has stayed remarkably consistent across three and a half decades of use:

The distinctive part of the classic Martin-style RAD model isn't the phase names, most methodologies have some version of plan, build, test, ship. It's the emphasis on treating the prototype as something to build from, rather than a throwaway mockup. IBM describes the prototype as something that often evolves directly into the final product, though the exact practice varies by project, and RAD projects are typically organized around short, timeboxed delivery cycles.

RAD never became the industry's only dominant approach, partly because the computer-aided software engineering (CASE) tools of the 1980s and 1990s couldn't turn a lightweight description into a sophisticated application on their own. That specific limitation has changed: AI coding agents can generate functional software from natural-language direction. Whether the result is production-ready is a separate question, and it's the one this article is about.

RAD's core trade-offs, in short:

Why RAD's Logic Is Back

Today you can describe an app to an AI coding agent in a chat window and watch a functional version appear in minutes. Practitioners call some forms of this "vibe coding," and the speed makes RAD's founding assumption, build something real, then learn from how people react to it, much cheaper to act on. The resulting software still needs review and verification before it handles real users or real data.

RAD's four-phase structure gives a useful lens for comparing classic iterative development with an AI-agent workflow:

As coding agents navigate larger multi-file projects, managing what enters the context window becomes critical. Rather than pasting entire directories into prompts, modern agent harnesses treat the codebase as an external environment. Read our analysis on Recursive Language Models and agent context routing to see how agents inspect large repositories programmatically.

The first three phases map closely onto common AI-assisted workflows. The prompt functions as the lightweight requirements pass RAD calls for. The agent's first draft is the clickable prototype. Iteration happens through the same conversational loop RAD describes: feedback goes back to the builder, and the builder, human team or AI agent, regenerates. Cutover is where the analogy gets interesting, because it's also where it gets dangerous.

The Expense-Approval Problem: Why "It Works" Isn't Evidence

Picture a common vibe-coding demo: someone on a finance team describes an expense-approval app to an AI agent, who submits requests, who approves them, what the rules are. In RAD terms, that's the requirements-planning prompt.

The agent generates a working prototype. People click through it, complain the layout is confusing, and the agent iterates. Eventually someone senior asks the obvious question: this works, so when does the whole company get it?

Say nobody's prompt ever specified that an employee can't approve their own expense report. There's a real chance the agent never wrote that rule, which means an employee could file a $900 expense and approve it themselves.

Nobody using the clickable prototype would discover this by clicking around, because you can't click on a rule that was never written. The interface can look complete even when the authorization logic is incomplete.

This is a specific, illustrative example, not a documented incident, but it points at a broader and well-evidenced pattern: functional behavior and security requirements diverge. Veracode's 2025 GenAI Code Security Report tested more than 100 large language models across 80-plus coding tasks in Java, JavaScript, Python, and C#, generating code with no security-specific guidance.

It found a detectable OWASP Top 10 vulnerability in 45% of those tasks, with Java the weakest performer at a 72% security failure rate. A Veracode Spring 2026 update re-ran the same testing framework on newer flagship models and found the pattern hadn't moved: syntax pass rates had climbed from around 50% to over 95% since 2023, while security pass rates stayed flat, hovering between 45% and 55% regardless of model generation or release date.

Bigger, newer models wrote code that compiled more reliably in Veracode's tests. The benchmark didn't show a comparable default improvement in security. Practitioner accounts point at the same gap from a different angle: a Reddit thread in r/AI_Agents describes a developer who reported spending roughly $4,000 on AI-assisted coding only to find, once the app reached production, that OAuth edge cases, timezone-sensitive data migrations, missing database indexes, and weak staging parity had all been invisible during development testing.

That's one person's account of one project, not a benchmark, but the specific failure list is a useful checklist of exactly the kind of thing a demo doesn't exercise.

Prototype evidence vs. production evidence

The core mistake teams make is treating "the prototype works" as evidence for questions it was never designed to answer. These are different kinds of testing, and passing one says nothing about the others:

A prototype that passes every click-through test tells you the happy path works. It tells you nothing about the rules nobody thought to state out loud.

One more category belongs on that list, and it's specific to AI-generated code rather than to AI-generated business logic: hallucinated dependencies. Coding models sometimes invent a package name that sounds plausible but doesn't exist, and an attacker can register that exact name on a public registry ahead of time, a technique researchers call slopsquatting.

A USENIX Security 2025 study that generated 2.23 million code samples across 16 code-generating models found roughly 19.7% contained at least one hallucinated package name; a 2026 replication on newer frontier models found the per-model rate had narrowed but was still running at roughly 4.6% to 6.1%, with a set of package names hallucinated consistently enough across different models to make them a predictable, repeatable attack target.

A prototype that runs locally proves nothing about this risk, because the demo either already has the real package cached or fails loudly with "module not found", it doesn't tell you whether every import in the lockfile is a package that legitimately belongs to the maintainer you think published it. That's a dependency-integrity check, not a functional test, and it belongs in the cutover gate, not the demo review.

What the Evidence Actually Shows About Speed and Quality

It's tempting to reach for a single number,  "AI coding agents are 10x faster" or "AI code is unsafe", and stop there. The current research doesn't support either as a settled fact.

Adoption is genuinely high. Stack Overflow's 2025 Developer Survey reports that 84% of respondents are using or planning to use AI tools in their development work, with 51% of professional developers using them daily.

But the same survey reports a trust gap sitting right next to that adoption: 46% of respondents said they distrust the accuracy of AI tool output, versus 33% who trust it, and only 3% report high trust. Widespread use and low confidence in the output are coexisting, not contradicting each other, developers are using the tools and still checking their work.

A 2026 academic study gives a more precise, if narrower, picture of what "faster" costs. Agarwal, He, and Vasilescu's study, presented at the Mining Software Repositories conference, used a staggered difference-in-differences design on open-source repositories to measure what happened after teams' first agent-generated pull requests.

The reported headline: velocity gains were large but front-loaded, appearing mainly when the agent was the team's first observable AI tool, while static-analysis warnings and cognitive complexity in the affected code rose by roughly 18% and 39% respectively.

That's one study's abstract-level finding on open-source repositories with a specific causal design, not a universal multiplier, but it's a rare piece of evidence that isolates a real trade-off: speed now, quality debt later, unless something catches it.

A broader 2026 review reaches a similar conclusion from a different angle. Michels et al.'s state-of-the-art review of vibe coding synthesizes findings across software engineering, security, and labor-economics research and reports that productivity results vary significantly depending on how they're measured and what task is being measured, with some evidence that gains are larger on new code and shrink, or reverse on mature, complex codebases.

That lines up with what practitioners describe informally: agents perform well on small, disposable, greenfield components and struggle to hold architectural context in large, tangled systems where a wrong refactor is expensive to unwind.

None of this is a case against AI coding agents. It's the same lesson RAD tried to teach in 1991: a demo that works is proof the happy path exists, not proof the system is done, and now there's research literature, not just intuition, backing that up.

Spec-Driven Development: RAD's Missing Verification Layer

A useful way to read the RAD model is as two complementary halves. The first is a precise description of what the system needs to do, the data model, the business rules, the constraints. The second is the tooling and process that turns that description into working code.

AI coding agents address the second half, the historical bottleneck that limited 1990s CASE tools, but they don't remove the need for the first half. Their speed makes it easier to see how thin that first half typically is in a chat-driven session: a prompt is not a specification.

Spec-driven development (SDD) is a family of practices for writing that first half down explicitly, as a structured artifact rather than a one-time prompt, before or alongside generation. Microsoft's engineering blog frames it as making a structured specification a shared source of truth for both the human team and the AI agent, aimed at reducing the "translation loss" that happens between a stakeholder's intent, a written requirement, an architectural decision, and the code that finally ships.

GitHub's open-source Spec Kit, published in September 2025, operationalizes this with a /specify → /plan → /tasks → /implement sequence instead of open-ended chat-based coding; as of mid-2026 the project's own documentation states it works with 30-plus AI coding-agent integrations, including GitHub Copilot, Claude Code, and Gemini CLI.

The mechanism that matters for the expense-approval example is simple: discoveries from the prototype get written down as explicit requirements, business rules, and acceptance criteria,  including the rule nobody thought to click on, like "no one approves their own expense.

" Once "an employee cannot approve their own expense" is written into a spec, a reviewer has something concrete to check the code against, and it becomes a test the generated code has to pass before cutover.

This is also where "the prototype is a keeper" needs a small but important correction for the AI era. The prototype is still one of the fastest ways to discover what a system actually needs to do.

But what goes into production shouldn't be assumed to be the prototype itself, it should be the verified system that incorporates what the prototype taught the team, with the important discoveries captured as requirements and tests before cutover.

How much of your codebase should the spec actually control — and when is it overkill?

Not every team means the same thing by "spec-driven development," and the difference matters for how much discipline it costs you. Thoughtworks' Birgitta Böckeler, evaluating three SDD tools, Kiro, GitHub's Spec Kit, and Tessl, for martinfowler.com, identified three levels of commitment that shouldn't be conflated:

Böckeler's evaluation found Kiro and Spec Kit sit closer to spec-first in practice, generating substantial upfront documentation for every task regardless of size, while Tessl was the tool explicitly built for spec-anchored and spec-as-source workflows.

Her review also raised a specific, practical caution worth carrying into any SDD adoption: on a small bug fix, the tooling produced a full set of user stories and acceptance criteria that were disproportionate to the change, creating review overhead and, in her words, a false sense of control rather than genuine risk reduction.

That's a direct parallel to the article's central warning about the expense-approval example, just pointed in the opposite direction, a process can also fail by treating a one-line fix like a regulated feature.

The practical reading: SDD is not free, and it's not meant to wrap every change. It earns its overhead on features with real business rules, security implications, or multiple stakeholders, not on a typo fix or a CSS tweak.

Acceptance criteria are what make a spec testable instead of merely descriptive. The most common format, borrowed from behavior-driven development, is GIVEN/WHEN/THEN: given the system is in some state, when an action happens, then a specific, checkable outcome must follow.

For the expense-approval example: given an employee has submitted their own expense report, when they attempt to approve it, then the system must reject the approval and log the attempt. Written this way, the rule stops being an assumption and becomes something a test suite can enforce before cutover.

# Feature Spec: Expense Approval Workflow ## Business Rules & Security Constraints - [REQ-01] Self-approval is strictly forbidden. - [REQ-02] Amounts > $500 require dual managerial sign-off. ## Acceptance Criteria GIVEN an employee submits their own expense report WHEN they attempt to trigger the approval action THEN the system must reject the request AND log the unauthorized attempt in the audit log.

The illustrative HTTP 403 response and audit-log behavior above are one reasonable implementation choice, not a universal standard, the exact response code and logging format should match your team's existing API conventions.

A spec only closes the gap if it turns into something that actually blocks a bad build. REQ-01 from the spec above translates directly into an automated test that fails the pipeline if the agent, or a human ever reintroduces the bug:

// test/expense-approval.test.ts describe('Feature: Expense Approval Workflow', () => { it('REQ-01: should forbid self-approval and return 403', async () => { const response = await request(app) .post('/api/expenses/123/approve') .set('Authorization', `Bearer ${employeeToken}`) // same user who filed it .send();
expect(response.status).toBe(403);
expect(response.body.error).toMatch(/self-approval is (strictly )?forbidden/i);

});
it('REQ-02: should require dual sign-off above the $500 threshold', async () => { const response = await request(app) .post('/api/expenses/456/approve') .set('Authorization', Bearer ${firstManagerToken}) .send();
expect(response.status).toBe(202); // pending second approval, not yet approved

}); });

This is the part that actually makes the spec load-bearing rather than decorative. A spec.md file that nobody turns into a test is just a more organized prompt, it can still be ignored, misread, or partially implemented.

Wire REQ-IDs from the spec directly into test names, so a reviewer (or the agent) can trace every requirement to a check that runs on every pull request, and a missing or deleted test shows up as a gap instead of a silent assumption.

Governance for Apps Built Outside the Engineering Team

Spec quality solves the "what should this do" gap. It doesn't solve a separate, less-discussed problem: who owns an AI-built app once it exists. A Reddit thread in r/devops describes a pattern several practitioners recognized, non-developers at their companies using tools like Cursor or Claude Code to build internal apps, then deploying them directly to platforms like Vercel, Cloudflare Pages, or Netlify, outside any process the engineering or security team tracks.

The concerns raised weren't about code quality; they were about authentication from day one, whether the deployment used an approved company account, whether anyone had an inventory of what got deployed where, and whether sensitive internal data ended up in a tool nobody vetted.

This is a single practitioner's account of a problem several others in the same thread said they recognized, not a documented industry rate, but it points at a governance gap that a code-level checklist won't close, because the app in question might never touch a code review at all.

If AI coding agents make it cheap for any employee to stand up a working internal tool, the RAD-style verification this article describes only helps if someone applies it, which means the more urgent first question for many organizations is discovery: knowing an app exists before deciding how rigorously to check it.

Practical starting points that come directly out of that concern: maintain a lightweight registry of internally built apps and their owners, require any app touching customer or financial data to route through an approved deployment account, and treat "an employee built this in an afternoon" as a trigger for a review step, not a reason to skip one.

RAD vs. Agile vs. Waterfall vs. Agentic Engineering

If you're deciding what to call the process your team actually follows, it helps to see the four approaches side by side. This is a simplified comparison, not a universal ranking, each approach fits different conditions, and real teams often combine elements of several.

RAD and agentic engineering share a philosophy,  build fast, learn from reality, keep improving the artifact, while spec-driven agentic workflows place more weight on explicit specification and verification before cutover.

A Decision Guide: When This Approach Fits, and When It Doesn't

Classic RAD guidance describes it as a poor fit for very large, complex projects requiring heavy upfront architecture, and for systems where failure carries severe consequences and therefore demands rigorous assurance. That caution carries over to AI-agent development, though the exact controls should depend on the system and its regulatory context.

Good fit:

1. Greenfield projects with real end users available to give feedback quickly
2. Small, well-bounded components that are cheap to rebuild if the first version is wrong
3. Internal tools and workflow apps where the business rules can be enumerated by people who know the process
4. Projects where a spec-driven or checklist-based verification step is feasible before launch

Poor fit, or fit only with heavy additional controls:

1. Systems handling regulated data (health records, payment data, personal information), where undocumented rules create compliance exposure, not just bugs
2. Mission-critical or safety-critical systems where a missed edge case has consequences beyond inconvenience
3. Large modifications to legacy codebases, where agents can lose architectural context and introduce regressions
4. Multi-team systems where "the users" who need to validate the prototype span dozens of stakeholders with conflicting requirements

The Cutover Checklist: What Has to Be True Before You Ship

RAD's cutover phase was originally about final testing, data migration, and training. For an AI-generated application, cutover needs a verification layer that a working demo cannot provide on its own.

The same rule applies when a website adds an agent-facing interface. WebMCP should be treated as an additional application contract—not as a shortcut around testing, accessibility, authentication, or server-side authorization. Before shipping, test tool discovery, malformed arguments, expired sessions, duplicate execution, cancellation, navigation, untrusted content, and consequential actions.

• Negative cases are written down, not just the happy path, who shouldn't be able to do this, and what happens if they try
• Every business rule discovered during prototyping is captured as an explicit requirement, not left implicit in the UI
• Authorization and access control are reviewed separately from functional testing, a feature working correctly for the intended user says nothing about whether the wrong user can also reach it
• Secrets and credentials are confirmed server-side, not embedded in client code or committed to the repository
• Integration and end-to-end tests are checked for mock overuse, a passing test suite that never touches real dependencies proves less than it appears to
• A human has reviewed the generated code for the specific rules that matter most, rather than approving based on the demo alone
• Rollback and monitoring are in place before launch, not added after the first incident
• Data migration has been validated against production-scale data, not just the sample data used during prototyping
• Every dependency the agent added has been checked against the real package registry, not assumed valid because the build succeeded locally
• The app is registered in whatever internal inventory tracks who owns it, what data it touches, and where it's deployed

None of these gates require abandoning speed. They require treating "it works in the demo" and "it's ready for production" as two different claims that need two different kinds of evidence.

Making the gate automatic instead of a checklist someone skips under deadline pressure

A checklist that lives in a wiki page gets skipped the first time a release is late. The more durable version of the same list is a set of checks wired into the pull-request pipeline that block a merge rather than politely suggest one. None of the following is a specific product endorsement, treat the categories as what to look for, since the tool landscape moves fast:

• Requirement-to-test traceability: the CI job fails if a REQ-ID referenced in spec.md has no matching test, the same way the REQ-01 example above is wired to an assertion, not just a comment.
• SAST scanning on generated code: static-analysis security tools (the category Semgrep and Snyk represent) run on every PR touching agent-generated files, not only on code a human typed.
• Dependency and lockfile verification: an automated step confirms every new package actually exists on the registry it claims to, flags packages registered in roughly the last 30–90 days as needing manual review, and fails the build on an unresolvable or suspicious import, the direct control for the hallucinated-dependency risk described above.
• AI-aware code review gates: review tooling that diffs generated code against the spec (the category CodeRabbit and similar review bots represent) adds a second check beyond human eyeballing, particularly useful when the volume of agent-generated PRs outpaces reviewer bandwidth.

The goal isn't to replace human review. It's to make sure the negative-case tests from the spec, the ones a click-through demo will never exercise, run on every single change instead of depending on someone remembering to run them manually before a release.

Common Mistakes Teams Make With AI-Assisted RAD

Treating the prompt as a complete spec

A prompt is requirements planning, not a specification. It captures what someone thought to mention, not what the system actually needs to enforce.

Confusing user testing with security testing

Users clicking through a prototype are testing whether the interface makes sense. They are not, and cannot be, testing whether the authorization model is complete.

Assuming greenfield performance generalizes to legacy work

The productivity gains reported for fresh, bounded projects don't transfer automatically to large changes in complex, existing systems, the two are different tasks with different risk profiles.

Skipping the write-down step

The value of a prototype is what it teaches you. If those lessons live only in Slack threads and meeting notes instead of a spec, they get lost by the time the code reaches production — exactly how a missing "no self-approval" rule survives all the way to cutover.

Treating a passing test suite as proof of correctness without checking what the tests exercise

A green checkmark on a mock-heavy integration test is not the same evidence as a green checkmark on a test that hits real dependencies.

Applying spec-driven discipline uniformly regardless of stakes

A one-line CSS fix does not need a constitution file and sixteen acceptance criteria. Match the process to the risk, not the tool's default workflow.

The Bottom Line

RAD's four phases have stayed useful for more than three decades because the underlying insight was never really about tooling, it was about sequencing: plan lightly, prototype early, build in short cycles, and don't move into production until the result has been verified.

AI coding agents address one historical limitation of RAD's era,  turning a plain-language description into functional software quickly. They don't remove the need for explicit requirements and verification, and the current evidence, from Veracode's security benchmarks to independent studies on agent-generated code quality, backs that up rather than contradicting it.

James Martin titled his 1982 book Application Development Without Programmers. Forty-four years later, that particular prediction is still waiting on its second sign-off, because programmers are still very much here. In AI-assisted workflows, some of their work has shifted from writing every line by hand toward specifying, reviewing, and verifying what the agent builds.

About The Author

A Gadallh

Ahmed Gadallah is the Founder and Editor of Vertex Frontier, where he publishes research-driven articles on AI, data science, cloud computing, cybersecurity, software engineering, and emerging technologies, with a focus on technical accuracy, clarity, and practical insights.

View all articles by A Gadallh →