Go in the Age of AI Agents: Why Boring Wins

The site you are reading right now is a single Go binary. I have written about that before, and have been working with Go for the past four years, building data pipelines and AI-related CLIs like AI Buddy. So when the Go team published a post this week arguing that Go is an ideal language for AI-assisted software engineering, I read it with the natural skepticism you should apply to any language team explaining why their language is the answer.

But the core argument is not really about Go. It is about a shift I have been feeling for months in my day to day work, both at Oracle Health and in my own projects: I write far less code than I used to, and I review far more. That single change reorders almost everything we used to believe about what makes a language good.

Let me walk through the argument, and then tell you where I think it is weaker than the post admits.

The bottleneck moved

For decades we measured languages by how pleasant they were to write. Terseness was a virtue. Clever abstractions were a virtue. Anything that reduced keystrokes between an idea and a running program was a selling point, and entire language communities grew up around that value.

That metric is now close to irrelevant. When an agent can produce four hundred lines of syntactically valid code in twelve seconds, my typing speed is not the constraint. The constraint is my ability to read those four hundred lines, understand what they claim to do, verify that they actually do it, and decide whether they belong in the system at all.

The Go team frames this as a shift from generation to verification, and I think that framing is correct. It also explains why some of my favorite languages have started to feel worse in an agentic workflow, even though nothing about them changed. A language that offers twelve ways to express the same logic will produce twelve different styles across a single agent session, and reviewing that is exhausting in a way that has nothing to do with the difficulty of the underlying problem.

Go is a platform, not just a language

The strongest part of the argument is that Go ships as an end to end toolchain rather than a language plus an ecosystem of competing tools. Formatting, testing, dependency management, vulnerability scanning, profiling, and now automated modernization all live in the standard toolchain.

This matters more for an agent than it does for a human. Give a coding agent a task in a JavaScript or Python codebase and it first has to infer the project's conventions: which formatter, which test runner, which package manager, which lint config, which of the four competing type checkers. Every one of those inferences is a chance to be wrong, and every wrong inference burns context and produces a diff full of noise that has nothing to do with the actual change.

In a Go repo, there is nothing to infer. go build, go test, gofmt, go vet, govulncheck. The agent has a deterministic, cheap oracle it can consult after every edit. This is the practical version of a point I keep making about agentic workflows: the agentic loop is only as good as the feedback signal you can give it. Go happens to ship with an excellent one in the box.

Readability as an AI feature

Go's design has always prioritized reading over writing. Gophers like to say you cannot tell who on the team wrote a given file, because it all looks the same. That was a deliberate choice from the beginning, part of what Rob Pike described as language design in the service of software engineering, and the Go team now argues it is a force multiplier for AI-assisted work.

I think this is right, and slightly under-explained. There are two separate effects here.

The first is on review. When syntax is entirely predictable, anomalies stand out. A hallucinated method call, a swallowed error, a subtly wrong loop boundary. These are easier to spot when the surrounding code has no stylistic variance competing for your attention. My review of an agent's Go diff feels like scanning; my review of an agent's TypeScript diff feels like decoding.

The second is on training data. Because effectively the entire open source Go ecosystem is gofmt'd and follows a narrow set of idioms, models are trained on unusually consistent data for that language. That is a real, structural advantage, and it compounds over time.

The compiler as a safety net

Here is where the argument gets honestly strong. LLMs are bad at structural coherence across files. They invent methods that do not exist, pass the wrong shape into a function, and confidently reference a field that was renamed three commits ago.

In Python, those mistakes are silent until runtime, and sometimes silent until a specific production workload hits a specific branch at 2am. In Go, they do not compile. The agent gets an immediate, precise, machine-readable error and fixes it before I ever look at the code.

Pair that with Go's compilation speed, which is the actual unsung hero of the story, and you get a very tight self-correction loop. A type system alone is not enough. Rust has a far stronger one, but a slow compile turns each iteration into a meaningful wait, and complex borrow checker errors are exactly the kind of thing agents flail against. Go's combination of "strict enough to catch real mistakes" and "fast enough to iterate twenty times a minute" is the actual sweet spot, and it is a narrower target than people assume.

