Nah, there's no evidence of reduced quality. If anything it's the reverse. I've seen AI code review tools be tremendously effective at catching defects which otherwise would have shipped.
Its easy to lean too hard into vibe coding. I've spent the last week unpicking a bunch of poor decisions claude made while coding something up. Its my mistake - I trusted it too much. It made a lot of sloppy, poorly thought through abstractions and then built a bunch of bad code on top of them. I should have been more careful reviewing its abstractions first.
But as others in this thread have said, LLMs are also great at doing all the tedious quality-improving tasks that I sometimes don't have time to do. You can prompt LLMs to write tests, to do fuzz testing and to set up CI pipelines. You can get them to formalise the constraints in the system (and then try to find violations of those constraints). I'm doing some work at the moment with Cocoa (apple's old UI library). I downloaded all the cocoa docs I could find. Then asked claude to read it all and review our code. It found lots of places where we're not using the API effectively. Fabulous.
LLMs are an accelerator. If you already know how to write performant, reliable software, LLMs can help you get there faster. But if you sit back and let the LLM guide itself, who knows where you'll end up. Probably nowhere good. Over the next few years we're going to see every possible use of LLMs. Probably more vibe coding disasters than anything else. But as a senior engineer, I think its way too reductive to write the tools off entirely. They're useful. But using them well? That's the trick.
In the DORA group's reporting on AI-assisted software engineering, they indeed state that across industries, quality goes UP with the use of AI assistants like Claude and others.
Moreover, in my experience helping businesses on this topic; They never defined or made measurable what quality meant in the first place. Then when they finally do figure it out, it turns out that the average repository is a total disappointment in terms of absolute quality.
Same for me. I have not yet successfully used an LLM to generate code to produce a feature, though to be fair, it might just be because I don't have the patience to go back and forth with it (will readily admit that I am using it wrong).
Also, while some code review comments are just plain wrong, LLMs did produce some damn good comments, on the same level as a different senior engineer might note had they taken the time to study the code carefully.
Its easy to lean too hard into vibe coding. I've spent the last week unpicking a bunch of poor decisions claude made while coding something up. Its my mistake - I trusted it too much. It made a lot of sloppy, poorly thought through abstractions and then built a bunch of bad code on top of them. I should have been more careful reviewing its abstractions first.
But as others in this thread have said, LLMs are also great at doing all the tedious quality-improving tasks that I sometimes don't have time to do. You can prompt LLMs to write tests, to do fuzz testing and to set up CI pipelines. You can get them to formalise the constraints in the system (and then try to find violations of those constraints). I'm doing some work at the moment with Cocoa (apple's old UI library). I downloaded all the cocoa docs I could find. Then asked claude to read it all and review our code. It found lots of places where we're not using the API effectively. Fabulous.
LLMs are an accelerator. If you already know how to write performant, reliable software, LLMs can help you get there faster. But if you sit back and let the LLM guide itself, who knows where you'll end up. Probably nowhere good. Over the next few years we're going to see every possible use of LLMs. Probably more vibe coding disasters than anything else. But as a senior engineer, I think its way too reductive to write the tools off entirely. They're useful. But using them well? That's the trick.