26 ms·

C –> Java != Java –> LLM

43 points by WoodenChair 10mo ago

SadWebDeveloper 10mo ago
This is another pointless article about LLM's... vibe coding is the present not the future, the only sad part of all of it is that LLM's is killing something important: code documentation. Every single documentation out there for new libs is AI generated and that is feed again into LLMs with MCP/Skills servers, the age of the RTFM gang is over sigh
- deleted 10mo ago
  [deleted]
cadamsdotcom 10mo ago
The spec rarely has enough detail to deterministically create a product, so current vibecoding is a lottery. So we generate one or many changesets (in series or in parallel) then iterate on one. We force the “chosen one” to be the one true codification of the spec + the other stuff we didn’t write down anywhere. Call it luck driven development. But there’s another way. If we keep starting fresh from the spec, but keep adding detail after detail, regenerating from scratch each time.. and the LLM has enough room in context to handle a detailed spec AND produce output, and the result is reasonably close to deterministic because the LLM makes “reasonable choices” for everything underspecified.. that’s a paradigm shift.
- tjr 10mo ago
  At that level of detail, how far removed are we from “programming”?
  - cadamsdotcom 10mo ago
    Far! But without the need to “program” you can focus on the end user and better understand their needs - which is super exciting.
  - Vegenoid 10mo ago
    Without understanding the level of detail required, which we do not yet know, we cannot say. When I think of English specifications that (generally) aim to be very precise, I think of laws. Laws do not read like plain, common language, because plain common language is bad at being specific. Interpreting and creating laws requires an education on par with that required of an engineer, often greater.
    - Muromec 10mo ago
      Laws being unreadable is largely an Enlish-language problem zo. I have no problem reading them in my native language. Not requiring massive context size of case law makes things easier still. Big part of being a lawyer is having the same context with all the other lawyers and knowing what was already decided and what possible new interpretation is likely to be accepted by everyone else.
      - Vegenoid 10mo ago
        > Big part of being a lawyer is having the same context with all the other lawyers and knowing what was already decided and what possible new interpretation is likely to be accepted by everyone else. And to create software specifications with language, the same thing will need to happen. You’ll need shared terminology and context that the LLM will correctly and consistently interpret, and that other engineers will understand. This means that very specific meanings become attached to certain words and phrases. Without this, you aren’t making precise specifications. To create and interpret these specifications will require learning the language of the specs. It may well still be easier than code - but then it would also be less precise.
        jimbokun 10mo ago
        And this could end up looking more like mathematics notation than English. For the same reason mathematicians opt to use specialized notation to communicate with greater precision than natural language.
        Muromec 10mo ago
- seanmcdirmid 10mo ago
  > The spec rarely has enough detail to deterministically create a product, so current vibecoding is a lottery. How is that different from how it worked without LLMs? The only difference is that we can now get a failing product faster and iterate. > If we keep starting fresh from the spec, but keep adding detail after detail, regenerating from scratch each time.. This sounds like the worst way to use AI. LLMs can work existing code, whether it was generated by an LLM or written by human. It can even work on code that has been edited by a human, there is no good reason to not be iterative when using an LLM to develop code, and plenty of good reasons to be iterative.
  - dizlexic 10mo ago
    >How is that different from how it worked without LLMs? I won't lie and say "That's a great idea" when it isn't.
  - dwringer 10mo ago
    For me it just depends. If the response to my prompt shows the model misunderstood something, then I go back and retry the previous prompt again. Otherwise the "wrong ideas" that it comes up with persist in the context and seem to sabotage all future results. The most of this sort of coding I've done was in Google's AI studio, and I often do have a context that spans dozens of messages, but I always rewind if something goes off-track. Basically any time I'm about to make a difficult request, I clone the entire context/app to a new one so I can roll back [cleanly] whenever necessary.
    - seanmcdirmid 10mo ago
      If you fix something it sticks, the AI won't keep making the same mistake, it won't change the code that already exists if you ask it not to. It actually ONLY works well when you are doing iterative changes and not used as a pure code generator, actually, AI's one-shot performance is kind of crap. A mistake happens, you point it out to the LLM and ask it to update the code and the instructions used to create the code in tandem. Or you just ask it to fix the code once. You add tests, partially generated by the AI and curated by a human, the AI runs the tests and fixes the code if they fail (or fixes the tests).
