Agile, Waterfall and the Vibe: Bringing SDLC Discipline to Vibe Coding

Vibe coding does not make the software development life cycle obsolete; it compresses it.

Requirements, design, build, test and release still happen, but now they can happen inside a single afternoon conversation with an AI agent. The teams getting real value from vibe coding are the ones that deliberately re-insert the discipline of waterfall and agile at the points where speed tends to erase it.

This article walks through what vibe coding is, why it has spread so quickly, how people are actually using it, where it collides with classic SDLC thinking, and a practical set of practices that borrow the best of both models.

What is vibe coding?

Vibe coding is building software by describing what you want to an AI model in plain language, running what it produces, and steering by feedback rather than by reading the code. The human acts as director; the AI acts as author.

The term was coined by Andrej Karpathy, OpenAI co-founder and former head of AI at Tesla, in a post on X on 2 February 2025. He described giving in to the vibes and forgetting the code even exists: accepting every change without reading the diffs, pasting error messages straight back to the model, and asking for tweaks by voice. Tellingly, he framed it as fine for throwaway weekend projects. Within months the phrase had escaped its origins, and Collins Dictionary named it its Word of the Year for 2025.

It helps to separate two things that often get lumped together:

• Vibe coding in the strict sense. The human does not review or understand the generated code; working output is the only test. Simon Willison's line is a useful one: if you reviewed, tested and understood it, it was not vibe coding.
• AI-assisted engineering. The human uses the same tools but stays accountable for design, review and testing. Karpathy himself later used the term "agentic engineering" for this more structured evolution.

Most organisations say "vibe coding" and mean something on a spectrum between these two. The rest of this article is about moving deliberately along that spectrum.

Why it is catching on

Vibe coding spread because three curves crossed at once: models got good enough, tools got agentic enough, and the cost of trying became close to zero.

1. Model capability. Current models can hold a whole feature, its spec, relevant code, tests and conventions, in context and work across many files in a single session. Two years ago they mostly completed lines.
2. Agentic tooling. Tools such as Cursor, Claude Code, GitHub Copilot's agent mode, Replit and Windsurf no longer just suggest code; they run it, read the error, and try again. That loop is exactly what Karpathy was describing.
3. Democratisation. Product managers, analysts, operations staff and founders can now produce a working prototype without waiting for an engineering queue. Some CIOs are actively enlisting business users to build their own tools.
4. Speed to a demo. An MVP that once needed a sprint can be shown in a day. In a world where a demo wins budget, that is a powerful incentive.
5. It is fun. The feedback loop is immediate and the barrier to starting is gone. Developers in surveys report high satisfaction even when objective productivity gains are mixed.

The adoption numbers reflect this. Industry trackers aggregating 2026 surveys describe AI coding tools as having moved from experiment to enterprise standard in roughly 18 months, and Gartner projects that the large majority of enterprise software engineers will use AI code assistants by 2028. One survey cited in academic work found three-quarters of respondents already using vibe coding, nine in ten of them satisfied with it.

The recurring theme in almost every one of those reports, however, is the same: adoption is running well ahead of governance.

How organisations and coders are vibe coding

In practice, vibe coding shows up in five recognisable patterns, each with a different risk profile.

A few observations on how organisations are responding:

• Sandboxed citizen platforms. Rather than ban it, many IT functions now provide governed environments where business users can build, with review and approval required before an app touches sensitive data or runs in production.
• Tool standardisation. Firms are mapping which AI tools developers already use, sanctioned or not, and consolidating onto a few platforms with enterprise controls such as SSO, audit logs and data-retention settings.
• Repository conventions for agents. Engineering teams increasingly keep instruction files such as CLAUDE.md or AGENTS.md at the repository root so every agent session starts from the same coding standards and architecture rules.
• Spec-first workflows. Open-source toolkits like GitHub's Spec Kit and spec-centred IDEs like AWS Kiro push the agent through a specify, plan, tasks, implement sequence instead of free-form prompting.

That last trend is the most telling: practitioners are reinventing SDLC structure from the inside.

