What Go Programmers Think of AI (go.dev)
- Reference: 0180717972
- News link: https://developers.slashdot.org/story/26/02/02/015206/what-go-programmers-think-of-ai
- Source link: https://go.dev/blog/survey2025
But the survey also found that among Go developers using AI-powered tools, "their satisfaction with these tools is middling due, in part, to quality concerns."
> Our survey suggests bifurcated adoption — while a majority of respondents (53%) said they use such tools daily, there is also a large group (29%) who do not use these at all, or only used them a few times during the past month. We expected this to negatively correlate with age or development experience, but were unable to find strong evidence supporting this theory except for very new developers: respondents with less than one year of professional development experience (not specific to Go) did report more AI use than every other cohort, but this group only represented 2% of survey respondents. At this time, agentic use of AI-powered tools appears nascent among Go developers, with only 17% of respondents saying this is their primary way of using such tools, though a larger group (40%) are occasionally trying agentic modes of operation...
>
> We also asked about overall satisfaction with AI-powered development tools. A majority (55%) reported being satisfied, but this was heavily weighted towards the "Somewhat satisfied" category (42%) vs. the "Very satisfied" group (13%)... [D]eveloper sentiment towards them remains much softer than towards more established tooling (among Go developers, at least). 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.
>
> The most frequently cited benefits, conversely, were generating unit tests, writing boilerplate code, enhanced autocompletion, refactoring, and documentation generation. These appear to be cases where code quality is perceived as less critical, tipping the balance in favor of letting AI take the first pass at a task. That said, respondents also told us the AI-generated code in these successful cases still required careful review (and often, corrections), as it can be buggy, insecure, or lack context... [One developer said reviewing AI-generated code was so mentally taxing that it "kills the productivity potential".]
>
> Of all the tasks we asked about, "Writing code" was the most bifurcated, with 66% of respondents already or hoping to soon use AI for this, while 1/4 of respondents didn't want AI involved at all. Open-ended responses suggest developers primarily use this for toilsome, repetitive code, and continue to have concerns about the quality of AI-generated code.
Most respondents also said they "are not currently building AI-powered features into the Go software they work on (78%)," the surveyors report, "with 2/3 reporting that their software does not use AI functionality at all (66%)."
> This appears to be a decrease in production-related AI usage year-over-year; in 2024, 59% of respondents were not involved in AI feature work, while 39% indicated some level of involvement. That marks a shift of 14 points away from building AI-powered systems among survey respondents, and may reflect some natural pullback from the early hype around AI-powered applications: it's plausible that lots of folks tried to see what they could do with this technology during its initial rollout, with some proportion deciding against further exploration (at least at this time).
>
> Among respondents who are building AI- or LLM-powered functionality, the most common use case was to create summaries of existing content (45%). Overall, however, there was little difference between most uses, with between 28% — 33% of respondents adding AI functionality to support classification, generation, solution identification, chatbots, and software development.
[1] https://go.dev/blog/survey2025
My own opinion, take with salt and more salt (Score:2)
I have spent the last 2 weeks really getting into CoPilot for helping write code, (python specifically). I am very fluent in Python, and have been for awhile. I give a shit about architecture, clean/simple code, data types, and can pass my stuff through mypy and it passes.
I started two greenfield projects - one for embedded development and one for math modeling using numpy and python, (C was a long time ago for me, and I am not deeply familiar with numpy, but I have knowledge of calculus and advanced
Re: (Score:2)
I hope you do not plan to give that code any publicly available interfaces. Because LLMs are absolute crap at writing secure code. Probably because most people that proudly put their code on the net as "examples" are too.
Re: (Score:2)
> I hope you do not plan to give that code any publicly available interfaces. Because LLMs are absolute crap at writing secure code. Probably because most people that proudly put their code on the net as "examples" are too.
If I was going to give a public interface to anything, it's going to go through the same process that I have been using for a number of years now - a templated design that has been tested/pentested/tested again for holes. And these days, it will likely be behind an AWS api gateway as well if we're talking about internet-facing apis. It won't be some EC2 instance with a public ip and a sec group of 80 -> 0.0.0.0/0.
I should have added in my original post that I feel AI tools can be very useful in th
Re: (Score:2)
I see you are being careful. Good. Careful and competent people can be trusted with any tool.
I had a student look at how well LLMs do with security (including several paid ones up to around the $100 tier) and the results for anything that matters (security-patch level or CVE level) are pretty bad. If code is well isolated, that matters not that much, unless it is something high profile with a lot of visibility.
That unmaintainable app will provide an interesting lesson. Fixing complex code is typically more
Re: (Score:1)
This reflects my experience as well. It really lowers the bar of entry for much of technical work. It suits well when the cost of trying it out is nothing.
It can help learning a lot if it does not replace thinking. It can be an extremely kind and patient tutor, useful even if it is sometimes wrong.
If you write a program even a fool can use (Score:2)
Only a fool would want to.
Re: (Score:2)
To be fair, there are tons of fools around. The very AI hype currently going shows that nicely. Or the 8 or so previous, equally mindless AI hypes. Although they were smaller and did not have a global economic crash at their end.
So search and copy & paste? (Score:2)
What a great win for AI! Go info would be just as fast to look up directly (but no hallucination), and cut & paste needs care anyways. Better write a function.
Sounds like an entirely redundant use that will fall into "slightly faster .... slightly slower" and in no way even remotely justifies the effort that goes into LLMs. Or the risks, because that AI generated code may well not have copyright, may leak and may have hallucinations in it. Or, worse, attack code from model poisoning. And the module info
All your base will belong to AI (Score:2, Insightful)
I've been in this business for over 30 years. The output of Claude Code is orders of magnitude cheaper than consultants, employees, even the lowly off-shore developers working for peanuts.
It doesn't matter what programming language. It doesn't matter what application. The platform is irrelevant. The complexity is even less of a factor. This isn't hype or fear; it's the new reality.
The last IT skill all you guys may ever learn is how to wield AI.
Re: (Score:2)
It's the customer that drives that. Back in the 90s, a friend of mine worked at a textile factory in North Carolina. They were producing high quality fabric at $20 a pound. The Asians were offering slightly lower quality "good enough" fabric at $4 a pound. What did the consumer choose? Take a guess. Don't bitch at the manufacturer, bitch at the consumer preference. You see two products on the shelf one is cheaper and you know it sacrifices quality. You don't care.
Buy Once, Cry Once. (Score:2)
> You see two products on the shelf one is cheaper and you know it sacrifices quality. You don't care.
Most don't care.
Those that do care often enjoy the kind of quality and benefit that infers buy once, cry once. Constantly replacing even "cheap" items makes them not cheap. Inflation is a bitch when you consider *anything* you bought last century and are now buying again is twice as expensive. Multiply that across a lifetime and you can really start to find respect a product built and guaranteed for life. Including the price.
I wonder who might still be using high quality North Carolina fabric, and who
Re: (Score:2)
I think the argument is that the AI assistant is so cheap it is worth using even if it is not better than the human. So cheap it even compares favourably to a totally free intern, in that an AI assistant is available 24/7, does not complain, quit, is not temperamental nor hard to manage. Both make stupid mistakes, but the AI is more consistent along time, such that after an habituation period you can depend on it within usefulness boundaries you come to establish.
Re: (Score:1)
Current AI prices are all deceiving, since AI hasn't entered the shareholder value maximising phase, quite the opposite. It won't be exactly cheap when the enshittification starts. It will still be cheaper than real developers.
Re: (Score:2)
The big problem will not be how many mistakes it makes, but if you can explain some feature to it.
Something I have been noticing in a lot of AI generated media, it can be visually impressive, but once someone actually tries to use it to tell a story, even a simple one, they find they can't control it well enough to actually produce what they want.
Ai generated stuff is great when you don't care what it produces because you just need _something_ that is close.. but as Ai researchers have known long before t
Re: (Score:2)
> I notice that you said the output of Claude is cheaper, not better. Thank you mister clueless pointy-haired boss who doesn't care if your company produces shit code and shit products, as long as it is "cheaper".
Thank Microsoft, for writing The Billionaire's Guide to Suck-cess?
Thank the consumer, who kept buying it? Like, every time?
How many more thanks across the face would you like? Feels like you're standing next to two sheiks arguing over a Cannonball Run.
Re: All your base will belong to AI (Score:3)
Claude can refactor your code a lot faster than you can correct your attitude, Mister Anonymous.
Deal with it.
Re: (Score:2)
This is important:
> (e.g., learning how to use a module) or toiling (e.g., writing repetitive blocks of similar code)
They use the LLM for learning and for rote work. This is perfect for Go. Go means favoring simplicity over higher level concepts. Like English at elementary school level instead of college level. Most languages have macros, generic types and union types. Go philosophy is "these concepts take too long to learn". Favor long code over concise code. Repeat yourself, often. Fix the same bug, often.
> The complexity is even less of a factor. This isn't hype or fear; it's the new reality.
Welcome to Go. Welcome to 2009.
Re: (Score:2)
You said that correctly, "cheaper" as in "cheaply (and hence badly) made".
Yes, LLMs allow you to make code even cheaper. But you still only get what you pay for. They are not magic. I do get that many people really do not get the idea of "quality" and how not having it ruins you in the longer term.
Also note that LLM-type AI is bound to be come A LOT more expensive in the near future, after the inevitable crash from the utterly catastrophic business stats.
Re: All your base will belong to AI (Score:2)
Correction: Management and orchestration are all that will be left. ./npx get-shit-done-cc
For a glimpse of what's to come.