systems

That’s why we’ve decided to approach the software factory category as infrastructure rather than as a factory product or AI teammate.

LLMs are not great at following commands. They deviate. Frequently. And they’re unreliable at self-verification—they’ll confidently tell you the code works while it’s on fire. The fix isn’t to ask the LLM to verify. It’s to ask it to write a script that verifies. Shift from judgment to artifact.

And so generating code is not necessarily the part that you need to worry about the most. Given enough context, agents can write the implementation and run the tests and inspect failure and revise code for us. We need to get to a place where we feel like there is enough of human taste encoded in the environment that we can trust what is being built, so that our human attention can be focused on the places where it’s needed most.

give Sol a grid with a "randomized" obstacle to navigate.
Tell it to use a hashmap solution for formulating pathing.
As soon as it runs into its first pathfinding problem (It will) it will start writing edge-case solutions, rather than fixing the core hashmap.

We argue that coding agents have crossed a threshold of capability at which traditional human code review is no longer a necessary component of a software quality pipeline. Our argument rests on two claims: every stated goal of code review can be served by agents at lower cost and higher throughput; the naive integration in which agents write code and humans remain the mandatory reviewers is a dead end because it neither provides meaningful assurance nor scales with AI-assisted throughput.

a cloud software factory is just an automation around the core loop of development, from triage → spec → implement → review → verify → ship → monitor, where at every step a mix of agents and humans moves the process forward.

the Unix / Linux Environment is a natural candidate, and could be turned into an Agentic harness with a few modifications.

An agent optimizing for passing tests will find ways to pass them. If the tests were written after the implementation, they are likely testing what the implementation happens to do rather than what it should do.

You cannot write a spec that survives that environment unless you deeply understand the architecture, the integration boundaries, the edge cases, the failure modes, and the invariants that must never break. The spec is not a prompt anymore. The spec is the product thinking made explicit.

Agents doing judgement-heavy work need a way to learn from the people whose judgement they are trying to approximate. 1. Principles beat rules, because rules overfit and principles transfer. 2. Agents need to learn how to learn, or feedback turns into brittle exceptions. 3. The feedback loop has to live where the team already works, or people stop participating.

The infrastructure that needs to exist to support this model at scale includes better automated regression detection, artifact-level validation that goes beyond diffing changed lines, reliable and fast environment provisioning, and guardrails that hold up under parallel workloads.

Feedback is not learning unless the agent can generalize

Agents run tools in a loop to achieve a goal

If you cannot articulate what success looks like in a way that can be evaluated, no amount of autonomous execution will produce it. Agents cannot clarify requirements they are never given. They will fill the gaps with assumptions, and those assumptions compound.

It's less about crafting individual assets and more about building systems with enough flexibility to serve a range of needs and enough structure to stay coherent at scale. Brand guidelines become agent-legible rules. A component library becomes the guardrails within which agents make decisions. An internal asset system that automatically tags images for color, text, and usage context means an agent can query for the right image rather than grabbing whatever's most recent.

Every SaaS business will become a harness around a model, whether or not they’ve realized it yet.

long-horizon agents assume requirements all exist upfront. They are fundamentally against human in the loop. And they don't have true judgment for what humans like. That—is why I don't like them.

Harrison’s 4 elements of an agent remain – the system prompt, planning tool, file system, and subgents – describing the core loop. This is the core loop the developer controls with the keyboard. The harness manages everything beyond this, the world the developer sits within.

Reacting to an event, running a sequence of isolated subagents, and separating their reasoning from the actions they’re allowed to take — it’s all just a workflow. One that could run just as well from a Slack message, a cron job, or a webhook as from a GitHub issue. Generalizing that realization into a runtime that works the same way regardless of where it’s deployed, or which model it’s driving, is what became Flue: an open, platform-agnostic framework for building durable agents and workflows.

If this continues, there’s a world where 3rd party harnesses become less valuable when used with frontier lab models because the 1st party harness behavior is already baked in. And there’s no longer a fine tuning escape hatch to generalize this behavior away.

It’s going to be funny if the network effects the AI labs have been searching for end up looking just like the network effects of the SaaS era. Coding harnesses, managing the environments around the agent, look a whole lot like the SaaS platforms of old.