For the past few months, it has felt like every week introduced a new way of coding with AI. Developers switched between Claude and Codex, experimented with different prompting techniques, and gradually delegated larger parts of their workflows to models.

AI is moving from a tool engineers use to write software toward a system that can actively maintain it.

The capabilities are already here. What's lagging behind is how companies are adapting to them.

Imagine a production application that detects its own bugs, investigates them, implements fixes, validates those fixes, and prepares pull requests for human approval — without an engineer initiating each step.

The individual capabilities already exist in various forms. The interesting challenge is how we connect them into a reliable system.

To understand how, we need to start with loops.

Loops: Giving Agents Continuous Objectives

Most developers interact with AI agents through individual tasks: ask an agent to implement something, review the result, and move on.

But one of the more powerful ways to use agents is to place them inside a loop.

A loop repeatedly executes a workflow until a stopping condition is reached or the next scheduled execution arrives.

The important part is having a clear, measurable objective. Without one, an agent can continue making changes without knowing whether it's improving anything.

There are two particularly useful types of loops.

Goal-bound loops

These execute until an objective is satisfied, a resource limit is reached, or the system determines it cannot make further progress.

For example, suppose you're developing a more efficient data format.

Instead of manually experimenting with different representations, you could give an agent a benchmark and an objective:

Reduce the serialized data size by at least 50% while preserving all required information.

The agent can propose a format, implement it, benchmark the result, inspect the metrics, and repeat.

Each iteration has measurable feedback that informs the next.

Goal-bound agent loop: make a change, then measure the metric. Check whether the output meets the goal; if not, repeat the loop. If the goal is met, the workflow is done. Example current metric: 0.42; goal metric: 0.90.

Periodic loops

Other workflows don't have a final objective. They need to keep operating.

Consider monitoring production logs.

An agent could run every hour, inspect new error events, identify potentially actionable regressions, and create maintenance jobs.

The monitoring loop doesn't need to fix anything itself. Its responsibility is simply to identify problems and ensure they are recorded.

Production logs feed an hourly monitoring loop, which creates a pending maintenance job for a POST /checkout 500 error. The job records its ID, error, status, and time found.

This distinction is important: agents work better when their responsibilities are narrowly defined.

But loops introduce another problem.

What happens when a job fails halfway through? What if multiple problems are detected at once? Who validates the work, and who decides what happens next?

A single loop isn't enough to coordinate all of that.

Graphs: Coordinating Multiple Loops

A more complete maintenance system can be constructed as a graph of interconnected workflows.

Each workflow has an isolated responsibility, and they communicate through persistent state.

Let's walk through one example.

Step 1: The monitoring loop detects an issue

Suppose a production API begins returning HTTP 500 responses for a particular endpoint.

The monitoring loop inspects recent logs, identifies the recurring error, and creates a maintenance job.

That job might look like this:

{
  "id": "JOB-1042",
  "error": "POST /checkout returns 500",
  "status": "pending",
  "implementation_model": null,
  "time_found": "2026-10-31T14:30:00Z"
}

This record represents durable state.

Rather than relying on an agent's conversation history to remember what needs to happen, the system records the work in a persistent store.

If an agent crashes or a process restarts, the job still exists and can be resumed or reassigned.

Step 2: The implementation loop picks up the job

The implementation loop looks for pending jobs and delegates them to agents.

Each agent operates independently in an isolated development environment.

For our checkout error, the implementation agent would:

  1. Retrieve the job and relevant logs.
  2. Clone the repository into a sandbox.
  3. Reproduce the error.
  4. Investigate the root cause.
  5. Implement a fix.
  6. Run the relevant tests.
  7. Submit the proposed change and supporting evidence for evaluation.

The job also records which model performed the implementation.

Multiple jobs can run concurrently without requiring a single agent to manage the entire workload.

Step 3: The evaluation loop validates the fix

An implementation that compiles or passes a few tests isn't necessarily correct.

That's why evaluation should be a separate responsibility.

The evaluation loop picks up completed implementations and assigns them to an independent evaluator.

When using LLMs as judges, it's important to understand their evaluation biases, including position bias, verbosity bias, and self-enhancement bias.

One way to reduce the risk of self-enhancement and correlated judgment biases is to use a different model family for evaluation than for implementation. This doesn't eliminate bias, but it introduces another degree of independence.

The evaluator reviews the proposed code changes and supporting evidence, runs relevant tests, and checks whether the fix addresses the reported issue without introducing regressions. Its assessment should be grounded in test results and observable behavior rather than the model's judgment alone.

If the fix fails evaluation, the results are attached to the job and returned to the implementation workflow for another iteration.

If it passes, the change moves forward to human review.

Step 4: Human approval requires product judgment

Even with independent evaluation, today's models are far from perfect. A fix can be technically correct and pass automated tests while still negatively affecting user experience or business metrics the evaluation system cannot accurately measure.

For example, an agent might resolve a checkout error by introducing an additional verification step. The error disappears, the tests pass, but the additional friction could reduce checkout conversion rates.

This is where human oversight becomes essential. A passing evaluation produces a pull request with the proposed fix and supporting evidence, but the engineer reviewing it needs to evaluate more than technical correctness.

Engineers need to develop product sense, not just technical expertise.

They need to understand their users, the metrics that matter, and the trade-offs behind each change. If every product decision has to be passed to a product manager, the engineer becomes little more than a human proxy between the AI and the person actually making the decision.

The engineer approving the change needs to own its impact on the product, not just the quality of its implementation.

Production logs feed an hourly monitoring loop that creates jobs in durable storage. An implementation loop clones the repository, implements a fix with an agent, and runs the application. An evaluation loop runs regression tests, measures metrics, and compares before and after. Rejected fixes return to implementation; successful fixes become pull requests.

From Individual Agents to a Maintenance System

Connecting these workflows creates a system that continuously identifies problems, implements solutions, and validates changes with minimal human intervention.

And it doesn't have to stop at bug fixing. The same architecture can support performance optimization, dependency upgrades, and other ongoing maintenance tasks. Additional loops can extend its capabilities, such as a daily reporting loop that summarizes detected incidents, attempted fixes, approved changes, and unresolved jobs.

The larger shift is that software maintenance becomes a continuously operating process rather than a collection of tasks engineers initiate and execute manually.

As the cost of implementation decreases, the value of knowing what to implement increases.

The competitive advantage shifts toward engineers who can identify valuable problems, design the systems that solve them, and take ownership of the results.

Sources