[nlh]

I'm guessing a lot of similar debates were had in the 1970s when we first started compiling C to Assembly, and I wonder if the outcome will be the same.

(BTW: I was not around then, so if I'm guessing wrong here please correct me!)

Over time compilers have gotten better and we're now at the point where we trust them enough that we don't need to review the Assembly or machine code for cleanliness, optimization, etc. And in fact we've even moved at least one abstraction layer up.

Are there mission-critical inner loops in systems these days that DO need hand-written C or Assembly? Sure. Does that matter for 99% of software projects? Negative.

I'm extrapolating that AI-generated code will follow the same path.

[groos]

The high level language -> assembly seems like an apt analogy for using LLMs but I would like to argue that it is only a weak one. The reason in that, previously, both the high level language and the assembly language had well defined semantics and the transform was deterministic whereas now you are using English or other human language, with ambiguities and lacking well-defined semantics. The reason math symbolisms were invented in the first place is because human language did not have the required unambiguous precision, and if we encounter hurdles with LLMs, we may need to reinvent this once more.

[crabbone]

This debate didn't start with C. Compilers existed pretty much since Algol, and the debate was there too.

There were also similar arguments made about certain other mechanisms that programmers expected to become obsolete over time, but which never did. For example, all the "visual programming" that later transformed into "no code" programming never really delivered on the promise. (We still have a bunch of tools and languages that carry the "visual" adjective in them, but very few people remember why that adjective was there in the first place). Eg. Visual Basic was supposed to be visual because you'd build interfaces by dragging components into the designer view of your IDE and then using graphical editor style interface to position them, label them etc. Not only MSVS came with the "designer" view, Eclipse had one too, probably more than one. Swing had its own "designer" as did a bunch of other UI frameworks.

Programmers also believed that flat files will be gone and be replaced by some sort of a structured database with an advanced query mechanism. Again, never happened, and the idea is mostly abandoned today as the storage moved on in a completely different direction.

Object databases: (not to be confused with object store like S3) the direction that seemed all but assured at the down of objects -- never really happened either. Instead we still struggle with ORM, and it's not sure that ORM will not die off eventually.

I wouldn't be so quick as to profess AI prompt libraries to replace source code. There are many problems with this idea, beside the quality of the output. The control of the AI agents and their longevity (in source code this is ensured by standards). Collaborative programming: how people w/o access to the agent are supposed to work with the prompt library instead of the source code?

I don't think we are anywhere close to the point where we can realistically expect prompt libraries to be a generally accepted replacement for the source code. In some niche cases? -- perhaps, but not more than that.