We're building a software factory you can buy
Agentic coding is real, but the workflow around it isn't. Why we built FactoryKit: background coding agents that turn tasks into evidence-backed pull requests.
tldr: The best engineering teams now run software factories, pipelines where AI coding agents do the work and humans review pull requests. Ramp and Uber built theirs in-house. FactoryKit is the one you can buy: tasks in, regression-tested pull requests out, with a video recording as proof.
I haven't opened my local development environment in weeks.
A year ago that sentence would have embarrassed me. Today it is just how I work. I write a task, an AI coding agent picks it up, and some minutes later a pull request shows up with a video of the change working in a real browser. I review the PR, watch the recording, and merge. The tool doing this is FactoryKit, and at this point it has built roughly 25 of its own features. The factory builds itself.
This post is about why we built it, what we learned about agentic coding along the way, and why I think every serious engineering team will run something like this within a few years. Most of them will not build it themselves. That last part is the company.
The best engineering teams already built one
The most interesting thing happening in software engineering right now is not a model release. It is quieter than that. The best engineering organizations have stopped treating coding as a foreground activity.
Ramp built an internal tool called Inspect, a background coding agent that runs in sandboxed VMs with access to their real development environment. It now produces more than half of Ramp's merged pull requests, up from 30% at the start of the year. Uber built Minion, an agent platform wired into their monorepo. It ships about 1,800 code changes a week, and 95% of Uber's engineers use it.
Neither company bought this. There was nothing to buy. They assigned platform teams to build agent infrastructure: sandboxes, credentials, review workflows, the whole pipeline. It worked, which tells you the model is right. But most engineering teams cannot fund an internal platform team to build agent infrastructure. A ten person startup gets the same benefit from this model as Uber does, arguably more, and has zero chance of building it in-house.
That gap is our thesis. We are building the software factory you can buy instead of build, with the testing already inside.
What is a software factory?
A software factory is a development pipeline where AI coding agents do the production work, implementing changes, running checks, and testing the result in isolated environments, while engineers direct the work and review it through pull requests. Tasks go in. Software comes out, with proof that it works.
The term is old. Microsoft used "software factories" in the 2000s to describe process frameworks and code generation. The US Department of Defense runs entire programs under the name. But the meaning has changed underneath the words. When people say software factory in 2026, they mean what Ramp and Uber built: a system where agents produce the code and humans supervise the line. That is the sense I will use for the rest of this post.
From coding assistants to background coding agents
It helps to see the last few years as a ladder. Autocomplete suggested lines. Chat wrote functions you pasted in. In-editor agents like Cursor and GitHub Copilot edit files while you watch. Each step moved more work to the machine, but every step still needed you present, in the editor, supervising in real time.
Background coding agents are the step where you leave the room.
What's the difference between vibe coding and agentic coding?
Vibe coding is prompting your way to software you never really read, which is fine for prototypes and terrifying for production. Agentic coding is different: you hand a defined task to an agent that plans, edits, runs tests, and returns finished work for human review. Vibe coding removes the review. Agentic coding moves it to the end, where it belongs.
What is a background coding agent?
A background coding agent is an AI coding agent that works away from your editor. It gets a task, spins up an isolated environment, writes the code, runs your checks, and comes back with a pull request. You are not watching it type. You are reviewing its output, the same way you review a teammate.
This class is getting crowded, which is a good sign for the model. Devin positions itself as an autonomous software engineer. Google has Jules. GitHub Copilot now has a coding agent that opens PRs. Cursor has background agents in the cloud. All of them share the core loop: task in, pull request out. Where they differ, and where we spent our effort, is everything around that loop. FactoryKit is our take on background coding agents done as a complete factory rather than a feature.
How our software factory works
We did not set out to build a dev tools company. We run Hashnode, and more recently Bug0, and I wanted both products to keep shipping with one or two engineers. The factory was the internal tool that made that possible. Then we watched Ramp and Uber describe the same architecture we had converged on, and realized the internal tool was the product.
Building it for real forced a set of decisions that I now think of as non-negotiable for anyone running agents in production:
Every task runs in an isolated sandbox. The agent gets a fresh cloud VM, clones your repos, and works there. Your laptop is never involved. Nothing it does can touch anything outside the sandbox.
The agent never sees a real credential. No API key, no GitHub token, no secret of ours ever enters the VM. Credentials are injected into outbound traffic in transit, scoped per repository. An agent cannot leak what it never had.
You pick the agent per task. Claude Code, Codex, or Grok, chosen when you submit the task. Models keep leapfrogging each other, and a factory should not be married to one line of them.
The agent never touches git. It edits code. The factory itself commits, pushes, and opens one pull request per changed repository. Multi-repo tasks come back as coordinated PRs, not one tangled diff.
Every change is QA'd in a real browser, on camera. Before the PR opens, the agent runs the app in the sandbox and drives it in a browser while the session is recorded. The recording is attached to the pull request.
The result is the whole development loop, from task to reviewed PR, running in the cloud without anyone opening a local dev environment. The PRs arrive with evidence, not promises.
Everyone is building the ADLC. Almost no one is testing it.
There is a name forming for this whole space: the agentic development lifecycle.
What is the agentic development lifecycle (ADLC)?
The agentic development lifecycle, or ADLC, is the software development lifecycle restructured around AI agents: agents implement, test, and prepare changes while humans set direction and review results. Every serious dev tools company is now building some slice of the ADLC as a service.
Here is what most of them are missing: regression testing. An agent can write code fast, and the code can even be good, but the question a reviewer actually cares about is older and harder. Did this change break something a user can see? A pull request without automated regression testing is a demo, not a deliverable. Merging fifty agent PRs a week on unit tests and vibes is how you turn a productivity story into an incident story.
We got this insight the hard way, because our other product is a QA company. At Bug0, AI regression testing is the entire job, and we open-sourced the engine behind it as Passmark, a Playwright library for AI browser regression testing with caching, auto-healing, and multi-model verification of assertions. Writing end to end tests in plain English and having agents execute and verify them stopped being research and became infrastructure.
So the factory ships with the testing built in. Every FactoryKit pull request is regression tested with Passmark, in a real browser, and the video recording of that run is attached to the PR as proof. This is the part of the ADLC that everyone skips because it is hard, and it is the part that makes the rest trustworthy.
What it can't do yet
I want this post to survive contact with experienced engineers, so here are the current edges, stated plainly.
The sweet spot is standard web applications. Mobile apps are not supported yet. We are GitHub only for now, so GitLab teams will have to wait. Simple tasks finish in about five minutes, moderate ones in ten to fifteen, and complex ones in twenty to thirty. And a background agent is not magic: a vague task produces a vague PR. The teams getting the most out of the factory write tasks the way they would write a good ticket.
If your workload looks like a web product with a backlog of well-described features and fixes, the factory works today. If it looks like embedded firmware, not yet.
Where this goes
The last piece of ceremony is submitting the task at all, and that piece is already falling away.
The factory plugs into Linear today: connect your workspace, pick the labels to watch, and any issue that wears one gets picked up, worked in a sandbox, and answered with a pull request posted back on the ticket. That closes a loop product teams have wanted for years: PRD to PR, with verification in between. Write the requirements doc, break it into issues the way your team already does, label them, and the factory works through the queue while every PR arrives tested and recorded. Jira is next, and a Slack integration will let anyone start a task by tagging the agent. Alongside that, we are building team-wide shared memory, so decisions and caveats from every task carry forward and the agent improves with every task your team runs, plus imported context from the tools where your decisions already live.
Follow that line and the shape of the job changes. Engineers stop being typists with good taste and become editors with leverage: setting direction, writing sharp task descriptions, reviewing evidence-backed work. The backlog stops being a graveyard. It becomes a queue that drains overnight.
I think every serious engineering team will run a software factory this decade, the way every team today runs CI. Some will build their own, like Ramp and Uber, and for companies of that scale it may even be the right call. Everyone else will buy one. We are building the one worth buying, offered as exactly that: a software factory as a service, with regression testing where it belongs, inside every pull request.
It is early. We are looking for teams who want their backlog moving while they sleep. You can try it, or just watch a task run live, at factorykit.ai. We are the team behind Hashnode and Bug0, and the factory that wrote a quarter of itself is ready to work on your repos.
FAQs
What is a software factory?
A software factory is a development pipeline where AI coding agents implement, check, and test changes in isolated environments while engineers direct the work and review it through pull requests. The term once meant process frameworks and code generation; today it describes what Ramp and Uber built internally and what FactoryKit offers as a product.
How is a background coding agent different from GitHub Copilot or Cursor?
Copilot and Cursor assist you inside the editor while you work. A background coding agent works away from your editor: it takes a task, implements it in a cloud sandbox, runs the checks, and returns a pull request for review. You review its output instead of watching it type.
Is FactoryKit an alternative to Devin?
Both are autonomous coding agents that turn tasks into pull requests. FactoryKit differs in what surrounds that loop: you pick the agent per task (Claude Code, Codex, or Grok), every change is regression tested in a real browser, and the recording is attached to the pull request as proof.
How do AI coding agents test their own changes?
Most run the repo's existing checks and stop there. FactoryKit adds automated regression testing on top: after lint, types, and tests pass, Passmark drives the app in a real browser, verifies the change, and records the session, which ships with the pull request.
Are background coding agents safe to run on real repos?
They are as safe as their isolation. FactoryKit runs every task in an isolated sandbox, never lets the agent see a real credential, and never lets it touch git; the platform commits and opens the pull request, so nothing lands without human review.
Can an AI coding agent pick up tasks from Linear?
Yes. Connect Linear to FactoryKit, choose the labels to watch, and any issue with one of them gets picked up, implemented, and answered with a pull request posted back on the ticket. Jira is next.
