The One Who Is Many: How I Run a Team of AI Agents as a Solo Developer
Most people use AI the way they use a search engine: ask, read, close the tab.
I run it the way you run a company. I have a planner that architects the work, implementers that write the code, cheap mechanical workers that grind through repetitive tasks, and classifiers that triage my inbox while I sleep. Each one gets a brief, a budget, and a definition of done. Each one gets verified before I trust a word it says.
I’m one person. Together, we ship like a small agency — real products, on production, for paying clients.
This post is the operating manual I wish existed when I started. It’s also my answer to the most common question I get: “which prompts do you use?” Wrong question. Prompts are 5% of it. The other 95% is architecture — and a mindset shift most people never make.
The core thesis
The bottleneck is not the model’s intelligence. It’s the architecture around it: memory, context, verification, guardrails, orchestration. AI doesn’t replace thinking — it replaces execution. Your job is to move from executor to architect-operator.
Every principle below falls out of that one idea. All of them were learned the hard way — including one incident where an agent wiped a production config file, which is why one of these principles is enforced by code on my machine, not by hope.
Principle 1: AI is a team, not a tool
Stop “asking the AI.” Start hiring it.
When I have work to do, I don’t open a chat window and improvise. I decide which worker the task needs. A heavyweight model plans architecture and reviews. Mid-tier models implement. Small, fast, cheap models do mechanical work — renaming, formatting, extraction, classification. Choosing a model is choosing an employee for the job and the budget. You wouldn’t pay a senior architect to rename variables. So why is your most expensive model doing it?
The moment you see AI as staff, everything else clicks: staff need briefs, context, boundaries, and performance reviews. Which is the rest of this list.
Principle 2: Close your eyes and press enter
Maximum autonomy, minimal checkpoints.
Most people micromanage AI: prompt, read, correct, prompt again, twenty times an hour. That’s not leverage — that’s you doing the work with extra steps. I run the opposite model: agents get long leashes and clear goals, and I keep a small set of hard checkpoints where nothing passes without me — pushing to production, running database migrations, touching secrets, contacting real customers.
Everything inside those boundaries, the agent does alone. My job is to approve outcomes, not to perform tasks. The test of a good setup: can you give the instruction, close your eyes, press enter, and trust the system? If not, fix the system — not the prompt.
Principle 3: Steer, don’t interrupt
When an agent is mid-task and I see it drifting, I don’t stop it. I send a course correction and let it keep moving — the way you’d lean over a colleague’s desk and say “use the other endpoint,” not pull their chair out from under them.
Interrupting throws away accumulated context, which is the most expensive thing an agent has. Steering preserves it. This one habit probably doubled my throughput.
Principle 4: “It works” requires proof
Agents lie. Not maliciously — confidently. I’ve had a delegated agent report a detailed list of files it changed without having written a single one. If I hadn’t checked git status, I’d have shipped air.
So the rule is: a claim is not a result. “It compiles” is not “it’s deployed.” “I deployed it” is not “the endpoint returns 200.” I verify artifacts, not assertions: curl the endpoint, query the database, take the screenshot, read the diff. Every serious workflow I run ends with a verification step the agent cannot skip, and every definition of done names the evidence that will prove completion.
If you adopt only one principle from this post, take this one.
Principle 5: Guardrails in code, not in prompts
Early on, an automated git cleanup overwrote a production .env file. My response wasn’t to add “please be careful with env files” to a prompt. It was to write a hook that deterministically blocks destructive commands — rm -rf /, git reset --hard, redirects into .env — before they execute. The model can’t talk its way past it, and neither can a bad day.
The lesson: anything that must be safe, make safe mechanically. Prompts are suggestions. Code is law. A politely-worded system prompt is not a security boundary, and the day you forget that is the day you learn it expensively.
Principle 6: Context and memory are infrastructure
An agent without context is an intern on their first day — every single day. Most people re-explain their project, their style, and their constraints in every conversation, then wonder why the output is generic.
I build agents a hard drive of identity: a soul file with operating rules, a goals file that defines what matters and in what order, per-project memory with deploy procedures and past incidents, and persistent memory that survives across sessions. When one of my agents starts, it already knows my infrastructure, my commit format, my priorities, and the mistakes we’ve already made once.
This is the single highest-ROI thing you can build. One afternoon of writing context files beats a year of clever prompting.
Principle 7: Define “done” before you start
Everything I delegate has a Definition of Done written before the agent starts — including, per Principle 4, what evidence will prove it. Agents work until DoD, not until they feel like answering. Workers signal completion through explicit markers, and the orchestrator harvests results only when they exist.
This matters doubly for me because I have ADHD, and “everything 95% finished, nothing shipped” is my factory default. Encoding finishing into the system — instead of relying on my discipline — is how the work actually closes. Closing beats starting. Always.
Principle 8: Fit the system to the human
My whole setup is designed around a brain that loses threads, drowns in open loops, and can’t rely on “just remember to check it later.” So the system decides instead of asking me to. It reduces instead of accumulating. It surfaces one next action, not forty. It never punishes what wasn’t done — it just re-plans.
You might not have ADHD. But if you’re busy, overloaded, or context-switched to death, you have situational ADHD — and a system that respects human limits will beat a system that assumes a perfect operator, every time. Design for your worst day, and your best days become absurd.
What this looks like in practice
A concrete morning: I write a brief for a feature. A planning agent turns it into a phased plan with explicit DoD per phase. I fan out three workers in parallel terminals, each in an isolated git worktree so they can’t step on each other. They work; I steer occasionally. When their completion markers appear, a review pass checks diffs and runs tests against the baseline — new failures only, because inherited failures aren’t the workers’ fault. I read the evidence, approve, and I push the button on deploy, because that’s a checkpoint.
Total hands-on time: maybe forty minutes of my attention, spread across a morning, for what used to be two days of solo work.
That’s the shift. Not a better prompt. A different job description.
I’m turning this operating model into a mentoring program and a series — teaching it live, one hour a week, to a CEO who has never delegated to an agent before. If you want the next posts as they land, join TheOnes. And if you’re a founder who wants a team of agents like this inside your company, talk to me.