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.
Google fixed more Chrome bugs in June than over the past two years, thanks to AI
511–520 of 667 posts
Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI
#512Earlier 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.
Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI
#513Not 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.
Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI
#514Earlier 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…
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
#515Earlier 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.
Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI
#516Earlier 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.
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
#517Earlier 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.
Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI
#518Re: Google fixed more Chrome bugs in June than over the past two years, thanks to AI
#519Earlier 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.
(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
#520This 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