Live data from Hacker News

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

blog.google

511–520 of 668 posts

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

#511
post #494

Earlier quoted context omitted.

>The general way technology is deployed is that we try to find ways to make it work, because those are the most interesting. That's not the way AI is being deployed. At all.

Sure it is. It's just like the .com bust: people didn't know what the internet was good for, so they did a lot of stupid stuff with it before settling on the most interesting uses.

No, AI is more like: people do know what it is good for, but that's immaterial because hundreds of billions of dollars of debt were poured into it, such that the only glimmer of hope of getting an ROI out of it is force-feeding AI everywhere, good or bad, and normal people are sick of that.

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

#512

Earlier quoted context omitted.

yea, we certainly wouldn’t want regular user applications to run fast or respect user resources. can’t have that

Even if that was the tradeoff, your average C/C++ program isn't notably fast or lean.

I’ll take a Qt application over the Electron garbage that we see all the time nowadays.

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

#513
post #5

Not that I don't believe its possible to fix a lot of bugs, I also wonder what the actual dynamic was. Were the people in team working much more than usual as well? Given its Google, I wouldn't be surprised if there was an "internal push" to fix more bugs over next X sprints so that they can publish this blog and some manager can show impact and AI adaption to his superior.

This is just my hypothesis, but I suspect that at Chrome‘s engineering team there has been a culture of inaction for the past decade or more. That nothing gets done, no bugs fixed, unless some higher ups at Google sees a business interest in resolving it. And what has changed now is that the higher ups at Google do indeed see a business interest in fixing bugs and giving the credit to AI to sell us more AI.

Hard disagree. Google holds browser PWN contests and pay people for reporting bugs. If they can find the bugs themselves, they won't have to pay others. Also, there is a business interest, controlling the browser market helps their data collection and ad business. People could drop Chrome like they drop IE if Chrome does not perform - there are other browsers. "inaction for the past decade or more." I don't follow Chrome dev but this is entirely false.

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

#514

Earlier quoted context omitted.

That is true, I was mostly speaking about a supposed need to review the code. My effort instead goes to manual QA testing, providing feedback and preferences, and asking questions. The limitation here is mostly that the model does not know what looks and feels good. With improvements to the vision capabilities and a better understanding of motion, or what looks appealing to humans, the implementation could probably h…

> That is true, I was mostly speaking about a supposed need to review the code. Until you go to prod, you can believe a lot of things about the state of your code. Reviewing code is not merely about “Does this things work”. Testing and linting do cover most of that. Reviewing is mostly about: Will this design cover the current set of constraints (some may be conformance) and can it evolve? Are the assumptions correct…

In the context of a mobile app the user interface is the main part.

Testing and linting often do not cover whether things work or provide decent UX. The 'security layer' is almost irrelevant here.

Do you do mobile app development? I would guess not.

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

#515

Earlier quoted context omitted.

Even if that was the tradeoff, your average C/C++ program isn't notably fast or lean.

I’ll take a Qt application over the Electron garbage that we see all the time nowadays.

It could be worse but that's not much of an argument for C in particular. There's a lot of ways to do UI that don't involve web engines.

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

#516

Earlier quoted context omitted.

Are you serious? Of course you can. Some hash algorithms are slower than others, you can read that and know that. Allocating in a hot loop is probably slower than allocating outside of it. Duh? I can't believe this even has to be justified, of course you can look at code and get an idea of its performance properties lol Obviously you want empirical evidence to justify changes, but like... duh, you can read code and u…

Sometimes when you look at code you know is slow, you can immediately see why it's slow. Obviously you didn't see it when you wrote it, which disproves your hypothesis.

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 nothing you can contribute.

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

#517
post #412

Earlier quoted context omitted.

> What about fuzzers, linters, typecheckers and formal tooling? Pretty sure Chrome has been using all of those forever, along with some of the best security researchers in the world, yet AI (which is what GP really means by “machine” here) is finding way more bugs. I think GP’s point is that AI makes some people uncomfortable because it operates more like a human than a special purpose tool. As for lack of informatio…

Here is a nice report about tooling https://cacm.acm.org/research/lessons-from-building-static-a... This is the kind of report that you can reflect upon and learn from instead of feeling like you’ve just read a marketing piece.

Thanks! I do believe I’ve read that piece (I worked in a similar area in a past job) it indeed is a good one. However I do think a big portion of the articles on blog.google are semi-marketing pieces, e.g. check this list: https://news.ycombinator.com/from?site=blog.google

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

#519

Earlier quoted context omitted.

I have at least one coworker who literally copy-paste AI output to respond to code and doc reviews (and most of her communications like on Teams and Asana) despite me telling her multiple times to take it a notch down. Two days ago, she started answering my doc review questions with literally AI outputs (like "Good question. " and "You're right. "). That really bothered me that I finally announced AI "code of conduct…

Need to be more aggressive. There must be audits to see what value people are adding on top of agents. If there is no value———fire them.

i mean, basically your talking to claude through a human proxy at that point...

(and yes, i've experienced this exact phenomena as well)

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

#520

This is a tacit admission it was Mythos, not Gemini, despite alluding to experiments with Gemini earlier on: > Added support for model interoperability to leverage the unique strengths of both open-weights and proprietary models

I'm also curious if they used Mythos. Google definitely had access to it via Project Glasswing. However, your logic doesn't hold. That sentence only tells us they were using multiple models, but offers no real clues as to which proprietary model(s) they were using.
Post reply on HN