> The point of programming is not to do the same thing again.

That's called an abstraction, which AI is expressly not. If your work involves writing the same code over and over again, you're doing it wrong.

> I’m happy most programming is going away. I was capable but now I’m even more capable at creating solutions.

This describes management.

> The art will stay.

This describes actual engineering.

Why isn’t AI a complex form of abstraction?

It works because it re-uses previous work to solve new problems. That is what abstractions are used for.

From a previous comment, vis-à-vis compilation vs. code generation:

> High-level programming languages use well-defined, limited syntax to encode program behavior in a deterministic way. Compilers translate these directions into programs that should have identical behavior between compiler runs and between different compilers. (If they don't, that's a compiler bug, or else an artifact of UB.) This means you can structurally and provably rely on the high-level programming layer without worrying about what's underneath: the assembly is abstracted away. You also get the massive benefit of being able to tweak and improve the assembly layer independently of the programming language layer, so long as the contract between language and compiler is not violated.

> If AI is a "layer of abstraction," so is working with a bunch of contractors to make your app. The definition is broadened to the point of absurdity. (Solely: "I don't have to think about code anymore," which only touches on the most superficial aspect of an abstraction.)

If there was a way to get a reproducible, deterministic mapping between natural language and code by way of a LLM, that would be an abstraction. But... that's just called a programming language (specifically a transpiler).

Thanks for your insights.

We might call LLMs non-deterministic transpilers / intention guesstimators. But how much mileage can we get out of them?

Being able to somehow describe what is needed in a natural way allows me to solve more problems, to the point of jokingly calling myself and my programming colleagues “product owners”. So your management conclusion isn’t far off.

To me, the interesting part is that I’m actually writing down what I want and designing how it should work in a mix of natural language and code.

This was previously done mostly in code / comments, where it was easy to lose sight of the big picture as working on decent code just took so much time. This was especially true of refactoring after gaining new insights. That type of refactoring (in our codebases) is now nearly free. The code generated is of dubious quality, so this approach only goes so far. Of course, we’d look for $framework / $library to shave off many hours of work. This is what we still do, but mostly faster.

I am, and have been, mostly building on top of an existing pyramid with the benefit that an LLM can consume mountains of documentation, RFCs, bug reports, and so on.

I wonder if the lower layers of the pyramid require more engineering and whether that can also be done properly by being more of a manager. Are LLMs management generators?

So I think that it absolutely is. It is a more predictive form of abstraction, being that the underlying framework is an LLM, but nonetheless, it still is layers of abstraction, no different from the compilers that programmers currently use or any form of translation layer.

I think the argument is irrelevant and idiotic for people to die on one side or the other, that AI is inherently bad or inherently good. I think it's only as useful as the base level knowledge that the person has.