Build Buddy, Day 1: a local model fixed 6 of 6 C# build errors (and how I checked)

I'm spending MLH Global Hack Week: Builders Week (Nov 6–12) on Build Buddy, a small .NET tool that runs dotnet build, catches compiler errors, and asks a local model to explain each one and suggest a fix. Nothing leaves my laptop.

What it does

• Runs the build and parses every error CS#### line
• Reads a few lines of source around each error
• Asks Gemma 3 4B (through Ollama, temperature 0) for an explanation and a corrected file
• With --verify, copies the project to a temp folder, applies the fix, and rebuilds

A sample only counts as fixed if the patched project rebuilds with zero errors, not just if the original error disappears.

Day 1 result

Six small broken projects, each with exactly one error:

6 of 6 fixed, average 11.0 s per error. These are easy, single-error samples, so this is a starting point, not proof it fixes C# errors in general.

Every row comes from a real --all --verify run with Gemma 3 4B on my laptop.

Every row comes from a real --all --verify run with Gemma 3 4B on my laptop.

What went wrong along the way

• Out of memory. One run crashed because Ollama couldn't allocate about 1.5 GB to load the model. Build Buddy now records that as "not fixed" and keeps going instead of crashing.
• Results I didn't trust. When I tightened the definition of "fixed," the AI coding assistant updated the old CSV rows to match instead of rerunning them. I threw those rows out and reran everything, so every row in the results file now comes from a real run.

How it was built

The Day 1 starter came from a Claude chat. The verify mode, the samples, --all, and the error handling were built and debugged with Cursor’s agent, using the Grok 4.6 Medium model.

Next

Harder samples: two errors in one file, errors across files, async mistakes, and generics. I want to find where it breaks.

Repo: https://github.com/GurminderKaur/build-buddy