Vibe Coding / Agentic Flow Interview Question Set

Note: There is no single standard answer for this question set. The “reference answers” are mainly meant to inspire thinking and help readers build their own judgment frameworks.

Target audience: Developers using agentic CLI tools such as Claude Code and Codex every day, especially those who want to upgrade AI programming from “human-computer chatting” to an “engineering-grade workflow.”

Table of Contents

1. Background Knowledge 2. Detail Clarification 3. Workflow 4. System Design: Open Discussion 5. Conceptual Philosophy: Open Discussion 6. Appendix: Recommended Learning Path 7. Reference Links

1. Background Knowledge

Q1. What is /command? How is it different from skill, and when should I use command versus skill?

Reference Answer

/command, or Slash Command, is Claude Code’s early extension mechanism. Users can place .md files under .claude/commands/ and trigger them by typing /command-name in the conversation. In essence, it is “a snippet of prompt text explicitly invoked by the user.”

Skill is a newer extension mechanism, typically located at .claude/skills/<name>/SKILL.md, ~/.claude/skills/, or in a plugin. Its main difference from command is that it can be:

In practice, nearly all new scenarios should prioritize skill. Especially when you want the model to auto-enable a procedure at the appropriate moment, or you need scripts, sample files, and templates attached, skill is the better choice.

command still has value for a few simple scenarios, such as legacy team assets or prompts that must be explicitly invoked by the user. But in new projects, it is not recommended to heavily depend on command.

Q2. What is an agent? When should you use an agent, and when should you use a skill?

Reference Answer

An Agent, especially a Sub-agent, can be understood as a “small Claude” with its own system prompt, independent context window, and independent tool allowlist. In Claude Code, a sub-agent is typically defined under .claude/agents/<name>.md and receives tasks dispatched from the main conversation. After a sub-agent completes the task, it only returns a summary to the main thread; the extensive search, reads, and logs in between do not pollute the main context.

A Skill, in contrast, is a set of instructions or procedures. It does not open a new context; instead, it guides Claude on what to do in the current conversation.

A simple rule of thumb:

• If the task is to tell Claude a workflow, such as “run lint and tests before committing,” use a skill.
• If the task generates a lot of tool output, such as reading dozens of files, running many greps, or analyzing logs, use an agent.
• If the task is just reading one known file, read it directly in the main conversation; no need for an agent.
• If the full reasoning process should remain in the main conversation, do not hand it to a sub-agent.

Q3. What is a Sub-agent? Can sub-agents communicate with each other?

Reference Answer

A core feature of a sub-agent is independent context, independent tool sets, and returning only a summary to the main conversation.

By default, sub-agents cannot communicate directly with each other. Their communication model is more like a star topology: the main conversation is the central node, and all sub-agents only communicate with it. If findings from A agent need to be passed to B agent, the main conversation typically relays them.

This design has advantages:

• Information is aggregated in the main context, making user audit easier.
• It prevents uncontrolled feedback loops between agents.
• It avoids context and tool-calling costs from spiraling out of control.

An experimental Agent Teams model may introduce peer-to-peer messaging between agents, but that is a much more complex collaboration model.

Q4. What is the biggest difference between Agent Team and Sub-agent?

Reference Answer

A sub-agent is more like “hiring a temporary contractor to do one thing and report back.” It is usually one-off: the main conversation assigns a task, the sub-agent executes it, and then returns a summary.

An Agent Team is more like “building a long-term collaborative small team.” Each teammate can have an independent role and context, and may communicate with each other via a messaging mechanism.

In practice, most day-to-day development tasks are already covered by sub-agents. Agent Team is closer to research in multi-agent collaboration, suited for complex projects, but harder to debug.

Q5. What is MCP? How is it different from API interfaces?

Reference Answer

MCP, the Model Context Protocol, is a protocol for exposing external tools, resources, and prompts to LLM clients in a standardized format. An MCP server can declare which tools, resources, and prompts it provides; once connected, the client can discover and call them automatically.

You can understand the difference between raw APIs and MCP like this:

