Six Rules Against Vibe Coding Inside AI-DLC

The lifecycle stops vibe coding at the gates. It does nothing about the engineer who opens the file and fixes it by hand.

Vibe coding is the habit of prompting an agent until the thing seems to work, without reading the code or deciding anything on purpose. AI-DLC was designed as the opposite: specify first, let the AI drive, approve every step at a gate. On paper, a team running AI-DLC cannot vibe code.

In practice it slides back in, between the gates. Someone spots a bug in generated code and patches it directly. Someone asks the agent a curious question and the agent rewrites a spec in response. Someone asks the agent whether its own design is good, in the same conversation where it wrote that design. None of these break a rule of the method. All of them quietly undo it.

The six rules below are not mine. They come from a team that runs AI-DLC in production and wrote them down after watching their own engineers make these mistakes. I have rewritten them in my words and added the reasoning I saw behind each one. The words to type are the part to steal.

Why a lifecycle still leaks vibe coding

Every rule on this list exists for the same reason: the shortcut is faster right now, and the cost shows up later, somewhere else.

AI-DLC keeps a chain of artifacts, from requirements to design to code, and each one is supposed to describe the next. That chain is the memory the agent uses in every future session. The moment you change the code without changing the design, the chain lies. The next time the agent generates code for that area, it builds from a design that no longer matches reality, and your fix quietly disappears or collides with what it writes.

One challenge from the pilot put it well: it is tempting, and faster in the short term, to fix the error instead of fixing what made the error happen. Every rule here forces you to fix the cause.

Fixing the error

1. 01Patch the generated code by hand
2. 02Ask the agent to just make the test pass
3. 03Keep going in a long, tired session
4. 04Trust the agent's review of its own work

Fixing the cause

1. 01Correct the design, then regenerate
2. 02Find which requirement or decision was wrong
3. 03Commit, clear the context, resume from state
4. 04Get the critique from a fresh context

The six rules

Six rules, and what to type

1. 01

   Never edit generated code by hand. Go back to the design.

   A hand patch makes the artifacts lie about the code. The next generation builds from the old design and undoes your fix, or fights it.

   Instead of

   Open the file, change three lines, commit, move on.

   Type this

   I found a problem in the order service: cancelled orders keep their stock reservation. Let's review the design and make a plan to fix it.

2. 02

   Prefix every exploratory question.

   Without the prefix, the agent reads a curious question as a change request and edits the spec in the middle of the conversation.

   Type this

   Do not update any documents. What happens if we move the reservation release into a background job?

3. 03

   Before a big change, ask for the impact without editing.

   A large design change on top of already approved work cascades through requirements, stories, and finished Units. You want the map of the damage before you approve the change.

   Type this

   Do not change anything. Assess the impact of splitting the order service in two on the requirements, the user stories, and the Units already implemented.

4. 04

   Tell the agent which internal libraries exist before it writes code.

   Every company has its own starters and libraries for authentication, tracing, and feature flags. An agent that does not know them invents dependencies or rewrites what you already have.

   Type this

   Before generating code, read docs/internal-libraries.md. Use these for auth, tracing, and feature flags, and do not add a dependency that duplicates one of them.

5. 05

   Get the second opinion from a fresh context.

   In the same conversation, the agent defends the decisions it made. It rationalizes. A clean context reads the artifact like a stranger would.

   Type this

   /clear
   Read design/order-service.md. Produce a critique of it as if you hadn't written it.

6. 06

   Clear the context at every approval gate, after you commit and push.

   Quality degrades as a session grows: wrong attempts, back and forth, old drafts. Clearing at a gate forces the agent to rebuild context only from what is authoritative, the approved files and the state.

   Type this

   git add -A && git commit -m "Approve requirements" && git push
   /clear

Rule one: the design is the source of truth, not the code

This is the rule teams break most, because it feels wasteful. The bug is right there. The fix is three lines. Why go back to a design document?

