Why I built a code factory
I initially used coding agents like other development tools: open a project, describe a task, inspect the result and start the next step. This helped me build small apps and websites. I also spent a lot of time sitting beside the agent, supplying context, responding to questions and moving results between tools.
I wanted to hand over more of that process. An agent on my laptop depends on my current session. For longer tasks, I wanted an environment that remains available when the laptop is closed, with a persistent place for requests, project knowledge and results.
Experiments with a personal assistant on a virtual server grew into my code factory. It connects task intake with analysis, implementation, testing and independent review. The intended output is a traceable change that can be assessed against its requirements.
I use existing tools to do this. My contribution is connecting them, defining responsibilities and designing the handoffs that let work continue. This includes less comfortable questions: who may change a task's state, what happens after a failure, and what makes a task complete?
The inspiration: OpenAI’s software factory
A reference point was Gergely Orosz’s article Inside OpenAI’s agentic software factory, alongside Owain Lewis’s discussion of it. The described workflow connects coding, CI, specialist reviews and following a change into production. Risk determines which additional checks are needed.
I was particularly interested in the connections between these stages. Implemented code is an intermediate result. Tests still need to run, feedback needs to be assessed and results need to reach the next person or agent. Automation should account for those handoffs.
My setup operates at a much smaller scale. I work with my own projects, available agent tools and a server I administer. OpenAI’s infrastructure, performance figures and approval mechanisms cannot be assumed to apply to my system. The article provided inspiration; the implementation had to fit my tasks and resources.
How the system fits together
The system runs on a virtual Linux server. Docker containers separate services and runtime environments, allowing components to operate independently of my local development environment. This separation helps organise the system. An agent’s actual permissions still depend on its configuration and available tools.
Hermes is my personal point of contact for requests and results. Paperclip provides the shared coordination layer, bringing together tasks, ownership and status. GitHub remains the home of repositories, issues, code changes and pull requests.
The CTO role coordinates development tasks and delegates individual stages to specialist agents. Analysis, implementation, testing and review each receive their own assignment. A QA role carries out additional checks at the organisation level. The overarching CEO role is responsible for operational approvals and escalations.
These names describe responsibilities in my configuration. Existing coding agents such as Claude Code and Codex perform the development work. My project integrates these building blocks through shared task routes, context, handoff rules and a defined path back to the result.
From issue to pull request
A task might begin with a bug, a missing feature or a test that does not yet cover an important case. Before implementation starts, the expected change and the conditions for a correct result need to be clear.
Analysis examines the existing repository and turns the task into a work order with verifiable acceptance criteria. The implementation agent then works in a separate Git workspace. This limits conflicts with other changes and makes the resulting diff easier to assess.
Testing follows. The test agent checks the requirements and may add tests. Its role prevents it from changing product code simply to produce a green result. If the implementation fails, the findings return to the implementation stage. Another agent performs an independent review and also does not edit the code.
After these stages, the publisher opens a pull request. CI runs the checks configured in that repository. Failures and review findings must feed back into the workflow. The factory defines bounded correction loops so that a problematic task cannot continue indefinitely.
The boundary is explicit: the code-factory pipeline does not merge its own work. It delivers a reviewable change. Final operational approval belongs to the CEO role in my surrounding organisation, outside the implementation pipeline. Producing a pull request, approving it and deploying a change are separate decisions.
Context that outlives a session
Context was a recurring problem in my early work with agents. A decision could be clear in one session and need explaining again in the next. With several agents working on a task, a useful handoff becomes especially important.
Project rules, work orders and verification results therefore belong in the system. Skills describe recurring workflows. Repository documentation explains the project itself. Tasks and comments record what was investigated, which findings remain open and what should happen next.
OpenAI’s Harness engineering describes a related approach: a short map pointing to structured knowledge in the repository. I find this useful as a design principle. An agent needs an entry point and discoverable sources so it can retrieve details when needed.
Persistent information still needs verification. An older note may describe an intention while today’s code behaves differently. I therefore treat documentation, source code, CI and observed behaviour as different kinds of evidence. A closed task alone, for example, does not establish that the corresponding change has reached the main branch.
Checks and clear boundaries
Separating roles is intended to prevent one agent session from approving its own work without an independent check. The implementer is not also the independent reviewer. Publishing a pull request does not grant permission to merge it. These rules form part of the agents’ instructions; technical permissions and repository rules need to support them.
A successful review is not proof of correctness. CI adds reproducible checks, but their meaning depends on the tests being run. A green suite can miss a bug that it does not cover. Each result should therefore make clear what was checked and which questions remain open.
Operations have a separate communication route. Routine messages and unresolved technical incidents should reach the responsible role within the organisation. My wake gateway can deduplicate repeated reports and create an internal task for the CEO role. The notification route examined for this article does not send me a Telegram message.
This matters in daily use. Automation that constantly requests confirmation or reports the same incident repeatedly still consumes attention. Alongside execution permissions, the setup needs rules for reporting back. Serious exceptions, substantial new commitments or a required personal login remain reasons to involve me.
A concrete result from practice
An example from one of my learning-app repositories shows how narrow a useful factory task can be. The actual function that extracts PDF text page by page needed to become directly testable. A test should be able to call the product code rather than check a reimplemented version of it.
The resulting change exposed that function specifically for testing. According to the pull-request documentation, its behaviour was preserved; the change concerned its name and the annotation for test access. A separate review checked, among other things, that the test called the production function.
The pull request was merged on 9 October 2026. Research for this article found nine successful checks recorded against its PR revision, including Flutter tests, a web release build, Functions checks, Rules tests and a secret scan. The merge commit was also verified to remain in the history of the main branch.
This example establishes one delivered change and its associated check results. It does not establish the failure rate of all factory tasks or the quality of the whole application. The bounded claim makes the evidence useful: the change, its checks and its destination can all be identified.
What the system does not establish
The factory is my own development setup. Its use so far does not support a reliable percentage for time saved or quality improved. Establishing that would require comparable tasks, a sound measurement method and enough runs. Operating costs and supervision effort belong in that calculation too.
For this case study, existing notes were checked against selected server files and an actual pull request. The Paperclip health endpoint responded successfully during the inspection. That establishes the service’s availability at that moment. It does not replace a fresh end-to-end run through every agent.
The workflow also depends on its environment. Models have limits, external services can fail, storage can run low and roles can receive excessive permissions. Containers alone do not resolve these questions. The system still needs maintenance, verifiable state and decisions about which tasks it should take on.
Adapting it to a company would require a separate assessment of that company’s data, permissions, infrastructure and approval processes. My environment is a practical starting point for those conversations. A successful personal project does not establish that the same setup will work unchanged in another organisation.
What I take from the project
The most valuable learning for me is in the handoffs. A precise task helps the next agent. A traceable test result helps the reviewer. A clear status helps the coordinating role. When these connections are missing, I have to recreate them myself.
Part of my development work therefore shifts towards architecture and process design: making requirements concrete, limiting responsibilities, making context accessible and assessing results through evidence. Technical understanding remains necessary. I need to judge whether a task was decomposed sensibly and whether the proposed evidence supports the claimed result.
Next, I want to evaluate completed tasks more systematically. Which tasks proceed without additional questions? Where do corrections recur? Which checks actually find defects? Those observations should guide the factory’s development.
The project brings together two areas I enjoy: developing software and designing workflows in which other people or agents can continue useful work.