I created a semi-popular plotting library back in university. The project still seems to be mostly used in academia, so a lot of the PRs and issues were from students and researchers - people who mean well, but don't always produce the highest-quality bug reports or code.
Initially I put a lot of effort into looking into bugs and cleaning up PRs to incorporate the useful parts. But I hadn't had the energy to work on this project in years, and over time collected a backlog of hundreds of issues and dozens of PRs.
Inspired by the Artcraft suite, I finally took the plunge and decided to automate the whole process as an experiment. I wrote a set of guidelines that roughly match what i would personally care about in a PR, and handed over to claude. I intentionally didn't look at or second guess any the judgments it made.
And...now i'm convinced this is the future. All PRs are merged or declined, issues are triaged, bugs are investigated and fixed where possible. I spot-checked a few instances, and its way more polite and patient than i ever was. The code is reasonable as well.
Most people I've talked to seem to be worried that following this approach will turn projects into an unmaintainable mess, but I'm not really seeing it. I mean, sure, it will happen to some degree, but every other pre-AI project is also an unmaintainable mess to some degree.
When OpenAI and Anthropic simultaneously announced their disproofs of the Exponential Time Hypothesis, it sparked a lot of commentary about the significance of the result, and the implications for AI and the future of mathematics.
But there was not a whole lot written about the how, ie. what's the trick that allowed them to break the exponential time barrier for SAT? How does the proof actually work?
So this video started as an experiment, can a simple "Hey claude, make me a 10-minute explainer video of this recent result" prompt produce something that can explain a research-grade mathematical result to an interested layman like myself?
The answer turns out to be "no": While Opus 5.5 and Astra are able to comprehend and answer questions about the proof, both of them are no great judges of which steps might be hard for a human to follow, where to add motivation, and in what order to introduce results. (in that sense, they're similar to human maths professors)
So here I share the final stage of this experiment, after several more hours of polishing and fine-tuning the result, until I actually felt I understood the main ideas.
How does it open the door to that? That's literally the argument that was rejected by saying the fair use defense only counts for the legally-acquired media.
> “Like any reader aspiring to be a writer, Anthropic’s LLMs trained upon works not to race ahead and replicate or supplant them — but to turn a hard corner and create something different,”
That's my mistake.
I went back and read the actual opinion, and while I'm disappointed that training an LLM is fair-use transformative, I'm hopeful about a trial on the subject of the pirated copies. But I'm also worried that the argument seems like it might succeed if such training is "one-shot" without the central library or repository of intermediate copies. And that doesn't seem like a good outcome. But maybe my pessimism here is also misplaced.
It's like fan fiction: sneaking into theatre to watch a movie without paying for admission is illegal, but writing fan fiction about the movie and publishing it on AO3 is legal.
How can a software developer not do the one basic abstraction step to see them both as tools with some unknown, low probability of error?
The human developer+compiler+linker toolchain isn't free of bugs either, some percentage it will produce code that fails loudly and sometimes it will produce code that has silent bugs, be it due to wrong source code or due to compiler or linker bugs.
Normal software can be reviewed to attempt to find bugs, and bugs can be fixed..!
LLMs instead are inscrutable, can output whenever at any time and you can't "fix their bugs"!
And don't attempt to place the probability of error of LLMs and normal software on the same plane, LLMs for the time being are wildly more unpredictable.
Given how many security vulnerabilities SOTA models are able to catch in software we've considered some of the most mature ever written, they can most certainly be more reliable in certain contexts and when used certain ways.
They're sure useful to find some vulnerabilities not previously noticed, but that doesn't make them write code better than humans.
Making them review LLM-generated code will probably catch some errors and vulnerabilities, but could well leave there insanely dangerous hallucinated code.
Are you working only with exceptionaly (like world class) good engineers that happen to write code by hand ? Because otherwise I'd find your claims dubious.
Meanwhile I've been dealing with so much human slop (including mine) for the last 25 years that what comes out of LLMs in 2026 is an absolute relief.
My claims? Do I live on a different universe? However bad "human slop" can be, an honest human is not going to write the completely senseless, security-shattering code that an LLM can output..!
You don't see what's going to happen if you don't even have a look at it?
You clearly must have been extremely lucky in your work environment then. As humans we've been tossing bugs and security issues for decades.
Current LLM output is so much better than what I or my colleagues used to write, on every levels. Better readability when properly steered, better performance, better security, everything. Frankly this year has been a humbling experience.
> Do I live on a different universe ?
I guess...
> You don't see what's going to happen if you don't even have a look at it?
This whole discussion is about not looking at it, did you see the initial post?
You are aware that howwer much better to your hellish experience the average LLM output is, it's going to spit brain-dead, extremely dangerous nonsense sometimes?
> it's going to spit brain-dead, extremely dangerous nonsense sometimes
Again, in my experience it's very rare (and rarer than at the beginning of this year). What was your experience with these tools ?
I'm not OP, and I'm not defending the point of not looking at the code at all or not doing any review. I do think checking each line is definitely not necessary and the amount of verification should be adapted to your domain.
However rare it might be, do you agree that it justifies checking all of the code?
How can you verify the code if you don't verify "each line"?
You can maybe check them with less care, yes.
But even for the most frivolous domains, in most cases malicious software can cause a lot of damage (for on example on older systems), so it is irresponsible to not check it, in my opinion.
No, definitely not. We've all been using libraries for decades with very real (and not rare at all) human-made bugs in them and almost never verified the code by reading each and every line. That would be impractical in most cases, even if it may be required in a few rare cases. What we do is test, to very various degrees depending on the domain.
There'd be a debate to have about why LLMs are threatening to some engineers while they are empowering to others. I'm having a blast producing the best output I ever done while some of my colleagues are suffering to the point of thinking about changing careers. There must be deep psychological reasons to this.
Libraries are (or used to be) written by humans, Jodie, which if honest don't add obviously devastating code.
For open source libraries there's a chance that some of its users reviewed the code, for commercial libraries there's the legal risks holding them from being excessively careless.
LLM code instead can only be looked upon by you.
And, until a short while ago we were worrying of how to reduce the risks placed by libraries, with dependency cooldowns etc. Now we decided that we can ship random code seen by absolutely no one?
> There'd be a debate to have about why LLMs are threatening to some engineers
You're claiming that if an engineer doesn't like LLMs it's because he feels threatened by them?
There definitely are at least two very different groups of software developers: one that enjoys writing code, and the mechanicality and predictability of it, and one that maybe doesn't love developing, and for sure cares more about making a product, and maybe about the money that you can earn from it.
This is the purely psychological difference, but then there's a group of developers who feels the responsibility for what they do, realizes what effects their software can have and does what it can to protect its users; and another group that doesn't care too much, and considers their user's fault to decide to use their software, and to possibly harm other people through its use.
And, if your capabilities are limited, or your company forces you to go too fast, for sure the average LLM output can be better than your average code.
Not all LLMs fans are like that, of course, many just have misconceptions and don't realize the risks.
No, they boil down to the idea that their worst output is tremendously worse and more dangerous than the worst output of the average (honest) engineer.
If the photocraft suite had been manually written in 2022, with the exact same source code as it has right now, they would be the poster open-source project that people would point to for the power of an open-source community over proprietary software and be praised for the high standards of the source code.
Just yesterday I tried out Gemini again after a while, and it was not able to open Google Maps in navigation mode to the destination i wanted.
For the purposes of writing this comment, i asked it to put on some Jazz in Youtube (i have youtube music with a premium account on the same device and same google account) and it started a Spotify Jazz playlist.
Google might still have the popular products from 20 years of history, but after years of them trying there's no indication whatsoever that they have the ability to shape it into a coherent product.
A hero hacking for free food and a chance to swap Cloudflare credits for stolen goods on the black market. That is W.Gibson's original cyberpunk spirit.
AI is here to stay - will be around for hundreds/millions of years. Whether company A is a few years ahead of company B is irrelevant. In 10 years time company A, who started the industry, may be gone completely - also irrelevant.
Just open weights are not enough, I think as a nation state you'd at least want a whole sovereign training pipeline. Otherwise you are stuck when Kimi K4 stops releasing their weights.
But I don't see why this needs to be done on a state-by-state level, a sovereign EU model seems to be much more realistic in terms of funding.
You want to, of course. There are several multi-billion dollar programs to subsidize fabs starting european offshoots. But so far not very successful, and it's not like one endeavour is blocking the other here.
Would that change anything about the conclusion? Having a "bug" that changes available model options for some small set of Pro users 3 months after launch certainly qualifies as a wtf-are-they-even-doing level of bug in my book.
Initially I put a lot of effort into looking into bugs and cleaning up PRs to incorporate the useful parts. But I hadn't had the energy to work on this project in years, and over time collected a backlog of hundreds of issues and dozens of PRs.
Inspired by the Artcraft suite, I finally took the plunge and decided to automate the whole process as an experiment. I wrote a set of guidelines that roughly match what i would personally care about in a PR, and handed over to claude. I intentionally didn't look at or second guess any the judgments it made.
And...now i'm convinced this is the future. All PRs are merged or declined, issues are triaged, bugs are investigated and fixed where possible. I spot-checked a few instances, and its way more polite and patient than i ever was. The code is reasonable as well.
Most people I've talked to seem to be worried that following this approach will turn projects into an unmaintainable mess, but I'm not really seeing it. I mean, sure, it will happen to some degree, but every other pre-AI project is also an unmaintainable mess to some degree.
reply