The Agentic Software Factory in 2026: How AI Agents Now Plan, Build, Test and Ship Code
Recently I wrote about Codex Cloud, where an agent keeps working after you close the laptop. Since then a bigger phrase keeps popping up in launch posts and docs: the software factory. People use it for a whole line of agents that carry an idea from a ticket to a merged pull request, with one agent per station.
I wanted to understand what that line actually looks like in October 2026, which tools are really doing it, and where the humans still sit. This is my plain-English map, with links to the official docs so you can check every claim yourself.
What an agentic software factory is
The phrase is older than AI agents. The US Air Force’s Kessel Run unit became the best-known “software factory” of the DevSecOps era. That was about humans and automated pipelines shipping fast. The 2026 version swaps many of the human hands on the line for agents.
The clearest description I found comes from Factory, a company that literally named itself after the idea. In its June 15, 2026 post, Factory 2.0: From coding agents to software factories, the founders describe a loop. Signals come in (bug reports, customer feedback, business requirements). They get triaged into planned changes. Those changes are built, tested, reviewed, secured, shipped and monitored. Monitoring creates new signals, and the loop starts again.
I like that framing because it moves the question away from “which coding assistant is best?” and toward “how does work flow through my team?” A single agent writing code is a tool. A factory is a system with stations, checks and an owner.
How the line runs: spec, code, tests, review, deploy
Every setup I looked at follows roughly the same five stations. The names change by vendor, but the shape holds.
1. The spec
Agents do much better with a written target. GitHub’s open source Spec Kit turns this into a set of commands: /speckit.specify to describe what you want and why, /speckit.plan to pick the stack and architecture, /speckit.tasks to break it into a dependency-ordered tasks.md, then /speckit.implement to build it. A final /speckit.converge step checks the code against the spec and adds tasks for any gaps.
Kiro works the same way inside its IDE. Every spec produces three files: requirements.md (user stories and acceptance criteria), design.md (architecture and sequence diagrams) and tasks.md. Requirements use EARS notation, the “WHEN … THE SYSTEM SHALL …” pattern, which reads almost like a test case.
2. Agents write the code
This is the station most people picture. You hand an agent a task, and it works on its own branch in a cloud sandbox. GitHub’s Copilot cloud agent can research a repository, plan changes, edit files, and run tests and linters in a short-lived cloud environment. Factory’s Missions go a step wider, splitting a big job like a framework migration into subtasks that several agents run in parallel.
3. Tests
Tests are what keep the line honest. The agents run them as they go, but the bigger point is that your existing CI still runs on whatever they push. Spec Kit’s docs say tests get generated inside each user story’s phase when you ask for them, so the checks arrive with the feature rather than weeks later.
4. Review
Review is now partly done by agents too. Copilot cloud agent, by default, runs a security check and gets a second opinion from Copilot code review before it finishes a pull request. I covered the desktop review flow in my Codex CLI and code review post, so I won’t repeat it here. The short version is that an agent reviewer is a filter, and a person still owns the merge.
5. Deploy and watch
Deploy is usually your normal pipeline after a human merges. What changes is the last mile of the loop. Factory’s pitch is that production signals flow back in as new work. Either way, you need to see what the agents did. That’s an observability problem, and I wrote a whole LLM observability guide on it.
The tools actually building these lines
I kept this to tools whose official docs I could read this week. I’ve skipped pricing, because it shifts too often.
Factory Droids
Droids take a task in plain language and plan, write, test and open a pull request. They work in the terminal, IDEs, the browser and Slack, and you can pick Claude, GPT, Gemini or other models per task. Autonomy is adjustable, from fully supervised to autonomous. Factory says its software factories are already in production at companies including NVIDIA, EY, Adobe and Palo Alto Networks. That’s the company’s own claim, so treat it as such.
GitHub Copilot cloud agent
You can assign an issue to Copilot the same way you’d assign a teammate. It reads the issue title, description and existing comments, works on a branch, opens a pull request, and asks you to review. A few hard limits are worth knowing: one repository per run, one branch and one pull request per task, and a maximum session of 59 minutes.
Claude Code GitHub Actions
Anthropic’s Claude Code GitHub Actions runs Claude inside your workflows. Mention @claude in an issue or pull request and it can implement changes and push commits. Give it a prompt instead and it runs on any GitHub event, including a schedule, so you can build stations like a daily report or an automatic review on every pull request.
Where humans stay in the loop
This is the part I read most closely, because “autonomous” is easy to say in a launch post. The docs are more careful.
GitHub’s risks and mitigations page is the clearest example. Copilot cloud agent can only push to one branch. Its pull requests must be reviewed and merged by a human. It cannot mark its own pull request ready for review, and it cannot approve or merge. By default, GitHub Actions workflows on its pull requests don’t run until someone with write access approves them, because workflows can reach secrets.
Claude Code GitHub Actions has similar gates. The person who triggers a run on an issue or pull request needs write access, and bot accounts are rejected unless you allow them, which stops bots from triggering each other in a loop.
So in practice humans hold four jobs:
- Writing and approving the spec. Kiro even lets you keep approval gates between requirements, design and tasks.
- Approving workflow runs on agent pull requests.
- The merge. GitHub’s agent can’t merge at all, and Anthropic’s docs tell you to review Claude’s changes before merging.
- Owning the outcome after deploy.
The risks: quality, security and cost
Quality
The best data here is still the 2025 DORA report from Google Cloud, based on nearly 5,000 survey responses. Its central finding is that AI amplifies what’s already there. Adoption was linked to higher delivery throughput, but it still had a negative relationship with delivery stability. And 30% of respondents reported little or no trust in AI-generated code. DORA’s advice is to fix the safety nets first: automated tests, version control habits and fast feedback. A factory that produces more changes without those just produces more breakage.
Security
An agent that can push code is a new kind of insider. GitHub names the risks plainly: vulnerable code, prompt injection hidden in issues, and leaking code or secrets. Its mitigations include filtering hidden characters (text in an HTML comment on an issue isn’t passed to the agent) and a firewall that limits internet access. GitHub is also honest that the firewall only covers processes the agent starts and “should not be considered a comprehensive security solution.”
On the Claude side, read the permissions table before you install. The Claude GitHub App asks for one permission set that covers all its features, including read and write on workflows, and GitHub doesn’t let you accept only part of it. The docs suggest a custom app with just Contents, Issues and Pull requests if your org needs tighter scope.
Cost
Agent runs cost money in two places. Anthropic’s docs spell it out for its action: GitHub Actions minutes for the runner, plus API tokens for the model. Its tips carry over to any tool: write specific requests, keep instruction files short, cap turns with --max-turns, set workflow timeouts and limit parallel runs. Parallel agents feel cheap until five of them are retrying the same flaky test.
My take as a PM
I work as a PM, and my day job sits close to network detection and response, so I tend to look at any new automation and ask “what will I be able to see when it goes wrong?” That’s my lens here.
The factory idea is useful, but the word can mislead. A real factory has a line manager, quality checks at each station, and someone who stops the line. The tools above give you the conveyor belt. The stations and the stop button are still your job.
From the product side, the biggest change I notice is where the work moves. If agents write most of the code, the expensive part becomes the spec. A vague ticket used to cost a developer an afternoon of questions. Now it can cost a full agent run that confidently builds the wrong thing. Writing clear acceptance criteria is becoming the most valuable hour in my week.
I’d also resist the urge to measure success by pull requests opened. DORA’s stability finding is the warning. I’d rather track how many agent pull requests get merged without rework, and how many caused an incident later.
A small first step for your team
You don’t need a full factory to start. Here’s what I’d do this month:
- Pick one boring, well-tested repo and one type of task, like adding missing tests or small dependency bumps.
- Write the spec first. Try Spec Kit or Kiro’s requirements file on two or three tickets, even if a person still writes the code.
- Turn on one coding agent with the defaults left alone: human merge, workflow approval on, firewall on.
- Log every agent run so you can see tokens, time and which pull requests needed rework.
- Review after two weeks. Count merged-without-rework pull requests and anything that broke.
If the numbers look good, add a second station, such as agent review on every pull request. If they don’t, the problem is usually the spec or the tests, not the agent. Fix those first and then run the line again.
Leave a comment