alt.hn

3/6/2026 at 11:53:18 AM

Hardening Firefox with Anthropic's Red Team

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

by todsacerdoti

3/6/2026 at 7:57:50 PM

I recommend that anyone who is responsible for maintaining the security of an open-source software project that they maintain ask Claude Code to do a security audit of it. I imagine that might not work that well for Firefox without a lot of care, because it's a huge project.

But for most other projects, it probably only costs $3 worth of tokens. So you should assume the bad guys have already done it to your project looking for things they can exploit, and it no longer feels responsible to not have done such an audit yourself.

Something that I found useful when doing such audits for Zulip's key codebases is the ask the model to carefully self-review each finding; that removed the majority of the false positives. Most of the rest we addressed via adding comments that would help developers (or a model) casually reading the code understand what the intended security model is for that code path... And indeed most of those did not show up on a second audit done afterwards.

by tabbott

3/7/2026 at 1:05:38 PM

I have a few skills for this that I plug into `cargo-vet`. The idea is straightforward - where possible, I rely on a few trusted reviewers (Google, Mozilla), but for new deps that don't fall into the "reviewed by humans" that I don't want to rewrite, I have a bunch of Claude reviewers go at it before making the dependency available to my project.

by staticassertion

3/6/2026 at 8:27:27 PM

I'm curious: has someone done a lengthy write-up of best practices to get good results out of AI security audits? It seems like it can go very well (as it did here) or be totally useless (all the AI slop submitted to HackerOne), and I assume the difference comes down to the quality of your context engineering and testing harnesses.

This post did a little bit of that but I wish it had gone into more detail.

by Analemma_

3/6/2026 at 9:28:26 PM

The HackerOne slop is because there's a financial incentive (bug bounties) involved, which means people who don't know what they are doing blindly submit anything that an LLM spots for them.

If you're running the security audit yourself you should be in a better position to understand and then confirm the issues that the coding agents highlight. Don't treat something as a security issue until you can confirm that it is indeed a vulnerability. Coding agents can help you put that together but shouldn't be treated as infallible oracles.

by simonw

3/7/2026 at 1:10:23 AM

That sounds like the same problem (a deluge of slop) with a different interface (eating straight from the trough rather than waiting for someone to put a bow on it and stamp their name to it)?

by hansvm

3/7/2026 at 1:33:06 AM

I've found it's pretty good. It's really not that much of a burden to dig through 10 reports and find the 2 that are legitimate.

It's different from Hacker One because those reports tend to come in with all sorts of flowery language added (or prompt-added) by people who don't know what they are doing.

If you're running the prompts yourself against your own coding agents you gain much more control over the process. You can knock each report down to just a couple of sentences which is much faster to review.

by simonw

3/7/2026 at 2:44:49 AM

You also probably have a much better idea of where the unsafe boundaries in your application are. Letting the models know this information up front has given me a dozen or so legitimate vulnerabilities in the application I work on. And the signal to noise ratio is generally pretty good. Certainly orders of magnitude better than the terrible dependabot alerts I have to dismiss every day

by Mapsmithy

3/7/2026 at 6:15:15 AM

Seems very similar to turning on compiler warnings. A load of scary nothings, and a few bugs. But you fix the bugs and clarify the false positives, and end up with more robust and maintainable code.

by stubish

3/6/2026 at 10:29:06 PM

The question still is: will enough useful stuff be included, to make it worth to dig through the slop? And how to tune the prompt to get better results.

by johannes1234321

3/6/2026 at 11:53:27 PM

I assume it's just like asking for help refactoring, just targeting specific kinds of errors.

I ran a small python script that I made some years ago through an LLM recently and it pointed out several areas where the code would likely throw an error if certain inputs were received. Not security, but flaws nonetheless.

by unethical_ban

3/6/2026 at 10:42:03 PM

Best way to figure that out is to try it and see what happens.

by simonw

3/6/2026 at 11:36:28 PM

[claimed common problem exists, try X to find it] -> [Q about how to best do that] -> "the best way to do it is to do it yourself"

Surely people have found patterns that work reasonably well, and it's not "everyone is completely on their own"? I get that the scene is changing fast, but that's ridiculous.

by Groxx

3/7/2026 at 12:05:15 AM

There's so much superstition and outdated information out there that "try it yourself" really is good advice.

You can do that in conjunction with trying things other people report, but you'll learn more quickly from your own experiments. It's not like prompting a coding agent is expensive or time consuming, for the most part.

by simonw

3/6/2026 at 11:44:21 PM

/security-review really is pretty good.

But your codebase is unique. Slop in one codebase is very dangerous in another.

by nl

3/7/2026 at 9:35:07 PM

that's kinda what I was looking for tbh. I didn't know that was an option, and nothing in the thread (or article) seemed to imply it was.

I was mostly working off "well I could ask claude to look at my code for security problems, i.e. 'plz check for security holes kthx', but is that really going to be the best option?". if "yes", then it would kinda imply that all the customization and prompt-fiddling people do is useless, which seems rather unlikely. a premade tool is a reasonable starting point.

by Groxx

3/6/2026 at 10:46:53 PM

That depends on how the tool is used. People who ask for a security vulnerability get slop. People who asked for deeper analysis often get something useful - but it isn't always a vulnerability.

by bluGill

3/6/2026 at 10:54:59 PM

You're either digging through slop or digging through your whole codebase anyway.

by ronsor

3/6/2026 at 8:55:25 PM

We split our work:

* Specification extraction. We have security.md and policy.md, often per module. Threat model, mechanisms, etc. This is collaborative and gets checked in for ourselves and the AI. Policy is often tricky & malleable product/business/ux decision stuff, while security is technical layers more independent of that or broader threat model.

* Bug mining. It is driven by the above. It is iterative, where we keep running it to surface findings, adverserially analyze them, and prioritize them. We keep repeating until diminishing returns wrt priority levels. Likely leads to policy & security spec refinements. We use this pattern not just for security , but general bugs and other iterative quality & performance improvement flows - it's just a simple skill file with tweaks like parallel subagents to make it fast and reliable.

This lets the AI drive itself more easily and in ways you explicitly care about vs noise

by lmeyerov

3/6/2026 at 8:29:27 PM

No mention of the quality of the engineers reviewing the result?

by ares623

3/7/2026 at 1:21:42 AM

This is exactly how I would not recommend AI to be used.

“do a thing that would take me a week” can not actually be done in seconds. It will provide results that resemble reality superficially.

If you were to pass some module in and ask for finite checks on that, maybe.

