Working With It, Day to Day

Starting AI-DLC is the easy part — one sentence, as we just saw. The teams who get the most out of it follow a handful of simple habits after that. Here they are, plus the one rule people describe as mattering more than any other.

Answering Well, Not Just Answering

We already saw that Requirements Analysis asks its questions through a file, multiple-choice, with [Answer]: tags. A few small habits make your answers much more useful to Robo:

• Add a label, not just a letter. C — quantity and due date only, nothing about condition is far clearer than a bare C.
• Say why, briefly. A — design first; write the plan before any code tells Robo your reasoning, and it carries that reasoning forward into later stages.
• Combine options when you mean both. B and C — a reminder on the day it's due, and a list Ms. Sharma can check any time (not D).
• Use X on purpose. If none of the options actually fit, say so in your own words rather than forcing the nearest wrong answer.

Once you've filled in the file, go back to the chat and say so explicitly:

We've answered your questions. Please re-read the file and continue.

Asking it to re-read matters — it makes sure Robo loads your actual, current answers off disk, not an outdated memory of the conversation.

Two Buttons, Every Time

At the end of every stage, Robo presents exactly two options — always the same two:

• Request Changes
• Continue to Next Stage (sometimes phrased "Approve and Continue")

No third option, no open-ended menu to interpret. Read what was generated before you pick either one — that's the entire point of the checkpoint.

"Do Not Update Any Documents Yet"

Sometimes you want to think out loud, push back, or ask "why did you choose this?" without it turning into an edit. Guard the question with this phrase up front:

Do not update any documents. Help me understand why you chose a
2-book limit here instead of leaving it unlimited.

This lets you explore freely. Once you're satisfied with the answer, drop the guard and ask for the change deliberately, if you still want one.

Controlling How Deep Robo Goes

Robo already adapts depth automatically — a one-line bug fix gets a light touch, a payment system gets the full treatment. You can also just say so directly:

Keep this at minimal depth — we just need the basic structure documented.

This is a production-critical component. Please run at comprehensive depth.

Useful whenever Robo's default guess doesn't match how much this particular piece actually matters.

One Prompt, or Several?

A simple rule from teams who've done this a lot: when two changes are tightly related to the same thing, put them in one prompt. When they're unrelated, send them one at a time.

Cramming unrelated changes into a single prompt makes Robo lose focus and miss details. Splitting up two things that really belong together just adds unnecessary round-trips. When you're not sure which, separate them — that's the safer mistake to make.

Pointing Robo at Things You Already Have

If a schema, an API spec, or an architecture diagram already exists somewhere, don't describe it from memory — point Robo straight at it:

Please read the attached schema. Use it as the basis for the Loan
and Book tables — don't invent a new structure.

This works at any stage, not just the start. If something changes mid-Construction — a new policy, a revised data model — load it and ask Robo to assess the impact before you keep going.

Getting a Second Opinion

Robo will generally defend decisions it already made — which makes sense, but isn't always what you want when you're trying to stress-test a plan. For a genuinely fresh look, ask in a brand-new chat, one with no memory of why the original choices were made:

Produce a critique of the requirements document. Do this in a new
context, separate from the conversation where it was written.

An honest critique is much easier to get from something that isn't invested in its own earlier answer.

Clearing Your Head Between Stages

AI tools have a limited amount of "working memory" for a conversation, called context. The longer a single chat runs, the more it has to hold onto — and quality can quietly degrade the more it accumulates.

The good news: at every approval gate, your progress is already saved to files. That makes it genuinely safe to start a brand-new chat right after approving a stage, rather than continuing the same long one. A fresh chat loads only what's relevant from disk and picks up cleanly.

To resume in a new chat:

Go to aidlc-docs/aidlc-state.md, find the first unchecked item, then
go to the corresponding plan file and resume from that point.

Tip: commit and push whenever you do this. It takes seconds, and it means there's always a clean point to come back to.

Never Vibe Code

This is the one rule people who've used AI-DLC for a while describe as mattering more than any other.

Vibe coding, here, means editing the generated code directly to make a quick fix — bypassing the design documents entirely. It feels fast in the moment. It causes real problems shortly after.

Here's why: the design documents in aidlc-docs/ are the source of truth Robo reads before doing anything else. If you quietly patch the code without touching the documents, the code and the plan now disagree — and the next time Robo touches a related unit, or you resume a session, or a teammate picks up the work, that disagreement causes confusion nobody can fully explain.

The rule: update the design first, then regenerate the code.

The Right Way to Make a Change

Step 1 — describe the issue without touching anything:

Do not update any documents yet. I've discovered issue X. Review the
design and help me understand where this needs to be addressed.

Step 2 — fix the design document:

Please update the loan design to reflect the fix. Then check whether
the requirements document also needs updating.

Step 3 — regenerate just the affected code:

The design for the loan unit has been updated. Please re-run code
generation for the affected files only.

It takes a few extra minutes compared to just editing the file. What it buys you: documentation that's never lying to you, and a teammate who can trust it.

A Realistic Example, Back in Our Story

Ms. Sharma notices during testing: a book she just returned still briefly shows as "on loan" for a few seconds.

The tempting way: open loan.py, tweak the condition, ship it. Nobody else knows it happened. The design document still describes the old (buggy) behavior.

The right way:

Do not update any documents yet. Ms. Sharma reported that a returned
book briefly still shows as "on loan." Help me understand where in
the design this is happening.

Robo traces it to a stale cache check in the loan design. You approve a one-line fix to the design document, Robo regenerates just that function, and audit.md now has an honest, permanent record of what broke and why — instead of a silent patch nobody remembers in six months.

Overriding a Design Decision

Sometimes Robo proposes something reasonable, and you still want to do it differently — a house pattern, a library your team already trusts, a deliberate simplification. Say so, and say why:

We'd rather not add a separate overdue-checking service for something
this small. A simple date comparison inside the existing loan check
is enough, and it keeps this a one-file app. Please update the design
accordingly.

The why matters as much as the what — Robo carries that reasoning into later stages, which is what stops the deviation from quietly getting "corrected" back to the original suggestion in a later unit.

After the Code Is Done: Closing the Loop

Small decisions get made while code is actually being written that never technically got asked as a formal question — a naming choice, a slightly different validation order. Left alone, the design documents quietly drift out of sync with what the code actually does. Once a unit's code is finished and polished, sweep those small decisions back up into the documents that describe them:

Now that this unit's code is finished, review the final code against
its design documents and propagate any small decisions made along
the way back up to the design. Make a short plan for how you'll do
this before starting.

Asking for a plan first keeps the sweep systematic instead of catching only the changes you happen to remember.

Where We Are So Far

One idea has run through everything so far: plan before you build, build in small checkable pieces, review often, and never let the code and the plan quietly drift apart. Robo, Ms. Sharma, and the treehouse were how we made that easy to picture. aidlc-docs/, the question files, the two-button approvals, and "never vibe code" are how it actually works, today, in a real project.

Everything up to here has quietly assumed one thing: that Ms. Sharma's project is brand new, with no code to worry about yet. That won't always be true — and it isn't even true for her project for very long. The next lesson covers what changes when there's already something there.

What's Next

Continue to: When Code Already Exists (Brownfield)