Developing With Ai

- Broadly speaking, Go developers asked for help with identifying and applying best practices, making the most of the standard library, and expanding the language and built-in tooling with more modern capabilities. - Most Go developers are now using AI-powered development tools when seeking information (e.g., learning how to use a module) or toiling (e.g., writing repetitive blocks of similar code), but their satisfaction with these tools is middling due, in part, to quality concerns. … In that spirit, this year’s top challenges are not radically different from last year’s. The top three frustrations respondents reported were “Ensuring our Go code follows best practices / Go idioms” (33% of respondents), “A feature I value from another language isn’t part of Go” (28%), and “Finding trustworthy Go modules and packages” (26%). We examined open-text responses to better understand what people meant. Let’s take a minute to dig into each. Respondents who were most frustrated by writing idiomatic Go were often looking for more official guidance, as well as tooling support to help enforce this guidance in their codebase. As in prior surveys, questions about how to structure Go projects were also a common theme. For example: … The second major category of frustrations were language features that developers enjoyed working with in other ecosystems. These open-text comments largely focused on error handling and reporting patterns, enums and sum types, nil pointer safety, and general expressivity / verbosity: … > pointer, or using a value without checking the err first. ... > “I often find it hard to build abstractions and to provide clear intention > to the future readers of my code.” — Somewhat dissatisfied / < 3 years / Technology The third major frustration was finding trustworthy Go modules. Respondents often described two aspects to this problem. One is that they considered many 3rd-party modules to be of marginal quality, making it hard for really good modules to stand out. The second is identifying which modules are commonly used and under which types of conditions (including recent trends over time). … > “Being able to filter by criteria like stable version, number of users and ... Respondents told us that except for `go test`, between 15% – 25% of them felt they “often needed to review documentation” with working with these tools. This was surprising, especially for commonly-used subcommands like `build` and `run`. Common reasons included remembering specific flags, understanding what different options do, and navigating the help system itself. Participants also confirmed that infrequent use was one reason for frustration, but navigating and parsing command help appears to be the underlying cause. In other words, we all expect to need to review documentation sometimes, but we don’t expect to need help navigating the documentation system itself. As on respondent described their journey: ... What is driving this lower rate of satisfaction? In a word: quality. We asked respondents to tell us something good they’ve accomplished with these tools, as well as something that didn’t work out well. A majority said that creating non-functional code was their primary problem with AI developer tools (53%), with 30% lamenting that even working code was of poor quality. … They can explain code effectively but > struggle to generate new, complex features” — Somewhat satisfied / 3 – 10 years / Retail and consumer goods