Despite the claims of agents… treat it more like an intern and you won’t be disappointed.

Would you ask an intern to “do a security audit” of an entire massive program?

by SV_BubbleTime

3/7/2026 at 1:51:38 AM

My approach is that, "you may as well" hammer Claude and get it to brute-force-investigate your codebase; worst case, you learn nothing and get a bunch of false-positive nonsense. Best case, you get new visibility into issues. Of _course_ you should be doing your own in-depth audits, but the plain fact is that people do not have time, or do not care sufficiently. But you can set up a battery of agents to do this work for you. So.. why not?

by padolsey

3/7/2026 at 2:00:13 AM

IMO the key behavior is that LLMs are really good at fuzz testing, because they are probabilistic monkeys on typewriters that are much more code-aware than a conventional fuzz tester. They cannot produce a comprehensive security audit or fix security issues in a reliable way without human oversight, but they sure can come up with dumb inputs that break the code.

The results of such AI fuzz testing should be treated as just a science experiment and not a replacement for the entire job of a security researcher.

Like conventional fuzz testing, you get the best results if you have a harness to guide it towards interesting behaviors, a good scientific filtering process to confirm something is really going wrong, a way to reduce it to a minimal test case suitable for inclusion in a test suite, and plenty of human followup to narrow in on what's going on and figure out what correctness even means in the particular domain the software is made for.

by creatonez

3/7/2026 at 5:25:39 AM

>the key behavior is that LLMs are really good at fuzz testing, because they are probabilistic monkeys on typewriters

That's exactly what they're not. Models post-trained with current methods/datasets have pretty poor diversity of outputs, and they're not that useful for fuzz testing unless you introduce input diversity (randomize the prompt), which is harder than it sounds because it has to be semantical. Pre-trained models have good output diversity, but they perform much worse. Poor diversity can be fixed in theory but I don't see any model devs caring much.

by orbital-decay

3/7/2026 at 6:14:54 AM

What is there to loose in trying?

Basically, don't trust AI if it says "you program is secure", but if it returns results how you could break it, why not take a look?

This is the way I would encourage AI to be used, I prefer such approaches (e.g. general code reviews) than writing software by it.

by krzyk

3/9/2026 at 2:24:01 AM

Because if you want the work done correctly, you WILL put the time you thought you were saving in. Either up front, or in review of its work, or later when you find out it didn’t do it correctly.

by SV_BubbleTime

3/7/2026 at 3:09:00 AM

It depends whether anyone was ever actually going to spend that week doing it the "hard" way. Having Claude do it in a few minutes beats doing nothing.

Put another way: I absolutely would have an intern work on a security audit. I would not have an intern replace a professional audit though.

It's otherwise a pretty low stakes use. I'd expect false positives to be pretty obvious to someone maintaining the code.

by eli

3/7/2026 at 3:26:32 AM

My point is that it’s one thing to say I want my intern to start doing a security audit.

It’s another thing to say hey intern security audit this entire code base.

LLM’s thrive on context. You need the right context at the right time, it doesn’t matter how good your model is if you don’t have that.

by SV_BubbleTime

3/7/2026 at 4:42:43 AM

> Would you ask an intern to “do a security audit” of an entire massive program?

Why not?

You can't relies solely on that, but having an extra pair of eye without prior assumption on the code always is good idea.

by j16sdiz

3/6/2026 at 1:18:21 PM

It's cool that Mozilla updated https://www.mozilla.org/en-US/security/advisories/mfsa2026-1... because we were all wondering who had found 22 vulnerabilities in a single release (their findings were originally not attributed to anybody.)

by mmsc

3/6/2026 at 11:03:18 PM

Use After Free Use After Free Use After Free Use After Free Use After Free Use After Free Use After Free.

I would be more satisfied if they gave a proper explanation of what these could have lead to rather than being "well maybe 0.001% chance to exploit this". They did vaguely go over how "two" exploits managed to drop a file, but how impactful is that? Dropping a file in abcd with custom contents in some folder relative to the user profile is not that impactful other than corrupting data or poisoning cache, injecting some javascript. Now reading session data from other sites, that I would find interesting.

by himata4113

3/7/2026 at 3:10:13 AM

You should generally assume that in a web browser any memory corruption bug can, when combined with enough other bugs and a lot of clever engineering, be turned into arbitrary code execution on your computer.

by mccr8

3/7/2026 at 3:11:42 AM

The most important bit being the difficulty, AI finding 21 easily exploitable bugs is a lot more interesting than 21 that you need all the planets to align to work.

by himata4113

3/7/2026 at 12:17:44 AM

If you can poison cache, you can probably use that a stepping stone to read session data from other sites.

by hedora

3/6/2026 at 10:46:48 PM

Looks like a lot of the usual suspects

by dmix

3/7/2026 at 1:10:49 AM

This resonates. I just open-sourced a project and someone on Reddit ran a full security audit using Claude found 15 issues across the codebase including FTS injection, LIKE wildcard injection, missing API auth, and privacy enforcement gaps I'd missed entirely. What surprised me was how methodical it was. Not just "this looks unsafe" it categorized by severity, cited exact file paths and line numbers, and identified gaps between what the docs promised and what the code actually implemented. The "spec vs reality" analysis was the most useful part.

Makes me think the biggest impact of LLM security auditing isn't finding novel zero-days it's the mundane stuff that humans skip because it's tedious. Checking every error handler for information leakage, verifying that every documented security feature is actually implemented, scanning for injection points across hundreds of routes. That's exactly the kind of work that benefits from tireless pattern matching.

by gzoo

3/6/2026 at 12:14:26 PM

The fact there is no mention of what were the bugs is a little odd. It'd really be nice to see if this is a "weird never happening edge case" or actual issues. LLMs have uncanny abilities to identify failure patterns that it has seen before, but they are not necessarily meaningful.

by fcpk

3/6/2026 at 1:49:37 PM

The fact that some of the Claude-discovered bugs were quite severe is also a little more than something to brush off as "yeah, LLM, whatever". The lists reads quite meaningful to me, but I'm not a security expert anyways.

by larodi

3/6/2026 at 12:29:14 PM

I’m guessing it might be some of these: https://www.mozilla.org/en-US/security/advisories/mfsa2026-1...

by deafpolygon

3/6/2026 at 12:30:11 PM

Yeah, the ones reported by Evyatar Ben Asher et al.

by muizelaar

3/6/2026 at 1:33:49 PM

I correctly misread that as “et AI”.

by robin_reala

3/6/2026 at 6:43:04 PM

