Free · structured · practical
Search 中文 Start at lesson 1
Courses/They Will Quiz You/Vibe Coding Methodology · 30 Tough Questions
Part 7 · Vibe Coding, With Guardrails

Vibe Coding Methodology · 30 Tough Questions

Each with intent, framework, and bonus points: why make rules / quality ownership / code merge gate / reject installments / decision persistence / safety gates

THE QUESTION THIS PAGE ANSWERS

ANSWER FIRST

What is the key idea behind “Vibe Coding Methodology · 30 Tough Questions”?

Each with intent, framework, and bonus points: why make rules / quality ownership / code merge gate / reject installments / decision persistence / safety gates

DECISION RULE

Make the claim earn its place. Use this page as a decision aid, not a definition to memorize. Connect the idea to one real task, one observable result, and one failure that would change your mind.

TRY NEXT

Write one question you could answer with evidence after trying this idea.

WATCH FOR

A conclusion that sounds complete but leaves the key assumption untested.

How to Use This Page
Each question is labeled with who's asking. They're all looking at the same AI collaboration guidelines, but each wants to hear something different.
🎙 InterviewerWants to verify you've actually used it — not just skimmed a few articles
👔 ManagerWorried about quality, accountability, and incidents
🛠 Dev ColleagueProbing whether you understand engineering well enough to be trusted
Each question has three layers: What they're testing → Answer framework → Bonus points. If you can't answer a section, click the linked lesson page at the bottom to review.
Q1Interviewer
"Your résumé says you're proficient in Vibe Coding. If AI is writing the code, why bother setting up all those rules?"
🎯 What they're assessing
An opening framing question. It tests whether you can speak with incidents. Anyone who just says "standards are important" is reciting clichés; someone who has actually hit the problems will immediately name specific incidents and the rules they produced. Answering "AI can occasionally make mistakes so we need to be careful" is technically correct but reveals nothing.
🧭 Answer framework
  1. Define Vibe Coding first: A development approach where you use natural language to have AI produce code directly. The problem has always been quality — moving fast just amplifies how badly things can go wrong.
  2. Name four classic incident types: misunderstanding-driven rework (changed 7 files before discovering the approach was wrong), stack drift (Express today, Fastify tomorrow), well-intentioned destruction (refactoring that removes working code), and permanent tech debt (the "lite" login that never got upgraded).
  3. Pinpoint the shared root cause: All four stem from the same issue — constraints never made it into context. AI can forget what you told it in every new conversation turn.
  4. Give the fix: Write constraints into a Rule file that is automatically loaded at the start of every conversation. Telling AI in chat gets truncated out of the window; writing it in docs the AI may not read; only Rules are the structurally most reliable injection channel.
⭐ Bonus point Add the rule-generation logic: every time AI repeats a mistake, turn it into a rule. The value of rules is that each one solves a real problem — piling up clauses for their own sake is meaningless. This shows you understand the method, not just the output. Worth memorizing verbatim.
Organize your answer using these lesson pages → Why You Need to Set Rules for AI The Value of Rules: Each One Solves a Real Problem
Q2Manager
"If AI is writing all the code, whose fault is it when there's a bug — AI's or yours? Can you really take accountability for quality?"
🎯 What they're assessing
The manager wants clear accountability and a quality mechanism. Answering "we review everything AI generates" is the same as having no mechanism; blaming AI is worse — that's admitting the process is uncontrollable. What the manager wants to hear: accountability sits with the human, and concrete checkpoints ensure that human can actually bear it.
🧭 Answer framework
  1. Accept accountability first: bugs are always on the human — AI is a tool. The purpose of this framework is to give humans a sign-off opportunity at every critical node, so any failure can be traced back to exactly which gate let it through.
  2. Pre-delivery checkpoints: The breakpoint is set before coding starts. AI must restate requirements, produce a PRD, and receive explicit approval before writing a line; changes touching more than 3 files require a modification plan first. Misunderstandings are intercepted before the first line of code.
  3. Hard delivery baselines: Two non-negotiable checks. Any feature touching an AI API must have been called for real — no Mocks allowed; core logic unit tests must pass before delivery.
  4. Post-incident protocol: When a real bug hits, speculative fixes are banned. Add logs first to locate the root cause. Before fixing, answer three questions (complete business flow, which modules are affected, are there similar issues elsewhere); after fixing, declare the scope of impact and specify what needs regression testing.
⭐ Bonus point Volunteer a data comparison: speculative fixes across three rounds, 47 lines changed, bug still there; one round of adding logs to locate the root cause, bug gone. Two minutes of logging buys out three rounds of guessing-wrong rework. The manager will understand that math.
Organize your answer using these lesson pages → Debugging Rule: Logs Before Code 4-Step Flow: Restate, PRD, Confirm, Code Why You Need to Set Rules for AI
Q3Dev Colleague
"Do you PMs really merge AI-generated code directly? Who can actually review changes across a dozen files at once?"
🎯 What they're assessing
The dev colleague is probing whether you have process awareness. What they're really afraid of is uncontrolled large-scale changes. Answer "AI is really capable now, it basically doesn't make mistakes" and they'll never trust you near the repo again; answer with concrete checkpoint mechanisms and they'll start treating you as a peer.
🧭 Answer framework
  1. Correct the premise first: There is no "direct merge." Before AI starts, it must go through a 4-step flow: think through the question, restate requirements in its own words, write a PRD, receive explicit approval before coding. No human sign-off means no code.
  2. Address large changes directly: Any change touching more than 3 files requires a modification plan first — listing which files, what changes in each, and the dependencies between changes. You're reviewing the plan; no matter how large, that's manageable.
  3. Add scope-limiting rules: Before adding new functionality, search the project for similar existing implementations to avoid reinventing the wheel; new components get a standalone demo in PlayGround first, integrated into the main project only after they work.
  4. Explain why rules must be explicit: Vague instructions like "please confirm you understand before coding" are useless — AI will decide it understands and proceed. Specifying concrete actions like "write a PRD, wait for approval" is what makes checkpoints real.
