Have you seen those indie developers with 20 AI agents working at the same time? Three designers, two QA testers, a product manager, four developers, two marketing experts, a lawyer, an accountant, a financial advisor, a therapist for the team, an agent to organize meetings, another to take notes, one to review the notes, and another to review the agent that reviewed the notes.
And of course, the CEO: an agent running the whole project from a folder on the computer.
Meanwhile, the side project still has no users.
I use agents and orchestrators too, and I like playing with them. But after a lot of iterations I've landed somewhere you won't see in those videos: more agents isn't more work done. It's more work to review. And you can't hand that review to the best model, not even in its most powerful mode.
Giving it a task is just the beginning
At first it's easy to think, "This model knows so much. I'll give it the task and that's it." It can do impressive things. It can also make decisions you didn't ask for, add features nobody needs, and turn something simple into a mess.
It's happened to me. I ask for one change and find three extra features when I check the work. Once, an agent built a whole web gallery to show me what it had changed, how, and why.
I didn't ask for a gallery. I wanted the original task finished. It burned a pile of tokens on something I didn't need, and the first version looked terrible.
Maybe that made sense to the model. It made none for the product, or for whoever was going to use it.
So my work doesn't end when I give the instruction. It starts before, when I decide what problem I'm solving and what should stay as it is. And it keeps going after the agent says "done," when I have to figure out what it did and whether it's what I wanted.
Two agents can agree and still be wrong
I work with an orchestrator that lets me split a task across several agents. It can be up to ten, though I rarely need that many. Each one needs a reason to be there: one builds, another reviews, another hunts for errors or checks whether we added complexity we didn't need.
It works. A second agent catches things the first one missed. But I read those reviews too, because two agents can agree and still be wrong. They'll confirm the code works without noticing the feature was never needed. Or nail a problem that wasn't the real one.
No agent replaces me there. I know the project, and I know what I'm trying to build.
Models aren't good at the same things, either. My split right now: Codex with GPT Images for assets, Claude Opus 5.5 for programming logic, and Grok 4.7 in Cursor for quick style changes. I didn't get there on day one. I had to try each one and see how it responded, and it'll probably change with the next models.
Taste is still yours
This is the part I care about most.
Models keep getting better, but I think it'll be years before AI can really imitate a person's taste. And taste is subjective. What I love, you might hate, looking at exactly the same screen.
Two developers can use the same model from the same company and end up with completely different products, because each one decides differently about what to keep and what to cut.
It happens to me while I work. I look at a first version and can't say yet what's missing. I change something, try another idea, and slowly figure out what I was after. Each round changes how I see the result.
That's why I don't delegate the review. Agents can offer options and help me try them. How the product feels, which details convince me, when it finally clicks: I decide that.
AI doesn't know when to stop talking
To me, AI is like a ridiculously smart person who seems to remember everything about almost any subject. It can give you ideas, write code, and find solutions you hadn't thought of.
But a lot of the time it doesn't know when to stop talking.
It's like that friend who has everything and always wants to tell you what they did with it. You listen and think, "Sure, impressive, but did you really need to spend that much time and money on it?"
You ask for a solution and get it, plus an extra feature, another layer, and an explanation of everything it did.
So I changed the question. My first instinct used to be "create this," "add that," "give it one more feature." Now, after seeing what it proposes, I ask:
"Of everything you're planning to create, what could we remove?"
And I ask it to check before touching anything: what depends on that code, what would stop working, and whether we're still solving the original problem. If I just say "remove this," it might do exactly that and never check what breaks.
Sometimes it finds the project already had a way to do it. Other times it finds code it added that can go without breaking anything.
Every iteration becomes a rule
A good result can take me 15 or 20 iterations, sometimes fewer. Each one lets me catch an error, explain better what I need, or realize I want something different.
Those lessons end up in the harness: the instructions, tools and rules that guide how the agents work. Almost all of mine are about what I don't want:
- Don't add features I didn't ask for.
- Don't create extra pages or reports unless they're necessary.
- Don't remove code without checking what depends on it.
- Don't call a task finished without checking that it works.
- Don't make the solution more complicated than it needs to be. More code isn't a better result.
They keep me from spending the next iteration cleaning up work I never asked for.
Before adding another agent
I'm still figuring out how many agents to use, which task to give each model and how to coordinate them. Some tasks need several reviews. Plenty just need a clear instruction.
The number of agents doesn't make a project good. Someone who reviews, decides, and dares to cut things does.
So before adding another agent, another feature, or more code, I stop and ask:
What can we remove without losing what matters?