ForgeInfra- We Built an AI That Repairs Legacy Infrastructure Software at HackUTD 2026

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.

This is a submission for the MLH x DEV Writing Challenge https://dev.to/mlh-hackathon . What happens when your data center is experiencing a failure, but its monitoring software tells you everything is fine? That was the problem my teammates, Ashmit and Ayman, and I decided to tackle at HackUTD 2026 . We 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. Our inspiration came from a common engineering problem. Legacy systems don't always fail visibly. Sometimes, they fail by confidently reporting incorrect information. For 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. ForgeInfra detects that inconsistency and investigates why the monitoring software missed it. Our workflow connects several components: In 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. We also persisted 564 Arduino telemetry readings , including 263 samples recorded while the simulated cooling fault was active . The project combined React, FastAPI, Python, Docker, NVIDIA Nemotron, Gemini, MongoDB Atlas, Tiger Data, Jira, Slack, and Solana. Looking back, we probably tried to build an entire engineering department in one weekend. But it was an incredible learning experience. Our demonstration centered around a simple question: Can an AI agent find and repair a monitoring bug that causes an infrastructure failure to go unnoticed? We demonstrated two hardware scenarios: normal operation and a simulated cooling-system fault. The monitoring software initially missed the fault, but our independent reliability checks detected the inconsistency. From there, our dashboard allowed us to inspect the incident, follow the AI investigation, review the generated repair, and examine the verification results. One of the most satisfying parts of the project was watching the regression result change: Before repair: 4/5 tests passing After repair: 5/5 tests passing The candidate repair corrected the missed warning in our representative legacy monitor. We also demonstrated the human approval and repair-evidence workflow. Of course, being a hackathon, not everything went according to plan. Our 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. That experience taught us an important lesson: always have a backup demo. One 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. Nemotron was central to our software repair workflow. Rather than building a chatbot that simply recommended what an engineer should do, we wanted an AI agent that could interact with actual engineering tools. Our Nemotron integration supported tool calls to: The agent identified that the representative legacy monitor wasn't accounting for the simulated cooling-fault signal and proposed a correction. We then evaluated the candidate inside an isolated Docker environment with restricted permissions and no network access. The key lesson was that AI-generated code should never be treated as correct simply because the model produced it. We made testing a required part of the workflow. We used MongoDB Atlas to persist our incident records, investigation results, repair evidence, and approval information. The goal was to preserve the sequence of engineering decisions rather than simply display a temporary AI response. For an infrastructure reliability system, this matters because operators need to understand what happened and why a decision was made. Infrastructure monitoring generates timestamped data continuously. We used Tiger Data's PostgreSQL-based time-series capabilities to store and query telemetry history, complementing the incident-oriented records in MongoDB. This separation gave the two databases distinct responsibilities: It was our first major lesson in choosing databases based on their responsibilities rather than simply adding technologies to a stack. One of the more unusual features we implemented was RepairProof , our Solana-based evidence verification workflow. We 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. Our approach was to: We successfully published and verified a real Solana Devnet transaction . The blockchain doesn't prove the software is bug-free. It provides independently verifiable evidence that a particular record was committed at a particular point. That distinction was important to our design. We integrated Gemini as a separate AI reviewer to examine the investigation and repair evidence. We also connected Jira and Slack to create engineering tickets and send incident notifications. One interesting challenge was ensuring that retrying an integration wouldn't create duplicate alerts or tickets. We addressed this through idempotent notification handling. These integrations helped turn ForgeInfra from a monitoring demonstration into a broader incident response workflow. Now for the part that made the weekend unforgettable. Our HackUTD experience began with a problem that had absolutely nothing to do with coding. Only one-third of our team was initially guaranteed entry. Ashmit 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. Luckily, both made it in shortly before the opening ceremony Since 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. Between 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. It was chaotic, but it was our kind of chaos. We entered HackUTD believing that building the most technically complex project possible would give us the best chance of winning. BOY, were we wrong We spent considerable time integrating multiple databases, AI models, hardware components, backend services, and blockchain verification. We were proud of the engineering. But after watching the winning projects and reflecting on our own, we realized something. A technically impressive project isn't automatically a great product. We spent too much time asking: What else can we build? And not enough time asking: What does the user actually need? That realization gave us several lessons we'll carry into future hackathons. 1. Understand the problem before choosing technologies. We should have spent more time studying the sponsor challenges, understanding the users, and identifying their biggest pain points. 2. Depth beats breadth. Three deeply developed features that solve a real problem can be more valuable than ten loosely connected features. 3. Every feature should justify its existence. Adding another database, model, or integration doesn't automatically make a project better. Sometimes, it makes the experience harder to understand. 4. The demonstration is part of the product. A 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. 5. Build for people, not just engineers. The goal isn't to impress someone with a technology stack. It's to make their life easier. Nope. And while winning would have been amazing, I genuinely believe the lessons we learned will be more valuable in the long run. We built a working prototype involving real hardware telemetry, AI-generated software repair, independent verification, enterprise integrations, and a finalized blockchain transaction. More 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. HackUTD gave us a better understanding of both software engineering and ourselves. Huge thanks to Ashmit and Ayman for an unforgettable weekend, and to the HackUTD organizers, volunteers, and sponsors for making it possible. We didn't leave with a prize. But 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. And regardless of the outcome, we lived to tell the tale of our quest to defeat the HIVE at HackUTD 2026 🐝 Project: ForgeInfra on Devpost https://devpost.com/software/factoryos