⭐ Bonus point Name the engineering judgment behind the threshold: 3 files is a rule-of-thumb — cautious projects set it to 1, rapid prototypes loosen it to 5. Single-line changes let AI skip the PRD on its own judgment; the rule catches multi-file changes where rework cost is highest. Knowing the threshold is tunable shows you've actually used this in a real project.
Organize your answer using these lesson pages → 4-Step Flow: Restate, PRD, Confirm, Code PlayGround: The Component Fitting Room
Q4Manager
"AI said to ship a lite version first — we'd have something to show in two days. Sounds pragmatic to me. Why are you pushing back?"
🎯 What they're assessing
The manager has sided with AI — you need to persuade a person. This question tests whether you can translate tech debt into cost terms the manager can understand. Going along with "sure, let's ship the lite version" makes you complicit in the debt; just saying "there'll be tech debt" is too vague — managers want numbers.
🧭 Answer framework
  1. Expose the motive first: When AI proposes "lite version first," it's usually unrelated to complexity — it wants to quickly give you something that runs and collect positive feedback. "Use a temporary solution," "mock it for now," "just handle it simply" — same pattern underneath.
  2. Give the cost math: Completing the lite version on launch day costs 0.5×; by day 30, four modules depend on the lite API and completion costs 3×; by day 90, nine modules are tightly coupled, 8× cost exceeds a full rewrite. "Optimize later" never comes.
  3. State the rule: No simplifying implementations for any reason, and AI is banned from proactively planning phased delivery or MVPs. Every implementation must be complete, correct, and debt-free.
  4. Return the choice to the manager: When a feature genuinely is too complex, the right move is to have AI produce the full solution, realistic effort estimate, and a list of decisions that need to be made — then humans decide whether to split it and how. Splitting is a human decision; downgrading is AI acting on its own judgment.
⭐ Bonus point Name a counterintuitive observation: after breaking the "lite version first" pattern, AI actually analyzes the full solution more carefully. This insight comes from real usage — saying it out loud puts you ahead of most candidates.
Organize your answer using these lesson pages → No Phased Delivery 4-Step Flow: Restate, PRD, Confirm, Code
Q5Dev Colleague
"Can you still explain why that feature was changed last month? Once you close an AI conversation, doesn't all the decision history just disappear?"
🎯 What they're assessing
This is the fatal question about Vibe Coding's maintainability. By default, decisions in conversational development are locked inside chat history — three months later, no amount of git log archaeology will recover them. Answering "I'll check the chat history" admits there's no retention mechanism; being able to describe a documentation system is what shows you're treating AI collaboration as engineering.
🧭 Answer framework
  1. Acknowledge the problem and give the mechanism: Decisions genuinely can't rely on chat history, so AI is required to maintain docs using a strict template — decisions survive across conversations and time.
  2. Name the three documents and their roles: FEATURES answers "how did this feature get to its current state" — with status transitions and history, changes and reasons all filed; CHANGELOG answers "what changed in this release" — root cause and impact scope; RELEASE_NOTES answers "what did the user receive."
  3. Add the taste-retention document: METHODOLOGY.md records product principles, design decisions, UX preferences, and anti-patterns. When a user rejects a modal dialog approach, AI logs it as an anti-pattern — new conversations automatically inherit it, and the same proposal never comes up twice.
  4. Explain why it must live in the repo: Decisions written in Notion or Feishu are invisible to AI. Only Markdown files inside the project repo let AI automatically get context every time.
⭐ Bonus point Add two easily overlooked rules: before writing a CHANGELOG entry, AI must read system time — filling timestamps from memory and backfilling entries are both banned; code comments require three elements (context, design intent, key constraints) — comments are also written for the AI in the next conversation.
Organize your answer using these lesson pages → Three Documents and Methodology Retention Comment Three-Element Rule and Code Protection
Q6Manager
"I've seen news about AI deleting entire databases. If we work this way, what happens if AI wipes our production database one day?"
🎯 What they're assessing
The manager wants reassurance. "AI wouldn't do that" is the worst answer — because AI actually will: well-intentioned cleanup, temporary changes sneaking into a release, these are real incidents. The correct approach is to acknowledge the risk and then lay out the gates one by one.
🧭 Answer framework
  1. State the master principle first: Safety for irreversible operations comes from gates. For database, configuration, and deployment operations, all gates are set before execution.
  2. Name the three gates: Gate 1 — backup: no migrate, drop, alter, or delete without a backup first, backup is timestamped in a backups/ directory, cost is one command, what's at stake is the entire database. Gate 2 — rollback: before acting, state how to recover, what backups are needed, and estimated recovery time. Gate 3 — audit: before releasing, have SubAgent compare actual diff against Release Notes — any unrelated changes and the release is paused.
  3. Add release discipline: Releases must go through GitHub; servers pull code via git pull or CI/CD. Tagging, pushing, and deploying are all banned before the user explicitly confirms — AI has no authority to release on its own.
  4. Lock down credentials too: All keys go through environment variables or secrets — no hardcoding. Once a key enters git history it's permanently compromised and must be revoked and reissued.
⭐ Bonus point Explain the design intent behind diff auditing: professional teams use CI/CD plus PR review to catch bad releases; solo developers often skip review and push directly. Having SubAgent act as the reviewer fills that gap. Being able to articulate this shows you understand the engineering intuition behind the rule.
Organize your answer using these lesson pages → Three Gates for Destructive Operations Writing Environment Facts into Rules
Q7Interviewer
"You said you write the rules into a Rule file. What does that file actually look like? If I start a new project tomorrow, what's step one?"
🎯 What they're assessing
Whether you've actually configured this yourself. Anyone who can only talk philosophy and can't name the file structure or directory is usually reciting articles. Being able to cite frontmatter fields and how the three files split the work is what shows you've shipped it.
🧭 Answer framework
  1. Start with the file structure: Rule files carry frontmatter. alwaysApply: true is for global coding standards — it kicks in on every conversation. Set it to false for on-demand files like writing standards, so they don't pollute coding-conversation context.
  2. Name the three files: xs_vibe_rules is three files. rule-opensource.mdc is the main development spec — 14 chapters covering the full flow; writing-style.mdc governs Chinese writing style and is cited manually when needed; secrets.mdc is the API Key and credentials template, in placeholder form.
  3. Give the three landing steps: Drop the .mdc files into the project's .cursor/rules/ directory — Cursor picks them up automatically; configure alwaysApply on each file; swap the model config, tech stack, and port rules for your own choices.
  4. Close the security loop: Fill the secrets file with placeholders and keep it out of git. Once a key enters git history it's permanently leaked — you can only revoke and reissue.
