A Vibe Coding Workflow That Ships: Plan, Code, Test, Deploy

You've used an AI coding assistant a few times. Sometimes you got something great; sometimes you got something terrible; and you're not sure which to expect next. The difference is rarely the model. It's the workflow around it.

Let's get the honest version out of the way: AI won't turn you into a 10x engineer. It makes typing about 10x faster and thinking maybe 1.2x faster. Most of this job is thinking, so the gain is smaller than the demos promise, but it's real. The actual shift is that you spend less time producing code and more time specifying and verifying it.

The loop: plan, code, test, deploy, with a verify after each

This isn't a new lifecycle. It's the four stages you already know, with an assistant plugged into each, plus one step that matters more than anything else: verify after every stage.

Skip it and errors compound forward. A made-up requirement in planning becomes a wrong function, then a test that certifies the wrong function is correct, and now it's in production. Catching it in planning costs a minute. Catching it after release costs an afternoon.

The other thing that decides whether this works is how much you ask for at once. Ask for "a user management system" and you'll get 800 lines you'll skim and merge without understanding. Ask for "the POST /users handler, validation only, no database calls yet" and you get 40 lines you can read properly in two minutes.

If you can't verify the output in five minutes, you asked for too much.

Context is the whole game

Your assistant isn't stupid; it's working blind. It can't see your repo conventions, your team's decisions or your production constraints. Almost everything it gets wrong for apparently silly reasons traces back to something you knew and it didn't.

• Write the project rules file once. Most AI coding tools read one from the repo root: stack, conventions, and things not to do. Ten minutes writing it saves correcting the same three mistakes forty times.
• Paste the real thing. The actual schema, real sample data, the exact error message, not a paraphrase from memory.
• Say "follow the patterns in this file". Paste an existing file from your codebase. A real file is unambiguous where a prose style guide is vague, and this one habit kills most convention drift.

Plan: ask for questions before you ask for a plan

Planning doesn't feel like progress, which is why engineers skip it. It's also the stage that pays best. Don't ask for a plan; ask to be interrogated:

I need to add recurring expenses to our tracker. Before proposing
anything, ask me the 7 questions that most affect the design. Number them.

You'll get questions like: what happens to future instances when someone deletes the series? What does a monthly rule starting on the 31st do in February? Some you'd have thought of. Some you'd have discovered three days later with the feature half-built.

Then harvest edge cases, grouped by data model, calendar and timezone, user actions and failure recovery, and triage them yourself into now, later and not doing. That triage is your spec. Ask for trade-offs, never for the answer: you know your team and your deadline, and the model doesn't.

On a CSV export feature, this step surfaced CSV injection: a user names an expense =HYPERLINK("http://evil.com","click"), a colleague opens the export in Excel, and it's a live formula. One prompt, forty seconds, and a vulnerability that never shipped.

Code: small batches, and read before you run

Match the mode to the task. Autocomplete is for the line you were already going to write. Chat is for self-contained units such as one function or one migration. Agents are for mechanical sweeps with a clear finish line, like a rename everywhere. The more judgement a task needs, the smaller the batch should be.

Work skeleton first: types, signatures and file layout before any function bodies. Then implement one unit at a time: implement, read, run, and commit at every green point. Scan every block that comes back with four questions:

1. Does it do what I asked, not what it decided would be nicer?
2. What did it invent? Check that every import and method actually exists.
3. Where does it break? Empty, null, zero, negative, enormous, concurrent.
4. Can I explain every line? If not, learn it or delete it.

And follow the two-strikes rule. If the second attempt at the same fix didn't work, the third won't either. The model has locked onto a wrong mental model, so reset with a fresh framing or write it yourself.

Test: from the spec, never from the code

This is where AI helps most and hurts most. The mistake almost everyone makes once: pointing it at finished code and saying "write tests for this". It reads your implementation and writes tests asserting that your code does exactly what it currently does, bugs included. You now own a suite that locks your bug in place, plus a green CI badge.

The fix is one sentence: generate tests from the rules, and keep the implementation off-limits.

Write tests for calculateRefund. Here are the business rules — do not
look at my implementation.
- Full refund if cancelled more than 7 days before the event
- 50% between 7 days and 24 hours
- Nothing within 24 hours
- The 2% processing fee is never refunded
- Refunding an already-refunded booking throws AlreadyRefundedError
Include boundary cases at exactly 7 days and exactly 24 hours,
with hardcoded expected values.

"Hardcoded expected values" matters more than it looks. If a test computes the expected number with the same formula as your code, it's running your bug twice and checking the results match.

Before you trust a suite, sabotage it: flip a comparison operator on purpose. If nothing goes red, your tests are decoration. And read the assertions: expect(save).toHaveBeenCalled() tells you far less than expect(saved.amount).toBe(4750).

Deploy: self-review first, and say what to skip

Run the AI over your diff before you ask a human, and tell it what to ignore:

Review this diff as a senior engineer on this codebase. Focus on unhandled
error paths, race conditions, N+1 queries and missing validation. Cite line
numbers. Skip style nits — the linter handles those.

Leave out the last line and you'll get twelve comments about variable names and nothing about the transaction you forgot to roll back. The AI is good at null paths, off-by-one errors and unclosed resources. It's blind to whether the feature is a good idea, which is why humans stay in the loop.

PR descriptions and changelogs are free money. In incidents, ask for ranked hypotheses plus a command that would confirm or rule out the top one, rather than an answer. And scrub emails, tokens and account IDs from logs before pasting them anywhere.

---

Originally published on TechBrosEbooks.

This article is adapted from the ebook The Vibe Coding Playbook, which includes a complete 90-minute worked example building a CSV export end to end, guardrails for security, licensing and privacy, the anti-patterns that waste the most time, a 30-day plan, a prompt library and a pre-merge checklist.
~

~

~