From Enterprise SDLC to Solo Vibe-Code with ADD

There are two ways to ship software badly.

The first is the one most senior engineers escaped from: the enterprise SDLC at full ceremony. A requirements document that takes three weeks and one committee. A design review with eleven attendees and one decision. A change-advisory board that meets on Tuesdays. A QA hand-off, a security sign-off, a release manager, a go/no-go call. Every gate exists for a reason — and collectively they move so slowly that the reason is often forgotten by the time the gate opens.

The second is the one a lot of those same engineers ran toward: solo vibe-coding. One person, one AI, no process. You describe what you want, the agent writes it, you skim the result, you ship. It is exhilarating. It is also how you put a confident, plausible, completely wrong change into production on a Friday afternoon with nobody to catch it.

This post is for the developer making that move — from the heavyweight lifecycle to building alone with an agent — who has noticed that something got lost on the way, and can’t quite name it. The thing that got lost is not the ceremony. It is what the ceremony was for. And the good news is that you can get all of it back without rebuilding the committee.

That lean replacement is AI-Driven Development (ADD) — the subject of this series. This installment is the practical one: a safeguard-by-safeguard field guide for the solo builder.

What “going solo” silently deletes

Here is the uncomfortable part. When you leave a team to build alone, you do not sit down and decide which safeguards to keep. You just stop having them. Nobody runs the design review because there is nobody to run it with. The change board does not reject your risky migration because there is no board. QA does not catch the regression because QA was a person, and that person is not you.

The enterprise SDLC is, underneath all the meetings, a list of jobs:

• Requirements / business analysis — decide what to build and what counts as done, before building it.
• Design & architecture review — agree the shape and the interfaces before code commits to them.
• Change control — stop a change from moving until someone has actually looked at its blast radius.
• QA / test — prove the thing does what was asked, independently of the person who built it.
• Code review — have a second mind read the change and find what the author cannot see.
• Security review — check the specific failure modes that hurt most when they ship.
• Release management — make the go/no-go an explicit, recorded decision, not a vibe.
• Post-mortem / retro — turn what broke into what changes next time.
• Onboarding docs — let the next person pick up the context without re-deriving it.

None of those jobs is ceremony. The ceremony is the enterprise-scale packaging of the job — the boards and documents and sign-off chains — and that packaging exists for one reason: many humans had to coordinate. A change board is what “look before you leap” turns into when forty engineers share a deploy pipeline. A QA department is what “test it independently” turns into when the author and the tester have never met.

Strip away the coordination problem — one person, one repo — and the packaging becomes pure overhead. But the jobs remain. Every single one of them still needs doing. You just need a form of each that one person and an agent can actually run.

Why it bites harder when you’re solo with an AI

You might think a solo developer is less exposed than an enterprise — smaller surface, fewer moving parts, full context in one head. For human-typed code, that was roughly true. With an agent in the loop, it inverts, because the agent changes the shape of the risk.

The series opener calls these the four failures of the AI-era SDLC. Read them again as a solo developer, and notice that each one is specifically a failure the team used to absorb for you:

1. Fast waste. An agent is fast in whatever direction it is pointed. Point it vaguely and it sprints confidently past the ambiguity instead of stopping at it — producing a finished-looking result built on an assumption you never made. On a team, a reviewer or a BA would have caught the wrong assumption in conversation. Solo, the first thing that questions your direction is production.
2. Context rot. The model degrades over a long session, and every new session starts cold. The design lived in the team’s shared memory — the wiki, the channel, the person who wrote it. Solo, the design lives in your head and a chat window that resets, so the agent re-guesses it every morning.
3. Trust-by-inspection breaks down. AI code is frequently plausible and wrong: it reads reasonably and behaves incorrectly. Code review was the safeguard against exactly this — a second mind that doesn’t share your blind spots. Solo, the only reviewer is the person who already accepted the change.
4. The verification ceiling. An agent can produce more change than one person can check. On a team the review capacity scaled with headcount. Solo, your verification capacity is fixed at one human, and everything the agent generates above that line is unreviewed risk.

This is the real reason “just vibe-code it” fails the moment the stakes rise. Vibe-coding doesn’t add risk by writing bad code — the code is often fine. It adds risk by removing, all at once and without telling you, every safeguard that used to stand between a plausible-wrong change and your users.

