For some reason these fully functional ai generated projects that the authors vibe out while playing guitar and clipping their toenails are never open source.
https://github.com/TeMPOraL/qr-code-generator
Built with Aider and either Sonnet 3.5 or Gemini 2.5 Pro (I forgot to note that down in this project), and recently modified with Claude Code because I had to test it on something.
Getting the first version of this up was literally both faster and easier than finding a QR code generator that I'm sure is not bloated, not bullshit, not loaded with trackers, that's not using shorteners or its own URL (it's always a stupid idea to use URL shorteners you don't control), not showing ads, mining bitcoin and shit, one that my wife can use in her workflow without being distracted too much. Static page, domain I own, a bit of fiddling with LLMs.
What I can't link to is half a dozen single-use tools or faux tools created on the fly as part of working on something. But this happens to me couple times a month.
To anchor another vertex in this parameter space, I found it easier and faster to ask LLM to build me a "breathing timer" (one that counts down N seconds and resets, repeatedly) with analog indicator by requesting it, because a search query to Google/Kagi would be of comparable length, and then I'd have to click on results!
EDIT: Okay, another example:
https://github.com/TeMPOraL/tampermonkey-scripts/blob/master...
It overlays a trivial UI to set up looping over a segment of any YouTube video, and automatically persists the setting by video ID. It solves the trivial annoyance of channel jingles and other bullshit at start/end of videos that I use repeatedly as background music.
This was mostly done zero-shot by Claude, with maybe two or three requests for corrections/extra features, total development time maybe 15 minutes. I use it every day all the time ever since.
You could say, "but SponsorBlock" or whatever, but per what GP wrote, I just needed a small fraction of functionality of the tools I know exist, and it was trivial to generate that with AI.
https://github.com/neocotic/qrious
All the hard work was made by humans.
I can do `npm install` without having to pay for AI, thanks.
Real musicians don’t mix loops they bought.
Real musicians make their own synth patches.
Real musicians build their own instruments.
Real musicians hand-forge every metal component in their instruments.
…
They say real musicians raise goats for the leather for the drum-skins, but I wouldn't know because I haven’t made any music in months and the goats smell funny.
1) even though most of people on here know what npm is, many of us are not web developers and don't really know how to turn a random package into a useful webapp.
2) The AI is faster than googling a finished product that already exists, not just as an NPM package, but as a complete website.
Especially because search results require you to go through all the popups everyone stuffs everywhere because cookies, ads, before you even find out if it was actually a scam where the website you went to first doesn't actually do the right thing (or perhaps *anything*) anyway.
It is also, for many of us, the same price: free.
You only need to search for “loops goat skin”. You’re butchering the quote and its meaning quite a bit. The widely circulated version is:
> I thought using loops was cheating, so I programmed my own using samples. I then thought using samples was cheating, so I recorded real drums. I then thought that programming it was cheating, so I learned to play drums for real. I then thought using bought drums was cheating, so I learned to make my own. I then thought using premade skins was cheating, so I killed a goat and skinned it. I then thought that that was cheating too, so I grew my own goat from a baby goat. I also think that is cheating, but I’m not sure where to go from here. I haven’t made any music lately, what with the goat farming and all.
It’s not about “real musicians”¹ but a personal reflection on dependencies and abstractions and the nature of creative work and remixing. Your interpretation of it is backwards.
I am sorry, none of your points are made. Makes no sense.
The LLM work sounds dumb, and the suggestion that it made "a qr code generator" is disingenuous. The LLM barely did a frontend for it. Barely.
Regarding the "free" price, read the comment I replied on again:
> Built with Aider and either Sonnet 3.5 or Gemini 2.5 Pro
Paid tools.
It sounds like the author payed for `npm install`, and thinks he's on top of things and being smart.
Yes, and?
The goal wasn't "write me a QR library" it was "here's my pain point, solve it".
> It sounds like the author payed for `npm install`, and thinks he's on top of things and being smart.
I can put this another way if you prefer:
Running `npm install qrious`: trivial.
Knowing qrious exists and how to integrate it into a page: expensive.
> > Built with Aider and either Sonnet 3.5 or Gemini 2.5 Pro
> Paid tools.
I get Sonnet 4 for free at https://claude.ai — I know version numbers are weird in this domain, but I kinda expect that means Sonnet 3.5 was free at some point? Was it not? I mean, 3.7 is also a smaller version number but listed as "pro", so IDK…
Also I get Gemini 2.5 Pro for free at https://aistudio.google.com
Just out of curiosity, I've just tried using Gemini 2.5 Pro (for free) myself to try this. The result points to a CDN of qrcodejs, which I assume is this, but don't know my JS libraries so can't confirm this isn't just two different ones with the same name: https://github.com/davidshimjs/qrcodejs
My biggest issue with this kind of thing in coding is the same as my problem with libraries in general: you're responsible for the result even if you don't read what the library (/AI) is doing. So, I expect some future equivalent of the npm left-pad incident — memetic monoculture, lots of things fail at the same time.
qrious literally has it integrated already:
https://github.com/davidshimjs/qrcodejs/blob/master/index.ht...
I see many issues. The main one is that none of this is relevant to the qemu discussion. It's on another whole level of project.
I kind of regret asking the poor guy to show his stuff. None of these tutorial projects come even close to what an AI contribution to qemu would look like. It's pointless.
So the fact they've already got the example is great if you do in fact already have that knowledge, and *completely useless* if you don't.
> I kind of regret asking the poor guy to show his stuff. None of these tutorial projects come even close to what an AI contribution to qemu would look like. It's pointless.
For better and worse, I suspect it's very much the kind of thing AI would contribute.
I also use it for things, and it's… well, I have seen worse code from real humans, but I don't think highly of those humans' coding skills. The AI I've used so far are solidly at the quality level of "decent for a junior developer", not more, not less. Ridiculously broad knowledge (which is why that quality level is even useful), but that quality level.
Use it because it's cheap or free, when that skill level is sufficient. Unless there's a legal issue, which there is for qemu, in which case don't.
I didn't know qrious exist. Last time I checked for frontend-only QR code generators myself, pre-AI, I couldn't find anything useful. I don't do frontend work daily, I'm not on top of the garbagefest the JS environment is.
Probably half the win applying AI to this project was that it a) discovered qrious for me, and b) made me a working example frontend, in less time than it would take me to find the library myself among sea of noise.
'ben_w is absolutely correct when he wrote:
> The goal wasn't "write me a QR library" it was "here's my pain point, solve it".
And:
<quote>
Running `npm install qrious`: trivial.
Knowing qrious exists and how to integrate it into a page: expensive.
</quote>
1. It worked and was trivial to use
2. Was 100% under my control, to guarantee no tracking, telemetry, ads, crypto miners, and other usual web dangers, are present, and ensure they never are going to be present.
3. It had no build step whatsoever, and minimal dependencies that could be vendored, because again, I don't do webshit for a living and don't have time for figuring out this week's flavor of building "Hello world" in Node land.
(Incidentally, I'm using Claude Code to build something bigger using a web stack, which forced me to figure out the current state of tooling, and believe me, it's not much like what I saw 6 months ago, and nothing like what I saw a year ago.)
2 and 3 basically translate to "I don't want to ever think about it again". Zero ops is my principle :).
----
> I see many issues. The main one is that none of this is relevant to the qemu discussion. It's on another whole level of project.
It was relevant to the topic discussed in this subthread. Specifically about the statement:
> But there are also local tools generated faster than you could adjust existing tools to do what you want. I'm running 3 things now just for myself that I generated from scratch instead of trying to send feature requests to existing apps I can buy.
The implicit point of larger importance is: AI contributions may not show up fully polished in OSS repos, but making it possible to do throwaway tools to address pain points directly provides advantages that compound.
And my examples are just concrete examples of projects that were AI generated with a mindset of "solve this pain point" and not "build a product", and making them took less time and effort than my participation in this discussion already did.
Since you're here, I have another question relevant to the thread: do you pay for AI tools or are you using them for free?
I pay for them; until last week, this was almost entirely[0] pay-as-you-go use of API keys via TypingMind (for chat) and Aider (for coding). The QR code project I linked was made by Aider. Total cost was around $1 IIRC.
API options were, until recently, very cheap. Most of my use was around $2 to $5 per project, sometimes under $2. I mostly worked with GPT-4, then Sonnet 3.5, briefly with Deepseek-R1; by the time I got around to testing Claude Sonnet 3.7, Google released Gemini 2.5 Pro, which was substantially cheaper, so I stuck to the latter.
Last week I got myself the Max plan for Anthropic (first 5x, then the 20x one) specifically for Claude Code, because using pay-as-you-go pricing with top models in the new "agentic" way got stupidly expensive; $100 or $200 per month may sound like a lot, but less so when taking the API route would have you burn this much in a day or two.
--
[0] - I have the $20/month "Plus" subscription to ChatGPT, which I keep because of gpt-4o image generation and o3 being excellent as my default model for random questions/problems, many of them not even coding-related. I could access o3 via API, but this gets stupidly expensive for casual use; subscription is a better deal now.
Interesting; I'm finding myself doing the opposite — I have API access to at least OpenAI, but all the SOTA stuff becomes free so fast that I don't expect to lose much by waiting.
My OpenAI API credit expired mostly unused.
I don't think anyone is claiming that. If you submit changes to a FOSS project and an LLM assisted you in writing them how would anyone know? Assuming at least that you are an otherwise competent developer and that you carefully review all code before you commit it.
The (admittedly still controversial) claim being made is that developers with LLM assistance are more productive than those without. Further, that there is little incentive for such developers to advertise this assistance. Less trouble for all involved to represent it as 100% your own unassisted work.
AI “assistance” is a short intermediate phase, like the “centaurs” that Garry Kasparov was very fond of (human + computer beat both a human and a computer by itself… until the computer-only became better).
Was your comment tongue-in-cheek? If not, where is this huge mass of AI-generated software?
Admitting such is like admitting you are overpaid for your job, and that a 20 USD AI-agent can do better and faster than you for 75% of the work.
Is it easy to admit that you have learnt skills for 10+ years that are progressively already getting replaced by a machine ? (like thousands of jobs in the past).
More and more, developer is going to be a monkey job where your only task is to make sure there is enough coal in the steam machine.
Compilers destroyed the jobs of developers writing assembler code, they had to adapt. They insisted that hand-written assembler was better.
Here is the same, except you write code in natural language. It may not be optimal in all situations but it often gets the job done.
Okay, not in every case, but in many, and that's where we're headed. The reason is economics - i.e. the same reason approximately no one in the West repairs their clothes or appliances; they just throw the damaged thing away and buy a new one. Human labor is expensive, automated production is cheap - even more so in digital space.
There is a lot of man made stuff you just cannot easily replace. Instead, we maintain it.
Remember, _this is not about you_. The post is about qemu.
I would argue that qemu is analogous to one of these pieces of infrastructure. There is only a handful of powerful virtual machines. These are _not_ easily replaceable commodities.
You don't fix their parts either, unless you absolutely have no other options. Maintenance involves replacing parts that are broken or are approaching the end of their service period.
(Infrastructure in some places is also special because it's so badly funded it's not maintained at all, but that's out of scope of this analogy).
> Remember, _this is not about you_. The post is about qemu.
The post is about qemu. The comment, as well as most of the comment thread, is talking about coding in general.
Sure, many things still get repaired - usually when they're expensive enough to dwarf marginal cost of repair labor. But if you dig into it, repair often involves treating parts as disposables, and tools as consumables.
You don't build these parts in assembly lines. They're often not cheap commodities.
Satellites, for example, are full of parts made by hand because no assembly line can handle the requirements.
These, require specialized troubleshooting (debugging).
If you're talking exclusively about the cheap stuff (trivial programs), you're in the wrong thread (arguibly, the wrong website). We gave you a little space, but that's a courtesy that other environments might not extend.
Granted I don't think something as specialized as QEMU is well suited to a component replacement model. But large parts of the codebases of the vast majority of software out there is.
Were the most extreme of edge cases. That was entirely because of space economics being stuck in a death spiral. SpaceX near single-handedly[0] turned this around, by focusing on slashing launch costs and increasing launch cadence. Both of that lead to more missions, meaning less risk, so satellites can be smaller and made of cheap COTS parts because now you can do 10 for price of 1, which enables economies of scale, blah blah. A feedback loop.
Or rather, the feedback loop. It's the same one that enabled mass production and commodities in every aspect of our lives. Satellites aren't an exception to my argument - space industry is just late to the party, but it's going through a commoditization process right now, in front of our very eyes.
10+ years from now, you won't find a hand-made part in any satellite outside obscure prototype edge cases.
--
[0] - Of course it was possible thanks to NASA COTS programs which funded it, and accumulation of knowledge, etc. SpaceX was the "operating end" of this transformation.
SpaceX took years to develop and debug their own engine, from scratch. Highly specialized work.
They proud themselves of not relying on external supply chains, and doing everything in house.
The refurbishment of boosters is very much what I described earlier "you don't throw away good stuff, you maintain it".
So, in a sense, you went around your own argument without noticing and proved my point.
The degree of vertical integration lets them optimize production of the boosters. They're not throwaway things, but they're not pets either. They streamline production of parts as much as possible - but the point of reusability is to cut costs by orders of magnitude, and increase launch cadence, all of which created conditions for the rest of the space industry to scale up production.
In short: SpaceX not throwing away boosters enables everyone else to throw away satellites. SpaceX, too - consider the size of the Starlink constellations. These are not hand-made "pets".
Also consider their entire philosophy that led to reusable F9s: just keep launching, let shit explode, because throwing away more means making more gets cheaper, and learning gets faster. Even as they're an actual, well-tested product, reusability is still a book-keeping thing. They don't worry much about losing a booster or three, they can just make more - it's just more flights per booster on average -> lower costs for everyone.
And then also look at where they're heading: Starship is basically a steel can with some engines on top. The reasoning is similar: they need to be cheap to make at scale.
The example you provided, the QR code generator, presents none of those qualities.
You used multiple AIs from different vendors (according to you: Sonnet and Gemini), a middleman (Aider), to produce a product that is not vertically integrated (uses qrious).
Meanwhile, qemu depends only on a tight set of dependencies (gcc, glib2, everything else optional). They are actually a good case of vertical integration.
In my opinion, you got it all reversed.
--
Starship is a terrible example. After failing to produce composite materials in house using an automated process, they hired specialized metal workers to do the body in steel, by hand. Again, it favors my line of reasoning that commoditization has many limitations.
--
You are also drifting away from the subject drastically, again. I have to constantly pull you in and remember you that we're talking about software first.
Not only you left the qemu subject, but now you forgotten that your own qr-generator _that you have chosen to showcase here_ has many of the failures you're now pointing at.
If you're only trying to leave with the last word, you're making it embarassing.
And how is that turning out for us? We have a climate crisis which is already causing immense destruction and deaths and will only get worse.
I’m not sure you could’ve picked a worse argument, you’re refuting your own point.
That makes absolutely no sense.
OK, but I asked for evidence and people just keep not providing any.
"God is all around you; he just works in mysterious ways"
OK, good luck with that.
Wide belief does not equal truth.
--
When you analyze church attendance, it drops to roughly 50% instead of 85% of the population:
https://en.wikipedia.org/wiki/Church_attendance#Demographics
If you start to investigate many aspects of religious belief, like how many christians read the bible, the numbers drop drastically to less than 15%
https://www.statista.com/statistics/299433/bible-readership-...
This demonstrates that we cannot rely on self-reporting to understand religious belief. In practice, most people are closer to atheists than believers.
It's the same thing with AI.
Also a sufficiently good exponential solver would do the same thing.
That is a big assumption. If everyone were doing that, this wouldn’t be a major issue. But as the curl developer has noted, people are using LLMs without thinking and wasting everyone’s time and resources.
https://www.linkedin.com/posts/danielstenberg_hackerone-curl...
I can attest to that. Just the other day I got a bug report, clearly written with the assistance of an LLM, for software which has been stable and used in several places for years. This person, when faced with an error on their first try, instead of pondering “what am I doing wrong” instead opened a bug report with a “fix”. Of course, they were using the software wrong. They did not follow the very short and simple instructions and essentially invented steps (probably suggested by an LLM) that caused the problem.
Waste of time for everyone involved, and one more notch on the road to causing burnout. Some of the worst kind of users are those who think “bug” means “anything which doesn’t immediately behave the way I thought it would”. LLMs empower them, to the detriment of everyone else.
By their own admission, this is just kind of OK. They don’t even know how good or bad it is, just that it kind of solved an immediate problem. That’s not how you create sustainable and reliable software. Which is OK, sometimes you just need to crap something out to do a quick job, but that doesn’t really feel like what your parent comment is talking about.
The most recent release includes a MacOS build in a dmg signed by Apple: https://github.com/banagale/FileKitty/releases/tag/v0.2.3
I vibed that workflow just so more people could have access to this tool. It was a pain and it actually took time away from toenail clipping.
And while I didn't lay hands on a guitar much during this period, I did manage to build this while bouncing between playing Civil War tunes on a 3D-printed violin and generating music in Suno for a soundtrack to “Back on That Crust,” the missing and one true spiritual successor to ToeJam & Earl: https://suno.com/song/e5b6dc04-ffab-4310-b9ef-815bdf742ecb
It began as an experiment in AI-assisted app design and a cross-platform “cat these files” utility.
Since then it has picked up:
- Snapshot history (and change flags) for any file selection
- A rendered folder tree that LLMs can digest, with per-prompt ignore filters
- String-based ignore rules for both tree and file output, so prompts stay surgical
My recent focus is making that generated context modular, so additional inputs (logs, design docs, architecture notes) can plug in cleanly. Apple’s new on-device foundation models could pair nicely with that.
The bigger point: most AI tooling hides the exact nature of context. FileKitty puts that step in the open and keeps the programmer in the loop.
I continue to believe LLMs can solve big problems with appropriate context and that intentionality in context prep is important step in evaluating ideas and implementation suggestions found in LLM outputs.
There's a Homebrew build available and I'd be happy to take contributions: https://github.com/banagale/FileKitty