Google fixed more Chrome bugs in June than over the past two years, thanks to AI
blog.google
blog.google
It's fine for a C or C++ program encompassing a couple hundred lines but beyond that it's a liability.
C and C++ are simply not fit for purpose when large scale software projects are concerned. All of these need to be ported to Rust or another memory-safe language ASAP to prevent mayhem.
The hundreds if not thousands of developers working on Chrome weren't idiots who didn't know what they're doing. The complexity of programming in C/C++ is simply beyond most intelligent individuals' ability to get perfect all the time.
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.
One surprising thing is that, in the grand scheme of things, developing an alternative like Rust is not that expensive. It takes something like a small team a few years. Maybe a person-decade of effort to get to a viable point? Maybe two, whatever. The industry as a whole throws away orders of magnitude more engineering-years than that on vanity projects and internal dysfunction every year.
Of course, even once we have an alternative, the switching costs are high. And the barriers are far more social, organizational and political than they are technical. But even so, moving to alternatives incrementally has been viable for decades. And hey, if we include moves to garbage collected languages, we have been moving quite a bit... but we could have been moving more. It was only a matter of will and, upstream of that, cultural change.
So really, the problem isn't that people complain too much, it's that they don't complain enough :)
I always remind people that C is a systems programming language and not fit for regular application programming. For that you need an application programming language like Pascal or Java.
Unironically this. Like most game developers, I was extremely sceptical of Rust, based on opinions I've read on the internet. Ugliest syntax I've ever seen, and "safety" features are irrelevant and just get in my way. Compile times are glacial. Tons of direct and indirect dependencies needed.
But then I got to use it professionally for a year or so, and I was MINDBLOWN by how much less stuff I have to keep in my working memory at all times. And libs like tokio and actix-web were so well-designed that I actually enjoyed reading the code in my free time. Fighting the borrow checker? I had like five such instances in the first month, understood what it wants and why, and it never bothered me again. Compiles were indeed slow, but I went from "if it complies the first time around, I'm probably missing something" to "if it compiles the first time around, it's most likely correct".
Turns out, I had significantly underestimated what Rust brings to the table, while focusing on stuff that wasn't really that important once you get used to it.
Nowadays I'm back to gamedev. I'm happy about that, because my year in cloud/edge dev felt like we were consistently solving the wrong problems. But I do wish my current team was more open to giving Rust a chance. It solves so many actual problems, and is being dismissed with reasoning like "sorry, I don't have programming socks". And by very smart people! WTF is this timeline?
That doesn't mean we shouldn't do it.
I’d love to have that happen within the next century. I might not be around for it, but I’d say that humanity deserves software that has fewer memory issues.
> 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?
Luckily one of the perks of A.I. is that it makes large scale code migrations feasible in a timely manner.
I'll quite happily say they were never fit for purpose. C had a role in bootstrapping early software development in the absence of anything better but once Lisp, Delphi, Smalltalk and Java arrived on the scene then it, and its equally footgunnable variants, should have been pushed to the margins where hardware constraint was the primary consideration.
Writing a browser in C++ in the 21st century was ridiculous and irresponsible.
It worked well enough, maybe "fit for purpose" is a stronger word
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.
Maybe Rust let's you encapsulate the unsafe a little better than C++ but the wins are going to be surprisingly small. If you had to build it today you'd maybe use Rust but the case for rewriting an existing C based runtime in Rust is not that strong.
Also for things like interpreter loops the absence of computed goto in Rust stable is a real performance killer. Explicit tail calls (the `become` keyword in nightly) work but maybe you don't want your big rewrite to rely on that.
For example, lot of C++ objects are tied to a garbage collected object in JS, so you need something special to hold a reference in C++ code to those, and prevent them from being garbage collected.
Another example, shared_ptr is fine if you eventually drop the reference count to 0, but in JS, you will have cycles, so the reference count will never get there. And that's one of the problems the garbage collector deals with, it checks cycles and connectivity to mark a group of objects to be released together. So you will have a special life-cycle for those objects. Another responsibility if that you can't really use the destructor there or you might trigger a delete storm and block the thread. So the garbage collector will destroy objects in batches when the page is idle no to create stuttering (jank).
It will, as long as the code uses them correctly all the time, including when refactoring. In the end, that's still manual memory management.
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!
The world runs successfully on C and C++. Ignoring that fact and claiming that Rust will magically remove all bugs is BS^2.
Logic errors are "out of scope" for Rust or any other programming language.
It is simply impossible, even for the smartest human minds, to manage this kind of complexity. And this is a fact.
Also better defaults.
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.
For many of the new bugs, do we think they would all have been prioritized in the past? Are these all critical bugs that would have all been addressed in a timely fashion or are they getting done because its easier to do.
Another way to ask it would be, do we think we're discovering that Chrome had more big holes than we thought or are we raising the security bar by fixing smaller holes?
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.
Linux Kernel: https://lore.kernel.org/all/CAHk-=wi4zC+Ze8e+p3tMv8TtG_80Kzs...
The idea that software has gotten so complex that a machine can evaluate code paths better than a human, seems to bristle the fur of many. Some people didn't think we would see the day where that comparative human limitation was laid bare in simpler tasks than they expected. I believe older developers are less likely to be offended, having to deal with this as a matter of course (as the mind declines).
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.
The big problem is that AI 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.
My own reviews have shifted now. I tend not to examine detailed semantics anymore. The AI is as good or better than me at assessing whether a chunk of code does what the author said it was supposed to do.
Instead my job is to spot design and architecture smells, broader semantic errors, violations of unspoken business requirements, etc.
For example, I was recently reviewing code that built out a transactional flow. Part of that flow involved recording the transaction somewhere user visible and I knew that should only happen after the transaction was confirmed. AI implemented it where the transaction was posted.
That starts as an issue of underspecified requirements but that always happens in the real world. Thus that's where I can provide the most valuable insight: assessing with that context, whether business, operational, historical, or forward looking.
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 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
So…are you planning to hire only seniors who already know everything? Where do these seniors come from?
The "engineers" using that AI. Could they repass the whiteboard tests of old? Have not some of them quietly left?
> 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.
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.
Saying “never used it” or “I tried and it was useless” was literally not possible.
I come to HN to read about AI failures and disappointments.
If you were the CEO of Amazon, would you be setting up channels for people to talk about their AI failures? The general way technology is deployed is that we try to find ways to make it work, because those are the most interesting. We're not as interested in all the ways it doesn't work.
From my perspective, some people are trying to use AI in the same way somebody might use a laptop to paddle a canoe. Sure, you can do it, but it's not a good idea. The fact that it doesn't work well is not particularly interesting.
If I steelman your position, I guess the ideal repository would be a set of cases where it's known to work well and a set of cases where it's known to not work well. A little bit like ProtonDB or SteamDB, perhaps.
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....
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
Adversarial testing, checking developer assumptions, refactor suggestions, small dev tools and even some guided coding all sit on the other side of the spectrum of what you can do with coding and AI. For larger and larger codebases even simple things like tracing dependencies or behavior might be greatly aided.
And the critiques reserved for that narrow bucket on the other end, blindly generating code, are too easily conflated with the rest.
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.
Recently I noticed an unusually high number of web inspector bugs fixed by one longtime WebKit engineer, and I suspected AI assistance, though the commit messages include no disclosure of this. Nonetheless, the increase in volume was quite dramatic.
The other day, an update to Safari Technology Preview was released, and I attempted to verify whether a couple of my bugs were indeed fixed. However, it was impossible for me to verify, because the latest version of Safari Technology Preview introduced a new web inspector bug that totally broke the features I was testing.
Thus, I remain unimpressed.
Without a doubt, LLMs have demonstrable skills and can produce code much faster than humans. I never thought that producing code fast was wise, though, even before LLMs arrived. For many years I've criticized software development based on management-driven release schedules, where developers are forced to pump out code regardless of quality, regardless of whether it's ready. Your boss may not like it, but code is done when it's done, not when your boss says it has to be done. If software complexity were predictable and reproducible, then indeed management could replace engineers with automation, but that's not how it works in reality.
Back to Chrome, the browser is notorious for continually adding invasive new "features" to the web that nobody wants except advertisers. I wonder how many Chrome bugs were the result of Google push push pushing all of this new crap on users over the years?
I think I'll abandon this discussion and keep using AI quietly while exchanging tips with like-minded people who are interested in using it properly and efficiently.
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've found AI to be immensely useful in gamedev, mainly UX development, research, and curation. In those areas I let it go quite wild, with mechanical and visual tests for UX, and summaries for research and curation. I've also made skills, custom subagents, hooks, and scripts (all made with AI assistance) to streamline development.
Gamedev is a good example of where AI shines, since the risks of fucking things up are not so big. If I worked on, let's say banking, I'd be much more careful. On my day job, as a data scientist (moving towards product owner) in a large industrial company, I'm much more careful. UX can run on vibes, but anything that touches data processing or business logic needs to be looked at by a human, row by row. Depending on use cases, it may be fine to look at only the tests. The main problem is that there's so much stuff to review, and maybe 98% of it is fine. It's then very boring to try to spot the 2%. I don't have good solutions for that yet, and idk if anyone does.
I also encouraged my team to paste any inquiries or alerts we got in our slack channel verbatim into codex and follow that procedure until it could figure it out as a one-shot.
I still treat it as more of a design and coding partner day-to-day, so I'm typically not trying to one-shot, but it can e.g. be triggered by a pagerduty alert, reference our code, check grafana panels, query application state across different servers/clusters, and come up with bug fix PRs all autonomously, and then post its analysis, mitigation suggestions, and PR link to slack for the on-caller to review. This was all just some docs, scripts, and a little listener service to trigger a one-shot model prompt that we built.
As a design partner, it's made it easier to add more telemetry or create rapid prototypes to check my assumptions. I've encouraged my team to regularly ponder on what facts they wish they knew, no matter how difficult it would be to find out. Pretend you could just ask God anything you want to know. Then ask the AI to go add whatever's needed to find out. We should all move toward a perfect intuition for what our system is doing because all questions can now be easily answered if we can only think to ask them.
But one thing that doesn’t change is the need to specify an end goal correctly and precisely. I think the emphasis of knowledge/information-processing work is going to increasingly be placed on verification mechanisms. This is practically equivalent to precisely defining an end goal.
Spend time deeply thinking about what it means for a solution to be correct. What properties will a correct solution have? What of those properties are testable? Write those things down and tell the agent.
As models get better, agents will be able to target more and more difficult end goals. The strategy just becomes more useful. (It’s useful for people as well.)
For example, if you want an agent to write a photo editor, think about what end properties the editor should have. There are reference images for color space and rendering transformations. That’s a good start.
Sometimes the goal will be fuzzier. “I want a feature like CaptureOne where I provide a reference image and it makes my image look like that.” Well, time to think really hard about what that means. Iterate with AI on how to test for that precisely. Come up with some good metrics/heuristics. Maybe it means local contrast should match. Maybe the overall distribution of colors. Maybe something more complicated.
Then you have a target and you can let an implementation agent work against that. If it fails, it’s either because the agent is bad or your target was incorrect or incomplete. As models get better, the limiting factor becomes your ability to correctly define a problem.
I also ask direct questions to AI for brainstorming and advanced programming language usage. In these cases, AI isn't touching the code.
Or you can also use it piece-meal and have it do parts of work that you want. It works in both ways and works really well.
I don't think there is any model right now that you can use with 0 oversight, but you can do pretty complex stuff without writing single line of code at this point.
I do not know what the secret sauce is.
But I have a responsibility to the team I lead. I need to protect our velocity. Which means that my hiring practices now include specific checks that people are able to work with ai.
In the end, it might be a step thing. Some people are just inherently incapable of working with this technology...
if the complexity is high but you know how the task is to be done then what you can do is divide the task into pieces yourself or with the help of the LLM and use an LLM for each piece.
if the task is complex and you don't have a good idea how it is to be done then you need to start exploratory work with the LLM (multiple sessions, don't reuse the sessions for code).
how to use an LLM correctly is a skill in and of itself. the people who say that LLM's are bad either haven't used any good ones and have such disorganized thinking processes that they are unable to encode them into English good enough for an LLM.
> 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.
If you test each feature and have it iterate on your feedback, you can build a decent product in this way.
Does it write too much code? Perhaps. Could I bring those 100k lines through code review in a team where some members nitpick? No.
That does not change the fact that it works, and that you do not need to read the code even today.
Unless progress slows down dramatically and soon, it seems rather likely that most of us will not be reading code in the near future. Their marketing is not wrong.
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?
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.
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 think LinkedIn belongs in a natural category with Reddit and Twitter far more than HN does.
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"
In fact, if it wasn't for the fact that it made making the actual changes I identified much easier (move these joins into a CTE etc) it would have been a detriment. Not only did I get sidetracked by a bunch of useless suggestions but I also had to put up with others dumping their raw AI output at me as if it was somehow a meaningful contribution.
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.
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.
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.
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.
> Added support for model interoperability to leverage the unique strengths of both open-weights and proprietary models
Because creating 100x more bugs and fixing 100x more isn't something to be proud of.
But it's an open source project, you can go and figure out whether your assertion is correct.
They obviously have the full git blame statistics but chose not to include them in the blog post, which is a bit concerning.
That's not a great argument. GPT3.5 was launched over 4 years ago, so that's already significant compared to Chrome's age. LLMs notoriously also produce more verbose code than a human, so its not out of question that it might produce 5x more bugs on average given the same time frame.
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.
As if humans are incapable of spotting critical bugs simply because they've existed for a long time? And we know humans don't produce fresh bug-free code, because the old bugs exist.
HN is so weird on the topic of AI, and so many desperately are trying to contrive a reality. Odd stuff.
This is wrong on almost every count.
1. The numbers are by milestone not month.
2. The latest milestone (or month) did not exceed the previous two years of milestones.
3. The only thing discussed are security bugs, not bugs in general.
What is true: the article is about Chrome.
Google Home became so unbelievably buggy, and I felt so betrayed by that, that I stopped using every single Google product - from Gmail to Android to Google Cloud Platform. The few physical Google devices that I'm yet to replace account for 10% of my tech, but still cause 90% of my problems.
Google.
We really need an alternative to this greedy and evil corporations de-facto controlling a huge portion of the modern www stack. All decision-making processes are here subjugated to what fits Google's adEmpire. This is a perpetual system of control amplifying abusive systems in place. We already see this with the recent age sniffing; Google just yesterday announced that all android users must hand over their age to everyone else. Before that google kicked out or locked out open source alternatives to android (or, at the least, made their life significantly harder than before). These are not isolated ways of abuse - this is systematic abuse.
We really need alternatives to Google here. It can not be that one tyrant company dictates so much of people's open lives (and no, Firefox is no alternative; Mozilla is basically a nerfed and bribed entity that has given up on firefox many years ago already; ladybird may become an alternative at one point in time, but right now is not and there are questions over how Kling handles the overall project, but these complaints are significantly below what Google is doing globally here).
Fixing more bugs in the adChromium code base does not change the underlying problem at hand.
We do / have? Multiple even. Of course, the vast majority of consumers doesn't care so they don't get as much traction.
You're absolutely right! Let me fix that.
On the other hand, my experience so far has been that they are terrible code-reviewers, to the point almost everyone ignores any kind of generic LLM review entirely (correctly - most of it is noise).
I feel the industry obsession with full-automation causes them to go down the wrong rabbit-holes on full-automation vs augmentation. In my view would be significantly more effective if the LLM review process in forge-tooling was designed with a human reviewer in the loop. The goal imo should be drastically improving the review efficacy & throughput of the human element, who needs to be acquiring confidence in & socializing the change in any sane org anyway. For example iteratively & interactively rubber-ducking out analysis + remediation, or interactively providing focusing guidance on the patch, instead of as agentic batch or harness processes as is cool nowadays. Sometimes a custom REPL is just better for an expert system. These things matter more as more and more code is LLM generated.
First they made it so when it came to rest it would then start scrolling again and overshoot by 2 lines before coming to a halt.
They fixed that after a few weeks then it worked until last week and now it’s left in a state where as it’s coming to a halt it jerks every time like dropping frames of the scroll almost.
I know it’s not my machine, config or trackpad because I’m seeing it on multiple computers.
Any tips?
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. :)
I've mostly only used Codex for reviews, for Godot/GDScript code, and it helped me catch bugs that would've taken me ages to even notice on my own; games be tricky like that.
Claude was mostly useless or annoying up until the last time I tried it (about 3 months ago)
You have to be vigilant though: Codex often picks out obscure edge cases and suggests adding multiple new functions and flags to avoid issues that would be better off left as fast-failure crashes. Maybe that's because of the 5.6 Sol Max I leave it on.
Google claims to help open source developers, but donates millions to the Alpha Omega Foundation that did not give access to Mythos to Curl and only found one issue.
The Alpha Omega people appear to be selected on physical appearance and take the money away from open source without doing much.
The entire Chrome article is obviously directed at suits and unsurprisingly hypes AI for better promotion chances.
> the “latent security issue.” Code that is safe and robust in isolation can be transformed into a critical vulnerability by an entirely unrelated, minor logic change elsewhere in the tree.
Similarly, you can accidentally fix a bug without discovering/triaging it, so the pointless repeated bug lifecycle is incomplete
Might as well be that the learning here is that if you put resources on fixing bugs, you can in fact fix a lot of bugs.
But since Google cares mostly about its investors, the numbers and a mention of Gemini in such a blog post are more important.
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 to have a sense of proportion, considering an average software engineer salary of $200k, that same money would buy you 650,000 engineer-year salaries. Of course there are other expenses, but that gives you an idea of the order of magnitude.
I'll believe in AI when I get to resize my Configuration Manager!
https://developercommunity.microsoft.com/t/Resize-configurat...
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.
And introduced how many new bugs? thanks to AI ...
Do you import new more bugs?
Fast foot didn't kill fine dining, but it is killing us..
I'm wondering what the Alphabet employees still commenting on this forum have to say about it? I guess for the right comps they can keep their mouths shut no matter the high level of idiocy involved.
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.
I got Codex to find and apply a bunch of settings I didn't know about and in the future I hope to use AI to make real changes in performance that venders probably don't have time or resources for.
that being said, what I've learned so far is essentially WhyIsItAlwaysHN's entire comment "The place to find them would be performance profiles, query plans, telemetry."
I just find it so frustrating that for a user interface that was basically solved in the 90s, Windows GUI still struggles to survive on hardware exceptionally more powerful than what we had 30 years ago
0 - https://www.lacksan.com/updates/ 1 - https://github.com/Lacksan-Dev/HP-ZBook-Performance