I'll await your Rust ports of Windows, Linux and MacOS then.

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.

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 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?

You can also take the opposite conclusion from this: C++ is now viable because LLMs can catch the security bugs.

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.

C++ has had smart pointers for memory (and other resource) management for a long time now (see e.g. the Windows ATL classes for working with COM objects and resources).

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.

Assume that you are writing a green field project in C++. If you never use "naked pointers" and always use std::unique_ptr and std::shared_ptr, will it not reduce nearly all memory related bugs? I don't have a lot of experience with them, but I found it dramatically reduced memory related bugs. I'm a very average C++ programmer, and those templates helped me greatly. Do you think it would help Chrome/ium to use (more) std::unique_ptr and std::shared_ptr?

> Most if not all of the bugs being uncovered are memory related

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

The rest were logic errors of various sorts.

This seems an awful lot like confirmation bias. Web browsers are themselves extremely complicated.

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

> C and C++ are simply not fit for purpose when large scale software projects are concerned

The world runs successfully on C and C++. Ignoring that fact and claiming that Rust will magically remove all bugs is BS^2.

Rust certainly helps for certain classes of errors but doesn't help at all for logic errors or incompletely understood requirements or occasional need for hacks due to business needs.

blaming bugs on C++ has got to be the most leetcode thing I've heard in my life

You make a false equivalence between being an idiot/“didn’t know what they were doing” and not knowing how to properly manage memory. Also, why do you think the devs who worked on google chrome weren’t idiots?

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.

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.

to be fair, with AI reviews i'm finding the opposite to be true. Anytime I push a one line fix it continuously tells me about all of the edge cases I didn't handle until it's pretty much bullet proof

Google improved chrome by reading code: Google built an agent harness using Gemini to scan Chrome's codebase, trained on a knowledge base of prior CVEs and the entire Git history, with a "critic" agent consuming developer-supplied SECURITY.md files.

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.

Its also has no big picture - it just can add ever more - cancer can grow, but it will kill the host organism and end years down the line as a dead end.

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

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

If that is the case, isn't that the failure of your testing strategy/setup? If your style doesn't fit full vibe coding - you can do the path of AI generate code - human reviews and tests all edge cases flow - I think in any serious software - that should be the flow until next few iterations. But either way, don't see a going back to coding every line by hand now, those days are gone. Was fun while it lasted!

I've heard screen-reader users reporting that Chrome and Edge are now virtually unusable in their Windows screen-reader, while Firefox remains fine.

Every single new working student we get, we have to teach every single thing again.

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

[flagged]

Let's replay this post but imagine Google made this announcement before LLMs were wide-spread (say, 2019). Below, I replace "AI" with "human programmers".

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

Google's entire modus operandi has been "automate everything" for decades. They've been doing this with fuzzers, with project zero and so on. Adding LLMs on top is a very obvious next step. And LLMs improving and finding more bugs also follows. Then improve the harness and the dev tools, to better use the LLMs. And then everything together end-to-end to find-triage-fix-confirm. Your LLMs are as good as the loop they run in, and the loop is as good as the verifier. Seems a reasonable enough dynamic without (or despite, depends how cynical you wanna be) the need for managers to show number goes up on some chart.

I would guess they have been confronted with an initial flood of newly discovered bugs whenever they added a new analysis tool or approach (e.g. automated static analysis, fuzzing, ...). Once working through that initial flurry of newly discovered bugs one would assume that the frequency goes down again.

1. Our backlog of bugs gets processed quicker because instead of staring at the code for 10 minutes fiuring out what's happening, there's a tool that can reason about it quicker.

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.

> In early 2026, we saw a gradual increase in all categories of bug reports, but by March, the shift was apparent: we received more bug reports than we had in the entirety of 2025

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 will say - and this is just my own experience and not a certain userwide trend response - that one benefit of LLMs is that they are able to take an annoyed observation and format it into a pretty stellar bug report, and then the human being can work on spit-polishing. Having the middle part of the composition automated is a real benefit (at least IMO) - I've been a better reporter.

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

