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

591–600 of 668 posts

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

#591

Post by insanitybit »

inigyou wrote: post #561
insanitybit wrote: post #516

Earlier quoted context omitted.

What? Sorry, I genuinely have no idea what you're talking about. Is it possible to look at code and intuit, just by reading, how to speed it up? Duh, yes. If you disagree, lol. Keep in mind that I've never stated that all performance issues are findable through code review. Just that there are many that are. > You can very easily spot performance issues through code. If you think that this is false, there's literally…

Demonstrate for me, then. Here's some slow code: https://github.com/torvalds/linux Speed it up.

I can't take this seriously. The claim "you can look at SOME code and see how to optimize it" is trivially true, and saying "you can't look at ALL code and see how to optimize it" changes nothing.

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

#592

Post by insanitybit »

CuriouslyC wrote: post #206
insanitybit wrote: post #192

Earlier quoted context omitted.

I've consistently found that I see performance issues that the AI misses. It often says "that's not going to be what improves performance, it's noise" and then I get it to do it and it's like a global 30% throughput win lol. I think a lot of performance guidance it'll be trained on is shit - I see devs consistently misunderstand performance too and downplay the impact of anything other than "IO".

Just give them a profiler. They drill down just like a human would and test stuff and validate. It works great.

Profiling is awesome, I do that. But it's also way slower. Like, 1000000% I'm with you, that's the right way. But I've seen huge gains just from reducing allocations and changing hash algorithms.

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

#593

Post by hegstal »

I've also seen similar recently at my place of work with LLM linting. Lots of hard to spot bugs in old very critical code have been caught. I remember seeing similar kinds of impacts back when linting or sanitizers were introduced. They're good for making it easy to encode more complex rules/areas-of-focus etc. that may have not been meaningfully possible with the more traditional tooling. Commercial LLMs in their current incarnations make for very expensive, but very effective intelligent linters.

On the other hand, my experience so far has been that they are terrible code-reviewers, to the point almost everyone ignores any kind of generic LLM review entirely (correctly - most of it is noise).

I feel the industry obsession with full-automation causes them to go down the wrong rabbit-holes on full-automation vs augmentation. In my view would be significantly more effective if the LLM review process in forge-tooling was designed with a human reviewer in the loop. The goal imo should be drastically improving the review efficacy & throughput of the human element, who needs to be acquiring confidence in & socializing the change in any sane org anyway. For example iteratively & interactively rubber-ducking out analysis + remediation, or interactively providing focusing guidance on the patch, instead of as agentic batch or harness processes as is cool nowadays. Sometimes a custom REPL is just better for an expert system. These things matter more as more and more code is LLM generated.

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

#594

Post by qsort »

sigmoid10 wrote: post #552
qsort wrote: post #380

Earlier quoted context omitted.

5.6 Sol on Codex, Opus 5 on Claude Code. (See sibling message, I'm not saying they're useless)

Then it's for sure a guidance or missing context issue. When given full access to everything they need, these models deliver results on par or above the best coders I've ever met and they are lightyears ahead of the lower 90% of developers. I feel more and more that when users report they can't solve their problems this way, it's like when a gorilla is mad at Einstein after talking to him and he didn't make bananas g…

> guidance or missing context issue

I mean yeah, that's mostly what I'm saying?

The only parts where I would disagree are that capabilities are spiky, and also the fact that they're a bit prone to losing the forest for the trees without guidance (the macro/micro distinction). But yeah, by default I don't write code by hand.

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

#595

Post by unknownfuture »

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.

Ehhhh, it's better at some things and not others.

My own reviews have shifted now. I tend not to examine detailed semantics anymore. The AI is as good or better than me at assessing whether a chunk of code does what the author said it was supposed to do.

Instead my job is to spot design and architecture smells, broader semantic errors, violations of unspoken business requirements, etc.

For example, I was recently reviewing code that built out a transactional flow. Part of that flow involved recording the transaction somewhere user visible and I knew that should only happen after the transaction was confirmed. AI implemented it where the transaction was posted.

That starts as an issue of underspecified requirements but that always happens in the real world. Thus that's where I can provide the most valuable insight: assessing with that context, whether business, operational, historical, or forward looking.

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

#596

Post by dominotw »

dragonwriter wrote: post #351
dominotw wrote: post #244

Earlier quoted context omitted.

Very few problems really have "all the tooling to verify its hypotheses" though. even if you want to construct such an harness. Also let me ask you why we need better and better and models if what we have already can produce good output with 'all the tooling to verify its hypotheses'

> Also let me ask you why we need better and better and models if what we have already can produce good output with 'all the tooling to verify its hypotheses' “Good” isn’t “perfect” and even if it was, the ability to produce perfect output with all the tooling to verify its hypotheses could still be improved, in time and token efficiency, by better models producing fewer spurious hypotheses, rejecting those it does g…

hmm.. ok but i dont think trillions of dollars are being spent for the improvements you mentioned.

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

#597

Post by Neywiny »

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.

I think I've seen it the other way. I told an AI I had data coming in at some fixed, slow rate that I wanted displayed. It did the job but only for that case. It literally put a polling loop to catch one sampling at that duration. I've noticed it gives me very specific code to the exact data, or wildly complicated code for all possible data to ever exist. Finding the middle ground has been my challenge

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

#598

Post by LearnYouALisp »

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.

I wonder, how much dogfooding did they do in this run?

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

#599

Post by wbl »

dingaling wrote: post #422
rpdillon wrote: post #416

Earlier quoted context omitted.

The entire compute world was built on top of C and C++. Saying they're not fit for purpose doesn't seem correct. I think what you're really saying is they're not an optimal choice from a safety perspective. > All of these need to be ported to Rust or another memory-safe language ASAP to prevent mayhem. Seems like hyperbole... It might be ideal if we could snap our fingers and suddenly have rust ports, but I feel like…

> Saying they're not fit for purpose doesn't seem correct. I'll quite happily say they were never fit for purpose. C had a role in bootstrapping early software development in the absence of anything better but once Lisp, Delphi, Smalltalk and Java arrived on the scene then it, and its equally footgunnable variants, should have been pushed to the margins where hardware constraint was the primary consideration. Writing…

You have chronology backwards. Lisp predates C by 14 odd years. Pascal was contemporaneous.
Post reply on HN