DevPixel Engineering
The original idea is very simple: Instead of forcing a single AI to think, act, and evaluate our work all at once, we split the tasks among four AIs—each with a dedicated role—and have them hand off work to each other using files. It sounds fancy, but all you actually need to do is place five text files in the right spots within your project.
This page covers it all: The complete, raw contents of those five files for you to copy, where to put each file, step-by-step setup instructions for anyone who has never opened a hidden folder, and the hidden pitfalls that can halt your pipeline in the middle of the night that few people ever talk about.
1. The 4-Agent Pipeline Philosophy and Handover Mechanism
Forcing a single AI to plan, write code, craft tests, and grade its own work clutters the entire context. Planning notes sit next to code, code sits next to error logs, and error logs sit next to review comments. A cluttered desk leads to a severe drop in quality.
The 4-Agent Pipeline splits the work into 4 independent shifts: Planner (Planning) to Coder (Implementation) to Tester (Testing) to Reviewer (Sign-off). The agents do not talk directly to each other; instead, they hand off work asynchronously via the .bangiao/ directory.
You need three things ready: First, Claude Code—that is, the version of Claude running in your computer’s terminal, not the web version. Second, an ongoing coding project. Third, knowing how to use git at a level sufficient to create a new branch. If you’re missing the first, install Claude Code before reading further. Before getting down to work, here is a conversational breakdown of a few concepts that will come up repeatedly in this article: Forcing one agent to plan, write code, write tests, and grade its own work crams everything into a single context window. Planning notes sit next to code, code sits next to error logs, and error logs sit next to review comments. The desk gets cluttered with paper, and the drop in quality happens not because the AI is dumb, but because it is juggling four roles at once. There is also a more delicate issue. When the person writing the code is also the one reviewing it, they lean toward whichever conclusion they can patch. If a test fails, they tweak the code to make it pass, instead of stopping to tell you that the design is fundamentally flawed. You end up with a pile of passing tests and a false sense of security. The Planner only thinks about planning. The Coder only thinks about implementation. The Tester only thinks about catching bugs. The Reviewer only thinks about whether to approve or reject. Every agent’s desk stays tidy, and none of them have to defend their own work. The four agents do not talk directly to each other. They leave files in a shared folder named .bangiao, and the next agent reads the previous agent’s files. The Planner leaves behind a plan. The Coder reads the plan, and once finished, leaves a summary of what changed. The Tester reads the summary, runs the tests, and leaves the results. The Reviewer reads all three and leaves a verdict. Just like consecutive shifts in a factory: the outgoing worker logs their notes, and the incoming worker reads the logbook and picks up the job. Nobody needs to know what the other three are thinking in their heads. Your request
↓
[ Planner · Opus 5 ] to .bangiao/ke-hoach.md
↓
[ Coder · Sonnet 4.6 ] to code in repo + .bangiao/thay-doi.md
↓
[ Tester · Sonnet 4.6 ] to test files + .bangiao/ket-qua-test.md
↓
[ Reviewer · Opus 5 ] to .bangiao/danh-gia.md (APPROVED / NEEDS CHANGES / BLOCKED)
↓
You review, you decide, you merge the branch
Tip: Folders starting with a dot like .bangiao or .claude are hidden directories; Mac’s Finder hides them by default. Press Cmd + Shift + Period to toggle their visibility. On Windows, go to the View tab in File Explorer and check the “Hidden items” box. This entire system lives in just two directories right inside your project: As for .bangiao/, you don’t even need to create it. The Planner will automatically generate it on its very first run. If you prefer doing it by hand, create two directories: .claude/agents and .claude/commands, create text files, and paste the content in. Remember to keep the exact file names: planner.md, coder.md, tester.md, reviewer.md, ship.md. Once set up, your project should look like this: Type /agents and hit Enter. If all four names—planner, coder, tester, reviewer—show up, you’re good to go. If your version of Claude Code doesn’t support that command, just prompt it directly: “list the subagents currently available in this project” and you’ll get the same result. If any name is missing, check two places: Is the file placed correctly in .claude/agents/, and does the name: line at the top of the file match the filename?
2. Preparing the Project Directory Structure
This entire system resides within just two configuration directories placed directly inside your project:
.claude/agents/: Contains 4 files defining the roles of the 4 agents (planner.md, coder.md, tester.md, reviewer.md)..claude/commands/: Contains the/shiporchestration command..bangiao/: Directory containing handover files (automatically generated during execution).
Step 3: Branch out in Git before every run
This is a must-have habit, not an option. Before implementing any feature, open the Terminal in your project and type git checkout -b feature-name. Whatever mess the four AIs create, it’s all safely contained within a separate branch—if you’re not satisfied, just delete the entire branch and you’re done.
Warning: The section between the two — lines at the top of each file is the configuration declaration, and it’s pickier than you might think. Do not add extra whitespace before name:, and tool names in the tools: line must have their first letter capitalized exactly as in the original file: Read, Write, Edit, Grep, Glob, Bash. Typing read instead of Read will cause the agent to lose file-reading permissions without any error message—you’ll just notice it suddenly starts performing poorly.
Regarding the model line in the file: In the file, you’ll see model: opus and model: sonnet written concisely like that. These are aliases, and Claude Code automatically understands to use the latest version of that family: Opus 5 for the Planner and Reviewer, Sonnet 4.6 for the Coder and Tester. Just stick with the shorthand names; when newer versions are released, your file will automatically adopt them without having to update each one manually.
3. Agent 1 (Planner): The Blueprint Designer
The Planner strictly writes zero lines of code. Its sole purpose is to transform your vague prompt into a plan so concrete that the Coder can execute it directly without any guesswork.
The plan here resembles a construction blueprint rather than a simple summary: which files to modify, which functions to write, what each function accepts and returns, and how to handle any edge cases that arise.
What the Planner leaves in the handover log
Exactly one file: .bangiao/ke-hoach.md. Inside, it contains the path to each file, every function signature, a list of edge cases, and the names of sample files for the Coder to follow the coding style. Wherever things are still ambiguous, it doesn’t guess blindly; instead, it notes them at the top of the file under the OPEN QUESTIONS section, and the entire pipeline halts right there waiting for your answer.
Why this one gets to run Opus 5
Planning is the highest-leverage step. If you draw the blueprint wrong, the better the builders are, the faster they will build the wrong house. Opus 5 is currently the strongest model at architectural reasoning and spotting edge cases that few would think of. Since it only runs once per feature, the extra cost is negligible compared to what it saves.
planner.md (the architect)
Reads the codebase and writes the implementation plan to .bangiao/ke-hoach.md. Equipped with only four tools: Read, Grep, Glob, Write. Deliberately lacks Edit and Bash so it cannot accidentally modify code even if it wanted to.
Located at .claude/agents/ · Model: Opus 5 · Cannot touch the code
Tip: If you are supervising actively rather than running overnight, pause after the Planner stage and read .bangiao/ke-hoach.md. Editing two lines in the plan takes half a minute, whereas letting the Coder build the wrong thing and tearing it down takes an entire hour. To stop right there, don’t type /ship; just send “use subagent planner for feature X” and it will execute only that single stage.
4. Agent 2 (Coder): The Builder
The Coder takes the blueprint and builds exactly according to it. It doesn’t question the plan, doesn’t grade our work, and doesn’t casually clean up neighboring files. It just builds.
What developers leave in the handover log
The actual code in the repo, along with a .bangiao/thay-doi.md file detailing which files were touched, what each change was for, and where Testers should scrutinize closely. This very record helps Testers know where to target instead of testing aimlessly.
Why this agent runs Sonnet 4.6
Once the design is clear, what remains is typing fast, accurately, and adhering to the repository’s coding style. That is Sonnet 4.6’s sweet spot, and it is many times cheaper than Opus 5. The coder also generates the most tokens in the entire pipeline, so keeping it on a cheaper model delivers the biggest cost savings.
coder.md (the implementer)
Reads .bangiao/ke-hoach.md, writes the code, and writes a summary to .bangiao/thay-doi.md. Equipped with the full toolset since this is the only agent permitted to touch production code.
Located at .claude/agents/ · Model: Sonnet 4.6 · Code editing enabled
Note: The instruction “do not add any features not requested by the plan” might seem redundant, but it curbs the most annoying habit of AI: modifying one file and casually refactoring three neighboring files along the way, leaving you dizzy when reviewing the git diff in the morning. Do not delete that sentence.
5. Agent 3 (Tester): The Inspector
The Tester checks what the builder just constructed, writes tests to prove it works correctly, and then runs them. If a test fails, the entire pipeline stops. It is not allowed to grab a hammer and fix things; it can only log where it broke in the notebook.
What Testers Leave in the Handover Log
The test files in the repo, along with .bangiao/ket-qua-test.md clearly stating whether everything passed or which ones failed and the reasons for their failure.
Why not let it fix bugs automatically?
Allowing the Tester to fix the code falls right back into the original trap: when the inspector is also the builder, genuine inspection no longer exists. A failed test means the pipeline halts, leaving it for the Reviewer to judge or for you to deal with tomorrow morning. What keeps the pipeline reliable is the fact that each piece only does its designated job.
tester.md (the acceptance tester)
Read the change summary and the plan, write tests for the happy path, edge cases, and at least one failing case, run them, and log the results to .bangiao/ket-qua-test.md.
Located at .claude/agents/ · Model: Sonnet 4.6 · Writes test files only
Note: The Tester still needs Write and Edit permissions because it has to create test files. This means that technically it could still modify production code; the “do not touch the code” constraint lives in the prompt instructions, not in the filesystem permissions. Therefore, make it a habit to glance over the git diff each morning to ensure it hasn’t strayed outside the test directory.
Tip: “Test behavior, don’t test internals” translates to practical terms like this: A test should ask, “Does failing to log in 6 times in one minute result in a lockout?”, not “Is the attempt counter variable named counter?”. Tests focused on behavior stay green even when internal implementations change; tests tied to internals turn red at every little tweak, and you’ll eventually get frustrated and delete them all.
6. Agent 4 (Reviewer): The Signer
This is the final gate before anything touches the main branch. It reads everything left behind by the other three, runs git diff on its own to inspect the actual code, and delivers its verdict. This one also runs on Opus 5, because catching a subtle bug here is far cheaper than running into it when users are already using the product.
The Most Important Detail: The Reviewer Cannot Edit
This is intentional, not an oversight in permissions. If the Reviewer could edit code, whenever it hit a snag, it would quietly patch it up and mark it as “good,” completely destroying the value of the review. An agent that can only observe has no choice but to report truthfully what it sees. It is precisely this hard constraint that ensures the quality of the final step.
Enforcing this takes just a single line: in the tools: section, grant it Read, Grep, Glob, and Bash—no Write, no Edit. The official Claude Code documentation also recommends giving each subagent strictly the minimal toolset required for its role, nothing more.[1]
Bash still has to stay, because without it, the Reviewer cannot run git diff. If you want to be even stricter, you can remove Bash entirely and manually paste the diff output for it to read, though at the cost of losing the ability to run unattended overnight jobs.
Three Verdicts
The result is located in .bangiao/danh-gia.md, always starting with one of three words. The term “merge branch” below means merging the feature branch into the main branch:
- APPROVE: The code matches the plan, tests have real value, and no issues are found. Review it once more, then merge the branch.
- NEEDS CHANGES: It runs, but some parts need tweaking. The reviewer explicitly lists what to fix, in which file, and on which line.
- BLOCK: There are serious issues regarding security, correctness, or performance. Do not merge the branch.
reviewer.md (approver/signer)
Read the plan, changelog, test results, run git diff, and write the verdict APPROVE, NEEDS_FIX, or BLOCK to .bangiao/danh-gia.md.
Located at .claude/agents/ · Model: Opus 5 · Read-only, do not modify
Note: In the file, the verdict line is intentionally written without diacritics (CHOT, CAN SUA, CHAN). The reason is very pragmatic: Later, if you want to write a script that automatically parses the results or quickly search across files, unaccented strings cause far fewer issues. The explanatory notes below can remain in standard Vietnamese with accents.
7. The /ship Command: The Conductor of All Four
Standing on their own, the four agents still need to be invoked individually. This file is the orchestrator: you type a single line, it calls the Planner, waits for the plan before calling the Coder, waits for the changes before calling the Tester, and only when the tests are green is it the Reviewer’s turn.
The $ARGUMENTS token in the file is a placeholder: everything you type after /ship will be injected right into that spot.[2] This allows a single file to be used for every feature without any further edits. If you want to rename the command, simply rename the file; name it lam.md, and the command becomes /lam.
ship.md (orchestrator)
Runs through all four stages, automatically pauses when encountering open questions or failing tests, includes a safeguard preventing execution on the main branch, and never automatically merges branches.
Located at .claude/commands/ · Type: /ship
How to Type It
Open Claude Code in your project, branch out, and then type a line like the one below. The word “endpoint” in the first example is the address the application calls on the server—in this case, where login processing is handled:
From there, the orchestrator handles the rest. If an issue occurs at any stage, it stops immediately at that step and explains clearly what happened, rather than silently continuing.
Warning: The pipeline will never auto-merge branches, and you shouldn’t edit ship.md to make it auto-merge either. It may sound convenient, but at that point, you’ve removed the only remaining checkpoint: the human. It executes, you decide.
8. Cost: Who gets to run the expensive model
Let’s be blunt: Running four agents consumes significantly more tokens than running just one. That’s the cost of quality. But the model allocation below keeps the bill manageable, because the two roles generating the most text run on the cheaper model.
- Planner, Opus 5: Runs exactly once per feature. You need the sharpest reasoning to map out the architecture and foresee potential roadblocks. Paying more here pays off in the quality of the next three stages.
- Coder, Sonnet 4.6: Generates the most tokens. However, building against an existing blueprint doesn’t require the reasoning depth of Opus 5, and Sonnet 4.6 is several times cheaper.
- Tester, Sonnet 4.6: Same reasoning. Writing and executing tests for well-defined changes is a structured, templated task—Sonnet 4.6 handles it cleanly.
- Reviewer, Opus 5: Also runs just once. This is the last line of defense to catch bugs, so don’t cut corners here.
The vast majority of tokens go to the Coder and Tester—the two roles running on the cheaper model—meaning the total bill doesn’t scale linearly with the number of agents. The exact ratio varies depending on the feature’s scope, so don’t take anyone’s word for it: run it a few times and observe our consumption patterns yourself.
This breakdown also aligns with what Anthropic’s engineering team shared when building their multi-agent systems: running multiple agents consumes tokens at a multiple of a standard chat session, making role-based model selection the primary lever for controlling costs.[3]
Note: If you want to cut costs even further, change model: opus to sonnet in planner.md for small, well-defined features from the get-go. But whenever a feature touches multiple files or impacts security, stick with Opus 5—don’t penny-pinch in the wrong places.
9. Let it run while you sleep
This is the most exciting part, and also where many fail on their very first night. Not because the pipeline is flawed, but due to the two very common traps below.
Two things that will stall your pipeline until morning: Trap one, the machine sleeps. Claude Code runs locally on your machine, not in the cloud; close your laptop lid and it turns off too. Plug it in, leave the laptop open, and disable sleep mode. On Mac, open an additional Terminal window, type caffeinate -i, and leave it running until morning. This command only prevents the system from going to sleep while idle; if you close the lid, it will still sleep as usual. On Windows, go to Power & battery and set the machine to never sleep while plugged in. Trap two, permission prompts. By default, Claude Code asks for your approval before running commands or modifying files. While you are asleep, no one is there to click approve, and it will just sit there waiting all night. To run it overnight, you need to grant permissions in advance, and this requires careful consideration rather than a one-size-fits-all answer. The section right below details the three levels, along with the trade-offs of each.
The More Permissions Granted, the More Control Lost
The three approaches below are ranked from strictest to loosest. The further down you go, the fewer prompts you encounter, and the less chance you have to stop it when things go wrong.
Level 1: Manual approval for the first few nights. Run a few features while you are still sitting there. Each time it requests permission for a command that looks reasonable, select “Yes, and don’t ask again”. Claude Code automatically logs this as an allowed rule in .claude/settings.local.json, your private file that is not pushed to git. After a few nights, that list will be sufficient for the pipeline to run smoothly without needing to grant anything extra. This is the recommended approach.
Level 2: Manually write the allowlist. If you are impatient, write directly to the file, with each line representing a tool or a type of command. More critical than the allowlist is the denylist, because deny always overrides allow. Run /permissions in Claude Code to see which rules are currently active and which files they originate from.
Replace npm test with your project’s actual test command. The two lines blocking git push and git checkout prevent it from pushing code or switching branches on its own while you sleep, while Read(./.env) keeps secret key files out of reach.
Level 3: Disable prompts. There is a mode allowing it to auto-approve everything, along with flags to bypass all permission requests entirely. Running it this way means nothing stops it from deleting files, making network requests, or executing any command; if something goes wrong by morning, there will be no trail left to trace back. If you must use this, only do so in your personal repo, on a secondary branch, on a machine free of company data or secret keys, and with a clean commit before going to bed.
Three common pitfalls: First, permissions are enforced by Claude Code, not by instructions in an agent file, so writing “do not delete files” in reviewer.md is no substitute for an actual deny rule. Second, the list placed in .claude/settings.json is a shared project file, requiring each person to explicitly trust the directory for it to take effect, whereas your personal settings.local.json applies immediately. Third, auto-approval modes cannot be picked up from project files; they must be configured on the host machine or passed as flags when launching Claude Code.
Before going to bed
Create a new branch. Make sure the computer doesn’t go to sleep. Type /ship along with the prompt, then stick around for about a minute to ensure the Planner phase kicks off smoothly; once it starts reading the files, I can finally go to sleep with peace of mind.
The Next Morning
Open that branch, read .bangiao/danh-gia.md first:
- APPROVED: Review the code with your own eyes once, then merge the branch. Don’t skip the reading step.
- NEEDS CHANGES: Review the specific feedback, then manually fix it or rerun the pipeline with clearer, adjusted requirements. If you plan to rerun it, copy
.bangiao/danh-gia.mdsomewhere else first, because the first step of/shipclears out that directory. - BLOCKED: Do not merge. Read the reason, and nine times out of ten you will find the root cause lies in the initial plan missing an important constraint.
Once you’ve decided to merge, these two lines below are all you need, run in the Terminal at your project root:
The pipeline never auto-merges anything; it always leaves the branch untouched for you to review. It does the work, you make the decisions—and that is a boundary that should not be blurred.
Tip: Don’t throw a massive feature at it on your first night. Pick something you could build yourself in half an hour, then in the morning compare its results with how you planned to do it. That’s the fastest way to find out how much you can actually trust it, rather than relying on gut feeling.
10. Tips to keep the pipeline running smoothly
The following seven things are only realized after running it in production a few times. Click on each line to expand and read:
11. Frequently Asked Questions (FAQ)
Answering common questions regarding costs and practical experience when deploying the 4-Agent Pipeline:
Chưa có bình luận nào. Hãy là người đầu tiên chia sẻ góc nhìn!