Where vibe coding collides with waterfall and agile

Vibe coding looks agile on the surface, with short loops, working software and constant change, but it quietly drops the parts of both models that exist to manage risk.

Waterfall assumes you know what you are building before you build it, and that each phase produces a signed-off artefact. Agile assumes requirements will change, but insists on small increments, a definition of done, team ownership and continuous feedback from real users. Pure vibe coding honours neither assumption fully.

The consequences are now measurable:

• Security. Veracode's testing of over 100 models found 45% of AI-generated code samples failed security tests against the OWASP Top 10. The SusVibes benchmark found that while 61% of one leading agent's solutions were functionally correct, only 10.5% were also secure, and adding security hints to the prompt did not fix it.
• Characteristic flaws. Research on deployed vibe-coded apps points to recurring patterns: placeholder logic left in, unfiltered input, exposed secrets and broken authorisation logic. These are the failures you get when nobody holds the system-wide intent.
• Perceived versus real productivity. In METR's 2025 randomised trial, experienced open-source developers expected AI tools to speed them up by 24%, and afterwards believed they had been 20% faster. Measured, they were 19% slower on familiar, complex codebases. The authors note results may differ with newer tools and other settings, but the gap between feeling and fact is the lesson.
• Technical debt. Code that "mostly works" accumulates. Vibe coding is easy; vibe debugging six months later is the hard part.

None of this means the old models were right and vibe coding is wrong. Waterfall's big up-front design is too slow for exploratory work, and agile's ceremonies were built around human typing speed. The task is to keep the intent behind each principle while changing its form.

Applying waterfall and agile principles to vibe coding

The workable model is a hybrid: waterfall discipline at the bookends, agile cadence in the middle, and vibe-style speed only inside a tightly bounded build loop.

What to borrow from waterfall

Waterfall's enduring insight is that the cheapest place to fix a mistake is before it is built. With AI agents that insight becomes stronger, not weaker, because an agent executes an ambiguous instruction literally and confidently.

• Requirements before prompts. Write a short specification (the problem, users, acceptance criteria, data handled, and what is explicitly out of scope) before the first prompt. This is the core of spec-driven development: the spec, not the chat log, is the source of truth. For MealPartner, a WhatsApp meal assistant for university students that I designed recently, the requirements went through several versions until every open question was closed, before a coding agent wrote a line.
• Design sign-off, lightweight. Ask the agent to propose a plan and architecture first; a human approves it before any code is generated. This is a phase gate measured in minutes, not weeks.
• Non-functional requirements up front. Security, privacy, performance and regulatory constraints rarely emerge from "make it work" prompting. State them in the spec and the repository's agent rules file. In MealPartner, deciding up front that the small local LLM never writes recipe content or links removed most of the hallucination and prompt-injection risk.
• Traceability. Keep the spec, plan and tasks in version control alongside the code, so anyone can see why the code is the way it is.

What to borrow from agile

Agile's insight is that you learn by shipping small things and inspecting them. Vibe coding already has the short loop; what it lacks is the inspection.

• Small increments. One user story or task per agent session, with a commit at each green step. Large wholesale diffs are where unreviewed risk hides.
• A real definition of done. "It runs" is not done. Done means acceptance criteria met, tests pass, code reviewed, security scans clean and the spec updated. In BeatKeeper, my multi-agent content campaign system, an uncited claim cannot be approved and rules such as no auto-posting are enforced by tests, so the AI cannot quietly redefine done.
• Test-first. Have the agent write tests from the acceptance criteria before the implementation, and have a human read the tests. Tests become the agent's guardrail and the human's cheapest review surface.
• Collective ownership. At least one person must be able to explain every merged change. If nobody can, it is not ready to merge.
• Retrospectives that update the system. When the agent repeatedly gets something wrong, fix the spec template or the agent rules file, not just the code.

Scale the process to the blast radius

Not every vibe-coded artefact needs the same rigour. A risk-tiered approach keeps the speed where it is safe and the discipline where it matters.

