Designing our first AI workforce

The problem we are trying to solve

We want to turn architect-approved issues into reviewable software changes without asking one person to supervise every coding step. Parallel implementation is useful only if the resulting changes still work together and the team can explain what was approved, tested, and released.

Our first scope is deliberately small: this website, independent issues, and a repeatable path from a written requirement to a release candidate. We are using our own delivery process as the learning environment.

Our current understanding

An AI workforce needs an operating process around the coding agents. People define business intent, architecture, acceptance criteria, and dependencies. Agents implement bounded tasks. Separate review and integration steps establish whether the changes are ready to advance.

The unit of accountability is a specific issue and commit. A review of an earlier version does not establish that a later change is acceptable. Likewise, individually successful changes still need validation as a combined candidate.

The delivery model we designed

A human marks an issue ready. GitHub Actions captures a batch of up to five independent issues. Each implementation runs in its own disposable container and checkout, starting from the same development commit. A separate publishing job turns each patch into a pull request.

An independent review checks each issue and its exact commit. Only after all reviews pass does integration combine the changes and run lint, type checking, a production build, and website smoke checks. Conflicts or failed checks stop the batch before the development branch advances.

The tested candidate advances to the development branch and becomes a release pull request. A human selects the exact candidate for release; the release workflow rechecks it before advancing the production branch. Deployment must then be verified separately.

Why we made these choices

We chose ordinary GitHub Actions and the official Codex action for the first version. For this website, that lets us use an existing job queue and runner model without adding a database or a separate message broker.

We plan to prove one issue on GitHub-hosted compute before provisioning a larger worker. If the proof succeeds, a dedicated Azure VM can host multiple runner registrations. One runner registration accepts one job at a time; five concurrent implementations require five registrations.

Implementation jobs produce patches. Separate trusted jobs publish and promote changes. Keeping those responsibilities apart makes the flow easier to inspect and limits the write permissions required by coding jobs.

What we have prepared—and what remains unproven

The working draft records locally prepared workflows, a controller, runner setup instructions, and controller tests. Its validation covers cases such as stale reviews, changed commits, concurrent branch movement, merge conflicts, and combined-candidate construction. Local website checks are a separate part of validation.

At the time of this first entry, the workforce is disabled by default. We have not demonstrated a successful end-to-end agent run, provisioned the Azure worker, or established cloud operating cost and throughput. Local preparation is evidence that the design can be inspected; it does not establish operational success.

Our smoke checks check page responses and selected site content. They do not establish full functional coverage or implementation correctness. The first live issue needs its own acceptance criteria and appropriate verification.

The boundaries we are keeping visible

Version one assumes independent issues. It does not schedule a dependency graph, resolve conflicts autonomously, or provide an automatic review-and-repair loop. Failed batches require investigation before retrying.

Human release approval is part of the workflow. Repository permissions and branch rules determine how strongly that control is enforced. A workflow convention alone does not prevent another authorized writer from changing a branch.

Runtime limits are not a hard spending cap. Model usage, hosted build minutes, VM time, and storage need separate observation. We will assess these after a successful small proof rather than publish estimated savings as results.

What we will learn next

Our next milestone is one small issue completing implementation, exact-commit review, combined validation, development promotion, human release approval, and deployment verification.

For that run we want to record elapsed time, model and infrastructure usage, review findings, failed checks, human interventions, and whether the acceptance criteria were met. We can then compare the observed effort with our existing process and decide whether parallelism is useful.

We will extend this case study as evidence arrives and add dated entries for subsequent experiments. Changes to our understanding will be part of the record.