⭐ Bonus point Add the starting move: this repo is MIT License open source. The right move is to Fork a copy, cut it to your stack, and what you get is your first version of an AI collaboration spec — a much higher starting point than writing from scratch.
Organize your answer using these lesson pages → Why You Need to Set Rules for AI The Value of Rules: Each One Solves a Real Problem
Q8Dev Colleague
"I looked at the bug in your chat box: hit Enter on a Chinese IME and a half-finished pinyin string goes out. AI wrote that, right? How do you make sure it doesn't do it again?"
🎯 What they're assessing
How deep your grasp of AI blind spots actually is. Anyone who can name the isComposing API and explain why AI will always step on this landmine has really fixed AI-written frontend in the field. Anyone who just says "I'll have AI patch it" will hit it again on the next project.
🧭 Answer framework
  1. Give the root cause first: Confirming a candidate in a Chinese IME also fires Enter. The code only checked e.key === 'Enter' and never looked at isComposing, so the candidate-confirm Enter got treated as send.
  2. Give the standard write-up: Send only when Enter, not Shift, and !e.nativeEvent.isComposing are all true. isComposing true means the IME is still composing — Enter only confirms the candidate, it does not send.
  3. Explain why AI does this: isComposing coverage in AI training data is thin. If you don't write it into a Rule, it will forget. The rule text is blunt: never check only e.key === 'Enter' without also checking isComposing.
  4. Raise it to the fix method: This bug is also the textbook case of "logs before code." One log line printing e.key and isComposing locates the root cause in one round — 4 lines and it's clean. The guessing route burned three rounds and 47 lines and still wasn't fixed.
⭐ Bonus point Mention !e.shiftKey in passing: the standard write-up reserves Shift+Enter for a newline — another detail AI often drops. Anyone who can recite the full condition set has clearly been in this hole.
Organize your answer using these lesson pages → Writing Environment Facts into Rules Debugging Rule: Logs Before Code
Q9Interviewer
"You said every component gets tuned in PlayGround before it lands. Frontend already has Storybook. Why aren't you using that?"
🎯 What they're assessing
Engineering judgment: do you know the industry-standard option, and why you picked the lighter one for your own scene. "Never heard of Storybook" shows a narrow field of view; "Storybook is more professional so we should use it" shows you can't do the cost math.
🧭 Answer framework
  1. Admit the idea is the same: PlayGround is a stripped-down Storybook idea — every UI element gets its own demo, tuned before it goes into a real page.
  2. The difference is cost: Storybook is the industry standard, but the setup is heavy — overkill for AI-assisted rapid prototypes. PlayGround is one static page with every component demo lined up. Cost is basically zero.
  3. Say what you get back: Isolation in both directions. Tweaking a component doesn't touch business logic; tweaking business logic doesn't scramble component styles. Write it straight into the page and you have to boot the whole page — log in, fetch data, flip states — just to look at one button. Bump the border-radius and you might shove the layout next to it out of place.
  4. Give the trigger: The rule is explicit: when page motion is involved, you must create a static PlayGround page first, freely tune and test, and only then write it into the real page.
⭐ Bonus point Add a delivery detail: parameters tuned in the demo can be copied straight into the real component — by integration time it's already a finished piece. Fit it in the fitting room, then walk on stage. Rework never gets a chance to start.
Organize your answer using these lesson pages → PlayGround: The Component Fitting Room
Q10Manager
"The last demo looked great. The second it went live, everything broke. Turns out the AI API was never connected — the page was all fake data. How do you stop that from happening?"
🎯 What they're assessing
The manager has been burned by a fake demo. They want a hard mechanism on the delivery line. "I'll check more carefully next time" admits there is no mechanism — it'll happen again. You need a gate written into the process.
🧭 Answer framework
  1. State the ban: Any feature that calls an AI model must confirm the API is actually reachable before delivery. Hardcoded fake responses or local mocks that skip the real call are banned.
  2. Pin it at the source: If the user hasn't given an API Key, AI must stop and ask — it is not allowed to Mock its way forward. Once the key is in, fire one test request to prove it works, then keep building. The biggest risk — "the API isn't live" — gets exposed on development step one.
  3. Add the second line: Core business-logic unit tests must pass or it doesn't ship. The two hard checks together are the delivery line.
  4. Name the motive: "Mock it for now," "use a temporary solution," and "just handle it simply" are the same pattern — AI wants to quickly give you something that runs and collect positive feedback. Those phrases are named and banned in the same clause.
⭐ Bonus point Translate the loss for the manager: fake data hides the risk until launch day, then it explodes. The rule moves verification to the moment the key arrives. The earlier the risk shows, the cheaper it is to handle.
Organize your answer using these lesson pages → Debugging Rule: Logs Before Code No Phased Delivery
Q11Interviewer
"You're building an AI chat product. To tweak one prompt, do you really have to run the whole business flow? How do you tune Prompts day to day?"
🎯 What they're assessing
Whether you have debugging-infrastructure awareness for an AI product. Prompts are the core asset of an AI product. If you can't name a dedicated debug environment, the product is still at "it runs" — not iteration.
🧭 Answer framework
  1. State the hard requirement: When a project has AI chat, PlayGround must include a simple conversation test page — you can run one turn of chat without the full business flow.
  2. Lay the prompts out: That page must list every Prompt the project uses. Prompts buried in code strings can't be debugged; laid out on a page, you can compare and tweak fast.
  3. Name what it actually is: Prompts are the core asset of an AI product. Give them a fitting room the same way you do components — tune them, then send them into the business flow.
