I Let Free AI and Claude Review My Go Code

What an agent actually is

Why not paste your diff into a chatbot and say “review this”? Three reasons. It burns far more tokens, because you dump everything in at once. It guesses whether your code compiles and your tests pass, so it’s more likely to make things up. And you have to teach it how you review, every single time.

An agent fixes all three. It’s just four things:

• A model that decides what to do next.
• Tools it can use: read a file, run go vet, run your tests.
• A loop that keeps going until it’s done.
• Your guidelines, which make it review the way you do.

It doesn’t guess, it checks. But I learned the hard way making this video that tools only help if the model knows where to look.

Why build agents in Go

Almost every agent tutorial is in Python or TypeScript. I think Go might be the best language for building with AI, for a boring reason: Go doesn’t change much. It has had a compatibility promise since 2012, so when AI writes Go, it looks like the Go I’ve been writing for years, and I can actually review it. That matters, because reviewing is the job now.

A skill that builds the agent for you

I didn’t type the agent by hand. I wrote a Claude skill, go-agent-builder, that interviews you before writing a line: what the agent should do, which tools it needs, whether it may change anything, which models it uses, its rules, and what the output should look like. When I asked for write access, it pushed back, explained the risk and asked me to confirm. Claude doesn’t build until it knows what we’re building.

The build: tools, model, loop

The agent has seven tools: list files, read a file, grep, git diff, go vet, go test, and a throwaway scratch test. Each is a name, a one-line description written for the model, and a Go function. The guardrails matter as much as the tools:

• No “run any command” tool. Each tool runs one fixed git or go command, never through a shell.
• It can’t push, and it can’t touch files outside the repo.
• go and git run with my API keys stripped from their environment.
• The only thing it can write is a scratch test named zz_review_*_test.go. It can’t overwrite my files, and it deletes the scratch tests when the review is done.
• A 20-step limit, so it can’t wander forever.

The model sits behind one Go interface. Claude, Ollama and Bedrock each implement it in their own file, and nothing else in the agent knows which model it’s talking to. The loop is the whole agent: ask the model what to do, run the tools it asks for, hand back the results, and repeat until it answers. That loop is the difference between a chatbot and an agent.

Guidelines: giving it taste

The guidelines are a markdown file that Go embeds into the binary, so the agent ships with my rules inside it. The first line is the most important one: clarity over everything else. Then:

• Look first: run go vet and go test. When you suspect a bug, don’t guess. Write a small test that triggers it, run it, and only mark it verified if you saw it happen.
• Check error handling, secrets, input validation, the services you call, resources and concurrency, and tests.
• Don’t flag formatting (gofmt does that), style preferences or praise.
• If the code works but is dense or too clever, explain in plain English what it does and suggest a clearer version.

That last rule is for me. When AI builds in an hour what would have taken me a week, there’s a lot of code to review at once. I want the agent to help me understand it, not just judge it.

One flag, any model

Because every model implements the same interface, switching is one flag: --model claude, --model bedrock or --model ollama. Ollama runs a model locally: free, private, and nothing leaves your machine. Bedrock rents the big open models that don’t fit on a laptop, by the token. The catch nobody puts in the thumbnail: free still needs hardware.

The showdown

The code under review was my own YouTube outliers tool, which I built with AI in about a week. go vet and go test both pass. It has five real bugs, which became the answer key.

Round 1: my laptop

A 7-billion-parameter model in Ollama froze my MacBook until it finished, and the review it wrote was nonsense: it described a go build step that never ran. The cause was Ollama’s default context of about 4,000 tokens. My code didn’t fit, so Ollama quietly dropped the beginning of the conversation, including my instructions, and the model made something up from what was left. Nothing warns you. The agent now asks Ollama for a bigger context by default.

Round 2: free GitHub runners

On GitHub’s free runners with a bigger context, the 7B model took eight minutes and said “No issues found.” A smaller 1.5B model took two minutes and reported fourteen issues. All fourteen were made up, and eight were the same invented bug, copied with the line number going up by five each time.

Round 3: a fair fight

That isn’t fair to open models, because the ones that fit on a laptop are small. So I put the big ones in the same agent: Qwen3-Coder 480B and DeepSeek V3.2 on Amazon Bedrock, against Claude Haiku, Sonnet and Opus. Same code, same guidelines, same seven tools, 20 steps max, every model run twice.

Claude Sonnet read my code, ran my tests, wrote one scratch test and ran it: four calls to the model, about fifty seconds. That one test proved two bugs at once, including this one. Whenever a request to YouTube fails, my tool logs the error. The error includes the full URL. And the URL includes my API key. In my own tool, that I use every week.

Sonnet found all five bugs in both runs, including one I had completely missed: YouTube titles go into my spreadsheet untouched, so a video title starting with = becomes a live formula when the file is opened in Excel or Google Sheets.

The open models used all twenty steps and didn’t find a single one of the five bugs:

• DeepSeek wrote a test that didn’t compile, then a second one with the same name, so neither compiled. It spent the rest of its steps fighting its own build errors.
• Qwen wrote a wrong test for something that already works and reported a “verified” bug that doesn’t exist.

My favorite was Claude Haiku. It wrote a test to check whether my key leaks, but the test built its own error message and then checked that message. Of course it passed, and the review said “Secrets: none found.” A passing test isn’t proof. You still have to look at what it tested.

The verdict

Free and local isn’t there yet for code review. Not because open models are bad, but because the ones that fit on a laptop are too small, and even the big ones didn’t know where to look. Same agent, same tools: the model is the difference.

And cheap per token isn’t cheap per review. Haiku wandered for twenty steps and cost more than Sonnet. Sixteen cents to find an API key leak in my own code? I’ll pay that. I’m keeping the Ollama flag, though: these models get better every few months, and when one passes this test, switching is one word.

Take it and make it yours

• The PR review agent, in Go. Swap in your own guidelines and it reviews the way you review. Install it with go install github.com/marianina8/pr-review-agent@latest.
• The go-agent-builder skill. It interviews you and builds your next agent the same clean way: a standup agent that reads your git log, a repo explainer for your first week on a new codebase, whatever you need.
• The GitHub Action. It builds the agent, runs it on every pull request and comments on the PR, and you pick the model with one setting. It’s the same one I used for the showdown, so you can run your own on your own code.

Want this for your team? I run a hands-on Build AI Agents in Go workshop where your team builds a working agent on a real problem of yours, like reviewing pull requests.

Next up: I give five AI models the same Go project to build from scratch. Same spec, same hidden tests, and we see who writes the bug.