this post was submitted on 09 Jul 2026
27 points (88.6% liked)
Programming
27651 readers
144 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I mean - define "non-trivial"? Do you want it to create an entire OS kernel from scratch based on a single prompt? Not gonna happen and nobody should expect it to. But it can generate rather complex parts of an application quite well and much faster than you can.
An experienced programmer who could actually review the code produced by a LLM, won’t be able to do so at the speed the LLM writes it.
What’s your solution to avoid slop in this scenario?
You're going to need to review any code you and other members of your team write anyway. Or are you just skipping code review? If so then you're already vibe-coding old-school. Reviewing others code and soliciting feedback on your own is an integral part of software development.
And I dispute the whole "it's harder to read code than to write it" thing. It's a helpful aphorism to get Jr. devs to write good code because you can certainly make your life a lot harder by writing bad code (hint: an LLM can help you understand that 15-yr old code that some apprentice wrote).
But code review doesn't generally take twice as long as it took the developer to create the PR to begin with. Why is that? Because the developer who worked on the code had to solve a bunch of problems, fix bugs they wrote, etc. as you pointed out. The LLM helps with all that as well and the "code, test, fix" loop is a lot shorter. Finding "all those places where I need to make this change" is a lot easier. Refactoring code is a lot easier. Debugging code is easier. Looking up documentation is easier.
I do understand your frustration though - I really do. I've been a developer for, well, a long time and I've honed my craft over those decades. To see it commoditized like this is...difficult. But we have other skills besides just writing code. The technical knowledge of what that code should look like, how it should work, security best practices, etc.
Keeping the human in the loop. Using AI as a tool but not abandoning software development best practices. If you're doing those then the source of the code kinda doesn't matter. Open source projects accept PRs from random sources on the internet for example. They already have processes in place to review code and apply it. It's already part of the system.
I don’t think you understood my point.
Writing code faster was never something anyone with any real knowledge of their domain would think is desirable. I don’t care if more code is written faster, because that has never been a good indicator of productivity. In fact, I would argue that less code is better.
Anyway, it’s funny that you mention, in a somewhat patronising tone by the way, that we need to adapt and not be wary of AI because we have “other skills”.
If you want to keep a human in the loop, then fine. Now you have a choke point in your otherwise faster machine. A human who now needs to understand code they haven’t written, and with more and more datapoints coming up suggesting that LLM usage leads to skill atrophy, an eventually more fallible human at that.
Maybe.
Sorry - that's bullshit. IDEs, code completion, syntax highlighting, editor macros, incremental compiling, editor syntax checking, debuggers, integrated debuggers in IDEs, code generators, RAD and "low code" tools, etc. The list goes on for tools we've created to do that exact thing. You're probably using many of the ones I've listed.
Okay. I've had an LLM help simplify some logic by refactoring a bunch of things before. The sort of thing that isn't "hard" but is time consuming. I know you don't care about "speed" but it did this work much faster than I would have taken. And it also resulted in "less code".
It's also the sort of work that I may not have done because "man that's gonna bit a bit of work." But since it was easier to do, I did it. So the LLM helped me cleanup our source.
And that's another thing here. I can spend 15-30 mins writing a small script to fetch data from an AWS API, parsing the results, using those results to fetch yet other resources, format the output, etc. Most of which is going to require me to dig through the AWS docs and read a lot of JSON responses, or I can have Claude do it in <3 mins and it just works. I'll throw it away in a few days once I'm done with that task so it doesn't need to be perfect. You needed to hit some threshold of "utility" vs. "time to write the script" to do things like that and being able to do it faster means more utility scripts so I don't have to dig through the aweful AWS console looking for when a scheduled job last ran.
Patronizing? I was being sincere.
You already had that choke-point with code review. I review code I haven't written all the time - have for decades. As a result I've gotten very good at it. If you haven't been then maybe that's a skill you need to focus on since it sounds like you find reading code to be quite difficult (I only say that because you keep bringing it up).
Skill atrophy is only bad if that skill is needed. How're your assembly skills these days? I could do it but I haven't in decades. Most developers have very little knowledge about how their computer even works. Ask your average dev what L1, L2 and L3 cache are. They don't care and don't need to. Even memory allocation is something you don't need to care about unless you're writing in C still. And frankly that's a good thing. So a lost skill - but good riddance.
I was with you with the whole tooling thing until
These have always been terrible.
Anyway, my point here was, obviously, that producing larger and larger volumes of code faster, isn’t something desirable, and it has never been. You took this out of context, with the added injury of commenting on the follow up sentence… but I’m glad you did, because it clarified your position a lot.
Because you said that you would instruct a LLM to refactor code because you didn’t feel like doing it. The irony here is three fold:
In short, I think you are wrong, but I don’t think you would know why until it bites you.
And further proof of it is this.
This is why we get shitty software, Java apps that blow up once a week and websites that freeze your browser. Because “memory allocation is something you don’t need to care about”.
I guess it won’t make any difference if you replace your skills with a LLM, since it sure sounds like you didn’t have that many to begin with.
Do you mean just the typing, or including thinking, designing, writing up, inolementing, testing and so on? Human developers spend less than 10% of their time typing. I think for a kernel it are less than 5%.
The thing is - you get your code faster, but need more time for testing.
It can definitely help design. LLMs are actually pretty good at it. It's quite useful for spit-balling ideas against as it will come up with approaches you may not have though of. Often better ones. It's much less limited than you are in its range of knowledge about algorithms and design. That's not an insult, we all have our specialties. What you may need to search on or read about it may just know.
And It's not actually like "legacy code" you're reading. It's code you're involved in and using an LLM to help write. And the LLM can tell you what it's doing unlike that developer who left the company 8 years ago. You're not going into it blind, you've asked for a certain result and expect to see what you asked for. So I don't find reading it particularly difficult.
So much of code is boilerplate anyway. Just having a LLM setup unit tests can be such a time saver. "Create me a test that mocks these three classes" is just wonderful. You can modify as needed.
Not to mention throw-away scripts and utilities that you want in your day-to-day. "Give me a script that queries AWS for all EC2 instances missing a specific tag" is something it can just spit out without you needing to spend an hour reading AWS docs and troubleshooting their API. Like, you can but Claude's going to have a working version in <3 mins.
You time testing - sure. But you would have been doing that anyway.
You can't use AI for things you do not know well. It will happily suggest total bullshit in the most confident tone.
This is a talking point. You're falling back on the nirvana fallacy.
Yes - absolutely nobody is recommending you do everything the LLM says. You still need to have critical thinking when using an LLM. I still use my many years of experience to gauge the quality of the responses. But it definitely has recommended solutions that I found to be quite good and better than what I was thinking of implementing. Do you think you can't recognize whether a solution would be a better or worse fit when recommended by either an LLM or a person if done "confidently"?
But even for "just coding" - I offer an example. It will happily convert an old Apache Tiles application to using Apache Thymeleaf (the former being unsupported). And it does it very well, and much faster than people can. The solution is very cookie cutter and we've established a pattern. It's very easy to recognize the changes being made are following the pattern and QA is testing all of the changes. What was going to take nearly a year will take weeks. It's an absolute win here.
You can tell yourself whatever you need to make yourself feel better, but there are real benefits to LLMs in software development.
In theory, people ought to check every LLM output. This collides with reality in different points;
people are lazy and being diligent just passively checking results is hard - and can be very tiring
people are under pressure to work faster
if they really check everything, the result is often slower.
As a result, careful checks of each result won't happen.
I know that by experience because I have a coworker who uses LLMs heavily. I am relying on interfaces he should provide and he is often not able to describe them in an usable way. Thinks that should take a day or two often take many weeks.
You could argue it is a competence problem, so maybe yes but LLMs apparently augment such problems.
We evaluate suggestions from people differently. For example, we use cues like use of language, certificates, reputation, personality, prior experience with them, and insitutions to evaluate their competence - and we trust then, with a reason. You won't go to a barber shop and ask a random person working there for a stomach surgery.
LLMs are more like a surgeon with fake certificates, using language from medical textbooks.
God yes I can relate to that. I have a similar "full vibe-coder" coworker who sent me a PR for something that amounted to 1,000's of lines of code changes. I rejected it out-of-hand. We had a long conversation about readable PRs, breaking work up into chunks, etc. Of course he had Claude do all that for him but... at least the PR was "better".
And the same trouble with him not having any clue what he just produced actually did. I 100% agree that's a problem. But it's kinda the same problem we had before LLM, though maybe a bit super-charged. That fella's code before Claude was terrible as well. So technically the code itself is better now so.... I guess that's a win?
Yeah - give bad drivers faster cars and people will die faster. I hear that. We do need to train people better on how to use these tools. It's definitely NOT "go vibe code a thing into existence and then drop it on others to maintain". But I don't think "bury your head in the sand and hope it goes away" is the right approach either.
Sure. But you can do that with LLMs too. They have strengths and weaknesses as well. But to understand how to use these tools appropriately you need to gain experience with them. To know when they tend to produce good results (well known and well documented languages and libraries) and when to be more "sus" about them (obscure libraries, poorly documented applications (coughOraclecough)).
The more you use them the more you get to see when it's struggling.