Google's developer blog published an argument this week that Go is the ideal language for AI-assisted software engineering (the post, 430 points and 509 comments on Hacker News). The thesis is seductive: when AI generates code, the bottleneck shifts from writing to reviewing, and Go's platform, with its built-in formatter, test framework, dependency management, and security tooling, makes review cheap. "A language that is clear for humans is inherently clear for AI models," the post argues.
I read the whole thing, then I read the 500-comment thread that pushed back on it. I am a Senior Software Engineer II at BS23 in Dhaka, and I have been building production AI systems with Spring Boot and Spring AI for over a year. My daily driver is Java, not Go, and I think Google's argument is half right. The half that is right matters a lot. The half that is wrong is a marketing move dressed as a technical law.
The core claim is correct, and it is the most important sentence in the post: the rate-limiting step in AI-assisted development has shifted from generation to verification. An agent can emit hundreds of lines of syntactically valid code in seconds. The bottleneck is now the human loop that reads, verifies, and maintains that code, and any language that makes that loop cheaper wins in the AI era.
Go genuinely has strengths here:
gofmt
is the single formatter, enforced by the community and by CI. Every Go codebase looks like every other Go codebase. For an AI model trained on Go, that uniformity is a gift, and for a human reviewer, predictability means faster pattern-matching.The HN thread found the weak points. A commenter who leads the Go language guild at Netflix confirmed the positive side: teams report their AI agents writing better Go than other languages. But the dissent was louder and sharper:
That last point is worth sitting with. One of the post's authors is Cameron Balahan, Group Product Manager for Go at Google. Of course Go is ideal, from the person who sells Go. The honest test is whether the argument survives contact with a language whose type system does what the commenters are asking for.
This is where my stack pushes back. Java's modern type system is substantially stronger than Go's for the exact failure mode the HN thread identified, and it got stronger in exactly the releases an AI assistant will target:
record
requires every field in its canonical constructor. You cannot partially construct one. The AI cannot generate a ShoppingOrder
with a missing customerId
, because the compiler will refuse. That is the "not a valid Widget" check Go's commenters said they wanted. The contrast is sharp when you write both:
// Java: the compiler enforces the shape
public record ShoppingOrder(String customerId, List<OrderItem> items, BigDecimal total) {}
// Go: the compiler accepts a partially built struct
type ShoppingOrder struct {
CustomerID string
Items []OrderItem
Total float64
}
// order := ShoppingOrder{Items: items} // compiles, Total is zero
The Java version cannot exist without its three fields. The Go version can, and an AI model that does not know the domain rules will happily emit the half-built one. That is the entire guardrail argument in one pair of examples.
The honest admission goes the other way too. Java's compile loop is slower than Go's, and Go's single formatter is genuinely simpler than the Java formatting story, which still involves a choice between Spotless, google-java-format, and editor conventions. And Spring AI, the framework I actually build on, is Java's own answer to the "clear for humans, clear for AI" claim: the tool-calling API, the evaluator interfaces, and the observability hooks give an agent a rigid structure to generate against.
Strip away the Go marketing and the Java defensiveness, and the thread converges on a real principle: the best language for AI-assisted work is the one whose toolchain enforces structure the AI cannot skip. Fast compilers, exhaustive type checks, one blessed formatter, strong defaults, and a review loop that catches what the model gets wrong.
Go has the formatter and the speed. Java has the type system and the framework depth. Neither is "the" answer, because the answer is a stack, not a language. The teams winning at AI-assisted development are not the ones who switched languages. They are the ones who wired their agents into a strict toolchain: tests that run on every generated change, formatting enforced in CI, type systems that refuse half-built objects, and a review culture that treats the agent as a fast junior who needs guardrails, not as an oracle.
The comment that got closest to the truth was the most direct: "Who cares? Languages are tools, LLMs are tools. Use the ones more appropriate for what you are trying to do." If you are shipping a network daemon or a CLI where uniformity and compile speed dominate, Go is a great choice, and the AI will write it well. If you are shipping a long-lived business system with domain invariants, records, sealed hierarchies, and a framework that models agents natively, Java earns its ceremony.
I use Java every day, and this post made me reconsider exactly one thing: whether my team's formatting and review loops are as disciplined as Go's community is by default. That is the real takeaway, and it has nothing to do with switching languages.
Which language do your AI agents write best in, and is it the language your toolchain constrains most tightly, or the one you like most? I read every response.
I write about Java, Spring Boot, and AI agents every week. Subscribe, it's free.
Bookmark this one. The next time someone tells you their language is the AI language, ask them what happens when the compiler meets a half-built object.