Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C –> Java != Java –> LLM

observationalhazard.com

Post reply on HN
Print view View original

31–40 of 50 posts

Re: C –> Java != Java –> LLM

#31

Post by Muromec »

Vegenoid wrote: post #20
Muromec wrote: post #13

Earlier quoted context omitted.

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.

> 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 un…

>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.

That sounds awfully similar to... software development.

Re: C –> Java != Java –> LLM

#32

Post by cowl »

seanmcdirmid wrote: post #11
cadamsdotcom wrote: post #3

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 kee…

> 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…

>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.

The difference is that there is an engineer in the middle who can judge if the important information is provided or not as input.

1. for a LLM "the button must be blue" has the same level of importance as "the formula to calculate X is..."

2. failing faster and iterating is good thing if the parameters of failing are clear which is not always the case with vibecoding, especially when done by people with no prior experience in developing. plenty of POCs build with vibecoding have been presented with no aparent failure in their happy path but with disastrous results in edge cases or with disastrous Security etc.

3. where previously, familairity with the codebase and especially the "history of changes" gave you context about why some workarounds were put into place, these are things that are lost to a LLM. Vibecoding a change to an existing system risks removing those "special workarounds" that keep in mind much more than the current context of the specifications or prompt.

Re: C –> Java != Java –> LLM

#33

Post by seanmcdirmid »

dwringer wrote: post #28
seanmcdirmid wrote: post #26

Earlier quoted context omitted.

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…

All I can really say is that doesn't match my experience. If I fix something that it implemented due to a "misunderstanding" then it usually tends to break it again a few messages later. But I would be the first to say the use of these models is extremely subjective.

I think we have very different experiences then. I find multiple prompts with narrow focuses each executed to update the same file work much better than trying to one shot the file. I think you would have a better experience if you used /clear (assuming you are using Gemini CLI), the problem isn't the change in the file, the problem is probably the conversation history instead.

Re: C –> Java != Java –> LLM

#34

Post by Muromec »

krupan wrote: post #25
cess11 wrote: post #18

"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?

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)

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.

Re: C –> Java != Java –> LLM

#35

Post by hu3 »

cadamsdotcom wrote: post #3

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 kee…

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.

Re: C –> Java != Java –> LLM

#36

Post by seanmcdirmid »

cowl wrote: post #32
seanmcdirmid wrote: post #11

Earlier quoted context omitted.

> 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…

>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. The difference is that there is an engineer in the middle who can judge if the important information is provided or not as input. 1. for a LLM "the button must be blue" has the same level of importance as "the formula to calculate X is..." 2. failing faster and iterating is good thi…

> 1. for a LLM "the button must be blue" has the same level of importance as "the formula to calculate X is..."

You can divide those into two prompts though, there is no point for the LLM to work on both features at the same time. This is why iterative is so useful (oh, the button should be blue, ... and later, the formula should be X).

> 2. failing faster and iterating is good thing if the parameters of failing are clear which is not always the case with vibecoding, especially when done by people with no prior experience in developing. plenty of POCs build with vibecoding have been presented with no aparent failure in their happy path but with disastrous results in edge cases or with disastrous Security etc.

This isn't about vibecoding. If you are vibecoding, then you aren't developing software, you are just wishing for good code from vague descriptions that you don't plan to iterate on.

> 3. where previously, familairity with the codebase and especially the "history of changes" gave you context about why some workarounds were put into place, these are things that are lost to a LLM. Vibecoding a change to an existing system risks removing those "special workarounds" that keep in mind much more than the current context of the specifications or prompt.

LLMs can read and write change logs just as well as humans can (LLMs need change logs to do updates, you can't just give it a changed dependency and expect the LLM to pick up on the change, it isn't a code generator). Actually, this is my current project, since a Dev AI pipeline needs to read and write change logs to be effective (when something changes, you can't just transmit the changed artifact, you need to transmit a summary of the change as well). And again, this is serious software engineering, not vibecoding. If you are vibecoding, I have no advice to give you.

Re: C –> Java != Java –> LLM

#37

Post by panny »

>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.

Re: C –> Java != Java –> LLM

#38

Post by acedTrex »

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.

Re: C –> Java != Java –> LLM

#39

Post by WoodenChair »

panny wrote: post #37

>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 databas…

> 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).

Re: C –> Java != Java –> LLM

#40

Post by est31 »

Muromec wrote: post #31
Vegenoid wrote: post #20

Earlier quoted context omitted.

> 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 un…

>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. That sounds awfully similar to... software development.

Yeah many programming languages have been advertised to fulfil precisely this goal, that people can program computers via natural language instead of having to think hard and too much about details.

Usually programming languages intend to make editing as easy as possible, but also understanding what the program does, as well as reasoning about performance, with different languages putting different emphasis on the various aspects.

Post reply on HN