logoalt Hacker News

layer8today at 4:36 PM3 repliesview on HN

> What's the real difference in that gray area? I'm not sure. I think it hinges on something that has to do with making versus asking to be made, even if that line isn't particularly clear.

For me the difference is in the extent that I can reason about how changes in the input affect the observable behavior of the output. When the executable the compiler outputs doesn’t behave in the way I intended, then in 99.99% of cases this is completely on me, and, importantly, I could have predicted it from the source code. Conversely, I can analyze any such misbehavior by reasoning on the source code. This doesn’t hold to any remotely comparable extent for the relation between vibecoded programs and the prompts used to create them.


Replies

dmriverstoday at 5:54 PM

But does this mean that a 99.99% reliable LLM would turn us back into the mode of us building it again? I would not say so.

I think for tasks that are about decisions, having the LLM make decisions is what makes it feel like the LLM did something for me.

Consider mowing the lawn. Imagine I had a lawnmower robot that does the mowing all on its own. Despite perfect accuracy, I didn't mow the lawn; it did. If I sit on that lawnmower the whole time and start driving it instead of letting it go on its own, then I mowed the lawn. Even if I stand there and control it with a joystick, I still mowed the lawn. Ownership comes from the decisions about where to mow.

show 1 reply
ike_atoday at 4:49 PM

This seems like a very clear way of thinking about it.

In making something, you develop a tangible understanding of and opinions for how and why your creation is how it is.

I have a lot of vibecoded projects. I feel "ownership" in varying degrees proportional to the amount of care and depth I put into them.

skydhashtoday at 5:05 PM

Sounds very much like agency over the process versus agency over the outcome.

Some are ok with deciding if and when the process should be started and whether the outcome is good and bad. But often they lack the judgment to truly decide what is good and what is bad. They trust the makers to provide equally good options in terms of lower concerns (that matters to the makers) and only make the judgment according to some other concerns.

The main difference when using a compiler is that the compiler will (99.999...%) produce correct binary code for my programs and will fail loudly if it cannot. But the compiler is not concerned about correctness of the algorithm written in the programming language. Responsibilities are clearly outlined and the compiler does the job perfectly, while I try to do mine as well. So when I do a good job, I don't have to worry about the compiler part and I can assume the result will be good as well.

LLM usage has no such clear line. Assuming the user can judge whether the outcome is good or bad according to the prompt, the LLM tool is not reliable enough to produce a good result for everything that was not specified in the prompt. Which is different when collaborating with humans. If you say to a professional artist "I want a batman drawing", you needn't check for missing toes and the numbers of arms.

show 1 reply