More likely just getting ahead of the AI attacks before they hit. The threat risk increase caused by AI has gone off the chart.

AI is very good at finding security bugs. If you are working on a product that processes hostile data like a web browser and has a security bug bounty program, your choices are either to find them yourself or be overwhelmed by external submissions.

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.

Nah they just write blog posts when they feel like it /s

Exactly, also it lacks a lot of context as to why they did that.

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

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

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.

They also don’t really provide an explanation for the big uptick in bugs found M146+ in the first place.

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

> How many introduced a new bug?

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

And how many were introduced by AI?

I assumed it was really just AI that found them, which allowed Google to know to fix them.

[flagged]

Perhaps this was due to their red-teaming partnership [1][2] with Anthropic which they wrote about a few months earlier in March?

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

Yes. AI is a tool, it’s supposed to be used a certain way, anything else is a misunderstanding og what AI is. You have to aim it in the direction you want it to go, not expect it to solve all your problems magically

AI has skills no individual can have. That part is true.

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.

Google already controls Chrome/Chromium direction so much that you should use Firefox if you value an open web.

Conversely, it has never been more feasible for alternative web browsers to be created and maintained outside of big tech.

> A lot of people here seem to be living in a different universe than me

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 agree with you.

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

Did you think for a second that maybe other people work with other languages, domains, tools and work approaches than you?

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?

This (fixing bugs, making code better, refactoring), is the best fit for AI.

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 appears to me that this is the same pattern you often see when junior employees are given one or more resources intended to help them succeed. Despite having access to those resources, there is frequently no shortage of complaints about how incompetent people are, that they "should know" esoteric home-built sowtware patterns or business knowledge without being told or that they failed to perform a task in the one specific way that someone considers the "correct" approach.

LLMs are the first tech topic I’ve seen that attracts as much wishcasting as political debates. Some people get attached to the conclusion they want to believe and get angry at anyone who disagrees with them.

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.

Reminds me those Bitcoin threads where I would explain a use case it solved for me and everyone was like "nope that's impossible, there's no use case". And before the inevitable replies come in: no, I'm not saying AI is like Bitcoin.

There is an argument that there is a lot propaganda in this space - because the issue of AI is now an issue of international security and politics.

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

Hell, $20/month is a pretty good deal for something that can proofread a 100 page report, do some light research work, and write some quick and dirty scripts. It doesn't have to replace the entire job of programming to be really damn useful. The pushback against using it even for these simple tasks seems utterly unreasonable to me.

Just exploit the edge while it lasts lol

[flagged]

> A lot of people here seem to be living in a different universe than me or simply don't know how to work with AI. I think detractors believe you should just let AI do the job blindly instead of leveraging it as a tool to accelerate you.

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"

Neither Mythos nor Gemini are open-weight models (right?) so I'm not sure what model(s) this is actually referring to.

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.

Weird, why would they use open weight models.

The thing that makes it work really well is to make sure it has all the tooling to verify its hypotheses. If you allow it to run the full lifecycle in loops you will be surprised how well it works.

The useless suggestions are exhausting. One of my co-workers uses Claude for all asynchronous communication, including Slack messages, Jira comments, code reviews, and emails.

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 mistake there is to point it at code to figure out performance optimizations.

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.

People in the comments sound like they're literally asking claude: "hey claude, can you find areas for performance improvements." Nah, it doesn't work like that. You have to be more like: "can you profile [...] and identify hot spots." then looks at results that are suspicious. if you don't ground it to the real world reality of your project then don't be surprised when it makes up its own.

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.

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

Which model/agent/harness tool did you use? I've found what you describe was my exact experience some ~6-8 months ago, but since about a month or so the game has completely changed. Using 5.6 Sol with highest reasoning setting in Codex or Fable in Code, the models come up with a list of possible improvements from static analysis (ranked by complexity/benefit), write and run their own custom profilers and deliver significant performance improvements with barely any input needed from my side. So this is no longer a model issue, it's a user toolchain issue.

