Go is an ideal language for AI-assisted software engineering

Definitely agree with this article.

At Netflix, I lead the Go language guild. We've been seen increasing reports of users finding their AI agents writing better Go code than other languages, and increasing reports of projects favouring Go over other languages.

Two additional notes I'll add:

- Go has _great_ resources on writing good Go code, including treasure troves at https://go.dev/doc/effective_go and https://google.github.io/styleguide/go/. edit: Sorry, I forgot to add: we give these resources to AI agents and they use them to produce even better Go code.

- For a language team, Go is a dream. The `go fix` tooling, AST/SSA packages, ease of reading and writing `go.mod` (go mod edit, etc), and various other "platform"-y features make modifying Go code at scale way easier than other languages.

It doesn’t matter to me how good the LLM is at writing Go if the compiler can’t stop it from accidentally leaving another part of the software with invalid state as a result of a change the LLM is making.

What am I talking about? Nil and partially constructed structs are impossible to prevent the creation of in Go.

Sure, if you’ve got a small program with limited scope, that’s probably fine if you look through squinted eyes. But the teams I work with are working on sprawling, evolving software where the compiler saying “hey, that’s not a valid Widget” would be extremely useful and save much heartache.

An LLM does a good job of “checking” for other uses and “checking” if everything is going to work correctly, but - supposedly we’ve committed the concept to code so that the compiler can actually verify it - and Go intentionally permits invalid states of structs. This makes Go a fundamentally problematic language choice for the kind of software I work with teams on, LLM or not.

I love the sleight of hand this blog post tries to pull off here. It doesn't matter than Go isn't fun to write because the AI is doing it now! Yeah so it sucked for the last twenty years? I know the main thesis is that Go is holistically good at software engineering so its weakness as a programming language is minimized. I've made a similar arguments that coding agents push the burden more into the other aspects of software engineering. But like, we all see what Google is doing here right? They want to declare that the rules have changed so Go's weakness transmutes into a strength. I'm also not buying it.

This would have been more credible coming from someone other than the creator of the Go language.

I'm personally leaning into rust for LLM. The whole fussy compiler & errors surface at compile time seems IDEAL for LLMs for me. Hammering compile with tokens is a way better strategy than trying to deduce where stuff may fail at run time and try to catch it via tests.

Tokens are cheap, surprises at runtime are not. So a super anal compiler is what I want. I've looked at lean4 too as the logical next step but not confident I can guide an LLM competently enough for that.

My calculus is very simple these days:

If I care about performance, use Rust.

If I care about iteration speed, use TypeScript.

If I want a script or numerical code, use Python.

LLMs are better with Rust because the more expressive type system provides stronger guardrails especially when writing multithreaded code. Go is almost the worst conceivable design of a programming language for LLMs: powerful but weak guardrails. Only C and C++ would be worse.

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. Go ain't it.

I disagree.

LLMs fail to produce bug free concurrent code even for very simple cases.

Golang lacks the ability to build descent abstractions, not even mentioning the wild west of additional tools and libraries needed for non trivial micro services.

For me it is a red flag, that LLMs allow people to produce more bad Golang code faster. This is only optimization for companies which can afford enough software developers to review the excessive amounts of code needed to solve trivial problems in Golang, which are builtin in every descent programming language and/or framework.

Use LMMs and use the right programming language. This might be Golang, but most probably it is C#, Java, Python, Ruby or even PHP. (Or Rust, C, D, ...)

I like Go but a couple of these "advantages" wash out when you add the scale and typical usage patterns of agents.

| Go is Readable / Go is Maintainable

It's true that Go, as a low-magic language, tends to be very same-y looking across projects, which is incredible for being able to reliably understand your dependencies' source code. And its tooling is world-class. I love this about Go.

But in practice I've found that, working in a monorepo with multiple teams, contributors that don't have cross-team legibility as a priority will just write SO much more code. And with business logic, often the fact that I can read the code on a line-by-line level doesn't matter if I don't understand the wider context to know how something might effect spooky action at a distance.