Because in AI-DLC the design document is not documentation. It is the input to the next generation. Patch the code and the next time anyone asks the agent to touch that area, it regenerates from the old design and your fix is gone, or worse, half gone. Correct the design and regenerate, and the fix survives every future session.

There is a second payoff. Going back to the design asks the question a patch never asks: why did the agent get this wrong? Often the answer is a missing requirement or an ambiguous answer in the questions file. Fixing that fixes a class of bugs, not one bug.

Rules two and three: questions are not instructions

An agent working inside AI-DLC is primed to act. It has artifacts open, a workflow to advance, and a strong bias toward treating whatever you say as a request to change something. So when you ask “what if we did this differently?”, it often does it differently, right there, in the spec.

The prefix is the cheapest guardrail in this list. “Do not update any documents” turns the agent from a contractor into an advisor for one answer. Use it every time you are thinking out loud.

Rule three is the same idea at a larger scale. Before you approve a change that touches the architecture, ask for the impact as a report, with editing explicitly forbidden. You get a list of requirements, stories, and finished Units that the change would invalidate. Then you decide, with the cost in front of you, instead of discovering it one regenerated file at a time.

Rule four: the agent does not know your company

A model has read most of the public internet. It has not read your internal authentication starter, your tracing library, or the feature-flag client every service is supposed to use. Left alone, it reaches for the popular open-source equivalent, and you get a pull request that adds a dependency your platform team spent a year removing.

The fix is to tell it, explicitly, before code generation starts. Keep a short document that lists the internal libraries, what each one is for, and which public alternatives are forbidden and why. The why matters. An agent told “do not use library X” will find library Y. An agent told “we use our own client because it handles retries and tenant headers” will look for our client.

This is also the kind of correction AI-DLC 2 can make permanent. When you correct the agent during a stage, its learning loop offers to save the correction as a project rule, and that rule applies from the next workflow on. Say yes to this one. You only want to type it once.

Rule five: never ask the author to review itself

Ask an agent, in the same conversation, whether the design it just wrote is good, and it will explain why it is good. That is not dishonesty. The reasoning that produced the design is still in its context, and it reads its own work through that reasoning.

Clear the context, load only the artifact, and ask for a critique as if it had not written it. The difference in what comes back is large. It finds the assumption it made silently, the case it did not handle, the requirement it read loosely.

AI-DLC 2 builds part of this in. Its reviewer agents run as separate subagents after a stage produces its artifacts, so they read the work without the author’s reasoning in their context. That is the same principle. Use it, and keep the habit for every artifact the reviewers do not cover.

Rule six: the conversation is disposable, the files are not

Long sessions degrade. The window fills with wrong attempts, corrections, and drafts that were replaced three steps ago, and the agent starts losing track of decisions it made earlier. In the teams I watched, quality dropped noticeably once the context window passed about three quarters full.

The answer is to treat the conversation as scratch paper. At every approval gate, commit and push the approved artifacts, then clear the context. The agent resumes from the state file and the approved files, which are exactly the things that are supposed to be true. What gets thrown away is the noise.

The order matters. Commit first, then clear. Clear first and you can lose the one artifact the next session needed. If a session got stuck in a long investigation, ask the agent to write a short summary of what it found and what it ruled out before you clear, and load that summary into the new session. The managing of all this on a large codebase is covered in AI-DLC in brownfield.

Rule seven: cap the size of every Unit

The team’s list had six rules. The rollout taught them a seventh, and it is the one with the most measurable effect.

When AI-DLC generates code, it generates a lot of it, fast. Before construction, the agent splits the work into Units, the independent pieces that each get built and reviewed on their own. Left alone, it will happily propose one Unit that delivers an entire feature: migration, entity, API, tests, all in one merge request with hundreds of changes. Nobody reviews that with real attention. Throughput goes up, merge requests pile up in review, and the time from first commit to deploy gets worse instead of better. That pattern has its own article: why AI-DLC makes you slower first.

The fix happens when the agent proposes the Units. Ask it to estimate the size of each one, and split anything above a limit your team agrees on. A hundred changes per merge request is a reasonable starting line. A fifty-change review is manageable. A three-hundred-change review is a rubber stamp.

