Scheduling the work
What should run at once, what depends on what, and what needs a longer time horizon?
Coding agents automate implementation. The next frontier is automating coordination: deciding what runs together, managing shared state, integrating changes, and knowing what's safe to ship.
The work is parallel. Dependencies, decisions and releases are still connected.
Tasks start and finish on different clocks. Progress overlaps; dependencies don’t disappear.
The interesting question isn't how many agents you can run. It's what happens when their work touches the same code, state and decisions.
What should run at once, what depends on what, and what needs a longer time horizon?
Separate code is easy. What about shared databases, ports, services, and environments?
How do agents manage overlapping ownership, interfaces, and mutable state?
What happens when changes are produced faster than the system can merge them?
Who verifies combined outcomes, evaluates risks, and decides what can ship?
How do decisions, evidence, and intent survive agents, branches, and time?
As the factory gets faster, product can make more bets, customers can shape their own variants, and human vs. agent cost changes what is worth building. Meanwhile, competitors—and open source—can catch up faster. Delivery becomes a business decision as much as an engineering system.
Pick a delivery tension. Compare the mechanisms being tried, what they protect, and what they cost. Follow the projects to their original sources.
A green check on each branch is not a green check on their combination. The choices differ in what they assume about independence and what they spend on CI.
Merge trains verify cumulative states such as A, A+B and A+B+C before any of them reaches main.
Trade-off: Speculative checks consume CI and later checks may need to restart.
Scope-aware queues allow separate areas to move concurrently while still ordering overlapping work.
Trade-off: Scope maps can miss dependencies that cross a module boundary.
Use contracts, ownership signals or merge-conflict forecasts before the changes arrive at the gate.
Trade-off: Earlier coordination reduces ambiguity but moves work into planning.
The comparison: test cumulative future states, declare independent scopes, or accept isolated risk. Those are different safety guarantees.
Projects illustrate approaches; inclusion is not an endorsement. Try the source links to judge the claims.
A curated source index. Descriptions are based on public documentation, not hands-on benchmarks or rankings.
Short essays built around specific engineering mechanisms, documented sources and a question that remains unresolved.
Green pipelines on separate changes do not guarantee one working system. Where merge trains help, what they cannot decide, and where the cost moves next.
Working essays, not performance studies. Examples are identified as hypothetical; claims link to public sources.
Good ideas have names, implementations and limitations. Six useful entry points into the conversations behind the landscape.
Selection is editorial, not a ranking or an independent performance assessment.
Suggest something missingSpeculatively tests combined future states (A, A+B, A+B+C), not simply isolated pull requests.
Serial, parallel and isolated modes make different choices about throughput and risk.
Moves isolation beyond Git, toward running containers, networks, ports and databases.
A dependency-aware issue graph that survives individual coding-agent sessions.
An experiment in forecasting merge conflicts while parallel work is still happening.
A different question: when is another parallel candidate worth its compute cost?
New tools, research worth reading, and arguments that changed our minds. A monthly email digest is planned; the working notes already have an RSS feed.
Tools are arriving faster than durable patterns. For now, we're collecting candidate mechanisms, examples, and counterexamples—not declaring a playbook.
Give parallel work separate state, and make shared integration a deliberate act.
Use early signals to predict conflicts and test combinations before they land.
Early ideas — this section will grow more slowly than the tool landscape.
Know a tool, paper, post, talk, or tiny experiment we should be tracking? Send the link and a sentence about why it's interesting. Contributions are welcome—even if the idea is unfinished.