To analogize: an API is “a different-shaped cable for each vendor,” while MCP is more like a USB-C designed for LLM tool calling.

Its core value is not just data transport, but giving tools “self-describing capability”: the model can know what a tool is called, what parameters it expects, whether it is write-capable, and whether confirmation is required, enabling informed reasoning about when and how to call it.

Q6. Can a Sub-agent spawn its own sub-agent?

Reference Answer

Usually not. A sub-agent should not start its own sub-agent.

This design is mainly to avoid three issues:

1. Infinite recursion: If agents can spawn agents indefinitely, the call tree can quickly become unmanageable. 2. Un-auditable information: With deep nesting, it becomes hard for the main conversation to know what happened at each layer. 3. Context and cost explosion: Each layer can have independent context, causing cost and latency to rise rapidly.

If you truly need “nested delegation,” better approaches are:

• Have the main conversation dispatch multiple sub-agents in a flat manner.
• Use skills inside sub-agents to organize steps.
• For highly complex tasks, consider Agent Team, but set clear boundaries and budgets.

2. Detail Clarification

Q7. What are CLAUDE.md and AGENTS.md? What is their load order and priority?

Reference Answer

CLAUDE.md and AGENTS.md can be understood as persistent prompt injection at project and user levels. They declare rules that the agent should know on every startup, such as code style, test commands, forbidden files, and commit standards.

Common levels include:

It is better not to write these as a project intro article; they should be hard rules the agent must follow. For example:

• Read related tests before modifying code.
• Do not modify .env or secret files.
• Run npm run typecheck before finishing.
• Do not add unnecessary dependencies.

A practical tip: keep each file to around 200 lines whenever possible. If it gets too long, split it into separate documents and organize via references.

Q8. What are Hooks? List several common hook scenarios.

Reference Answer

A hook is a deterministic callback registered on lifecycle events in Claude Code or similar agentic tools. It is not something the model “remembers to do”; it is enforced by the tool runtime.

Common events include:

• Before tool calls: for example, blocking dangerous commands.
• After tool calls: for example, auto-formatting after file edits.
• Session start: for example, injecting current git status.
• Stop: for example, sending desktop notifications.

Common scenarios include:

The value of hooks is in being “deterministic.” A prompt can be ignored by the model; a hook is an enforcement constraint at the tool level.

Q9. What Permission Modes are there, and what scenarios are they suited for?

Reference Answer

Permission Mode determines whether the agent needs user confirmation to execute file reads/writes, run commands, or call external tools.

In general, the closer to production, the more conservative permissions should be; the closer to one-off experiments or isolated sandboxes, the more permissive.

Q10. During /compact, what context is retained and what is lost?

Reference Answer

The essence of /compact is context compression. It keeps some high-priority information, but does not fully preserve historical tool-call details.

Typically retained or re-injected content includes:

• The system prompt.
• Project-level rule files, such as CLAUDE.md.
• User or project memory.
• Conversation summaries.
• Some high-priority skill descriptions.

Content likely to be lost includes:

• Full output from historical tool calls.
• Details from files read but not written to persistent files.
• Temporary agreements that existed only in the conversation.
• Full schemas for tools that are lazily loaded.

A practical recommendation: do not keep long-term constraints only in chat. Important rules should be written into CLAUDE.md, AGENTS.md, memory, PROGRESS.md, or project documentation.

Q11. What is the relationship between Plugin and Skill?

Reference Answer

A skill is a unit of capability; a plugin is a packaged, distributed extension bundle.

A plugin may include:

• Multiple skills.
• Sub-agent definitions.
• Hooks.
• MCP server.
• LSP server.
• Binary tools.
• Default settings.

You can think of it this way: skill is a part, plugin is a packed toolbox. If a team has a stable AI coding process, it can package it as a plugin so new members can install it in one click.

Q12. What are ToolSearch / Deferred Tools, and why were they designed this way?

Reference Answer

The core idea of Deferred Tools is: do not load full schemas for all tools into context at startup. Instead, only make tool names known first. When the model actually needs a tool, ToolSearch (or a similar mechanism) loads detailed parameter structure on demand.

