Take sending a packet over a noisy, low SNR cell network. A high number of packets may be lost. This doesn't prevent me, as a software developer, from building an abstraction on top of a "mostly-reliable" TCP connection to deliver my website.

There are times when the service doesn't work, particularly when the packet loss rate is too high. I can still incorporate these failures into my mental model of the abstraction (e.g through TIMEOUTs, CONN_ERRs…).

Much of engineering and reliability history revolves around building mathematical models on top of an unpredictable world. We are far from solving this problem with LLMs, but this doesn't prevent me from thinking of LLMs as a new level of abstraction that can edit and transform code.

      f(x) -> y

Not at all. If this were true then the Python code in question would generate deterministic binary. Of course that’s not what happens. The Python runs through an interpreter that may change behavior on different runs. It may change behavior version to version. It may even change behavior during multiple invocations of a function in the same running instance. Because all of that is abstracted away.

Same for the C code. You give up control and some determinism for the higher abstraction. You might get there same output between compilations on the same version but that’s not actually guaranteed and version to version consistent certainly isn’t.

Moving to a higher layer of abstraction very often results in less constrained behavior.

With changes like substantial refactors or ambitious feature additions, it's easy to exceed the infamous "seven things I can remember at once":

  * the idea for the big change itself
  * my reason for making the change
  * the relevant components and how they currently work
  * the new way they'll fit together after the change
  * the messy intermediate state when I'm half finished but still need a working system to get feedback
  * edge cases I'm ignoring for now but will have to tackle eventually
  * actual code changes
  * how I'm going to test this

  * wiring a new parameter through several layers
  * writing a test harness for an untested component
  * experimentally adding multibyte character support on a branch

The main benefit is to defer the concern until I have a mostly working system. Then I come back and review its output, since I'm still responsible for what it delivers, and I want better than "mostly working".

I have a feeling that if LLMs were built on a deterministic technology, a lot of the current AI-is-not-intelligent crowd would be saying "These LLMs can only generate one answer given a question, which means they lack human creativity and they'll never be intelligent!"

I've gone through hand-coding HTML, CGI, CMSes, web frameworks, and CMSes built with web frameworks. Each is (roughly) a layer of abstraction on top of lower layers.

People talk about LLMs as an extension of this layering but they're not. With the layers of abstraction I've listed you can go down to the layers underneath and understand them if you take the time.

LLMs are something different. They're a replacement for or a simulation of the thinking process involved in programming at various layers.

And LLMs can handle very abstract concepts that could not possibly be encoded in C++, like the user's goal in using software.

However, they can abstract away the need to understand implementation, similar to a coworker. They can summarize behavior, be queried for questions, etc, so you don't have to actually understand the inner workings of what is going on. This is a different form of abstraction than the typical abstraction stack of a program.

Bit like when people say "it's like riding a bike" they're not actually talking about bicyle riding being the exact same activity.

Coming with this in response:

> f(x) -> P(y) ∪ P(z1) ∪ P(z2) ∪ ... P(zN)

is a failure in human communication not a disagreement about what LLMs are or aren't.

But how were various combinations of popular programming languages, operating systems and hardware platforms not effectively f(x) -> P(y | z1 | z2 | ... z3)? Suppose you were quick on the take and were writing in Unix and C in the early 80s and found yourself porting your program from a PDP-something to an 8088 PC, or to a 68k Mac, dealing with DOS extenders, printer drivers, different versions of C (remember K&R style?) or C++? Remember MFC? The evolution of the STL?

LLMs are similar to that maelstrom, just on a faster timescale.

For sure the problem isn't that clear-cut, for the siren's call of AI coding is to induce a system out of prompts with ambiguous semantics. It's hardly surprisingly you get unpredictable outcomes when giving ambiguous commands to human collaborators, and that in the case of LLMs they resolve ambiguity with probabilistic approximation.

  - contributing individually
  - contributing as a tech lead
  - contributing as a technical manager
  - leaving the occupation to open a vanity business, such as a gastropub or horse shoeing service

C and Python have a bunch of different compilers, so you don't if you take the same code, the f' output can be different. There's determinism within the same compiler. Add in different architectures, and the machine code output definitely is more varied than presented.

But that's still a manageable; then what if you add in all the dependencies, well you get a more florid complexity.

So really, it's a shitty abstraction rather than an inaccurate analogy. If you lined them up in levels, there could be some universe where they are a valid abstraction. But it's not the current universe, because we know the models function on non-determinism.

I'd posit if there was a 'turtles all the way down' abstraction for the LLM, it's simply coming from the other end, the one where human mind might start entering the picture.