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

Prevent cognitive debt by manually retyping LLM-generated code

ankursethi.com

Post reply on HN
Print view View original

391–400 of 479 posts

Re: Prevent cognitive debt by manually retyping LLM-generated code

#391

Post by Anamon »

aucisson_masque wrote: post #374

> might not be the most efficient way to work with an LLM, but I value comprehension over productivity. LLM are becoming so good that they are better than us at understanding code. And it's only going to get worst every year. I think that the job of 'coding' is done, it's dying and will be effectively dead in a decade. You better find ways to make yourself usable around LLM work but not by doing what LLM already do.

LLMs don't understand a damn thing. They can't. They're not built to.

An LLM doesn't "understand" its own slop. It can use that slop as further input for generating more slop on top of it, but at no point of the process does anything like a concept or understanding come in.

Re: Prevent cognitive debt by manually retyping LLM-generated code

#392

Post by safehuss »

sarreph wrote: post #90
f311a wrote: post #31

This does not sound fun. It's better to work on your side projects with manual coding. You will learn more. Retyping things is inefficient for learning. It's like trying to retype calculus solutions — you don't learn from it. Even if there is an explanation of why the code is written in such a way, you did not come up with it, and you don't know alternative solutions. It is a practice for memorizing, not for building…

When I was learning to code at college, by myself (I did a Business degree), I bought a book on iOS development[0]. This book mandated that you type all the examples out line-by-line. I thought the idea was a pretty silly one, but I stuck with it because I didn't know what I was doing and wanted to learn. 14 years later, as a software engineer, I still think about that book and the way I can trace back a lot of my in…

Very much agree with you. My own experience with calculus specifically is that I would attempt a problem or example myself, then review the solutions and if I'm stuck, I would not understand a proof or solution unless I copy out every single line as the lecture/textbook and even add to it.

The act of slowing down to ensure every line makes sense to me is one of the most valuable things for my learning.

Re: Prevent cognitive debt by manually retyping LLM-generated code

#394

Post by tetha »

20k wrote: post #365
bigbuppo wrote: post #332

Also... if your workflow is "think hard, let LLM write it, read what AI wrote, think hard about what AI wrote, re-type what AI wrote, fix what AI wrote"... Where in the heck are the efficiency gains? Couldn't you just drop the LLM part of it and save the company a trillion dollars in tokens?

LLM speedups have always been predicated on not understanding the code they produce as well as if you wrote it yourself. Reviewing even well written code to understand it in depth, has always taken longer than simply writing it yourself - let alone sloppy LLM code that you have to fix People are, in heavy LLM systems, realising that the most valuable commodity is engineers knowing WTF is going on, and that loss of un…

> People are, in heavy LLM systems, realising that the most valuable commodity is engineers knowing WTF is going on, and that loss of understanding of your codebase is the #1 blocker to actually getting things done. Any senior engineer knows this all too well

I've been pushing against this "maximum LLM driven speed" in our infrastructure as well and been working on a middle ground:

We can generate a change to Ansible or terraform code in half or a third of the time, sure. But we don't use this to make three times the changes in the same time frame. We rather use the freed up time to discuss the change, the context and the affected systems with 2-3 engineers maintaining them. And yes, at times this means us three are sitting around half a day discussing and drawing diagrams about our systems.

I'm just happy to work in a company understanding the value of speeding up less than we could in the feature direction, but investing this time in the direction of control and understanding of the infrastructure.

Re: Prevent cognitive debt by manually retyping LLM-generated code

#395

Post by safehuss »

epolanski wrote: post #319
f311a wrote: post #31

This does not sound fun. It's better to work on your side projects with manual coding. You will learn more. Retyping things is inefficient for learning. It's like trying to retype calculus solutions — you don't learn from it. Even if there is an explanation of why the code is written in such a way, you did not come up with it, and you don't know alternative solutions. It is a practice for memorizing, not for building…

Working on the problems yourself and have AI in a reviewer/feedback mode is the most productive way to challenge complex software problems.

As time goes on, I become more and more convinced of this also. Also fits in with how many of us already learn via feedback loops - just now it's an LLM instead of a human giving you that feedback.

Re: Prevent cognitive debt by manually retyping LLM-generated code

#396

Post by big_paps »

As someone who’s been programming for 20 years, I have to say that programming itself often causes a kind of brain rot. I’m very glad that I can now focus on other aspects of software development. It was only with Claude Code that I realized I never actually enjoyed programming—I enjoyed building things. You can live a perfectly mentally healthy life without programming.

Re: Prevent cognitive debt by manually retyping LLM-generated code

#397

Post by kriro »

20k wrote: post #365
bigbuppo wrote: post #332

Also... if your workflow is "think hard, let LLM write it, read what AI wrote, think hard about what AI wrote, re-type what AI wrote, fix what AI wrote"... Where in the heck are the efficiency gains? Couldn't you just drop the LLM part of it and save the company a trillion dollars in tokens?

LLM speedups have always been predicated on not understanding the code they produce as well as if you wrote it yourself. Reviewing even well written code to understand it in depth, has always taken longer than simply writing it yourself - let alone sloppy LLM code that you have to fix People are, in heavy LLM systems, realising that the most valuable commodity is engineers knowing WTF is going on, and that loss of un…