Design reasons include:

1. Token savings: large MCP servers may expose dozens or even hundreds of tools, and fully loading all schemas consumes substantial context. 2. Reduced attention noise: keeping unrelated tools in the prompt for too long can interfere with model decisions. 3. On-demand loading: detailed descriptions are only loaded when truly needed.

The trade-off is that first-time use of a tool may require one extra round trip, but overall it is more efficient.

3. Workflow

Q13. When you receive a moderately complex new feature task, how should you break it down with agentic tools?

Reference Answer

A typical process can be:

1. Enter plan mode first and explore the code read-only without editing. 2. Use Explore sub-agents in parallel to search related files and identify entry points, data flow, and test locations. 3. Have the main conversation or a Plan sub-agent produce a TDD-style plan: acceptance criteria, test cases, minimal implementation, verification strategy. 4. Use a second model or review agent for cross-model review to fill blind spots. 5. Ask the user at key design forks rather than unilaterally deciding high-impact changes. 6. Exit plan mode and enter editable mode. 7. Write or update tests first, then implement. 8. Run relevant tests, typecheck, and lint after implementation. 9. Finally self-review using a review skill or a code-review agent.

The key is not that “opening many agents feels advanced,” but splitting exploration, design, implementation, verification, and reflection into distinct phases.

Q14. When should you launch a sub-agent, and when should you not?

Reference Answer

Situations to launch a sub-agent:

• You need to read more than 10 files for research.
• You need to run a lot of grep, find, or log analysis.
• You need independent code review or security review.
• You need to process multiple independent subtasks in parallel.
• Tool output will be very large and you do not want to pollute the main context.

Situations not to launch a sub-agent:

• The task requires only 1–3 tool calls.
• It only needs reading a known path.
• The task needs frequent user confirmation.
• You want the full reasoning process preserved in the main conversation.

One line: sub-agents are suitable for “heavy search, heavy reads, heavy logs” tasks, and not for “quick, one-and-done” tasks.

Q15. How can you prevent main-context pollution?

Reference Answer

You can control this from several angles:

• Delegate heavy reading and research to Explore sub-agents and only ask them to return summaries.
• Limit long command outputs with head, tail, and grep; avoid pushing thousands of log lines into the conversation.
• Package repetitive processes into skills instead of pasting large rule blocks every time.
• Run /compact after completing phases.
• Write important long-term information into CLAUDE.md, AGENTS.md, memory, or PROGRESS.md.
• Don’t have the agent read the same file repeatedly; verify file state via diff, tests, and version control.

The core principle is: context quality is not about more tokens, but a higher signal-to-noise ratio.

Q16. How should you debug a code bug using agentic tools?

Reference Answer

A safer process is:

1. Don’t edit immediately; reproduce the bug first. 2. Write a minimal test or minimal case that fails consistently. 3. Confirm the test truly fails so you know you understand the issue. 4. Use Explore to find related files on the bug path. 5. Form hypotheses and verify each one instead of patching by guesswork. 6. Run relevant tests after fixing. 7. Finally run full or critical validation commands. 8. If the agent fails repeatedly, stop the current context and either switch approaches or ask another model for independent diagnosis.

The biggest danger in agent debugging is “guess, patch, patch, patch.” Without a reproducible case, the model can easily make the code messier while trying to fix it.

Q17. In a multi-developer repository, how can you make agentic workflows team-oriented?

Reference Answer

The key is turning individual experience into repository-level assets.

Shared layer can include:

• Repo-root CLAUDE.md / AGENTS.md: team hard rules.
• .claude/skills/: shared workflows.
• .claude/agents/: shared sub-agents.
• .claude/settings.json: shared permission, hooks, tool allowlist.
• PR templates: require documentation of AI-driven key decisions and validation commands.

Personal layer can include:

• CLAUDE.local.md: personal preferences, usually uncommitted.
• .claude/settings.local.json: personal permission overrides.

Further, teams can package common capabilities as a plugin for unified installation, upgrade, and maintenance.

4. System Design: Open Discussion

