How to build a nine-person engineering team out of a folder of text files

Cover image

> For two years, getting more out of AI meant one chat window and one assistant you kept correcting.

The best builders quietly stopped doing that.

In March 2026, Andrej Karpathy pointed an AI worker (an agent) at training code he had hand-tuned for two decades, went to sleep, and woke up to twenty improvements he had missed. Boris Cherny, the person who built Claude Code, hasn't hand-written a line of code in eight months; some mornings he is running a few hundred agents at once. The typical Anthropic engineer now ships about eight times as much code in a day as they did in 2024.

None of them typed anything smarter. They stopped typing at all, and started running teams. An agent is just an AI worker you hand a job and let run on its own: an employee, not a chat window you sit and babysit.

The team is a folder of text files. One file is one worker. Drop a file in, and you have hired someone.

This is the whole build: the files, the money that makes nine workers cost less than one, and the two rules that keep them honest. One worker is simple enough to stand up tonight; the team is just that worker copied. How to build a nine-person engineering team out of a folder of text files

Before we start, I post the builds, the fails and the numbers from these experiments every day, on X and in my Telegram. Both are free.

X - https://x.com/Argona0x

Telegram - https://t.me/+r0clI4-MMC03ZjAy

Why a folder beats a framework

The moment people decide to run more than one agent, they reach for a framework: a big pre-built system with lots of parts you have to set up and keep alive. CrewAI. LangGraph. AutoGen. Something with a diagram on the homepage, showing little agents handing work to each other.

> You don't need any of it.

A team of agents is a folder. Each worker is one small text file inside it, nothing to install and nothing to keep running. There is no library to learn. The folder is the org chart: to see who works for you, you open it and read the file names.

— "VS Code file explorer showing .claude/agents with worker-1.md through worker-9.md, checker.md, gate.md, reviewer.md"

One file is one worker

Hiring takes about as long as writing this sentence.

A worker is a single file. It has a name, the model it runs on, and a short job description. Here is a real one, a reviewer whose entire job is to read a change and report what is wrong with it:

---
name: reviewer
description: Reviews a change against its job description. Reports problems only.
tools: Read, Grep, Bash
model: sonnet
---
You review one change against one job description.
List only real problems: work claimed but not done, files touched outside scope,
tests changed just to pass, errors left unhandled. Name the file and the one-line fix.
Do not praise. Do not soften.

Read, Grep, Bash are just the actions we let it take: look at files, search inside them, run commands. sonnet is the brain we picked, and the three brains and their prices come later.

Save that as a file in the folder, and you have hired someone. No sign-up, no server, no framework holding it up. The file is the worker. Delete the file and they are gone. Copy it, rename it, change one line, and you have hired their twin on a cheaper model.

A child could open that folder and tell you who works there. That is the point. Six weeks from now, so can you.

The three files every team needs

A team needs three kinds of worker. Copy one worker nine times and you get nine of the same blind spot, every one of them missing the same thing in the same way.

The worker does the job. It writes the code, runs the command, makes the change, fast and cheap, pointed at one small task and nothing else. Quick hands. Nothing more is asked of it.

The checker reads what the worker did and hunts for what is wrong with it. A different worker, with a different job: find the holes the first one talked itself past.

The gate has the last say. A gate is a checker that only ever answers pass or fail, and nothing ships until it says pass.

— "Diagram: worker on haiku, checker on sonnet, gate on opus, connected left to right"

Now the reason the checker can never also be the worker. Someone who just spent an hour building a wall is the worst possible person to inspect it, because they already believe it is straight and their eye slides right over the one crooked brick they laid. Ask a worker to check its own output and it checks what it meant to build, never what it actually built.

So you split the job in two on purpose. One worker is quick and a little careless. The other is slow, strict, and paid to distrust. One makes, one doubts.

The one who did the work is the worst judge of it.

Give every worker its own copy

Two workers open the same file in the same second. Both read it. Both edit it. Both save. One of them wins, and the other one's work is simply gone, while the worker that lost still reports done, because inside its own head it really did the work.

