That's not actually true. Nobody understands everything about how an airplane works, not even the lead engineers. Nobody understands everything about how a car works, or how medical billing works, or how taxes work, or how traffic flow works, or how a CPU works, or how almost anything works. You just need to understand the broad picture and be able to find the details when necessary.

Of course people do.

The fear of deskilling is very valid and is already messing things up.

Contrast this with a vibe-coded "airplane" where nobody actually understands the tires and you're basically operating on a set of assumptions. The tires are not rated and there's no trusted organization. Maybe it works, but you don't actually know. Very different; don't play language games.

Cal used to require EECS students learn how to make a basic CPU. Students at CalTech learn how to make advanced planes as student projects.

Plenty of people have a deep understanding of software/hardware, as that's the context here. I personally can take you from usermode, through the kernel (both NT and Linux), down to the hardware interface, explaining the vast majority of systems along the way, and critically, as they relate to performance concerns.

So can plenty of others who actually know+understand things.

Because most AI generated code is incredibly verbose and noisy. This can be true for any codebase, but it is especially egregious in AI codebases. It is hard to prevent that by just saying "be concise" because knowing exactly where to be concise is the measure of true skill/intelligence.

Every time I have success with AI coding, it is because whatever I need done can work as a pure function, where the probability I have to return to it is very very low.

Making sense of a codebase is like putting together a puzzle. A purely AI generated codebase is like trying to put it together without a picture on the pieces.

You won't want it back. How much time do you spend surfing through your .o or .obj files today?

But there are still libraries where familiarising yourself with the header is important, for example stb's libraries. man(1) and GNU Info were both invented to be computer-stored reference manuals, and indeed to this day you can type `man 3p open` to get the POSIX documentation of the system up in front of you.

I am not aware of many codebases that have manuals as complete as this, but back in the day (1970s-era to the 1990s-era) there would be internal documentation written as par of course for the specification created by the waterfall model of development. Post-2010 companies are very lackadaisical about documenting internal interfaces and libraries because they come from startup cultures where "move fast and break things" is the name of the game.

Those are not the source of truth for the application logic. But the higher level code is.

The application code describes the behavior of the program and the compiler translates it into a different representation following a set of known, deterministic rules. This is unlike an LLM producing code from a prompt, which is why the source code is still the source of truth, and not a bunch of prompts.

I think if people change their mind in six months, let alone 3 years, they would just rewrite it again with something different, or just double down on the AI rewrite to rewrite the rewrite to fix the gaps and so on. It's a rabbit hole.

What people are completely missing with AI is that when a company/someone makes the decision (which is most these days) to go heavily on the AI route, they are probably going to keep going that way.

We don't really know what’s the right balance of AI and People right now.

My personal take would be to leverage AI to fix and improve what already exists in a maintainable way and wait for others to experiment with going heavily AI. It's worked great for Apple who is generally years behind in a lot of things because they wait it out for others to experiment with things.

Things ship and change way too fast and the changes are massive.

Consequently, porting my game engine from Java to Rust was more challenging than I had anticipated.

If a model can tell you anything you’d hope to have a human tell you, what’s the difference? It’s a different point of failure— models can go offline, but employees can also quit anytime too.

the native app wins every single time. Give me native or give me death!