A quick definition, since the term gets thrown around: vibe coding is the prompt-accept-and-move-on style of working with an agent — you describe an outcome, accept what comes back, and keep going on feel rather than on evidence. It is a genuinely good way to work for the right tasks, and ADD is not its enemy. The point of this guide is not to slow vibe-coding down. It is to keep its speed while putting the deleted safeguards back — in a form light enough that one person can carry them.

The reframe: keep the function, drop the ceremony

The instinct, once you feel the loss, is to drag the enterprise process back in — write the big requirements doc again, set up a review checklist, gate yourself. Don’t. That re-imports the overhead you correctly fled, and a solo developer will abandon it inside a week.

The move instead is to separate two things the enterprise SDLC always bundled together: the what and the how.

The enterprise SDLC, in practice, clamped both. It specified the behavior and dictated the implementation, through design docs and architecture standards and reviewers who rewrote your code to taste. That double-clamp is most of where the slowness came from.

ADD clamps only the what — the behavior, the interface, the definition of done — and leaves the how completely open for the agent. That single change is what lets the safeguards shrink. A “design review” no longer has to evaluate your implementation, because the implementation is disposable; it only has to pin the interface. A “QA pass” no longer needs a separate department, because the definition of done is a test suite written before the code. Each heavyweight stage collapses to the one decision it was actually protecting.

So the translation rule is: for each enterprise safeguard, ask what question did this gate exist to answer? — then find the lightest artifact that answers the same question for one person and an agent.

The mapping: each safeguard, and its lean equivalent

This is the core of the field guide. The left column is what you left behind. The middle is the job it was really doing. The right is the ADD artifact that does the same job at solo scale — most of them just sections of a single TASK.md file that the method walks top to bottom.

Enterprise safeguard	What it was for	Lean solo-ADD equivalent
Requirements doc / BA	Decide what to build and what “done” means, before building	Specify — a short list of Must / Reject (with named error cases) / After-state
Design & architecture review	Agree the external shape before code locks it in	Scenarios + Contract — Given/When/Then, then a frozen interface
Change-control board	Stop a change moving until its blast radius is seen and approved	The frozen contract — one approval, checksummed; the agent may not alter it on its own
QA / test team	Prove behavior independently of the builder	Red tests first — the executable definition of done, written and run failing before any code
Code review	A second mind finds what the author can’t see	Verify by evidence — an adversarial refute-read that tries to break the green, not skim the diff
Security review	Catch the specific failure modes that hurt most in production	Security gate — a hard stop that can never be auto-passed or waived
Release management / sign-off	Make go/no-go an explicit, recorded decision	The recorded gate — exactly one logged outcome: PASS, RISK-ACCEPTED, or HARD-STOP
Post-mortem / retro	Turn what broke into what changes next	Observe — tagged lessons folded back into the living project docs
Onboarding / knowledge transfer	Let the next person resume without re-deriving context	State in files — PROJECT.md plus one tracked TASK.md per feature

Two of those deserve a closer look, because they are where solo developers most often think they’re fine and most often aren’t.

Code review → verify by evidence. The trap is reading your agent’s diff, finding it reasonable, and shipping. Reasonable is exactly the failure mode — plausible and wrong. The replacement is not “read it harder.” It is to make the green earned: confirm the tests were red for the right reason first, then do an adversarial pass that actively hunts for the cheat — a test that asserts nothing, an implementation overfit to the fixture, logic stubbed out to pass. On a solo project you can even spawn a second agent whose only job is to refute the first one’s work. That restores the independent second mind without a second human.

Change board → frozen contract. The board’s real job was never the meeting; it was the moment of “nobody changes this without a decision.” ADD keeps the moment and drops the meeting: you approve the contract once, it is checksummed, and from then on the agent is forbidden to alter it to make a build pass. A failing build against a frozen contract is not a license to edit the contract — it is a change request that sends you back to Specify. That one rule is most of what a change board bought you.

What does not map — and where you might still want a second human

Honesty requires the other column. A few enterprise safeguards do not have a clean solo equivalent, because their entire point is independence between people:

• Segregation of duties — the person who writes the change is not the person who approves the deploy. Solo, you are both, by definition. A refute-read agent narrows the gap but does not close it.
• Independent review and audit — in regulated or high-blast-radius work, “a second human looked” is itself the deliverable, and an agent’s sign-off does not legally or organizationally count.
• Adversarial collaboration — sometimes the value of review is a colleague who disagrees with you about the goal, which no amount of tooling supplies.