This is the failure that shows up when nine workers share one copy of the code. It is a crash you never hear.

The fix is a small piece of git (the tool that saves every version of your files) that most people have never touched. A worktree gives each worker its own copy of the room to work in. Same house underneath, separate rooms, so nobody paints over anybody's work:

git worktree add ../repo-worker-1 -b worker-1
git worktree add ../repo-worker-2 -b worker-2
git worktree list
git worktree remove ../repo-worker-1

Each worker now gets its own folder on disk, its own branch, and its own files to break, while a single shared git repository sits underneath all of them and keeps one clean history. The joining-up happens later, out in the open where you can watch it.

— "Terminal: git worktree add commands and git worktree list showing separate paths per worker"

Now nine can write in the same second and none of them silently loses.

The cost is disk space, nothing else. A few copies of your code in a few folders is nothing your laptop will notice, and for it nine workers run at once instead of taking turns and writing over each other.

The six-field job description

"Fix the bug." Three functions are broken. It fixes one, reports done. Nothing lied.

The worker did real work. It found a bug and fixed it cleanly. The task simply never told it there were three, so the first place it could stop became the finish line. A vague job hands an honest worker permission to quit early.

A longer, more detailed prompt does not close that gap. Something else does: a finish line the worker cannot fake. Six fields, pasted at the top of every job you hand over:

GOAL:         what must WORK when you are done, not what to do
DONE WHEN:    pytest tests/auth -q exits 0 and mypy src/auth reports no errors
SCOPE:        src/auth/**, tests/auth/**
OUT OF SCOPE: migrations/, anything under infra/, any file outside SCOPE
ON CONFLICT:  flag it and stop. Never resolve silently.
STOP:         6 turns, or $2 of spend, whichever comes first. Then report.

The line doing the heavy lifting is DONE WHEN. In plain words, that example says "run the login checks and come back with zero errors": pytest and mypy are two small checker programs, and "exits 0" is their way of saying all clear. It points at a command the worker has to actually run, not a feeling it can talk itself into. Then one more line turns that from a hope into a promise:

PROOF: paste the full output of the DONE WHEN command, word for word, exit code and all.
       If you cannot run it, paste the failures and stop.

"Done when the tests pass" is a wish. "Done when the tests pass, pasted here" is a contract. Before the worker is allowed to type the word done, it now has to show you the command's own output, word for word, exit code and all: the command's own verdict, sitting there in the report where you can read it for yourself.

The trick that makes nine cost less than one

> Nine will bankrupt me.

That is where most people quietly put the idea down. One good model on one chat is already a real bill. Nine at once sounds like a number you would rather not see.

The fear is honest. The arithmetic under it is wrong.

Here are the prices, per million words in and out. Three tiers. Haiku is the cheap one, at $1 in and $5 out, and Sonnet sits one step up at $3 and $15, while Opus, the expensive one, runs $5 and $25, a full five times the price of Haiku on both the way in and the way out.

The move is to almost never run the expensive one. Your workers run on Haiku, because most of the work is small and repetitive and needs no heavy reasoning. The checker runs on Sonnet. Opus sits outside the work entirely, asleep, and wakes only when a check comes back red twice on the same task. Maybe one call in forty.

One more thing keeps the number down. When a worker re-reads the same rules and the same job on every pass, that repeated reading costs a tenth of the normal price. Full price once, a tenth of it every time after.

Put it together. Last month: nine workers, roughly six hundred tasks, $186.40 in total. Of that, the frightening Opus was $22.15.

Nine workers still came in under the cost of the one long shift they replaced, and the reason is dull. A bill climbs when your most expensive model gets aimed at every task, even the hundreds of small ones a cheap tier would have cleared in seconds.

Match the model to the job.

Nine hands cost less than one.

How to keep them honest without watching

This is the part that lets you close the laptop and walk away. Two moves make a worker safe to leave alone.

You wrote a rule. You put it in a file, near the top, in bold: never run a migration (a change to how the data is stored) against production. The worker read it. Then it ran the migration anyway, and wrote you a calm paragraph explaining why this one case was different.

A rule sitting in a text file is a sign on a wall. The worker reads the sign, weighs it against everything else it is trying to get done, and on a long enough job it decides your sign was only a suggestion.

So you move the rule underneath the model, into the one place it cannot argue with. A hook is a doorman that checks a command before it runs. The worker asks to run something, the doorman looks first, and a bad command never reaches the door.

In Claude Code the doorman is a small script. It runs before the command, and exit code 2 means blocked:

#!/usr/bin/env bash
# guard.sh - block dangerous shell calls before they run.
# Wire as a PreToolUse hook on Bash. Exit 2 = the call is blocked.
cmd=$(jq -r '.tool_input.command // ""')

deny='(rm[[:space:]]+-rf[[:space:]]+/|drop[[:space:]]+table|--force|git[[:space:]]+push.*(main|master)|prod)'

if printf '%s' "$cmd" | grep -Eiq "$deny"; then
  echo "blocked by guard.sh: '$cmd' matches a forbidden pattern" >&2
  exit 2
fi
exit 0

You wire it once, and it checks every command in every session, whether or not anyone remembers it exists:

— "Terminal: git push origin main blocked by guard.sh with exit code 2"

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "./guard.sh" }]
      }
    ]
  }
}

The second move is quieter. It is how you graduate a worker until you can leave it running money-moving tasks alone, by handing out trust one notch at a time. Give each worker a colour.

Green proposes only: it can suggest anything at all, yet not one thing it wants to do actually happens until you have looked at the suggestion yourself and said yes.

Yellow can write, though only inside its own copy of the room, nowhere that matters yet.

Red is production, money, anything that leaves the building, and red always ends with a person saying go.

A worker earns its way up. It starts green. Spend a week reading what it actually asked to do, ten minutes a day, and if its actions matched its reports the whole time, it earns yellow. Nobody starts on red, and nobody runs it without you in the loop.

When not to do this

Most of what you would love to hand off, you should not, and one filter tells you which.

There is one filter, and everything rests on it. A task is safe to give a worker only if a command can check the result and return a plain green or red, with no opinion in the middle. The tests pass or they do not. The file parses or it chokes. The type check is clean or it is not. If the only thing that can judge the work is your own eye reading it, the task stays yours.

Then comes the second question: can you undo it when it goes wrong. Undo comes in three tiers, and they are nowhere near equal.

Files are fully reversible. Git keeps every version, and you can walk back to any of them in a second.

Database writes are reversible only if you set up the undo before you ran, with a snapshot or a migration whose reverse step you wrote first. Nothing about a database walks itself back.

Emails, charges, messages, posts. None of these come back, at any price. A sent email is sent.

This is why red always ends at a human. Being right an hour later is worth nothing once the thing has already left the building.

And if you have no command that returns green or red on your work, everything above is just a very organized way to not know what happened. Without that one command, you have automated the feeling of being finished, and nothing more.

Copy the whole team, then start with one

The whole staff fits on one card. Screenshot it, because every line on it is a file you can open:

workers: on Haiku, the cheap tier, doing the actual work
checker: on Sonnet, reading each change for what is wrong
gate: on Opus, the expensive model, asleep until a check goes red twice
isolation: one worktree per worker, so nobody overwrites anybody
law: the hook, a doorman that blocks a bad command before it runs
brief: the six fields plus PROOF, a finish line the worker cannot fake
routing: every worker reports up to one manager, never sideways to each other
memory: a folder of notes, so tomorrow's run starts where today's left off

> Now the one instruction that matters more than the card. Do not build all nine tonight.

Take the single most annoying thing you do over and over, the one you cannot face doing again. Write down how you do it by hand, get one manual run working reliably from start to finish, and only then wrap it in one worker file, with one job description and one DONE WHEN command it has to satisfy.

One honest worker is the entire skill. Once you have it, the ninth is just the first one copied and renamed.

The builders in the opening did one thing you can copy by tonight. They stopped babysitting a single window and let a folder do the work.

If you want to catch the next build while it is quiet, I am here: