Can AI Agents Write, Verify, and Apply Fixes on the Fly?

A deployment passes the pipeline. Everything looks fine. Then a service starts restarting, requests begin failing, and users can no longer complete what they came to do.

Now, let’s reason through this.

Could an AI agent investigate what changed, write a fix, verify it, and apply it while the system is running?

This is something I’m experimenting with as a DevOps Software AI Engineer. I’m exploring it across microservices, deployment pipelines, backend services, and infrastructure. I’m also interested in how the same approach could apply to frontend applications.

The question that keeps bringing me back is simple:

If an agent can make a change, how do we establish that it made the right change—and that the change actually worked?

Start with a problem we can follow

Imagine we have a payment service running in production.

Version one is working. We introduce version two gradually, sending it five out of every hundred requests. This gives us a chance to observe the new version before sending it all our traffic.

Then we notice something:

Memory usage keeps climbing on version two.

Its containers restart repeatedly.

Some payment requests fail.

Version one continues behaving normally.

An agent might suggest increasing the memory limit.

That could be appropriate if the service simply needs more memory. But if the new code contains a memory leak, increasing the limit might only delay the next failure.

So, before changing anything, the agent needs to investigate.

Observe → reason → propose

I want the agent to connect the evidence.

What changed in the release? When did the failures begin? Are they concentrated in version two? Is the stable version still healthy? What do the logs, metrics, and deployment history tell us?

An out-of-memory termination is a clue. It does not, by itself, prove a memory leak.

For this example, suppose the evidence points to the new release and the stable version has enough capacity to handle the traffic.

The agent could propose a focused action:

Stop sending new requests to version two and return traffic to version one.

That gives us two separate tasks: restore service, then investigate and repair the underlying problem.

Routing traffic back does not fix the faulty code. It creates room to work on it while reducing further disruption.

Propose → verify → apply

This is where the experiment becomes more interesting.

The agent has written a routing change. Should we execute it simply because the explanation sounds reasonable?

I would want the surrounding system to check things such as:

Does the change target the intended service and environment?

Does it leave the stable version available?

Can that version handle the additional traffic?

Does the configuration pass validation?

Is this action within the agent’s approved permissions?

Can we reverse it if the result is worse?

Some checks should be enforced by ordinary software and policy rules. An LLM reviewing another LLM’s output can contribute useful criticism, but that review should sit alongside concrete checks.

For a narrowly scoped, previously authorized action, the system could apply the change automatically after those checks pass. A change outside that scope would stop for human review.

That boundary is part of what I’m experimenting with: deciding which actions can run autonomously, under which conditions, and with what evidence.

Apply → observe → check the outcome

A successful command tells us that a command ran.

We still need to establish whether users can complete their requests again.

After the traffic change, the system should observe error rates, latency, capacity, and relevant business behavior over a defined period. For a payment service, that includes checking whether transactions complete correctly—not just whether an endpoint returns a successful response.

If the evidence does not show recovery, the agent should report that clearly and follow the agreed escalation or recovery path.

“Applied successfully” and “resolved successfully” are different claims.

What about fixing the code itself?

Once the service is stable, the agent could investigate the suspected memory problem.

Let’s keep the example basic.

Suppose the service stores request data in an in-memory collection but never removes it. As requests arrive, the collection grows.

The agent could:

Locate the code responsible.

Reproduce the growing memory usage.

Propose a bounded collection or remove unnecessary retention.

Run a test that exercises repeated requests.

Compare memory behavior before and after the change.

Prepare the fix for review and a controlled rollout.

The important part is connecting the proposed change to the observed failure.

A patch that passes existing tests may still miss the problem if those tests never exercise it. We need a check that would fail under the original behavior and provide meaningful evidence about the correction.

The same thinking applies beyond infrastructure

Take a login problem.

A user enters valid credentials, but the frontend keeps sending them back to the login page.

The cause might be a frontend state update, a backend response, or a cookie configuration. An agent should investigate that connection before choosing where to patch.

Suppose it discovers that the frontend redirects before the authentication state has finished updating.

It could propose a code change and test the complete flow:

Enter valid credentials → submit → wait for authentication → reach the dashboard → refresh → remain signed in.

It should also check that invalid credentials still fail correctly.

Here, verification includes what a person experiences in the browser. A passing backend test alone would not establish that the login journey works.

The same cycle can apply across different parts of a system:

Microservices: correct a request-handling bug, then check the failing request and relevant compatibility behavior.

Backend services: fix unnecessary data retention, then check that repeated requests no longer cause unbounded memory growth.

Deployment pipelines: correct a faulty release step, then verify the intended artifact is produced and deployed.

Infrastructure: adjust an incorrect routing rule, then verify traffic reaches the intended healthy destination.

Frontend applications: correct a login-state race, then test the expected browser journey.

The tools change. The need to connect the problem, the patch, and the evidence remains.

Where does learning come in?

The original idea that attracted me was an agent that could improve how it responds over time.

After an incident, it could record what happened, what it tried, what worked, and what remained uncertain. During a similar incident, that history could help it investigate more efficiently.

But I would be careful about turning one incident into a permanent rule.

“Always roll back when memory rises” would be a poor lesson. Memory can rise for several reasons, and a rollback may not always be safe.

A more useful record would preserve the context:

In this rollout, failures were concentrated in the new version. The previous version remained healthy and had sufficient capacity. Returning traffic to it reduced failures during the observation period.

That is evidence a future investigation can assess.

The agent could also propose an improvement: an additional memory test in the pipeline, better deployment monitoring, or a dedicated profiling step. Changes to its own permissions, tools, or persistent behavior would need a separate review.

What I want to establish through these experiments

I’m interested in how much of this cycle we can make dependable:

Observe → reason → propose → verify → apply → check the outcome.

That means giving an agent useful access to evidence, clear limits on what it can change, and checks that can block an unsuitable patch.

A signature can establish who approved an artifact and whether it was altered. A syntax check can establish that a configuration is structurally valid. Neither establishes that the change will solve the problem. We still need tests, policy enforcement, observation, and human judgment where appropriate.

For me, the exciting part is bringing these pieces together across software delivery and operations.

An agent might write a backend patch, correct a frontend bug, adjust a deployment configuration, or restore traffic to a healthy service. In each case, I want to be able to follow its reasoning and inspect the evidence.

That is what I’m exploring as a DevOps Software AI Engineer: how to let agents act with useful autonomy while keeping their changes understandable, bounded, and verifiable.

The complete workflow