Last week's plan review: 25 yes/no questions about my repo, one agent per question reading the code, the git history and the live site, then one skeptic agent trying to refute each answer with file:line. It overturned seven, including a fix of mine that would have broken the service worker. Nothing was written. Every finding came from reading what already existed, 26 times over.
The rest is waste. One run fanned out to around 70 agents and ate a 5-hour window. Parallelism is capped since.
Mostly reading. Writing code is the cheap part.
Last week's plan review: 25 yes/no questions about my repo, one agent per question reading the code, the git history and the live site, then one skeptic agent trying to refute each answer with file:line. It overturned seven, including a fix of mine that would have broken the service worker. Nothing was written. Every finding came from reading what already existed, 26 times over.
The rest is waste. One run fanned out to around 70 agents and ate a 5-hour window. Parallelism is capped since.
Can you break down how this works. Your main agent is spawning 26 subagents to summarize a huge repo / code changes.
And it gets back 26 summarized reports.
Then another subagent is reading those summaries without seeing the full code directly and giving it a pass/fail?
Yeah .. I'm not getting how the skeptical subagent is being used here (or being useful).
[flagged]
[dead]