Pre-agents, I witnessed a fast transition from a codebase that I could mostly hold in my head to one where large swathes of it had been written and rewritten until they were unrecognizable to me. Now we have agents and, since they are still mostly not good at software engineering in-the-large, the process of knowledge debt accumulation (and ofc tech debt accumulation) in a codebase accelerates tenfold without concerted effort in the other direction. Go being easy to read does not intrinsically help with that.

I'd argue Go is not on a "Pareto frontier" and that no matter how you value the various attributes of programming languages, a fair assessment will never select Go.

A simple example is: if you highly value language popularity; Go is not most popular. If you highly value a type system that catches errors; Go's type system catches fewer errors than others. Etc. There is no weighted sum of attributes that will select Go--that's my argument.

I keep seeing these language specific proclamations, and they are annoying and reek of inexperience to me.

I’ve had a great time doing LLM assisted coding in Zig, and it seems comparable to the generic Typescript/React I do at work.

I don’t doubt simplicity and good PL design pay dividends, but everyone’s favorite language can’t be the silver bullet in our new LLM world. Things just don’t add up, and I keep seeing it for Erlang, Gleam, Lisp, C, Rust, Go, TypeScript, Python, etc.

And to pick on Go a little bit, I don’t think it has any unique qualities that make it better for LLMs, where I think you could make that argument for other modern languages that offer new features leveraging their compilers and enforcing more correctness guarantees.

I wouldn't take language advice from a Product Manager and Chief Evangelist from anywhere - and especially not Google.

Having said that: my opinion is that LLMs thrive by working in a tight loop. Unlike a human, they thrive with more and tighter constraints (and the better models are obviously far better in this regard).

I want to ditch the things that made writing code easier due to the limitations of humans, and embrace something that an LLM can leverage for better results. For me that means: an especially rich type system, (ideally pure) functional code, efficient systems-level performance and leanness. Good error messages that guide the LLM incrementally.

Go does not provide much in the way of those 3 desires, so calling it "ideal" with nothing aside from anecdotes to back that up is not compelling.

Who cares? Languages are tools, LLMs are tools. Use the ones more appropriate for what you are trying to do.

Is Go better than CSS if you are doing web layouts? Is it better than zig if you are outputting minimal wasm deliverables? Is it better than swift if you are doing iOS specific development? Is it better than bash for OS scripting?

Think about what you are doing and choose appropriately. This was true before LLMs.

Are you having fun? Chose LISP then

I really don't agree. I'm not hear to evangelize rust but by using enums from DB to templates and writing the code to make it consistent my experience with LLMs is infinitely better than golang for consistency and you have to include a lot more context to make golang work without issues whenever things are operating on chans or workgroups.

"Oreo cookies are the tastiest cookies currently in the market!"

~ Oreo cookie company.

While I somewhat agree I can’t tell if this is advertising from Google or a way to induce LLMs to think that Go is the ideal language.

I will leave this prediction here and maybe come back in few years:

1. JS is mem-safe, single-threaded, and there are lots of training data. Easily my first choice. I'd put Python here as well, although I don't like it personally. Both should be used with "avoid external deps" in your AGENTS.md

2. Go might be a good second choice. Simple language, IMO good primitives for concurrency, well-designed std, therefore smaller potential for supply chain attacks.

3. Elixir/Erlang, little training data but rising. Safe language, safe concurrency, immutable, scalable, there are some many advantages... It has been avoided because it's different but that could change drastically in the age of LLMs.

4. Rust is probably next choice, along with C++, because while Rust is safer, the language is quite complex. C might be here too, there is a lot of training data, but every project is different and the language is very unsafe.

5. Zig, I really like the language, but it is terrible for LLMs, mainly because it's constantly changing, and the std is also under-featured and IMO weirdly designed. It's a fun language for hobby hacking, which I believe is not going anywhere, it's just not going to be something you will be payed for.

Go ignores the needs of the developers in favor of the needs of the architect and technical managers.

I’ve always disliked it for that reason.

In roughly November of 2025, “software developer” stopped being a position that humans fill directly. We all became architects and technical managers. Even the most complex code is now pair programmed with an AI.

