It's delegation then.

We can use different words if you like (and I'm not convinced that delegation isn't colloquially a form of abstraction) but you can't control the world by controlling the categories.

Human developers by their very nature are probabilistic. Probabilistic is NOT deterministic. Which means the manager is never really sure if the developer solved the problem, or if they introduced some bugs, or if their solution is robust and ideal even when it seems to be working.

All of which is beside the point, because soon-ish LLMs are going to develop their own equivalents of experimentation, formalisation of knowledge, and collective memory, and then solutions will become standardised and replicable - likely with a paradoxical combination of a huge loss of complexity and solution spaces that are humanly incomprehensible.

The arguments here are like watching carpenters arguing that a steam engine can't possibly build a table as well as they can.

Which - is you know - true. But that wasn't how industrialisation worked out.

So it's a noisy abstraction. Programmers deal with that all the time. Whenever you bring in an outside library or dependency there's an implicit contract that you don't have to look underneath the abstraction. But it's noisy so sometimes you do.

Colleagues are the same thing. You may abstract business domains and say that something is the job of your colleague, but sometimes that abstraction breaks.

Still good enough to draw boxes and arrows around.

"LLMs, by their very nature are probabilistic."

So are humans and yet people pay other people to write code for them.

> An abstraction is a deterministic, pure function

That must be why we talk about leaky abstractions so much.

They're neither pure functions, nor are they always deterministic. We as a profession have been spoilt by mostly deterministic code (and even then, we had a chunk of probabilistic algorithms, depending on where you worked).

Heck, I've worked with compilers that used simulated annealing for optimization, 2 decades ago.

Yes, it's a sea change for CRUD/SaaS land. But there are plenty of folks outside of that who actually took the "engineering" part of software engineering seriously, and understand just fine how to deal with probabilistic processes and risk management.

> LLMs, by their very nature are probabilistic

I believe that if you can tweak the temperature input (OpenAI recently turned it off in their API, I noticed), an input of 0 should hypothetically result in the same output, given the same input.

> LLMs, by their very nature are probabilistic.

This couldn't be any more wrong. LLMs are 100% deterministic. You just don't observe that feature because you're renting it from some cloud service. Run it on your own hardware with a consistent seed, and it will return the same answer to the same prompt every time.

Ok, let's call it a stochastic transformation over abstraction spaces. It's basically sampling from the set of deterministic transformations given the priors established by the prompt.

Just want to commend you for the perfect way of describing this re. not being an abstraction

agree but does this distinction really make a difference ? I think the OP point is still valid

> LLMs, by their very nature are probabilistic. Probabilistic is NOT deterministic.

Although I'm on the side of getting my hands dirty, I'm not sure if the difference is that different. A modern compiler embeds a considerable degree of probabilistic behaviour.

Local models can be deterministic and that is one of the reasons why they will win out over service based models once the hardware becomes available.

The LLM is not part of the application.

The LLM expands the text of your design into a full application.

The commenter you’re responding to is clear that they are checking the outputs.

This is an excellent reply

with proper testing you can make suer that given A the returned value is B

>LLMs, by their very nature are probabilistic.

So are compilers, but people still successfully use them. Compilers and LLMs can both be made deterministic but for performance reasons it's convenient to give up that guarantee.

> An abstraction is a deterministic, pure function, than when given A always returns B.

That is just not correct. There is no rule that says an abstraction is strictly functional or deterministic.

In fact, the original abstraction was likely language, which is clearly neither.

The cleanest and easiest abstractions to deal with have those properties, but they are not required.

It's still early stages, that is why.

It is not yet good enough or there is not yet sufficient trust. Also there are still resources allocated to checking the code.

I saw a post yesterday showing Brave browser's new tab using 70mb of RAM in the background. I'm very sure there's code there that can be optimized, but who gives a shit. It's splitting hairs and our computers are powerful enough now that it doesn't matter.

Immateriality has abstracted that particular few line codes away.

It is an abstraction.

Just because you end up looking at what the prompt looks like “under the hood” in whichever language it produced the output, doesn’t mean every user does.

Similar as with assembly, you might have not taken a look at it, but there are people that do and could argue the same thing as you.

The lines will be very blurry in the near future.

I like to think of it as a duck-typed abstraction. I have formal specs which guarantee certain things about my software, and the agent has to satisfy those (including performance, etc). Given that, the code the agent generates is essentially fungible in the manner of machine code.

