Harnesses, Loops and Factories

At first, the teams we work with asked Claude or Copilot to fix a small bug or write a test. Then they gave agents tools to debug production systems, so the agent could track down the cause of a failure and propose the fix itself. Now some of them leave an agent working towards a goal for several hours before anyone looks at the result. We've watched teams and customers make that whole journey, and the next step is to scale it up. At that point the team's job changes. It becomes responsible for designing the system of work that agents operate within, and the guard rails around it.

The harness

An agent is a model plus the harness around it. The harness is everything built so the model can act on its own: the tools it can call, the context it is given about the codebase and the task, and the limits on what it may touch. The first coding assistants had none of this. They saw the file you had open and could offer the next few lines. Claude Code, Copilot's agent mode and Cursor give the model a terminal, the test suite, the logs and a set of permission rules, so it can make a change, run it and see whether it worked.

The harness is also where most of a team's effort goes. In practice the hard decisions were about what the agent could see, what it was allowed to change and when it had to hand back to a person. That work keeps its value as models change, because the tools, context and permissions carry over to the next one.

Loops

A loop is the agent going round the cycle of change, run and check until something tells it to stop. Anthropic's Claude Code team set out four kinds of loop:

• Turn-based hands over the check. This is the familiar back and forth of a chat: the agent checks its own work and then stops for your next instruction.

• Goal-based hands over the stop condition. You set the finish line (e.g. every test passing) and the agent keeps going until it gets there or runs out of turns.

• Time-based hands over the trigger. The agent runs on a schedule, and Anthropic's example is checking a pull request every five minutes to address new review comments and fix whatever is failing in CI.

• Proactive hands over the prompt itself. Schedules, goals, skills and pre-approved permissions combine so the agent picks up well-defined work like incoming bug reports or a long migration without anyone asking each time.

Most teams we work with are somewhere around goal-based loops, with agents working towards a finish line for hours at a time and a person checking the result and managing state via markdown files. This works to a degree for an individual but doesn’t scale for teams. 

Factories

The emerging term for the next step is a software factory: many loops running at once across the backlog with work arriving from Jira/Linear, bug reports, production events and failed deployments. Personally, I don't like that term as a factory suggests a production line where people have been automated away and software delivery that runs from start to finish with nobody involved. My view is that we can scale loops to deliver software more effectively, guided by human expertise but not replacing it.

I like to think of this as scaling loops or loop engineering for teams. Today it is mostly individual engineers designing loops for their own work. Scaling up means the team designs them together, deciding which work goes to agents, what each one can see and change and where a person reviews the result. Those decisions add up to a system of work with guard rails around it curated by the people who know the codebase and the business.

When we build this with customers each agent gets just enough autonomy and context to complete its task then hands the result back to a person for review. Everything it does is traceable and guard rails limit what it can touch. Addy Osmani describes the alternative as a dark factory where code ships that no human has read.

For heavily regulated businesses a dark factory isn't an option because someone has to stay accountable for every change. Loop engineering for teams keeps that person in place. The review points stay where an auditor expects a person to sign off and the record of what each agent did and why is the same evidence a regulator asks for. In a bank or an insurer, the guard rails are what make loops usable at all.

Beyond the factory

Anthropic recently published an article When AI Builds Itself which states that as of May 2026 more than 80% of the code merged into its codebase was written by Claude. The length of task its models can reliably complete on their own has been doubling roughly every four months. Followed far enough the trend leads to recursive self-improvement where AI systems design and refine their own successors.

Anthropic is also clear about what is still missing. Claude can match or beat skilled researchers at running a well-specified experiment, but "large performance gaps persist when it comes to Claude exercising judgement in choosing goals". The article describes the current arrangement inside Anthropic as "humans have ideas, and the models are able to implement, test and evaluate them an order of magnitude faster than before."

Applied literally to software, self-improvement is the dark factory: a system that ships and improves itself with nobody reviewing it. The version worth building is loops that improve the loops. Each task teaches the agents something and they propose changes to the team's skills, tests and harness, with people deciding which ones stick.

I find that prospect exciting because small teams can have a much bigger impact than ever before. It is also slightly terrifying if a team doesn't maintain engineering discipline, put the right guard rails in place or understand what their system does.

What this means for our industry

I think the shift moves human expertise to the most important work. Agents are doing more and more of the heavy lifting and people spend more of their time deciding what is worth building, designing the loops that build it and judging what comes back.

The best way to start building your own loops is with one kind of work your team already handles by hand. Generating a fix for a crash/incident in a production app is a good first candidate. Today someone gets alerted, reads the stack trace, finds the change that caused it and writes a fix. An agent can do the initial triage and first pass of implementation then raise a pull request so the engineer on call reviews a fix with the investigation already done and plenty of data to make an informed decision.

Building that one loop forces the decisions every later loop will need: what the agent can see, what it can change and where a person signs off. Once that works, add failed deployments then the bug backlog before starting to tackle larger items like breaking down work or building a first pass implementation of a task/story. Layer multi-agent adverserial review on top of this and you have the first iteration of our own factory tailored to your team or product.