Two years of complaining about AI code generation being bad for Go and I think I finally understand the actual problem. It’s not that these tools don’t know Go. It’s that they know generic Go and have no idea how your organization writes Go. Our codebase has internal libraries for almost everything. Custom error types, internal HTTP clients, a telemetry wrapper, internal testing utilities. Generic AI code generation doesn’t know any of it exists. It generates textbook-correct Go that uses the standard library directly everywhere and misses our internal abstractions entirely. Then somebody has to review and refactor the suggestion into something that fits which eliminates most of the productivity gain. The change that made AI code generation useful was switching to a tool that could index our repos and build persistent understanding of our patterns. After a few weeks it started suggesting our internal types correctly, stopped recommending raw net/http when our httpclient wrapper exists, learned our small-interface convention. Acceptance rate went from roughly 20 to 35 percent. More importantly the accepts needing no editing went from almost nothing to most of what we accepted. Concurrency is still hard for these tools. Complex goroutine patterns and anything involving our internal worker pool abstractions still need human authorship. That’s a model reasoning limitation that organizational context doesn’t fix. submitted by /u/Alarming-Hippo4574
Originally posted by u/Alarming-Hippo4574 on r/ArtificialInteligence