Most teams adopting coding agents have spent the last year asking how to get an agent to produce a good change. A harder question is arriving fast: what happens to a codebase when agents produce thousands of changes and nobody reads most of them? Agent feedback loops are emerging as one of the more convincing answers.

Maria Gorinova, a member of technical staff at Tessl, returned to The AI Native Dev to unpack how Tessl's internal "dark factory" uses feedback loops to keep itself healthy. In conversation with host Simon Maple, she moved from how an agent writes code to how a whole system of agents maintains itself.

What a Software Factory Actually Is

When Gorinova asked a room of engineers to define a software factory, she got a different answer from almost everyone. Her own definition is compact: a software factory is a system with repeatable workflows, a shared execution environment, and feedback loops.

The third element is the one most definitions skip, and it appears to be the one that matters most once humans step back. "We are supervising the tasks that go into the agent sometimes, but we don't really supervise the code," she explained. Without something watching the output, she noted, things deteriorate quickly.

That framing also clarifies a common confusion. Ticket-to-PR automation, where an issue is filed and a pull request appears, is often treated as the factory itself. Gorinova described it instead as one workflow running inside the factory. The bigger opportunity is maintenance: agents churning through data to suggest and implement improvements without a human reviewing each one.

From Agent to Context to Harness Engineering

It can be helpful to read the evolution of coding agents as three stages. The first was a bare agent: a closed-source tool driven only by prompts, with little control over its behavior. Since every codebase and team differs, prompts alone rarely produce compliant, high-quality behavior.

The second stage added context: CLAUDE.md and AGENTS.md files, then skills and hooks. This gave teams real, shareable control over how an agent operates in a repo. But Gorinova pointed to a gap that many teams will recognize. There is no principled way to answer "is my CLAUDE.md good?" other than vibes, and improving it usually means asking an agent to "vibe something into it based on more vibes."

The third stage is where harness engineering comes in. In this view, a harness is the agent, its context, and a feedback loop that measures and improves both.

The Three Stages of an Agent Feedback Loop

So what is an agent feedback loop? In Gorinova's framing, it is an agentic workflow with three distinct stages: analyze a data stream, identify problems or inefficiencies within it, and request a fix. The fix might be a code change, a refactor, a bug fix, or an improvement to the context itself.

The data stream can be almost anything. It might be PR review comments, where the same feedback appears again and again because an agent keeps missing a repo convention. It might be agent session logs. In Tessl's own factory, agents analyzing their own session logs spotted friction, such as many turns lost figuring out a tool, and added context so future agents avoid it. Gorinova was candid that this wasn't predicted; it made sense only in hindsight. The practical lesson is to experiment with multiple data sources rather than expecting to know in advance which will pay off.

Inner, Middle and Outer Loops

Tessl loosely groups its loops by scope, and the taxonomy is a useful mental model for anyone designing their own.

Inner loops operate on a single change. Verifiers are the clearest example: a set of criteria a change must meet, checked by an LLM-as-a-judge on every PR during CI. Gorinova framed verifiers as an addition to code review, closer to linting for rules that are hard to express as tests, and far cheaper and more tightly scoped than open-ended review.

Middle loops look across many changes, such as many PRs or many agent sessions, so the agent can generalize. These typically run on a schedule, from daily to monthly.

Outer loops respond to production signals. A service failing can trigger a loop that detects the error and self-heals. A drop in daily active users can trigger an investigation.

The distinction between inner and middle loops becomes sharper when Gorinova introduced drift. She used the rule of three: write code once, write it twice, and on the third time introduce an abstraction. Agents will repeat code just as humans do, "but that's not the job of the agent writing the third time code." Recognizing the pattern needs something with the bigger picture, which is exactly what a middle loop provides.

Why Vague Intent Breaks Feedback Loops

Asked where first attempts go wrong, Gorinova was clear: intent. Be explicit about the data source, what the agent should look for in it, and what it should improve. Asking an agent to look at past PRs and improve the repo isn't clear intent. It produces something like a god loop that tries to fix everything and ends up shallow, surfacing things that may be true but aren't important.

Her counterexample is deliberately narrow. Tessl runs a middle loop called the comment diet, born from the observation that agents "tend to become crazy with comments," and that comments grew longer over time because each new agent saw long comments and assumed it should write them too. The loop counts comment lines against code, flags the worst files and trims them, without touching architecture or logic. Inner-loop gates help, but Gorinova suspects drift like this will reappear over time regardless, which is why the scheduled audit matters.

The Human Role in a Software Factory

A common worry about this level of automation is that it removes people. Gorinova's view suggests the opposite. Humans are involved constantly, analyzing what's happening, requesting the right changes, monitoring loops and inventing better metrics. There is even a meta feedback loop that evaluates whether other loops are working. "I don't think the factory is something that can just be built and done."

Internally, Tessl describes two personas. The dark factory operator keeps the main loops running and the factory available to everyone. Stewards own particular areas, projects or repos. Gorinova described the steward as something like the new code owner, with one twist: they didn't write the code. Each repo can share common orchestration while defining its own feedback loops.

Underneath all of this sits a mindset shift. The factory is not a black box you get angry at when it fails. Your code, your context and your data are part of it. A well-structured, context-rich project gets better results from the same agent than semantically identical spaghetti code.

For teams ready to build a first loop, Gorinova's advice is to start where agents trip up most, be precise about the data source and the signals in it, and decide in advance what you want improved. It's a fascinating conversation, and worth a listen for anyone moving from prompting agents to running them at scale. Which feedback loop would you build first?