Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google fixed more Chrome bugs in June than over the past two years, thanks to AI

blog.google

Post reply on HN
Print view View original

581–590 of 668 posts

Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI

#581

Post by karmasimida »

prymitive wrote: post #580
karmasimida wrote: post #573

Earlier quoted context omitted.

Let's be honest with ourselves, AI review is better than human right now, especially top tier models. Not saying that for important project like Chrome, you can skip reviewing changes. Far from it. But it is probably better and more thorough than most human devs already.

To be fair it’s also worth noting that it’s much easier to find a buggy edge case with existing code than it is to write bug free code that doesn’t have any edge cases at all. It’s so much easier to read some concrete logic and find holes in it, than it is to start from nothing and end up with perfection. It’s true both for humans and agents, but agents are better are validating correctness.

Yes this is why models are superior here: they can equally (opportunity wise) attend everything in their context window.

Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI

#582

Post by Orphis »

throwaway2037 wrote: post #560
hn_submit wrote: post #389

To me this merely signals how broken C++ development really is. Most if not all of the bugs being uncovered are memory related and therefore intimately tied to the mental memory model of C and C++, namely manual memory management. It's fine for a C or C++ program encompassing a couple hundred lines but beyond that it's a liability. C and C++ are simply not fit for purpose when large scale software projects are concer…