⭐ Bonus point Add the maintenance rule: PlayGround demos are only added or changed, never deleted. If a requirement is cancelled, the matching demo stays. It's an archive of the design process — when the requirement comes back, you pick it up and use it.
Organize your answer using these lesson pages → PlayGround: The Component Fitting Room
Q12Interviewer
"I've seen AI comments — they just restate the function name. Three months from now, will you still understand why your code is written that way?"
🎯 What they're assessing
Whether you can turn "write good comments" from a slogan into an executable structure. Those four words AI cannot execute. Anyone who can cite a fixed structure, an example, and a judgment standard is actually managing AI code quality.
🧭 Answer framework
  1. Admit the problem first: Code can only say "what it does." Why it exists, why this implementation, what callers must watch — that only survives across time if you write it into comments.
  2. Name the three elements: Background (what business problem it solves, what scene calls it), design intent (why this approach, which alternatives were dropped — git log will never have this), key constraints (side effects, dependencies, edge cases the caller must know).
  3. Add the protection rule: During a refactor, you may not delete background and design-intent comments because they're "too long," "the code is self-explanatory," or "cleaning up while I'm here." If the implementation changed and the comment is wrong, update the content in lockstep.
  4. Give the judgment standard: Only one: without this comment, could the person who inherits this still understand why it was done this way?
⭐ Bonus point The course example is the most convincing: the three-element comment on merge_chat_history records "server records are authoritative, only append locally unique messages, drop all system messages." You cannot read those decisions out of the code itself.
Organize your answer using these lesson pages → Comment Three-Element Rule and Code Protection
Q13Dev Colleague
"That compatibility code I wrote last week for the old data format — your AI wiped it during a refactor. Did you even know?"
🎯 What they're assessing
The colleague is assigning blame, and also probing whether your process can protect their code. Blow this answer and collaboration trust goes to zero. The core test is how you prevent "well-intentioned destruction."
🧭 Answer framework
  1. Name the incident type first: That's well-intentioned destruction. AI cleans up code it thinks is surplus during a refactor, and only later do you find it was useful — one of the four classic incidents.
  2. Give the declaration rule: Before deleting any existing feature code, the user must be told explicitly, with a reason. Silent deletes justified as "cleaning up while I'm here" or "looks unused" are banned.
  3. Give the standard move: When AI thinks a block should go, it first marks // TODO: suggested removal - reason: xxx and waits for explicit approval. "Looks unused" is not a deletion reason.
  4. Add the process gate: This kind of destruction usually happens inside a bulk refactor. Changes touching more than 3 files require a modification plan first, file by file. "While I'm here" cleanup shows up at plan review.
⭐ Bonus point Close the other wrong turn too: commenting the whole block out and leaving it in place is also wrong — the rules don't encourage that; it's still destruction. There is only one correct path: mark, tell, wait for approval.
Organize your answer using these lesson pages → Comment Three-Element Rule and Code Protection 4-Step Flow: Restate, PRD, Confirm, Code
Q14Interviewer
"We had an outage, opened the logs, nothing there — every error had been caught and quietly swallowed. Do you have any constraints on error handling?"
🎯 What they're assessing
Whether the quality baseline goes all the way down to the statement level. Being able to list what counts as silently swallowing an error means the rules actually reach the code. "We handle errors carefully" means there are no rules.
🧭 Answer framework
  1. State the ban: Empty catch is banned. Every try/catch and error branch must do something real.
  2. Define swallowing: Only console.log(e), pass, or // ignore all count as silently swallowing errors. None of them are allowed.
  3. Give the pass standard: A log plus a user-visible error message, or a reasonable fallback — at least one of those.
  4. Pair it with the logging surface: Backend prints detailed logs in the terminal; frontend prints in the browser Console. Swallowing errors and missing logs are the same disease — when something breaks, "logs first, then find the root cause" has nowhere to start.
⭐ Bonus point If you can fold this together with comment protection and deletion declarations into the same plate (quality baseline — specifically blocking AI laziness), it shows you have the full map of the rules in your head. Every clause you cite, you know where it sits in the system.
Organize your answer using these lesson pages → Comment Three-Element Rule and Code Protection Debugging Rule: Logs Before Code
Q15Manager
"How many times have I told you — no modal dialogs. Then you switch conversations and AI pops one up again. Can't these preferences just stick?"
🎯 What they're assessing
The manager is complaining about the cost of repeating themselves. They want a taste-retention mechanism: say a preference once, and every later conversation inherits it. "I remind AI at the start of every chat" leaves the cost exactly where it is.
🧭 Answer framework
  1. Give the mechanism: METHODOLOGY.md. AI actively spots product thinking, decision logic, and trade-off preferences in the conversation, distills them, writes them in, and new conversations inherit them automatically.
  2. Say where the modal goes: When a user rejects a modal approach and gives a reason, AI files it under "anti-patterns." The same proposal never comes up twice.
  3. Name the four-part structure: Product principles (core beliefs that keep showing up), design-decision log (with dates and reasons), UX preferences (UI/UX taste and aesthetic standards), anti-patterns (explicitly rejected approaches, with the rejection reason).
  4. State the write-in principle: Distill the essence, merge likes with likes, date new entries — don't paste conversation verbatim. Don't record implementation details or one-off temporary decisions. When AI spots one, it writes it in and briefly tells you — no permission needed every time.
⭐ Bonus point Recite the four trigger moments: the user explained "why we do it this way," rejected a proposal with a reason, stated a clear UI/UX preference, or summed up a lesson in a retro. At those four moments AI records automatically, and the manager's taste stacks up into a handbook, one line at a time.
Organize your answer using these lesson pages → Three Documents and Methodology Retention
Q16Interviewer
"Three months ago you swapped a feature from plan A to plan B. If I ask you now why you switched, what do you look up?"
🎯 What they're assessing
Feature-level traceability. Anyone who says "I'll check the commits" hasn't noticed that decision info and code info are two different things: git log only records how the code changed, not why.
🧭 Answer framework
  1. Give the answer directly: Open docs/FEATURES.md. It's the single source of truth for features. Every feature has a "history" — original need, plan changes and reasons, final implementation.
  2. Name the status flow: 🟡 Planned, 🔵 In progress, 🟢 Done, ⚪ Cancelled. Every status change or plan tweak appends a dated record.
  3. Call out the details: Cancelled features aren't deleted — mark ⚪ and note why; dates must come from system time, not memory; even if the plan never changed, write one "original need" line.
  4. Explain why git log isn't enough: "Search switched from A to B because of performance" — a commit only shows the change itself. History is exactly what answers "why we dropped plan A."
