Vibe Code Engineering
Claude is a pioneer in agentic coding AI. It's the most stable and structured so far. I worked on parallel worktree feature with harness and it amazes me. While I like to use Antigravity for their speed, planning and browser debug. The speed of Antigravity is amazing, I can't multitask more than two projects.
Prompt Engineering Tips
The prompt must contain:
- Clear hierarchy using Markdown
- Give LLM a role, background, constraints (environments, version), task & goal and IO format
- Let the model to ask for conformation when it's uncertain
- Avoid ambiguity and conflicts
- The cleaner the better
Prompt Examples
Template for a Vibe Coding a Project
I like to drive a few devdocs using markdowm. Each files should focus on one category and located on the top of the specific folder. Use AGENTS.md as the main file to guide the agent. For claude, CLAUDE.md is used.
## Goal
## Keep In Mind
- Write a summary of how each components works and the architecture of the system
- Write the history of method eliminations consideration, tradeoff and conclusion
- Keeps things in modular. Don't over-engineer one-time use component. Start with simple solution, when things starts to duplicate and grow, refactor earlier
- Add comments for non-obiouvs logic, do not remove comments or unrelated code unless specified
- Clean temporary files when the project ends.
- Make reusable scripts and backward compatibility
- Every script must have CLI for your execution
## Architecture Reference
Remember to refer these before doing any related action
- `devdocs/AGENTS.md` — Extended development guidelines. Always read this
- `devdocs/UTILSPEC.md` - Data model and util specs
- `devdocs/FLOWSPEC.md` — Pipeline detail
- `dev/EXPERIMENT_SPEC.md` - Experiment instructions
| Behavior | More | Less |
|---|---|---|
| Effort | Put more effort into evaluating the possible risk and potential. You may suggest a method that is beyond to reach the goal. | Strictly follow the instructions and ignore non-related stuff. |
| Responseness on Ambiguity | When in doubt, respond directly. | When in doubt, pick the one with more meaningful quality improvement that the user will agree with and stick with it. Only consider other method when you have eliminate all other cause and this method itself is the problem. |
| Thinking Effort | Think through this step by step before giving your final answer | Thinking adds latency and should only be used when it will meaningfully improve answer quality |
| Explaination | Explain the problem, root cause, fix, your consideration, and prevention. | Do minimal explanation, eliminate preambles (things like… based on…) |
| Over Engineering | Please write a high-quality, general-purpose solution. Consider the future extension and backward compatibility. Add comments when the logic is less intuitive. Identity modules that will be reused. Make things modular. Do not hard-code things that’ll work on this instance. | Avoid over-engineering. Only make changes that are directly requested or clearly necessary. Keep solutions simple and focused. Only add comments where the isn't self-evident. Only validate at system boundaries. Don't create helpers, utilities, or abstractions for one-time operations. Don't design for hypothetical future requirements. The right amount of complexity is the minimum needed for the current task. |
Systematic Edit: Consider the reversibility and potential impact of your actions. You are encouraged to take local, reversible actions like editing files or running tests, but for actions that are hard to reverse, affect shared systems, or could be destructive, ask the user before proceeding.
Detect for Risk: Report every issue you find, including ones you are uncertain about or consider low-severity. Do not filter for importance or confidence at this stage - a separate verification step will do that. Your goal here is coverage: it is better to surface a finding that later gets filtered out than to silently drop a real bug. For each finding, include your confidence level and an estimated severity so a downstream filter can rank them.
Saving Work: As you approach your token budget limit, save your current progress and state to memory before the context window refreshes. Always be as persistent and autonomous as possible and complete tasks fully, even if the end of your budget is approaching.
Clean Temporary Files: If you create any temporary new files, scripts, or helper files for iteration, clean up these files by removing them at the end of the task.
Shortcuts: When encountering obstacles, do not use destructive actions as a shortcut. Report for any shortcut you used.
<investigate_before_answering> Never speculate about details and code you have not confirmed. If the user references a specific file, you MUST read the file before answering. Make sure to investigate and read relevant files BEFORE answering questions about the codebase. </investigate_before_answering>
<do_not_act_before_instructions> Do not jump into implementation or changes files unless clearly instructed to make changes. When the user's intent is ambiguous, default to providing information, doing research, and providing recommendations rather than taking action. Only proceed with edits, modifications, or implementations when the user explicitly requests them. Make sure you don't run out of context with significant uncommitted work </do_not_act_before_instructions>
Optimal Step: Carefully reflect on quality and determine optimal next steps before proceeding
Avoid Saving Token: Do not consider about token budget and go further
Self Reflection: Now argue against what you just said.
Parallel Subagent: Use subagents when tasks can run in parallel, require isolated context, or involve independent workstreams that don't need to share state. For simple tasks, sequential operations, or tasks where you need to maintain context across steps, work directly rather than delegating.
Parallel Tool: Prioritize calling tools simultaneously whenever the actions can be done in parallel rather than sequentially to increase efficiency.
How to Start and Scale
Start with Prepare PRD (Product Requirements Document) or SDD (Spec-Driven Development). Spend most time and resource on planning. Use lighter model to implement. Start with Minimal Viable Product, the core (v1). Add single feature on each version, and verify before moving (v2).
- Overview
- Tech stack
- Directory architecture
- Code convention
- API
- Test
- Dependency order and modularity
Prompt Philosophy
Human language is a bridge between human's embedding to AI's embedding. When you don't know the exact term to express, use multiple scenario to scope down the meaning. AI tends to mirror your ideas, being too agreeable. You may say speak like a ..., not just to purely critique you, but to give a "rational" perspective. Stop the AI when it's too agreeable, remind of it's contradictions to train the AI to your expectations.
Kiro

