The two don’t have to be mutually exclusive. You can let the agent code and you review it, or vice versa. No different from being a team lead where you don’t write all the code, or even review each and every line of code, but you have a very firm grasp of the code base.
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.
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"
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.
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.")
The two don’t have to be mutually exclusive. You can let the agent code and you review it, or vice versa. No different from being a team lead where you don’t write all the code, or even review each and every line of code, but you have a very firm grasp of the code base.
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.
What do you do to learn new programming construct? What did you do to learn programming - didn't you write
while having no idea what 'stdio.h' is?
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"
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.
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.")
That's not even remotely satisfactory if we're talking about understanding what we're doing
-- me, two months ago
After vibe coding: I can't understand how I could deal with coding before.
[dead]