⭐ Bonus point Name the philosophy that runs through both: FEATURES "cancel, don't delete" and PlayGround "demos only grow, never shrink" are the same thing. A killed requirement is still an archive of the design process — when it comes back, you pick it up.
Organize your answer using these lesson pages → Three Documents and Methodology Retention PlayGround: The Component Fitting Room
Q17Interviewer
"Your release notes say 'refactored the message-rendering module.' Can a user even read that? How do you split CHANGELOG and RELEASE_NOTES?"
🎯 What they're assessing
Audience awareness in docs. The two documents have completely different voices — one for developers, one for users. Mixing them means you never decided who each one is for.
🧭 Answer framework
  1. The split in one sentence: CHANGELOG answers "what changed this time," for developers; RELEASE_NOTES answers "what did the user get," for real users.
  2. CHANGELOG's grid: Reverse chronological. Each row is a table of problem/need, root cause/approach, change scope, impact surface, status. Type tags: BUG / FEAT / REFACTOR / PERF / DOCS. Before writing, read system time — filling timestamps from memory and backfilling a pile later are both banned.
  3. RELEASE_NOTES red lines: No debug features, no implementation details (module names, file paths, refactors), no changes users can't feel. "Refactored the message-rendering module" doesn't change external behavior — it should never appear in an announcement.
  4. Give a passing write-up: Every line should answer "what does this do for me." New features: one sentence on the new thing a user can do. Fixes: what was broken, what's fixed now. No more than 3 sentences per item. Version numbers follow SemVer.
⭐ Bonus point Demo the split on the same incident: the IME misfire fix. CHANGELOG writes the root cause as not checking isComposing, type BUG; RELEASE_NOTES only writes "Chinese input no longer sends by accident." One fact, two documents, each takes what it needs.
Organize your answer using these lesson pages → Three Documents and Methodology Retention
Q18Dev Colleague
"I pulled your branch, ran it, and axios is gone — everything's fetch now. You don't even say anything when that happens?"
🎯 What they're assessing
Dependency governance. A dependency change pulls the whole project's build and runtime with it. Silent swaps are a collaboration sin. They want to know if you have a declaration mechanism — or if it's whatever mood AI is in.
🧭 Answer framework
  1. Name it first: That violates the dependency-change declaration. Any change to package.json or requirements.txt is banned from silent install or remove.
  2. Report three things: Before touching anything, you must proactively say what was added or removed, why it's needed, and why that version.
  3. Explain why it's strict: A functionally equivalent swap may not be equivalent in blast radius. The real course case: axios from 0.27.2 to 1.6.0 — a major version with breaking changes that can hit every network request.
  4. Add the release-side backstop: Even if the declaration is missed, the pre-release diff audit catches it once more. A dependency change Release Notes never mentioned gets flagged by SubAgent as risk, and the release pauses.
⭐ Bonus point Draw the boundary hard: mentioning it in a commit message does not count. The declaration must happen before you act — same "declare first, then touch" pattern as marking a TODO and waiting for approval before deleting code.
Organize your answer using these lesson pages → Comment Three-Element Rule and Code Protection Three Gates for Destructive Operations
Q19Interviewer
"Do you even run tests on AI-generated code? And the tests are written by AI too, right? Isn't that just lying to yourselves?"
🎯 What they're assessing
How hard the delivery line actually is. Anyone who can name the directory, naming, and coverage has tests inside the process; "we run them when we have time" means tests are decoration. The second half is a challenge — you have to catch it.
🧭 Answer framework
  1. Give the hard line: Core-logic unit tests must pass or it doesn't ship. That's one of two hard pre-delivery checks; the other is a real AI API verification.
  2. Name the coverage: Core business logic, API endpoints, data-processing functions, and edge cases all get covered.
  3. Name the spec details: Test files live in tests/, named test_{module}.py; Python projects use pytest. Throwaway debug scripts delete themselves when done. Test assets and debug junk are kept apart.
  4. Catch the challenge: Tests are only the last gate. Upstream you still have PRD confirmation catching misunderstandings and a modification plan catching scope creep. The gates complement each other — any one of them alone is not enough.
⭐ Bonus point Add the boundary: tests catch regressions at the implementation layer. If AI misunderstood the requirement, the tests still go all green — so the breakpoint has to sit before coding. That's exactly why the 4-step flow exists.
Organize your answer using these lesson pages → Debugging Rule: Logs Before Code 4-Step Flow: Restate, PRD, Confirm, Code
Q20Interviewer
"Your rules ban AI from proposing an MVP? Shipping an MVP first to validate demand is product 101. Isn't that backwards?"
🎯 What they're assessing
A concept-splitting question: can you tell a human-decided split from an AI-improvised downgrade. Anyone who mixes the two will either turn a good rule into dogma, or be too scared to use it.
🧭 Answer framework
  1. Draw the line first: The rule bans AI from proactively planning phases, MVPs, or stage one-two-three. It has never banned humans from making an MVP decision. Splitting is a human decision; downgrading is AI acting on its own. That difference is the core of the rule.
  2. Give the correct flow: When a feature really is complex, AI's correct move is to produce the full solution, a realistic effort estimate, and a list of decisions that need to be made. Whether to split, and how, is a human call.
  3. Give a boundary case: A feature that truly needs 2,000 lines — writing it in one sitting isn't realistic. Have AI report the full plan and effort; based on that, humans split it into two PRs. That's a split, not a downgrade.
  4. Add one hard rule: If a plan is already known to be flawed, give the correct version. Don't ship a "good enough" one first.
