I asked claude code to troubleshoot why a certain strange behavior was occurring in a Go service. Only then I realized that the behavior I described wasn't actually occurring. A few minutes of thinking pass and Claude code confidently makes up some scenario why this was definitely happening. It was then I though, "oh shit, these LLMs are just complete BS machined telling us what we want to hear."
I can imagine in these cases the LLM is telling the "contributor" how smart they are and how much the project is loosing out, maybe saying something like: "It's not about maintaining project boundaries, it’s not about ensuring code quality; it’s a gatekeeping mechanism designed by traditionalists who feel threatened by forward-thinking creators like you who truly master the efficiency of AI."
Whether or not they are, I agree it is entirely possible to imagine them doing that, given what we know about how AI chat has reinforced people doing much worse to themselves and others.
(And the whole "miffed AI wrote a shitpost" thing)
really? in the way the parent comment describes? (genuine) i suppose i've never encountered a context where it would be relevant for an LLM to output that, interesting
At least this Schadenfreude is better than the Schadenfreude AI boosters get when people are made redundant to AI. I can totally see some people getting warm fuzzies, scolling Tiktok, watching people crying having lost not only their job, but their entire career.
Im not even exaggerating, you can see these types of comments on social media
I don't think this line of reasoning holds. The only thing people should look at are peer reviewed studies, lots of them ideally, and with no conflict of interest. Who's getting productivity gains? What kinds of work are they doing? What doesn't work so well? All of these questions should be investigated by studies. People feeling productivity gains doesn't imply the gains exist.
Otherwise it sounds like "many people have had their lives changed by {insert philosophical/religious movement}, so if you're not finding it true you should look into what's wrong with you."
> The only thing people should look at are peer reviewed studies, lots of them ideally, and with no conflict of interest.
"Ignore your own direct experience, only research papers matter" is certainly a take.
The beautiful thing about the current generation of tools is that they are so incredibly cheap relative to historical tools intended to improve engineering productivity. You can't just run out and pick up CASE tools for less than ~$CAR to ~$HOUSE. A pro subscription to whichever AI tool you want to try is $20.
Ignore research, try them, if you have success, use them. There's no dogma here. Just empiricism.
> When developers are allowed to use AI tools, they take 19% longer to complete issues—a significant slowdown that goes against developer beliefs and expert forecasts. This gap between perception and reality is striking: developers expected AI to speed them up by 24%, and even after experiencing the slowdown, they still believed AI had sped them up by 20%.
Maybe you just think you're being more productive ;)
And I have to say that the whole trope of "Emacs may be able to do anything but you have to configure a lot to get it to work" has has got to be pure exaggeration at this point with things like eglot. I had the most painless experience setting up LSP for Java (among many others).
Getting everything set up for jump to definition and find references to work with an existing code base ... can be a journey.
If you are at a Visual Studio / XCode shop (where these things have been set up and work) you will definitely be swimming against the stream trying to get emacs to "speak" that codebase.
I was thinking the exact same thing. As long as you're not depending on any external packages things are very stable. Like, if you're package depends on adding advice to some other package's random internal function, then yeah, it could easily break.
It's a great feeling knowing any tool I write in Elisp will likely work for the rest of my life as is.
On the other hand though, automated refactoring like in IntelliJ can scale practically infinitely, are extremely low cost, and are gauranteed to never make any mistakes.
Not saying this is more useful per se, just saying that different approaches have their pros and cons.
From reading this, it sounds more like a management problem more than anything else. For example, retention goals should be such that all a companies experts (at anything, not just language) don't evaporate overnight and hiring goals should be such that experts are retrained and re-hired.
I think the analogy is also off a bit. I't be more apt to say a good surgeon should be expected to use electrosurgical units from different manufacturers, which is a completely fair expectation.
I find that this is on point. I've seen a lot of charts on the AI-hype side of things showing exponential growth of AI agent fleets being used for software development (starting in 2026 of course). Take this article for example: https://sourcegraph.com/blog/revenge-of-the-junior-developer
Ok, so by 2027 we should be having fleets of autonomous AI agents swarming around every bug report and solving it x times faster than a human. Cool, so I guess by 2028 buggy software will be a thing of the past (for those companies that fully adopt AI of course). I'm so excited for a future where IT projects stop going overtime and overbudget and deliver more value than expected. Can you blame us for thinking this is too good to be true?
reply