The supply chain point is also underrated. Asked to solve a problem, models reach for whatever library dominated their training data, which is frequently a package that is stale, abandoned, or in the worst case, malicious. Go's comprehensive standard library means the idiomatic answer to "serve HTTP," "parse JSON," or "run concurrent workers" is usually zero new dependencies. The module mirror and checksum database mean the dependencies you do add cannot silently change underneath you, and govulncheck reports only vulnerabilities in functions your code actually calls, which cuts the noise that makes most scanners easy to ignore.

Maintainability on day 500

The last pillar is the compatibility promise. Go 1 code compiles on today's toolchain, and the team has committed to never shipping a breaking Go 2.0. Your code does not rot. You upgrade the toolchain, recompile, and inherit better performance for free.

This mattered before. It matters much more now, because agents can generate pull requests faster than any team can absorb them, and architectural drift is the natural result. Go's answer is deterministic tooling: gopls and the rebuilt go fix with its modernizers, which mechanically rewrite older patterns into current idioms across an entire codebase. Deterministic refactoring is exactly the kind of work you should never hand to a probabilistic system, and having it in the standard toolchain means an agent can invoke it rather than attempt it.

Add single static binaries with no runtime dependencies and trivial cross compilation, and you get something well matched to a world where agents deploy as much as they code.

Where I think the argument is weaker

Now the part the original post skips, because a language team is never going to write it.

Go's error handling means more code to review, not less. The Go team's own thesis is that reviewing is the bottleneck. But idiomatic Go produces a lot of surface area to review, and a meaningful fraction of it is repetitive error propagation. Agents write that boilerplate perfectly and instantly, which is a real win, but I still have to read it, and the signal to noise ratio of a Go diff is not obviously better than a well-typed TypeScript one.

The type system is decent, not great. Compared to Python, Go's compiler catches enormously more. Compared to Rust, or to TypeScript with strict mode and a well-designed domain model, Go's type system is fairly blunt. nil is still nil. There are no sum types, no exhaustive matching, and no way to make an invalid state unrepresentable in the way you can elsewhere. Those are precisely the guardrails that catch the class of agent mistakes that do compile.

Compiling is not correctness. Everything above is about mechanical errors. The mistakes that actually cost me time in agentic work are not type errors, they are logic errors, wrong assumptions about the domain, and plausible looking code that solves the wrong problem. No compiler in any language catches those. The verification burden the post identifies does not go away, it just moves up a level, and that level is entirely human.

Python is not going anywhere. The post carefully avoids saying so, but the language where the most AI is actually written remains the one with the weakest guarantees, because that is where the libraries live. "Go is better for agents" and "I am going to write my model training pipeline in Go" are different claims, and only the first one is defensible.

Less training data. Go's data is more consistent, but there is far less of it than Python or JavaScript. Consistency helps. Volume also helps. Which effect dominates is an empirical question, and neither the Go team nor I have the numbers.

What I am actually changing

None of the above stops me from thinking the core insight is correct, and it has changed two concrete things in how I work.

First, when I start a new backend service that an agent will do most of the typing for, Go moved up my list. Not because I write it faster, but because the review loop is cheaper and the toolchain gives the agent something reliable to check itself against.

Second, and more portable across languages: I now treat "what deterministic feedback can I hand the agent" as a first class architecture question. Formatter, type checker, fast test suite, vulnerability scanner, all runnable in one command. Go gets this for free. Every other stack can be configured to approximate it, and if you are doing serious agentic development, you should.

Final thoughts

The counterintuitive conclusion in the Go team's post is that as we write less code, the choice of language matters more, not less. I think that is the sharpest idea in the piece, and it survives the skepticism.

What I would add is that the underlying principle is bigger than Go. The languages and tools that win the next few years will be the ones that optimize for verification rather than expression: predictable syntax, strong mechanical checks, fast feedback, and boring uniformity. Go is a strong instance of that class because it was designed around collaboration at scale twenty years before anyone imagined a non-human collaborator. It got there early, and mostly by accident.

Boring, it turns out, is a feature. It just took a new kind of teammate to make that obvious.