- emodendroket 10mo ago
  Well, it’s really a return to the old-fashioned role of an analyst coming up with a data dictionary and a detailed spec. But in practice how often did that work as intended?
- mungoman2 10mo ago
  Yes, I believe the paradigm shift will be to not treat the code as particularly valuable, just like binaries today. Instead the value is in the input that can generate the code.
- DelightOne 10mo ago
  In what environment do you run such tests? Do you have a script for it, or do you have a UI that manages the process?
- hu3 10mo ago
  This is interesting. It's like the nix philosophy. When changes are needed, improve the spec and you can nuke the entire thing and start over. something like immutable code development. One major problem is: how do you not break existing data on the database when code changes? Maybe include current database structure in the spec.
chuckledog 10mo ago
> “As an aside, I think there may be an increased reason to use dynamic interpreted languages for the intermediate product. I think it will likely become mainstream in future LLM programming systems to make live changes to a running interpreted program based on prompts.” Curious whether the author is envisioning changing configuration of running code on the fly (which shouldn’t require an interpreted language)? Or whether they are referring to changing behavior on the fly? Assuming the latter, and maybe setting the LLM aspect aside: is there any standard safe programming paradigm that would enable this? I’m aware of Erlang (message passing) and actor pattern systems, but interpreted languages like Python don’t seem to be ideal for these sorts of systems. I could be totally wrong here, just trying to imagine what the author is envisioning.
- aardvark179 10mo ago
  Smalltalk, Lisp, and other image based languages allowed this. I would not recommend it beyond a very restricted idea of patching.
- handoflixue 10mo ago
  I think at some point in the future, you'll be able to reconfigure programs just by talking to your LLM-OS: Want the System Clock to show seconds? Just ask your OS to make the change. Need a calculator app that can do derivatives? Just ask your OS to add that feature. "Configuration" implies a preset, limited number of choices; dynamic languages allow you to rewrite the entire application in real time.
  - 8organicbits 10mo ago
    Maybe I'm missing it, but when my calculator app gets a new derivatives feature, how am I supposed to check that it's implemented correctly? End user one-shot of bug free code seems like a different technology than what LLMs offer.
    - seanw444 10mo ago
      Yeah I don't see how LLMs are ever supposed to be reliable enough for this, but they did say "at some point in the future", which leaves room for another (better) technology.
emodendroket 10mo ago
The analogy to IDE templates seems more compelling.
cess11 10mo ago
"Many have compared the advancements in LLMs for software development to the improvements in abstraction that came with better programming languages." Where can I see examples of this?
- krupan 10mo ago
  Tons of people throw this argument out on social media. "You keep using assembly while I go up an abstraction layer by using AI." I can only assume people saying that don't even know what assembly is. Actually, as I typed that out I remembered seeing one comment where someone said "hexcode" instead of assembly (lol)
  - Muromec 10mo ago
    You never know. Writing machine code in hex directly into memory of the running process is totally a thing and people exposed to this kind of fun long enough just know.
- layer8 10mo ago
  Comments comparing LLMs to just another level on the abstraction ladder are fairly commonplace: https://news.ycombinator.com/item?id=46439753 https://news.ycombinator.com/item?id=46439753 https://news.ycombinator.com/item?id=46369114 https://news.ycombinator.com/item?id=46369114 https://news.ycombinator.com/item?id=46366864 https://news.ycombinator.com/item?id=46366864 Juts the first three I found via hn.algolia.com.