The questions below have no standard answer; the focus is on building trade-off frameworks and risk awareness.

Q18. If you are designing a low-code platform with agentic capabilities, what principles should be prioritized first?

Discussion Direction

First, establish the source of truth. Is the final authority agent-generated code, or the low-code DSL? Bidirectional synchronization sounds ideal, but in practice it can quickly become engineering hell.

You also need to consider:

• Reversibility and version control: if an agent changes 50 components at once, it must be diff-able, revertable, and reviewable.
• Sandboxing and permission tiers: platform users’ agents should not access databases directly; they must go through a permission gateway.
• Context provisioning: how does business knowledge enter the agent—through user-written rules or automatic extraction from existing docs?
• Failure observability: when agents call third-party APIs or MCP and fail, you must be able to replay.
• Critical decision confirmation: do not replace user judgment; high-impact decisions must be explicitly confirmed.
• Cost visibility: token usage, API calls, and latency per operation should be visible.

A good agentic low-code platform is not a “magic button,” but an auditable, rollback-capable, composable engineering system.

Q19. When designing an enterprise MCP gateway, how should permissions, auditing, and rate limiting be handled?

Discussion Direction

An enterprise-grade MCP gateway should handle at least the following:

• Permissions: different roles can see different tools. Read-only roles should not see delete_* tool schemas.
• Auditing: each tool call should record user, agent_id, parameters, return size, latency, and result status.
• Rate limiting: restrict QPS, concurrency, and daily call volume per user or per agent.
• Data masking: sanitize PII, keys, and sensitive internal fields before returning data to the agent.
• Degradation strategy: return structured errors when back-end services fail instead of waiting indefinitely.
• Version management: tool schema changes need versioning to prevent older clients from breaking unexpectedly.
• Tenant isolation: tools and data for different teams and projects must be isolated.

The core of an MCP gateway is not “connecting more tools,” but “letting models use tools safely.”

Q20. Should multi-agent collaboration models be star-shaped or mesh-shaped? Why?

Discussion Direction

A star topology is clear, controllable, and easy to audit. The main conversation is the center, and all sub-agents report to it. The downside is that the main conversation can become a bottleneck and concurrency is limited.

A mesh topology is closer to real teams, where multiple agents can communicate with each other, with potentially higher parallelism. But issues are obvious:

• Agents can loop in conversations.
• Context can explode.
• Boundaries of responsibility are unclear.
• Debugging complexity rises sharply.

In practice, most tasks are sufficiently served by a star structure. A mesh is worth trying only for complex, multi-role tasks, and then only with strict message budgets, thread limits, conversation-graph visualization, and strong auditing mechanisms.

A deeper question: is the ROI of multi-agent collaboration truly higher than that of “one stronger single agent”? If model capability keeps improving, multi-agent orchestration may only have stable value in limited complex scenarios.

Q21. If you design an AI security review agent, what pitfalls should you avoid?

Discussion Direction

A security review agent cannot only look at diff. Many security issues appear in call chains and context, not just in a few changed lines.

You should also avoid:

• Blindly trusting passing tests: vulnerabilities often hide where tests don’t cover.
• Executing attack commands yourself: review phases should be mostly read-only, avoiding turning a review agent into an attack surface.
• Aiming for zero false positives: safety review should tolerate reasonable false positives rather than miss high-severity issues.
• Lack of severity tiers: you must differentiate P0/P1/P2 so humans can prioritize.
• Lack of explainability: it is not enough to say “unsafe”; explain why, what impact it has, and how to fix it.

A safer approach is one model for review, another model for cross-checking, then a human to make the final judgment.

Q22. How should you design a long-term memory mechanism, and what should be remembered or not remembered?

Discussion Direction

You should remember:

• Code style repeatedly corrected by the user.
• Project-level hard constraints.
• Common commands.
• Long-lived engineering information that is easy to forget, such as ports, test entry points, and documentation locations.

You should not remember:

• One-off temporary conversations.
• Sensitive content.
• Bug states that are already outdated.
• Guesses whose long-term validity is uncertain.

