Status: working prototype and architecture exploration. It has implemented onboarding, workflow, review, and release-gate capabilities, but it is not an autonomous replacement for an engineering team.
The engineering question
Most coding assistants begin after a developer has already chosen the repository, interpreted the issue, found the relevant conventions, and decided how the change should be reviewed. That leaves the difficult coordination work outside the tool.
AI Dev Orchestrator tests a broader question: can repository knowledge, explicit agent roles, validation evidence, and human decision gates be assembled into one repeatable delivery workflow?
System boundary
The orchestrator sits between a work item and a GitHub pull request. It can inspect and profile a repository, retain architecture and convention snapshots, dispatch bounded workflow roles, run repository-specific commands, publish review status, and prepare a change for human judgment.
It does not own product intent, credentials, branch-protection policy, or final approval. First-use runs require manual review, and the orchestrator has a permanent self-modification guard that prevents it from auto-merging changes to its own repository.
What was implemented
- Repository onboarding that detects a capability profile, runs known checks, and records architecture and coding-convention snapshots.
- Jira-to-repository mapping and workflow dispatch backed by PostgreSQL and a Redis queue.
- Separate planning, implementation, testing, review, documentation, and governance responsibilities inside a coordinated run.
- GitHub status publication, deployment validation hooks, clarification handling, and an operator dashboard.
- First-use and self-modification safety gates that keep early or self-referential releases under manual control.
Key decisions and trade-offs
Role separation made the workflow easier to reason about than one long model conversation, but it also introduced coordination state and more places where incomplete context can propagate. Repository profiles use automatic detection for common stacks and explicit command hints for atypical repositories; that keeps onboarding convenient without pretending detection is always correct.
The release gate uses completed-run evidence rather than model confidence. This makes the path slower than unconditional automation, but keeps merge authority outside the generated work. The same trade-off appears in repository bootstrapping: the system opens a branch and pull request rather than writing directly to the protected integration branch.
Inspectable evidence
The public AI Dev Orchestrator repository on GitHub contains the FastAPI service, workflow and queue code, repository profiling, GitHub status integration, bootstrap templates, tests, phase summaries, security notes, and operations runbooks.
That repository supports the claim that the workflow exists as implemented software. It does not by itself prove broad team adoption, unattended reliability, or effectiveness across every repository shape.
Limitations and what remains unproven
- External-project setup still requires operator configuration for Jira mappings, repository permissions, branch protection, and deployment profiles.
- Automatic capability detection can fall back to an unknown profile; explicit command hints are then required for meaningful validation.
- The workflow has been dogfooded and exercised through bounded scenarios, not validated across large numbers of teams or repositories.
- Model output still requires human review. More agents do not remove ambiguity, security risk, or responsibility.
- The prototype does not establish comparative delivery-speed, cost, quality, or reliability benchmarks.
Outcome and learning
The useful result was not “AI can write the whole system.” It was a clearer delivery architecture: repository context must be acquired before generation, responsibilities must be separated, validation must produce evidence, and authority must remain explicit.
That changed the design from a chain of tools into a governed workflow. The remaining manual gates are not unfinished polish; they are part of the system boundary.