How They Will Quiz You

Vibe Coding Methodology · 6 Soul-Searching Questions

Nothing invites more skepticism than using AI to write code. These 6 questions come from three real-world scenarios — most from managers and dev colleagues. Try answering out loud first, then check the framework.

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 Are Testing
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 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.
Use these lesson pages to build your answer → 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 Are Testing
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 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.
Use these lesson pages to build your answer → 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 Are Testing
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 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.
Use these lesson pages to build your answer → 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 Are Testing
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 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.
Use these lesson pages to build your answer → 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 Are Testing
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 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.
Use these lesson pages to build your answer → 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 Are Testing
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 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.
Use these lesson pages to build your answer → Three Gates for Destructive Operations Writing Environment Facts into Rules
One Final Piece of Advice
The best way to prepare these 6 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.