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.
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.