AI coding agents are improving rapidly.
Give one an issue, and it can inspect a repository, write code, run tests, and open a pull request. Running several agents in parallel is no longer particularly unusual either.
But once I started assigning one large development goal to multiple AI agents, the central problem stopped being the agents’ coding ability.
The difficult questions became:
- How should a large requirement be decomposed?
- Which tasks are actually safe to run in parallel?
- In what order should multiple changes be integrated?
- How do we resume after execution state is lost?
- Where should probabilistic LLM judgment end and deterministic control begin?
- At which points should humans intervene?
This is no longer just a question of how to make an AI write code.
It is a question of how to design and operate the software development process itself when AI agents become the workers.
I have been exploring one approach to this problem through a development orchestrator called Orchestune.
Orchestune originally started as a supporting tool for an AI-assisted novel-writing project.
As I implemented and operated it, however, I discovered that the orchestration layer contained a much more general and fundamental problem than the application it had been created to support.
This article is not primarily a product introduction.
It is about the engineering principles that emerged while building Orchestune.
Agent Capability and Development Reliability Are Different Problems
A more capable coding agent is more likely to complete an individual task successfully.
But the reliability of an entire multi-agent development process does not follow automatically.
Even if every agent can produce a locally correct implementation, the following problems remain:
- Two tasks modify the same file.
- One task creates an API based on assumptions that differ from another task’s assumptions.
- A shared module that was not identified during planning becomes necessary.
- An upstream implementation changes a contract that downstream tasks rely on.
- Each pull request passes independently, but the combined result fails.
- An agent reports completion, but its commit or push did not actually succeed.
- An execution process disappears while progress metadata remains behind.
These are not primarily intelligence problems.
Human software teams also need more than individually capable developers. They need task decomposition, dependency management, branching strategies, CI, review processes, incident handling, and coordination mechanisms.
AI agents need the same kind of control structure.
In fact, because AI agents can produce changes faster and work in parallel, weak coordination becomes visible even sooner.
The central question should therefore not only be:
Which model is the smartest?
It should also be:
How do we make multiple imperfect and failure-prone workers converge on one reliable outcome?
Prefer Traceability Over Full Autonomy
Autonomy is often treated as one of the main success metrics for AI agents.
How long can an agent work without human input?
How many decisions can it make on its own?
How broad a task can it complete autonomously?
But autonomy by itself is not enough for an operational development system.
An agent may act independently, but if:
- we cannot explain why it made a decision,
- we cannot determine how far it progressed,
- we cannot reproduce the point of failure,
- another agent cannot continue its work,
- and a human cannot safely correct it later,
then the system is difficult to trust.
One of Orchestune’s design principles is:
Traceability over autonomy
Instead of keeping all state inside an agent session, Orchestune externalizes development state through GitHub artifacts:
- Issues
- labels
- branches
- commits
- pull requests
- CI results
The important point is not merely that humans can view this information in a browser.
The important point is that another system can read the same evidence and determine what should happen next.
Traceability is not only for auditing.
It is the foundation for recovery, continuation, and agent replacement.
GitHub Is Not the Truth; It Is a Durable Ledger of Evidence
The original idea behind Orchestune was simple:
If development state is visible in GitHub, coordinating multiple AI agents should become easier.
Issues represent tasks.
Labels represent progress.
Branches isolate work.
Pull requests represent outcomes.
CI verifies correctness.
GitHub already provides most of the objects needed to describe a development workflow.
But in practice, having visible state is not the same as having consistent state.
For example:
- An Issue is labeled
in-progress, but the worker process has already died. - A branch exists remotely but not locally.
- A pull request is still open, but its commits have already been integrated through another path.
- A CI check is missing, but it is unclear whether it does not exist or has not been fetched yet.
- An agent wrote code but failed to push it.
- A label was updated, but the runtime disappeared before local state was persisted.
No single GitHub artifact is sufficient to establish the true state of the system.
An Issue label alone is not authoritative.
The existence of a pull request is not enough.
A branch reference or CI result is also not sufficient on its own.
For this reason, Orchestune does not treat GitHub as one perfectly consistent source of truth.
It treats GitHub as:
A durable ledger containing the evidence required to reconstruct state.
Orchestune combines evidence from Issues, labels, branches, commits, pull requests, and CI results, then derives the effective state using deterministic rules.
GitHub is the ledger.
Orchestune is the reconciler that interprets it.
Design Reconciliation, Not Just State Storage
In a typical application, state is stored in a database.
A record has a status, and the system updates that value over time.
AI-driven software development is more difficult because relevant state can change outside the orchestrator.
A human may merge a pull request.
Another process may update a branch.
An agent may change an Issue label.
CI completes asynchronously.
A local runtime may be destroyed at any time.
In this environment, it is less important to store a supposedly perfect current state once.
It is more important to:
Repeatedly observe available facts and repair the difference between the current and desired state.
This is the reconciliation model.
Conceptually, Orchestune performs the following loop:
- Observe GitHub and the local runtime.
- Reconstruct the relationships among tasks, branches, pull requests, and CI results.
- Validate whether the current state is internally consistent.
- Select tasks that are now safe to execute.
- Dispatch, pause, retry, rebase, or integrate work.
- Repeat the observation process in the next cycle.
A single execution cycle is not assumed to complete perfectly.
The goal is that repeated executions safely converge toward a valid state.
The key property is not one-shot success.
It is convergence.
Decompose Before Solving
AI agents can often decompose a large request internally.
But internal decomposition has two major weaknesses:
- It is difficult for humans to inspect.
- It is difficult for multiple agents to coordinate around.
Orchestune follows another principle:
Decompose before solve
Before implementation begins, the system externalizes:
- subtasks,
- expected file changes,
- expected symbols,
- explicit dependencies,
- shared interfaces,
- risk areas,
- and integration order.
The decomposition is not merely a checklist.
It is an executable coordination structure used by later stages for:
- dispatch,
- conflict detection,
- scheduling,
- integration,
- and recovery.
A human reviews the structure before the workers begin.
This moves human attention away from micromanaging every agent action and toward validating whether the overall plan is sound.
Parallelism Is Not About Concurrency; It Is About Proving Independence
Starting several agents at the same time is easy.
Determining whether their work is truly independent is difficult.
Two tasks may be described as separate Issues but still modify the same file.
They may modify different files but depend on the same public API.
They may both need to create a shared extension point that does not exist yet.
Parallel execution is therefore not simply a matter of increasing the worker count.
It is a question of:
How confidently can we establish that multiple changes can be integrated without invalidating each other’s assumptions?
Orchestune asks each task to declare a footprint: the files and symbols it expects to modify.
The orchestrator uses overlap between footprints and symbols to infer implicit dependencies between tasks.
But literal path comparison is not enough.
Consider two tasks that both require a new format registry.
One agent may plan to create:
format_registry.py
Another may expect to extend:
serializers/__init__.py
The paths do not match, even though both tasks are trying to own the same architectural responsibility.
To address this, Orchestune introduces the concept of a shared contract.
A shared contract represents an architectural extension point that several tasks rely on, such as:
- a registry,
- public API wiring,
- dependency configuration,
- CLI registration,
- or another shared integration surface.
The shared contract can be assigned to a dedicated owner task, while dependent tasks are ordered around it.
This goes beyond file-level conflict detection.
It attempts to manage parallelism at the level of architectural contracts.
Repair the Plan, Not Just the Worker
When an AI worker fails, the simplest response is to run it again.
That is not always enough in a multi-task development process.
Suppose a worker modifies a file outside its declared footprint.
The original assumption that another task could run independently may no longer be valid.
Suppose an upstream task changes a public interface.
Downstream tasks may now be based on obsolete assumptions.
Suppose a human starts editing the same area of the repository.
The existing execution plan may no longer be safe.
In these cases, the broken thing is not necessarily the agent.
The broken thing is the plan.
Another Orchestune principle is:
Reschedule instead of restart
Rather than blindly restarting the same task, Orchestune can re-observe changed footprints and external work, recompute relevant dependencies, and reschedule only the affected part of the task graph.
From a worker-centered perspective, failure leads to retry.
From a plan-centered perspective, failure leads to reconciliation.
That distinction matters.
Separate Generative Implementation from Deterministic Integration
LLMs are extremely useful for implementation.
They can interpret ambiguous requirements, inspect unfamiliar code, and infer appropriate changes.
But some decisions should not depend primarily on probabilistic judgment:
- Does a commit actually exist?
- Did CI really pass?
- Is a branch safe to delete?
- Should an Issue be considered complete?
- Is a pull request safe to merge?
- Can this action be retried without creating duplicate effects?
Whenever possible, these decisions should produce the same output from the same observable facts.
Orchestune follows the principle:
Deterministic integration over heuristic judgment
LLM code review can still be valuable.
But it is not the primary mechanical integration gate.
Before integrating a task, Orchestune creates an actual combined state and runs CI against it.
The merge decision is based primarily on Git facts and test results, rather than on an LLM saying that the code “looks correct.”
The goal is not to remove LLMs from the process.
The goal is to assign LLMs and deterministic systems to the kinds of decisions each handles best.
A Two-Tier Branch Model Reduces Human Approval to the Final Merge
Parallel implementation does not help much if every child task still creates a pull request directly against main and requires an individual human review.
The implementation phase may be parallelized, but the human reviewer becomes the integration bottleneck.
Orchestune addresses this with a two-tier branch model.
For a parent Issue such as #100, Orchestune creates a long-lived parent branch:
parent/issue-100
Child task branches are based on that parent branch rather than integrating directly into main.
Each completed child task is validated and merged into the parent branch.
Only after all child tasks have been integrated does Orchestune create the final pull request from the parent branch to main.
A child change is first tested in a temporary integration state against the parent branch.
If CI passes, the child change can be merged automatically into the parent branch.
The child Issue can then be closed without requiring a human to inspect and click through every intermediate pull request.
When all child tasks are complete, the parent branch represents the full implementation of the larger goal.
Orchestune then opens the final pull request from:
parent/issue-100
to:
main
That final pull request is not automatically merged.
A human reviews the combined result and makes the final acceptance decision.
This structure concentrates human approval at the point where judgment matters most.
The human does not need to approve:
- every child task,
- every intermediate branch update,
- or every mechanical integration step.
Instead, CI acts as the deterministic quality gate for child integration, while the human reviews the final “big rock.”
This branch model is a concrete implementation of another Orchestune principle:
Humans approve structure, not every action
Use LLMs as Explorers for Unknown Failure States
In real operation, deterministic rules cannot immediately cover every failure mode.
In those situations, asking an LLM to inspect the Issue, pull request, branches, CI results, and logs often works surprisingly well.
A prompt as simple as:
Investigate the cause.
can produce a useful diagnosis.
LLMs are good at combining multiple weak signals.
For example, given:
- an Issue still marked as running,
- an open pull request,
- an empty diff,
- an existing remote branch,
- missing CI checks,
- and a recent rebase,
an LLM may correctly suspect a branch-reference inconsistency rather than an implementation failure.
This is useful.
But an LLM diagnosis is not fully reproducible.
The same state may produce different recommendations depending on:
- the model,
- the prompt,
- context ordering,
- or the subset of evidence retrieved.
For this reason, Orchestune should not treat the LLM as the final authority on system state.
A better role is:
An exploratory diagnosis engine for previously unknown states.
Once an unknown failure has been understood, its recovery logic can be converted into:
- an explicit state transition,
- an integrity check,
- a fail-closed rule,
- retryable versus fatal failure classification,
- an idempotent repair operation,
- and a regression test.
The improvement loop becomes:
- An unknown failure appears.
- An LLM or human diagnoses it.
- The system is repaired.
- The cause and conditions are extracted.
- A deterministic rule is implemented.
- A regression test preserves the behavior.
- The failure becomes a known, automatically handled state.
In this relationship:
The LLM discovers recovery knowledge, and the control plane turns it into a reproducible specification.
The Goal Is Not Zero Bugs, but Absorbing Unknown Failures
Orchestune exposed many bugs during real-world operation.
Examples included:
- remote Git references,
- missing CI results,
- completion detection,
- worktree cleanup,
- state persistence,
- external locks,
- and pull request pagination.
In a system like this, the presence of bugs does not automatically mean the architecture has failed.
The more important question is whether the same failure class keeps returning.
If the same cause repeatedly breaks the system, the control plane is not learning.
But if each incident reveals a different boundary condition and results in a new invariant and regression test, then the system is exploring previously unknown parts of its state space.
The meaningful form of convergence is not:
No new bugs ever appear.
It is:
New failures increasingly fall into established paths for safe stopping, diagnosis, repair, and regression prevention.
A reliable orchestrator is not one that never fails.
It is one that can convert failure into durable operational knowledge.
Humans Should Approve Structure, Not Every Action
If humans must inspect every action taken by every AI agent, the benefits of parallelization disappear.
But if the system is completely autonomous, an incorrect plan can be executed at high speed.
Orchestune attempts to place human approval at two high-value points.
The first is before execution.
A human reviews:
- task boundaries,
- dependencies,
- parallelization assumptions,
- shared contracts,
- and risk areas.
The second is the final pull request from the parent branch to main.
The intermediate operations can then be automated:
- dispatching,
- branch creation,
- worker execution,
- child integration,
- CI,
- state transitions,
- and local replanning.
This is not about removing humans from software development.
It is about concentrating human judgment where it has the highest leverage: architecture and final acceptance.
Workers Are Replaceable; Orchestration Is the Asset
AI models and coding agents will continue to change rapidly.
The best worker today may not be the best worker several months from now.
If task state, progress, dependencies, and recovery knowledge are trapped inside one agent’s internal session, switching workers means losing operational continuity.
Orchestune follows another principle:
Workers are replaceable, orchestration is the asset
The implementation worker may be Claude Code, Codex CLI, another local agent, or a cloud-based execution service.
The more important question is whether the following information exists outside the worker:
- What task was assigned?
- What dependencies were satisfied?
- Which branch was used?
- What artifacts were produced?
- Why did execution stop?
- What remains to be integrated?
- What recovery action is safe?
If that state is externalized, the worker can be replaced without losing the development process.
The durable assets of AI development may therefore become:
- decomposition rules,
- state transitions,
- safety conditions,
- recovery procedures,
- integration strategies,
- and accumulated incident knowledge.
Not the prompt for one particular model.
GitHub Ops–Style AI Orchestration
While building Orchestune, I have started using the phrase GitHub Ops–style AI orchestration to describe this design space.
The term refers to using GitHub not merely as a code host or pull request destination, but as:
- a durable state ledger,
- a task queue,
- an audit trail,
- a human coordination surface,
- a CI verification layer,
- a source of recovery evidence,
- and an input to automated agent control.
The system observes Issues, branches, pull requests, commits, and CI results.
It reconstructs the current development state.
It dispatches workers, detects inconsistencies, reschedules tasks, and drives multiple changes toward one integrated result.
This can be described as:
A GitHub-native reconciliation engine for AI software development.
The name itself is less important than the underlying principle:
Design the control system around externalized development state, not around one agent’s private session.
The Orchestrator Is a Control Plane Above the Coding Agents
A coding agent is a worker that writes code.
An orchestrator is not simply a chat room containing several workers.
Its responsibilities include:
- decomposing large goals,
- deciding which tasks are safe to run concurrently,
- maintaining dependencies,
- observing external changes,
- reconstructing lost state,
- repairing invalid plans,
- integrating multiple outputs,
- and limiting human intervention to meaningful decisions.
From this perspective, Orchestune is less a multi-agent coding tool and more:
A development control plane for coding agents.
As individual agents become more capable, the amount of work that can be performed in parallel increases.
As the amount of parallel work increases, dependency management, integration, conflict prevention, and recovery become more important.
Better agents do not eliminate the need for orchestration.
They may increase it.
Conclusion
The most important question in AI-assisted software development is not how many agents can be started at once.
It is:
Can multiple imperfect and failure-prone workers be made to converge on one reliable result through a reproducible process?
That requires:
- decomposing before solving,
- preferring traceability over full autonomy,
- designing reconciliation instead of trusting stored state,
- proving independence before parallelizing,
- repairing broken plans rather than blindly retrying workers,
- separating generative implementation from deterministic integration,
- turning LLM diagnoses into reproducible rules,
- placing human approval at structural decision points,
- and storing operational knowledge in the control plane rather than the worker.
Orchestune began as a supporting mechanism for an AI-assisted novel-writing application.
The deeper problem it revealed was not specific to novel writing.
It was the problem of designing a development process for a world in which AI agents are software workers.
If AI agents are developers, they need a control layer above them to manage planning, state, conflicts, recovery, and integration.
And the most important qualities of that control layer may not be greater intelligence.
They may be:
Reproducibility, traceability, idempotency, and safe convergence.
GitHub Repository
Orchestune is available on GitHub:
The project is still under active development, but the repository contains the implementation and ongoing experiments behind the GitHub-native orchestration ideas discussed in this article.
Top comments (0)