this post was submitted on 14 May 2026
237 points (95.8% liked)
Technology
84699 readers
5260 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Well there's the problem.
I'm a software developer and I say that AI is the greatest force-multiplier that's been introduced into the field since the compiler. I love using it, it handles the most tedious and annoying parts of the process. But there are situations I don't want to use it in, and of course being forced to use would give me a more negative opinion of it. Obviously.
I didn’t read this as “people who like it in some situations being forced to use it in other situations,” but rather people who are against it as a whole being forced to use it at all. And yeah those folks are going to have a bad time, and won’t be in their jobs long. Just facts.
As a person who works with coworkers who fully embraced it, it doesn't look like they are any faster. There is one group that is faster, but they don't verify their code and provide burden of it on another person who reviews PR to go through their shit code (sorry, but it is unnecessarily complex, does things in weird ways, I've seen it had bugs that even canceled each other (I guess this is probably due to re-running until things work))
In the late 1980s there was a time where we seriously weighed the option of hand assembly vs using compilers and hand assembly didn't always lose. In the early 1990s I wanted to use C++ but the available compiler for IBM compatible PCs was too buggy to be of value.
By the mid 1990s that had changed, good C compilers were exceeding all but the highest effort human assembly code - if you didn't like how it looked in assembly, you could much more easily "fix it" with a tweak to the C code instead of the assembly. I feel like we're sort of getting there with AI agent LLMs today - if you don't like what it provided, tell it why and let it try again - it's usually faster and easier and gets a better product for the time invested to use the tool instead of calling it a slop box and doing it yourself.
people shit down your throat and you celebrate and beg for more. Absolute clownshow.
There isn’t any credible evidence out there that actually shows LLMs are a “force multiplier.” That is almost certainly just a made up marketing term for unprofitable chatbot companies.
If it's a tool you can use yourself and it makes you more efficient, you don't need a study to recognize its efficiency.
If you're a software engineer, just try it yourself. Your own experience is the best proof you can find to judge if a tool is useful to you or not.
I am a software engineer, and trying it is exactly how I know it is not a “force multiplier.”
Outside of my personal experience—there’s also zero actual evidence it provides anywhere near the benefits it’s marketed as.
Then we have a different experience, and that's fine
In this case the evidence is literally first-hand experience. There is nothing that will change my mind on this because it's my direct personal experience from actual use.
I honestly don't care what marketing says, and if other people have different experiences then that's just them. In my personal actual real-world experience I found that they let me get tons more done and their quality of work is perfectly fine as long as you're using the right tools and giving them the right instructions.
The article says that developers are disagreeing with that in situations where they are "forced" to use AI, and that's fair, it doesn't make sense to force a tool to be used for something it's not good at. They might be using it wrong. I use it whenever it's better than not using it, and that ends up being quite often in my workflow.
The right tools is definitely key. Back an eternity ago, like October 2025, there was only Claude IMO if you wanted anything bigger than about a page of code. The others have come a long way - better than Claude was then, and I still feel like Claude is out in front, though by a less dramatic margin now.
As for "the right instructions" - I'd say it's more of "use the right process" which basically involves applying all those best practices that have developed over the past decades for human development, but we old farts from back before their time "don't need all that, it's a waste of time" because, basically, we internally practice most of the discipline without doing the documentation. With the AI tools: document your requirements, your architecture, tool choice selection process, designs, development plan, comment the code with traceability to why the code is being written, unit and integration tests, reviews, lessons learned, etc. etc. Having all that documentation kept with the project, well organized, is key to "bringing the AI agent up to speed" which you may be doing often. They really do demonstrate the eternal sunshine of the spotless mind, so if you have them take the time to write everything relevant down as they go (not just the code), then when a new one comes online it can jump into the middle of a development plan without repeating (as many) mistakes / making (as many) bad assumptions.
To be brutally honest, working with AI coding agents reminds me a LOT of working with overseas programmer consultants - if you don't get everything in writing you're gonna have a bad time.
Unfortunately your being downvoted by the echo chamber participants that have to make sure you know that your opinion is wrong and theirs is better. AI is a tool, just like my impact gun. Yea there are times where you absolutely should not use an impact gun on something, but it's THE tool for some situations. And yea, using an impact gun where you should t will get you in trouble just like using AI in situations you shouldn't will get you in trouble. There is nothing new on that front!
I don't disagree with the post you are responding to, almost all of that is reasonable.
Your overall argument would be more convincing if it wasn't you doing the exact same thing you are complaining about.
As for specifics , the "Just a tool" argument is meh, not all tools are equal in potential benefit and harm.
Asbestos (while it is a material) was a "tool" used to insulate from heat.
Was it good at that, sure, it probably saved many lives, was it also harmful as fuck in the medium to long term, yes it was.
It can be a useful tool and also be a detriment, those things aren't mutually exclusive.
The danger of a tool can also be mitigated with adequate safeguards that come from experience gained over time.
The argument then becomes risk vs reward, which is an entirely different conversation.
There are way too many ways to use LLMs for programming to make a blanket statement
'Your personal experience is invalid because it goes against the circlejerk'
Did you miss the part about no credible evidence? Feeling like something is a certain way doesn’t make it true.
I kind of agree it's a multiplier. But so far every time I've had it do something its written such an ugly turd I have to rewire it all taking more time than if I'd just solved the problem to start with. Maybe someday but it's not up to the quality I expect of development.
I got a lot of garbage when I didn’t know what I was doing and just tried AI once or twice a week with lazy prompts, expecting perfection without iterations. I’d huff and crow about how I had to fix things, whereas now I just tell it what to fix, or even better how to get it right the first time. I’ve built up my library of skills and prompts and refined them quite a bit. The models keep getting smarter. You should really look at your tools and methods - sounds like you’re stuck in 2024.
I've been using it rather heavily since about October of last year, I definitely do notice the models getting better, the tools around the models starting to do some things automatically that I had to manually prompt for last year (especially remembering key instructions). I also believe I am getting better at using them, how much that contributes to my overall results is extremely hard to quantify, but the feeling is definitely there. Like - last October I used to "just ask" for things without having a documented set of requirements. Today, I just know that the requirements document is necessary when the level of complexity is above... well, above a one-off simple example of how to do something relatively trivial.
It's definitely a force multiplier, it's just that the factor after the X can be less than 1.0.
Have you tried giving it coding standards and other such preferences about how you like your code to be organized? I've found that coding agents can be quite adaptable to various styles, you can put stuff like "try to keep functions less than 100 lines long" or "include assertions validating all function inputs" into your coding agent's general instructions and it'll follow them.
For me, one of the things that's a huge fundamental improvement is telling the agent to create and run unit tests for everything. That way when it does mess up accidentally it can immediately catch the problem and usually fixes it in the same session without further intervention. Unit tests used to be more trouble than they were worth most of the time, now I love them.
After I worked with AI agents a little, I dove in with a big set of coding standards and practices and... I overdid it. I find I get better results by starting off with a "light touch" and letting it do what it wants, then correcting where it gets off track (like using python for something that needs efficient performance...)
You... just started writing unit tests?
No, I've used them plenty before. I just found them to generally be a huge hassle of minimal benefit. They became much more useful in the context of agentic coding, where you want the agent to be able to immediately realize "oh, this change I made causes these specific problems when it's run." The hassle is all on the agent, not on me.
So much this. That hassle on the agent, a few minutes of me waiting for it to crunch out the unit tests, saves me tons of hassle later - not going in circles re-fixing problems that were fixed before.
Same for keeping implementation code and documentation in sync - I've got hundreds of out-of-date wiki pages that simply aren't worth my time to fix. But when it's the agent keeping the docs in sync, just tell it to do it and wait a few minutes - totally worth the effort.
I think we do very different development.
Could be. I'm a professional programmer whose usage runs the whole gamut - large applications with hundreds of programmers working on them for years, smaller apps that I make for my own use, and one-off scripts to do some particular task and then generally throw away afterwards.
I don't do unit tests for that last category, of course. I don't even use coding agents for those, generally speaking - a bit of back-and-forth in a chat interface is usually enough there.
Is this like a who's got a bigger portfolio situation? I'm not sure how to respond
I guess I've been developing for decades including consulting for Page 6, a stint in RD at Sony Music. One of my open source contributions was used as part of the backend for one of Obama's State of the Unions. I spend my time these days writing and maintaining multiple software stacks integrating across multiple platforms.
Since you brought up the notion that we might be doing different styles of development, I was giving you context as to the kinds of development that I do. Sounds like we might not be doing such different scales of development after all, but I couldn't have known that until you gave that information just now.
This isn't supposed to be some kind of duel or argument, I don't see the point of that. I'm just explaining my usage of coding agents and specifically unit tests in that context. Since that's what you were questioning.
I see it seemed more like a weird flex.
Anyways, I couldnt possibly deploy with any confidence a large project or honestly a small project I expected someone to rely on without layers of test. Unintended consequences of even a small change are just a reality. And with the expectation to move quick with large legacy systems, if you don't have tests that's a dangerous high wire act.
In my world, that depends just about entirely upon how "dynamic" the code base is expected to be after release. We send a lot of things into the field, thousands of copies used for important work, which we pretty much know certain aspects of the system are unlikely to be changed once released. Others are very likely to be changed. "Back in the day" we'd make reasoned judgement calls about which ones would benefit from the effort of unit / integration testing and which ones that effort would be better invested elsewhere. As time marches on, our procedures and cross-departmental "advisors" who aren't so cozy with the code are relentlessly pushing for more and more automated testing. It is safer, no argument, but it also delays launch - sometimes without added value IMO.
I meant my first sentence to be an apology for jumping to conclusions but it clearly isn't. It's late. Sorry for the snarky response.
Well, I've seen large projects without extensive unit tests before. The main time I remember a big project with them before coding agents they were largely a checkbox that developers implemented with a grumble when first deploying a new system and then that were slowly disabled one by one as later changes broke them.
These were stand-alone projects, though, with a large QA department and without an expectation of future versions directly descended from them once deployed. If it worked then it worked, that was all that was needed at the end of the day.
never had a large qa team. And my experience has when we have qa resources, people move to the new feature so it's up to the developers to not break the critical features every forgets about until they break. And I've yet to meet a developer that has time to also bee a full time qa resource
Wow what a circlejerk this turned into.
Oh well, I guess that's what everything really is the whole time.
We have ours configured with our coding standards, mcps, and we have a skill library.
It still outputs code full of mistakes. Usually they're minor mistakes, but not always.
When we use it to fix defects, it usually fixes the problem, but not in a very robust way. It still needs a lot of supervision to output quality code.
I'll say that during a recent week where I was forced to use an LLM, I found Claude Opus to be extremely poor at referencing this guide: https://mywiki.wooledge.org/BashPitfalls
it took almost an hour to get Claude to write me a shell script which I considered to be of acceptable quality. It completely hallucinated about several of the points in that guide, requiring me to just go read the guide myself to verify that the language model was falsifying information. That same task would have taken me about 5 minutes.
I believe that GIGO applies here. 99% of shell scripts on the internet are unsafe and terrible (looking at you,
set -euo pipefail), and Claude is much more likely to generate god awful garbage because of the inherent bias present in the training data.And as for unit tests? Imo, anything other than property-based testing is irrelevant. If you're using something like Pydantic, you can auto-generate a LOT of your tests using the rich type annotations available in that library along with hypothesis. I tend to write a testing framework once, and then special case property tests for things that fall outside of my models. None of this is super helpful for big ugly codebases with a lot of inertia around practices, but that's not been my environment, thankfully.
WTF are you expecting Claude to code in bash?
I have found Sonnet and Opus to both be very capable in bash, but then, I don't usually ask bash to do super-complex things - its syntax is just too screwy to think about big applications in it.
I will say, you might be misguiding the LLM by filling it full of bad examples before starting. Kind of like the advice about not staring at a tree downslope while skiing, if you're fixated on it you're MORE likely to hit it.
I gave it no advice, and all I wanted it to do was generate a script to tell me the file type of the newest file in a directory. It was a very trivial piece of code. Each time it generated something I disliked, I told it "don't do this, reference this guide for the correct thing to do," or "don't do that, do it in such a way that X happens." It was like 20 lines of bash in the end.
I was expecting it to write me a bash script because that's the example that everyone, without fail, says will work well. "I just used Claude to write a little throwaway script to move some files around" were the exact words a colleague used.
Bash is a shitty, unsafe language. I don't write large programs in it. I expect "throwaway scripts" to still be written in a way that defends against all of the innumerable shitass foot guns present in the language. Claude was incapable of doing this in a reasonable time frame.
I also dislike the Python and Go it generated, while we're at it. It produces overly verbose, overly documented, poorly performing code. It was also fucking dog shit at referencing runbooks and documentation in a local folder when I was on call and responding to alerts.
I'm glad it's been such a great help to you. I did not find it to be particularly helpful for me. It was very good at putting me in a sour mood, however.
There's the problem with your expectations. You may be able to follow your little guide to bash problems and "best practices" but defending against the innumerable shitass footguns present in bash is not a task that can be accomplished by anybody in a reasonable timeframe...
I wasn't so thrilled with Claude in the October 2025 timeframe - Opus was slow and costly and wrote un-necessarily weird solutions for simple problems, Sonnet would still get caught in bug-fix creates new bug loops. It (and the other models like Gemini, GPT, etc.) has improved, significantly, since then. Back then it wasn't hard to "make the tool look bad." It's still not too hard to make the tools look bad today if you try, but it is much easier for me to make them look good.
I, too, would be more sour mood if I hated the tools and still had to be demonstrating to management "how we're going to leverage AI for software development" - which is on our goals this year.
Why not just give it shellcheck and have it run that on every script it creates?
Shellcheck, while good, doesn't capture all best practices in my opinion. There are many items in that doc which shellcheck would happily allow, worst of all being
set -euo pipefail.Sounds like you were writing bad unit tests and AI showed you how to do it right.
If so, it was project-wide across hundreds of devs.
There was a time when nobody wrote unit tests, not so long ago, really.
It lets me focus on the software architecture, not the minutiae. It feels exactly like when I ran a team of brand new interns. They require a lot of hand holding but with the right direction they get good at their jobs very fast.
I think the problem is that for now, it will always continue to require that hand-holding, whereas interns/new programmers will need less and less over time and become more independent over time
I find that I get the best results when I develop a suite of documents in parallel with the code: requirements, architecture, designs, lessons learned, indexes into those documents, traceable ID tags on atomic, testable item descriptions. Development plans. When a new agent is introduced to the project, it can "get up to speed quickly" by jumping to the current working point on the development plan and indexing into all the relevant details in the other documents before even starting to read the existing code.
That working method itself is evolving, and each new LLM driven project builds on the previous successful projects' processes...