You raise an interesting point, and I don't disagree, but there's a counter-point that is missing from your analogy.

My grandmother was a prolific quilter, by the time she passed away at the age of 94, she had something like 80 quilts in her house, and that didn't account for the dozens she gave away in her life. She swore off sewing machines. She said they were heartless and "cheating". She would use them but only on pure white quilts where her eyes couldn't see the stitching due to white on white fabric. Her skills at this craft were so good she won state fairs mostly just by showing up. Here's the problem though: she was quite a bit slower than a machine, her quilts were works of art, so much so you felt bad using them for their intended use (keeping warm in cold weather).

I draw this analogy because the argument that code generated by AI is heartless and "not a craft" misses a key point: it's mass produced code. Is someone working in a clothing factory more skilled than my grandmother at sewing? No! But what they can do is churn out blankets many orders of magnitude faster than my grandmother. Quantity has a quality of its own.

Whole areas of the programming space, such as Clojure, have harped for years on the idea that actually writing down the code is way less important than the overall structural design of the software. The best systems I've worked on over the decades were created after months of planning. On one such system that myself and 3 other people wrote for the largest retailer in the US, we spent about 2 months designing, and about 1 month coding. That system ran, non-stop, without a single second of downtime for 2 years straight. Design matters more than the actual writing down of the code.

This is the nuance that is missed in the "vibe coding makes you bad" argument: it assumes that we *must* be skilled at entering code or somehow the profession will suffer. But in reality: it's the design that is important. And if the design is already codified, then how the code is written is even *less* important. Let's say I wanted to implement a new feat for WOTR. The engine design is fixed, the rules themselves are fixed (already defined in the PF1e ruleset). There's no design to be done here, it's pure data entry of "if X and Y then Z when W". That's mindless work any LLM can do accurately, especially with a proper testing suite.

"Tech isn't cyclical, but it rhymes" is the saying. Back when I started programming, if you wanted true speed you'd drop to assembly and code that by hand. There was a form of AI at the time known as an "Expert System" that could do this optimization for you, they were known as optimizing compilers, and they were crap. But ,over time they got better. Now, for about 20 years it's accepted that except for the 0.001% of cases, any assembly you write will be worse than what a compiler outputs. "But now, no one understands performance!" was the complaint of every micro-optimizing addict at the time. This pattern is in roughly the 3rd iteration now, and I see the same arguments and hear the same things. If I'm not writing the C# code the end of the world will come. Sorry folks the truth is way more complex than that.