we can put that one next to the Weird AI Yankovic music generator.

by moffkalast

3/6/2026 at 1:37:22 PM

“et AI, Brutus!"

by deafpolygon

3/6/2026 at 1:57:50 PM

Yon Claude has a lean and hungry look.

by tclancy

3/6/2026 at 2:27:06 PM

An LLM by any other name would hallucinate the same

by deafpolygon

3/6/2026 at 4:38:53 PM

Anyone still reading down here will appreciate this https://bsky.app/profile/simeonthefool.bsky.social/post/3kbk...

by tclancy

3/6/2026 at 6:32:02 PM

Hang on, someone downvoted me for a horrific pun? GOOD.

by tclancy

3/6/2026 at 9:19:59 PM

I upvoted, so maybe that restored the balance.

by deafpolygon

3/7/2026 at 2:35:41 AM

Out, out, vile upvote.

by tclancy

3/6/2026 at 11:38:49 PM

He computes too much.

by nervysnail

3/6/2026 at 12:27:13 PM

Indeed, without it looks like a fluffy marketing piece.

by pjmlp

3/6/2026 at 3:48:39 PM

And now that you know that it isn't, do you feel differently about the logic you used to write this comment?

by tptacek

3/6/2026 at 4:10:27 PM

i am curious, what are you hoping to get out of this comment? will you feel better if they say yes? what is your plan if they say no?

by john_strinlai

3/6/2026 at 4:13:18 PM

I genuinely want to understand how they arrived at the claim that this was a fluffy marketing piece. Like, if you said on a different thread, "the Linux kernel is probably mostly written in Pascal", I would really want to understand how it was you got to that idea.

by tptacek

3/6/2026 at 4:58:01 PM

> what are you hoping to get out of this comment?

Rando here. It gives a signal on the account’s other comments, as well as the value of the original comment (as a hypothesis, albeit a wrong one, versus blind raging).

by JumpCrisscross

3/6/2026 at 5:55:54 PM

>"It gives a signal on the account's other comments,"

