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

This isn't really a fair take. Keep in mind that C/C++ has been the backbone of the most important software in the world since the 1970s. At that time we didn't have virtually unlimited compute and memory at our fingertips the way we do now. It was a huge improvement to have a high level language which still could be optimized nearly as well as assembly.

Its staying power is due to the fact that we really haven't had many good alternatives until maybe the last few years. Things are not going to get ported and rewritten overnight, especially when they largely just work like Linux & PostgreSQL. We'd nuke a huge amount of institutional knowledge and inertia to change those up.

And C/C++ are still key in the embedded space where we still have devices constrained on compute and memory. That's not going to go away anytime soon.

This criticism feel like someone complaining about why anyone still uses horses on the day the Model T was announced. Change takes time.

> 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 you're discounting the effort that goes into doing that properly.

Which brings me to an interesting point. We have a web engine written in Rust. It's Servo. If the Rust port is so important to do as soon as possible to avoid mayhem, why aren't companies picking up Servo and using that?

I'm obviously not entirely serious here, but I think this is true to some extent: the number of memory safety bugs in a codebase is finite. Once you have a way to find them, you can drive that number down to zero.

C++ has become a far safer language thanks to LLMs - at least if you run the LLMs before you are attacked.

There are a number of challenges that make browsers more challenging (even in memory safe languages like Swift and Rust).

1. Back references/pointers like `parentElement` to other objects in the graph that create dependency cycles (where traditional/simple reference counting will prevent the objects being deallocated).

2. Interacting with (and creating resources in) a garbage collector when running/evaluating JavaScript code.

3. Just-in-Time (JIT) compilation of JavaScript and other complicated interpretation-compilation pipelines that can allocate and transfer objects between the different stages.

I checked the stats. 73% were memory management related issues, mostly use-after-free.

The rest were logic errors of various sorts.

Also, this doesn't address why the rate increased, which is the interesting part!

Some of the most important and safety critical large scale projects in the history of humanity had/have manual memory management. If you think the effort of doing it correctly is not worth it for certain projects, that may be a reasonable opinion. But the idea that humans cannot write correct C/C++ programs is in direct contradiction to historical fact.

In my experience, I find it to be exceptionally good at exploring and fixing the edge cases. Of course the output is not human maintainable for these fixes and needs to be heavily tests controlled, refactored or just accepted as being agent-maintained going forward.

The "engineers" using that AI. Could they repass the whiteboard tests of old? Have not some of them quietly left?

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

    > What remains to be seen is whether Google also introduced more Chrome bugs in June than over the past two years, thanks to human programmers.

    > The big problem is that human programmers 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.

2. Code reviews and security reviews happen quicker and produce more findings.

I would think that (m)any team(s) using AI might also be seeing a higher rate of finding and fixing issues.

