# AI Coding Factories Canonical: https://gaboesquivel.com/blog/2026-09-ai-code-factories **Published:** 2026-09-12 **Summary:** A reliable AI coding factory coordinates tasks, isolated execution, verification, and production feedback into a repeatable delivery process. **Categories:** Product, Engineering, Artificial Intelligence, Backend, Fullstack A coding agent can edit files, run tests, and open a pull request. Turning those capabilities into a repeatable delivery process requires a system that defines the work, supplies context, coordinates execution, verifies results, and learns from production. That is what I mean by an **AI coding factory**: an engineering workflow in which agents carry work through defined stages, with explicit criteria for advancing, retrying, or asking for help. You can build one with existing models and coding tools, without owning the infrastructure that trains them. Paul Iusztin's [Inside a Software Factory](https://www.oreilly.com/radar/inside-a-software-factory/) describes that broader lifecycle, from intake through release and production feedback. He also writes about an initial version that became so elaborate he stopped using it. That detail matters: the process has to make delivery easier for the people using it. ## Follow one change through delivery Imagine a recurring bug: submitting a form twice creates duplicate records. A coding agent might find the handler and propose a fix. A delivery process has to carry the work further. First, someone defines the expected behavior. What counts as the same submission? What should the person see while the request is pending? What happens when a request succeeds but the response never arrives? Those answers determine what the implementation and its tests need to prove. The work then moves through specification, implementation, verification, release, and production feedback. Each stage should leave something the next stage can use: - A specification defines expected behavior. - Implementation produces a reviewable change. - Verification produces evidence that the change meets the specification. - Release produces an observable change in the running product. - Production feedback shows whether duplicate records stopped and whether the change introduced another problem. ![Delivery pipeline from specification through implementation, verification, review, release, and production feedback](https://gaboesquivel.com/images/diagrams/2026-09-ai-code-factories.svg) A coding factory coordinates implementation, evidence, decisions, and production feedback rather than treating generated code as the finished product. The transitions are as important as the stages. A failed check should return useful evidence to the implementation step. An unresolved product question should go back to a person who can answer it. Neither should become an endless retry loop. ## What the system needs to carry I would organize the architecture around six responsibilities. A small setup can handle several of them with tools the team already uses: - **Context and specifications.** Repository instructions, product requirements, architecture decisions, examples, and acceptance criteria give agents a working understanding of the system. Keep this material versioned and close to the code, with current decisions separated from historical notes. - **Models and harnesses.** The model interprets the task and proposes actions. The harness assembles context and coordinates tool use. Their behavior needs to be evaluated together. - **Orchestration and state.** A coordinator tracks tasks, dependencies, assignments, retries, budgets, and completion. Durable records should make it possible to understand what happened and continue after an interruption. - **Execution environments.** The agent needs the dependencies and access required to do the work. Branches and worktrees separate code changes; sandboxes control execution and access to files, credentials, and networks. A separate branch is not a security boundary. - **Verification and release gates.** Tests, type checks, security checks, browser validation, and review determine whether a change meets its specification. Merging and deploying should have explicit conditions. - **Observability and feedback.** Logs, artifacts, costs, failures, and production signals let engineers diagnose runs and improve the workflow. Useful autonomy still depends on the configured system around the model, the same architectural concern as [AI Agents are Infrastructure](https://gaboesquivel.com/blog/2026-05-ai-agents). ## Orchestration and evidence [Anthropic's guidance on effective agents](https://www.anthropic.com/engineering/building-effective-agents) distinguishes predefined workflows from agents that dynamically choose their steps. A factory can combine both: a sequential pipeline for predictable work, parallel workers for independent tasks, and a dynamic split when subtasks emerge during investigation. Two unrelated bug fixes may be able to run in parallel. A database migration and a feature that depends on its schema need sequencing or an agreed contract. I would establish those dependencies and the files each worker may change before adding parallel execution. Long-running work needs continuity. Anthropic's [research on long-running harnesses](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents) uses incremental progress and explicit handoff artifacts to preserve work across sessions. For a coding factory, that means recording completed tasks, failed checks, unresolved decisions, and the next useful step. For the duplicate-submission bug, I would want a test that reproduces the failure before the fix and passes afterward, along with checks of the affected user flow. Disabling a button may improve the interaction while leaving the server vulnerable to a retry. Verification should cover the behavior the team agreed on, including that distinction. Agent review can help find gaps. The evidence still needs to come from running the relevant checks and inspecting the result. If a run reveals that the acceptance criteria were wrong, resolve that explicitly rather than letting the agent quietly weaken them to pass. ## Platforms and pieces What interests me about [Factory](https://factory.ai/) is its treatment of these concerns as a connected delivery system. Its [Software Factory documentation](https://docs.factory.ai/software-factory/overview) covers triage, implementation, validation, release, documentation, and monitoring. That is a useful scope to evaluate: how well does the platform carry work between stages, and can the team understand where a run stopped? [AI coding factories video](https://www.youtube.com/watch?v=ow1we5PzK-o) You can also assemble a factory around existing tools. These projects address complementary layers: - **[Sandcastle](https://github.com/mattpocock/sandcastle)** is a [TypeScript](https://gaboesquivel.com/tech/typescript) library for orchestrating coding agents in sandboxes, with configurable branch strategies and providers including Docker, Podman, and Vercel. - **[Machinist](https://github.com/owainlewis/machinist)** focuses on infrastructure for AI coding workflows. I would evaluate its execution controls and run records against the tasks I want to automate, including what must happen after an interrupted run. - **[Superpowers](https://github.com/obra/superpowers)** encodes a development methodology as composable agent skills. Its workflows include brainstorming, planning, worktree isolation, implementation, testing, and review within existing coding harnesses. - **[Addy Osmani's agent skills](https://skills.addy.ie/docs/getting-started/)** encode engineering workflows for specifications, incremental implementation, testing, review, and shipping, and carry that process knowledge into an existing agent environment. These tools operate at different levels. Skills describe how to work. Orchestration coordinates when work runs and how results move between steps. Execution infrastructure provides the environment. Putting them together still requires decisions about state, permissions, failure handling, and release. For a small team, I would begin with a coding harness, a few carefully chosen skills, an isolated environment, and existing CI. A managed platform becomes more attractive when coordinating repositories, users, integrations, and operational controls takes substantial time. ## Start with one task The engineer still owns the problem, architectural tradeoffs, and definition of done, as in [Engineering in the AI Era](https://gaboesquivel.com/blog/2026-02-engineering-ai-era). People also need to see what is running, why it stopped, and how to redirect it, as in [Evolution of AI UX](https://gaboesquivel.com/blog/2026-01-evolution-ai-ux). I would start with one recurring task and track time to an accepted change, review effort, defects, and total cost. Failed runs should tell us which instructions, tools, checks, or handoffs need improvement. Then I would expand the workflow when it has demonstrated that it can carry that task reliably. The useful outcome is a change the team can understand, verify, and operate in production. The factory earns its place by making that outcome easier to achieve repeatedly.