Overview
This project explores a practical question: what infrastructure and policy are required for an AI coding agent to behave like a dependable member of a software-development workflow rather than an unrestricted code generator?
The result is a controlled, long-lived development environment in which an agent can receive ticket information, complete implementation work, open a pull request, respond to review feedback, and notify a human reviewer when the work is ready.
The problem
Producing code is only one part of software delivery. Dependable implementation also requires repository state management, scoped credentials, project-specific policy, repeatable validation, structured review, and an accountable approval boundary.
Without those controls, an agent may produce a plausible change while bypassing the practices that make the change reviewable and safe to integrate.
My role
I designed, built, and operate the environment, source-control interface, ticket workflow, validation policy, and human handoff. I also use the platform for ongoing research into collaboration patterns and role-specific agent behavior.
Current workflow
I supply a ticket number and description. The ticket number becomes the branch identity. The agent then:
- Inspects repository status and synchronizes the ticket branch.
- Reads project policy and analyzes the requested change.
- Modifies the implementation and runs relevant validation.
- Commits with the required ticket prefix and pushes the branch.
- Opens a structured pull request and reports check results.
- Notifies me that the pull request is ready.
When review comments require changes, the agent retrieves top-level and inline feedback, applies corrections, reruns validation, commits and pushes the update, and requests re-review. Human review remains the final approval checkpoint.
Controlled environment
The agent operates inside a hardened, long-lived Docker image containing Codex CLI, a dedicated source-control identity, project policy files, controlled source-control tooling, and required build utilities.
Source-control policy
Agents do not receive unrestricted source-control access. A controlled wrapper exposes approved operations for repository status, diffs, fetching, ticket synchronization, commits, pushes, pull-request creation, comments, reviews, and check inspection.
The workflow enforces ticket-based branches and commit prefixes, merge-based synchronization, structured pull-request descriptions, required testing disclosure, scoped changes, clean-working-tree expectations, and secret protection. History rewrites and force pushes are disabled by default.
CI and build behavior
Woodpecker provides CI validation. Agents inspect and report failures rather than bypassing or working around them. Maven and Docker operations use controlled execution paths because project builds may start containers.
Proof of use
The workflow is used across more than a dozen software and infrastructure projects. It has completed dozens of merged pull requests while building and improving the platform itself.
Those changes have covered source-control tooling, review commands, CI pipelines, secure build images, Maven and Docker workflows, repository synchronization, backup automation, deployment configuration, and operational documentation.
Active research
The current workflow begins with me supplying ticket information. I am researching and prototyping:
- VoceChat (research) as a collaboration interface
- Agents interacting more like members of a development team
- Specialized roles for architecture, feature development, testing, and evaluation
- Model selection by task and role
- Genetic algorithms for evaluating combinations of models by role
These are active experiments, not a finished autonomous engineering organization.
What this demonstrates
- Agentic workflow architecture
- Secure automation and source-control policy
- Human-in-the-loop engineering
- CI and developer-platform integration
- Applied AI experimentation
- Bootstrapping a system through its own workflow