Best practices for vibe coding

The practices below turn vibe coding from a gamble into a repeatable engineering habit. They apply whether you are a solo builder or a team lead.

Before you prompt

1. Decide which tier you are in. Be honest about whether this will ever touch real users, real data or real money. Prototypes have a habit of becoming production.
2. Write the spec first. One page is enough: goal, users, acceptance criteria, constraints, out of scope. Iterate on the spec, not on prompts.
3. Set up agent rules. Keep a CLAUDE.md / AGENTS.md or equivalent with architecture, coding standards, approved libraries, and security rules (no secrets in code, parameterised queries, authorisation on every endpoint).
4. Ask for a plan, then approve it. Have the agent outline files, components and steps before it writes code. Correct the plan, not the output.

While you build

1. Work in small slices. One task per session; commit after each passing step so you can roll back cleanly.
2. Tests before code. Ask for failing tests derived from the acceptance criteria, read them, then let the agent make them pass.
3. Read the diff. At minimum, skim every change for things you did not ask for: new dependencies, disabled checks, hard-coded credentials, deleted tests.
4. Keep the human in the architecture. Let the agent choose variable names, not trust boundaries. Decisions about data flows, authentication and integrations stay with a person.
5. Reset context when it drifts. Long sessions accumulate confusion. Start a fresh session from the spec and current code rather than arguing with a confused agent.

Before you ship

1. Automate the safety net. Run static analysis, dependency and secret scanning in CI on every AI-generated change; the research shows prompting alone does not make code secure. It is the same principle behind Attic, my Gmail cleanup agent: the LLM only proposes actions, and fixed server-side guardrails decide what is allowed.
2. Human review proportional to risk. Tier 3 and 4 changes need a reviewer who can explain the code, not just approve it.
3. Document as you go. Have the agent update the README, spec and change log in the same commit. Documentation is now nearly free; skipping it no longer saves time.
4. Assign an owner. Every vibe-coded app that survives past a demo needs a named person accountable for maintaining it.

For organisations

1. Provide a sanctioned path. Approved tools with enterprise controls beat a ban that drives usage underground.
2. Separate sandbox from production. Citizen developers build freely in a sandbox; promotion to production goes through review, as any other change would.
3. Measure outcomes, not output. Lines of code generated is a vanity metric. Track lead time, escaped defects, security findings and rework.
4. Invest in review skills. As agents write more code, the scarce skill becomes reading, specifying and testing it. Train for that.

Conclusion

Vibe coding has changed who can build software and how fast an idea becomes something you can click. That is a genuine shift, and organisations that ignore it will lose ground. But the software development life cycle was never really about typing code; it was about understanding the problem, agreeing what good looks like, checking that you got there, and being able to change it safely later. None of those needs went away when the typing did.

The principles of waterfall and agile still apply; they just move. Waterfall's discipline moves into the spec and the plan the agent works from. Agile's discipline moves into small slices, test-first loops and a definition of done that "it runs" cannot satisfy. Vibes stay where they belong: inside the build loop, and in the throwaway experiments where they shine.

Answer that honestly, and you get the speed of the vibe with the reliability of engineering.

Sources

• Karpathy's original vibe coding post, as reproduced by Superwhisper
• Vibe coding glossary entry, including agentic engineering (Codegen)
• Vibe coding meaning, Collins Word of the Year and Willison's distinction (Hora de Codar)
• Vibe Coding Trends 2026: Adoption, Productivity, and Code Quality Data (Keyhole Software)
• Vibe Coding Enterprise Adoption: 2026 Benchmarks (Superblocks)
• Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code (SusVibes, arXiv / ICML 2026)
• Vibe Coding Security Debt: AI-Generated Vulnerabilities at Scale (Cloud Security Alliance)
• Understanding the (In)Security of Vibe-Coded Applications (Emergent Mind)
• METR study: AI tools slow experienced developers (The Register)
• Spec-driven development with AI: Spec Kit (GitHub Blog)
• Spec-Driven Development: From Code to Contract (arXiv)