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

221–230 of 668 posts

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

#221

Post by Version467 »

VBprogrammer wrote: post #17

I've recently been using AI a lot for performance optimisation during a particularly busy period at work. I would say it was almost completely useless at the high-level direction - it would point out suspicious parts of SQL queries for example but on back to back testing these almost never resulted in any performance change. In fact, if it wasn't for the fact that it made making the actual changes I identified much e…

Yup, I do this regularly now. Whenever I think that something takes longer than it should I just tell it to set up a testing harness to measure each part of the process.

Once I have the baseline I'll just set a goal to improve performance by 10x. Works better than it has any right to. Have to be careful to exclude changes that massively increase complexity for tiny gains after its done, but the big improvements are often sensible choices that I'd also make as an engineer (i.e. more efficient data representation, caching and memoization where it matters, parallel processing, etc.)

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

#223

Post by mycall »

VBprogrammer wrote: post #17

I've recently been using AI a lot for performance optimisation during a particularly busy period at work. I would say it was almost completely useless at the high-level direction - it would point out suspicious parts of SQL queries for example but on back to back testing these almost never resulted in any performance change. In fact, if it wasn't for the fact that it made making the actual changes I identified much e…

CTEs are often slower than using temp tables with indexes.

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

#224

Post by williamdclt »

buzzin__ wrote: post #151
seanmcdirmid wrote: post #78

This is only a flex if AI also didn’t cause an increase in bugs that needed to be fixed.

So, your conjecture is that the LLM's skill to detect bugs somehow magically disappears the moment they start writing new code?

I wouldn't say "magically", it's what happens with me and every other engineer I know: we're all detecting bugs and yet we're all writing them too. Not saying that LLMs work the same as humans, but saying it's not a logical fallacy.

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

#225

Post by epolanski »

VBprogrammer wrote: post #17

I've recently been using AI a lot for performance optimisation during a particularly busy period at work. I would say it was almost completely useless at the high-level direction - it would point out suspicious parts of SQL queries for example but on back to back testing these almost never resulted in any performance change. In fact, if it wasn't for the fact that it made making the actual changes I identified much e…

What's the complain? That AI can't do your job yet?

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

#226

Post by bluGill »

troupo wrote: post #204
madeofpalk wrote: post #72

Earlier quoted context omitted.

Tests! Unit tests, integration tests, random adhoc scripts. You know - TDD! I’ve been working on UI component improvements and it was doing a lousy job until i specifically told it to test in a headless browser to validate it works. I think somewhere in an AGENTS.md i have an instruction to “don’t state your guesses as fact - validate findings and results”.

> Tests! Unit tests, integration tests, random adhoc scripts. You know - TDD! Tests onli validate the presence of bugs, not their abscence (Djikstra). I'll also add that tests look at outputs and don't care how those outputs are derived. E.g. code filtering the entire db in memory will be fine in tests.

"Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth

Tests prove the things you thought of worked, and it often isn't hard to find the likely edge cases such that you have reasonable confidence everything works. You will be wrong from time to time, but not that often. You can prove code correct, but if the proof is wrong (common when a human is doing it), or the spec is wrong (most people have no clue how to write a comprehensive spec) it can still be wrong.

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

#227

Post by bluGill »

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.

And without a profiler they do about as bad as humans: spending a lot of time optimizing code that is rarely used (and then often with small n)

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

#228

Post by dpark »

cyanydeez wrote: post #156
jfrbfbreudh wrote: post #83

Earlier quoted context omitted.

Built exactly this for work a few months ago. Claude has a read-only account to the dev DB and a bunch of python postgres tools, I point it at queries/views and ask it optimize, and it has to: 1) verify identical query results 2) run repeatedly to get average, worst, best, etc duration of runs Sped up so many legacy things that none of us were ever going to bother with.

the point is more: are people going to flood the zone with infinite bikeshedding that drowns out the real gains

What is bikeshedding supposed to mean here?

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

#230

Post by zzzeek »

VBprogrammer wrote: post #17

I've recently been using AI a lot for performance optimisation during a particularly busy period at work. I would say it was almost completely useless at the high-level direction - it would point out suspicious parts of SQL queries for example but on back to back testing these almost never resulted in any performance change. In fact, if it wasn't for the fact that it made making the actual changes I identified much e…

I would never undertake a big performance optimization without first measuring that area's total impact. The LLM would then be great to work out the refactoring and you can give it your bench suite (which it probably wrote) to work against.

I guess just another area where the LLM is useful only as long as you remain in charge using your own programming experience as a guide.

Post reply on HN