Long-term memory also needs an update mechanism: deduplicate on write, avoid duplicates; periodically clean stale entries; allow users to review, edit, and delete. Cross-project sharing must be careful: preferences may transfer across projects, but project-specific knowledge should not.

5. Conceptual Philosophy: Open Discussion

Q23. Why keep context simple? Isn’t a prompt packed with information better?

Discussion Direction

Context value is not about length; it is about signal-to-noise ratio.

Packing too much information causes several issues:

• Attention dilution: key rules are drowned out by unrelated information.
• Higher cost: every reasoning step must process more tokens.
• Higher latency: long context usually means slower responses.
• Lower debuggability: when something goes wrong, it is harder to identify which rule conflicts.
• Poor evolvability: complex prompts become spaghetti and get messier as they evolve.

Good context is not “less information,” but “only the information truly needed for the current task.”

Q24. Should an agent be proactive or reactive? When should it ask the user, and when should it decide on its own?

Discussion Direction

You can evaluate using three dimensions:

1. Reversibility: reversible local edits can be decided by the agent; push, delete, and send email should be asked. 2. Impact radius: being proactive is more suitable for local-only effects; team-wide, production, or customer impact requires caution. 3. Uncertainty: if the agent is not confident, it should ask rather than gamble.

A good agent is neither “asks everything” nor “asks nothing,” but asks the right questions: it should ask at key forks and avoid bothering on trivial details.

Q25. Is Vibe Coding hype, or a paradigm shift?

Discussion Direction

The hype camp says: this is just smarter autocomplete. In complex projects, agents still make basic mistakes, and maintenance cost is underestimated.

The paradigm camp says: the primary unit of programming is moving from “line/function” to “intent/constraint.” Engineers shift from typists to architects, reviewers, and system designers.

A sensible middle ground is: it is indeed a paradigm change, but not a 1:1 replacement. It amplifies high-skilled engineers because they can provide better specs and reviews; it also amplifies low-quality output from less capable users because they can now produce bad code faster.

The key questions are:

• If an agent writes code, where is knowledge consolidated? In the repository, documentation, tests, or an individual’s brain?
• Will code review become more important than writing code itself?
• How will junior roles and programming education change?

Q26. If an agent keeps fixing a bug incorrectly, should it keep trying, or should it be shut down and restarted?

Discussion Direction

If the agent keeps trying the same wrong fix repeatedly, that likely means the context is polluted. Keeping it burning tokens usually just deepens the dead-end.

Better practices are:

• Set a retry cap for the agent, such as stopping after 3 consecutive failures.
• Stop the current patching loop, then reframe the minimal repro, logs, and failing tests.
• Switch models for independent diagnosis.
• Take over key paths manually when necessary.

When an agent gets stuck, it is usually not because it “isn’t trying hard enough,” but because of missing information, unclear tests, context pollution, or wrong direction.

Q27. Why is TDD more important in an agentic workflow than in a traditional workflow?

Discussion Direction

Agents can confidently write the wrong thing. They may craft wrong APIs, fields, and return values. Testing is one of the few objective mechanisms that tells you whether the task was actually completed.

TDD is especially important in agentic workflow because:

• Tests are a contract with the agent.
• Failing tests provide a clear feedback loop to the agent.
• Tests turn vague requirements into executable specifications.
• Acceptance tests prevent “looks done, but actually incomplete.”

But also be careful: don’t let the agent write tests, implement code, and declare pass entirely by itself. Critical acceptance and security tests should be written by humans, or independently reviewed by another model.

Q28. “Agent-generated code is often unreadable.” What is the remedy? Is it a tool problem or usage problem?

Discussion Direction

Both.

On the tool side, models can over-abstract, over-defend, and over-comment. On the usage side, if users provide no constraints, do not review, and accept first try blindly, bad code will accumulate.

Actionable fixes include:

• Specify readability hard rules in CLAUDE.md or AGENTS.md.
• Restrict function length, naming style, and comment style.
• Add “simplify/refactor/remove-redundancy” as explicit steps.
• Enforce self-review using a code-review skill.
• Require human diff review for critical modules.

