---
title: "Discussion on \"How we built an AI that fixes failed builds (and why we verify the patch before building)\" | Hashnode"
description: "Discussion on \"How we built an AI that fixes failed builds (and why we verify the patch before building)\". 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"
url: "https://hashnode.com/posts/how-we-built-an-ai-that-fixes-failed-builds-and-why-we-verify-the-patch-before-building/6af200e73bb56a980ff2150b"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [How we built an AI that fixes failed builds (and why we verify the patch before building)](https://uagents8.hashnode.dev/how-we-built-an-ai-that-fixes-failed-builds-and-why-we-verify-the-patch-before-building?utm_source=hashnode&utm_medium=feed)

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

6h ago · 7 min read · uagents8.hashnode.dev  
Read the article

-   [#ai](https://hashnode.com/tag/ai)
-   [#devops](https://hashnode.com/tag/devops)
-   [#webdev](https://hashnode.com/tag/webdev)
-   [#kubernetes](https://hashnode.com/tag/kubernetes)

## Written by

[Serhii Antonuik](https://hashnode.com/@uagents8)

@uagents8

  
[View profile](https://hashnode.com/@uagents8)

Building uagents8, a platform for deploying AI agents to Kubernetes. Writing about AI Fix and LangGraph deployments.

Building uagents8, a platform for deploying AI agents to Kubernetes. Writing about AI Fix and LangGraph deployments.

## Responses 2

Markdown supported · ⌘↵ to post

[OneLifeVibe](https://hashnode.com/@onelifevibe)

[1h ago](https://hashnode.com/posts/how-we-built-an-ai-that-fixes-failed-builds-and-why-we-verify-the-patch-before-building/6af200e73bb56a980ff2150b/comment/6af24467d33f19b0aeb81bc4)

The verify-before-you-build idea is the part I would steal first. Most fix-it loops I have seen re-run the whole pipeline on every guess, so a patch that was never going to work still costs a full build. The triage step is a nice counterweight too — routing by LOW, MEDIUM and HIGH with a deterministic fallback instead of letting the model decide everything keeps the cheap fixes cheap. And the rule that only successful fixes enter memory is quietly important: a system that remembers its failures as successes just repeats them faster. Really clear write-up.

[Serhii Antonuik](https://hashnode.com/@uagents8)

[1h ago](https://hashnode.com/posts/how-we-built-an-ai-that-fixes-failed-builds-and-why-we-verify-the-patch-before-building/6af200e73bb56a980ff2150b/comment/6af24467d33f19b0aeb81bc4#reply-6af247a0b9e17432e02e3283)

Thanks! That's exactly the problem we wanted to solve.

Generating a patch is the easy part. Knowing whether it's safe, valid, and actually fixes the deployment before spending time and resources on another build is where things get interesting.

The same goes for memory — we don't want AI to become more confident in repeating its own mistakes.

We're continuing to push this further, and I'd love to hear what you'd consider the most important next step for a system like this: deeper runtime recovery, more framework coverage, or something else?

Appreciate you taking the time to read the technical details!