"SwiftUI red circle with a white outline 100px"

``` Circle() .fill(Color.red) .overlay( Circle().stroke(Color.white, lineWidth: 4) ).frame(width: 100, height: 100) ```

Is the mapping 1:1 and completely lossless? Of course not, I'd say the former is most definitely a sort of abstraction of the latter, and one would be being disingenuous to pretend it's not.

> and it never will be

The only thing I’m certain of is that you’re highly overconfident.

I’m sure plenty of assembly gurus said the same of the first compilers.

> because it's not an abstraction

This just seems like a category error. A human is not an abstraction, yet they write code and produce value.

An IDE is a tool not an abstraction, yet they make humans more productive.

When I talk about moving up the levels of abstraction I mean: taking on more abstract/less-concrete tasks.

Instead of “please wire up login for our new prototype” it might be “please make the prototype fully production-ready, figure out what is needed” or even “please ship a new product to meet customer X’s need”.

Would that experience get eroded though? LLMs let me perform experiments (including architecture/system level) quickly, and build stress test/benchmark/etc harnesses quickly to evaluate those experiments, so in the time you can build human intuition with one experiment I've done 10. I build less intuition from each experiment, but I'm building broader intuition, and if I choose a bad experiment it's a small cost, but choosing a bad experiment and performing it manually is brutal.

I would bet a significant amount of money that many LLM users don’t check the output. And as tools improve, this will only increase.

The number of users actually checking the output of a compiler is nonexistent. You just trust it.

LLMs are moving that direction, whether we like it or not

> We're not because you have to still check every outputted code.

To me, that's what makes it an abstraction layer, rather than just a servant or an employee. You have to break your entire architecture into units small enough that you know you can coax the machine to output good code for. The AI can't be trusted as far as you can throw it, but the distance from you to how far you can throw is the abstraction layer.

An employee you can just tell to make it work, they'll kill themselves trying to do it, or be replaced if they don't; eventually something will work, and you'll take all the credit for it. AI is not experimenting, learning and growing, it stays stupid. The longer it thinks, the wronger it thinks. You deserve the credit (and the ridicule) for everything it does that you put your name on.

-----

edit: and this thread seems to think that you don't have to check what your high level abstraction is doing. That's probably why most programs run like crap. You can't expect something you do in e.g. python to do the most algorithmically sensible thing, even if you wrote the algorithm just like the textbook said. It may make weird choices (maybe optimal for the general case, but horrifically bad for yours) that mean that it's not really running your cute algorithm at all, or maybe your cute algorithm is being starved by another thread that you have no idea why it would be dependent on. It may have made correct choices when you started writing, then decided to make wrong choices after a minor patch version change.

To pretend perfection is a necessary condition for abstraction is not even somebody would say directly. Never. All we talk about is leaky abstractions.

Remember when GTA loading times, which (a counterfactual because we'll never know) probably decimated sales, playtime, and at least the marketing of the game, turned out to be because they were scanning some large, unnecessary json array (iirc) hundreds of times a second? That's probably a billion dollar mistake. Just because some function that was being blindly called was not ever reexamined, and because nobody profiled properly (i.e. checked the output.)

You conflated two things. Availability to the world's information did not produce loneliness, etc., that was availability of social networks designed for engagement^Waddiction on that same device that did. You don't need to install FB et all on your phone.

I don’t think this is a critique of llms so much as a general observation that actual deep learning is difficult.

I’ve read plenty of books (thanks, Dickens) where I looked at every word on every page but can recall very little of what they meant. You can look at the results from an llm and say “huh cool, I know that now) and do nothing to assimilate that knowledge, or you can think deeply about it and try to fit it in with everything else you know about the subject. The advantage here is that you can ask follow-up questions if something doesn’t click.

On a more serious note, here in India most millennials/boomers remember taking a Engineering Drawing class in second semester Engineering courses. It would involve using a real drafter, real calculations and making real drawings. Isometric projects and all.

I remember it took me like 4 nights of standing to make Isometric projections of a landing gear strut. I wondered if pursuing an Engineering degree was even worth it. Some of my classmates did quit, as years went by.

These days they just let you use CAD software to make things work, and based on what I hear kids just Copy paste files and are done with the assignments.

I mean we all have these Kids these days talk, but somethings do matter. Making all these tasks easy has allowed lots of people who would have other wise failed in the previous generations pass.

