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

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

Comment [How we built an AI that fixes failed builds (and why we verify the patch before building)](https://hashnode.com/posts/how-we-built-an-ai-that-fixes-failed-builds-and-why-we-verify-the-patch-before-building/6af200e73bb56a980ff2150b)

[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!