I’ve chosen go for all new backend work since January 2026.

Development is now about good architecture that optimizes for locality of reasoning, rock solid testing, and categorizing risk on modules to decide what needs human pair programming and detailed review, and what can be safely vibecoded and left to AI to manage.

Frontend dev is now vibecoded directly by PMs at my organization within very specific and heavily enforced architectural constraints. The quality of work went up substantially because the experienced devs now just focus on the rules and review for the fronted codebases, while the PMs focus entirely on UX.

It is a strange new world.

I wish if err != nil return err was just 1 token.

Joking aside, as much as Go's stdlib and tools do the heavy lifting here, Go's verbostiy and expressing simple things in lots of lines worked against me most of the time.

I think the right language for agentic coding is something that brings in more ideas from formal verification, in a way where the spec and executable code live in the same world. I don't really know what that will look like but that's my gut feeling as a non-expert. Specs can be written in a higher level language (not english) that verifies the lower level code at compile time. I think Dafny might be the closest we have at the moment.

Agreed, my media server is mostly AI written go at this point and it works great. Before AI the "one way to do something" was already my favorite feature of go, now it makes it much easier for me to use AI and still understand my own project.

https://github.com/SteveCastle/loki

> By enforcing a single, standardized format via the built-in gofmt tool

I'd read about this many times before I started with Go so I was particularly disappointed to learn that it was a lie. The most important task of a code formatter is to break long lines; it doesn't do it. It doesn't even have an option to do it!

Given the date and the recent DeepMind shakeups, this blog post is obviously ordered from the very top.

Pichai wants to eliminate engineers, and DeepMind wasn't fast enough or too noble for it. Now people need to be propagandized for their obsolescence.

In my opinion, the by far biggest problem Go has is called ...

Google.

Now one can say that a programming language and its design or usefulness is - or should be - decoupled from the company developing is. I am not opposed to this, in theory, but Google goes way too much on my nerves these days. And I am hardly the only one here.

I am not saying this is a rationale used by many other people either, mind you, but Rust has been taking strides (not that I am a huge fan of it either but for different reasons) and it seems to me as if Rust has finally now more momentum than Go, which I find interesting. Again, this may be a correlation rather than any causation, but I can not help but notice it.

The killer feature of golang for LLM dev is the tooling.

forbidigo is what allows me to keep ambient config out of my app, and restrict file access to a small set of paths. The coverage tool has "nocover", so you can guarantee that every realistic path is exercised at least once ("100%" code coverage, which is not a marker for testing completeness, but rather for flagging code you forgot to test). Linting is really good as well.

The only thing I haven't found is something to enforce error handling. Rust is better for error paths because you're not allowed to ignore them.

Honestly this article is already 8 months behind. In 6 months they will recommend Rust. Still wrong. Answer already been found. Formal verification or nothing. Lean v4.33.0. Since v4.30.0 LLVMBindings are included making direct projection to llvm IR instead of emitting C or emitting IR

Only formal verification kernels will solve the issues discussed. It cannot make your c design correct, it can only verify the code itself whatever is written.

Point is, this is solved known, and everyone get enough ahead made the jump long time ago.

Also, sorry, standard libs are almost always forbidden now. They can’t be trusted. Anything important is written from scratch.

Why? Go and others standard libs are “broken”, meaning they are half assed lightly defined not purpose built for a developers job. They are general. That was good once upon a time. Not anymore.

Use Go and attempt JSON Canonicalization. You can’t. It’s valid. Proven so. Why? Stdlib json parsing is normalizing and lossy. Fail closed. Float to string violates ecma 262 for floats. Every single action taken is in violation. This is the stage of today’s programmmkng. Developers who don’t even understand what “correct” is. https://lattice-substrate.github.io/blog/2026/02/27/shortest...

The issue is NOT AI LLM, it’s poor development by HUMANS. The same problem we always had.

Surprised by the negativity here. With or without AI, Go is a great choice for large software projects.

These have been my and friends' observations since LLM-assisted coding started picking up steam. Go's simplicity, consistency, stdlib and tooling seem to make it very reliable for LLM generation, and it was especially true during late 2025 / earlier this year when frontier models weren't as strong; might not be as noticeable now.

