Just to make this clear up front: I was always very skeptical of LLMs (I'll never call them AI) and still see them as fundamentally limited and unreliable. See my post history if you don't believe me.
Having said that: I work in business software and the models have progressed to the point where typing code and writing classes and functions by hand has become uneconomical. We review the output closely to avoid the idiocy of "vibe-coding", but the quality has improved to the point where we rarely have to outright reject solutions. The discussions have moved to high-level architectural points, where we just request better implementations than the first-shot. We get them, review again and move on. Maybe there are deeper, latent problems beeing embedded in the code-base through this process, but we can't spot any although we are looking intently.
And just like that, my profession has died. Nobody in my team writes code anymore. Things that would have taken days are now done in minutes. We are all just considering design and architecture. We are changing our processes since they are not fit for the new way of doing things. Scrum? What's even the point anymore? We can work through a sprint-backlog that would've taken two weeks in two days now. We do reviews 90% of the time. When we request changes they come back in minutes.
I have a feeling like the ground has been taken from below me. My son wanted to become a developer, that isn't a real job anymore. Everyone around me feels the same way, including our management. We are a small team and a small company, everyone is effective and our jobs are not in danger as long as our product is succesful. But my profession is essentially dead. It's a craft I honed for many, many years and the craft itself is now automated. I wanted to improve my typing skills to code faster, this is now a ridiculous endeavour. We don't know what comes next, but I now only have my analytical skills and knowledge of good architecture to fall back on.
And it all changed so fast. I don't think this will transfer to other professions so easily, but for programming LLMs ended it all in the span of the last four months. I thought I knew what my future holds as a senior dev, now I can barely see past christmas.This is a nightmare.
That's a part of it, yes, but the big part is that the code you have to review hasn't been thought about, because the entity creating it doesn't think, it just replicates patterns. This means it misses a lot of the more subtle details that separate quality, maintainable, and reliable code from the mediocre.
If you are competent and using an LLM to generate code you'll put your name to, that mean reviewing a lot of code that isn't up to your usual quality, rather than just writing it yourself, which is frankly extreme tedious, demoralising, and mentally exhausting. If you're not competent, you wont catch any of that, and it'll either just go to production, or it'll fall to someone else to review it.
If you're reviewing code submitted by others, using LLMs or not, you'd better be competent, and you're going to end up flooded with low quality commits from coworkers who've either given up or weren't competent in the first place. While that's not a new problem, the volume is, and it's much harder to train people to good practice when they're abdicating the thinking to a machine. There are lots of other comments here about the difficulties faced there.
Isn't that just admitting that the author of the PR has not read the code they're submitting? If I caught wind of that I would reject the PR on principle without even reading all of it.
That's not been my experience. While there are often multiple iterations of feedback I go through with an LLM before I consider a PR ready, it's rarely a significant deviation from what I already planned out. Most often it's just basic code organization that I forgot to specify (especially if the area of code it's working on was already poorly organized), or tradeoffs I wasn't even aware of until the code was written. The amount of effort per cycle is usually very small, and I'm able to work on other things in between (like reviewing other peoples' code).
This sounds mostly like a workplace culture problem. It's always been important to have a high bar on code review to catch poor quality. Not to catch bugs per se, but to catch code that isn't properly tested.
Again, that's a workplace culture problem. You need to either stick to your principles and try to enact change, quit, or go along to get along. I'm sorry if the last option is where you're at and that does suck.
I totally agree. That's something each engineering org needs to reckon with, lest they burn out the devs who care about code quality.