AI helps ship faster but it produces 1.7× more bugs

https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report

by birdculture • 7 months ago

207 181 7 months ago

bogzz2• 7 months ago

oh wow, an LLM-based company with an article that claims AI is oddly not as bad when it comes to generating gobbledegook as everyday empirical evidence should suggest

jjmarr4• 7 months ago

Coderabbit is an LLM code review company so their incentives are the opposite. AI is terrible and you need more AI to review it.

fwiw, I agree. LLM-powered code review is a lifesaver. I don't use Coderabbit but all of my PRs go through Copilot before another human looks at it. It's almost always right.

bpicolo• 7 months ago

Their incentives are perfectly aligned - you’re making more bugs, surely you need some AI code review to help prevent that.

It’s literally right at the end of their recommendations list in the article

elktown12• 7 months ago

You're comment history suggests a pro-AI bias on par with AI companies. I don't understand it. It seems like critical thinking, nuance, and just basic caution have been turned off like a light-switch for far too many people.

smb06• 7 months ago

Do you use Copilot for coding and then also Copilot for reviewing? Or are you using some other coding agent and Copilot only for PR reviews?

tyleo3• 7 months ago

I have a theory that vibe coding existed before AI.

I’ve worked with plenty of developers who are happy to slam null checks everywhere to solve NREs with no thought to why the object is null, should it even be null here, etc. There’s just a vibe that the null check works and solves the problem at hand.

I actually think a few folks like this can be valuable around the edges of software but whole systems built like this are a nightmare to work on. IMO AI vibe coding is an accelerant on this style of not knowing why something works but seeing what you want on the screen.

jmkni• 7 months ago

Blindly copying and pasting from StackOverflow until it kinda sorta works is basically vibe coding

AI just automates that

giantg23• 7 months ago

Yeah, but you had to integrate it until it at least compiled, which kind of made people think about what they're pasting.

I had a peer who suddenly started completing more stories for a month or two when our output was largely equal before. They got promoted over me. I reviewed one of their PRs... what a mess. They were supposed to implement caching. Their first attempt created the cache but never stored anything in it. Their next attempt stored the data in the cache, but never looked at the cache - always retrieving from the API. They deleted that PR to hide their incompetence and opened a new one that was finally right. He was just blindly using AI to crank out his stories.

That team had something like 40% of capacity being spent on tech debt, rework, and bug fixes. The leadership wanted speed above all else. They even tried to fire me because they thought I was slow, even though I was doing as much or more work than my peers.

zipy124• 7 months ago

I agree but I'd draw a different comparison. That is vibe coding has accelerated the type of developers who relied on stack overflow to solve all their problems. The kind of dev who doesn't try to solve problems themselves. It has just accelerated this type of working, but is less reliable than before.

skeeter20202• 7 months ago

this matches with my first thought of this "study" (remember what coderabbit sells...); can you compare these types of PRs directly? Is the conclusion that AI produces more bugs, or is that a symptom of something else, like AI PRs are produced by less experienced developers?

whynotmaybe• 7 months ago

"on error resume next" has been the first line of many vba scripts for years

eterm• 7 months ago

I caught claude trying to sneak in the equivalent to a CI script yesterday as I was wrangling how to run framework and dotnet tests next to each other without slowing down the framework tests horrendously.

It tried to sneak in changing the CI build script to proceed to next step on failure.

It's a bold approach, I'll give it that.

eurekin• 7 months ago

"ship fast, break things"

palmotea2• 7 months ago

I actually think a few folks like this can be valuable around the edges of software but whole systems built like this are a nightmare to work on. IMO AI vibe coding is an accelerant on this style of not knowing why something works but seeing what you want on the screen.

I would correct that: it's not an accelerant of "seeing what you want on the screen," it's an accelerant of "seeing something on the screen."