⭐ Bonus point Close with the auth-system example: AI reports a full plan of about 3 days, complexity sitting in the OAuth callback and multi-device sessions, plus 3 decisions up front (phone-number login or not, how many providers, session TTL). A human can call it in tens of seconds, and the complete version lands in one shot.
Organize your answer using these lesson pages → No Phased Delivery
Q21Interviewer
"You require Agent tool calls to use XML? Everyone's on JSON now. Where did that rule even come from?"
🎯 What they're assessing
The engineering reason behind the format choice. If you can talk through escape hell and the error pattern of an LLM generating token by token, your understanding is at the generation-mechanism level — and you know the rule has a boundary.
🧭 Answer framework
  1. Name the three-way split: Agent tool calls use XML; config files and data storage use YAML; external REST APIs use JSON. Each format owns one domain. They don't mix.
  2. Give XML's reason: JSON nested inside a JSON string is escape hell — every nesting level doubles the backslashes, and an LLM generating token by token easily mismatches brackets and quotes. XML tag closure is intuitive; the model error rate is lower.
  3. Give the other two: Config files are read and written by humans. YAML has no bracket-and-quote noise, supports comments, and "why this value" can sit right next to it. REST APIs use JSON because that's the industry standard — the principle for external interfaces is don't make callers suffer.
  4. Name the exception: A GPT-only project can switch tool calls back to JSON — its function calling is natively JSON. "Agents use XML" is the greatest common divisor for mixed-model setups. Claude-family models are more stable on XML.
⭐ Bonus point Also rule YAML out of the call protocol: it expresses hierarchy with indentation, and indentation drifts easily when an LLM generates — one space off and the whole tree leans. If you can give the rejection reason for all three formats, you actually understand the three-way split.
Organize your answer using these lesson pages → Writing Environment Facts into Rules
Q22Interviewer
"Your image-generation feature timed out at scale the day it launched. Turned out to be the timeout config. How do you prevent a pit this basic?"
🎯 What they're assessing
How you manage environment facts. The signature of this pit: AI steps in it again and again — you fix it this conversation, the next one falls back to the default. They want to know you solve it once with a Rule, and that you can cite the actual numbers.
🧭 Answer framework
  1. Describe the pit: Image APIs often fail on the default 30-second timeout, and AI will keep retrying the same wrong config — right once you fix it, wrong once it forgets.
  2. Give the numbers: HTTP client timeout for image generation is at least 120 to 180 seconds, written into a Rule, loaded automatically every conversation. Solved once.
  3. Name the sibling rules: A failed network request must first retry through a proxy (default 127.0.0.1:7890) and only then report to the user — skipping the proxy and erroring immediately is banned. Every user-visible large-model response on the frontend must stream; non-streaming is only allowed for internal backend calls.
  4. Raise it to a mechanism: These are all environment facts. Writing them into a Rule is handing AI a pre-filled .env manual. A new conversation needs no briefing — it already knows which model to call and what timeout to set.
⭐ Bonus point Give the verification method: open a new conversation, give no briefing, and ask AI for the project's tech stack and model config. If it can answer, it's actually in the Rule. That's the in-class exercise — people who've done it don't hesitate.
Organize your answer using these lesson pages → Writing Environment Facts into Rules
Q23Dev Colleague
"I hear you spin up several SubAgents to edit code at once? Two Agents touch the same file — the later one overwrites the earlier one. Then what?"
🎯 What they're assessing
Consistency awareness for multi-Agent parallelism. This is a new engineering problem. Anyone who can answer it is actually using multi-Agent to do work; anyone who can't is treating parallelism as a demo.
🧭 Answer framework
  1. Give the rule: When multiple SubAgents or multiple edits touch the same file, later edits must re-read the file's current state first. Editing from a cache or from remembered old content is banned.
  2. Give the analogy: That's optimistic locking for the multi-Agent era. Confirm the latest file state before you write, and someone else's change won't get silently overwritten.
  3. Pair it with goal consistency: During parallelism the user may have changed the goal. When restating the goal, use the latest one and mark the change explicitly, so old and new goals don't get mixed and two Agents don't each do their own thing.
  4. Note the constructive use of parallelism: The rules encourage parallel research. The three-question self-check before a bugfix suggests spinning up SubAgents first to research blast radius in parallel, then acting once it's confirmed safe.
⭐ Bonus point Name what the two rules share: in long conversations and parallel work, the information in your hands goes stale. Refresh before the critical move (re-read the file, restate the goal) — much cheaper than debugging after the fact.
Organize your answer using these lesson pages → Long-Conversation Anchoring and Writing Standards Debugging Rule: Logs Before Code
Q24Interviewer
"AI made a very convincing case for swapping your database from SQLite to PostgreSQL. Do you switch?"
🎯 What they're assessing
Who owns stack decisions. Anyone who follows AI into the swap will eventually drown in stack drift. The answer they want is "lock it," plus how you lock it.
🧭 Answer framework
  1. Give the stance first: No. Tech-stack selection is a human decision. Once it's set, alternative proposals are off the table. AI's job is to write good code inside the chosen stack.
  2. Describe what drift looks like: Without a lock, AI picks different frameworks in different conversations — Express today, Fastify tomorrow, MongoDB one hour and PostgreSQL the next. The project loses consistency in the drift.
  3. Name what you lock: Write the selection into a Rule and freeze it. The course example is FastAPI on the backend, React + Tailwind + Vite on the frontend, SQLite for the database, Chroma for the vector store.
  4. Add the port detail: Avoid port 5000; pick at random from 8000 to 9000 so multiple projects can run together without colliding. Being able to cite this means you actually read the Rule down to the details.
⭐ Bonus point Add "how you switch the right way": if you really need to change the database, the entry is a human editing the stack declaration in the Rule (the "swap" in the four adapt actions). Then AI works inside the new stack. The selection can change — but the change entry is in human hands, never in AI's suggestion.
Organize your answer using these lesson pages → Writing Environment Facts into Rules Why You Need to Set Rules for AI
Q25Manager
"I still remember last version's incident: unfinished code snuck into the release. You said you added a review. How do you actually review? And if you find a problem, then what?"
🎯 What they're assessing
The manager wants step-level process detail. They're tired of the four words "we review." They want it broken into what each step does, and who decides when a problem is found.
🧭 Answer framework
  1. Name the three process steps: Take the full diff, compare file by file, classify and handle. Have SubAgent independently analyze the gap between the actual diff and the Release Notes.
  2. Say what you're reviewing: Release Notes are the intended change; the actual commit may have mixed in unrelated tweaks or even accidental deletes. Course case: the release theme is dark mode, but the diff also rewrites a message-parsing function and bumps axios from 0.27.2 to 1.6.0. Anything not in the announcement is risk.
  3. Give the disposition: Finding risk pauses the release and waits for user confirmation. Until then, tagging, pushing, and deploying are all banned. AI has no authority to release on its own.
  4. Add the release channel: Releases must go through GitHub; servers pull via git pull or CI/CD. Emergency hotfixes can be an exception — a follow-up commit to sync is mandatory.