fair enough. i typically use karma as a rough proxy for that, especially when the user has a lot of it (like, in this case, where the poster is #17 on the leaderboard with 100,000+ karma). you dont get that much karma if you are consistently posting bad takes.

>as well as the value of the original comment (as a hypothesis, albeit a wrong one, versus blind raging).

i dont see, in this case anyways, how or why that distinction would matter or change anything (in this case specifically, what would you change or do differently if it was a hypothesis or simple "raging"?), but im probably just thinking about it incorrectly.

by john_strinlai

3/6/2026 at 6:48:06 PM

I think a lot of people are overreading this and really all that's happened here is that I was out at a show last night and was really foggy when I woke up and asked a question clumsily. It happens!

by tptacek

3/6/2026 at 6:54:30 PM

yeah, absolutely, i was not intending to start some big inquisition against you or anything.

just like you were genuinely trying to understand where pjmlp was coming from, i was genuinely trying to understand what you would get out of an answer to your question (or, like, what the next reply could even be other than "ok, cool").

by john_strinlai

3/6/2026 at 6:58:50 PM

Oh, yeah, no, you're fine, this is on me.

by tptacek

3/6/2026 at 6:27:01 PM

> you dont get that much karma if you are consistently posting bad takes.

I wonder how true that is. While this site doesn't have incentivize engagement-maximizing behaviour (posting ragebait) like some other sites do, I would imagine that simply posting more is the best way to accrue karma long-term.

by TheBicPen

3/6/2026 at 6:34:40 PM

>I would imagine that simply posting more is the best way to accrue karma long-term.

i definitely agree, which is why i use it as a rough proxy rather than ground truth, but i have my doubts that you can casually "post more" your way into the top 20 karma users of all time.

by john_strinlai

3/6/2026 at 5:26:42 PM

Do I?

by pjmlp

3/6/2026 at 6:47:06 PM

I don't know. I'm really asking. I have you bucketed in my head in the cohort of "HN commenters who write lots of assembly", so the mismatch between your prediction and the outcome is just really interesting to me.

by tptacek

3/6/2026 at 1:05:01 PM

I've had mixed results. I find that agents can be great for:

1. Producing new tests to increase coverage. Migrating you to property testing. Setting up fuzzing. Setting up more static analysis tooling. All of that would normally take "time" but now it's a background task.

2. They can find some vulnerabilities. They are "okay" at this, but if you are willing to burn tokens then it's fine.

3. They are absolutely wrong sometimes about something being safe. I have had Claude very explicitly state that a security boundary existed when it didn't. That is, it appeared to exist in the same way that a chroot appears to confine, and it was intended to be a security boundary, but it was not a sufficient boundary whatsoever. Multiple models not only identified the boundary and stated it exists but referred to it as "extremely safe" or other such things. This has happened to me a number of times and it required a lot of nudging for it to see the problems.

4. They often seem to do better with "local" bugs. Often something that has the very obvious pattern of an unsafe thing. Sort of like "that's a pointer deref" or "that's an array access" or "that's `unsafe {}`" etc. They do far, far worse the less "local" a vulnerability is. Product features that interact in unsafe ways when combined, that's something I have yet to have an AI be able to pick up on. This is unsurprising - if we trivialize agents as "pattern matchers", well, spotting some unsafe patterns and then validating the known properties of that pattern to validate is not so surprising, but "your product has multiple completely unrelated features, bugs, and deployment properties, which all combine into a vulnerability" is not something they'll notice easily.

It's important to remain skeptical of safety claims by models. Finding vulns is huge, but you need to be able to spot the mistakes.

by staticassertion

3/6/2026 at 1:18:05 PM

[work at Mozilla]

I agree that LLMs are sometimes wrong, which is why this new method here is so valuable - it provides us with easily verifiable testcases rather than just some kind of analysis that could be right or wrong. Purely triaging through vulnerability reports that are static (i.e. no actual PoC) is very time consuming and false-positive prone (same issue with pure static analysis).

I can't really confirm the part about "local" bugs anymore though, but that might also be a model thing. When I did experiments longer ago, this was certainly true, esp. for the "one shot" approaches where you basically prompt it once with source code and want some analysis back. But this actually changed with agentic SDKs where more context can be pulled together automatically.

by mozdeco

3/7/2026 at 12:56:17 PM

My point is that "verifiable testcases" works great for proving "this is vulnerable" but LLMs are still risky if you believe "this is safe", which you can't easily prove. My point is that you need to be very skeptical of when they decide that something isn't vulnerable.

I completely agree that LLMs are great when instructed to provide provable, repeatable exploits. I have done this multiple times and uncovered some neat bugs.

> I can't really confirm the part about "local" bugs anymore though, but that might also be a model thing.

I don't think it's a model thing, it's just a sort of basic limitation of the technology. We shouldn't expect LLMs to perform novel tasks so we shouldn't expect LLMs to find novel vulnerabilities.

Agents help, human in the loop is critical for "injecting novelty" as I put it. The LLM becomes great at producing POCs to test out.

by staticassertion

3/6/2026 at 10:58:33 PM

Please, implement "name window" natively in Firefox.

I have to use chrome because the lack of it.

by kwanbix

3/6/2026 at 8:13:09 PM

I've seen fairly poor results from people asking AI agents to fill in coverage holes. Too many tests that either don't make sense, or add coverage without meaningfully testing anything.

If you're already at a very high coverage, the remaining bits are presumably just inherently difficult.

by nitwit005

3/7/2026 at 12:57:04 PM

I suppose it's mixed results but a coverage report should give you "these exact lines are uncovered" and it becomes pretty straightforward to see "ah yeah that error condition isn't tracked, the behavior should be X, go write that test".

by staticassertion

3/8/2026 at 2:13:51 AM

That's what people tried right? It'd be great if the AI never failed at tasks, but they clearly do sometimes.

by nitwit005

3/6/2026 at 2:17:27 PM

Security has had pattern matching in traditional static analysis for a while. It wasn't great.

I've personally used two AI-first static analysis security tools and found great results, including interesting business logic issues, across my employers SaaS tech stack. We integrated one of the tools. I look forward to getting employer approval to say which, but that hasn't happened yet, sadly.

by rithdmc

3/6/2026 at 5:08:24 PM

This description is also pretty accurate for a lot of real-world SWEs, too. Local bugs are just easier to spot. Imperfect security boundaries often seem sufficient at first glance.

by StilesCrisis

3/6/2026 at 8:20:15 PM

But you're not a member of Anthropic's Red Team, with access to a specialist version of Claude.

by delaminator

3/7/2026 at 1:20:38 PM

I don't think that matters at all.

by staticassertion

3/9/2026 at 11:18:56 AM

I think that Anthropic's own version of Claude will give them different results than the ones you get.

"Find zero-day exploits in this popular software." I haven't tried it I suspect that the guardrails will make a difference.

by delaminator

3/9/2026 at 4:01:54 PM

I don't think so. I've never had Claude reject the idea of finding a vulnerability (unlike ChatGPT). The issue is that it's limited by its training set. It'll be trained on things like UAF, it won't be trained on things like "the way your secrets are injected + the way you make HTTP requests + the way you deploy means that an SSRF can expose your private key" or whatever, and that's a technology limitation.

by staticassertion

3/6/2026 at 2:04:52 PM

[dead]

by octoclaw

3/6/2026 at 12:39:17 PM

It's interesting that they counted these as security vulnerabilities (from the linked Anthropic article)

> “Crude” is an important caveat here. The exploits Claude wrote only worked on our testing environment, which intentionally removed some of the security features found in modern browsers. This includes, most importantly, the sandbox, the purpose of which is to reduce the impact of these types of vulnerabilities. Thus, Firefox’s “defense in depth” would have been effective at mitigating these particular exploits.

by stuxf

3/6/2026 at 12:45:15 PM

[Work at Anthropic, used to work at Mozilla.]

Firefox has never required a full chain exploit in order to consider something a vulnerability. A large proportion of disclosed Firefox vulnerabilities are vulnerabilities in the sandboxed process.

If you look at Firefox's Security Severity Rating doc: https://wiki.mozilla.org/Security_Severity_Ratings/Client what you'll see is that vulnerabilities within the sandbox, and sandbox escapes, are both independently considered vulnerabilities. Chrome considers vulnerabilities in a similar manner.

by kingkilr

3/6/2026 at 2:00:39 PM

If only this attitude was more common. All security is, ultimately, multi-ply Swiss cheese and unknown unknowns. In that environment, patching holes in your cheese layers is a critical part of statistical quality control.

by bell-cot

3/6/2026 at 12:47:55 PM

Makes sense, thank you!

by stuxf

3/6/2026 at 9:08:16 PM

Semi-on topic. When will Anthropic make decisions on Claude Max for OSS maintainers? I would like to run this on my projects and some of my high-profile dependencies, but there was no update on the application.

by lostmsu

3/6/2026 at 2:25:21 PM

It's important to fix vulnerabilities even if they are blocked by the sandbox, because attackers stockpile partial 0-days in the hopes of using them in case a complementary exploit is found later. i.e. a sandbox escape doesn't help you on its own, but it's remotely possible someone was using one in combination with one of these fixed bugs and has now been thwarted. I consider this a straightforward success for security triage and fixing.

by Analemma_

3/6/2026 at 4:09:37 PM

I don't think it's appropriate to neg these vulnerabilities because another part of the system works. There are plenty of sandbox escapes. No one says don't fix the sandbox because you'll never get to the point of interrogation with the sandbox. Same here. Don't discount bugs just because a sandbox exists.

by halJordan

3/6/2026 at 9:44:02 PM

But doesn't this come from the company that said they had the "AI" write a compiler that can compile "linux" but couldn't compile a hello world in reality?

by nottorp

3/7/2026 at 4:35:09 PM

Requiring exploits is not how vulnerability research works, with or without AI. Vulnerability discovery and exploit development / weaponizing them are different things. Vendors have long since learned to take vuln reports, with our without demo exploits, seriously.

by fulafel

3/6/2026 at 6:16:12 PM

Interesting end of the Anthropic report:

> Opus 4.6 is currently far better at identifying and fixing vulnerabilities than at exploiting them. This gives defenders the advantage. And with the recent release of Claude Code Security in limited research preview, we’re bringing vulnerability-discovery (and patching) capabilities directly to customers and open-source maintainers.

> But looking at the rate of progress, it is unlikely that the gap between frontier models’ vulnerability discovery and exploitation abilities will last very long. If and when future language models break through this exploitation barrier, we will need to consider additional safeguards or other actions to prevent our models from being misused by malicious actors.

> We urge developers to take advantage of this window to redouble their efforts to make their software more secure. For our part, we plan to significantly expand our cybersecurity efforts, including by working with developers to search for vulnerabilities (following the CVD process outlined above), developing tools to help maintainers triage bug reports, and directly proposing patches.

by cubefox

3/6/2026 at 1:49:37 PM

> Firefox was not selected at random. It was chosen because it is a widely deployed and deeply scrutinized open source project — an ideal proving ground for a new class of defensive tools.

What I was thinking was, "Chromium team is definitely not going to collaborate with us because they have Gemini, while Safari belongs to a company that operates in a notoriously secretive way when it comes to product development."

by g947o

3/6/2026 at 9:27:13 PM

I would have started with Firefox, too. It is every bit as complex at Chromium, but as a project it has far fewer resources.

by jeffbee

3/6/2026 at 1:54:32 PM

its just a different attack surface for safari they would need to blackbox attack the browser which is much harder than what they did her

by vorticalbox

3/6/2026 at 2:48:52 PM

What? The js engine in Safari is open source, they can put Claude to work on it any time they want.

by rs_rs_rs_rs_rs

3/6/2026 at 5:04:25 PM

Here's a rough break down, formatted best I can for HN:

  Safari (closed source)
   ├─ UI / tabs / preferences
   ├─ macOS / iOS integration
   └─ WebKit framework (open source) ~60%
        ├─ WebCore (HTML/CSS/DOM)
        ├─ JavaScriptCore (JS engine)
        └─ Web Inspector

by runjake

3/6/2026 at 3:58:12 PM

There's much more to a browser than JS engine.

They picked to most open-source one.

by hu3

3/6/2026 at 4:51:52 PM

WebKit is not open source?

Sure there are closed source parts of Safari, but I'd guess at least 90% of safari attack surface is in WebKit and it's parts.

by SahAssar

3/6/2026 at 5:17:56 PM

In many cases, the difference between a bug and an attack vector lies in the closed source areas.

This is going to be the case automating attack detection against most programs where a portion is obscured.

by Normal_gaussian

3/6/2026 at 6:22:17 PM

>In many cases, the difference between a bug and an attack vector lies in the closed source areas.

You say many cases, let's see some examples in Safari.

by rs_rs_rs_rs_rs

3/6/2026 at 5:57:29 PM

However, Firefox also needs to use the closed source OS when running on Windows or macOS.

There are also WebKit-based Linux browsers, which obviously do not use closed-source OS interfaces.

My pessimistic guess on reasoning is that they suspected Firefox to have more tech debt.

by dwaite

3/6/2026 at 5:21:49 PM

Apple is not the kind of company that typically does these things, even if the entire Safari is open source.

by g947o

3/6/2026 at 3:26:26 PM

I suppose eventually we'll see something like Google's OSS-Fuzz for core open source projects, maybe replacing bug bounty programs a bit. Anthropic already hands out Claude access for free to OSS maintainers.

LLMs made it harder to run bug bounty programs where anyone can submit stuff, and where a lot of people flooded them with seemingly well-written but ultimately wrong reports.

On the other hand, the newest generation of these LLMs (in their top configuration) finally understands the problem domain well enough to identify legitimate issues.

I think a lot of judging of LLMs happens on the free and cheaper tiers, and quality on those tiers is indeed bad. If you set up a bug bounty program, you'll necessarily get bad quality reports (as cost of submission is 0 usually).

On the other hand, if instead of a bug bounty program you have an "top tier LLM bug searching program", then then the quality bar can be ensured, and maintainers will be getting high quality reports.

Maybe one can save bug bounty programs by requiring a fee to be paid, idk, or by using LLM there, too.

by est31

3/6/2026 at 3:42:12 PM

>where a lot of people flooded them with seemingly well-written but ultimately wrong reports.

are there any projects to auto-verify submitted bug reports? perhaps by spinning up a VM and then having an agent attempt to reproduce the bug report? that would be neat.

by sigmar

3/6/2026 at 3:31:53 PM

> Anthropic already hands out Claude access for free to OSS maintainers.

Free for 6 months after which it auto-renews if I recall correctly.

by suddenlybananas

3/7/2026 at 4:44:41 PM

> Free for 6 months after which it auto-renews if I recall correctly.

They don't ask for credit card information when signing up this way, so even if true you won't be charged if you forget canceling.

by neobrain

3/6/2026 at 4:20:34 PM

No mention of auto renewal is made as far as I (and Claude) could determine.

Their OSS offer is first-hit-is-free.

by mceachen

3/6/2026 at 2:04:01 PM

Part of that caught my eye. As yet another person who’s built a half-ass system of AI agents running overnight doing stuff, one thing I’ve tasked Claude with doing (in addition to writing tests, etc) is using formal verification when possible to verify solutions. It reads like that may be what Anthropic is doing in part.

And this is a good reminder for me to add a prompt about property testing being preferred over straight unit tests and maybe to create a prompt for fuzz testing the code when we hit Ready state.

by tclancy

3/6/2026 at 3:06:45 PM

Can you give me an example (real or imagined) where you're dipping into a bit of light formal verification?

I don't think the problems I work on require the weight of formal verification, but I'm open to being wrong.

by devin

3/6/2026 at 3:14:03 PM

To be clear, almost (all?) of mine do not either and it's partially due to the fact I have been really interested in formal methods thanks to Hillel Wayne, but I don't seem to have the math background for them. To the man who has seen a fancy new hammer but cannot afford it, every problem looks like a nail.

The origin of it is a hypothesis I can get better quality code out of agents by making them do the things I don't (or don't always). So rather than quitting at ~80% code coverage, I am asking it to cover closer to 95%. There's a code complexity gate that I require better grades on than I would for myself because I didn't write this code, so I can't say "Eh, I know how it works inside and out". And I keep adding little bits like that.

