3 ms·

No, we can’t retreat to the “LLMs so dumb” position every time we discuss anything around them. This is not a rebuttal. It is an interesting thing to discuss on

by dpark 6mo ago

No, we can’t retreat to the “LLMs so dumb” position every time we discuss anything around them. This is not a rebuttal. It is an interesting thing to discuss on its own merit, but it’s not relevant here. If a natural language specification is an abstraction over the code implementation, then it is an abstraction whether given to a human or an LLM. The LLM being arguably a bad tool does not change that.

HarHarVeryFunny 6mo ago
So let's take LLMs and AI out of the discussion altogether. The question is then can specifying a computer behavior in (inherently imprecise) natural language be considered as some sort of "program", a higher level abstraction in same sense as a HLL provides a higher level of abstraction to programming in assembler? I would say no, for various reasons: 1) There is a difference between an abstraction and under-specifying your requirements 2) Whatever you want to call it, any descriptive language that is insufficiently precise to unambiguously describe the details that are important to you is not very useful as a way to specify system behavior 3) If you are not only using natural language to describe the desired behavior of a system, but are also assuming that the person (or thing) interpreting the description is bringing their own knowledge and expertise to bear in "fleshing out the details", then you don't have a full specification at all, even an abstract one. What you have in that case is not something analogous to a computer program, but more like business requirements.
- dpark 6mo ago
  I think this is all valid. What I think bears highlighting is that often you don’t need a 100% unambiguous specification. Very often “meets the business requirements” if totally sufficient and plenty of other stuff is either implicit or just doesn’t really matter. If you need to develop an API that you’ll support publicly for 10+ years, yeah. You probably want to be really precise. If you need to code up yet another feature in some CRUD app, it matters a lot less. Sometimes natural language is entirely sufficient to “unambiguously describe the details that are important”.
  - HarHarVeryFunny 6mo ago
    Sure, there are some cases where "business requirements is all you need", and certainly CRUD apps are the poster child for this. However, no/low-code solutions for things like this have existed basically forever, way before AI (I remember "The Last One" from the 1980's that was going to make custom coding obsolete), and yet people still mostly prefer to hand code CRUD apps. It's interesting to guess why this is the case. Is it just because writing code that is 100% boilerplate is so simple that automation has no value, or is it that even in this simplest of cases that there is in fact still some human taste/skill being applied so that the app doesn't just "meet business requirements", but also doesn't suck, and/or maybe seeing as the business wants someone to call and fix it when it inevitably stops working, you may as well have that person write it in the first place? No doubt there are other factors too. I guess the multi-billion dollar question is how much of software development overall consists of CRUD-like "business requirements are all you need" type applications, vs how many need some actual software engineering, and time will tell how many companies end up choosing to use automation tools to write software, vs the CRUD situation where despite this having been possible for a long time, hardly anyone chooses to do so for a myriad of other reasons.

by dpark 6mo ago

HarHarVeryFunny 6mo ago

So let's take LLMs and AI out of the discussion altogether. The question is then can specifying a computer behavior in (inherently imprecise) natural language be considered as some sort of "program", a higher level abstraction in same sense as a HLL provides a higher level of abstraction to programming in assembler? I would say no, for various reasons: 1) There is a difference between an abstraction and under-specifying your requirements 2) Whatever you want to call it, any descriptive language that is insufficiently precise to unambiguously describe the details that are important to you is not very useful as a way to specify system behavior 3) If you are not only using natural language to describe the desired behavior of a system, but are also assuming that the person (or thing) interpreting the description is bringing their own knowledge and expertise to bear in "fleshing out the details", then you don't have a full specification at all, even an abstract one. What you have in that case is not something analogous to a computer program, but more like business requirements.

dpark 6mo ago
I think this is all valid. What I think bears highlighting is that often you don’t need a 100% unambiguous specification. Very often “meets the business requirements” if totally sufficient and plenty of other stuff is either implicit or just doesn’t really matter. If you need to develop an API that you’ll support publicly for 10+ years, yeah. You probably want to be really precise. If you need to code up yet another feature in some CRUD app, it matters a lot less. Sometimes natural language is entirely sufficient to “unambiguously describe the details that are important”.
- HarHarVeryFunny 6mo ago
  Sure, there are some cases where "business requirements is all you need", and certainly CRUD apps are the poster child for this. However, no/low-code solutions for things like this have existed basically forever, way before AI (I remember "The Last One" from the 1980's that was going to make custom coding obsolete), and yet people still mostly prefer to hand code CRUD apps. It's interesting to guess why this is the case. Is it just because writing code that is 100% boilerplate is so simple that automation has no value, or is it that even in this simplest of cases that there is in fact still some human taste/skill being applied so that the app doesn't just "meet business requirements", but also doesn't suck, and/or maybe seeing as the business wants someone to call and fix it when it inevitably stops working, you may as well have that person write it in the first place? No doubt there are other factors too. I guess the multi-billion dollar question is how much of software development overall consists of CRUD-like "business requirements are all you need" type applications, vs how many need some actual software engineering, and time will tell how many companies end up choosing to use automation tools to write software, vs the CRUD situation where despite this having been possible for a long time, hardly anyone chooses to do so for a myriad of other reasons.