A client asked us to put coding agents on a live product and "just let them ship." The demo was easy to imagine. Open the repo, describe the feature, come back to a pull request.
We have watched that version. The first feature lands before lunch. The second one quietly contradicts it. By the end of the week the review queue is a pile of plausible diffs, and nobody can say which session owned the decision.
That is not an agentic SDLC. That is a fast pair of hands with no floor.
We set up a software factory so the hands can stay fast and the work can still ship. The agent is a station on that floor. It is not the factory.
The factory is the part we can repeat
A factory, in the old sense, is not a building full of robots. It is a product line: the same inputs, the same stations, the same checks, so the tenth unit looks like the first. Jack Greenfield and Keith Short argued for that in 2003, schema and assets and a process, so you stop crafting every system from a blank page. They were also clear that software does not become a mechanical process. The people stay. The tools take the repeatable part. That paper is still the cleanest description of what we mean, and it predates the current agent rush by twenty years (OOPSLA 2003).
Agentic development needs the same thing, for a blunter reason. A coding agent will fill any gap you leave. If the gap is "how we structure this app," it will invent a structure. If the gap is "who may call production," it will use whatever token it can see. Speed without stations is how you get a week of output and a month of repair.
So when we say we run a software factory for an agentic SDLC, we mean a small set of stations that every agent session has to walk. Not a new brand. Not a promise that humans left the building. A floor.
What we actually put on the floor
We did not start by buying an agent platform and hoping the process would appear. We already had a delivery method for enterprise work: discovery, architecture, sprints, a change advisory board, QA before production, a pilot, hypercare. We already had BLITZ for the short path, where reusable modules and a fixed scope are the point, and an engineer still reviews.
The agentic factory sits inside that, at the coding station. Four things have to exist before we let an agent open a repo in anger.
A ruleset the agent can read. Folder layers, import direction, form and empty-state contracts, the boring decisions we do not want re-litigated every session. We wrote that down in the ruleset has to land before the AI writes the frontend. The factory version is stricter: if the ruleset is not in the repo, the session does not start. A chat is not a brief.
A map, so the agent does not rediscover the tree. Cold sessions burn the first half of their time re-learning where things live. We want a local map the agent can open, and we still want it to open the source before it edits. That argument is in stop making the agent rediscover the repo. The factory uses the map as the address book for the floor, not as a substitute for the code.
A broker, so the agent never holds the keys. The model proposes a tool call. A broker checks the agent, the session, and the argument shape, then attaches a short-lived credential. We do not paste a service account into the prompt. That is architecting agent tool access without handing over the keys. On a factory floor this is the locked cabinet. Useful work gets a key for the job. Production does not sit in the model's context.
A human who still reads the diff. This is the station people try to automate first, and the one we refuse to delete. The map does not review itself. A ruleset makes a lot of review a yes or no against a document, so the person spends time on behavior and edge cases. They still read the diff. On customer-facing agents we already sell the same instinct as approval gates, spend limits, action whitelists, and a kill switch. The coding factory gets the same shape: propose, check, then act.
Those four things have to exist before the line even starts. They are not the whole floor.
How a ticket moves
Warp's factories page draws the line the way we want it drawn. Work arrives from the place the team already tracks it, a ticket or a pull request or a scheduled chore, not from a side chat. Something can walk that ticket down the line. The line stops wherever a human has to decide. Merge stays ours. We do not need their product to run that. We do need the stops written down, in the repo, next to the code. A factory that lives only in a dashboard is someone else's factory.
The stops we actually use:
- Intake. The ask has a ticket, a bounded repo, and what is out of scope. If that is missing, we do not start a session to figure it out.
- Spec, when the change is not obvious. A short plan for how it should land. We skip it for a dependency bump or a flaky test. We do not skip it for a new flow.
- Implement. One task, one branch, tests included, a pull request. Then the session is thrown away. Memory that matters is in the repo.
- Verify. The tests we already trust, then a pass that tries to break the change. A polite self-review is not a gate.
- A named human. The spec if we asked for one, then the diff, then anything a user can see. The person who opened the session does not approve their own change.
- Monitor. What production finds comes back as a ticket. The line does not end at merge.
The floor itself is a file. Which repo, which tools, which gates, which model is allowed on which station. Changing that is a pull request, not a settings screen three people can edit without a trace.
We start on the boring path. Dependency bumps, flaky tests, the chore a senior person is tired of reading. The feature path comes after that line has survived a week without a surprise.
Quality is a station, not a mood
"The agent is careful" is not a quality system. Careful is a mood. A factory needs a reject path.
The reject path we actually use is boring, which is the point.
The ticket names the behavior. The ruleset names the shape. The agent writes the change. CI runs the tests we already trusted before the agent existed: unit, the contract tests around the API, the Playwright path if the change touches a flow a user can see. If CI is red, the station stops. We do not ask the model to "try again until it looks green" against a suite it can game by skipping the assertion.
Then a person reviews against the ruleset, not against their memory of last Tuesday's chat. Did the import direction hold. Did the empty state get handled. Did the agent invent a second way to call the same API. Those are cheap checks if the ruleset is short, and expensive archaeology if it is not.
Irreversible actions never belong to the coding agent. Merge to the default branch, a migration against production, a secret rotation, a customer email. Those wait for a named human. The same way we do not let a customer agent spend money because the prompt was confident.
We also keep the deny log. The calls the policy refused are often the interesting ones. That is how you notice a session probing for a tool it should not have, before it becomes a story in a security review.
When we change the model or the harness, we do not trust a vibe. We replay a handful of tickets we already shipped. If those get worse, the new setup does not go onto client work. That is a private scoreboard, not a leaderboard, and we do not publish someone else's cost-per-PR as if it were ours.
None of this is a new QA department. Enterprise work still gets functional, regression, performance, and security testing before production promotion, then a pilot and hypercare. The factory does not replace that gate. It stops the coding station from arriving at that gate with a novel architecture every Friday.
What we stopped doing
We stopped opening a fresh agent session on a client repo with no ruleset and no map. That session is not cheaper. It invoices you later, in review.
We stopped treating a long chat as the specification. If the decision is not in the repo, the next session will not see it, and the next person will not either.
We stopped sharing one admin token across every agent on the floor. One bad prompt then owns the tenant.
We stopped counting generated lines as progress. The factory metric we care about is simpler: did a reviewable change land, with the ruleset intact, without a human reconstructing the session from a transcript.
Reusable modules matter here more than people admit. On BLITZ we already build with modules and frameworks we have shipped before, and an engineer still owns quality. A coding agent is much more productive when the auth shell, the layout, and the error contract already exist. It is much worse when it is allowed to author those on a blank repo because the prompt said "make it production grade."
Where the factory gets in the way
A factory can become a costume for the same change advisory board. If every station is a meeting, you slowed the agents down and kept the ceremony. We only keep a station if it either rejects bad work on its own, or gives a senior person a smaller decision.
Launching more agents does not raise the merge rate. It fills the review queue. The factory's real capacity is how fast a small squad can define the job, read the trace, and approve a release. If we cannot name who drains that queue, we do not have an agentic SDLC. We have a backlog with a model attached. The person who opened the session does not approve their own diff.
We also do not pretend one floor fits every job. A four-week BLITZ MVP does not need a change advisory board in week one. An enterprise rollout with a compliance gate does. The stations that stay in both are the ruleset, the map, the broker, and the human on the diff. The surrounding process is allowed to be thicker when the blast radius is larger.
And we do not hand the factory to the model to run. Supervisor agents are useful for a narrow chore, like splitting a ticket or checking that a ruleset heading exists. They are a poor replacement for the person who knows why the last incident happened. If your factory's quality station is another agent with a prompt that says "be strict," you have built a more confident rubber stamp.
The honest limit: this setup makes a good squad faster. It does not turn a vacant repo and a vague brief into a product. The agent fills gaps. The factory's job is to leave fewer gaps worth filling badly.
The floor, before the first session
If we are putting agents on a codebase next week, this is the floor we want in place first.
- Write the ruleset in the repo. Architecture note, folder layers, the contracts review will check.
- Put a map next to it, generated from the tree, short enough to open.
- Give the agent a broker, not a key. Closed tools. No production credential in the context.
- Point CI at the tests you already trust. Red means stop.
- Name the human who reads the diff. They review against the ruleset.
- Keep merge, migration, and customer-facing sends off the agent's list.
- Check the factory definition into the repo. Gates included.
- Keep a handful of golden tickets, and re-run them when the harness changes.
- Start with a low-risk chore, not the feature the client is nervous about.
Then let the session run. The productivity is not the model. The productivity is that the tenth session looks like the first, and a small squad can still tell you what shipped.