[layer8]

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

[dmrivers]

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.

[layer8]

If the outcome is equivalent regardless which choices the LLM made, then these LLM decisions weren’t material for the outcome, and it would be fine for me. If the decisions don’t materially change the result, then it means that I can still reason about the output that will be produced. If, on the other hand, the decisions materially change the output, then this also breaks the ability for the prompter to predict what will be produced.

This is analogous to the compiler example: It generally doesn’t matter which exact variation of machine instructions the compiler chooses to generate from the source code. It doesn’t significantly impact the ability to predict the resulting program’s behavior in detail based on the source code.

This predictability relation is what allows the creator to reason about the creation, to reason about which exact change to apply to the input to effect a precise modification in the output.

In that sense, the robot lawnmower is like a compiler, if it yields the state of lawn that I specified. I largely don’t care if it first moved left or right, the same as I largely don’t care if a compiler translates a multiplication by a power of two with a shift instruction or a multiplication instruction.

However, we use LLMs precisely for their heuristics, for their property to actually make material choices. Therefore LLMs inherently conflict with the ability to reason about which exact input will yield which desired output.

[skydhash]

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.

[ike_a]

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.