The seventh rule

1. 01

   Cap the size of each Unit before you approve the plan.

   Review is the bottleneck once generation is cheap. A small Unit gets a real review. A huge one gets a glance. Decide the limit with the people who review, and write it down so future sessions respect it.

   Type this

   Before I approve the Units, estimate the files and lines each one will change. Split any Unit above about a hundred changes: one per endpoint, and migrations in a Unit of their own.

What AI-DLC 2 already enforces for you

The newer engine closes some of these doors on its own, and it is worth knowing which ones so you do not fight the tool.

It runs five guards it calls fences, which refuse work nobody asked for. They reopen an approval when something you already approved was changed underneath it, freeze an artifact while it is under review, block direct writes to the workflow state, keep reviewers inside their read scope, and require a real human to answer the gate. A setting called Guard Policy decides how hard the first four hold. Nothing lowers the last one. Every Unit also needs its own plan approval. The command that verifies each Unit is chosen and authorized by a human, and changing it needs a new authorization. Reviewers run in their own context. The state file survives context compaction.

What it cannot enforce is your hands on the keyboard. Nothing in the engine stops you from opening a generated file in your editor and changing it. Nothing stops you from asking a curious question without the prefix. The guards protect the workflow. The rules protect the code.

Put the rules where the agent reads them

A rule that lives in a team wiki gets remembered on good days. A rule that lives where the agent reads it gets applied every day, by the agent, to every engineer’s session.

Put the internal libraries, the size limit for Units, and the prefixes into your agent’s instructions. That can be your AGENTS.md, your CLAUDE.md, or, in AI-DLC 2, the team memory file that every workflow loads at the start. Keep the human-only rules, like committing before clearing, in the onboarding for anyone who runs the workflow.

Are you vibe coding inside AI-DLC?

• ✗Anti-pattern:
  Someone fixed generated code by hand this week.Check whether the design was updated too. If not, the next generation will undo it.
• ✗Anti-pattern:
  A spec changed in a conversation that was supposed to be a question.Missing prefix. The agent took the question as an instruction.
• ✗Anti-pattern:
  The agent reviewed its own design in the same session.That review was a defense, not a critique.
• ✗Anti-pattern:
  A session ran past three quarters of the context window.Output quality was already degrading. Commit, clear, resume.
• ✗Anti-pattern:
  A merge request with hundreds of changes was approved in minutes.Nobody reviewed it. Split Units before construction next time.
• ✓Required:
  The internal library list lives where the agent reads it.Then nobody has to remember to paste it.

FAQ

What is vibe coding?+

Vibe coding is prompting an AI agent until the result seems to work, without reading the code or making deliberate decisions about it. It is fine for a throwaway prototype. It breaks down when the code has to be maintained, because nobody decided anything and nobody understands what was built.

Can you vibe code inside AI-DLC?+

Yes, between the gates. The lifecycle checks each phase's output, but it cannot stop an engineer from patching generated code by hand, asking exploratory questions that the agent turns into edits, or letting the agent review its own work. Those habits undo the method without breaking any of its rules.

Why not just fix a small bug in generated code by hand?+

Because in AI-DLC the design is the input for the next generation. A hand patch makes the design and the code disagree, and the next time the agent touches that area it regenerates from the old design and your fix disappears. Correct the design, then regenerate.

Do I lose my work when I clear the context?+

Not if you commit and push first. AI-DLC keeps the work in versioned files and a state file that records where you stopped. Clearing the context throws away the conversation, which is noise by then, and the agent resumes from the files.

How big should a Unit of work be?+

Small enough that a person reviews its merge request with real attention. A reasonable first limit is about a hundred changes per merge request. Agree on a number with the people who do the reviews, ask the agent to estimate each Unit's size before you approve the plan, and split anything above it.

Where to go next

AI-DLC gives you gates. These rules are what you do between them. The pattern under all seven is the same: fix the cause, not the symptom, and keep the files true, because the files are the only memory the agent has.