If you are letting Claude run for seven minutes at a time, you aren't thinking hard enough about what you're building.
If you start trying to juggle multiple agents, you are doubling down on the wrong strategy.
If you start trying to juggle multiple agents, you are doubling down on the wrong strategy.
The rest of my time goes to prepping those big features (designing, speccing, talking, thinking, walking).
Going to see how big a feature can be before the quality suffers too much and it becomes unmaintainable. This highly depends on how good I spec it out and how good I orchestrate the agentic workflow.
Giving it large tasks that take 40 minutes basically always fails for me. Giving it small tasks that take 30s to a minute feels like it is my typist and not a worker. I find that I am happiest and most effective at the 5 to 7 minute cycle timeframe.
And if you're building a feature that will call AI at runtime, you'll be iterating on multiple versions of a prompt that will be used at runtime, each of which adds token generation to each round of this.
In practice on anything other than a greenfield project, if you're asking for meaningful features in complex systems, you'll be at that 10 minute mark or more. But you've also meaningfully reduced time-to-review, because it's doing all that QA, and can provide executive summaries of what it finds. So multitasking actually works.
Whenever I see transcript of a long running task, I see a lot of drifting of the agent due to not having any context (or the codebase is not organized) and it trying various way to gather information. Then it settle on the wrong info and produce bad results.
Greppability of the codebase helps. So do following patterns and good naming. A quick overview of the codebase and convention description also shortens the reflection steps. Adding helper tools (scripts) help too.