"""People are, in heavy LLM systems, realising that the most valuable commodity is engineers knowing WTF is going on, and that loss of understanding of your codebase is the #1 blocker to actually getting things done."""

Very much this. It is also true for non-LLM code bases. I still remember my first job at a company with a bigger codebase than my typical "university project code base". It was a full fledged ERP system and just learning the lay of the land and understanding what lives where and why took quite a bit of time.

Interestingly, I think LLMs can be used for this "self-onboarding" and codebase-browsing/understanding. I've experimented a bit with treating an LLM as a guide of a bigger codebase it has "ingested" and having dialogues about it. Works reasonably well, I'm curious if there are companies out there that use this approach.

Re: Prevent cognitive debt by manually retyping LLM-generated code

#398

Post by vector_spaces »

locknitpicker wrote: post #389
20k wrote: post #365

Earlier quoted context omitted.

LLM speedups have always been predicated on not understanding the code they produce as well as if you wrote it yourself. Reviewing even well written code to understand it in depth, has always taken longer than simply writing it yourself - let alone sloppy LLM code that you have to fix People are, in heavy LLM systems, realising that the most valuable commodity is engineers knowing WTF is going on, and that loss of un…

> LLM speedups have always been predicated on not understanding the code they produce as well as if you wrote it yourself. Reviewing even well written code to understand it in depth, has always taken longer than simply writing it yourself - let alone sloppy LLM code that you have to fix I don't think this personal opinion holds well when contrasted with reality. The truth of the matter is that in moderately large cod…

I will say that yes, sadly, I have browsed through code written by people, and sadly also have browsed through code written by LLMs. Who do you suppose wrote the code the LLM was trained on? Divinity?

I'm being tongue and cheek, but as someone who uses these things extensively in work and personal projects, I want to point out that it's new or novel that generating lots of plausible code is now vastly cheaper than it once was, so the scales are quite different.

And yes, slop is an apt moniker for something that requires lots of careful prompting and configuration and guardrails (which is extremely sensitive to small changes in these initial conditions in ways that can be fairly nonobvious) to produce something that will in most cases read at least a little bit worse than if a human had written it. And it will still go off the rails sometimes!

To be clear I don't really agree that typing out the code generated by LLMs is a reasonable counterweight, it largely defeats the purpose. I agree that at a certain point you have to treat parts of your code base like a black box and enforce modularity. But this is still nontrivial, especially in more specialized domains with lots of nuance

Re: Prevent cognitive debt by manually retyping LLM-generated code

#399

Post by spacer-dinos »

danielvaughn wrote: post #189
npras1 wrote: post #120

Big no for retyping llm generated code by hand. But a big yes for still typing code by hand, and not leaving it to the llm. Except it has to be the code generated by your brain. That is what will create new neurons and new connections, which is what will keep away the cognitive decline. And the constraint of not having to use llms will enhance creativity. Actually, the constraints llms add to your code are more in nu…

I disagree. Before coding agents really took off, back in like 2022, I was trying to learn how to create grammars in Treesitter. One evening I sat down with ChatGPT and had it generate a grammar for me. But because it was on ChatGPT, I had to manually write everything it spit out. What ended up happening is that I was typing, I'd notice little weird bits here and there, and I'd ask questions about it, explore alterna…

[flagged]

Re: Prevent cognitive debt by manually retyping LLM-generated code

#400

Post by Anamon »

bonoboTP wrote: post #108
petcat wrote: post #51

> manually retyping LLM-generated code This is just a miserable career of "paint-by-number" because people can't be bothered to have a creative thought about their professional work or programming hobbies. Software developers think that they are being clever with these kinds of strategies to "keep their skills sharp", but unfortunately the entire industry knows about this, and especially the upper management who are…

Right, it's just pretending to be able to delay the inevitable. It's like the assembly programmers of the 70s and 80s keeping their assembly-fu sharp. Yes it might come handy, and it's good to have a grasp of the concepts, but most careers have shifted to not needing to use assembly. Yes, I know that better knowledge of the low level would improve performance and efficiency. But people don't work with this any more,…

You mention further down that you're in academia, and with that knowledge this post makes some kind of sense to me. I used to do academic research. Like you, I almost only worked on my own code and nobody else worked on mine. I also knew I wouldn't have to maintain, usually not even expand it, so I worked accordingly.

None if this holds for programming in business, and this is why you keep hearing people saying that the output of coding agents suck. It does! I won't accept the insinuation that people just dismissed it. I use frontier models daily and try to keep up with best practices. Even under the best circumstances, it still sucks, but you learn to apply it only in places where the suckiness matters less and you can mitigate it.

It's been disclaimed so many times that it's a tired trope already, but no, this is in no way comparable to compilers! Compilers relieve you of a tedious layer of deterministic (!) machine translation. It's offloading drudgery and busywork. What agentic coding is offloading is concept and understanding. Not even remotely the same ballpark! One is using a calculator when doing the maths for the structural engineering of a new bridge. Saves time, is more reliable, gives deterministic results based on the inputs of the engineers. The other is having an intern look up some numbers of how it was done for other bridges. It's unreliable, risks missing context, has an unacceptable error rate, nobody knows how to check the numbers because nobody knows how the heck they were jumbled together, and nobody wants to be responsible when the bridge inevitably collapses. How can anyone get the idea to even try to equate the two?

Post reply on HN