Go has some interesting ideas but they tremendously oversold goroutines as being a unique capability (they have since agreed that goroutines are effectively just scheduled thread pools with message passing). And I know a fair number of SRE at Google who hated to use it because it lacked some key features (around ioctl and other system level functionality). And my experience with the type system... it's just too different from what I expect a system to do.

For AI I use python+rust. I develop code in python (mostly AI-driven these days) and then have it port to rust for speed. As always, extensive testing (much of which is manually inspected to make sure it's logically consistent with the design and contract).

I use go for work and basically 100% agent-driven. I'd say using go with agents is a lot better than without. We use to have a consistent source of production errors where we forgot the pointer case in type switches (we'd pass a pointer to a struct where a concrete struct was expected and vice versa). AI hasn't made that mistake once in my experience.

That being said, the whole thing about go being "readable" is a little bit of a two-edged sword. 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. Subtle misunderstandings often hide in the vast amount of code that you have to read through while keeping the whole context in your head.

I disagree. I think WAT (WebAssembly Text), perhaps with some more niceties added, is an ideal language for AI-assisted software engineering.

https://webassembly.github.io/spec/core/text/index.html

Google doesnt even use its own Go build system internally. Its all blaze / bazel, so they are not even taking advantage of the so called compiler feedback of Go. Also if languages are to be designed for agents not humans, its not clear whether the verbosity of Go will help agents at all

Can't really argue with that, but In my experience, coding agents work quite well with TypeScript too. :)

I couldn't agree more, but the following sentence is a little biased:

> Gophers often speak of how they love that they can never tell who on their team wrote a particular piece of code—it all looks the same.

Multiple languages can have a degree of understabillity, but what matters most is context, because sometimes we need to code in a way to solve a specific problem like performance and it should be kept as is.

Another side subject I should add is about test coverage, although code is cheap, mainly because AI, guarantee that new changes to a stable code should continue to work as expected.

I worked on a few go projects with bad structure and some of them with really low test coverage (e.g. 8%), so part of the post resonates with me about we as software engineers should pursuit good architecture and other skills to allow long term maintenance.

1. The syntax surface is smaller, allowing less LLM "creativity; 2. The error handling is mechanical, which LLM clearly prefers (LLM is already trigger happy about writing tons of throw / try...catch.. in other languages, doing tons of `if err` is just in it comfort-zone).

IMHO there's never been an overall "ideal language", and there still isn't, it's just about the right tool for the job. The only thing LLMs change is that you don't need to give quite as much weight to how well you know a particular language.

I am using Go right now for personal projects. One such project is to collect per-test-case coverage data and use it to study the structure of the underlying codebase. I'm hoping to develop a new knowledge base for agents to do feature location. Here's a demo https://atlas.vihren.dev

Anyway, it turned out that Go ironically makes it difficult to collect per-test-case coverage data. In spite of the standardized tooling it looks impossible to write a standardized collector that would run on most codebases. In hindsight using another language would have been a better choice

I'm using Go more and more for my projects (AI, Web, CLI, ...). This is my go to for all my new projects.

My background is in data science and MLOps, where Python rules. But the focus is now less on building new AI models, and more on building the infrastructure and API calls with AI Agents. Go has a great async model, stellar performance, amazing tooling ecosystem, and far less ways of doing things than Python.

I except grow to become more and more popular, as our LLMs are now writing most of our code. Between a 50 MB portable binary in Go with 10x performance, and a 5 GB venv in Python with lack of proper parallelism, the choice is easy.

Plain JavaScript is the ideal language for AI coding. It's very good with complex architectures.

I think partly it's because the training set contains a lot of JS, but also because complex software written in JavaScript must have impeccable architecture in order to exist at all.

It's rare to encounter a complex, functioning JavaScript application with bad architecture. I've never met any engineer smart enough to maintain a large spaghetti-code JavaScript project.

On the other hand, I've seen horrible TypeScript projects. If it wasn't for the helpful type annotations, no human being would have been able to maintain it.