From agent speed to system speed
Alexander Polomodov opens with the load created by many parallel agents. Each consumes more than tokens: it needs a code copy, an environment, stored results and checks. Large labs offer useful engineering patterns, although their compute budgets and freedom to experiment differ from those of most teams.
Aleksey Litvinov describes friction when one engineer produces more changes than colleagues can process. Evgeny Sergeev adds that agent load is harder to predict from headcount: one task can spawn several working copies. Faster code generation shifts constraints to storage, CI, review and acceptance.
Parallel work and queues
Agents may fix the same problem or alter related parts of a system at once. A pessimistic approach restricts access in advance; an optimistic one allows parallel changes and resolves conflicts later. Even a clean merge can violate a business rule that was never made explicit.
The hosts discuss task, review and merge queues as ways to regulate flow. A queue can itself become a bottleneck. Evgeny also describes collecting agent questions and results in an inbox, so a person can respond at their own pace instead of constantly switching context.
Alexander compares coordination with running a large organisation: one central coordinator may not scale. Hierarchy distributes work, but Aleksey argues that roles at different levels are distinct. Adding another supervising agent is not enough; its responsibilities and lifetime need design.
Reviewing the outcome
Evgeny recounts discussions with engineering teams where more changes are created but value does not reach users faster because pull requests wait for review. Review also orders the flow of changes. The hosts do not claim that the industry has found a universal replacement.
One option is to classify changes by risk and automate routine decisions. Evgeny describes an experiment with small dependency updates: some can merge without a person when automated review and checks pass. The criticality of the affected system and consequences of failure still matter; a green CI run does not establish that behaviour is right for a user.
Another approach moves some checks after merge or relies on production observability. This improves throughput while requiring failures to be detected and repaired. Aleksey highlights the separate difficulty of evaluating new behaviour and interfaces. Even when code is cheap, gathering enough user feedback takes time and limits the pace of change.
Tools for a particular flow
The hosts discuss Anthropic’s Scion as infrastructure designed around a stream of agent changes. Alexander describes storing change metadata in a distributed database and contents in object storage, while retaining relationships between changes. A system needs to know not just the result but what it builds on and how it was combined.
The architecture reflects a choice to allow parallel work and run some checks after integration. The hosts do not recommend that every team build its own version-control system. They are looking for transferable principles and trade-offs; a lab’s scale and internal needs may differ from a listener’s.
Evgeny offers Symphony as another coordination model: agents take work from a tracker and people review outcomes and approvals around the task. He values the publication of a specification alongside an implementation because a team can adapt that description to its own environment.
Feedback loops
Alexander describes an agent’s inner loop: make a change, run the application, inspect logs and metrics, run static checks and tests, and retry when something fails. A person then reviews the change. A recurring process mistake can become a rule, test or automated check so the same comment need not consume attention again.
Automation helps only when a rule checks the property that matters. A linter cannot replace semantic judgement, and tests depend on the scenarios they cover. The local loop connects to a longer one: observing the system and its users can change the checks and the way the team works.
Permissions and boundaries
The hosts note the temptation to grant broad permissions so an agent can keep working uninterrupted. Convenience does not answer which actions are acceptable or how to limit damage. Alexander describes a cloud environment where secrets are kept from the agent and a proxy injects them for permitted requests.
Isolation, access rules and checks provide layers of protection. Each has limits: a model can make mistakes, while tools and environments can have vulnerabilities. The question is therefore not just whether to trust the model, but which operations are available, how they are observed and what happens after an error.
The cost of an accepted change
The discussion ends with economics. The bill extends beyond tokens for the first attempt: retries, automated review, CI, human work and repairs after release also consume resources. Alexander suggests linking these costs to an accepted change so alternatives can be compared on the same basis.
Evgeny notes that AI adds a line to team budgets while the value of each individual change is difficult to calculate. Aleksey suggests delivery metrics and freed capacity, while emphasizing the organisational question: leaders need to understand why spending has risen. The hosts present measurement as an unfinished problem rather than a formula for guaranteed returns.
Key takeaways
- More changes shift bottlenecks to verification, integration and feedback from users.
- Queues and explicit rules help coordinate parallel work but require their own capacity management.
- Limit agent permissions and choose verification depth according to the consequences of failure.