Harness engineering and the path to a software factory

Harness engineering is the practice of building the feedback loops, checks, and workflows that let coding agents do more of your software delivery work with less human correction. Instead of treating agents as one-off assistants, you treat them as parts of a system that can be improved over time. Th

MMichael SwindellJuly 2, 202617 min read

Harness engineering is the practice of building the feedback loops, checks, and workflows that let coding agents do more of your software delivery work with less human correction. Instead of treating agents as one-off assistants, you treat them as parts of a system that can be improved over time. The goal is a software factory: a setup where most product output is produced by agents, while engineers focus on improving autonomy, automation, and quality. Teams moving in this direction usually need a shared control plane, durable feedback, and repeatable review loops. An agent-first platform like Levr fits that model by centralizing tasks, tests, and agent context.

At a Glance

Harness engineering turns ad hoc agent usage into an improvable delivery system.

Core idea: You improve the system around coding agents, not just individual prompts.
Three metrics: Progress depends on autonomy, automation, and quality.
Three loops: Inner, outer, and meta loops catch mistakes at different stages of delivery.
Main constraint: Trust, not raw generation speed, is usually the bottleneck.
Practical outcome: The best setups reduce backlog pressure and raise review quality over time.

What is a software factory?

A software factory is a delivery system where agents produce most of the shipped output, and engineers spend more time improving the system than hand-authoring every change. The concept is less about a dramatic switch and more about gradually delegating more work to reliable, observable agent workflows.

In this model, software teams stop thinking only in terms of individual coding sessions. They start thinking in terms of throughput, gates, feedback loops, and reusable workflows. Instead of repeatedly coaching an agent through the same task, the team codifies what good work looks like so the next run starts from a better baseline.

The important point is that a software factory is not a single product or a fixed maturity badge. It is a direction of travel. If your team already uses coding agents for simple or medium-complexity tasks, you are probably already somewhere on that path.

How do you know if your team is ready for harness engineering?

Your team is usually ready when coding agents already handle easier tasks with decent reliability, but review and trust are starting to become bottlenecks. At that point, prompt quality alone stops being enough, and the surrounding system matters more.

A few signs show up repeatedly:

You run multiple agent sessions at once.
Simple tasks are often one-shotted successfully.
Medium tasks sometimes complete with little intervention.
Engineers spend more time reviewing than writing.
The same corrections keep being repeated.

If that sounds familiar, the next step is not necessarily a bigger model or longer context window. It is better harnesses around the work. That means clearer workflows, shared checks, and durable feedback that the whole team can benefit from.

Why are autonomy, automation, and quality separate metrics?

They sound similar, but they measure different things. Autonomy is about how little correction an agent needs while working. Automation is about how much work you can let it do without human oversight. Quality is about the standard of the final product.

This distinction matters because teams often confuse a good generation with a trustworthy process. An agent might complete a task with little intervention, which suggests high autonomy, but still require a careful human review before merge, which means automation remains low.

Thinking in separate metrics helps teams diagnose the real bottleneck:

Low autonomy: The agent keeps needing nudges and corrections.
Low automation: The output might be decent, but nobody trusts it yet.
Low quality: The system ships quickly, but the product is not improving.

The sequencing usually matters too. Teams tend to improve autonomy first, then increase automation, while holding quality steady. The longer-term payoff is the chance to improve quality beyond the old human-only baseline.

What are the inner, outer, and meta loops?

These three loops describe where and how you improve agent output. The inner loop helps the agent self-correct while working. The outer loop evaluates the result at the pull request boundary. The meta loop learns from failures and updates the system so the same mistake happens only once.

This framing is useful because it turns vague agent optimization into concrete engineering work. You stop asking, How do we make the model smarter? and start asking, Which loop should catch this problem?.

How does the inner loop work?

The inner loop is everything the agent uses while actively building a change. These are fast checks and resources that help it steer itself before a PR is opened.

Examples include:

Test suites the agent can run quickly
Skills or playbooks for common workflows
Plugins and tools used during implementation
Repo-specific guidance checked into version control

