The multi-agent workflow described here -- architect designs, developer implements, reviewers critique -- mirrors how engineering teams already work. The interesting shift is that the author's role isn't architect or developer anymore. It's closer to a tech lead who sets constraints and reviews proposals without writing the implementation.
The failure mode the author describes on unfamiliar tech is the critical observation. When you have deep domain knowledge, you catch bad design decisions during the 30-minute planning phase and correct them before any code is written. When you don't, bad decisions compound silently because you can't distinguish a reasonable proposal from a plausible-sounding wrong one. The multi-agent pattern doesn't help here -- you just get reviewed bad architecture instead of unreviewed bad architecture.
This is why "the human still needs expertise" isn't just a platitude. It's a specific mechanism: expertise lets you intervene at the design stage where the cost of correction is lowest. Without it, you're reviewing code that shouldn't have been written in the first place.
I like reading these types of breakdowns. Really gives you ideas and insight into how others are approaching development with agents. I'm surprised the author hasn't broken down the developer agent persona into smaller subagents. There is a lot of context used when your agent needs to write in a larger breadth of code areas (i.e. database queries, tests, business logic, infrastructure, the general code skeleton). I've also read[1] that having a researcher and then a planner helps with context management in the pre-dev stage as well. I like his use of multiple reviewers, and am similarly surprised that they aren't refined into specialized roles.
I'll admit to being a "one prompt to rule them all" developer, and will not let a chat go longer than the first input I give. If mistakes are made, I fix the system prompt or the input prompt and try again. And I make sure the work is broken down as much as possible. That means taking the time to do some discovery before I hit send.
Is anyone else using many smaller specific agents? What types of patterns are you employing? TIA
that reference you give is pretty dated now, based on a talk from August which is the Beforetimes of the newer models that have given such a step change in productivity.
The key change I've found is really around orchestration - as TFA says, you don't run the prompt yourself. The orchestrator runs the whole thing. It gets you to talk to the architect/planner, then the output of that plan is sent to another agent, automatically. In his case he's using an architect, a developer, and some reviewers. I've been using a Superpowers-based [0] orchestration system, which runs a brainstorm, then a design plan, then an implementation plan, then some devs, then some reviewers, and loops back to the implementation plan to check progress and correctness.
It's actually fun. I've been coding for 40+ years now, and I'm enjoying this :)
The multi-agent workflow described here -- architect designs, developer implements, reviewers critique -- mirrors how engineering teams already work. The interesting shift is that the author's role isn't architect or developer anymore. It's closer to a tech lead who sets constraints and reviews proposals without writing the implementation.
The failure mode the author describes on unfamiliar tech is the critical observation. When you have deep domain knowledge, you catch bad design decisions during the 30-minute planning phase and correct them before any code is written. When you don't, bad decisions compound silently because you can't distinguish a reasonable proposal from a plausible-sounding wrong one. The multi-agent pattern doesn't help here -- you just get reviewed bad architecture instead of unreviewed bad architecture.
This is why "the human still needs expertise" isn't just a platitude. It's a specific mechanism: expertise lets you intervene at the design stage where the cost of correction is lowest. Without it, you're reviewing code that shouldn't have been written in the first place.
I like reading these types of breakdowns. Really gives you ideas and insight into how others are approaching development with agents. I'm surprised the author hasn't broken down the developer agent persona into smaller subagents. There is a lot of context used when your agent needs to write in a larger breadth of code areas (i.e. database queries, tests, business logic, infrastructure, the general code skeleton). I've also read[1] that having a researcher and then a planner helps with context management in the pre-dev stage as well. I like his use of multiple reviewers, and am similarly surprised that they aren't refined into specialized roles.
I'll admit to being a "one prompt to rule them all" developer, and will not let a chat go longer than the first input I give. If mistakes are made, I fix the system prompt or the input prompt and try again. And I make sure the work is broken down as much as possible. That means taking the time to do some discovery before I hit send.
Is anyone else using many smaller specific agents? What types of patterns are you employing? TIA
1. https://github.com/humanlayer/advanced-context-engineering-f...
that reference you give is pretty dated now, based on a talk from August which is the Beforetimes of the newer models that have given such a step change in productivity.
The key change I've found is really around orchestration - as TFA says, you don't run the prompt yourself. The orchestrator runs the whole thing. It gets you to talk to the architect/planner, then the output of that plan is sent to another agent, automatically. In his case he's using an architect, a developer, and some reviewers. I've been using a Superpowers-based [0] orchestration system, which runs a brainstorm, then a design plan, then an implementation plan, then some devs, then some reviewers, and loops back to the implementation plan to check progress and correctness.
It's actually fun. I've been coding for 40+ years now, and I'm enjoying this :)
[0] https://github.com/obra/superpowers
This was on the front page and then got completely buried for some reason. Super weird.
On the front page at the moment. Position 12