/
Company
Seven lessons from building Alpic's software factory
Over the past four months we rebuilt Alpic's development cycle around coding agents, with a deliberately extreme goal: a software factory in which autonomous agents write every line of code. We didn't get there. What we built instead ships features and bug fixes about twice as fast as our previous process, with no drop in code quality or infrastructure uptime, and it keeps humans at a handful of checkpoints we no longer believe can be removed.
Why we tried
Software factories have become a genre of engineering blog posts. Stripe reports that more than a thousand of the pull requests it merges each week are written entirely by its internal coding agents, called Minions, and every one is still reviewed by an engineer. OpenAI describes a five-month experiment in which a small team shipped a product of roughly a million lines without writing any of it by hand. Ramp has written about Inspect, its in-house background agent, and WorkOS presented its own factory at AI Engineer World's Fair. We wanted to know how much of this holds up at a company without a dedicated developer-productivity team, and, more pointedly, how a codebase stays maintainable when agents write most of it.
The term “software factory” describes a familiar loop. Ideas come from the team's product vision or from user feedback; the product team turns them into specifications and designs; engineers implement them; and the release goes to production, where monitoring and maintenance feed the next round of ideas.
The software development life cycle
A software factory automates as much of that cycle as it can, much as assembly lines automated car manufacturing a century ago. A dark factory, named after manufacturing plants that run with the lights off, automates all of it.
We set ourselves three objectives: ship features and fixes faster end to end, raise code quality and infrastructure uptime (or at the very least not degrade them), and bring down the token cost per feature as the process matured.
Alpic's factory. Boxes are production cells and hexagons are quality gates; Ice Blue gates are automated, Berry ones are human.
Production cells and quality gates
Every factory runs two kinds of processes. Production cells are where a person or an agent makes something, such as a spec or a piece of code. Quality gates are where someone checks that output and sends it back if it isn't good enough. Looking at our development cycle this way showed us three ways to bring agents in, and each one has a cost.
The first is to let agents take over production tasks. That speeds up output, but every extra pull request lands on a gate. The second is to replace human gates with agentic ones so the gates keep pace, which is the hard part, because an automated check only helps if it catches at least as much as the person it replaces. The third is to add routines nobody had time for before: they open up work the team could never get to, and they put even more strain on review.
What follows are the seven things we learned doing all three.
Learning 1: product agents don't work
Our first attempt let agents generate product requirements documents and technical specs end to end. The output was bad enough that we dropped the approach.
Next we built co-pilot skills for our product engineers, modeled on Matt Pocock's "grill me" skill, in which the agent questions the human step by step before drafting anything. For small features this works reasonably well. On long, complex projects it breaks down: the agents write far too much, handle small edits clumsily, and make awkward collaborators when several people and several agents work in the same Notion page. People lose confidence in the output and stop reading it, which defeats the purpose of a requirements document.
We also reached a less technical conclusion. For our product engineers, writing the spec is how they think a feature through, and the competitor research and mockup iterations are where they decide what to build. When an agent drafted the document, much of that thinking didn't happen.
One automation earned its place. A research agent reads our meeting notes, CRM and analytics, researches competitors, and gives the product team a brief before a feature is scoped. Beyond that, product definition is the stage where automation returned the least, and the last place we'd point a team starting out.
Learning 2: if you want your code on autopilot, write detailed specs
Our tech strategy documents used to stay fairly abstract, because the engineer reading them would fill in the gaps. An agent won't, so if we wanted features implemented in one pass, the spec had to settle the unknowns in advance. Ours now cover the architecture along with database schemas, the code modules to use, the edge cases and, where it helps, pseudo-code.
We also moved peer review from the pull request to the spec, which is now where the team discusses and challenges design. The back and forth happens before any code exists, and once the spec is settled, a single engineer reviews what the agent produces. The time we spend on this phase roughly tripled, but it has paid off many times over: each hour spent resolving an edge case in the spec saves several hours of steering an agent or iterating on its pull request later. Once the spec is approved, a final skill breaks the project into Linear issues, which the engineer who owns the project re-reads before they go to the agents.
Learning 3: context is everything (ok, duh, but how)
Given a precise enough spec, current models can handle the whole implementation, on one condition: they need the same context a human engineer would have. That sounds pretty obvious but in practice that took three investments.
An identical dev environment, ready in seconds
Agents need a machine running exactly the stack our engineers use, which meant cloud agents working inside sandboxes that contain all of it. This was the hardest foundation to build. Alpic relies on several AWS managed services, a GitHub App and Stripe, each of which needs a separate environment per developer, and a sandbox is no use to an agent if it takes minutes or a manual step to start. We built pre-warmed sandboxes with pre-seeded databases and pre-installed services, and replaced a number of OAuth flows with machine-to-machine authentication. A sandbox now comes up in a few seconds.
Access to the data engineers look at
Our agents can read GitHub, Linear, Notion, Sentry, PostHog and AWS, and nothing in production data. Granting that much access felt like a leap of faith, but an agent that can't see what an engineer sees will always underperform that engineer, and the gap closed as soon as we opened access.
Writing conventions down makes divergence expensive
Every team carries rules that live only in people's heads. We tightened static linting and documented our coding conventions, but the most effective rule took one sentence to write: any implementation that departs from existing patterns in the codebase requires an architecture decision record, and should happen only when there's no alternative. Instead of trying to enumerate every convention, we made it costly for the agent to invent new ones.
Learning 4: don't kill your human code reviews (yet)
As agent-written PRs pile up, dropping human code review is the most tempting cut, and plenty of teams are making it. We kept it, for two reasons. Agents still write code that works today and decays over months, and catching that requires someone who knows where the codebase is heading. The second reason is ownership: if agents write all your code and production goes down at 3 a.m. in a way they can't fix, someone has to understand it.
At Alpic every agent-generated PR has a named engineer responsible for it, and that engineer can take over the agent's session in its cloud sandbox and finish the work directly.
What we did change is how much reaches the human reviewer. Agentic reviewers now run before any person looks at the code. Two practices made the largest difference: using a different model for review than for implementation, and splitting review across specialists (security, performance, code quality) that each see the full codebase and context instead of only the diff. Specialists multiply token costs quickly, so we run two, a general reviewer and one focused on code quality.
Learning 5: improve your quality gates
Every production task handed to an agent pushes more work onto the gates, so the gates need investment of their own. Part of that goes into checking output faster: a quicker CI with higher test coverage, the agentic reviews described above, QA loops, and loops triggered by production alerts so the team reacts sooner when something breaks.
After a PR merges, it still goes through manual QA on staging. We haven't been able to remove that step, but QA agents now make it faster and considerably more thorough. Browser use has improved to the point where agents test credibly, provided they have a preview environment for each PR, a browser driven through the Playwright MCP server, a skill containing QA instructions, and every test account and test card the flows require. Their main contribution is coverage: they run the tedious checks a person skips on a busy day, and that has raised our confidence in each release.
The other part goes into improving the process itself. Once a week the whole team goes through the previous week's agent PRs together, looking for review comments that keep recurring. Each one becomes a candidate for a new lint rule, a written convention or an architecture gate, so that nobody has to leave the same comment twice. We run this loop by hand because we wanted to learn from it first, and a skill could run the same review agentically once you know what to look for.
Learning 6: add new AI routines to your workflows
Routines are the specialists you always wanted to hire and never had the budget for. They're agents that sweep the whole codebase on a schedule, each with a specialty: a security agent that pentests code and infrastructure, a UI agent that opens the dashboard in a browser and tries to break it, an agent that hunts for performance problems. They resemble the PR reviewers, but they examine everything instead of a diff and run once a week, which keeps them cheap.
The UI agent has impressed us most, surfacing some bad interface bugs along with improvements nobody on the team had thought to make.
Left alone, routines can bury a team in pull requests, so ours run under three constraints. An agent opens a PR only when it judges the change materially useful, each run opens at most five, and the routine doesn't run again until every PR from its previous batch is closed. We keep iterating on their instructions.
Learning 7: get your team's buy-in
Again, this might sound obvious at this point, but the first versions will work worse than whatever your engineers are used to, and reaching something better takes many iterations. That requires patience, and a team motivated enough to keep going until the factory works. This is the key to the long-term success of your software factory and the engineering teams managing it.
What changed in our stack
The largest shift was moving coding agents off developers' laptops and onto cloud infrastructure. We tried proprietary cloud agents first and moved away from them for two reasons: we want to switch models freely, and we want to open any remote coding session on demand. The orchestrator that connects Slack, GitHub and Linear to the agents and supervises them in their sandboxes turned out to be easier to build than we expected, and several open-source libraries cover most of what it needs. CI/CD barely changed, since it was already in good shape.
On the product side, we still write requirements in Notion while we look for a tool designed for several people and several agents editing the same document. Design moved from Figma to Paper, whose MCP server makes it far easier for agents to read and modify mockups.
A complete look of what changed in our stack can be found below:
Inside our orchestrator
Our orchestrator, Parallel, is built around one rule: one conversation, one sandbox, one persistent agent session. Requests come in from Slack, Linear, GitHub, Notion or a web UI, and scheduled tasks and production alerts can start conversations too. All of them reach the same TypeScript control plane, which runs Hono and Chat SDK on Railway.
For each turn, the control plane finds the conversation, queues the work, starts or resumes that conversation's Daytona sandbox, and talks to an OpenCode server inside it over HTTP, so follow-ups reuse the same sandbox and agent session. Redis holds conversation metadata, messages, state and costs. The agent's transcript lives in the sandbox and is backed up to a Railway bucket after every turn, which means a session can be restored into a fresh sandbox.
Each sandbox contains the full development environment, our repositories, and the skills and MCP servers that give the agent its working context, with models served from Azure. Results go back to the channel the request came from, and pull requests and Linear issues are linked to the conversation, so later feedback resumes the same work. The separation that matters is between the control plane, which manages conversations and their lifecycle, and the sandbox, where the agent does the work.
Results
Measured against our three objectives, the factory delivered on the first two. We ship about twice as fast, and code quality and uptime have held steady. Token cost per feature remains a work in progress: our spend has stayed reasonable, so we haven't made optimizing it a priority yet.
Where this leaves us
In the end, our factory ended up light rather than dark. Agents now handle implementation, first-pass review, browser testing and a weekly sweep of the whole codebase, while the people on the team spend their time where judgment matters most: deciding what to build, settling the design in the spec, and owning what ships. The human checkpoints moved rather than disappeared, and most of them moved earlier in the cycle, where an hour of thinking saves the most rework later.
If you're starting now, invest in SDLC fundamentals and in cloud agent orchestration, since good fundamentals help humans and agents alike and orchestration compounds as models improve. Start small and iterate every week rather than rebuilding everything at once.
Several pieces are still missing. Production remains manual until we have the traffic to let agents decide on rollouts, token spend per feature hasn't been optimized, and our product specs still live in a tool built for people rather than for people and agents editing together. We expect the factory to keep changing shape as models improve, and each of these gaps is where we'll invest next.
We'd love to hear how you've built your own factory, and what you'd do differently!
Liked what you read here?
Get our newsletter!