The stronger the inner loop, the more likely the agent lands near the right solution without needing a human to intervene.

How does the outer loop work?

The outer loop runs at the PR boundary. These checks are slower or more expensive, so they do not belong inside the agent’s constant iteration cycle.

This is where teams put:

Deeper code review
QA-oriented agent checks
Verification steps that replace manual inspection
Final safety gates in CI

In practice, this is where trust is built. The outer loop should reduce the need to read every line manually or run ad hoc validation on a local machine.

How does the meta loop work?

The meta loop sits outside both of the others and watches how the whole system behaves over time. It looks at review comments, failed checks, repeated mistakes, and human interventions, then proposes changes to the inner or outer loop.

The ideal outcome is simple: if the team teaches the system something once, that lesson becomes reusable. Repeated human correction is a sign that the meta loop is still weak.

Why does code review become the new bottleneck?

As agents get better at producing code, the limiting factor shifts from generation to verification. Teams stop struggling to get a decent PR and start struggling to review a growing number of acceptable PRs consistently and fast enough.

This pattern shows up naturally. Once an agent can work for 30 or 40 minutes and produce something mostly right, the question is no longer “Can it code?” It becomes “Can the team trust, validate, and merge this without drowning in review work?”

That is why outer-loop design matters so much. Strong review systems should remove low-value review effort first. They should catch common readability, security, reuse, and policy issues automatically, leaving humans to review architecture, product intent, and judgment-heavy tradeoffs.

This maps closely to what agent-first control planes try to centralize. In Levr’s workflow model, intent, task pickup, automated verification, and final human approval are separate steps. That structure gives agents room to work while preserving clear gates.

Make agent output easier to trust

A shared control plane gives your team one place for issues, tests, reviews, and agent context, so verification does not depend on scattered prompts and local sessions.

See how teams structure agent workflows

How do verifiers differ from general agentic code review?

General agentic review catches broad classes of issues across a diff, while verifiers enforce narrow, recurring invariants with higher reliability. Both matter, but they solve different problems at different levels of specificity.

A broad review layer is useful for finding issues you did not explicitly predict. It can flag problems such as poor readability, missed reuse opportunities, or obvious security concerns. That gives you flexible coverage across many categories.

But broad review alone has limits. Once your team accumulates a long list of things that must always be true, a single review prompt becomes bloated and less reliable. That is where targeted verifiers help.

Good verifier candidates are small, black-and-white checks such as:

Every front-end element must include ARIA attributes
Logging must use the approved internal logger
Specific design tokens must be used instead of ad hoc values
Certain file patterns must respect defined conventions

Because these checks are narrow and scoped, they can run in parallel and with high confidence. The bigger lesson is that recurring review comments should usually become machine-enforced rules rather than permanent human chores.

Why is durable feedback more important than interactive sessions?

Interactive sessions are useful early on, but they hide too much context and too much learning in temporary places. Durable feedback matters because the meta loop can only improve what it can observe, store, and reuse.

When work starts from a tracked issue, results in a PR, and receives feedback in visible systems, the team gets a durable ledger of intent, output, and correction. That makes repeated problems easier to detect and easier to turn into shared improvements.

This is also why local-only configuration tends to hurt compounding gains. If a useful improvement lives only in one engineer’s setup, the team does not benefit from it. Shared repo-level configuration and reusable workflows create a compounding effect because every improvement applies to the next run for everyone.

That principle aligns well with a shared platform model. One way teams handle this in Levr’s feature set is by keeping projects, issues, test management, and observability inside one control plane instead of scattering state across personal sessions.

Why is harness engineering hard in practice?

Harness engineering is difficult because it combines fast-moving technical change, unplanned improvement work, and missing operational visibility. The challenge is not just knowing what to build. It is creating enough time, data, and discipline to keep improving the agent system while still shipping product.

Three recurring problems show up.

1. The discipline changes quickly