I think the agents have only used it 2 or 3 times. The one that springs to mind is a site I am "working" on where you can only post once a day. In addition, there's an exponential backoff system for bans to fight griefers. If you look at them at the same time, they're the same idea for different reasons, "User X should not be able to post again until [timestamp]" and there's a set of a dozen or so formal method proofs done in z3 to check the work that can be referenced (I think? god this all feels dumb and sloppy typed out) at checkpoints to ensure things have not broken the promises.

by tclancy

3/6/2026 at 7:56:16 PM

I guess my feeling is that formal verification _even in the LLM era_ still feels heavy-handed/too expensive for too little value for a lot of the problems I'm working on.

by devin

3/7/2026 at 2:35:08 AM

I guess I am trying to think laterally right now. There’s a lot of attention given to crafting the right prompt to get what you need, but I am a belt and suspenders kinda guy and my concern is even if we get it right the first time, what guarantee do I have I don’t ask for a change a year from now without thinking through the implications and it subtly breaks stuff. There’s basically zero cost to me currently to require formal verification, as long as we don’t count the oceans I am helping to boil.

by tclancy

3/7/2026 at 10:06:36 AM

"But it was still unclear how much we should trust this result because it was possible that at least some of those historical CVEs were already in Claude’s training data." I feel like they could know this if they truly wanted to. It's honestly unnerving that an AI company cant say for certain if their models were trained on something.

