How we built an AI that fixes failed builds (and why we verify the patch before building)

Serhii Antonuik — Mon, 09 Nov 2026 14:09:11 +0000

It's Tuesday, 11 p.m. The demo is at nine. You push one last change to your
agent, and the deploy fails: a dependency you installed locally and never
wrote down, a variable you renamed in one file and not the other, a port your
framework picked by itself. The error is somewhere in three hundred lines of
build log.

We run a hosting platform for AI agents, and that moment is the one we wanted
to remove. Not with a chatbot that explains the log, but with a button: Fix
with AI. One click, and a fixed copy of your agent is live a few minutes
later, or you are told clearly why not.

The hard part turned out not to be "ask a model for a patch". It was
everything around the model. This is how it works, and what each part taught us.

Triage first: is this even a code problem?

Our first version sent every failure straight to code generation. It went
wrong in a very specific way: an agent missing a required environment variable
was "fixed" again and again. The model can't set a variable, so it wrote code
around the missing value, the deploy failed the same way, and the user clicked
again.

Now every attempt starts with a diagnosis that sorts the failure. Three
outcomes are possible before any code is touched:

A value only the owner can know. A missing API key, connection string or host. The fix stops and says which variable to set. We learned this one in a stress test: a model "fixed" a missing database URL by writing its own placeholder in as the real value, and the agent started, connected to nothing, and reported success. Now a credential-looking name or a placeholder-looking value is never filled in by AI.
A configuration change the evidence supports. If the platform's own health-check events show "connection refused" on the expected port, the port is aligned in configuration and the agent is redeployed. If the agent was stopped by a genuine out-of-memory kill, it is moved up one size (within the plan; at the largest size it stops and says so). The diagnosis alone is not enough; the evidence has to agree - and "exit code 137" alone is not evidence of a memory kill, because a process stopped for failing its health check exits the same way. We learned that one live too: an agent bound to the wrong interface was given more memory twice before the one-line code fix ran.
A real code problem. Everything else goes on to the patching pipeline.

A failure caused by us, such as a temporary capacity limit while building, is
never sent to a model at all. No patch can fix our capacity, and trying would
spend the user's allowance on nothing.

Choosing a model per failure class

Not every failure deserves the same model. A missing import is mechanical; a
race condition across three files is not. So before generating anything, a
fast, cheap model labels the failure LOW, MEDIUM or HIGH, with a
one-sentence reason. If that call fails, deterministic rules decide instead:
known patterns like ModuleNotFoundError or SyntaxError mean LOW,
deadlocks, segmentation faults and out-of-memory signals mean HIGH, and a
generic "never became ready" with no application error also goes to HIGH,
because there is nothing safe to guess from.

Each label has its own ordered chain of models. LOW and MEDIUM failures start
with a fast model that has a very large context window; HIGH ones, and every
second attempt, start with the strongest coding models we use. If one provider in the
chain errors, times out or is rate-limited, the next one answers.

Two lessons from running this in production:

Routing everything to the strongest model made the fix the most expensive thing we sell. Starting easy cases on a cheaper model, and saving the expensive ones for hard failures and retries, kept quality where it matters and costs bounded by each plan's monthly AI budget.
A fallback you never exercise is not a fallback. We found two models in our chains failing almost every call for weeks: for one, our account's rate limit was smaller than a single fix prompt; for the other, the context window was. Both were fixed, and every chain was re-tested with a real-size prompt.

What the model sees

The model gets the error output (the tail, where the failure is), your
Dockerfile if there is one, and up to 60 source files. The files the error
names come first and whole, even when they are larger than the usual
per-file limit, because a fix for a syntax error needs the file's header too.
It also gets the names, never the values, of the environment variables
you have set, so it doesn't invent a "missing variable" that exists.

Before anything leaves the platform, files that exist to hold credentials
(.env, private keys) are left out, and values that look like secrets are
replaced with placeholders. The real values go back into the patched files
afterwards. This is pattern-based and can't catch every secret, which is why
we tell users to keep secrets in variables, not in code.

Two gates before any build: parse, then a security review

A build takes real time and real money. An early patch for a Go service
dropped the file's package line; it went to a full build only for the
compiler to reject it in the first second. Now every patch must parse
before anything is built: real parsers for Python, Go, Java, JavaScript,
TypeScript, Rust and JSON, plus Go-specific checks for the mistakes models
actually make (a dropped or renamed package clause, = instead of == in a
condition). A patch that fails goes back to the model with the parser's
message. For a typical file this takes well under a millisecond.

We also check the whole snapshot, not only the patched files. In a stress test
a repository with several broken files cost one redeploy per broken file,
because each fix only looked at the file the latest error named. Now every
file that doesn't parse is listed in the prompt and ranked first.

Then the patch goes through an automated security review, the same one
every deploy from source goes through. If it finds a critical problem, nothing
is built. If the review itself can't complete, nothing is built either: there
is no human between the click and the deploy to weigh a skipped check, so the
pipeline fails closed.

Deploy a copy, then ask the health check

The patched code is never pushed to your repository. No commits, branches or
pull requests. It is written to a snapshot, built by the normal build
pipeline and deployed as a new version of the agent, marked as AI-fixed,
next to the versions you already have. If you don't like it, you restore the
previous version in one click, and your next push builds from your own code
again.

The new version goes through the same health check as any deploy: the agent
must start, listen on its port and answer. In our own tests, fixed copies went
live in 2 to 4.5 minutes, depending on the error and the size of the code.

If the health check fails, one more attempt runs automatically, and it is told
what the first attempt changed and what happened. That second attempt is
routed to the strongest models. After two attempts it stops and says so. A
human clicking again later starts a new streak, but the history of what
already failed is kept, so the same wrong fix isn't proposed with fresh
confidence.

What counts

A plan includes a number of AI Fixes a month. Only a code fix that ends with
your agent passing its health check uses one. A patch that failed to parse,
failed the security review, failed to build or failed to come up costs no fix.
Every model call does draw on the plan's monthly AI budget, which is how the
cost stays bounded either way.

What failures taught us: memory

Models are confident, and a model will propose the same failed fix twice.
So the platform remembers outcomes:

When a fix is confirmed healthy, it is stored for your own account. The same error on the same files can get that fix back without a model call. Confirmed fixes are never reused across accounts.
When a patch fails, its fingerprint is recorded. A patch that has already failed twice for a similar error is rejected outright. When another customer hits a similar error, the model is warned with the error signature, the error output and the names of the files that failed patch changed. Never the code itself.

What it doesn't do

It fixes failed builds and deploys, not an agent that crashes days after it went live. Today that gets a restart, a crash email and a plain-language diagnosis. Repairing a live agent is on our public roadmap.
It can't make an agent smaller than its workload. If an agent is killed for using more memory than its size allows, the repair is a larger size, not a patch: AI Fix moves it up one size when the kill is genuine, and stops and tells you when the next size is not in your plan.
It needs source code. An agent deployed from a ready-made image has no code to patch; diagnosis still explains the failure.
It isn't always right, which is why it stops after two attempts and why every result is a version you can roll back. We'll publish real success rates once we have enough launch traffic to make them honest.

Try it

Every plan includes AI Fix. If you have an agent that works on your laptop,
deploy it, break it on purpose, and press the button:
uagents8.com.
Launch code LAUNCH30 takes 30% off the first three months on Builder or
Growth until 30 November.

DEV Community: Serhii Antonuik