Even the Linux Kernel (I'd say Windows and Apple too) are seeing the same phenomenon.

sure, moreover - maybe big AI usage significantly influenced the amount of bugs. So, the picture can be like that: - 2025: 50bugs found, 45fixed - 2026: 500bugs found, 450 fixed

I previously reported on my own and was ignored; now, not so much. I assume that the assistance by the LLM is providing needed detail or formatting. (Yes, I am reading what I am submitting and making sure it is optimal before sending 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.

1: https://www.anthropic.com/news/mozilla-firefox-security

2: https://blog.mozilla.org/en/firefox/hardening-firefox-anthro...

Previous discussion: https://news.ycombinator.com/item?id=47273854

Possible (probable?) scenario:

- Marketing: "we found and fixed lots of bugs thanks to AI"

- Reality: the KPI is now to fix as many bugs as possible with the help of AI, so they used AI to search old and easy bugs in the backlog, and then fixed it manually

That's AI for you.

At Amazon we have many forums to share our AI wins, but none to share AI failures or disappoinments.

No wonder execs make bad decisions regarding AI, they only hear completely one-sided stories.

Is that better testing? Or more bugs were being introduced in the first place?

I'd say that one is not really an issue. In 2012 the Pinkie Pie exploit chain already required chaining 6 bugs to lead to an exploit [1]. Since then we've seen chains requiring more than 10 bugs (!).

If you fix any one of those bugs, the exploit is non-functional anymore. Sorry out of luck.

So if, say, for every ten bugs you fix, you introduce two new ones then it's still a very net win. Unless of course it introduces a bug so bad it becomes a simple exploit not requiring a long chain of exploits.

But in the case of browsers we've only ever been moving to longer and longer chains of exploits required to pwn a browser.

A great many window of opportunities are closing for dark-side hackers / north korean intelligence etc.: there were probably exploit chains still open for exploitation in April that just got closed by Google.

If anything, besides the supply chains attacks in amateur-land, the world didn't stop working: projects (not just browsers but OSes too) are being hardened left and right.

Using AI to find potential bugs is an amazing use case and there really aren't many downsides.

> The post has counts for everything that went right and nothing for what could go wrong.

I'm not saying there aren't a few downsides but the benefits are just too good to ignore.

[1] https://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1....

But AI is not smarter than you, AI is as smart as the user who uses it. It often makes wrong decisions unless user corrects it.

I feel this way on this topic too.

> I think detractors believe you should just let AI do the job blindly instead of leveraging it as a tool to accelerate you.

The problem is; how _should_ I use AI? On a previous thread, I had two replies to the same comment, one saying "provide the LLM all the context it needs and let it go ham", and the other saying "Carefully guide and craft it and review everything". Both subthreads had people agreeing.

My experience with LLMs is leaving them unattended gives very poor results within a handful of iterations, and that carefully guiding them can be a value add, but the effort ot do that is very often as much as just writing the damn code myself, particularly if there's a few iterations that go on.

> I think detractors believe you should just let AI do the job blindly instead of leveraging it as a tool to accelerate you.

However this is how it’s marketed. C-suite is telling people eventually you won’t need to read code, frontier labs saying programmers won’t exist etc.

The reality is like you said, a tool to accelerate you.

I think a lot of us were excited that we will finally be able to polish our old software.

Many of us were never given the opportunity and were tasked to produce new features at an ever increasing pace. Depending on where you landed you can be either elated or jaded.

It's so bizarre that noone realizes that there's a bit of a difference between banging together JavaScript into websites, writing firmware for widgets, herding servers or fixing medical devices?

Most of the tech people I talk to outside of HN, Reddit, Twitter, and other debate heavy spaces have a more nuanced view. In group chats we share stories about the amazing things we got out of an LLM today, or the hilarious failures or mistakes they made. We share tips and battle stories. We talk about the pros and cons of different models. We discuss the hard things we’re doing that LLMs can’t handle yet.

Go on HN or LinkedIn or Lobsters and there are some comments from people who seem like they’re coming from a different universe or timeline. Some people claim LLMs are doing everything in their life perfectly. They’re posting thought leader Tweets about working 2 hours per day and doing everything with ChatGPT voice so they don’t even need to be at their computer. Others are claiming that LLMs are useless and they can’t get anything usable out of them at all, or that they create more problems than they solve.

It’s weird. I can’t recall a time when people in tech were having hot takes that disagreed with such polarized extremes. Like I can look at LLM output all day long and see that both of the extreme takes are not right, but they’re all steadfast in their ideas.

I see a lot of the disagreement here has the same form as many of the political arguments from 10 years ago.

Where do you suppose those misconceptions on how to use the tool comes from? That's rhetorical because the answer is obvious: the people selling the tools and their army of bots and sycophants. You can't be mad at people for being like "hey I tried to use this tool in the way it has been sold to me and its not delivering on its promises"

Every single message from him, literally every time he communicates, it's a massive wall of text, overflowing with scope-creep suggestions like nothing I've ever seen before. It's impossible to ask him a simple question and get a simple answer.

And this seems to be a broader trend with AI in general. It's getting more and more difficult to retain some semblance of brevity with AI tools. I'm constantly asking them to "be brief," and "only answer the question I asked," and "don't provide more information than I requested," but they keep churning out more than I want in their responses.

It looks like a subtle attempt to use up more tokens.

The place to find them would be performance profiles, query plans, telemetry. The guidance for perf still applies, measure before and after change.

The issue is that the code often does not contain the information to do a perf optimization. Eg. you can't tell your cache size, the volumes of data in your DB or the latency of your network through just the text. Should you provide this context, you can get better results.

that's the first mistake i made as a new claude user. i only knew what prompts people were sharing on forums. but since they had been written by vibe coders it was all complete non-sense. also think about this: software engineering is filled with highly specialised tooling that can easily improve software quality. the thing is, most developers dont know how to use them, and if they do -- using them is so slow that its almost not worth it.

any tool you can name claude can use. obscure academic proof verifiers, memory corruption scanners, debuggers, profilers, coverage tools, backdoor supply chain pattern scanners... it can run these and have results in seconds. really is like living in the future.

Performance optimization involves simulating real world loads and measurable results. Give them the opportunity to actually have a closed loop if you want more than trivial improvements.

Give Fabe 5 access to a test database with some data, or even restricted access to your live DB and tell it to optimize then.

I've had stunning success optimizing for performance this way. In a single day, I made the core part of our app 2-3x faster.

As an example Opus 5.0 is in completely different class compared to Cursor Grok 4.5 even if the benchmarks don't show such massive difference. Not even talking about regular stuff like Sonnet or Composer or stuff like that.

I was able to optimize a physical water simulation that was almost unrunnable on browsers to a buttery smooth 60fps version.

I've been using Claude to create a software architecture diagram. It came up with a lot of useful functionality that we had neglected to show but upon further examination a lot of steps didn't make any sense. It added a box to do validation on some data then it put another box downstream to do validation again on the exact same piece of data (the second box had a different name but upon questioning, Claude conceded that it was the exact same validation step). When doing inference on user input, it put a box to extract specific insights from the prompt and then it put another box to do inference again on the inferred data to categorize it... And this would add latency and unnecessarily strip out useful context when doing the second inference... It really only needed a single inference step...

I re-uploaded the diagram to Claude and confronted it and it conceded to all of my points and it even noticed a theme between them and suggested that the diagram exhibited "a pattern of redundant steps." But it was incapable of suggesting viable solutions besides name changes. All of its solutions made the design more complicated. It was incapable of simplifying the design. I've noticed this with AI code; it can make things more complicated, add more features but struggles to simplify things.

Also, AI is horrible at rating things... It's just too superficial. For example, if you write a huge amount of intentionally over-engineered, tightly coupled code with poor separation of concerns but you do proper linting, define all the types, add a lot of comments, it will give it a higher score than a shorter, more readable and maintainable snippet which exhibits loose coupling and high cohesion because it lacks the superficial aspects.

It's horrible because now business people who understand nothing about coding may ask AI about code quality and it will consistently rank low quality over-engineered projects that are full of bugs, unmaintable and less secure, with a higher score.

Frustratingly, if you point out problems in its judgement, it will concede to your points without reservation, even building on top of your argument... but it will never actually tell you this stuff up-front, unprompted if you don't already know it! It never seems to reveal new insights, at best it can only expand on existing insight which you've already had.

It tells you what you want to know but not what you need to know.

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.)

The trend I've noticed is that AI struggles to think outside the box when making optimisations, which exactly what's needed when you've made all of the practical DB and logic optimisations to the existing code.

Often you need to take a step back and question how the system is working and if there would be better ways to design it so the bottlenecks you're hitting wouldn't exist in the first place. Caching things, adding indexes, tweaking logic – these can help, but you'll quickly hit diminishing returns once you've done all of the obvious stuff.

I've seen people here say how AI is great at optimising code though, but I'm not sure if that's because they're giving it optimisation problems with a lot of low hanging fruit or if they're successfully getting AI to rework their systems to remove bottlenecks. This one area I find AI to still be particularly bad at.

Turns out folks had been copy pasting some setup code which took 2 minutes to run, and only needed to be run once per environment. Claude refactored the code to get it to run once, and since we had tests which validated the build artifacts, it was able to roll back if its change had broke the build.

It's not "hard" or novel--it's just tedious grunt work. I'm happy to have AI solving that one.

That might work better. I haven't tried it with SQL but it worked with a few complex UI issues I had. It identified the actual issue after a few false starts.

I profile sql performance and LLMs find more opportunities than I could. All it takes is real data, a sql repl and an agent. Just ask the agent to use the repl to EXPLAIN and profile the sql. It works amazingly most of the time.

But that's ok - I still get a lot of value of the tool elsewhere (e.g. writing data analysis scripts, exploring code, breaking down bug artifacts...), but it doesn't stop the tiring BS from other people going "why not just AI it?" (especially from managers).

I usually let them try to "just AI it" and most of them learn quickly that it's not that simple. (The others stay deranged and are making my job miserable.)

1. Ask Claude Code or coding agent to research the internet, documentation, and Github for examples and learning working with similar problems.

2. Make the ten best examples of solving the problem based on the research.

3. Run each against the database enough times (100, 1000, or 10,000,000 depending) to empirically prove which is optimized. You can set other criteria based on your knowledge.

4. ???

5. Profit

The point is, it is cheap to research combing through 1,000s of examples and learnings and test the best and most relevant.

Then being able to suggest several things to try and have them go off and build, measure and tweak is hugely useful in my experience.

Also things like making custom visualisations for comparing changes.

And at worst you still saved a bunch of time on writing the tooling to test the issue

I had worked on some earlier deployment environments for a few models where we focused on one version of Triton and one runtime technology. Even upgrading to a newer Triton version was brittle, involving a lot of command-line changes at various phases. This was written mostly pre-Claude-getting-real-good. I decided that probably Claude had matured and was way better at understanding the particulars of AI-model-GPU-deployment-and-technologies. I worked with Claude to make the framework a much more lightweight wrapper, ignorant for the most part of a lot of the deployment internals.

After this refactoring and doing the first couple of models, it's quite amazing at how well Claude can figure things out. For any new model we now set up its "specialization" directory and its documentation subdirectory, point Claude at the proper AI-model files, point Claude to the sample non-optimized inference code and test data, and point Claude to a similar conversion we've done in the past. There a multi-layer class hierarchy dealing with various tiers. I ask Claude to explore the existing conversion/packaging, the model, any documentation that comes with it (a lot of times there are unexpected twists), the sample code, and the desired multiple use cases the model is meant to address, and the test data. Claude has been trained, I'm sure, on a lot of AI model conversion, so it's able to synthesize the full multi-stage conversion/deployment pipeline, come up with appropriate test cases for all the use cases involved. There are usually between 3 and 10 refinements after initial synthesis, fixing outright errors, refinemnts that the data-science team requests after playing with test deployments, etc. The options and pitfalls are vast, and without Claude each preparation likely would 10x or more longer. I just put most details in Claude's hands, and make sure the general framework is good enough to provide external uniformity. When all is working, it takes a couple of hours to make sure the documentation is good.

All this to say that at least for this domain, Claude / AI has been a game-changer and has sped up the process amazingly.

That's uninteresting as long as you don't specify the model you used. For example, Mythos was far better at finding security bugs than previous models.

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.

But it's an open source project, you can go and figure out whether your assertion is correct.

If models can spot 13 years old critical bugs, I think they can also produce fresh code without those bugs. The skillset is the same.

HN is so weird on the topic of AI, and so many desperately are trying to contrive a reality. Odd stuff.

We do / have? Multiple even. Of course, the vast majority of consumers doesn't care so they don't get as much traction.

Then try starting with voice mode (if you're comfortable chatting out loud) and just talk your way through it.

Build a sandbox, download Codex CLI or Claude Code or whatever and spend some time doing some creative stuff with it just for the sake of learning how it all fits together.

Pay attention to the inputs you provide and the outputs that they result in. Keep your bullshit detector engaged: Bots often lie.

If you get stuck, or it gets stuck, or you want prompting advice or whatever: Ask any frontier-level bot for help. Sometimes, it's very instructive to get help from Claude for an issue with Codex, or vice-versa.

Want better tools? Ask the bot to suggest some that exist. (None of the existing tools fit? Have the bot write new ones.)

All of this stuff is always in a state of flux, so even with the lies they'll do better at teaching than any fixed reference will. They're LLMs and processing language is what they tend to be best at... so go ahead and use that.

And remember: They're designed to behave kinda-sorta like humans, but they are not humans. They're just computer programs. If you don't like their output style, or they don't like your input style: Ask them how to implement rules that make them knock that shit off. :)

Some were probably just theoretical "if we have over 2B of this item, it'll crash because X/Y/Z and that can be exploited", some are probably in rarely used features.

Once the LLMs are done going through the code, the baseline will be all better and they will probably fix a lot less than they have now. Or they will have LLMs automatically check every single crash bug that has been submitted and take care of those too. I am assuming that they are probably already using this as an input source for their AI.

Just open up a configuration window manually, tell if that the Window is open and it can pull apart the executable from there.

Biggest impediment would be Fable safeguards if it tries to decompile.

There are many things it's not good at (eg design and architecture), but that doesn't invalidate the things it is good at. Everyone is learning how to best use it and there are growing pains. Ignore the hype and try to find the common patterns in what people say.

Or you can bury your head in the sand while the rest of the industry is moving on, I guess.

I don't want "To Be Right", I just don't want dunces slopping nonsense into this comment chain. Not my fault you fall into that group.

I don't need to assume Google's intentions and goals here. I want to see what they've done and the results they've reached with each action. I want to learn. You just want to reaffirm your delusions, that's why you have to pull the "you will learn" card rather than show objective metrics. If you really cared about quality, you would have them ready to present. Given that you haven't and even avoided doing so, it's safe to assume, as most of us have learned through experience, this to be a case of placebo at best. And placebo is not the sign of a good programmer.

Next time, provide some actual data rather than vague self-gloating. Then, we can have a discussion.