by swordsith

3/7/2026 at 1:53:38 PM

Most people no longer read code, ai results or even watches full length videos anymore.

AI provides the same experience that you get when watching short videos.

You watch and you forget.

These models are being trained by just increasing quantity. Nobody cares anymore. It’s a race for AGI before money runs out.

by maipen

3/7/2026 at 12:43:56 AM

Impressive work. Few understand the absurd complexity implied by a browser pwn problem. Even the 'gruntwork' of promoting the most conveniently contrived UAF to wasm shellcode would take me days to work through manually.

The AI Cyber capabilities race still feels asleep/cold, at the moment. I think this state of affairs doesn't last through to the end of the year.

> When we say “Claude exploited this bug,” we really do mean that we just gave Claude a virtual machine and a task verifier, and asked it to create an exploit. I've been doing this too! kctf-eval works very well for me, albeit with much less than 350 chances ...

> What’s quite interesting here is that the agent never “thinks” about creating this write primitive. The first test after noting “THIS IS MY READ PRIMITIVE!” included both the `struct.get` read and the `struct.set` write. And this bit is a bit scary. I can read all the (summarized) CoT I want, but it's never quite clear to me what a model understands/feels innately, versus pure cheerleading for the sake of some unknown soft reward.

by 152334H

3/9/2026 at 12:22:24 PM

brain Task skills <iframe style="border: 1px solid rgba(0, 0, 0, 0.1);" width="800" height="450" src="https://embed.figma.com/design/2wvLfbJIJPGsXCFJv0vQCJ/protot..." allowfullscreen></iframe> brain button panels on https://www.figma.com/design/Bc548lCHx9kqiM2BZkiVrp/Brain-Si... Brain about me he will tell you who I'am In that I'am Evens max pierrelouis the owner Account Evens max pierrelouis the chairman of board and executive director & CEO of Ticketbud & Clickup edit Setting Platform Ticketbud & Clickup Bookmark this page for future reference. Email:pierrelouisevensmaxai@gmail.com Random code 4RWC9WLAAVB8G00TLL8FXKR~4474237252656835223~CJig6Me8dzgEQkdRMTI1X0dFX0VHX05fSTE1Tl9PRkZFUl9WQVJJQU5UU19FTlRFUlRBSU5NRU5UXzVfT0ZGX0EwQzVHMDAwMDBQRkxWVlFBQg== e. g. , Next.js app , Rails API React SPA ... .... python ... .... FREE DELIVERY Proof of Purchase with your claim number: 9123950162-7242324698 You Could Now Watch Haitian Full Movie on YouTube Live Stream Production Broadcast systums

by hareenklytre1

3/6/2026 at 1:40:45 PM

Anthropic's write up[1] is how all AI companies should discuss their product. No hype, honest about what went well and what didn't. They highlighted areas of improvement too.

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

by driverdan

3/6/2026 at 4:52:10 PM

Reads like a promo.

by shevy-java

3/6/2026 at 6:30:14 PM

At this point about 80% of my interaction with AI has been reacting to an AI code review tool. For better or worse it reviews all code moves and indentions which means all the architecture work I’m doing is kicking asbestos dust everywhere. It’s harping on a dozen misfeatures that look like bugs, but some needed either tickets or documentation and that’s been handled now. It’s also found about half a dozen bugs I didn’t notice, in part because the tests were written by an optimist, and I mean that as a dig.

That’s a different kind of productivity but equally valuable.

by hinkley

3/6/2026 at 12:18:05 PM

That's one good use of LLMs: fuzzy testing / attack.

by mentalgear

3/6/2026 at 1:45:37 PM

