on the contrary, reviewing LLM code and human code is very different. LLMs don't learn. if a human makes a mistake i can teach them to avoid that mistake in the future. if an LLM makes a mistake, all i can do is fix it over and over again. the dynamics are fundamentally different. some people may prefer to work with a machine, but i don't, i prefer to work with humans.

for me this is similar to the difference of using FOSS vs closed source software. if there is a problem on my linux machine, i can potentially fix it, on windows or mac i just can't.

both closed source software and working with LLMs make me feel helpless. whereas using FOSS or working with humans is empowering.

i get that not everyone feels that way, and that's fine. for my part i'll just stay away from LLM generated code.

In theory, vibe coding and understanding don't have to be mutually exclusive, but in practice, I think that the people who have the discipline to actually maintain their understanding of a codebase are few. I've code reviewed things from people who claim they are reviewing what comes out of the LLM carefully, and talked to them about the code, and while they think they understand the code, they simply don't, which becomes abundantly clear when I try to explain the problems I find in the code.

Choosing not to know what stdio.h means is willful ignorance, an LLM has little to do with said chosen ignorance, that is a choice because "hey it works on machine!" and when I pushed it, nobody seemed to mind.

What a time to be alive. Actively choosing to rebuke knowledge because "what the fuck does it matter anyways"

no. it was the first question I asked and was given a satisfactory explanation (along the lines of, "this adds things to your program that help it write text to the screen.")

Funny you should mention hello world. Kernighan and Ritchie presented it in TCPL as a little anatomical diagram of close to the smallest possible functional C program with the different parts labelled. The first line is labelled "include information about the standard library". What this means in detail is explained in that chapter. Furthermore, if you were compiling on a Unix system, stdio.h was readily available as /usr/include/stdio.h. Curious people could open it up using more or vi and see what was inside. There was no shortage of curious people back then.

The process of "going through the motions" of writing and compiling a program without even a small understanding of what it all meant was a later innovation, perhaps done as a classroom exercise in an introductory CS course for impatient freshmen or similar.

When you first learn anything you don't really understand it - that takes longer. When you learn woodworking you won't know why you have to hold the saw a certain way. When you learn chemistry you don't know how we know atoms exist. You start by doing the fun stuff and fill in the gaps later.

After vibe coding: I can't understand how I could deal with coding before.