|
|
|
|
|
|
by The-Pebble
95 days ago
|
|
|
What stood out to me here is the idea of orchestrating multiple coding agents across machines rather than treating AI coding as a single-agent workflow. Most discussions about AI-assisted development still assume one tool running locally, but the approach described here (task decomposition + parallel execution across machines) feels closer to how distributed build systems evolved. The dependency-graph model is particularly interesting. If AI agents can operate on isolated git worktrees and resolve tasks in parallel, the bottleneck shifts from raw coding to how well the system can plan and coordinate tasks. In practice that probably means developers spend more time defining boundaries between tasks rather than writing every line themselves. Another challenge I’ve noticed when experimenting with these tools is deciding which agent to use for which task. Different coding agents behave very differently depending on the type of work (refactoring, feature building, test generation, etc.). Having a runner that can dispatch tasks to different agents and machines could make that experimentation much easier. For anyone exploring the broader ecosystem of agentic coding tools, this overview was useful as well:
https://prommer.net/en/tech/guides/best-ai-agentic-coding-to... It compares several of the current tools and workflows that are emerging around multi-agent development. Curious how people think this model scales once teams start coordinating dozens of agents simultaneously. |
|
|
Re Dependency graph: In real coding, sometimes even the arguably the best agent -- claude code + Opus 4.6 + High reasoning -- still struggles, because either the tasks are very complicated or human prompting cannot articulate the problem in a way that agent can understand and solve it.
We allow graph-based task decomposition, replanning if user does not like it, and even more complex graph operations such as (i) expanding a task into a few nodes, (ii) rephreasing a subgraph of tasks into a new set of tasks.
In this way, the gains are (i) the agent is better at understanding the whole project, (ii)task executions can be parallel and retried. Say the user wants to change the prompt of a particular step, then all the tasks before that does not need to be re-run.
Re Different models for different tasks: So far we don't support that, but that is in our pipeline. Claude code has that. For example, context compaction arguably is done by Sonnet.