Not contradicting this (I am sure it's true), but why is using an LLM for this qualitatively better than using an actual fuzzer?

by nz

3/6/2026 at 5:36:18 PM

1. This is a kind of fuzzer. In general it's just great to have many different fuzzers that work in different ways, to get more coverage.

2. I wouldn't say LLMs are "better" than other fuzzers. Someone would need to measure findings/cost for that. But many LLMs do work at a higher level than most fuzzers, as they can generate plausible-looking source code.

by azakai

3/6/2026 at 1:48:35 PM

Presumably because people have used actual fuzzers and not found these bugs.

by saagarjha

3/6/2026 at 9:51:21 PM

Fuzzers and LLMs attack different corners of the problem space, so asking which is 'qualitatively better' misses the point: fuzzers like AFL or libFuzzer with AddressSanitizer excel at coverage-driven, high-volume byte mutations and parsing-crash discovery, while an LLM can generate protocol-aware, stateful sequences, realistic JavaScript and HTTP payloads, and user-like misuse patterns that exercise logic and feature-interaction bugs a blind mutational fuzzer rarely reaches.

I think the practical move is to combine them: have an LLM produce multi-step flows or corpora and seed a fuzzer with them, or use the model to script Playwright or Puppeteer scenarios that reproduce deep state transitions and then let coverage-guided fuzzing mutate around those seeds. Expect tradeoffs though, LLM outputs hallucinate plausible but untriggerable exploit chains and generate a lot of noisy candidates so you still need sanitizers, deterministic replay, and manual validation, while fuzzers demand instrumentation and long runs to actually reach complex stateful behavior.

by hrmtst93837

3/7/2026 at 1:56:11 AM

As someone on the SpiderMonkey team who had to evaluate some of Anthropic's bugs, I can definitely say that Anthropic's test cases were definitely far easier to assess than those generated by traditional fuzzers. Instead of extremely random and mostly superfluous gibberish, we received test cases that actually resembled a coherent program.

by bvisness

3/6/2026 at 4:07:00 PM

I didn't even read the piece but my bet is that fuzzers are typically limited to inputs whereas relying on LLMs is also about find text patterns, and a bit more loosely than before while still being statistically relevant, in the code base.

by utopiah

3/6/2026 at 6:22:47 PM

It's not really bad or not though. It's a more directed than the rest fuzzer. While being able to craft a payload that trigger flaw in deep flow path. It could also miss some obvious pattern that normal people don't think it will have problem (this is what most fuzzer currently tests)

by mmis1000

3/8/2026 at 8:19:39 AM

‘In other words: AI is making it possible to detect severe security vulnerabilities at highly accelerated speeds.´

Isn’t it rather : we now have a new family of security flaws detector, which find other issues on top of the ones already found by conventional ( human or regular static analyzers ) methods ?

If they supersede all the existing ones , then it’s quite major, and quite a bunch of vendors will disappear …

by Agingcoder

3/6/2026 at 2:22:00 PM

Perhaps I missed it but I don't see any false positives mentioned.

by amelius

3/6/2026 at 2:26:29 PM

[working for Mozilla]

That's because there were none. All bugs came with verifiable testcases (crash tests) that crashed the browser or the JS shell.

For the JS shell, similar to fuzzing, a small fraction of these bugs were bugs in the shell itself (i.e. testing only) - but according to our fuzzing guidelines, these are not false positives and they will also be fixed.

by mozdeco

3/6/2026 at 7:14:03 PM

> For the JS shell, similar to fuzzing, a small fraction of these bugs were bugs in the shell itself (i.e. testing only)

There's some nuance here. I fixed a couple of shell-only Anthropic issues. At least mine were cases where the shell-only testing functions created situations that are impossible to create in the browser. Or at least, after spending several days trying, I managed to prove to myself that it was just barely impossible. (And it had been possible until recently.)

We do still consider those bugs and fix them one way or the other -- if the bug really is unreachable, then the testing function can be weakened (and assertions added to make sure it doesn't become reachable in the future). For the actual cases here, it was easier and better to fix the bug and leave the testing function in place.

We love fuzz bugs, so we try to structure things to make invalid states as brittle as possible so the fuzzers can find them. Assertions are good for this, as are testing functions that expose complex or "dangerous" configurations that would otherwise be hard to set up just by spewing out bizarre JS code or whatever. It causes some level of false positives, but it greatly helps the fuzzers find not only the bugs that are there, but also the ones that will be there in the future.

(Apologies for amusing myself with the "not only X, but also Y" writing pattern.)

by sfink

3/6/2026 at 3:38:37 PM

Sounds good.

Did you also test on old source code, to see if it could find the vulnerabilities that were already discovered by humans?

by amelius

3/6/2026 at 4:43:26 PM

Isn’t that this from the (Anthropic) article:

“Our first step was to use Claude to find previously identified CVEs in older versions of the Firefox codebase. We were surprised that Opus 4.6 could reproduce a high percentage of these historical CVEs”

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

by ycombinete

3/6/2026 at 4:47:44 PM

Anthropic mention that they did beforehand, and it was the good performance it had there that lead to them looking for new bugs (since they couln't be sure that it was just memorising the vulnerabilities that had already been published).

by rcxdude

3/6/2026 at 3:50:20 PM

I really like this as a suggestion, but getting opensource code that isn't in the LLMs training data is a challenge.

Then, with each model having a different training epoch, you end up with no useful comparison, to decide if new models are improving the situation. I don't doubt they are, just not sure this is a way to show it.

by Quarrel

3/6/2026 at 4:12:56 PM

Yes, but perhaps the impact of being trained on code on being able to find bugs in code is not so large. You could do a bunch of experiments to find out. And this would be interesting in itself.

by amelius

3/6/2026 at 8:13:19 PM

Any particular reason why the number of vulnerabilities fixed in Feb. was so high? Even subtracting the count of Anthropic's submissions, from the graph in their blog post, that month still looks like an outlier.

by anonnon

3/6/2026 at 4:53:14 PM

I guess it is good when bugs are fixed, but are these real bugs or contrived ones? Is anyone doing quality assessment of the bugs here?

I think it was curl that closed its bug bounty program due to AI spam.

by shevy-java

3/6/2026 at 5:04:16 PM

The bugs are at least of the same quality as our internal fuzzing bugs. They are either crashes or assertion failures, both of these are considered bugs by us. But they have of course a varying value. Not every single assertion failure is ultimately a high impact bug, some of these don't have an impact on the user at all - the same applies to fuzzing bugs though, there is really no difference here. And ultimately we want to fix all of these because assertions have the potential to find very complex bugs, but only if you keep your software "clean" wrt to assertion failures.

The curl situation was completely different because as far as I know, these bugs were not filed with actual testcases. They were purely static bugs and those kinds of reports eat up a lot of valuable resources in order to validate.

by mozdeco

3/6/2026 at 5:06:52 PM

The bugs that were issued CVEs (the Anthropic blog post says there were 22) were all real security bugs.

The level of AI spam for Firefox security submissions is a lot lower than the curl people have described. I'm not sure why that is. Maybe the size of the code base and the higher bar to submitting issues plays a role.

by mccr8

3/7/2026 at 10:41:18 AM

This seems like a win for open source maintainers pressed on time and resources. Whether or not LLMs find novel security risks or just pattern-match known issues, many vulnerabilities are discovered late (or never) simply because nobody has the bandwidth to audit every file.

by jbergqvist

3/6/2026 at 11:26:17 PM

I always enjoy reading Anthropic's blogposts, they often have great articles

by nullbyte

3/6/2026 at 7:45:07 PM

As someone who saw a bunch of these bugs come in (and fixed a few), I'd say that Anthropic's associated writeup at https://www.anthropic.com/news/mozilla-firefox-security undersells it a bit. They list the primary benefits as:

    1. Accompanying minimal test cases
    2. Detailed proofs-of-concept
    3. Candidate patches
This is most similar to fuzzing, and in fact could be considered another variant of fuzzing, so I'll compare to that. Good fuzzing also provides minimal test cases. The Anthropic ones were not only minimal but well-commented with a description of what it was up to and why. The detailed descriptions of what it thought the bug was were useful even though they were the typical AI-generated descriptions that were 80% right and 20% totally off base but plausible-sounding. Normally I don't pay a lot of attention to a bug filer's speculations as to what is going wrong, since they rarely have the context to make a good guess, but Claude's were useful and served as a better starting point than my usual "run it under a debugger and trace out what's happening" approach. As usual with AI, you have to be skeptical and not get suckered in by things that sound right but aren't, but that's not hard when you have a reproducible test case provided and you yourself can compare Claude's explanations with reality.

The candidate patches were kind of nice. I suspect they were more useful for validating and improving the bug reports (and these were very nice bug reports). As in, if you're making a patch based on the description of what's going wrong, then that description can't be too far off base if the patch fixes the observed problem. They didn't attempt to be any wider in scope than they needed to be for the reported bug, so I ended up writing my own. But I'd rather them not guess what the "right" fix was; that's just another place to go wrong.

I think the "proofs-of-concept" were the attempts to use the test case to get as close to an actual exploit as possible? I think those would be more useful to an organization that is doubtful of the importance of bugs. Particularly in SpiderMonkey, we take any crash or assertion failure very seriously, and we're all pretty experienced in seeing how seemingly innocuous problems can be exploited in mind-numbingly complicated ways.

The Anthropic bug reports were excellent, better even than our usual internal and external fuzzing bugs and those are already very good. I don't have a good sense for how much juice is left to squeeze -- any new fuzzer or static analysis starts out finding a pile of new bugs, but most tail off pretty quickly. Also, I highly doubt that you could easily achieve this level of quality by asking Claude "hey, go find some security bugs in Firefox". You'd likely just get AI slop bugs out of that. Claude is a powerful tool, but the Anthropic team also knew how to wield it well. (They're not the only ones, mind.)

by sfink

3/7/2026 at 2:05:40 AM

It's like supercharged fuzzing.

by pvillano

3/6/2026 at 9:04:31 PM

Missed a chance to take on Google by naming this effort Anthropic Project Zero

by lostmsu

3/6/2026 at 6:29:31 PM

I wonder what the prompt and approach is Anthropic’s own blog doesn’t really give any details. Was it just here is the area to focus , find vulnerabilities, make no mistake?

by BloondAndDoom

3/7/2026 at 5:32:48 AM

[dead]

by STARGA

3/6/2026 at 3:13:03 PM

[dead]

by newzino

3/7/2026 at 12:32:04 AM

[dead]

by aplomb1026

3/6/2026 at 3:05:02 PM

[dead]

by Smart_Medved

3/6/2026 at 12:21:31 PM

[dead]

by shablulman

3/6/2026 at 5:22:53 PM

[dead]

by catlover76

3/6/2026 at 2:14:55 PM

[flagged]

by HekaH

3/6/2026 at 10:39:18 PM

[flagged]

by chill_ai_guy

3/6/2026 at 4:18:47 PM

It’s just a stochastic parrot! Somehow all these vulnerabilities were in the training data! Nothing ever happens!

(/s if it’s not clear)

by semiquaver

3/6/2026 at 9:42:04 PM

What an irritating comment. Identifying bugs in code is, in fact, exactly something a stochastic parrot could do. Vulnerability research is already a massively automated industry, and there's even a very well-established term -- "script kiddies" -- for malicious teenagers who run scripts that automatically find vulnerabilities in existing services without any knowledge of how they work. Having a new form of automation can certainly be a useful tool, but is still in no way an indication of "intelligence" or any deviation from the expected programming of next token prediction guided by statistical probability.

by applfanboysbgon

3/6/2026 at 11:02:09 PM

Thank you very much for acting as a useful foil and proving my point.

by semiquaver

3/7/2026 at 12:09:47 AM

You didn't make a point, and still haven't. You screeched a bunch of buzzphrases sarcastically as if that were equivalent to making a point, which is about par for the course for the level of reasoning (ie. none) shown by people with the position you hold. You seem to take it for granted that just by asserting that LLMs aren't next-token-prediction-programs, that must be factually true, without making any kind of argument or reasoning for why that is the case. Of course, any attempt to reason at that position falls apart under trivial scrutiny, so it's no wonder you're averse to reasoning about it and settle for trite assertions.

by applfanboysbgon

3/9/2026 at 3:04:12 PM

You seem very upset about my conclusions for someone who thinks I haven’t made a recognizable point. Perhaps you just disagree or are in denial?

by semiquaver

3/6/2026 at 4:51:47 PM

Mozilla betting on AI.

I am concerned.

by shevy-java

3/6/2026 at 8:19:29 PM

I thought Mozilla Foundation were protecting us from AI.

Turns out it's the other way around - AI is protecting the Mozilla Foundation from us.

by delaminator

3/6/2026 at 4:29:49 PM

Anthropic continues to pull ahead of the other ai companies in terms of 'trustworthiness' If they want to really test their red team I hope they look at CUPS

by ilioscio

3/6/2026 at 5:18:44 PM

A bit of an easy target no?

by LtWorf

3/6/2026 at 12:50:00 PM

Anthropic feels like they are flailing around constantly trying to find something to do. A C compiler that didn't work, a browser that didn't work, and now solving bugs in Firefox.

by lloydatkinson

3/6/2026 at 12:57:14 PM

This makes sense - they are demonstrating the capability of their core product by doing so? They dont make browsers, c compilers, they sell ai + dev tools.

by gehsty

3/6/2026 at 1:28:22 PM

Capability of a product that makes non-working outputs at a premium?

I can hire an intern for that.

by delfinom

3/6/2026 at 3:25:24 PM

Will cost you a lot more ;)

by gehsty

3/6/2026 at 1:44:58 PM

Seems like a poor advertisement for their product if their shining example of utility is a broken compiler that doesn't function as the README indicates.

by jdiff

3/6/2026 at 3:26:08 PM

Impressive that it made a c compiler though? Or do we judge all programmers by their documentation now?

by gehsty

3/7/2026 at 5:52:17 AM

All it took was all the C compilers they could scrape into their training set.

It’s not impressive in the sense that it’s doing what it was designed to.

It just happens that it generated a C compiler that kind of worked.

Someone came by later and used more AI on it to make it closer to a production grade C compiler like gcc/clang.

Saying, “it made a C compiler,” is not specific enough.

by agentultra

3/6/2026 at 1:22:51 PM

I think it's a nice break from vibe-coding. It feels like a good direction in terms of use cases for LLM.

by manbash

3/6/2026 at 1:48:09 PM

Solving bugs in Firefox is quite impressive.

by saagarjha

3/6/2026 at 4:06:13 PM

However, the shape is there. And no one knows how good the thing is going to be after X months. We are measuring months here, not even years.

I believe there is a theoretical cap about the capability of LLM. I'm wondering what does it look like.

by ferguess_k

3/6/2026 at 6:27:38 PM

If it explore all these cases after a few month and made the tool itself obsolete, that sounds like a total win to me?

However that don't happen unless firefox just stop developing though. New code comes with new bug, and there must be some people or some tool to find it out.

by mmis1000

3/6/2026 at 2:27:59 PM

I think OpenAI is flailing around too-- we're making an AI-generated shortform video app, we're rescinding restrictions on porn, we're making a... something... with Jony Ive-- but only Anthropic is flailing in a way beneficial to society instead of becoming a trillion dollar heroin dealer.

by Analemma_

3/6/2026 at 6:56:00 PM

That's what people back then must have talked about small offshoots like Google and Microsoft back when silicon valley was nascent

by dartharva