Every Fast Team Is Building a Different Software Factory
Resourceful founders and enterprises are inventing the same story-to-ship loop under different names, each shaping it around their customers, strengths, and ambitions.
I have been talking with founders and operators I admire, many of them close friends. They have already done the hard, unglamorous work of getting from zero to one: finding customers, earning revenue, and staying in the game long enough to learn what people will pay for. For years, their next move was often blocked by an engineering queue, a hiring freeze, or simply the limits of a small team.
AI has eased that bottleneck.
What I find exciting is how quickly they acted. They did not wait for a settled category or a perfect tool. They wrote down the intent, put cloud agents to work, and learned by shipping. Now pull requests open in parallel. A demo can branch for several customers. Features that once waited in a queue can move together. Review, test, merge, repeat. Some of these teams are moving dozens of PRs in a week. A few are exploring what it would take to move hundreds. The point is not the volume. The point is the new leverage: the work can move like a factory even when the company is two people.
They do not share a name for what they are building, and I like that. One calls it a factory. Another calls it a copilot for AI. A third calls it a harness. Someone else says agent pipeline. Enterprises I consult with are wiring the same loop into their SDLC and calling it story-to-PR. Each name reflects a slightly different path into the same new territory.
This is not a playbook. It is an appreciation of the people finding their own way through a new kind of company building. The industry is converging on one loop, task in and shipped feature out, while inventive teams stretch that loop into wildly different shapes. Each version teaches the rest of us something.
The same loop, different names
In software-engineering research, a harness is the scaffolding around the model: the sandbox, the tests, the pull-request loop that decides whether a patch actually works. SWE-bench, the best-known test of whether an agent can fix a real GitHub issue, is famous for its evaluation harness. Product teams borrowed the word because the insight is right. The model is interchangeable. The harness is what you trust when you are not reading every line.
I wrote about the technical version of that idea in The Harness Is the Product. This essay is the field version. It is what that system looks like when founders, operators, and enterprises invent it independently, under different names, around the opportunities directly in front of them.
Factory.ai’s software factory is the same idea stretched across the whole lifecycle: intake, plan, build, validate, ship, monitor. Cursor’s cloud agents made the parallel version obvious: isolated VMs, many PRs at once, screenshots and recordings attached as proof. Faire described doubling weekly PR throughput by running that fleet.
Different labels. Same promise. Write down what you want built. The agent builds it, tests it, and pushes toward production. You review the evidence, guide the product, and keep moving.
From intent to shipped feature
The people building these systems come from different backgrounds. Some are technical founders who used to write the code. Some are operators who never did. Both are product people now. Both need the pipeline to think in layers, because they will not stare at every diff.
That is the quiet shift. The audience is not just “engineers who like agents.” It is anyone with enough customer knowledge to know what should exist next. A founder closing a deal. An operator customizing a demo. A small team shipping the thing the last sales call made obvious. Their closeness to the customer has become executable. They can turn what they heard this morning into something a customer can use this week.
The loop they keep reinventing is more than prompt, code, ship. In practice, it looks closer to this:
- Intent and context. A founder or operator describes the customer need, the outcome they want, and what “done” should feel like. The harness brings in the relevant code, product rules, prior decisions, design references, and constraints so the agent does not have to rediscover the company every time it starts a task.
- Architecture. A high-intelligence model plans the change: boundaries, data flow, dependencies, edge cases, and what must not break.
- Break down and implement. The plan becomes a set of bounded tasks that can run independently. Faster models write the code in isolated branches or environments, each with a clear assignment and definition of done. This is where one feature turns into several safe streams of parallel work.
- Extensive testing. The harness runs unit tests, edge cases, regression suites, and behavioral checks, then produces evidence: logs, screenshots, recordings, or a working preview. A passing build is useful; proof that the customer request works is better.
- Review. Another capable model, a human, or both compare the result with the original intent and the architecture. Anything unclear goes back through the loop with more context.
- Ship and learn. The approved change is merged and released. What happens in production—and what the customer says next—becomes context for the next run.
That sequence is not a maturity model. It is a division of labor. Intent and context need customer knowledge. Architecture needs judgment. Breaking down and implementing the work creates speed and parallelism. Extensive testing and review create confidence. Shipping creates the next round of learning. The teams doing this well are discovering where human attention creates the most value, then building the rest of the system around it.
If you have already moved from copilot to agent, this is the next layer: not a better prompt, a bounded handoff. From Copilot to Agentic Engineer is the individual version. The factory is what happens when that handoff becomes a system.
Testing is the non-negotiable gate
Every harness I saw treats testing as a hard gate. That discipline is what makes the new speed useful.
That is the one axis that does not compress. Teams may use a less expensive execution model. They may start without a polished UI or deep observability. They still will not merge untested agent code. If you are not looking at every line, the tests become another way of looking: unit tests, edge cases, regression suites, and the flows that broke last week.
Some teams will not merge until each node in the pipeline reports confidence at 95% or better. That is not a vibe. That is the substitute for reading the patch.
This is why the mixed audience matters. A technical founder can still open the diff when something feels wrong. A non-technical operator may navigate through product behavior and test evidence instead. Both still own the customer. So the factory has to make good engineering judgment visible: architecture stated clearly, edge cases enumerated, regressions replayed. The people who used to wait on engineering are not looking for a shortcut around quality. They are building a way to carry quality with them as they move faster.
SWE-bench measures whether a patch passes repository tests. It does not measure taste, deal-closing UX, or whether tomorrow’s customer demo still works. Teams that care about product are adding those evals themselves. Verification Is the Real Agent Loop is the practical stack: cheap deterministic checks first, behavioral tests next, human judgment last.
The gate is not “tests exist.” The gate is “the requested behavior was proved.”
Model routing without cheapening the plan
Nobody I spoke with wants to compromise on the plan. They will pay for the model that can hold the architecture. What they will not do is run that model for every file edit.
Model routing, sending each step to a different model, is the practical compromise. Plan on a high-intelligence model. Execute on a fast one. Review on whatever currently wins the relevant benchmark. Some watch SWE-bench for code. Others watch product-style evals for UX and judgment.
Cost is the other split. A few teams are taking their time. They expect a cheaper frontier model to arrive and are designing for that curve. Most are routing today. They keep the expensive model on the architecture step, the review step, and the ambiguous cases. They send the bulk of implementation to a faster model. They treat routing as a product policy, not as a discount code.
That is the same argument as Model Routing Is a Product Policy, except the operators I am watching already do it by hand. Research on agentic routers, systems that pick a model per task and learn from outcomes, is catching up to the spreadsheet version.
The interesting part is how consistently they protect the plan. Token matching is real. Waiting for the next model is real. Neither group is willing to let speed alone determine the architecture. They spend for judgment, save on repetition, and keep adjusting the balance as the models improve.
Node graphs and the agent control plane
The other split is interface.
Some people want a node graph: a what-you-see-is-what-you-get canvas where Plan, Implement, Test, Review, and Deploy are boxes you connect. Run the flow. Watch confidence on each node. Ship when the graph is green.
That instinct is not decoration. If you are not reading code, you need to see the path. A canvas of nodes is a way to inspect the factory without inspecting the diff. Each node is a stage with a contract. Each contract has a confidence number. 95% is the number I keep hearing. Below that, the feature does not ship.
That is the same instinct as a control plane: policies, usage, observability, and guardrails sitting above the agents that write the code. I have been building in that direction, including the PylonAI control-plane work. So has almost everyone else, except each version is private and tuned to what that team values most.
One team wants to know what agents exist and what they are allowed to touch. Another wants traces: which run failed, where the tokens went, why the review node dropped to 70%. Another wants permissions tight enough that a runaway agent cannot open the network or touch prod. How to Know When a Coding Agent Has Gone Rogue and Permissions Are Part of Agent Architecture go deeper on those parts of the system.
Enterprises are not doing something entirely different. They are adapting the same loop to a larger organization. Story in. Agent out. PR reviewed. Tests green. Change-management requirements met. The SDLC already had stages. The opportunity is to put models inside those stages while preserving the trust the organization has built around them.
The radar chart of AI delivery
If you have played games with character stat screens, you already know the picture. Strength shoots far out on one spoke. Speed stays short on another. The official name is a radar chart, also called a spider chart or web chart: axes around a center, a polygon for the profile.
That is how these harnesses look when you talk to enough people: not as better and worse versions of one product, but as distinct profiles shaped by real customers and real companies.
| Axis | What they stretch |
|---|---|
| Testing | The shared outer ring. No merge without it. |
| Cost | Token routing, cheaper execution models, or waiting for the next frontier drop. |
| Model routing | Right model per step, not one model for all. |
| Guardrails | Policy, permissions, what agents may not do. |
| Observability | Traces, spend, which run failed and why. |
| Taste | UX, architecture quality, whether the feature delights. |
One team’s polygon is long on testing, guardrails, and observability. Another is long on cost and routing. A third is long on taste: they will spend tokens to get the interaction right, because the demo is the sale. Enterprises running story-to-PR programs have the same spider, just more compliance on the guardrails spoke.
Resilience sits inside that chart even when nobody labels it. Some teams optimize for the agent that recovers. Some optimize for the agent that rarely needs to recover because the permission envelope is tight. Both are stretching a spoke. They are solving the problem in their own way.
There is no cookie-cutter approach, and that is a strength. There is a shared loop, stretched into different shapes, all pointed at the same outcome: close the deal, ship the demo, delight the customer, and turn a small team’s conviction into something real.
Why everyone is building their own
I used to think the missing product was a standard harness. Talk to enough people and a more interesting possibility appears: the shared loop may become standard, while the advantage comes from how each team shapes it.
A two-person company closing custom demos is not trying to solve enterprise audit. An enterprise with a story-to-PR program is not trying to maximize demo velocity. A founder who can still read code may not need a rich visual canvas. An operator who works through product behavior probably does. One team puts its energy into lowering token costs. Another invests in safer merges. Another obsesses over the UX because the demo is where the product earns belief.
Each of those priorities becomes a spoke. The factory gets built around the strengths the team needs next.
That is why the names keep multiplying. Factory, copilot, harness, agent pipeline, story-to-PR: they are all trying to name the loop. The radar chart is trying to name the difference.
If you are designing one of these, the useful question is not only “which vendor has the harness?” It is “where can our version become distinctly good?” Testing should already be at the outer ring. Everything else is a choice, and those choices can become part of how the company builds.
An observation, not a playbook
That is all this is: a snapshot of founders, small teams, and large enterprises independently inventing the same factory under a dozen names. The radar chart is one way to see what each of them is contributing.
I am not arguing that one polygon is correct. I am arguing that the polygons are now the product. The model will change again. The loop will endure: intent in, tests in the middle, a shipped feature out.
What makes me optimistic is not merely that AI can write more code. It is watching people who fought their way from zero to one gain a new kind of agency. They know their customers. They have taste, urgency, and hard-won context. Now they can turn more of that knowledge into working software, without waiting for their team to become ten times larger.
My friends are not following a finished playbook. They are writing parts of it through action. One harness at a time, each in their own way, they are showing what a small, determined team can build when its ambition is no longer pinned to the size of its engineering queue. It feels like the beginning of a much more creative era of company building.