The right column is “closest lean equivalent,” not “perfect replacement.” Where the job is fundamentally another independent person, the honest answer is to keep another independent person.

The loop you actually run

Put the equivalents in order and they are not nine stages. They are one loop, walked per feature.

The shape that makes this sustainable for one person: across the entire loop, you make exactly two decisions. You approve the frozen contract — once, at the point where direction is locked. And you accept the verify gate — once, when the evidence is in. Everything between those two points is the agent’s to drive, because direction is fixed and the contract cannot move. Everything outside them is recorded in files, so the next session resumes from state instead of re-deriving it.

That is the whole trick of going solo without going sloppy: you spend your scarce human attention on the two things an agent genuinely cannot do for you — setting direction and judging evidence — and you let it have the part it is actually good at, which is writing the code.

Proof: the same loop, from a blog post to a production gateway

The fair objection to any lightweight method is that it only stays lightweight because it is never tested by anything serious. So here is the same method at both ends of the dial — both built by one person, with the same engine.

At the heavyweight end is ai-proxy, a multi-tenant LLM gateway run all the way to production on ADD. Its living docs, read straight from the repository: PROJECT.md at 657 lines, CONVENTIONS.md at 802 lines, carrying 38 lessons folded back from real loops (17 tagged ADD, 14 TDD, 2 SDD, 2 SECURITY, 2 UDD, 1 DDD). It has shipped 52 milestones (v1 through v53), and across its recorded gates there are 234 logged PASS outcomes and zero risk-waivers — not zero risk, but zero risk silently accepted; every release was an explicit decision. Each task tracks its own md5 tripwire, gate, scope, and verified flags in state, so a cold session resumes exactly where the last one stopped.

At the lightweight end is this blog. It runs the identical engine at stage: mvp — a handful of loose content tasks (the post you are reading is one of them), each a single TASK.md with the same state schema: tripwire, gate, scope, phase. No milestones, no production rigor dialed in, because a blog post does not need it.

That is the point worth sitting with. It is not a team-versus-solo comparison — both projects are solo. It is one person, one method, one state file, with the depth dialed by stage: full rigor and a security hard-stop for the gateway, a light touch for the blog post. The enterprise SDLC promised that production-grade discipline required a production-grade organization. A single developer reaching foundation-version 38 on a multi-tenant production gateway, with a clean gate ledger and zero silent waivers, is the counter-evidence. You can have what the enterprise SDLC was for without the enterprise.

Where you should still reach for the heavyweight process

This is a field guide, not a manifesto, so the limits are part of it.

Keep — or adopt — the real enterprise SDLC when the coordination problem it solves is genuinely present:

• Regulated work — finance, health, safety-critical — where independent review, audit trails, and segregation of duties are legal requirements, not nice-to-haves. ADD’s recorded gates help you produce the evidence, but they do not replace the independent humans the regulation demands.
• Large teams — once many people share a pipeline, you are back to the coordination problem the boards and sign-offs were invented for. ADD scales down beautifully; it does not abolish the need to coordinate across people.
• High, irreversible blast radius — a migration that can corrupt years of customer data warrants a second independent human, full stop.

And in the other direction: a genuine throwaway — a prototype you will delete on Friday, a one-off script, a spike to learn an API — needs none of this. Vibe-code it. The discipline in this guide is for work you intend to keep and run, where a plausible-wrong change has somewhere to do damage. Matching the weight of your process to the stakes of the work is the whole skill; ADD’s contribution is that the floor — frozen contract, red test, recorded gate — is light enough to leave on almost all the time.

ADD complements team process; it does not pretend to abolish it. What it abolishes is the excuse that discipline requires a department.

The solo dev’s minimum

If you take one thing from this guide, take the reframe: leaving the enterprise SDLC does not mean leaving its safeguards behind. It means keeping their jobs and dropping their meetings. Specify before you build. Freeze the interface before you generate. Write the failing test before the code. Earn the green instead of reading the diff. Record the decision instead of feeling it. Fold what you learned back into the docs.

The method states it as a mantra, and it is a good one to keep above a solo desk:

Steer before you accelerate. Trust evidence, not impressions. Keep the decisions, throw away the code. Loop freely, but never skip silently. Grant the AI only as much autonomy as you can verify.

For the full step-by-step mechanics, start at How AI-Driven Development Fixes the SDLC; for the stage-by-stage mapping onto a team lifecycle, see ADD Across the SDLC. This post was the solo cut: the same loop, sized for one.