upvote
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

reply
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.

reply
Debugging concurrency issues isn't a syntactic process so they have to resort to println debugging. This works but isn't exhaustive and burns a lot of tokens.
reply
They do a fantastic job just by inspecting the source. It's obviously not exhaustive, but it's quite good.

Test it on your last concurrency bug. Point fable at the rough symptoms and ask to find where the issue is by inspection. It'll probably do just fine.

reply