There is now an unemployment and low pay crisis all over India due to so many Engineers passing. Sometimes when I hear the newer generations complain about how hard it is to buy a home, or get a good job. Im inclined to think, perhaps hard things should have been kept hard for a reason.

Let them.

-Your Friend Mel (probably)

It would! I'd be very interested in seeing the shape and outliers. Like, are there some folk who actually see improvements? Or who don't see any brain reprogramming at all? Do different methods of interacting with these systems have the same reprogramming effect? etc etc

> I don't follow; you can read the code that your LLM produces as well.

You can. You can also read the code a compiler produces perfectly well. In fact https://godbolt.org/ is a web site dedicated to programmers do just that. But ... how many programmers do you know who look at the assembler their compiler produces? In fact how many programmers do you know who understand the assembler?

Now lets extrapolate a bit. I've seen people say they've vibe coded a some program, yet they can't program. Did they read the code the LLM produced? Of course not. Did it matter? Apparently not for the program they produced.

Does the fact that they can vide program but not read code alter the types of programs they can produce? Of course it does. There limited to the sort of programs an LLM has seen before. Does that matter? Possibly not if the only programs they write are minor variations of what has been posted onto the internet already.

Now take two people, one who can only vide code, and another who knows how to program and understands computers at a very deep level. Ask yourself, who is going to be paid more? Is it the one who can only write programs that have been seen many times before by an LLM, or is it the one who can produce something truly new and novel?

The distinction is that you cannot make the LLM do the drilling. And the way these tools are designed is to train the user to use the LLM rather than their own brain, so they'll never learn it themselves.

A big problem with the "Just read the code" approach is that reading the code at the level deep enough to truly understand it is at minimum equally time-consuming than writing the code in the first place. (And in practice tends to be significantly worse) Anyone who claims they're reading the LLM's code output properly is on some level lying to them.

Human brains are simply bad at consistently monitoring output like that, especially if the output is consistently "good", especially especially when the errors appear to be "good" output on the surface level. This is universal across all fields and tools.

That's a bit pedantic: lots of python programs will work the same way in major OSs. If they don't, someone will likely try to debug the specific error and fix it. But LLMs frequently hallucinate in non deterministic ways.

Also, it seems like there's little chance for knowledge transfer. If I work with dictionaries in python all the timrle, eventually I'm better prepared to go under the hood and understand their implementation. If I'm prompting a LLM, what's the bridge from prompt engineering to software engineering? Not such direct connection, surely!

Undefined behavior does not violate correctness. Undefined behavior is just wiggle room for compiler engineers to not have to worry so much about certain edge cases.

"Correctness" must always be considered with respect to something else. If we take e.g. the C specification, then yes, there are plenty of compilers that are in almost all ways people will encounter correct according to that spec, UB and all. Yes, there are bugs but they are bugs and they can be fixed. The LLVM project has a very neat tool called Alive2 [1] that can verify optimization passes for correctness.

I think there's a very big gap between the kind of reliability we can expect from a deterministic, verified compiler and the approximating behavior of a probabilistic LLM.

[1]: https://github.com/AliveToolkit/alive2

However, the undefined behaviours are specified and known about (or at least some people know about them). With LLMs, there's no way to know ahead of time that a particular prompt will lead to hallucinations.

[dead]

You're kind of side stepping the issue. The problem is, when it does matter, they won't know how to make things performant.

There has been a growing amount of evidence for years that modern technology is not without it's side effects (mental health issues due to social media use, destruction of attention spans among the youth due to cell phone use, erosion of societal discourse and straight up political manipulation, and now we're seeing impacts to cognitive ability from LLMs).

So .. people in the past were supposedly wrong about the next generation being "screwed", and therefore we all know that makes it completely impossible for any new generation at any point in history to ever be in any way worse or more screwed than previous generations. Because some people in the past were supposedly incorrect with similar assertions.

You can see what people built with LLM 3 years ago and what they build with LLM today and compare the two.

That is a very natural and efficient way to do it, and also more reliable than using your own experience since you are just a single data point with feelings.

You don't have to drive a car to see where cars were 20 years ago, see where cars are today, and say: "it doesn't look like cars will start flying anytime soon".

> you sound like you have a lot of opinions about LLM performance for someone who says that doesn't use them

It's not reasonable to treat only opinions that you agree with as valid.

Some people don't use LLMs because they are familiar with them.

"It can't do 9.9-9.11 or count the number of r's in strawberry!"

lol