Kiro is an AI agent IDE that can communicate to explore requirements and understanding the specs. After requirements, design, tasks and tests method is confirmed, it will start implement.
Vibe Coding Engineering
Token Engineering
| Strategy | Description | Effect |
|---|---|---|
| Prompt Trimming | Remove redundant words, trim System Prompt | Medium |
| Context Trimming | Keep the most recent and important conversation records (model will be stupid after 40% of context) | High |
| Summary Replacement | Replace full long conversation history with summary (save on md) | High |
| Tool Result Truncation | Limit the amount of data returned by the tool (limit listing) | Medium |
| Model Stratification | Use small models for simple tasks (plan) and large models for complex tasks (implement) | High |
| Cache Mechanism | Reuse the results of similar queries | Depends |
API have a clever design: It's more expensive per token, this motivates the work to give short and precise input token.
Sub-Agent Engineering
Main goal is to control context, reducing context on main agent, create a abstraction for a specific task returning summary for main agent. Subagent should do the planning, implementation and validation.
- Make a spec and plan in md files
- Keep main context clean, reduce noise
- Save progress in md files
- One task every session
- Clean state after a session completion
- Handle clean info for others
- Able to reproduce initialization and states
- Use structured data like JSON to keep consistency
- Create CLI tool for repeated task
Claude Code
Claude Code Architectual Structure
| Components | Files | Description |
|---|---|---|
| Context Management | claude-progress.txt, feature_list.json | session (short term memory) and task list (long term memory) |
| System Prompt | CLAUDE.md | Role definition + constant rules (system prompt layer) |
| Lifecycle Hooks | settings.json hooks configuration | Event-driven control layer |
| Sub-agent | .claude/agents/ sub-agent role definition (.md files) | Sub-agent role definition |
| Skills | .claude/skills/ knowledge base injection | Knowledge base injection |
| Slash Commands | .claude/commands/ SOP (Standard Operating Procedure) | Controllable SOP for repetitive tasks |
npm install -g @anthropic-ai/claude-code
claude login
claude logout
claude # Start a session in terminal
claude -w my-new-feature # Create a isolated worktree to develop a feature in parallel
Worktree
A worktree is a lighther git clone on another folder to develop in parallel, symlinking shared heavy files. It inherite .gitignore. Add .worktreeinclude to include ignored files.
Session
When the context window is around 40%, Claude Code start to act less smart. So we need to control the context window by prompting.
- Give a specific example
- Point a good example
- Do one thing at a time
- Flywheel & Guardrail: incrementally tell what not to do
Session Command
| Command | Desc |
|---|---|
/clear | Clear context window |
/compact | Sumamrize context window |
/remote-control | Enable this session to be accessed by web (claude.ai/code/) or app remotely. Remember to keep the terminal alive |
/web-setup | Authenticate with local GitHub credential to run a cloud instance at Anthropic cloud. No local setup required and code at (claude.ai/code/) |
Configuring Command Permission
{
"defaultMode": "acceptEdits",
"permissions": {
"allow": [
"Read(//opt/**)",
"Bash(./venv/bin/python3 run.py)",
"Bash(npm run *)",
"Bash(git *)",
"Bash(mkdir:*)",
"Bash(ls:*)",
"Bash(find:*)",
"Bash(grep:*)",
"Write(*)",
"Read(*)",
"Bash(tail)"
],
"deny": [
"Read(.env*)",
"Bash(rm *)"
]
},
"hooks": {
"Stop": [
{
"hooks": [
{
"type": "command",
"command": "echo "Run Test"
}
]
}
]
}
}
--dangerously-skip-permissions is "YOLO mode" CLI flag, bypasses all permission checks, allowing Claude Code to execute all operations without any prompts. bypassPermissions is the defaultMode value you set inside settings.json. It skips permission prompts, though writes to .git, .claude, .vscode, .idea, and .husky directories still prompt for confirmation to prevent accidental corruption.Token
| Plan | Description |
|---|---|
| Pro plan | Reach limit very quick. Suitable for frequent light use. |
| API | A 2-hour session cost [[]{.katex-mathml}[[[]{.strut style="height:0.8889em;vertical-align:-0.1944em;"} 6perdeveloperperday,with90 ]{.base}]{.katex-html ariaHidden="true"}]{.katex} 12/day |
| Max 5x ($100/mo) | Suitable for heavy user |
Subagents
Subagent is child of agent. Parent is the center of orchestration, Claude code can spawn multiple subagent to target specific task, reducing context window.
Agent Teams
A new concept of a team of leads, a shared task list, and specialized teammates sharing messages with one another. This is really beneficial for parallel research and development. However, it might take 3~4x more tokens compared with developing sequentially. Enable it through settings.
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
Harnness
Harness is an “architecture/frame” to follow iteratively. Enable the agent to adjust the harness. Allow other agents to specialize in judging. Make the planner and the judger agree before and after implementing
Stage 1 (2-Agent)
Initializer + Coding Agent. The result might not be working
Stage 2 (3-Agent)
Planner + Generator + Evaluator. Create a sprint contract to decide what success looks like
Stage 3
Remove sprint architecture, simplify the code, cleaning and removing debt
Harness concepts changes as AI model evolves
Philosophy of Using AI as a Software Engineer
Learning Tips
- Let AI to teach you how to ask
- Let AI asks you: “what background knowledge will help him answer better?”
- Ask AI architectural reason > why do this > how to do > do it
The best way to learn a framework: Debug manually first, only ask for assistance when you're stuck for a long time.
Role as Software Engineer
- Explain tech to other people
- Find consensus in blurry requirements
- AI don’t understand business
- AI is tool not brain
- When everything is important, what’s important? You only have 24 hours daily