Exactly what I see at work. I have a 'senior' C++ team lead which I have to explain over and over that for concurrent access of variables in device drivers one needs meticulous locking of shared variables. He was helding the view that when one thread is modifying a variable and another one is only reading it, then it's no race condition - even if the code crashes. And he still responds with generated code and suggesting names of members that don't exist.
this post was submitted on 04 Jul 2025
192 points (99.0% liked)
Programming
21807 readers
439 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 2 years ago
MODERATORS
This would infuriate me to no end. It's literally the definition of a data race. All data between threads needs to either be accessed through synchronization primitives (mutexes, atomic access, etc) or needs to be immutable. For the most part, this should include fds, though concurrent writes to stderr might be less of an issue (still a good idea to lock/buffer it and stdout though to avoid garbled output).
Exactly.
It's been so long since I've had to worry about this type of race condition, and like you...it infuriates me reading that comment.
wow, I hate that guy
This is something I've said for a very long time. Everytime some RAD or "low code" tool claims that it will make developers obsolete because "you won't need to write code"! I know that I'm going to need to help some BA use that tool and that there will be a tiny little box hidden in that tool somewhere which let's me write code to work around its limitations.
LLMs are useful to a developer as a cordless drill is to an engineer.
Software development is about understanding logic, data structures, and how to solve business problems with computers. A language is simply what we use to do that.
The tech lead at my team started using AI to do code reviews he can't be bothered to properly do himself. His suggestions during reviews are now shit. I hate the future. I'm seriously thinking on taking a leadership position just because how much I hate this dynamic, to shield others and discourage AI usage from a higher ground.
Using AI just to be lazy is by far the worst use case. It should be a tool made for speeding up repetitive work, and its output (if important) should always be reviewed by humans.
You need to tell him that. Seriously. Pick some especially bad example to point at, and come to him with, "Hey Bob, I used to get real value from your review comments. I could tell you were thinking about what to say and it helped me to produce better code. Now it seems I am mostly seeing LLM-generated junk like this one that doesn't help anybody. This isn't an improvement, can you go back to the more helpful way you used to do things?"
Eh, I get you, but the guy is my lead, and I'm a senior member. There is a bit of office politics involved here. My corporate-fu is not that good. Also there is a push to use AI tools from the top of the chain of command. I hate this, so much, but I need bring it in a more casual and friendly conversation.
Say it however you want that works for your relationship.
What I meant to be saying there was — if nobody tells him his review comments aren’t helpful anymore, then he probably won’t know.
I’m speaking from the perspective of somebody who spends like 1/2 their time or more doing code reviews, if I’m wasting people's time I would want to know it
Omg this is so true, I had 3 engineers which supposed to work on component. It took me almost a day to explain context, requirements and how work is split. Two of them were busy with other work. One did their part. After reviewing I realized they still lack understanding and need to rework what was done.I made an experiment and implemented whole thing myself. Since coordination part was eliminated it took me 3 times less than initially estimated.
That's also why good, experienced developers are so exponentially more valuable on complex systems. They need less coordination than multiple people doing the same thing, and that saves time. Plus really good people are also masters of technical communication which get straight to the points which are really relevant.
Not only are generally experienced developers really valuable, but developers experienced with the project they work on.
It takes a long time to actually understand everything in a large project, and if you do, you save a ton of time because you just know a lot of context already. No need to research or figure things out, you just know.
That's why the constant reorgs in larger corporations are incredibly hurtful to performance. If you want performance, let people stick to the few projects they know instead of switching stuff around all the time.
I’m the last of the original developers of a particular system and now it’s my turn for management to move me on. There’s a new person and they are being instructed to use AI to work on it. It’s like moving the system to hospice care, looked after by the janitor with an Alexa until the lights go out.
The main value I found from Copilot in vscode back when it first released was its ability to recognize and continue patterns in code (like in assets, or where you might have a bunch of similar but slightly different fields in a type that are all initialized mostly the same).
I don't use it anymore though because I found the suggestions to be annoying and distracting most of the time and got tired of hitting escape. It also got in the way of standard intellisense when all I needed was to fill in a method name. It took my focus away from thinking about the code because it would generate plausible looking lines of code and my thinking would get pulled in that direction as a result.
With "agents" (whatever that term means these days), the article describes my feelings exactly. I spend the same amount of time verifying a solution as I would just creating the solution myself. The difference is I fully understand my own code, but I can't reach that same understanding of generated code as fast because I didn't think about writing it or how that code will solve my problem.
Also, asking an LLM about the generated code is about as reliable as you'd expect on average, and I need it to be 100% reliable (or extremely close) if I'm going to use it to explain anything to me at all.
Where I found these "agents" to be the most useful is expanding on documentation (markdown files and such). Create a first draft and ask it to clean it up. It still takes effort to review that it didn't start BSing something, but as long as what it generates is small and it's just editing an existing file, it's usually not too bad.
Where I found these "agents" to be the most useful is expanding on documentation (markdown files and such). Create a first draft and ask it to clean it up.
How would the thing know what you were thinking and intending, what were the requirements, constraints, pre- and postconditions? How do you work around the risk that you end up with something that looks like useful information - but isn't ?
Because you created a first draft. Your first draft should include all that info. It isn't writing the whole doc for you lol, just making minor edits to turn it from notes into prose.
Without that? No clue, good luck. They can usually read source files to put something together, but that's unreliable.
I find getting the LLM to either generate or rephrase documentation gives a distinctly worse result than doing it myself. I was in a hurry to document a new API from scratch recently and thought I'd try Copilot, but the results were overly verbose and sometimes inaccurate so I ended up rewriting all of it.
The LLM is best for boilerplate code that is easily predictable and verifiable. Beyond that it's sometimes good for initial suggestions if you don't know where to start with a tool, after which you can go to the actual documentation. But you'll need to do that, because half the time the suggestions use nonexistent APIs and methods.
I have always thought that writing code is the easy part of being a developer. The hard parts are the parts management doesn't appreciate: clarifying requirements, architecting new systems, translating business goals into something codable, letting egotistical know they're not making sense without offending them, designing effective testing processes, persuading management to prioritize reducing technical debt, and integrating and maintaining existing systems. Maintenance is a huge part of the job that no one gives you credit for. Oh, and if you ever touch the front end, CSS.
I don't use it anymore though because I found the suggestions to be annoying and distracting most of the time and got tired of hitting escape
Same. It took longer for me to parse and validate the suggestion as it did for me to just type what I wanted.
I do like the helper for more complex refractors.
Where you have a bunch of similar, but not exactly the same, changes to make.
Where a search & replace refactor isn't enough.
It manages to figure out what you are doing, highlights the next instance of it and suggests the replacement.
I don't think I've seen it make a mistake doing that, and it is a useful speedup.
I guess the LLM already has all the context: the needle, the haystack and the term.
This short article is so true it hurts. And of course management never understood this in the first place.
I am programming since a looong time, but I somehow never learned to touch-type. In 2020, my org then had mandatory home office and I used a nice FLOSS program called "TIPP10" to learn it - 15 minutes every morning.
It is certainly a little distraction less, no question. But typing speed is not programming speed. The most time spent is wondering what the requirements should say, thinking about how to make something work, or wondering what a piece of code one needs to use is supposed to do. And only after that comes inquiring with people what they were meaning or thinking.
FLOSS program called "TIPP10"
Looks cool! Just weird that it doesn't provide the code hosted on a forge and gives a download of the source instead
This is why I rarely use AI for coding. How to put my thoughts into code is not my main concern. My main concern is that another person should understand my thoughts when reading the code.
Me too. If I have anything mildly complex to code, I'll be faster writing it myself than trying to come up with a prompt.
LLMs are great for rubberducking, to do pre-reviews, and sometimes code boilerplate (under supervision).
Nothing more IMHO
Nah, they're actually fantastic at brain numbing tasks. I like to feed it sql tables and have it act like an ORM, but without the tradeoffs of an ORM. I'd never do it manually, but it's far more readable and easy to work with
I also love using it for api's. You can feed it a response, say "hey, I just want the id, status, and amount" (or whatever) and it'll restructure the data for you
These are not hard problems... They are tedious ones though. They solve a problem by brute force, a problem we "solve" over and over because at the end of the day: programmers are lazy.
You can over engineer complex bindings until the cows come home, but a simple pattern with each field explicitly mapped is the best solution. It's just really, really annoying to actually do it
25% business and product roadmapping, 15% discovery, 10% coding, 15% unit testing/debugging/refactoring, 25% scrum/huddle/other useless meetings, 10% answering stupid questions at the 11th hour about why we need this feature that they asked for.
An additional 100% we didn't plan for to make the damn thing actually work after delivery.
Not my experience. More like 50% coding/debugging, 25% meetings, 25% admin/helping people/procrastinating.
BTW, when I think about it, this will make Open Source code more relevant, not less. Because such code is often developed and reviewed via text exchange, by people which know how to communicate in writing, and therefore is on average far better documented than typical company code, which in future thanks to LLMs will drown even faster in technical debt than it does already.
I agree with the sentiment, but was this article written by an LLM?
OK so you walk into your VP's office and tell him that vibe coding isn't a silver bullet. He tells you his boss told him to use AI for something, and all you've done with him is come with a problem and not a solution.
What then? You build an agentic pipeline to attempt to do code reviews and the other problems you say still exist? This article is incomplete.