panny 10mo ago
>The intermediate product of LLMs is still the Java or C or Rust or Python that came before them. English is not the intermediate product, as much as some may say it is. You don’t go prompt->binary. You still go prompt->source code->changes to source code from hand editing or further prompts->binary. It’s a distinction that matters. Funny enough, that wasn't the case for me recently. I was working with an old database with no FKs and naturally, rows that pointed to nowhere. I was letting search.brave.com tell me what delete statement I needed to clean up the data given an alter table statement to create an FK. It was just magically giving me the correct delete statements, but then I had a few hundred to do. So I asked it to give me a small program that could do the same thing. It could do the job for me, but it could not write the program to do the job. After about 30 minutes of futzing with prompts, it was clearly stuck trying to create the proper regex and I just went back to pasting alter tables and getting deletes back until the job was done. There was no intermediate product. The LLM was the product there.
- WoodenChair 10mo ago
  > After about 30 minutes of futzing with prompts, it was clearly stuck trying to create the proper regex and I just went back to pasting alter tables and getting deletes back until the job was done. If you're copying and pasting SQL statements, then SQL statements are the intermediate product. The fact that you didn't carefully review them and just ran them immediately is no different than an LLM producing Java source code that you shipped to the user without reviewing because it worked correctly in your limited testing. There's still an intermediate product that should have gone through the same software development robustness process that all source code should go through, you just didn't care to do it (and maybe rightly so if it's not super important).
  - panny 10mo ago
    There's no reason to be assmad. I know how to produce the sql statements in question. Being able to give the AI an example of what I wanted was part of the process. But doing hundreds of them is prone to typos. And cranking them out by hand is just slower. Especially when there are compound keys. Giving it to the AI just made the process faster. But the AI could not, absolutely not, generate a program that could do what the AI was doing. Which would be really nice, because I'm probably going to go back through those hundreds of statements again in the future. The database is evolving, and my task is to migrate it to a whole new one. I would really rather have it give me a program. But it could NOT do that.
acedTrex 10mo ago
Good lord thank you, the comparisons to other "abstraction changes" have made me so mad. You are not changing the abstraction, you are generating it in a different way. That is a hugely different idea. Until the ONLY thing you look at for a long lived product is the "english spec" then the analogy is incredibly wrong.
kazinator 10mo ago
Any time someone posts that LLMs are just the next abstraction level to get used to, they instantly reveal themselves to be an impostor. All abstraction layers are predictable and repeatable when used correctly. You specify something in the language of the abstraction, and get a result that is precisely understood by the rules and requirements of the abstraction. Only those who programmed by trial and error before AI do not see a difference. That's because they treated their compilers as mysterious AI, and must massaged their programs into working. In other words, they were already accustomed to a kind of prompt engineering.
- WoodenChair 10mo ago
  Thank you. I think that's a good explanation for much of the phenomena and your insight would have strengthened my post. I think you're probably right about where many of the people who see it that way are coming from. But not all of them...

43 points by WoodenChair 10mo ago

This is another pointless article about LLM's... vibe coding is the present not the future, the only sad part of all of it is that LLM's is killing something important: code documentation. Every single documentation out there for new libs is AI generated and that is feed again into LLMs with MCP/Skills servers, the age of the RTFM gang is over sigh

deleted 10mo ago
[deleted]

cadamsdotcom 10mo ago

The spec rarely has enough detail to deterministically create a product, so current vibecoding is a lottery. So we generate one or many changesets (in series or in parallel) then iterate on one. We force the “chosen one” to be the one true codification of the spec + the other stuff we didn’t write down anywhere. Call it luck driven development. But there’s another way. If we keep starting fresh from the spec, but keep adding detail after detail, regenerating from scratch each time.. and the LLM has enough room in context to handle a detailed spec AND produce output, and the result is reasonably close to deterministic because the LLM makes “reasonable choices” for everything underspecified.. that’s a paradigm shift.

tjr 10mo ago
At that level of detail, how far removed are we from “programming”?
- cadamsdotcom 10mo ago
  Far! But without the need to “program” you can focus on the end user and better understand their needs - which is super exciting.
- Vegenoid 10mo ago
  Without understanding the level of detail required, which we do not yet know, we cannot say. When I think of English specifications that (generally) aim to be very precise, I think of laws. Laws do not read like plain, common language, because plain common language is bad at being specific. Interpreting and creating laws requires an education on par with that required of an engineer, often greater.
  - Muromec 10mo ago
    Laws being unreadable is largely an Enlish-language problem zo. I have no problem reading them in my native language. Not requiring massive context size of case law makes things easier still. Big part of being a lawyer is having the same context with all the other lawyers and knowing what was already decided and what possible new interpretation is likely to be accepted by everyone else.
    - Vegenoid 10mo ago
      > Big part of being a lawyer is having the same context with all the other lawyers and knowing what was already decided and what possible new interpretation is likely to be accepted by everyone else. And to create software specifications with language, the same thing will need to happen. You’ll need shared terminology and context that the LLM will correctly and consistently interpret, and that other engineers will understand. This means that very specific meanings become attached to certain words and phrases. Without this, you aren’t making precise specifications. To create and interpret these specifications will require learning the language of the specs. It may well still be easier than code - but then it would also be less precise.
      - jimbokun 10mo ago
        And this could end up looking more like mathematics notation than English. For the same reason mathematicians opt to use specialized notation to communicate with greater precision than natural language.
      - Muromec 10mo ago
seanmcdirmid 10mo ago
> The spec rarely has enough detail to deterministically create a product, so current vibecoding is a lottery. How is that different from how it worked without LLMs? The only difference is that we can now get a failing product faster and iterate. > If we keep starting fresh from the spec, but keep adding detail after detail, regenerating from scratch each time.. This sounds like the worst way to use AI. LLMs can work existing code, whether it was generated by an LLM or written by human. It can even work on code that has been edited by a human, there is no good reason to not be iterative when using an LLM to develop code, and plenty of good reasons to be iterative.
- dizlexic 10mo ago
  >How is that different from how it worked without LLMs? I won't lie and say "That's a great idea" when it isn't.
- dwringer 10mo ago
  For me it just depends. If the response to my prompt shows the model misunderstood something, then I go back and retry the previous prompt again. Otherwise the "wrong ideas" that it comes up with persist in the context and seem to sabotage all future results. The most of this sort of coding I've done was in Google's AI studio, and I often do have a context that spans dozens of messages, but I always rewind if something goes off-track. Basically any time I'm about to make a difficult request, I clone the entire context/app to a new one so I can roll back [cleanly] whenever necessary.
  - seanmcdirmid 10mo ago
    If you fix something it sticks, the AI won't keep making the same mistake, it won't change the code that already exists if you ask it not to. It actually ONLY works well when you are doing iterative changes and not used as a pure code generator, actually, AI's one-shot performance is kind of crap. A mistake happens, you point it out to the LLM and ask it to update the code and the instructions used to create the code in tandem. Or you just ask it to fix the code once. You add tests, partially generated by the AI and curated by a human, the AI runs the tests and fixes the code if they fail (or fixes the tests).
emodendroket 10mo ago
Well, it’s really a return to the old-fashioned role of an analyst coming up with a data dictionary and a detailed spec. But in practice how often did that work as intended?
mungoman2 10mo ago
Yes, I believe the paradigm shift will be to not treat the code as particularly valuable, just like binaries today. Instead the value is in the input that can generate the code.
DelightOne 10mo ago
In what environment do you run such tests? Do you have a script for it, or do you have a UI that manages the process?
hu3 10mo ago
This is interesting. It's like the nix philosophy. When changes are needed, improve the spec and you can nuke the entire thing and start over. something like immutable code development. One major problem is: how do you not break existing data on the database when code changes? Maybe include current database structure in the spec.

chuckledog 10mo ago

> “As an aside, I think there may be an increased reason to use dynamic interpreted languages for the intermediate product. I think it will likely become mainstream in future LLM programming systems to make live changes to a running interpreted program based on prompts.” Curious whether the author is envisioning changing configuration of running code on the fly (which shouldn’t require an interpreted language)? Or whether they are referring to changing behavior on the fly? Assuming the latter, and maybe setting the LLM aspect aside: is there any standard safe programming paradigm that would enable this? I’m aware of Erlang (message passing) and actor pattern systems, but interpreted languages like Python don’t seem to be ideal for these sorts of systems. I could be totally wrong here, just trying to imagine what the author is envisioning.

aardvark179 10mo ago
Smalltalk, Lisp, and other image based languages allowed this. I would not recommend it beyond a very restricted idea of patching.
handoflixue 10mo ago
I think at some point in the future, you'll be able to reconfigure programs just by talking to your LLM-OS: Want the System Clock to show seconds? Just ask your OS to make the change. Need a calculator app that can do derivatives? Just ask your OS to add that feature. "Configuration" implies a preset, limited number of choices; dynamic languages allow you to rewrite the entire application in real time.
- 8organicbits 10mo ago
  Maybe I'm missing it, but when my calculator app gets a new derivatives feature, how am I supposed to check that it's implemented correctly? End user one-shot of bug free code seems like a different technology than what LLMs offer.
  - seanw444 10mo ago
    Yeah I don't see how LLMs are ever supposed to be reliable enough for this, but they did say "at some point in the future", which leaves room for another (better) technology.

emodendroket 10mo ago

The analogy to IDE templates seems more compelling.

cess11 10mo ago

"Many have compared the advancements in LLMs for software development to the improvements in abstraction that came with better programming languages." Where can I see examples of this?

krupan 10mo ago
Tons of people throw this argument out on social media. "You keep using assembly while I go up an abstraction layer by using AI." I can only assume people saying that don't even know what assembly is. Actually, as I typed that out I remembered seeing one comment where someone said "hexcode" instead of assembly (lol)
- Muromec 10mo ago
  You never know. Writing machine code in hex directly into memory of the running process is totally a thing and people exposed to this kind of fun long enough just know.
layer8 10mo ago
Comments comparing LLMs to just another level on the abstraction ladder are fairly commonplace: https://news.ycombinator.com/item?id=46439753 https://news.ycombinator.com/item?id=46439753 https://news.ycombinator.com/item?id=46369114 https://news.ycombinator.com/item?id=46369114 https://news.ycombinator.com/item?id=46366864 https://news.ycombinator.com/item?id=46366864 Juts the first three I found via hn.algolia.com.

panny 10mo ago

>The intermediate product of LLMs is still the Java or C or Rust or Python that came before them. English is not the intermediate product, as much as some may say it is. You don’t go prompt->binary. You still go prompt->source code->changes to source code from hand editing or further prompts->binary. It’s a distinction that matters. Funny enough, that wasn't the case for me recently. I was working with an old database with no FKs and naturally, rows that pointed to nowhere. I was letting search.brave.com tell me what delete statement I needed to clean up the data given an alter table statement to create an FK. It was just magically giving me the correct delete statements, but then I had a few hundred to do. So I asked it to give me a small program that could do the same thing. It could do the job for me, but it could not write the program to do the job. After about 30 minutes of futzing with prompts, it was clearly stuck trying to create the proper regex and I just went back to pasting alter tables and getting deletes back until the job was done. There was no intermediate product. The LLM was the product there.

WoodenChair 10mo ago
> After about 30 minutes of futzing with prompts, it was clearly stuck trying to create the proper regex and I just went back to pasting alter tables and getting deletes back until the job was done. If you're copying and pasting SQL statements, then SQL statements are the intermediate product. The fact that you didn't carefully review them and just ran them immediately is no different than an LLM producing Java source code that you shipped to the user without reviewing because it worked correctly in your limited testing. There's still an intermediate product that should have gone through the same software development robustness process that all source code should go through, you just didn't care to do it (and maybe rightly so if it's not super important).
- panny 10mo ago
  There's no reason to be assmad. I know how to produce the sql statements in question. Being able to give the AI an example of what I wanted was part of the process. But doing hundreds of them is prone to typos. And cranking them out by hand is just slower. Especially when there are compound keys. Giving it to the AI just made the process faster. But the AI could not, absolutely not, generate a program that could do what the AI was doing. Which would be really nice, because I'm probably going to go back through those hundreds of statements again in the future. The database is evolving, and my task is to migrate it to a whole new one. I would really rather have it give me a program. But it could NOT do that.

acedTrex 10mo ago

Good lord thank you, the comparisons to other "abstraction changes" have made me so mad. You are not changing the abstraction, you are generating it in a different way. That is a hugely different idea. Until the ONLY thing you look at for a long lived product is the "english spec" then the analogy is incredibly wrong.

kazinator 10mo ago

Any time someone posts that LLMs are just the next abstraction level to get used to, they instantly reveal themselves to be an impostor. All abstraction layers are predictable and repeatable when used correctly. You specify something in the language of the abstraction, and get a result that is precisely understood by the rules and requirements of the abstraction. Only those who programmed by trial and error before AI do not see a difference. That's because they treated their compilers as mysterious AI, and must massaged their programs into working. In other words, they were already accustomed to a kind of prompt engineering.

WoodenChair 10mo ago
Thank you. I think that's a good explanation for much of the phenomena and your insight would have strengthened my post. I think you're probably right about where many of the people who see it that way are coming from. But not all of them...