Like say Ä it might be either Ä a single byte, or combination of ¨ and A. Both are now supported, but if you can have more than two such things going in one thing it makes a mess.
That's fundamental to the mission of Unicode because Unicode is meant to be compatible with all legacy character sets, and those character sets already included combining characters.
That has nothing to do with UTF-8; that's a Unicode issue, and one that's entirely unescapable if you are the Unicode Consortium and your goal is to be compatible with all legacy charsets.
Yep, that's the point I was making - that choosing fixed 4-byte code-points doesn't significantly reduce the complexity of capturing everything that Unicode does.
(More than?) half of the difficulty comes from the vocabulary. It’s very much a shibboleth—learn to talk the talk and people will assume you are a genius who walks the walk.
That! It took me a while to start. My education of graph theory wasn't much better than your average college grad. But I found that fascinating and started reading. I was also very lucky to have had two great mentors - my TL and the product's architect, the former helped me to expend my understanding of the field.
It's happening slowly all around. It's not obvious because people producing high quality stuff have no incentive at all to mark their changes as AI-generated. 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.
It's only going to get more pervasive from now on.
> It's not obvious because people producing high quality stuff have no incentive at all to mark their changes as AI-generated
I feel like we'd be hearing from business that crushed their competition by delivering faster or with fewer people. Where are those businesses?
> But there are also local tools generated
This is really not the same thing as the original claim ("Software projects that somehow are 100% human developed will not be competitive with AI assisted or written projects").
> I feel like we'd be hearing from business that crushed their competition by delivering faster or with fewer people. Where are those businesses?
As if tech part was the major part of getting the product to market.
Those businesses are probably everywhere. They just aren't open about admitting they're using AI to speed up their marketing/product design/programming/project management/graphics design, because a) it's not normal outside some tech startup sphere to brag about how you're improving your internal process, and b) because almost everyone else is doing that too, so it partially cancels out - that is what competition on the market means, and c) admitting to use of AI in current climate is kind of a questionable PR move.
WRT. those who fail to leverage the new tools and are destined to be outcompeted, this process takes extended time, because companies have inertia.
>> But there are also local tools generated
> This is really not the same thing as the original claim
Point is that such wins compound. You get yak shaving done faster by fashioning your own tools on the fly, and it also cuts cost and a huge burden of maintaining relationships with third parties[0]
--
[0] - Because each account you create, each subscription you take, even each online tool you kinda track and hope hope hope won't disappear on you - each such case comes with a cognitive tax of a business relationship you probably didn't want, that often costs you money directly, and that you need to keep track of.
Did you notice that what companies say to investors and what they say to the public are usually entirely different things? When they get mixed up - especially when investor-bound information reaches general public - it's usually a bad day for the company.
And because from the outside everything looks worse than ever. Worse quality, no more support, established companies going crazy to cut costs. AI slop is replacing thoughtful content across the web. Engineering morale is probably at an all time low for my 20 years watching this industry...
So my question is: if so many people should be bragging to me and celebrating how much better things are, why does it look to me like they are worse and everyone is miserable about it...?
I think in context of this discussion you might be confused about what the term "better" refers to.
> And because from the outside everything looks worse than ever. Worse quality, no more support, established companies going crazy to cut costs. AI slop is replacing thoughtful content across the web. Engineering morale is probably at an all time low for my 20 years watching this industry.
That is true and present across the board. But consider, all of that is what "better" means to companies, and most of that is caused by actions that employers call success and reward employees for.
Our industry, in particular, is a stellar example - half of the things we make are making things worse; of the things that seem to make things better, half of them are actually making things worse, but it's not visible because of accounting trickery (e.g. specialized roles cut is legible to beancounters; the workload being diffused and dragging everyone else's productivity down is not).
So yeah, AI is making things better for its users, but expect that what's "better" for the industry whose main product is automating people away from their jobs, is going to translate to a lot of misery down the line.
If it was self-evident then I wouldn’t need to ask for evidence. And I imagine you wouldn’t need to be waving your hands making excuses for the lack of evidence.
To me it's self-evident, but is probably one casual step removed from what you'd like to see. I can't point to specific finished or released projects that were substantially accelerated by use of GenAI[0]. But I can point out that nearly everyone I talked with in the last year, that does any kind of white-collar job, is either afraid of LLMs, actively using LLMs at work and finding them very useful, or both.
It's not possible for this level of impact at the bottom to make no change on the net near the top, so I propose that effects may be delayed and not immediately apparent. LLMs are still a new thing in business timelines.
TL;DR: just wait a bit more.
One thing I can hint at, but can't go into details, is that I personally know of at least one enterprise-grade project whose roadmap and scoping - and therefore, funding - is critically dependent on AI speeding up significant amount of development and devops tasks by at least 2-3x; that aspect is understood by both developers, managers, customers and investors, and not disputed.
So, again: just wait a little longer.
--
[0] - Except maybe for Aider, whose author always posts how much of its own code Aider wrote in a given release; it's usually way above 50%.
> One thing I can hint at, but can't go into details, is that I personally know of at least one enterprise-grade project whose roadmap and scoping - and therefore, funding - is critically dependent on AI speeding up significant amount of development and devops tasks by at least 2-3x; that aspect is understood by both developers, managers, customers and investors, and not disputed.
Mm. I can now see why, in your other comment, you want to keep up with the SOTA.
It's actually unrelated. I try to keep up with the SOTA because if I'm not using the current-best model, then each time I have a hard time with it or get poor results, I keep wondering if I'm just wasting my time fighting with something a stronger model would do without problems. It's a personal thing; I've been like this ever since I got API access to GPT-4.
My use of LLMs isn't all that big, and I don't have any special early access or anything. It's just that the tokens are so cheap that, for casual personal and professional use, the pricing difference didn't matter. Switching to a stronger model meant that my average monthly bill went from $2 to $10 or something. These amounts were immaterial.
Use patterns and pricing changes, though, and recently this made some SOTA models (notably o3, gpt-4.5 and the most recent Opus model) too expensive for my use.
As for the project I referred to, let's put it this way: the reference point is what was SOTA ~2-3 months ago (Sonnet 3.7, Gemini 2.5 Pro). And the assumptions aren't just wishful thinking - they're based on actual experience with using these models (+ some tools) to speed up specific kind of work.
Schroedingers AI. It's everywhere, but you can't point to it cause it's apparently indistinguishable from humans, except for the shitty AI which is just shitty AI.
This is happening right now and it won’t be obvious until the liquidity events provide enough cover for victory lap story telling.
The very knowledge that an organization is experiencing hyper acceleration due to its successful adoption of AI across the enterprise is proprietary.
There are no HBS case studies about businesses that successfully established and implemented strategic pillars for AI because the pillars were likely written in the past four months.
Do you think that company success and it's causes are measurable day by day? I've worked for an industrial company that completely screwed up their software development, but their business is rooted so deep into other businesses, that it would take a decade until the result emerges. This may be extreme, but for average business I would expect 2-3 years for these results to be measurable. Startups may be quicker, but it's extremely difficult to compare them as every startup is quite unique. So if you wait for hard evidence, good luck not missing the train.
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.
Going by the standard of "But there are also local tools generated faster than you could adjust existing tools to do what you want", here's a random one of mine that's in regular use by my wife:
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!
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.
I am reminded of a meme about musicians. Not well enough to find it, but it was something like this:
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.
There's two points here:
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.
> I am reminded of a meme about musicians. Not well enough to find it
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.
> > 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…
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.
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.
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>
This is precisely what it was. I built this in between other stuff, paying half attention to it, to solve an immediate need my wife had. The only thing I cared about it here is that:
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.
TL;DR: I pay, I always try to use SOTA models if I can.
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.
> TL;DR: I pay, I always try to use SOTA models if I can.
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.
The very first part of the quotation is "Knowing qrious exists".
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.
> the authors vibe out while playing guitar and clipping their toenails
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.
> Assuming at least that you are an otherwise competent developer and that you carefully review all code before you commit it.
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.
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.
Sure I won't disagree that those people also exist but I don't think that's who the claim is being made about. Pointing out that subpar developers exist doesn't refute that good ones exist.
The point isn’t that “subpar developers exist” but that the tool misuse far outweighs and greatly affects the correct use and even those who don’t use them. These people aren’t even “subpar developers” a lot of the time, they aren’t developers at all. But they still negatively affect and impact good developers and software in general.
Why would you need to carefully review code? That is so 2024. You’re bottlenecking the process and are at a disadvantage when the AI could be working 24/7. We have AI agents that have been trained to review thousands of PRs that are produced by other, generative agents, and together they have already churned out much more software than human teams can write in a year.
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).
> We have AI agents that have been trained to review thousands of PRs that are produced by other, generative agents, and together they have already churned out much more software than human teams can write in a year.
Was your comment tongue-in-cheek? If not, where is this huge mass of AI-generated software?
All around you, just that it doesn’t make sense for developers to reveal that a lot of their work is now about chunking and refining the specifications written by the product owner.
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.
P = NP is less "crush their little hearts", more "may cause widespread heart attacks across every industry due to cryptography failing, depending on if the polynomial exponent is small enough".
This demonstrates that we cannot rely on self-reporting to understand religious belief. In practice, most people are closer to atheists than believers.
And not that long ago, the majority of the population believed the Earth is flat, and that cigarettes are good for your health. Radioactive toys were being sold to children.
Obviously it's the basis for a religion. We're to have faith in the ability of LLMs. To ask for evidence of that is to question the divine. You can ask a model itself for the relevant tenants pertaining to any given situation.
You don't debug AI-generated code - you throw the problematic chunk away and have AI write it again, and if that doesn't help, you repeat the process, possibly with larger chunks.
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.
You don't throw away dams, bridges, factories, submarines, planes.
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 throw away dams, bridges, factories, submarines, planes.
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.
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.
Satellites are the most extreme of edge cases. The equivalent might be a binary that gets burned into a ROM chip installed in an impossible to access location. QEMU is not that.
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.
I think you need to look closer on what SpaceX does, how it does it, and why.
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.
This degree of vertical integration is missing from any of the AI examples you mentioned.
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.
What do the environmental impacts of physical manufacturing have to do with digital goods? The status quo you're objecting to arose specifically because it is cheaper. His argument is sound.
> You don't debug AI-generated code - you throw the problematic chunk away and have AI write it again, and if that doesn't help, you repeat the process, possibly with larger chunks.
> To be clear: this isn't an endorsement of using models for serious Open Source libraries. This was an experiment to see how far I could get with minimal manual effort, and to unstick myself from an annoying blocker. The result is good enough for my immediate use case and I also felt good enough to publish it to PyPI in case someone else has the same problem.
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.
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
This app is concatenating files with an extra line of metadata added?
You know this could be done in a few lines of shell script? You can then make it a finder action extension so it’s part of the system file manager app.
The parent claim was that devs don’t open-source their personal AI tools. FileKitty is mine and it is MIT-licensed on GitHub.
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.
Only the simplest one is open (and before you discount it as too trivial, somehow none of the other ones did what I wanted) https://github.com/viraptor/pomodoro
The others are just too specific for me to be useful for anyone else: an android app for automatic processing of some text messages and a work scheduling/prioritising thing. The time to make them generic enough to share would be much longer than creating my specific version in the first place.
> and before you discount it as too trivial, somehow none of the other ones did what I wanted
No offense, it's really great that you are able to make apps that do exactly what you want, but your examples are not very good to show that "software projects that somehow are 100% human developed will not be competitive with AI assisted or written projects" (as someone else suggested above). Complex real world software is different from pomodoro timers and TODO lists.
> Complex real world software is different from pomodoro timers and TODO lists.
Simplistic Pomodoro timer with no features, sure, but a full blown modern Todo app that syncs to configurable backend(s), has a website, mobile apps, an electron app, CLI/TUI, web hooks, other integrations? Add a login system and allow users to assign todos to each other, and have todos depend on other todos and visualizations and it starts looking like JIRA, which is totally complex real world software.
The weakness of LLMs is that they can't do anything that's not in their training data. But they've got so much training data that say you had a box of Lego bricks but could only use those bricks to build models. If you had a brick copier, and one copy of every single brick type on the Internet, the fact that you couldn't invent new pieces from scratch would be a limitation, but given the number of bricks on all the Internet, that covers a lot of area. Most (but not all) software is some flavor of CRUD app, and if LLMs could only write every CRUD app ever that would still be tremendous value.
Cut it out with patronising, I work with complex software, which is why I specifically mentioned the only example I published was simple.
> but your examples are not very good to show that "software projects that somehow are 100% human developed will not be competitive with AI assisted or written projects"
Here's the thing though - it's already the case, because I wouldn't create those tools but hand otherwise. I just don't have the time, and they're too personal/edge-case to pay anyone to make them. So the comparison in this case is between 100% human developed non-existent software and AI generated project which exists. The latter wins in every category by default.
My apologies, I didn't want to sound patronizing and wasn't making assumptions about your work and experience based on your examples, I am happy that generative AI allows you to make such apps. However, they are very similar to the demos that are always presented as showcases.
I don't think they're being patronizing, it's that "simple personal app that was barely worth making" is nice to have but not at all what they want evidence of.
It doesn't matter that my thing doesn't generalise if someone can build their own customised solution quickly. But also, if I wanted to sell it or distribute it, I'd ensure it was more generic from the beginning.
If you comment about AI generated code in a thread about qemu (mission-critical project that many industries rely upon), a pomodoro app is not going to do the trick.
And no, it doesn't "show that is possible". qemu is not only more complex, it's a whole different problem space.
I'm getting towards the end of a vibe coded ZFS storage backend to ganeti that includes the ability to live migrate VMs to another host by: taking snapshot and replicating it to target, pausing VM, taking another incremental snapshot and replicating it, and then unpausing the VM on the new destination machine. https://github.com/linsomniac/ganeti/tree/newzfs
Other LLM tools I've built this week:
This afternoon I built a web-based SQL query editor/runner with results display, for dev/ops people to run read-only queries against our production database. To replace an existing super simple one, and add query syntax highlighting, snippet library, and other modern features. I can probably release this though I'd need to verify that it won't leak anything. Targets SQL Server.
A couple CLI Jira tools to pull a list of tickets I'm working on (with cache so I can get an immediate response, then get updates after Jira response comes back), and tickets with tags that indicate I have to handle them specially.
An icinga CLI that downtimes hosts, for when we do sweeping machine maintenances like rebooting a VM host with dozens of monitored children.
An Ansible module that is a "swiss army knife" for filesystem manipulation, merging the functions of copy, template, file, so you can loop over a list and: create a directory, template a couple files into it, doing a notify on one and a when on another, ensure a file exists if it doesn't already, to reduce duplication of boilerplate when doing a bunch of file deploys. This I will release as a ansible galaxy module once I have it tested a little more.
None of this seems relevant to the original claim: "Software projects that somehow are 100% human developed will not be competitive with AI assisted or written projects"
I don't feel like it's meaningful to discuss the "competitiveness" of a handful of bespoke local or internal tools.
It's like saying "if we discuss professional furniture making, it's not relevant that you are able to cut, drill, assemble, glue, paint, finish wood quickly with good enough quality".
I vibe-coded my own MySQL-compatible database that performs better than MariaDB, after my agent optimized it for 12 hours. It is also a time-traveling DB and performs better on all benchmarks and the AI says it is completely byzantine-fault-tolerant. Programmers, you had a nice run. /s
Not sure about parent but you could argue Jetbrains fancy auto complete is AI and generates a substantial portion of code. It runs using a local model and, in my experience, does pretty good at guessing the rest of the line with minimal input (so you could argue 80% of each line was AI generated)
Sure. But what's the alternative way of finding out?
Most (perhaps all) places I've worked have had NDAs, which means statements like this are one of the few ways most of us find out what companies like MS are doing internally.
The only other ways I can think of are when hackers leak their entire commit history, or if a court case reveals it. (I don't expect a whistleblower to do so unless they're also triggering one of those other two categories).
This claim just seems like sensationalist marketing BS. If you find the real quote:
> “I’d say maybe 20%, 30% of the code that is inside of our repos today and some of our projects are probably all written by software,” Nadella said during a conversation before a live audience with Meta CEO Mark Zuckerberg.
that's like driving big personal vehicles and having a bunch of children and eating a bunch of meat and do nothing about because marine and terrestrial ecosystems weren't fully destroyed by global warming
Ahh, there you go, environmental activists outright saying having children is considered a crime against nature. Wonderful, you seem to hit a rather bad stereotype right on the head. What is next? Earth would be better of if humanity was eradicated?
Second, the Pixar one is not "mere" translation; it is full localization because they changed the visual to match the "textual" change.
The Pokemon one is where the change was limited to the "text". The translator's heart might have been in the right place (it would depend on how integral to the story it is that the item is onigiri) but didn't have the authority to make the full breadth of changes needed for such adaptation to be successful.
It has little to do with authority and more to do with the effort/return ratio. Visual edits are expensive and dialogue changes are cheap, so it doesn't make sense to redraw frames just for an irrelevant onigiri.
4Kids was very well known to visually change the japanese shows they imported if they thought it was worth it, mostly in the context of censorship. For example, all guns and cigarettes where removed from One Piece, turned into toy guns and lollipops instead.
The most infamous example, however, has got to be Yu-Gi-Oh!. Yu-Gi-Oh started as a horror-ish manga about a trickster god forcing people to play assorted games and cursing their souls when they inevitably failed to defeat him. The game-of-the-week format eventually solidified into the characters playing one single game, Duel Monsters (the Yu-Gi-Oh! TCG itself in the real world), and the horror-ish aspects faded away, although they still remained part of the show's aesthetic, based around Egyptian human sacrifices and oddly-card-game-obsessed ancient cults.
When the manga was adapted to the screen, it started directly with a softer tone[1], especially because the show was to be a vehicle for selling cards in the real world, not dissimilarly to Pokemon and MANY other anime from the era.
Nothing that happens in the show is particularly crude or shocking, it had that kind of soft edginess that fit well with its intended target audience (early teens). I imagine watching Bambi had to be much more traumatizing than anything in the show.
But that was still not enough for 4Kids, which had a pretty aggressive policy of no violence or death. Kind of problematic when the show's main shtick was "Comically evil villain puts our heroes in a contraption that will kill them if they don't win." (You can imagine the frequency these traps actually triggered neared zero).
To solve this, 4Kids invented the Shadow Realm. The show, thanks to its occultist theming, already had examples of people being cursed, or their souls being banished or captured. 4Kids solidified these vague elements into the shadow realm as a censorship scape-goat. Any reference to death was replaced with the shadow realm. Now, one might wonder why the censors thought that "hell-like dimension where your soul wanders aimlessly and/or gets tortured for eternity" was in any way less traumatizing than "you'll die", but I imagine it's because there was always the implication that people could be 'saved' from the shadow realm[2] by undoing the curse.
The Shadow Realm was a massive part of the western Yu-Gi-Oh mythos and even today it's a fairly common meme to say that somebody got "sent to the shadow realm", which makes it all funnier that it is not part of the original show.
A couple funny examples off the top of my head:
- Yugi must win a match while his legs are shackled. Two circular saws, one for him and one for the enemy, are present in the arena. They near the two competitors as they lose Life Points, with the loser destined to have their legs cut off.
In the 4Kids adaptation, the saws are visually edited to be glowing blue, and it's stated they're made out of dark energy that will send anybody that touches it to the shadow realm.
- A group of our heroes fight a group of villains atop of a skyscraper with a glass roof. In the original version, the villains state that the roof has been boobytrapped so that the losing side will explode, plunging the losers to their death by splattening.
In the 4Kids version, the boobytrap remained, but the visuals were edited to add a dark mist under the glass, with the villains stating that there's a portal under the roof that will send anybody that touches it to the shadow realm. This is made funnier when the villains lose and they're shown to have had parachutes with them all along, and they are NOT edited out.
[1] Technically speaking, there was a previous adaptation that followed the manga more closely and got only one season, generally referred to as Season 0.
[2] It does eventually happen in the anime that the heroes go in an alternate dimension to save somebody's cursed soul. Obviously, this dimension was directly identified as the Shadow Realm in the localization.
Do you think the article is speaking primarily to the "aviation community"?
reply