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, ...)

Broadly agreed, the concurrent Go code I've gotten out of them has been absolutely riddled with issues, and they're even worse at writing tests for it. They can get tutorial-level code on the first shot almost always... but tutorial-level Go code is often rather unusable in production due to missing error handling or observability.

Go's generics are getting a fairly important improvement soon though! Generic methods, finally! It should help open up some more ergonomic patterns: https://tip.golang.org/doc/go1.27

Ask them to debug. LLMs are acceptable at writing code, but they're really good at spotting bugs in code that's already been written. What kind of results do you get if you tell them to look for bugs with a clean context subagent?

In my experience, LLMs are excellent at finding concurency bugs.