Then you're not grounding it to reality properly. LLMs get bad pretty quickly when you just tell them to pull the answer out of thin air. Pin them to reality with actual performance tests to run to test theories and the results will be much better.

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.

You're using it wrong. No really you are.

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.

I've had a completely different experience. I usually know the problematic part and then ask the AI to optimize that exact part with benchmarks, telling it to try various different approaches, and it very often gains massive performance increases on various tasks, with me of course steering it and giving it pointers every now and then.

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

Which model are you using? There is monumental difference between models. Even between "frontier models". When people tell these stories, it would be great to also add which model you were using.

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.

AI can uncover certain issues and resolve certain problems but it also has its blind spots.

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.

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

I've noticed the same thing.

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.

A self validating loop goes a long way with getting AI to optimize stuff. We had some builds that used to take a long time (15-20~ minutes), that i just asked Claude to reduce the build time. It brought it down to 2 minutes and under 10 seconds for incremental builds.

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.

You have to learn to use your tools, not try whatever intuitively made sense to you at first (expecting the tool to do all the work) and then whining on Hacker News when it doesn’t work out for you.

I did a lot of SQL optimisation with claude code over the last year, what made it work for me was making sure I verify everything with explain analyze. The whole loop was not fully “agentic” because of this but it was still faster and better than when done entirely manually. Claude also suggested plenty of small optimisations I would otherwise not do.

My favorite thing lately is that it's very good at resolving dependency security vulnerabilities. GitHub already does a good job at detecting and notifying which packages are vulnerable and at what versions they're fixed, and without AI, it's just a super tedious process to figure out what things all depend on that package, find a version that'll work for all of them (potentially including upgrading the things that depend on it), wire it up, test things, and make any minor changes necessary in our code.

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

Ask it to create a small sample to reproduce the issue in isolation. If it can't reproduce the performance changes then it drops it.

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.

Echoing the other folks, I have a different experience.

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.

Yep, as a performance specialist I've had the same outcomes - it'll find "smoking guns" galore which will sound plausible and be completely wrong.

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

It is very cheap to:

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.

This is the research taste part - often they can be good but human experts are really good at this (also you know your codebase, without the prompt these models have no other background).

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.

I had good results when I started AI with building the testing for the actual problem, then it can just run itself over and over without wasting much time on verifying its output.

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

One of my tasks is to take various AI models the data science team has produced/fine-tuned and make them runnable with optimizations on GPUs (TensorRT, vLLM, Triton Inference Server, etc.), involving conversion, deploy, smoke-test, packaging, documentation, all within a uniform framework. The documentation includes model-provenance, simple deployment instructions (usually a Docker run), simple deployment test. The DevOps team takes this and tailors it to Kubernetes / helm-charts or whatever the target environment needs.

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.

I'm surprised to hear this. I've found AI incredibly useful for optimizing queries. Give it the EXPLAIN ANALYZE output of your query and it will have no problem optimizing it

> I've recently been using AI

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.

For sql, i found that it can recommend indexes that i didnt have in place. So for that part of it, its great. For optimizing code, it does an ok job, i guess.

Is this with the good Anthropic models? With extended thinking? And a way for it to validate the changes? My experience is the complete opposite.

I am not denying what you are saying but I am interested in what models you were using for these tasks?

Were you using Fable 5?

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

Did it ever tell you not to optimize what you should redesign?

CTEs are often slower than using temp tables with indexes.

What model is “AI”?

Did you give it access to a planner/analyzer?

As others have said, these were uninformed guesses which LLMs seem still to be willing to hand out deliberately. If you provide more information (your schemas, the distribution of values in your database tables, the EXPLAIN ANALYZE outputs, DB configuration etc.) it will do a much better job.

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.

Which model/mode?

Why are you sidetracked instead of piping that to another AI?

[dead]

[dead]

[flagged]

[flagged]

Can't have been much, as the Chrome project is 20+ years old and LLMs have only recently become a thing; they did not slacken their code review and testing practices with the advent of LLM code generators. And I doubt they do much development on the affected areas at the moment, they mention a 13 year old issue for example.

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