Assume that you are writing a green field project in C++. If you never use "naked pointers" and always use std::unique_ptr and std::shared_ptr, will it not reduce nearly all memory related bugs? I don't have a lot of experience with them, but I found it dramatically reduced memory related bugs. I'm a very average C++ programmer, and those templates helped me greatly. Do you think it would help Chrome/ium to use (more…

Chrome uses those already, and a few other pointer types that are fit for purpose.

For example, lot of C++ objects are tied to a garbage collected object in JS, so you need something special to hold a reference in C++ code to those, and prevent them from being garbage collected.

Another example, shared_ptr is fine if you eventually drop the reference count to 0, but in JS, you will have cycles, so the reference count will never get there. And that's one of the problems the garbage collector deals with, it checks cycles and connectivity to mark a group of objects to be released together. So you will have a special life-cycle for those objects. Another responsibility if that you can't really use the destructor there or you might trigger a delete storm and block the thread. So the garbage collector will destroy objects in batches when the page is idle no to create stuttering (jank).

Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI

#583

Post by Yopolo »

userbinator wrote: post #550

What remains to be seen is whether Google also introduced more Chrome bugs in June than over the past two years, thanks to AI. The big problem is that AI output can be very convincing and look "right", even appear to work, until you examine it in detail and realise all the edge-cases it didn't handle.

Every single new working student we get, we have to teach every single thing again.

Its a massive effort for our team it has to be a massive effort around the globe if you take quality series.

It will just be easier better cheaper to teach ONE LLM how to do good code review

Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI

#584

Post by StevePrefontain »

karmasimida wrote: post #573
userbinator wrote: post #550

What remains to be seen is whether Google also introduced more Chrome bugs in June than over the past two years, thanks to AI. The big problem is that AI output can be very convincing and look "right", even appear to work, until you examine it in detail and realise all the edge-cases it didn't handle.

Let's be honest with ourselves, AI review is better than human right now, especially top tier models. Not saying that for important project like Chrome, you can skip reviewing changes. Far from it. But it is probably better and more thorough than most human devs already.

It’s not better than human review. It’s good at catching low-hanging issues but it is often requested overly-defensive code to handle edge cases that don’t exist or are handled elsewhere in the stack. It generates a ton of noise with low-signal comments. It basically cannot at all identify problems that pose the highest risk, like integrations, correctness from a business perspective, etc.

Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI

#585

Post by xyzsparetimexyz »

jkrejcha wrote: post #564
xyzsparetimexyz wrote: post #541

Earlier quoted context omitted.

How is it high level assembly? Have you written much assembly recently?

C is very much a "high level/portable assembly" type language still and there's really no sign that it'll change from that. Even if it has ostensibly has abstract semantics, many operations map to 1 or a few assembly instructions and much C code, even when not strictly conforming (as all but the most trivial examples are), is conforming enough that it's portable amongst most relevant targets For example, I kinda know…

No, you don't know what that code will do. Depending on the inner block, it'll most likely be vectorized. Like I said, it's significantly higher level than assembly.

Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI

#586

Post by ImaCake »

glimshe wrote: post #41

A lot of people here seem to be living in a different universe than me or simply don't know how to work with AI. I think detractors believe you should just let AI do the job blindly instead of leveraging it as a tool to accelerate you. They get mad at Excel for the poor investment returns. At this point, this is such a strawman, it isn't worth counter arguing. I think I'll abandon this discussion and keep using AI qu…

Hell, $20/month is a pretty good deal for something that can proofread a 100 page report, do some light research work, and write some quick and dirty scripts. It doesn't have to replace the entire job of programming to be really damn useful. The pushback against using it even for these simple tasks seems utterly unreasonable to me.

Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI

#587

Post by stack_framer »

majormajor wrote: post #356
harrall wrote: post #326

Earlier quoted context omitted.

If I were to be real, my coworkers that post AI responses straight rarely had insightful comments before AI.

> If I were to be real, my coworkers that post AI responses straight rarely had insightful comments before AI. There's never been a shortage of low-value coworkers because hiring is hard and firing is unpleasant and painful in many ways. But there's a weird phenomenon with AI where a lot of people are using it to actively call attention to the fact that they aren't doing anything but call the tools. Rarely in the pas…

Ironically, in synchronous conversations, the same co-worker is constantly going on about how swamped he is, and how he's being pulled in so many directions.

Apparently, it takes a lot of time and work to manage all those AI chat bots.

Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI

#588

Post by hegstal »

glimshe wrote: post #542
addaon wrote: post #329

Earlier quoted context omitted.

> But when I need to write code in areas I'm less confident about, I'll let AI take the reins and the do a thorough review myself. I see this mindset a bunch, and I just don’t get it. Reviewing code is so much harder than writing code! To write code, I need to find one path to achieve my goal, and convince myself, the compiler, and the reviewer that it does so. To review code, I need to consider all reasonable paths…

Seeing a solved problem and verifying the solution's correctness is much easier than solving the problem yourself. it's a bit like riddles. You can find examples of that when studying any topic. I disagree that reviewing code is harder than writing code in all/most instances. Also, there's code that is just tedious and repetitive to write. AI can write that and reviewing is pretty easy.

You could ask someone a math question, and they can write an equation down, and the equation can be mathematically sound, but it still not be the right form of the equation, or even relate to the question correctly at all. If all you're being asked to do is validate the mathematical soundness of the equation then sure, it's not that hard and it often mechanical, probably easier than having to generate the equation. But that isn't review -- that's cargo-culting what review is supposed to be.

To bring back to code: They are making the point that verifying "correctness" is not the be all and end all of code review. In every situation, there are multiple "correct" solutions, and only a few of them are actually correct and fit within the past, current and future context (technical and business). If someone isn't doing this, they aren't reviewing effectively and are acting as a glorified linter, which is an astonishingly low value-add use of human capacity.

There are situations where nobody really cares about the output, and nobody wants the true form of review, so it reverts to (at best) human-linting. In those situations, engineering capability of any kind functionally has no moat and all participants are equally fungible. If the business is dependent on engineering it's also a horrendous business. I would personally avoid being involved in these environments in an engineering capacity. I mean this in a diagnostic sense - it's a terrible career move, though there will always be busy work that's exactly what we have LLMs for.

Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI

#589

Post by nneonneo »

Yopolo wrote: post #583
userbinator wrote: post #550

What remains to be seen is whether Google also introduced more Chrome bugs in June than over the past two years, thanks to AI. The big problem is that AI output can be very convincing and look "right", even appear to work, until you examine it in detail and realise all the edge-cases it didn't handle.

Every single new working student we get, we have to teach every single thing again. Its a massive effort for our team it has to be a massive effort around the globe if you take quality series. It will just be easier better cheaper to teach ONE LLM how to do good code review

Yep! Then you’ll never need to train any students ever again.

So…are you planning to hire only seniors who already know everything? Where do these seniors come from?

Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI

#590

Post by stefanlindbohm »

They show how many more bugs they fixed compared to previous periods, but not how the amount of resources allocated to fixing bugs changed over time. If they allocated proportionally more resources to bug fixing, it really doesn’t tell us anything about the tools being used.

Might as well be that the learning here is that if you put resources on fixing bugs, you can in fact fix a lot of bugs.

Post reply on HN