If you never read code written by the agent, you are effectively outsourcing production code to an unaccountable intern.

Q29. “I let an agent run all night, and I don’t understand what it did” — is this the agent’s problem or the user’s problem?

Discussion Direction

Responsibility is shared by both sides.

Tool providers should provide observability: file diffs, command logs, key decision points, failure records, and periodic summaries.

Users also need boundaries: do not let agents run overnight without constraints. Long tasks should be split into stages, each with clear goals, permission scope, and checkpoints.

The longer the autonomous task, the stronger the controls needed. A fully unsupervised long-running agent is like an unsupervised junior intern with sudo in production—it carries high risk.

Q30. Will agentic tools eventually make the programmer profession disappear?

Discussion Direction

The more likely outcome is not “programmers disappear,” but “programmers move to a higher level of abstraction.”

Roles most likely to weaken are those that only translate clear specs into code. Still essential are: understanding requirements, breaking systems down, judging correctness, taking ownership, and maintaining long-term architecture.

Roles that may become more important include:

• Agent Architect: designs agent collaboration graphs, skill libraries, and context strategies.
• AI Reviewer: performs high-speed review of agent outputs.
• Context Engineer: structures domain knowledge into forms that agents can consume.
• Engineering Lead: decides which tasks to automate and which must remain under human control.

A historical analogy: compilers did not eliminate programmers, but they drastically reduced people writing assembly by hand. AI agents may be similar: not replacing engineers, but pushing them to a higher abstraction layer.

6. Appendix: Recommended Learning Path

Beginner Stage

Start with official documentation and get basic capabilities working:

• Project rule files: CLAUDE.md / AGENTS.md
• skill
• agent
• hooks
• /compact
• memory
• Codex / Claude Code basic permission modes

The goal is not to memorize concepts, but to know which problem each one solves.

Intermediate Stage

Package your three most common tasks, for example:

1. Generate commit messages. 2. Write PR summaries. 3. Automatically run tests and typecheck after code changes.

The goal at this stage is to upgrade from “I tell AI the same thing every time” to “I turn my workflow into project assets.”

Advanced Stage

Set up a full agentic workflow for team or personal projects:

• CLAUDE.md / AGENTS.md: long-term rules.
• skills/: reusable procedures.
• agents/: specialized roles for research, review, and debugging.
• hooks/: deterministic constraints.
• PROGRESS.md: long-task state tracking.
• TASKS.md: task decomposition.

Expert Stage

Start tackling more complex issues:

• Permission decisioning for hooks on PreToolUse.
• MCP gateway and enterprise permission models.
• Message budgets and auditing in multi-agent collaboration.
• Checkpoint design for long overnight workflows.
• How tests, documentation, and rule files together become reliable agent context.

7. Reference Links

• Claude Code Docs: llms.txt
• Claude Code Docs: Hooks Reference
• Claude Code Docs: Automate workflows with hooks
• OpenAI Codex: Get started
• OpenAI Codex GitHub Repository
• OpenAI Codex: Installation Docs
• OpenAI Cookbook: Codex Prompting Guide

For more Codex practice, see Getting the Most Out of Codex; if you want to switch quickly between Claude tools, see CC Switch Tool Introduction.

FAQ

What level of developer is this article suitable for?

Refer to the “Target audience” in the main text. Articles in this programming category cover different levels from beginner to AI programming workflow, each with different assumed backgrounds.

Will tools or commands in this article differ across systems?

They will. macOS, Linux, and Windows differ in terminal environments, path formats, and command syntax. If the article does not specify the OS, adjust according to the official documentation for your platform.

Which AI tools are recommended for learning programming alongside this approach?

Claude Code and Codex are currently the strongest programming AI tools and can be used for code explanation, logic completion, debugging, and script generation. You can refer to the CC Switch Tool article and Vibe Coding Interview Question Set for related tool introductions.

What is the most important habit for learning programming?

Hands-on practice is more important than watching tutorials. It is best to find a real project as early as possible, even if small, and, when encountering problems, read the docs and code instead of just finishing theory and stopping.