If people are handing off the coding to AI more and more then they'll be less skilled at spotting potential bugs in the first place. AI, course of, could be run to find potential bugs in the AI-coded features before commit. But then you're getting further and further towards a world where code, and code that runs infrastructure, is incomprehensible. We'll have to start sacrificing the first-born to the silicon in the hopes of a good build for code that controls your electrical sub-station.

Look at the git stats for the project. Lines of code submitted haven't changed dramatically. Not everyone is just merging slop into the codebase. There are many ways to use AI, and most established players are not merging vibe coded nonsense.

If you assume that AI can produce code with less bugs, your 100 times increase in fresh bugs means you also increased your speed for new functionality by more than 100 times.

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.

That is a stat you invented out of thin air, based upon nothing but pejorative hope, against all logic or rational consideration of the timeline or the scale of the project, and you declare it the "elephant in the room"?

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

Company advertises their products. In other news, water is wet

> We really need an alternative to this greedy and evil corporations de-facto controlling a huge portion of the modern www stack.

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

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

There are zero mentions of Project Glasswing or Mythos in the blog post. I wonder why.

Title is accurate if imprecise. Security bugs are a subset of bugs.

Yes, it is relatively easy to find any solution to a bug. It is hard to find the root cause and change only what is necessary to fix the bug. AI makes it very efficient to "fix" bugs with code that needs to be fixed again later. The big problem in fixing bugs is understanding what is causing it, not to suggest a temporary "bug fix".

Concerning even

The best option at this point is to just sign up for a paid plan with either ChatGPT or Claude and then ask the model the same thing. My preference would be for ChatGPT and if you've been out of the game for a long time then using the desktop app might be the best choice https://chatgpt.com/codex/

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

Just jump in.

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

won't forgive them either for making it harder to filter out ads

Old bugs at the bottom of the prioritization list deserve to be fixed.

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.

The whole point is that these are security bugs that didn't necessarily bother people so far but could be exploited

Didn't expect to see the goalposts moved to "AI can fix bugs but do they even matter"

If only there was alternative browsers...

Like what?

Honestly, there's a 50-50 chance that you'd be able to do this in Claude today, even without access to the source code.

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.

At this time, a generic AI snark is tiring. AI is not perfect, but it's an amazingly useful tool, we should accept it and move on.

I’ve heard from people inside Google that they’re prohibited from using anything but their own models. AlbertaTech on YT, ex-Google working on YT said in a video that right before she quit someone had threatened to quit if they couldn’t get access to Claude Code

The Gemini (and Claude / Codex) that we have, is much different to their internal models / harnesses.....

There is hype, but there are also real tangible wins as well. Analyzing code for bugs is something that works very well. We use it for helping us revert changes that lead to a flaking test and it's dramatically faster than previous techniques. It's great at suggesting duplicate bug reports. It's amazing at scaling an API migration throughout a codebase. It's great at prototyping an idea before you decide to do it properly.

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.

You seem to be proficient at monologuing towards walls. Perhaps that's why you keep assuming people will just take your word.

All the evidence is against you here, sorry. Just read the google or microsoft security blogs, linux kernel mailing list, or any of the published security research about bug density in Rust vs C++.

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

This post is basically a massive projection. When I guess, I make my guesses explicit. You, however, consistently make guesses and pretend they are true. You misinterpret facts so you can conveniently fit them into your narrative.

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.

How about you elaborate instead of vague posting?

I don't know about Chromium specifically, but in general Google requires 2 humans to have looked at every change (normally one is the author, but not necessarily for bot-authored changes).

Did you go and look at their open source repositories and open code review tools instead of fearmongering on HN? The answer can be found.

Google has not really embraced vibe coded slop. Humans are involved before any code merges and the quality bar remains high.

I'm not sure why you're asking here instead of opening the ticket and having a look at the current status.

It's not a bug but a suggestion rejected by the team (cuttent status: Won't fix, obsolete)