Practices evolve fast. Teams can spend a lot of time chasing the latest approach, only to see it become outdated shortly after. That makes it harder to standardize and harder to justify long design cycles.

2. Improvement work competes with feature work

Most of the best harness improvements are discovered during normal delivery. That means the work is inherently unplanned. If the team does not make space for it, the same mistakes repeat and the system plateaus.

3. The feedback is often trapped in the wrong places

If corrections live in chat histories, local environments, or individual memory, the team cannot learn from them systematically. The meta loop depends on accessible, legible feedback.

This is one reason industry tooling is shifting toward observable, workflow-based systems. The GitHub Octoverse 2024 highlights how deeply AI-assisted development has entered mainstream software workflows, and the Stack Overflow Developer Survey 2024 shows strong usage alongside concerns about trust and correctness. Those concerns are exactly where harness engineering earns its keep.

How should teams adopt a software factory without breaking delivery?

The safest path is incremental. Teams that treat the shift as a giant one-time transformation usually stall, while teams that automate one workflow at a time build momentum without forcing premature standardization.

A practical rollout usually looks like this:

Pick a narrow, repeatable workflow. Start with something the team already agrees on.
Codify it as a shared skill or playbook. Keep it in version control.
Route work through durable systems. Use issues, PRs, and CI instead of local-only flows.
Add targeted review and verification. Remove the most repetitive review work first.
Watch for repeated failures. Feed them back into the system.
Expand only after the workflow sticks. Layer on additional automation gradually.

This incremental pattern also reduces organizational friction. It is easier to get buy-in for one clearly useful workflow than for a top-down rewrite of the entire software delivery lifecycle.

How do you give coding agents a real project control plane?

Coding agents work better when they inherit structured project context, clear acceptance criteria, and automated gates instead of a prompt alone. A real control plane separates intent, execution, verification, and approval so the system can improve over time.

One way to handle this in practice is to adopt the same four-step pattern that strong agent workflows use:

Define intent in natural language. Capture the work as issues, scope, and test criteria.
Let agents pick up scoped tasks. The agent works from shared context, not a blank prompt.
Run automated verification. Tests and review checks validate the result.
Require human review and approval. A human handles final judgment, not mechanical checking.

Levr’s workflow approach is designed around that exact separation. For teams using Claude Code, Cursor, Codex, or Copilot, that matters because the control plane becomes the persistent source of truth rather than each session becoming its own fragile universe.

When multi-agent coordination becomes part of the picture, the infrastructure layer matters too. Qinetic is relevant here because it focuses on agent message bus behavior, shared memory, and intelligent routing, which are the kinds of capabilities that help a factory operate as a system rather than as isolated runs.

Technical Deep Dive FAQ

What is harness engineering in software development?

Harness engineering is the practice of building the workflows, checks, and feedback systems around coding agents so they can produce useful work more reliably. Instead of focusing only on prompts, you focus on the mechanisms that shape, validate, and improve agent behavior over time. That usually includes fast inner-loop checks, slower PR-boundary gates, and a meta loop that learns from repeated failures and turns them into reusable rules or workflows.

What is a software factory for coding agents?

A software factory is a setup where most user-facing software output is produced by agents, while engineers spend more of their time improving the system that produces that output. It is not a binary state or a single tool. It is a gradual move toward higher autonomy, higher automation, and eventually higher quality. Teams usually get there by standardizing workflows, making feedback durable, and turning repeated corrections into codified checks and playbooks.

What is the difference between autonomy and automation?

Autonomy measures how often an agent can reach the right answer without human correction during the work itself. Automation measures how much of that work you are willing to let proceed without human oversight. An agent can be autonomous enough to produce a good-looking PR, but if nobody trusts it, automation is still low. That distinction helps teams see whether they need better generation quality, better verification, or simply more operational confidence.

Why does code review become a bottleneck with coding agents?

