Coding agents are very good at finishing bounded tasks.
They are not, by themselves, good stewards of large systems.
That distinction is what led me to build Issue-Orchestrator: a software-engineering control plane for coding agents.
The model is a division of labor.
You define what "good" means for your codebase. Issue-Orchestrator makes those standards enforceable inside the agent workflow.
You bring the standard:
- a named architecture
- tests, validation, and coverage gates
- review criteria
- right-sized, reviewable issues
- a clear definition of done for each one
Issue-Orchestrator brings the enforcement:
- an isolated worktree per issue
- reviewer agents and bounded rework
- crash recovery and reconciliation
- timelines, transcripts, and session replay for inspection
- human merge authority
The shift that makes it work is simple: agent output is a claim, not authority.
Nothing advances just because an agent says it is done. The orchestrator re-observes GitHub state, worktree state, validation records, and review output before moving an issue forward. Otherwise the work reworks, blocks, or waits for a human.
This matters because prompt discipline does not scale by itself. You can keep adding instructions telling agents to respect the architecture, write better tests, maintain coverage, and avoid bypassing validation. At some point those instructions become noise. If the standard matters, it needs to be checkable and enforced.
Issue-Orchestrator uses GitHub issues and milestones as the external work system. Large goals become milestones. Milestones become human-sized issues. Issues carry acceptance criteria, labels, dependencies, and enough context for an agent to attempt bounded work without inventing the project plan on the fly.
Under the dashboard, each running issue is an enforced workflow. The orchestrator delegates to coding, validation, and review steps, but owns the state transitions. The agent can produce work. The system decides whether that work is allowed to advance.
This is not a fully autonomous coding system, and it is not a prompt collection. It is an attempt to make agentic software development look more like software engineering: explicit standards, mechanical checks, recoverable state, inspectable artifacts, and humans at the merge.
The project is open source under Apache 2.0:
https://github.com/BruceBGordon/issue-orchestrator
Status: early beta. Core orchestration, guardrails, review workflow, and dashboard are in daily use; external setup is still being hardened.
If you are using coding agents on real repos, I would be interested in how you are handling the same problem: what do you enforce mechanically, what do you leave to review, and where do agents still quietly erode the system?