⭐ Bonus point Capture the review's value in one sentence: split "what I thought I changed" from "what I actually changed" and compare. The delta is where incidents come from. Once the manager hears that, they know you've thought it through.
Organize your answer using these lesson pages → Three Gates for Destructive Operations
Q26Interviewer
"You talked to AI for 30 turns and it suddenly swapped the database you locked in at the start. Has that happened to you? How do you treat it?"
🎯 What they're assessing
Whether you understand why long conversations drift. "I'll remind it a few more times" hasn't entered the room. Anyone who can explain window truncation and periodic anchors is a real long-conversation user.
🧭 Answer framework
  1. Explain the cause first: Context-window truncation plus attention decay at the tail of a long text. "Use PostgreSQL" from turn 1 has already slid out of the window by turn 30. AI is only making a "reasonable" inference from what it can still see — so it suggests switching to SQLite.
  2. Give the rule: After more than 10 turns, before key operations — editing code, changing config, deploying — AI must first review and restate the current goal and key constraints.
  3. Give the format: Restatement has a fixed format: "📌 Current goal: XXX | Key constraints: YYY." A human can glance and confirm it hasn't drifted.
  4. Add the boundary: Even a 200K-token model has real attention decay at the tail of a long text. Anchoring is still necessary on long-window models. Switching to a bigger model does not cure this.
⭐ Bonus point Connect the two lines of defense: stack drift is itself one of the four classic incidents. Stack lock blocks it from outside the conversation (Rule injected every turn); anchoring blocks it from inside (periodic restatement). Dual insurance.
Organize your answer using these lesson pages → Long-Conversation Anchoring and Writing Standards Why You Need to Set Rules for AI
Q27Interviewer
"You let AI write product copy too? Honestly, I can spot the AI voice a mile away — and so can users. How do you make it sound like a person?"
🎯 What they're assessing
Whether you can turn a subjective ask like "natural and fluent" into engineering. "I'll revise it a few more times" has no method. Anyone who can cite a banned list and a self-check flow has stable delivery quality.
🧭 Answer framework
  1. Explain why the slogan is useless: "Please write natural, fluent Chinese" does nothing. What AI thinks is natural and what you think is natural can be completely different. You have to give a concrete list of banned words and banned sentence patterns before AI can execute precisely.
  2. Give banned patterns: writing-style.mdc's list includes full-width dashes, full-width ellipses, contrast sentences like "not A but B," web-novel emotion words, comments evaluating other people, preamble that interprets before it starts, and English curly quotes.
  3. Give the self-check flow: Before delivery, search each banned pattern. Find one, fix one. When done, note that the self-check is complete. Banned patterns in the System Prompt get fixed the same way.
  4. Give the config detail: Writing standards live in their own file, frontmatter set to alwaysApply: false, cited manually only when writing copy or Prompts — so they don't pollute coding-conversation context.
⭐ Bonus point Name what the list method actually is: banned patterns are searchable. AI can scan the draft it just wrote, line by line, and subjective taste becomes a mechanical check. Anchors fight forgetting; lists fight vagueness. Both turn a fuzzy expectation into an executable action.
Organize your answer using these lesson pages → Long-Conversation Anchoring and Writing Standards Why You Need to Set Rules for AI
Q28Interviewer
"Your first UI was all emoji buttons — AI's handwriting, right? Can design taste even be turned into a rule?"
🎯 What they're assessing
Whether taste can be turned into rules. Most people think rules only cover process and safety. Being able to cite concrete design-layer clauses shows you understand how far this ruleset actually reaches.
🧭 Answer framework
  1. Give the clause: Emoji as button icons is banned. Icons must be SVG.
  2. Give the selection method: Pick an icon set by product tone — Lucide for SaaS, Tabler Icons for a warmer tone.
  3. Give the engineering detail: Download icons and use them locally. No CDN dependency.
  4. Answer "can you": Yes. Taste decisions like this sit in the "docs and design standards" chapter, same as isComposing. Once taste is frozen into a rule, AI follows it on every generation — you don't have to hand-pick every version.
⭐ Bonus point Split the two layers of taste: Rule covers the common baseline (no emoji, use SVG); METHODOLOGY's "UX preferences" covers this project's specifics — confirm button always bottom-right, use the brand color. The two layers together are what make taste complete.
Organize your answer using these lesson pages → Writing Environment Facts into Rules Three Documents and Methodology Retention
Q29Interviewer
"You said this spec has 14 chapters. You've got 60 seconds. Walk me through the skeleton."
🎯 What they're assessing
The big picture and the ability to distill. Anyone who can't recite the map has probably only used two or three clauses. Anyone who can name the plates and the underlying logic is actually qualified to talk methodology.
🧭 Answer framework
  1. Name the five plates: Process control (breakpoint before coding), quality baseline (complete implementations, no "good enough"), doc retention (decisions survive across conversations), environment and safety (environment facts written once and frozen), communication and writing (anchoring and self-check).
  2. Give one representative clause each: More than 3 files, list a plan first; speculative fixes banned; three documents, each owning one dimension; backup, rollback, and diff audit as three gates; after 10 turns, restate the goal.
  3. Land on the shared bottom layer: Turn a fuzzy expectation into a concrete, executable action. "Watch the quality" cannot be executed. "Before deleting code you must declare it explicitly" can. All 14 chapters are doing that translation.