[Hey guys, that's a non-LLM it's not X, it's Y!]

Things like habitual, unthoughtful null-checks are a recipe for subtle data errors that are extremely hard to fix because they only get noticed far away (in time and space) from the actual root cause.

jerf• 7 months ago

One of my frustrations with AI, and one of the reasons I've settled into a tab-complete based usage of it for a lot of things, is precisely that the style of code it uses in the language I'm using puts out a lot of things I consider errors based on the "middle-of-the-road" code style that it has picked up from all the code it has ingested. For instance, I use a policy of "if you don't create invalid data, you won't have to deal with invalid data" [1], but I have to fight the AI on that all the time because it is a routine mistake programmers make and it makes the same mistake repeatedly. I have to fight the AI to properly create types [2] because it just wants to slam everything out as base strings and integers, and inline all manipulations on the spot (repeatedly, if necessary) rather than define methods... at all, let alone correctly use methods to maintain invariants. (I've seen it make methods on some occasions. I've never seen it correctly define invariants with methods.)

Using tab complete gives me the chance to generate a few lines of a solution, then stop it, correct the architectural mistakes it is making, and then move on.

To AI's credit, once corrected, it is reasonably good at using the correct approach. I would like to be able to prompt the tab completion better, and the IDEs could stand to feed the tab completion code more information from the LSP about available methods and their arguments and such, but that's a transient feature issue rather than a fundamental problem. Which is also a reason I fight the AI on this matter rather than just sitting back: In the end, AI benefits from well-organized code too. They are not infinite, they will never be infinite, and while code optimized for AI and code optimized for humans will probably never quite be the same, they are at least correlated enough that it's still worth fighting the AI tendency to spew code out that spends code quality without investing in it.

[1]: Which is less trivial than it sounds and violated by programmers on a routine basis: https://jerf.org/iri/post/2025/fp_lessons_half_constructed_o...

[2] https://jerf.org/iri/post/2025/fp_lessons_types_as_assertion...

tyleo3• 7 months ago

This is close to my approach. I love copilot intellisense at GitHub’s entry tier because I can accept/reject on the line level.

I barely ever use AI code gen at the file level.

Other uses I’ve gotten are:

1. It’s a great replacement for search in many cases

2. I have used it to fully generate bash functions and regexes. I think it’s useful here because the languages are dense and esoteric. So most of my time is remembering syntax. I don’t have it generate pipelines of scripts though.

ryandrake• 7 months ago

a lot of things I consider errors based on the "middle-of-the-road" code style that it has picked up from all the code it has ingested. For instance, I use a policy of "if you don't create invalid data, you won't have to deal with invalid data"

Yea, this is something I've also noticed but it never frustrated me to the point where I wanted to write about it. Playing around with Claude, I noticed it has been trained to code very defensively. Null checks everywhere. Data validation everywhere (regardless of whether the input was created by the user, or under the tight control of the developer). "If" tests for things that will never happen. It's kind of a corporate "safe" style you train junior programmers to do in order to keep them from wrecking things too badly, but when you know what you're doing, it's just cruft.

For example, it loves to test all my C++ class member variables for null, even though there is no code path that creates an incomplete class instance, and I throw if construction fails. Yet it still happily whistles along, checking everything for null in every method, unless I correct it.

palmotea2• 7 months ago

is precisely that the style of code it uses in the language I'm using puts out a lot of things I consider errors based on the "middle-of-the-road" code style that it has picked up from all the code it has ingested.

That is a really good point: the output you're gonna get is going to be mediocre, because it was trained (in aggregate) on mediocrity.

So the people who gush about LLMs were probably subpar programmers to start, and the ones that complain probably tend to be better-than-average, because who would be irritated by mediocrity?

And then you have to think about the long-term social effects: the more code the mediocrity machine puts out, the more mediocre code people are exposed to, and the more mediocre habits they'll pick up and normalize. IMHO, a lot of mediocrity comes from "growing up" in an environment with poor to mediocre norms. The next generation of seniors, who have more experience being LLM operators than writing code themselves, and probably more likely to get stuck in mediocrity.

I know someone's going to make an analogy to compilers to dismiss what I'm saying: but the thing about compilers is they are typically written by very talented and experienced people who've spent a lot of time carefully reasoning about how they behave in different scenarios. That's nothing like an LLM (just imagine how bad compilers would be if they were written by a bunch of mediocre developers from an outsourcing body shop, that's an LLM).

PaulHoule2• 7 months ago

My experience with AI coding is mixed.

In some cases I feel like I get better quality at slightly more time than usual. My testing situation in the front end is terribly ugly because of the "test framework can't know React is done rendering" problem but working with Junie I figured out a way to isolate object-based components and run them as real unit test with mocks. I had some unmaintainable Typescript which would explode with gobbledygook error messages that neither Junie or I could understand whenever I changed anything but after two days of talking about it and working on it it was an amazing feeling to see that the type finally made sense to me at Junie at the same time.

In cases where I would have tried one thing I can now try two or three things and keep the one I like the best. I write better comments (I don't do the Claude.md thing but I do write "exemplar" classes that have prescriptive AND descriptive comments and say "take a look at...") and more tests than I would on my on my own for the backend.

Even if you don't want Junie writing a line of code it shines at understanding code bases. If I didn't understand how to use an open source package from reading the docs I've always opened it in the IDE and inspected the code. Now I do the same but ask Junie questions like "How do I do X?" or "How is feature Y implemented?" and often get answers quicker than digging into unfamiliar code manually.

On the other hand it is sometimes "lights on and nobody home", and for a particular patch I am working on now it's tried a few things that just didn't work or had convoluted if-then-else ladders that I hate (even if I told it I didn't like that) but out of all that fighting I got a clear idea of where to put the patch to make it really simple and clean.

But yeah, if you aren't paying attention it can slip something bad past you.

alexjplant• 7 months ago

I've written before about my experience at a shop like this. The null check would swallow the exception and do nothing about the failure so things just errored silently. Many high fives and haughty remarks about how smart the team was for doing this were had at the expense of lesser teams that didn't. The whole operation ran on a hackneyed MVP architecture from a Learning Tree class a guy took in 2008 and snippets stolen from StackOverflow and passed around on a USB key. Deviation from this bible was heresy and rebuked with sharp, unprofessional behavior. It was not a good place to work for those who value independent thought.

AI vibe coding is an accelerant on this style of not knowing why something works but seeing what you want on the screen.

I've been saying this exact thing for years now. It also does the whole CRUD app "copy, paste, find, replace from another part of the application" workflow for building new domains very well. If you can bootstrap a codebase with good architectural practices and tests then Claude Code is a productivity godsend for building business apps.

LorenPechtel• 7 months ago

Yeah. There are times when silently swallowing nulls is the proper answer. I've found myself doing it many times in C# to trap events that get triggered during creation. But you should never do so unless you've traced where they're coming from!

qudat• 7 months ago

Totally agree. I see it all the time: https://bower.sh/death-by-thousand-existential-checks

Groxx• 7 months ago

I'd call some null-pointer-lint-with-automatic-fixes tools "vibe coding" tbh. I've run across a couple that do a pretty good job of detecting possible nulls and add annotations about it and that's great... but then the fix is "if null, return null", in practice it's frequently applied completely blindly without any regards to correctness.

If you lean on tools like that, you can rapidly degrade your codebase into "everything might be null and might short circuit silently and it can't tell you about when it happens", leaving you with buggy software that is next to impossible to understand or troubleshoot because there aren't "should not be null" hints or stack traces or logs or anything that would help figure out causes.

motbus3• 7 months ago

If you are in the industry for enough time you certainly crossed with a boss who said that it needs to be fixed in 5 minutes or else even if the problem was not caused by you and the solution clearly needs more than 5 minutes. (The root cause was because someone had only 5 minutes to do something too)

I once had a job that my boss ordered (that's the word he used) me to do the wrong thing. Me and the rest of the team refused except for one guy who did it because he was certain that 9 out 10 people were wrong while he was the only right one) The company spend 2M USD in returns, refunds and compensations in a project that probably didn't cost that. It was just a patch! How he could've possibly know - said the dismissed manager.

(Now he works for oracle, why not right)

phartenfeller• 7 months ago

Definitely. But AI can also generate unit tests.

You have to be careful by exactly telling the LLM what to test for and manually check the whole suite of tests. But overall it makese feel way more confident over increasing amounts of generated code. This of course decreases the productivity gains but is necessary in my opinion.

And linters help.

SketchySeaBeast• 7 months ago

I've been using Claude sonnet 4.5 lately and I've noticed a tendency for it to create tests that prove themselves. Rather than calling the function we're hoping to test, it re-implements the code in the test and then tests it there. It's helpful, and it usually works very well if you have well defined inputs and outputs, I much prefer it over writing tests manually, but you have to be very careful.

stuaxo• 7 months ago

It doesn't generate good tests by default though.

I worked on a team where we had someone come in and help us improve our tests a lot.

The default LLM generated tests are bit like the ones I wrote before that experience.

dnautics2• 7 months ago

this is solvable by prompting and giving good examples?

LanceH• 7 months ago

It doesn't generate good tests by default though.

I agree with this.

I've found I need a whole separate cycle of test writing to get proper (in both scope and accuracy) coverage.

It does help tremendously with all the boilerplate of tests, and it seems to be quite good at setting up numerous tests for all combinations of variables. It does have to be done explicitly, though.

And you do need to mind when a test fails whether it fixes the test or the code.

strangescript2• 7 months ago

Do they consider code readability, formatting and variable naming as "errors" for the overall count. That seems dubious given where we are headed.

No one cares what a compiler or js minifier names its variables in its output.

Yes, if you don't believe we will get there ever, then this is totally valid complaint. You are also wrong about the future.

oblio3• 7 months ago

The "future" is a really long time.

I'll take the other side of your bet for the next 10 years but I won't take it for the next 30 years.

In that spirit, I want my fusion reactor and my flying car.

strangescript2• 7 months ago

If your outlook is 10 years then for sure, its valid. I am not sure how you come to that conclusion logically though. At the beginning of the year we had 0 code agents. Now we have dozens, some are basically free, (of various degrees of quality, sure).

The last 2-3 months of releases have been an unprecedented whirlwind. Code writing will be solved by the end of 2026. Architecture, maybe not, but formatting issues isn't architecture.

cgearhart• 7 months ago

So…great for prototyping (where velocity rules) but somewhere between mixed to negative for critical projects. Seems like this just puts some mildly quantitative numbers behind the consensus & trends I see emerging.

GoatInGrey4• 7 months ago

I'm seeing parallels between this and factory-assembled houses.

Input costs are lower and velocity is higher. You get a finished product out the door quicker, though maintenance is more expensive. Largely because the product is no longer a collection of individual parts made to be interfaced by a human. It is instead a machine-assembled good that requires a machine to perform "the work". Therefore, because the machine is only designed to assemble the good, your main recourse is to have the machine assemble a full replacement.

With that framing, there seems to be a tradeoff to bear in mind when considering fit for the problem we're meaning to solve. It also explains the widespread success of LLMs generating small scripts and MVPs. Which are largely disposable.

everdrive• 7 months ago

Sounds like what companies have been scrambling for this whole time. People just want to dump something out there. They don't really care if it works very well.

0x3f• 7 months ago

At best this would be 1.7x more _discovered_ bugs. The average PR (IMO) is hardly checked. AI could have 10x as many real issues on PRs, but we're just bad at reviewing PRs.

core-utility2• 7 months ago

Couldn't this be true in the other direction as well? Anecdotally I see developers putting a lot more scrutiny into vibe coded PRs, while AI code tends to be highly commented (by the AI) and potentially easier to read.

I've seen way more human comments of "I don't know what this does but if I remove it everything breaks" in systems.

maerF0x0• 7 months ago

It's been suggested that code reviews shouldnt be about finding bugs, because they do not really work well for that goal.

https://www.microsoft.com/en-us/research/wp-content/uploads/...

bodge5000• 7 months ago

As has already been said, we've been here before. I could ship significantly faster if I ignored any error handling or edge cases and basically just assumed the data would flow 100% how I expect it to all the time. Of course that is almost never the case, so I'd end up with more bugs.

I'd like to say that AI just takes this to an extreme but I'm not even sure about that, I think it could produce more code and more bugs than I could in the same amount of time but not significantly so if I just gave up on caring about anything

dnautics2• 7 months ago

I could ship significantly faster if I ignored any error handling...

time to switch to erlang/elixir?

nerdjon• 7 months ago

Something I have been very curious about for some time now. We know the quality of the code is not very high and has a high likelihood of bugs.

But, assuming there are not bugs and the code ships. Has there been any study in resource usage creeping up and an impact of this on a whole system. The tests I have done with trying to build things with AI it always seems like there is zero efficiency unless you notice it and can put it in the right direction.

I have been curious about the impact this will have on general computing as more low quality code makes it into applications we use every day.

windex• 7 months ago

I think devs have now split into two camps, the kvetchers and the shippers. It's a new tool, it's fresh. Things will work itself out over the next couple of years/months(?). The kvetching helps keep AI research focused on the problem which is good. Meanwhile continue to ship.

SideburnsOfDoom• 7 months ago

ship faster but it produces more bugs

This is ... not actually faster.

mmastrac• 7 months ago

In the pre-AI days I worked on a system like this that was constructed by a high-profile consulting team but continuously lost data and failed to meet even the basic standards.

I think I've seen so much rush-shipped slop (before and after) that I'm really anxiously waiting for this bubble to pop.

I have yet to be convinced that AI tooling can provide more than 20% or so speedup for an expert developer working in a modern stack/language.

yomismoaqui• 7 months ago

Agentic AI coding is a tool, you can use it wrong.

To give an example of how to use AI successfully check the following post:

https://friendlybit.com/python/writing-justhtml-with-coding-...

joshribakoff• 7 months ago

The problem with this black or white framing is it implies competency is a failure. Finding it not useful doesn’t make you wrong, anymore than finding it useful doesn’t make you inexperienced.

cmiles83• 7 months ago

There are certainly some valid criticisms of vibe coding. That said, it’s not like the quality of most code was amazing before AI came along. In fact, most code is generally pretty terrible and took far too long for teams to ship.

Many folks would say that if shipping faster allows for faster iterations across an idea then the silly errors are worth it. I’ve certainly seen a sharp increase on execs calling BS on dev teams saying they need months to develop some basic thing.

tyleo3• 7 months ago

I think you need a balance. I’ve seen products fall apart due to high error rate.

I like to think of intentionalists—people who want to understand systems—and vibe coders—people who just want things to work on screen expediently.

I think success requires a balance of both. The current problem I see with AI is that it accelerates the vibe part more than the intentionalist part and throws the system out of balance.

cmiles83• 7 months ago

Don’t disagree… I think it’s just applying a lot more pressure on dev teams to do things faster though. Devs tend to be expensive and expectations on productivity have increased dramatically.

Nobody wants teams to ship crap, but also folks are increasingly questioning why a bit of final polishing takes so long.

jmathai• 7 months ago

More important than code quality is a joint understanding of the business problem and the technical solution for it. Today, that understanding is spread across multiple parties (eng, pm, etc).

Code quality can be poor as long as someone understands the tradeoffs for why it's poor.

coliveira• 7 months ago

When a team says that a "trivial" feature takes months to ship is not because of the complexity of the algorithm. It's because of the infrastructure and coordination work required for the feature to properly work. It is almost aways a failure of the technical infrastructure previously created in the company. An AI will solve the trivial aspects of the problem, not the real problem.

dj_gitmo• 7 months ago

It is almost aways a failure of the technical infrastructure previously created in the company. An AI will solve the trivial aspects of the problem, not the real problem.

This is so true. Software that should be simple can become so gnarly because of bad infra. For example, our CI/CD team couldn't get updated versions of Python on the CI machines, and so suddenly we need to start using Docker for what should be a very simple software. That's just an example, but you get the idea, and it causes problems to compound over the years.

You really want good people with sharp elbows laying the foundations. At one time I resented people like that, but now I have seen what happens when you don't have anyone like that making technical decisions.

thunky• 7 months ago

It's because of the infrastructure and coordination work required for the feature to properly work.

Or, it's because they have no incentive to do it faster.

WhyOhWhyQ3• 7 months ago

And you think people who don't understand the software telling people who do they're doing it wrong is an outright positive?

Aurornis• 7 months ago

I’ve certainly seen a sharp increase on execs calling BS on dev teams saying they need months to develop some basic thing.

Some of the teams I worked with in the years right before AI coding went mainstream had become really terrible about this. They would spend months forming committees, writing documents, getting sign-offs and approvals, creating Gantt charts, and having recurring meetings for the simplest requests.

Before I left, they were 3 months deep into meetings about setting up role based access control on a simple internal CRUD app with a couple thousand users. We needed about 2-3 roles. They were into pros and cons lists for every library and solution they found, with one of the front runners involving a lot of custom development for some reason.

Yet the entire problem could have been solved with 3 Boolean columns in the database for the 3 different roles. Any developer could have done it in an afternoon, but they were stuck in a mindset of making a big production out of the process.

I feel like LLMs are good at getting those easy solutions done. If the company really only needs a simple change, having an LLM break free from the molasses of devs who complicate everything is a breath of fresh air.

On the other hand, if the company had an actual complicated need with numerous and changing roles over time, the simple Boolean column approach would have been a bad idea. Having people who know when to use each solution is the real key.

cmiles83• 7 months ago

Yes. I’ve seen meetings where the dev team is going on and on about how it will take weeks to add a feature and someone calling BS just shares their screen, asks some AI agent to code it up, and it does. Is it 100% perfect? Perhaps not, but is close and does put the dev team in a spot of having to truly justify why it will take so long vs hand-wavy smoke and mirrors and “its technical you wouldn’t understand” commentary to leadership. Things have changed and I don’t think we’re going back.

Seattle3503• 7 months ago

I think the "just do it" mindset requires management who understands that follow up requests might need to clean things up and refactor. I think some engineers have been traumatized by repeated applications of "just do it" and try to avoid technical debt up front, which is really really hard unless you are a SME with years of experience on building that exact thing.

dannersy• 7 months ago

This attitude just furthers our race to the bottom. I agree with iteration, but software quality is getting really laughable. I know we're still on the better side of what existed in the hands of consumers in the 90s, but anyway... Execs calling BS is further evidence of that race to the bottom.

adverbly• 7 months ago

if shipping faster allows for faster iterations across an idea then the silly errors are worth it.

There is more to the consideration here...

Maintenance costs compound over time, as does complexity.

If you're building something that doesn't need to last long or is really simple, sure it's worth it... But a lot of stuff does need to last a long time and continuously change.

Vibe coding is a trade off that only works up to a certain distance from the existing system. If you don't need to go far, it's great. But if you need long range then it's the wrong tool for the job at the moment.

satisfice• 7 months ago

The “it’s no worse” argument seems to ignore the headline, which literally reports that it is worse.

exitb2• 7 months ago

1.7x does not look that bad? If "AI code" is a broad classification that includes people using bad tools, or not being very skilful operators of said tools, then we can expect this number to meaningfully improve over time.

speed_spread• 7 months ago

Tell that to your customers. And tell them how much longer the bugs generated by AI will take to fix by humans. Or tell them that you'll never fix the bugs because you're too busy vibe coding new ones.

exitb2• 7 months ago

I'm not saying bugs aren't a problem. I'm saying that if an emerging, fast improving tech is only slightly behind a human coder now, it seems conceivable that we're not that far off when they reach parity.

djeastm2• 7 months ago

Auto-assign bug tickets to AI agents which work to fix the bugs, get AI code reviewed, make adjustments, send to human for sanity checking, deploy via CI.

lherron• 7 months ago

They buried the lede. The last half of the article with ways to ground your dev environment to reduce the most common issues should be its own article. (However implementing the proper techniques somewhat obviates the need for CodeRabbit, so guess it’s understandable.)

bgwalter• 7 months ago

The report is from cortex.io, based on only 50 self-selected responses from "engineering leaders" as well as from idpcon.com, hosted by cortex.

All websites involved are vibe coded garbage that use 100% CPU in Firefox.

neallindsay• 7 months ago

1.7x more is not the same as 1.7x as many.

esafak2• 7 months ago

It's a lost cause. "It's two times faster!"

brainless3• 7 months ago

I use LLMs to generate almost all my code. Currently at 40K lines of Rust, backend and a desktop app. I am a senior engineer with almost all my tech career (16 years) in startups.

Coding with agents has forced me to generate more tests than we do in most startups, think through more things than we get the time to do in most startups, create more granular tasks and maintain CI/CD (my pipelines are failing and I need to fix them urgently).

These are all good things.

I have started thinking through my patterns to generate unit tests. I was generating mostly integration or end to end tests before. I started using helping functions in API handlers and have unit tests for helpers, bypassing the API level arguments (so not API mocking or framework test to deal with). I started breaking tasks down into smaller units, so I can pass on to a cheaper model.

There are a few patterns in my prompts but nothing that feels out of place. I do not use agents files and no MCPs. All sources here: https://github.com/brainless/nocodo (the product is itself going through a pivot so there is that).

WhyOhWhyQ3• 7 months ago

I see that your release is GPL 3.0. Are you worried about LLM's effectively laundering your source code a year from now? I've become hesitant about releasing source code since LLM's, though I do use Claude heavily while programming to make suggestions and look for issues etc.., but I'd be interested in hearing your perspective.

brainless3• 7 months ago

I am using GPL 3.0 mostly from a business standpoint, so that I can sell a commercial license to companies that may want to modify the project. In really LLMs will launder everything they can, I am not sure if that can be stopped. So that affects every project. The reason why LLMs are as good is that they train on all code that is available.

naasking19• 7 months ago

It's totally plausible that AI codegen produces more bugs. It still seems important to familiarize yourself with these tools now though, because that bug count is only ever going to go down. These tools are here to stay.

oasisaimlessly• 7 months ago

Are you trying to assure others or reassure yourself?

naasking19• 7 months ago

Just extrapolating a trend of the past few years. If you disagree, then carry on and time will tell.

djeastm2• 7 months ago

Same question can be asked to either side of this debate. We're all self-soothing apes, after all.

esafak2• 7 months ago

It produces more bugs but the count goes down?!

naasking19• 7 months ago

Did the models from 2 years ago produce more bugs, fewer bugs or the same bugs as today's models? Do you think next years AI models will produce the same number of bugs, more bugs, or fewer bugs?

GoatInGrey4• 7 months ago

These tools are here to stay.

I see this stranded claim get trotted out in the corporate world all the time as a refutation to "The AI broke". I fail to understand who the invisible audience for this is supposed to be.

Also, the FOMO argument for why one should use X as much as they can comes across as scammy. Not that I believe you're trying to scam anyone. Though the person you originally got this from may have been!

naasking19• 7 months ago

Also, the FOMO argument for why one should use X as much as they can

Who said that you should use it as much as you can?

Though the person you originally got this from may have been!

Borderline offensive to claim that I could only parrot someone else's sales pitch rather than come to my own conclusions based on technical merit and an evaluation of progress of the past few years.

kentm2• 7 months ago

These tools are here to stay.

I don't think that these specific tools are here to stay. Categorically, yes, but I expect there to be big changes in interfaces and how they work in the next five years.

I don't think spin up time on LLM technology requires as much investment as the hype claims, nor do I think that the current methodology will be as long lived as they think. Sitting out may be detrimental in the now, but I expect that developers that do so will be able to catch up just fine.

naasking19• 7 months ago

I don't think that these specific tools are here to stay.

I agree, we're still in an experimental phase so these tools are definitely not in their final form, I meant more that the LLM core of the tool is here to stay, and familiarizing yourself with how to use LLMs to solve every day problems is a good time investment.

I've experimented mostly with the raw chat interfaces for programming, circuit design, querying documentation, and troubleshooting OS issues rather than spending time googling, and they've proven incredibly valuable even with the basic chat interface. I've also hit many of the issues/limitations other people have reported, sometimes wasting some time going down a rabbit hole, and sometimes I was convinced that the LLM was wrong in diagnosing some issue, but it turned out to be correct in the end.

Despite the difficulties, it remains the case that I wouldn't have started or finished some projects without them.

geldedus• 7 months ago

Not for me.

827a• 7 months ago

Archetypes of prompts that I find AI to be quite good at handling:

1. "Write a couple lines or a function that is pretty much what four years ago I would have gone to npm to solve" (e.g. "find the md5 hash of this blob")

2. "Write a function that is highly represented and sampleable in the rest of the project" (e.g. "write a function to query all posts in the database by author_id" (which might include app-specific steps like typing it into a data model)).

3. "Make this isolated needle-in-a-haystack change" (e.g. "change the text of such-and-such tooltip to XYZ") (e.g. "there's a bug with uploading files where we aren't writing the size of the file to the database, fix that")

I've found that it can definitely do wider-ranging tasks than that (e.g. implement all API routes for this new data type per this description of the resource type and desired routes); and it can absolutely work. But, the two problems I run into:

1. Because I don't necessarily have a grokable handle on what it generated, I don't have a sense of what its missing and needed follow-on prompts to create. E.g.: I tell it to write an endpoint that allows users to upload files. A few days later, we realize we aren't MD5-hashing the files that got uploaded; there was a field in the database & resource type to store this value, but it didn't pick up on that, and I didn't prompt it to do this; so its not unreasonable. But oftentimes when I'm writing routes by hand, I'm spending so much time in that function body that follow-on requirements naturally occur to me ("Oh that's right, we talked about needing this route available to both of these two permissions, crap let me implement that"). With AI, it finishes so fast that my brain doesn't have time to remember all the requirements.

2. We've tried to mitigate this by pushing more development into the specs and requirements up-front. This is really hard to get humans to do, first of all. But more critically: None of our data supports the hypothesis that this has shortened cycle times. It mostly just trades writing typescript for reading & writing English (which few engineers I've ever worked with are actually all that good at). The engineers still end up needing long cycle times back-and-forth with the AI to get correct results, and long cycle times in review.

3. The more code you ask it to generate, the more vibeslop you get. Deeply-nested try/catch statements with multiple levels of error handling & throwing. Comments everywhere. Reimplementing the same helper functions five times. These things, we have found, raise the cost and lower the reliability & performance of future prompting, and quickly morph parts of the system into a no-man's-land (literally) where only AIs can really make any change; and every change even by the AIs get harder and harder to ship. Our reported customer issues on these parts of the app are significantly higher than others, and our ability to triage these issues is also impacted because we no longer have SMEs that can just brain-triage issues in our CS channels; everything now requires a full engineering cycle, with AI involvement, to solve.

Our engineers run the spectrum of "never wanted to touch AI, never did" to "earnestly trying to make it work". Ultimately I think the consensus position is: Its a tool that is nice to have in the toolbox, but any assertion that its going to fundamentally change the profile of work our engineers do, or even seriously impact hiring over the long-term, is outside the realm of foreseeable possibility. The models and surrounding tooling are not improving fast enough.

kristopherleads• 7 months ago

I really think the answer here is human-in-the-loop. Too many people are thinking that AI is a full on drop-in replacement for engineers or managers, but ultimately having it be an augment is the magic. I work at FlowFuse so super biased, but that's something I've really enjoyed with our MCP and Expert Assistant - it's built to help you, not to replace you, so you can ask questions, get insights, etc. faster.

I suppose the tl;dr is if you're generating bugs in your flow and they make it to prod, it's not a tool problem - it's a cultural one.

sailfast• 7 months ago

How many more bugs does it produce if we use CodeRabbit to review PRs? I assume the number will be less? (Asking seriously and hopefully if the product will help or would’ve caught the bugs, while also pointing out the natural conclusion of the article is to purchase your service :) )

jampa• 7 months ago

I've used it in some repos. It doesn't catch all code review issues, especially around product requirements and logic simplification, and occasionally produces irrelevant comments (suggesting a temporary model downgrade).

But it's well worth it. It has saved me some considerable time. I let it run first, even before my own final self-review (so if others do the same, the article's data might be biased). It's particularly good at identifying dead code and logical issues. If you tune it with its own custom rules (like Claude.md), you can also cut a lot of noise.

carra• 7 months ago

Am I the only one thinking that 1.7x is a very weird way of saying "70% more"? It's even wrong since, like other comments point out, 1.7x MORE would in fact be 2.7 times as much. Which is not what the bug numbers say.

visarga• 7 months ago

AI helps ship faster but we need to code 1.7x more tests (with AI) and it's allright

kkarpkkarp• 7 months ago

I can't find if they deducted false-positives before they count the results. I've been using CodeRabbit heavily and like any other AI code reviewing tools it was having a lot of them.

Like for example: found missing data validation / sanitization reported, only because the code has already been sanitized / validated but this is not visible in the diff.

You can tell CodeRabbit he is wrong about this and the tool accepts it then, though.

TheAnkurTyagi• 7 months ago

code reviews take way longer now because you gotta actually read through everything instead of trusting the dev knew what they were writing. Its like the AI is great at the happy path but completely misses edge cases or makes weird assumptions about state...

The real kicker is when someone copies AI generated code without understanding it and then 3 months later nobody can figure out why production keeps having these random issues. debugging AI slop is its own special hell

LurkandComment• 7 months ago

Sorry guys I'm having trouble here:

Is it: AI builds product faster but with more bugs in production (Adds overall time to acceptable production)

Is is: Al helps us build faster, enough though we have to fix more bugs before production. (over all less time to acceptable production, but specifically fixing bugs takes longer)

givemeethekeys• 7 months ago

It’s AI helps you ship faster. Ignore everything else.

daheza• 7 months ago

Depends on the product

compliance / healthcare - shipping faster with bugs is not better

marketing / non-critical-workflows - sure go for it

nphardon• 7 months ago

Ship fast, let customer do the QA, is that the idea?

jasonlotito• 7 months ago

The title (Our new report: AI code creates 1.7x more problems) is wrong.

The article says problems, not bug. Problems seems to include formatting or naming issues. I couldn't find 1.7x bugs specifically. I only see 3 mentions of bugs, with no number attached.

bilater• 7 months ago

for now

yonibot• 7 months ago

How useful is this metric if we don't know which LLM produced each MR?

There could be massive differences in quality between LLMs.

core-utility2• 7 months ago

Also, vibe coding has really become a skill in itself. Does it allow the average non-programmer to go to production easily (and likely have bugs/flaws)? Yes. But as someone who used to be a programmer and just fell out of skill with all of it, I've found that what I do still have is a keen sniff test for good vs bad, and can guide the direction and architecture with proper planning.

Garbage in, garbage out still applies.

stevenfoster• 7 months ago

Someone solved this 13 years ago: https://github.com/mattdiamond/fuckitjs

alexgotoi• 7 months ago

The pattern here feels pretty old: every time something shows up that lets people go much faster, we use it to crash harder first. When cars showed up, people didn’t suddenly become more careful because they could now move at 50 km/h instead of 5 – they just plowed into things faster until seatbelts, traffic rules and driver training caught up.

LLMs in coding feel similar. They don’t magically remove the need for tests, specs, and review; they just compress the time between “idea” and “running code” so much that all the missing process shows up as outages instead of slow PRs. The risk isn’t “AI writes code”, it’s orgs refusing to slow down long enough to build the equivalent of traffic lights and driver’s ed around it.

andrenotgiant• 7 months ago

... _says company selling a service to use AI to find bugs._

gwbas1c• 7 months ago

A few days ago I implemented IComparable in .Net / C#, and copilot "read my mind" and made a suggestion. It saved me 2-3 minutes of typing.

It took me about an hour of debugging to realize that copilot swapped a variable prefixed with "x" and a different one prefixed with "y".

If I wrote it myself, I wouldn't have made that mistake. But, otherwise copilot wrote the exact code that I was going to write.

scuff3d• 7 months ago

Yesterday we get a "report" from an AI company talking about how much faster you can go with AI. Today we get an AI code review company telling us how much buggier that code is.

It's almost like companies that want to sell you shit are only interested in the parts of the story that benefit them.

gilbetron• 7 months ago

1.7x more bugs, not great, not terrible

xnx• 7 months ago

What we learned from analyzing hundreds of open-source pull requests.

This does not sound like a sufficiently large dataset

quantum_state• 7 months ago

Vibe coding does not seem to be able to escape from the saying: he who attempts a free lunch will get diarrhea.

AI helps ship faster but it produces 1.7× more bugs

Related Stories