Do code AIs afford programmers a higher level of abstraction?

One of my claims to fame is to have been the main architect and implementor of the first UML virtual machine. The idea was that developers should express their programs using UML (the Unified Modeling Language) rather than Java at the time, and that work would be faster, better, cheaper than if they hand-coded everything. After all, things got better once we moved from Assembly language to higher-level languages like C, Java, or Typescript.

The UML VM idea never caught on, nor did its sibling, Executable UML. But the idea of giving developers higher levels of abstraction than before to make them more effective has remained a mainstay of computer science and programming language design.

So today, code AIs are providing a new level of expressing what a program or component should do. Developers describe what they want using natural language and review merge requests generated by the AI.

This raises two questions in my mind:

1. Natural language has no precise semantics, at least not like programming languages. So there is vagueness in what developers are describing, opening the doors to a new category of bugs based on misunderstanding intentions.
2. Reviewing code more than writing it will ultimately deskill developers, making me wonder about the implications. How well can you think through a program, including the edge cases, if you are reviewing code that you didn’t write yourself?

The leaky bucket theory of programming with code AIs

To me, AI generated code, even if reviewed and approved by developers, looks like a leaky bucket. The leaks in this case are of a new type, and they result from the code AI and the developer having different world models, misunderstanding each other when communicating about it using natural language, and the developer losing their skills to catch corresponding bugs in code.

Of course all code is like a leaky bucket, because all code has bugs. However, I’m talking about a new type of bug, one caused by the additional indirection of code creation by way of the intermediate code AI. If you are not technical, think of it as a new incarnation of the old Telephone game (“Stille Post” in German) problem. As people communicate on, meaning subtly shifts, and the more intermediaries there are the more final output differs from initial input.

Code AIs are beneficial in that they increase speed of developers who were brought up without code AIs and they also reduce traditional bugs that junior or distracted developers might introduce. At the same time they introduce a new type of bug that requires new skills. I suspect developers need to learn to be much more flexible with speed, in particular to learn when to slow down and review thoroughly. What I don’t know is how to compensate for the deskilling of developers—throwing more AI at the problem seems to be an unlikely solution.