You could say the same thing about the transition from assembler to C in the 1970s and early-1980s, albeit that was at vastly smaller scale of impact. It’s not that nobody knows _anything_. We still direct the machines, just in a different way. And if what comes out the other side satisfies our needs, does it matter what lies beneath?

Tail risks have always existed in software development. The tail risk of a bug introduced by some dev who quit five years ago is similar to the tail risk of a bug introduced by Claude six months ago. Deal with it by building better visibility into how your systems work. Demand that your agents write good documentation to accompany their code-writing.

If you’re doing it right these days, it means you’re thinking of a much bigger picture and containing downside risks as boldly as you’re expanding the frontier of upside opportunities.

You did not have to know about the assembly most of the time _because_ the assembly output of the compiler would be guaranteed (bugs notwithstanding) to conform to certain rules. Not the case with an LLM