not that im particularly pro-ai, but it seems a bit silly to rely on a paper about early-2025 ai when people are using late-2026 ai, given how different they are.
> how are they different? did the algorithms upon which they operate suddenly change?
Just like most technologies AI algorithms and tools get continuously refined/improved over time.
One thing modern AI has gotten especially good at in the last year is reverse engineering, it went from struggling and frequently making mistakes when analyzing binaries even with say a specialized Ghidra MCP integration to being able to very quickly and accurately analyze even heavily stripped BROM binaries with almost no user guidance or specialized environments. Binaries that would previously take days or weeks to analyze can be analyzed by a modern AI in minutes to hours.
The difference is massive and obvious to anyone who has been working with these tools over these time periods.
Presumably yes. It is safe to assume that algorithms running the model changed, the training procedures changed, and the scale changed. Unfortunately the AI companies refuse to disclose the details of any of this, which is a harm to human knowledge (hopefully a temporary one). Yet the results speak for themselves.
For me it's only been in the last month with Opus 5.5 that I've been seeing code quality I actually respect (though this is with substantial human effort in the loop). Though this experience is from work where I don't have access to non-Anthropic models, nor Fable.
The interesting thing about that paper, I would have said, was the _perception_ gap; people believed that it was making them more productive even when it was doing the opposite. That effect presumably hasn’t gone away.
It takes time to research and publish. It'll always be some slightly old model. Is this argument just a permanent get out of jail free card? Add 10 to each year, will we be seeing that said in the future?
i don't think models will continue to improve at the rate they have been, so eventually it will be less of an issue. there are also questions to answer and studies to be done that aren't as sensitive about the specific model.
however, productivity is sensitive to the model, and models have significantly improved in the last 1.5-2 years. sometimes things move quickly and research gets outdated. ai is not the first field where this has happened.
the research is still valuable, it just has to be acknowledged that it is specific to a point in time. using it for an argument 2 years later just shows that the leah is cherry-picking results, and weakens the overall point.
I find this hilarious since I'm actively having my clankers work on porting EDK2 to an SoC that's used in a Chromebook, though not the ones mentioned here.
Are you publishing anywhere that I can follow? In particular, it would be really helpful if you could publish the prompts and workflow, so that the rest of us can more quickly use it to replicate your work on other machines:)
(Signed, the owner of several Chromebooks in need of better firmware)
I can't use software that rejects AI to this degree for privacy reasons.
You can't expect to sufficiently protect your users privacy when not using AI for finding vulnerabilities.
Same thing with Asahi Linux with their highly anti-AI stance. I had a bit of hope when I saw someone was making an LLM assisted fork but it's not the same support.
While MacOS is likely becoming much more secure, Linux distros that reject AI would fall even further behind, if that's possible.
The Assisted-by: tag is no longer requirement because LLM assistance is the default.
Robot friends enable you to get much more done faster and more accurately, that if you call yourself an engineer you're a damn fool not to make use of them.
Ai and privacy in the same sentence is wierd. You supported your argument, I guess, but unless you are using local ai, the developer would be sacrificing their own privacy.
You say "faith-based political filter," I say "standing on principles." Your valuation of outcomes and outputs over inputs and intent is also a faith-based political filter, in that they make the value judgement that outputs are the only thing that matter when shipping a product or managing a project.
There is a respectable way to approach this and this.
The right way is something like, we've been getting spammed with a bunch of PR's from AI that we find difficult to review (because AI allows the average bob who isn't technically minded to make a PR). We have therefore decided not to allow AI submissions.
---
I think the people who have some moral / ideological issue and bring that into projects kind of feel like clowns to me. I agree with Linus that the point is to make something that people find useful, and obviously you want it to be maintainable.
Saying "it makes you dumber etc" is not related to the project, with all due respect it's non of your fucking business how I learn / retain skills.
I get it, but everything is ideological -- whether you want to hear about it or not.
In a world where software exerts considerable control and influence over peoples' lives, your ability to insulate yourself from that influence is a priveledge. Software IS ideological. Free software was created so people can have the freedom to share and collaborate on their own terms. There is an extent to which it gets extreme, but without the GPL we would live in an even more monopolistic "free" market hell world than we already do. That's a moral obligation that spawned a practical one. If no one ever took a moral stance because you find it annoying, the world would be an objectively worse place.
I always find these sorts of responses fascinating. “Oh no people are being mean about our lovely robots!!” Like, people are entitled to dislike and be sceptical of LLMs.
I can't be the only one who thinks the way they handled that is incredibly disrespectful right?
It's their own business to disallow AI contributions.
But instead of adding that to the Code Of Conduct they chose to knowingly misuse a file to target a group of people they don't like.
If I want to use AI on my copy of that repo, I have to delete that file and consider if the developer has added any more of what is (by intent) basically malware to the source code. Sure the file is just an unhinged rant, but now I have to wonder if they attempted to put some prompt injection in the repo.
“If I want to crawl a website with a robots file that says ‘fuck off’, I have to ignore the robots file. If I want to use AGPL code as part of a commercial web service without creating my source, I have to ignore the license.”
Like, c’mon now. This is far from the weirdest open source restriction.
I don't see how any of those things are similar, I think you've missed my point. Those hypothetical authors are using robots and license files correctly.
Would you be OK if a repo had Visual Studio files that were designed to crash visual studio if they are used, just because the maintainer hates Microsoft? That's what this feels like, a deliberate malicious abuse of the intent that adding agents.md would otherwise imply.
Unfortunately this is bad for one of my projects, a slop detector extension... it assumes that AGENTS.md be short in size to say stuff like "You may view and use this code but not edit or commit anything"... this rant is long enough that it classifies as slop itself!
Yeah, the (poisoned) AGENTS.md file reads lots like "f*ck AI", which feels like anti-AI dogmatism for me. If I really wanted to use this project, I would use Coreboot instead or fork it to remove proprietary blobs.
> Imported all 233 currently supported Chromebooks from the MrChromebox coreboot distro. Baytrail (Kip) tested - others need testing. Source-only in this release (must build from source, no binaries provided).
Nice. I think I loaded MrChromebox onto my Google Pixel some years ago. I should see if it can get Libreboot now.
Everyone’s focusing on the AI policy (perhaps because Leah for some reason said this was the most important part of the release), but the UEFI/EDK integration and Chromebook support is a massive step forward. Suddenly Libreboot has multiplied the devices available by many times, and future devices will be much easier to add. This is huge.
I used AI to reverse engineer my Clevo laptop's BIOS, and that of the Latte Panda Mu SoM.
How time consuming would it be to contribute this work to coreboot/libreboot? I really wish I could just send this data to someone because I don't have time to do this "properly" right now.
I'm surprised Libreboot was able to add all the ChromeOS devices at once, Just adding the 2 ports for Heads hasn't been easy, although I'm not an expert when it comes to Coreboot.
Anyway, I love seeing more support for Chromebooks, they are great devices. Funny enough my Acer Chromebook (Kano) is now more open and more secure than my Framework 13s.
I realize that, but what's the selling point of Libreboot on Chromebooks when Coreboot is already supported, and it merely merged in support from Coreboot?
there is upstream code but it's not well-integrated, and google's tree is largely optimised for their own payload called Deptchcharge. mrchromebox tweaks coreboot for use with edk2 so you can use normal operating systems, and the modifications that they make are extensive, e.g. mechanism in EDK2 to update EC firmware at boot time. mrchromebox is, for our purposes, a coreboot distro or indeed its own upstream. libreboot takes mrchromebox and makes several of its own modifications. "just use coreboot" is easier said than done :)
It's refreshing to see serious open-source projects adopting a strict policy on LLM-assisted contributions.
Besides considering frontier LLMs a serious threat to humanity, I find LLM-assisted programming simply...not fun! I tolerate only AI-assisted bug reports, as they are genuinely useful.
I guess I'm AI centrist lol but to me, I can see a way around the 'threat' to humanity issue simply by going local and avoiding the use of datacenter ai. That might reduce the quality of code but running it on your own computer is a lot better -at least IMO.
My issues, personally, are the IP rights issues. What was this shit trained on? When the bubble pops (as I've said a lot in this thread -I know) who's going to shake me down?
If you want something with more power look into the Dell Latitude 5400 Chromebook Enterprise or the Dell latitude 5300 2-in-1 Chromebook Enterprise. Both of these devices have DDR4 user replaceable memory.
There is also the Framework 13 Chromebook edition, but that seems almost impossible to find now-a-days.
>"Libreboot is free, open source boot firmware replacing proprietary BIOS/UEFI firmware on supported Intel/AMD and ARM64 hardware." [...] MrChromebox supports nearly every Chromebook..."
This is great news! Finally an open-source UEFI replacement which can work on nearly every Chromebook, including used/old Chromebooks!
Now, I haven't reviewed the source... it may still contain binary blobs for various drivers; I don't know. If it doesn't, then that's absolutely awesome! But if it does, then remember that having some of the UEFI firmware code open-source is a huge step forward, and it's only a matter of time before those closed-source binary blobs are reverse engineered (possibly by AI) and/or rewritten from scratch entirely, as open-source codebases...
So, a good step forward for open-source, right-to-repair, understandability of the boot chain, the Chromebook hardware ecosystem (used and new), and tranparency in general!
Neat project. I find their new anti-AI policy to be interesting, but not at all useful to anyone. There are no objective arguments. No evidence of poor code quality in late 2026. No examples of why AI can't help the project. Just a rant.
I am very glad to see people with opinions that flow into what they do, but the question becomes: are you trying to make the best software, or make the most idealistic software? There's a big difference.
I am not at all advocating the use of straight AI slop, but with a policy like that you're opening yourself up for missed bugs, security issues, delayed features, and other things. Especially if you move away from software just because an AI wrote one line of code in it. You can still review the code. If it does the thing right, then use it!
60 comments
[ 0.23 ms ] story [ 19.2 ms ] threadhttps://codeberg.org/libreboot/lbmk/src/branch/master/AGENTS...
>"think AI makes you super hacker? think again: https://arxiv.org/abs/2507.09089"
not that im particularly pro-ai, but it seems a bit silly to rely on a paper about early-2025 ai when people are using late-2026 ai, given how different they are.
Just like most technologies AI algorithms and tools get continuously refined/improved over time.
One thing modern AI has gotten especially good at in the last year is reverse engineering, it went from struggling and frequently making mistakes when analyzing binaries even with say a specialized Ghidra MCP integration to being able to very quickly and accurately analyze even heavily stripped BROM binaries with almost no user guidance or specialized environments. Binaries that would previously take days or weeks to analyze can be analyzed by a modern AI in minutes to hours.
The difference is massive and obvious to anyone who has been working with these tools over these time periods.
For me it's only been in the last month with Opus 5.5 that I've been seeing code quality I actually respect (though this is with substantial human effort in the loop). Though this experience is from work where I don't have access to non-Anthropic models, nor Fable.
however, productivity is sensitive to the model, and models have significantly improved in the last 1.5-2 years. sometimes things move quickly and research gets outdated. ai is not the first field where this has happened.
the research is still valuable, it just has to be acknowledged that it is specific to a point in time. using it for an argument 2 years later just shows that the leah is cherry-picking results, and weakens the overall point.
(Signed, the owner of several Chromebooks in need of better firmware)
You can't expect to sufficiently protect your users privacy when not using AI for finding vulnerabilities.
Same thing with Asahi Linux with their highly anti-AI stance. I had a bit of hope when I saw someone was making an LLM assisted fork but it's not the same support.
While MacOS is likely becoming much more secure, Linux distros that reject AI would fall even further behind, if that's possible.
The Linux kernel extensively uses AI now; most lkml submissions have an Assisted-by: LLM tag.
Robot friends enable you to get much more done faster and more accurately, that if you call yourself an engineer you're a damn fool not to make use of them.
Do you have a link? Because this contradicts the kernel documentation.
https://docs.kernel.org/process/coding-assistants.html
Fork it and use Ai if you have a problem.
The Linux kernel has always been focused on outcomes and outputs, which is the right focus. Here's Linus: https://x.com/LundukeJournal/status/2110524360377458786
Outputs: Code quality and long term maintenance matters. Outputs: Serving users with correctness, security and performance matters.
Focus on "purity of input" is a faith-based political filter, not engineering.
The right way is something like, we've been getting spammed with a bunch of PR's from AI that we find difficult to review (because AI allows the average bob who isn't technically minded to make a PR). We have therefore decided not to allow AI submissions.
---
I think the people who have some moral / ideological issue and bring that into projects kind of feel like clowns to me. I agree with Linus that the point is to make something that people find useful, and obviously you want it to be maintainable.
Saying "it makes you dumber etc" is not related to the project, with all due respect it's non of your fucking business how I learn / retain skills.
I feel people have the right to bring any sort of issue into the projects they make. Nobody is forced to participate.
In a world where software exerts considerable control and influence over peoples' lives, your ability to insulate yourself from that influence is a priveledge. Software IS ideological. Free software was created so people can have the freedom to share and collaborate on their own terms. There is an extent to which it gets extreme, but without the GPL we would live in an even more monopolistic "free" market hell world than we already do. That's a moral obligation that spawned a practical one. If no one ever took a moral stance because you find it annoying, the world would be an objectively worse place.
I am not claiming that they must stop following their silly ideas. I am just saying they are silly.
It's their own business to disallow AI contributions. But instead of adding that to the Code Of Conduct they chose to knowingly misuse a file to target a group of people they don't like.
If I want to use AI on my copy of that repo, I have to delete that file and consider if the developer has added any more of what is (by intent) basically malware to the source code. Sure the file is just an unhinged rant, but now I have to wonder if they attempted to put some prompt injection in the repo.
Like, c’mon now. This is far from the weirdest open source restriction.
Would you be OK if a repo had Visual Studio files that were designed to crash visual studio if they are used, just because the maintainer hates Microsoft? That's what this feels like, a deliberate malicious abuse of the intent that adding agents.md would otherwise imply.
Nice. I think I loaded MrChromebox onto my Google Pixel some years ago. I should see if it can get Libreboot now.
How time consuming would it be to contribute this work to coreboot/libreboot? I really wish I could just send this data to someone because I don't have time to do this "properly" right now.
I'm now working on the 2nd ChromeOS device in this PR right now: https://github.com/linuxboot/heads/pull/2225 And there is a 3rd port by someone else: https://github.com/linuxboot/heads/pull/2219
I'm surprised Libreboot was able to add all the ChromeOS devices at once, Just adding the 2 ports for Heads hasn't been easy, although I'm not an expert when it comes to Coreboot.
Anyway, I love seeing more support for Chromebooks, they are great devices. Funny enough my Acer Chromebook (Kano) is now more open and more secure than my Framework 13s.
Besides considering frontier LLMs a serious threat to humanity, I find LLM-assisted programming simply...not fun! I tolerate only AI-assisted bug reports, as they are genuinely useful.
My issues, personally, are the IP rights issues. What was this shit trained on? When the bubble pops (as I've said a lot in this thread -I know) who's going to shake me down?
There is also the Framework 13 Chromebook edition, but that seems almost impossible to find now-a-days.
It just works and that's great.
This is interesting given Googlebooks actually use the same boot process as Chromebooks, they just chain into aboot.
This is great news! Finally an open-source UEFI replacement which can work on nearly every Chromebook, including used/old Chromebooks!
Now, I haven't reviewed the source... it may still contain binary blobs for various drivers; I don't know. If it doesn't, then that's absolutely awesome! But if it does, then remember that having some of the UEFI firmware code open-source is a huge step forward, and it's only a matter of time before those closed-source binary blobs are reverse engineered (possibly by AI) and/or rewritten from scratch entirely, as open-source codebases...
So, a good step forward for open-source, right-to-repair, understandability of the boot chain, the Chromebook hardware ecosystem (used and new), and tranparency in general!
I am very glad to see people with opinions that flow into what they do, but the question becomes: are you trying to make the best software, or make the most idealistic software? There's a big difference.
I am not at all advocating the use of straight AI slop, but with a policy like that you're opening yourself up for missed bugs, security issues, delayed features, and other things. Especially if you move away from software just because an AI wrote one line of code in it. You can still review the code. If it does the thing right, then use it!
But... it should be binary specifications with "human-like" assembly implementations since you have to remove the "compiler" issue from the SDK.