Once agents start producing acceptable pull requests consistently, review volume rises faster than human review capacity. The team stops spending most of its time writing code and starts spending more time checking code. Without structured outer-loop review, the human reviewer becomes the slowest part of the system. That is why agentic review, targeted verifiers, and CI-boundary checks matter. They remove repetitive inspection work so humans can focus on architectural and product-level decisions.

What belongs in the inner loop versus the outer loop?

The inner loop should contain fast, cheap, frequently run checks that help the agent self-correct while implementing. That includes local tests, repo skills, and lightweight guidance. The outer loop should contain slower or more expensive checks that make sense at the pull request boundary, such as deeper review, QA-oriented validation, or final verification gates. If a check is too slow for repeated iteration but valuable for trust, it probably belongs in the outer loop.

What makes a good verifier for agent-written code?

A good verifier enforces a narrow, high-value rule that should always be true and can be checked in a black-and-white way. Examples include accessibility requirements, approved logging patterns, or design system conventions. Verifiers work best when scoped to relevant file patterns and phrased as small invariant checks rather than broad review prompts. The goal is not to replace general review, but to prevent known mistakes from recurring after the team has already paid the cost of finding them once.

Why should teams avoid local-only agent configuration?

Local-only configuration prevents improvements from compounding across the team. If one engineer discovers a better workflow, test setup, or skill but keeps it in a personal environment, everyone else repeats the old mistakes. Shared repo-level configuration creates a force multiplier because the next agent run starts with better defaults for everyone. That is especially important when building toward a software factory, where consistency and repeatability matter more than individual optimization on a single workstation.

How do you decide when to automate a workflow?

If a workflow is repeated often, follows a recognizable pattern, and already works reasonably well with a coding agent, it is usually a good automation candidate. The best early targets are narrow tasks with low ambiguity and clear outputs. Avoid trying to automate the entire development process at once. A better approach is to automate one durable workflow, route it through issues and PRs, observe the failure modes, and only then expand. This keeps risk contained while building team trust.

What should a control plane for coding agents include?

A useful control plane should include durable task definitions, shared context, verification gates, and observable execution history. In practical terms, that often means issues, PR hooks, test management, and a record of how feedback was applied. The value is not just coordination. It is that the system becomes inspectable and improvable. Teams using agent-first platforms typically want the control plane to cover both human and agent contributors, so all work happens against the same operational context.

Can a software factory improve code quality, not just speed?

Yes, that is one of the stronger long-term arguments for the model. Early on, teams may accept roughly constant quality while gaining speed, but once agents can fix every issue they detect, backlog pressure changes. Repetitive correctness, cleanup, consistency, accessibility, and verification tasks become cheaper to address. A human team often ignores those improvements because capacity is limited. An agent system with strong loops can apply them more consistently, which creates a plausible path to higher quality over time.

How does Qinetic fit into multi-agent software delivery?

When teams move beyond isolated coding sessions and start coordinating multiple agents, infrastructure becomes part of the problem. Qinetic is relevant because it focuses on the shared systems that agent networks need, including a message bus, shared memory, and intelligent routing. Those capabilities matter when work is no longer just one agent producing one patch, but a set of specialized agents handling planning, execution, review, and verification across longer-running workflows.

Do you need a fully automated setup to benefit from harness engineering?

No. In fact, most teams benefit long before they reach full automation. Harness engineering starts paying off as soon as repeated corrections become shared improvements. Even if humans still review every PR, better inner loops, targeted verifiers, and durable workflow feedback reduce waste and increase consistency. The point is not to force a fully automated system on day one. It is to create a structure where each improvement compounds instead of disappearing after a single agent session.

Key Takeaways

Software factories are less about replacing engineers and more about shifting engineering effort toward system design, trust, and quality control.

The transition works best when teams improve one loop at a time.

Start point: Begin when agents already handle easy and medium tasks reasonably well.
Main bottleneck: Review and trust usually become harder than generation.
Best lever: Turn repeated human corrections into shared checks, skills, and verifiers.
Operational need: Use a control plane with durable feedback, not isolated local sessions.

The teams that compound fastest are the ones that stop solving the same agent mistake twice.