{"slug": "forgeinfra-we-built-an-ai-that-repairs-legacy-infrastructure-software-at-hackutd", "title": "ForgeInfra- We Built an AI That Repairs Legacy Infrastructure Software at HackUTD 2026", "summary": "A three-person team built ForgeInfra, an AI-powered infrastructure reliability and legacy software repair platform, at HackUTD 2026. The system uses NVIDIA Nemotron to investigate why legacy monitoring software misses infrastructure faults and to generate candidate repairs, which are then verified in an isolated Docker sandbox; in a demonstrated scenario, a legacy monitor passing 4 of 5 regression tests passed all 5 after the AI-generated repair, including a previously missed cooling-fault case. The team also persisted 564 Arduino telemetry readings, 263 of them during a simulated cooling fault, and required human approval before repairs.", "body_md": "*This is a submission for the [MLH x DEV Writing Challenge](https://dev.to/mlh-hackathon).*\n\n**What happens when your data center is experiencing a failure, but its monitoring software tells you everything is fine?**\n\nThat was the problem my teammates, Ashmit and Ayman, and I decided to tackle at **HackUTD 2026**.\n\nWe built **ForgeInfra**, an AI-powered infrastructure reliability and legacy software repair platform designed to detect overlooked infrastructure failures, investigate faulty monitoring logic, generate and verify software repairs, and coordinate incident response.\n\nOur inspiration came from a common engineering problem. Legacy systems don't always fail visibly. Sometimes, they fail by confidently reporting incorrect information.\n\nFor example, imagine a cooling system reporting a temperature of 29.4°C while a cooling fault is active. An outdated monitoring program might still report everything as NORMAL because it doesn't account for the cooling failure.\n\nForgeInfra detects that inconsistency and investigates why the monitoring software missed it.\n\nOur workflow connects several components:\n\nIn one demonstrated scenario, our original monitoring code passed **4 out of 5 regression tests**. After Nemotron generated a repair, the candidate passed **all 5 tests**, including the previously missed cooling-fault case.\n\nWe also persisted **564 Arduino telemetry readings**, including **263 samples recorded while the simulated cooling fault was active**.\n\nThe project combined React, FastAPI, Python, Docker, NVIDIA Nemotron, Gemini, MongoDB Atlas, Tiger Data, Jira, Slack, and Solana.\n\nLooking back, we probably tried to build an entire engineering department in one weekend.\n\nBut it was an incredible learning experience.\n\nOur demonstration centered around a simple question:\n\n**Can an AI agent find and repair a monitoring bug that causes an infrastructure failure to go unnoticed?**\n\nWe demonstrated two hardware scenarios: normal operation and a simulated cooling-system fault.\n\nThe monitoring software initially missed the fault, but our independent reliability checks detected the inconsistency.\n\nFrom there, our dashboard allowed us to inspect the incident, follow the AI investigation, review the generated repair, and examine the verification results.\n\nOne of the most satisfying parts of the project was watching the regression result change:\n\n**Before repair: 4/5 tests passing**\n\n**After repair: 5/5 tests passing**\n\nThe candidate repair corrected the missed warning in our representative legacy monitor. We also demonstrated the human approval and repair-evidence workflow.\n\nOf course, being a hackathon, not everything went according to plan.\n\nOur hardware decided not to cooperate during the live judging demonstration. Thankfully, we had recorded both working hardware scenarios beforehand, and the judges allowed us to show those videos instead.\n\nThat experience taught us an important lesson: **always have a backup demo.**\n\nOne of our initial goals was to experiment with technologies we hadn't worked with extensively before. Here's how we integrated several sponsor and ecosystem platforms into ForgeInfra.\n\nNemotron was central to our software repair workflow.\n\nRather than building a chatbot that simply recommended what an engineer should do, we wanted an AI agent that could interact with actual engineering tools.\n\nOur Nemotron integration supported tool calls to:\n\nThe agent identified that the representative legacy monitor wasn't accounting for the simulated cooling-fault signal and proposed a correction.\n\nWe then evaluated the candidate inside an isolated Docker environment with restricted permissions and no network access.\n\n**The key lesson was that AI-generated code should never be treated as correct simply because the model produced it.**\n\nWe made testing a required part of the workflow.\n\nWe used MongoDB Atlas to persist our incident records, investigation results, repair evidence, and approval information.\n\nThe goal was to preserve the sequence of engineering decisions rather than simply display a temporary AI response.\n\nFor an infrastructure reliability system, this matters because operators need to understand what happened and why a decision was made.\n\nInfrastructure monitoring generates timestamped data continuously.\n\nWe used Tiger Data's PostgreSQL-based time-series capabilities to store and query telemetry history, complementing the incident-oriented records in MongoDB.\n\nThis separation gave the two databases distinct responsibilities:\n\nIt was our first major lesson in choosing databases based on their responsibilities rather than simply adding technologies to a stack.\n\nOne of the more unusual features we implemented was **RepairProof**, our Solana-based evidence verification workflow.\n\nWe wanted a way to establish that a particular AI-generated repair had been reviewed and approved without publishing sensitive source code or private incident data.\n\nOur approach was to:\n\nWe successfully published and verified a **real Solana Devnet transaction**.\n\nThe blockchain doesn't prove the software is bug-free. It provides independently verifiable evidence that a particular record was committed at a particular point.\n\nThat distinction was important to our design.\n\nWe integrated Gemini as a separate AI reviewer to examine the investigation and repair evidence.\n\nWe also connected Jira and Slack to create engineering tickets and send incident notifications.\n\nOne interesting challenge was ensuring that retrying an integration wouldn't create duplicate alerts or tickets. We addressed this through idempotent notification handling.\n\nThese integrations helped turn ForgeInfra from a monitoring demonstration into a broader incident response workflow.\n\nNow for the part that made the weekend unforgettable.\n\nOur HackUTD experience began with a problem that had absolutely nothing to do with coding.\n\n**Only one-third of our team was initially guaranteed entry.**\n\nAshmit and Ayman arrived at UT Dallas around **5:30 AM**, joining an already enormous line in the cold. They waited for hours, hoping to get inside.\n\nLuckily, both made it in shortly before the opening ceremony!\n\nSince I live on campus, I knew a few classrooms with excellent projectors and sound systems. We ended up turning one of them into our unofficial headquarters for the weekend.\n\nBetween building ForgeInfra, we watched movies, played music, took naps, argued over technical decisions, and laughed at things that probably wouldn't have been funny if we weren't sleep-deprived.\n\nIt was chaotic, but it was our kind of chaos.\n\nWe entered HackUTD believing that building the most technically complex project possible would give us the best chance of winning.\n\n**BOY, were we wrong!**\n\nWe spent considerable time integrating multiple databases, AI models, hardware components, backend services, and blockchain verification.\n\nWe were proud of the engineering.\n\nBut after watching the winning projects and reflecting on our own, we realized something.\n\n**A technically impressive project isn't automatically a great product.**\n\nWe spent too much time asking:\n\n*What else can we build?*\n\nAnd not enough time asking:\n\n*What does the user actually need?*\n\nThat realization gave us several lessons we'll carry into future hackathons.\n\n**1. Understand the problem before choosing technologies.**\n\nWe should have spent more time studying the sponsor challenges, understanding the users, and identifying their biggest pain points.\n\n**2. Depth beats breadth.**\n\nThree deeply developed features that solve a real problem can be more valuable than ten loosely connected features.\n\n**3. Every feature should justify its existence.**\n\nAdding another database, model, or integration doesn't automatically make a project better. Sometimes, it makes the experience harder to understand.\n\n**4. The demonstration is part of the product.**\n\nA judge should understand the problem, solution, and value within the first few moments. An intuitive interface, clear workflow, and memorable demonstration can matter as much as the underlying architecture.\n\n**5. Build for people, not just engineers.**\n\nThe goal isn't to impress someone with a technology stack. It's to make their life easier.\n\nNope.\n\nAnd while winning would have been amazing, I genuinely believe the lessons we learned will be more valuable in the long run.\n\nWe built a working prototype involving real hardware telemetry, AI-generated software repair, independent verification, enterprise integrations, and a finalized blockchain transaction.\n\nMore importantly, we learned how we behave under pressure, how we collaborate when things go wrong, and how much we still have to learn about building products.\n\nHackUTD gave us a better understanding of both software engineering and ourselves.\n\nHuge thanks to **Ashmit and Ayman** for an unforgettable weekend, and to the HackUTD organizers, volunteers, and sponsors for making it possible.\n\nWe didn't leave with a prize.\n\nBut we left with a project we're proud of, a stronger team, countless memories, and a much clearer understanding of what we want to build next.\n\n**And regardless of the outcome, we lived to tell the tale of our quest to defeat the HIVE at HackUTD 2026!** 🐝\n\n**Project:** [ForgeInfra on Devpost](https://devpost.com/software/factoryos)", "url": "https://wpnews.pro/news/forgeinfra-we-built-an-ai-that-repairs-legacy-infrastructure-software-at-hackutd", "canonical_source": "https://dev.to/eeraj_rahman_ac16ce223078/forgeinfra-we-built-an-ai-that-repairs-legacy-infrastructure-software-at-hackutd-2026-15a3", "published_at": "2026-11-12 17:45:43+00:00", "updated_at": "2026-11-12 17:52:24.001880+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-tools", "ai-infrastructure", "large-language-models"], "entities": ["ForgeInfra", "HackUTD 2026", "NVIDIA Nemotron", "Gemini", "MongoDB Atlas", "Tiger Data", "Jira", "Solana"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/forgeinfra-we-built-an-ai-that-repairs-legacy-infrastructure-software-at-hackutd", "markdown": "https://wpnews.pro/news/forgeinfra-we-built-an-ai-that-repairs-legacy-infrastructure-software-at-hackutd.md", "text": "https://wpnews.pro/news/forgeinfra-we-built-an-ai-that-repairs-legacy-infrastructure-software-at-hackutd.txt", "jsonld": "https://wpnews.pro/news/forgeinfra-we-built-an-ai-that-repairs-legacy-infrastructure-software-at-hackutd.jsonld"}}