Go is an ideal language for AI-assisted software engineering
TL;DR
Google's Go team argues that once agents write most code, the bottleneck moves from writing to reviewing. Go suits that work best, they say. One formatter, a strict and fast compiler, a large standard library and a no-breakage compatibility promise keep AI output uniform and checkable.
The article
- Agents can produce hundreds of lines in seconds, the Go team says. A language should now be judged by how easy its code is to review, verify and maintain. The post's authors are a Go product manager and a Google evangelist.
- Go ships with its own formatter, test framework, fuzzer, dependency manager and govulncheck. Agents that iterate against those tools, they argue, avoid the compounding errors of unvalidated refactoring passes.
- Because gofmt enforces one format and the language limits abstractions, they claim AI-written Go looks like human-written Go. That makes a hallucinated API call or a logic flaw easier for a reviewer to spot.
- Static types catch the hallucinated methods and wrong types that slip through in Python. They say Go compiles orders of magnitude faster than Java, C# or Rust. That lets an agent fix its own errors in a tight loop.
- A large standard library steers models away from stale or malicious third-party packages. The checksum database and module mirror protect the dependencies that remain.
- For maintenance they point to the compatibility promise that there will never be a Go 2.0. They also cite static cross-compiled binaries and go fix modernizers that rewrite old idioms deterministically. Last comes profile-guided optimization fed by production data.
Why it matters
Read it to see the Go team's official pitch for agent workflows, including the specific tools they expect agents to call. It is a vendor argument with no benchmarks or measurements. The thread below fills in the counter-case the post leaves out.
The discussion
A long, mostly skeptical thread. Commenters accepted that Go's tooling and fast builds help agents. Most of the energy went to whether a weak type system suits a model, with Rust as the usual counterexample. Several also noted that Google wrote the post and offered no data.
Strict compiler or fast loop
The largest argument set Rust's borrow checker and richer types against Go's quick builds. The Rust side says models lose track of global invariants, not lifetimes, so a compiler that enforces invariants is worth slower builds and more retries. Go users answer that each extra compile error costs tokens and latency, and agents fighting the borrow checker often reach for clones, Arc<Mutex> and unsafe. Some said Rust's error messages and cargo check make up the difference, others that only Rust programmers can review the result.
LLMs don't struggle with the low-level lifetimes like humans do. They struggle with the high-level view because of limited context windows. That's why you want a powerful type system to enforce those global constraints.
What happens is the LLM catches the error, then may hit another error, and try again. This leads to more tokens and more latency, and then after all that you have a longer compile time.
Agents still write broken concurrent Go
Many commenters said models write ordinary Go fine but fall apart on goroutines and channels, and one cited Uber's study of data races. Defenders called most of those bugs beginner mistakes that any shared-memory language allows. A long side fight over whether Go has ever produced a correct Raft went nowhere, since Antithesis had found bugs in every Raft it tested. tptacek noted those were distributed-systems bugs, not threading bugs.
But good god, the second it gets to anything concurrency-related, it just loses its mind.
In my experience, shared memory instills the appropriate fear and caution, while the apparent simplicity of channels encourages novice Go programers to take on concurrency projects beyond their abilities and without due care.
Nil and zero values let invalid state compile
The second-ranked thread argued that Go allows nil or half-built structs, so the compiler can't catch an agent breaking another part of the system. Constructor conventions, nilaway and linters were offered as fixes. Critics said the standard library itself doesn't follow those conventions. Experienced Go users said nil panics are rare and easy to fix, but others said silent zero values do more damage because nothing crashes.
Nil and partially constructed structs are impossible to prevent the creation of in Go.
nil pointer panics aren't nearly as bad as values getting zero initialized, then used in places that assume they were initialized, and getting subtle bugs because the state is inconsistent.
Readable lines, too many of them
Commenters agreed Go is easy to read a line at a time and doubted that helps once agents produce it in bulk. Reviewers described losing subtle mistakes in long diffs, and some argued denser languages fit more logic into a context window and a reviewer's head. The if err != nil pattern drew complaints as token waste, though one commenter said models like its mechanical style. A few said gofmt doesn't even fully deliver uniform style, since it won't break long lines.
Sure, it's straight-forward to read, but it's pretty verbose. And agents are good at producing a lot of text. The problem with reviewing go code for me is to see the forest for the trees.
Also Go prioritises local readability over global understandability which is a poor tradeoff for LLMs with limited context windows.
Anecdotes and a vendor pitch
The top comment, from the lead of Netflix's Go guild, said agents write better Go than other languages, based on informal user feedback. Others compared the post to Oreo praising Oreos and noted that one author holds the title Chief Evangelist. The only systematic data offered pointed the other way. A benchmarking group said models do worst with Go and Python, and Tencent's AutoCodeBench put Elixir on top.
No - these are reports from users, not a systematic analysis.
We've seen a pretty consistent pattern in our evaluations where Go is among the languages that models perform worst with (alongside Python), for reasons unclear.
Consensus
Go's built-in formatter, fast compiler, standard library and static binaries are real advantages when agents iterate. Models write routine Go well. Concurrent code is where they fail, in Go and elsewhere.
Dissent
A sizable minority uses Go as their main agent language and reports good results. Examples included Netflix teams, a TinyGo WASM project that shipped only after other languages failed, and bash scripts ported to static binaries. They argue Rust's compile times and borrow-checker fights cost more tokens than Go's weaker types cost in bugs.