⭐ Bonus point Mapping chapter numbers is even sharper: environment and safety alone packs model config, data formats, tech stack, and deploy — four chapters. Being able to name the chapters inside the structure proves you read the rule text. Those 60 seconds are digested, not recitation.
Organize your answer using these lesson pages → The Value of Rules: Each One Solves a Real Problem
Q30Interviewer
"Suppose tomorrow we drop your ruleset into the company repo as-is and make everyone follow it. Are you in?"
🎯 What they're assessing
A closing trap. "Yes" and you've fallen in: this ruleset carries the author's project environment facts — copy it wholesale and it will crash. They want to know if you have an adaptation method, and the answer has to include trade-offs.
🧭 Answer framework
  1. Stop it first: Don't copy it as-is. The rules freeze the author's tech stack, ports, and format choices — those environment facts won't match your company. Copying all 14 chapters is worse than picking 5 well.
  2. Give four actions: Delete (if you don't create Chinese content, move writing standards out of .cursor/rules/ to cut irrelevant context), swap (replace the stack declaration with the company's), tune (the "more than 3 files, confirm first" threshold — 1 for cautious projects, 5 for rapid prototypes), add (turn mistakes AI keeps repeating on the team into new rules).
  3. Give a verification cycle: Run it on a real project for a full week. Record which rules fired and which never did. Delete the ones that never fired; write newly hit pits into new rules.
  4. Say why: Rules rot like code if nobody maintains them. Moving them in is only the start. Raising them is what counts as using them.
⭐ Bonus point Close the loop: the version after delete / swap / tune / add can be open-sourced. The original repo is MIT License and encourages Forking, adapting, and publishing your own. Getting this far shows you treat the rules as an asset you can keep iterating.
Organize your answer using these lesson pages → The Value of Rules: Each One Solves a Real Problem 4-Step Flow: Restate, PRD, Confirm, Code
One Final Piece of Advice
The best way to prepare these 30 questions is to run them on a real project: drop xs_vibe_rules into your project, run it for two weeks, and the incidents and rules will become your own stories. An interviewer can hear the difference between an answer with a story and an answer reciting a framework in seconds.

Why “Vibe Coding Methodology · 30 Tough Questions” depends on the operation

“Each with intent, framework, and bonus points: why make rules / quality ownership / code merge gate / reject installments / decision persistence / safety gates” makes the structure concrete. The useful comparison is not which name sounds more advanced, but how the data is arranged and how far the most common operation has to travel.

Read a structure through access and change

“Each with intent, framework, and bonus points: why make rules / quality ownership / code merge gate / reject installments / decision persistence / safety gates” exposes a trade-off that is easy to miss: reading by position, looking up by key, adding at either end, inserting in the middle, and traversing relationships do not favor the same organization. A structure that is fast for one operation is not automatically fast for all of them.

  • Define Vibe Coding first: A development approach where you use natural language to have AI produce code directly. The problem has always been quality — moving fast just amplifies h…
  • Pinpoint the shared root cause: All four stem from the same issue — constraints never made it into context. AI can forget what you told it in every new conversation turn
  • Accept accountability first: bugs are always on the human — AI is a tool. The purpose of this framework is to give humans a sign-off opportunity at every critical node, so any fail…

Count scale and update frequency together

Use “Each with intent, framework, and bonus points: why make rules / quality ownership / code merge gate / reject installments / decision persistence / safety gates” as a boundary check. Write down the data size, the dominant operation, and the latency you can accept before deciding whether an AI-generated structure actually fits.

Take the example one step further

The lesson starts with “Define Vibe Coding first: A development approach where you use natural language to have AI produce code directly. The problem has always been quality — moving fast just amplifies how badly things can go wrong” and then moves to “Pinpoint the shared root cause: All four stem from the same issue — constraints never made it into context. AI can forget what you told it in every new conversation turn”. Reading those two pieces together makes the distinction clearer: which points are facts in the lesson, and which judgments depend on their conditions.

Carry the judgment into the next situation

When you meet a new data structure, do not begin by memorizing its definition. Write down the most frequent operation, estimate scale and update behavior, and check whether the structure satisfies all three conditions.

  • “Vibe Coding Methodology · 30 Tough Questions”: Define Vibe Coding first: A development approach where you use natural language to have AI produce code directly. The problem has always been quality — moving fast just amplifies how badly things can go wrong
  • “Take it further”: Pinpoint the shared root cause: All four stem from the same issue — constraints never made it into context. AI can forget what you told it in every new conversation turn
  • “The closing point”: State the rule: No simplifying implementations for any reason, and AI is banned from proactively planning phased delivery or MVPs. Every implementation must be complete, correct, and debt-free

The final “The closing point” brings the discussion to “State the rule: No simplifying implementations for any reason, and AI is banned from proactively planning phased delivery or MVPs. Every implementation must be complete, correct, and debt-free”. The useful thing to carry forward is knowing which judgments must be revisited when input, scale, or risk changes.

Mark as learned Your reading progress updates automatically
← PreviousNext →

Keep reading

The next useful article in the thread.

What You Can Do Now · Hands-onDistill Your Own Collaboration SpecA four-step flow comparison; three tasks: write your first Rule, walk a real requirement through the flow, export the Build Log and shape it into spec v1Topic Wrap-Up · FinaleThe Value of Rules: Each Solves a Real ProblemOverview recap + usage guide + four actions to adapt rules to your own projectCommunication & Writing · InteractiveLong-Chat Anchoring & Writing StandardsForce a goal restatement after 10+ turns; a banned-phrases list to rid copy of AI-speakEnvironment & Safety · InteractiveThree Gates for Destructive OperationsBackup the DB first; provide a rollback plan for irreversible ops; diff review before release

ARTICLE DISCUSSION

Leave one useful thought here.

Keep the idea that clicked, the question that stayed open, or a small note for the next learner.

↗
Discussing Vibe Coding Methodology · 30 Tough Questions Vibe Coding, With Guardrails
3discussionsArticle discussion · synced with the Circle
View in the learning circle
AM
Asha MorganContent editor
INSIGHTField note

I turned one judgment from this article into a small experiment I could run today. Knowing what to observe next is more useful than simply remembering the conclusion.

ARTICLE DISCUSSION7 helpful
LH
Lin HarperIndie developer
INSIGHTInsight

After reading this, I first looked for the conditions behind the idea instead of copying the method into a project. That order made the later trade-offs much clearer.

ARTICLE DISCUSSION5 helpful
KM
Kiki MooreProduct operations
QUESTIONQuestion

When this judgment reaches real work, which constraint should be added first? I am curious which step matters most between reading and the first practical attempt.

ARTICLE DISCUSSION4 helpful