| ▲ | dimtion 6 hours ago |
| I'm not sure why people struggle with the fact that an abstraction can be built on top of a non-deterministic and stochastic system. Many such abstractions already exist in the world we live. 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. |
|
| ▲ | distalx 6 hours ago | parent | next [-] |
| A transmission error has a strictly contained, predictable blast radius. If a packet drops, the system knows exactly how to handle it: it throws a timeout, drops a connection, or asks for a retry. The worst-case scenario is known. A reasoning error has an infinite, unpredictable blast radius. When an LLM hallucinates, it doesn't fail safely but it writes perfectly compiling code that does the wrong thing. That "wrong thing" might just render a button incorrectly, or it might silently delete your production database, or open a security backdoor. You can build reliable abstractions over failures that are predictable and contained. You cannot abstract away unpredictable destruction. |
| |
| ▲ | DiscourseFan an hour ago | parent | next [-] | | Very few people are even beginning to understand the constraints of these systems, and none of them have yet been elevated to high enough positions of prominence to rise above the noise of all the hype. Give us some time man, jeez | |
| ▲ | harrall 2 hours ago | parent | prev | next [-] | | A transmission error does not have a strictly contained blast radius. A bad packet could tell a flying probe to fire all thrusters on and deplete its fuel in 15 minutes. What makes a transmission error controlled is all the protection mechanisms on top of it. An LLM cannot delete a production database unless you give it access to do it. My hot take is that many people are naturally more comfortable with deterministic systems that have clearly analyzable outcomes. Software engineering has historically primarily been oriented around deterministic systems and it has attracted that type of thinker. But many of us, myself included, prefer chaotic systems where you can’t fully nail down every cause and effect. The challenge of building a prediction model on top of chaos is exhilarating. I really don’t find many people like me in SWE as in, say, the graphics design department. To me, that’s the underlying threat here — LLMs are rewriting a field that has previously self selected a certain type of person and this, quite understandably, rubs them the wrong way. | | |
| ▲ | c-linkage 2 hours ago | parent | next [-] | | I don't need to be able to write proofs about my maths using logic and determinism. If the answer comes out in a way that I like then it has to be correct! | | |
| ▲ | dpark 2 hours ago | parent [-] | | This is vapid condescension. The comment you replied to made no statements about math or proofs. They made a statement about working in systems of non determinism effectively. Your statement seems to imply that this is dumb, as if working in a world of full determinism is an option. | | |
| ▲ | panarky 2 hours ago | parent | next [-] | | Thank you for "vapid condescension". I've wanted a term for this for decades! | |
| ▲ | 2 hours ago | parent | prev [-] | | [deleted] |
|
| |
| ▲ | aeon_ai 2 hours ago | parent | prev [-] | | Insightful. Feels like this maps to the J/P of Myers Briggs |
| |
| ▲ | yunwal 5 hours ago | parent | prev | next [-] | | > A reasoning error has an infinite, unpredictable blast radius. Says who? It’s quite easy to limit the blast radius of a reasoning error. | | |
| ▲ | distalx 4 hours ago | parent | next [-] | | In 2024, a Chevy dealership deployed an AI chatbot that confidently agreed to sell a customer a 2024 Chevy Tahoe for $1. It executed a catastrophic business failure simply because it didn't know the logic was wrong. Sure, you can patch that specific case with guardrails, but how many unpredictable edge cases are you going to cover? It only takes a user with a bit of ingenuity to circumvent them. There are already several examples of AI agents getting stuck in infinite loops, burning through massive API bills while achieving absolutely nothing. You can contain a system failure, but you cannot contain a logic failure if the system doesn't know the logic is wrong. | | |
| ▲ | pear01 2 hours ago | parent [-] | | This would be more convincing if a single car had been exchanged for $1. It didn't happen. Seems the bug was "contained". Sort of undermines your point re "catastrophic business failure" don't you think? |
| |
| ▲ | amazingamazing 5 hours ago | parent | prev [-] | | How so? Suppose you had: Math()
Add()
Subtract() Program()
Math(“calculate rate”) This is intentionally written vaguely. How do you limit that these implementations ensure Program() runs and does the right thing when there is no guarantee Math() or its components are correct? Normally you could use a typed programming language, unit tests, etc, but if LLM is the ultimate abstraction programs will be written line above. At some point traditional software engineering principles will need to apply. |
| |
| ▲ | td2 5 hours ago | parent | prev [-] | | I mean if your talking about packets, your already one abstraction over the real data Transmission, in wich is noisy. So bits can randomly flip, noise could be interpreted as bits, and bits could get lost.
A much larger blast radius | | |
|
|
| ▲ | zadikian 5 hours ago | parent | prev | next [-] |
| I'm fine with that. The part that makes it not really an abstraction is, you still deliver code in the end. It'd be different if your deliverable were prompt+conversation, and the code were merely an intermediate build artifact. Usually people throw away the convo. Some have tried making markdown files the deliverable instead, so far that doesn't really work. It makes even less sense when people compare an LLM to a compiler. Imagine making a pull request that's just adding a binary because you threw the source code away. |
| |
| ▲ | mpyne 5 hours ago | parent | next [-] | | The whole field of reproducible builds is only a field because compilers also have had trouble historically of producing binary artifacts with guaranteed provenance and binary compatibility even when built from the same source codes. If I assign a bug fix ticket to a human developer on my team, I won't be able to precisely replicate how they go about solving the bug but for many bugs I can at least be assured that the bug will get solved, and that I understand the basic approach the assigned dev would use to troubleshoot and resolve the ticket. This is an organizational abstraction but it's an abstraction just the same, leaky as it is. | | |
| ▲ | kibwen 4 hours ago | parent | next [-] | | > The whole field of reproducible builds is only a field because compilers also have had trouble No, this is not comparable. The reason reproducible builds are tricky is not because compilers are inherently prone to randomness, it's because binaries often bake-in things like timestamps and the exact pathnames of the system used to produce the build. People need to stop comparing LLMs to compilers, it's an embarrassingly poor analogy. | | |
| ▲ | mpyne 3 hours ago | parent [-] | | > The reason reproducible builds are tricky is not because compilers are inherently prone to randomness And neither are LLMs. Having their output employ randomness by default is a choice, not a requirement, just like things like embedding timestamps into builds is a choice that can be unwound if you want the build to be reproducible. > People need to stop comparing LLMs to compilers, it's an embarrassingly poor analogy. They are certainly different things, but if you are going to criticize LLMs it would be better if you understood them. | | |
| ▲ | jmuguy 2 hours ago | parent | next [-] | | Are you arguing that the output of an LLM isn’t random? | | |
| ▲ | mpyne 2 hours ago | parent [-] | | It is random if you select it to be (temperature != 0, etc.). It is not random if you don't use random sampling in its output generation. It the whole thing were actually stochastic then prompt caching would be impossible because having a cache of what the previous tokens transformed into to speed up future generation would be invalidated by the missing random state. Look at llama.cpp, you can see what samplers are adjustable and if you use samplers that employ randomness you can see what settings disable the random sampling. Or you can employ randomness but fix the seed to get reproducible results. |
| |
| ▲ | 3 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | achierius 2 hours ago | parent | prev [-] | | > Having their output employ randomness by default is a choice, not a requirement This is not really meaningfully true. E.g. batching, heterogeneous inference HW, and even differences in model versions can make a difference in what result you get, and these are hard to solve. | | |
| ▲ | mpyne 2 hours ago | parent [-] | | But again, these are all things that are also true of build systems. GCC 16.1 vs. 15.2 will get you differences. GNU ld vs. gold vs. mold vs. lld will get you differences. Whether you do or do not employ LTO or other whole-program optimization vs. whether you do gets you differences. Have you never debugged a race condition that worked on your machine but didn't work in prod, based only on how things ended up compiled in the final binary? I'm not saying these are identical but there's a lot more similarity than you all seem to understand. And we've made compilers work well enough that a lot of you believe that they give very routine, very deterministic outputs as part of broader build systems even though nothing could be further from the truth, even today. |
|
|
| |
| ▲ | z3c0 4 hours ago | parent | prev [-] | | It's an abstraction for you, not the rest of that developer's team, who have to reproduce the same solution even after said developer has "won the lottery", so-to-speak. inb4: "Don't worry, just use GPT to make the docs" | | |
| ▲ | zadikian 2 hours ago | parent [-] | | If you throw away the code then yeah, but I've never seen anyone do this. |
|
| |
| ▲ | danenania 2 hours ago | parent | prev [-] | | This is a great point. We’re very much in a transitional phase on this, but I personally do see signs in my own work with agents that we are heading toward the main deliverable being a readme/docs. The code is still important, but I could see it becoming something that humans rarely engage with. |
|
|
| ▲ | rock_artist 19 minutes ago | parent | prev | next [-] |
| > I'm not sure why people struggle with the fact that an abstraction can be built on top of a non-deterministic and stochastic system. Many such abstractions already exist in the world we live. It depends on what's the abstraction. Using LLM for coding is 'abstracting' the developer, adding extra layer that can produce code. But it's not abstraction layer of the code itself. |
|
| ▲ | evrydayhustling 6 hours ago | parent | prev | next [-] |
| Besides deeply unpredictable factors (like signal transmission), most users of higher-level abstractions do so without certainty about how the translation will be executed. For example, one of the main selling points of C when I was growing up was that you could write code independent of architecture, and leave the architecture-specific translation to assembly to the compiler! Abstractions often embrace nondeterministic translation because lower level details are unknown at time of expression -- which is the moivation for many LLM queries. |
|
| ▲ | cwyers 33 minutes ago | parent | prev | next [-] |
| If people can figure out how to write RFCs about IP over carrier pigeons for April Fools, they can figure out how to conceive of LLMs as a layer of abstraction beneath a protocol as well. |
|
| ▲ | qazxcvbnmlp 3 hours ago | parent | prev | next [-] |
| Grocery stores are a level of abstraction. Exchange money, get food. If your whole life you had grown food, it might feel a bit strange. Occasionally the low level details leak through ie: this egg came from this farm, theres a shipping issue so onions are more expensive or whatever. I think llm assisted coding is going to work something like this. |
|
| ▲ | yomismoaqui 4 hours ago | parent | prev | next [-] |
| The kicker is when you delegate some work to another team member and discover that humans are also non-deterministic. |
| |
| ▲ | bluefirebrand 3 hours ago | parent [-] | | We can mitigate a lot of the problems with humans being non-deterministic by establishing trust and consequences There are no consequences for a bad output from an LLM and idk about you but I don't trust them |
|
|
| ▲ | faangguyindia 2 hours ago | parent | prev | next [-] |
| Machine itself is built on top of non deterministic world. While your code is executing asteroid from space may hit it and halt execution. |
|
| ▲ | jauntywundrkind 2 hours ago | parent | prev | next [-] |
| People are really really weird about the non-determinism thing. Got someone very adamant that Prompt API shouldn't be a web standard because the output isn't deterministic and according to them that means we can't allow prompts. Such strong correlation between narrow specific demands on how things have to be & posting, in general. I'd really like to see open mindedness & exploratory views be more frequent and have better standing, in general. I do tend to think this is different than a level of abstraction. But it feels like it's trying to hit hard, on a pretty weird narrow point. |
|
| ▲ | avazhi 3 hours ago | parent | prev | next [-] |
| There’s a big difference between a packet being dropped and a packet’s meaning being changed along the way. The latter is better analogised to what LLMs do between receiving inputs and outputs. |
|
| ▲ | dominotw 5 hours ago | parent | prev [-] |
| that would make sense if ai said "fail. i dont know" . Its active deception is what makes it difficult. |