Prevent cognitive debt by manually retyping LLM-generated code
38 points by abhin4v
38 points by abhin4v
Hey, former CS teacher here. In addition to being somewhere in the middle for speed, you are also likely somewhere in the middle for understanding. The actual benefits of writing it out versus manifesting it yourself are quite diminished in my experience with students doing the same. Generally, I observed students having more success by reading the example, understanding it, then replicating it independently. This is still at the loss of building intuition for planning out your own solution, but if you're going to use these tools regardless, that might also help.
That all being said, this excerpt gives me a modicum of hope:
If I don't understand an API or algorithm, I can stop to look it up, or just ask the LLM to explain it.
While I think this exercises a different brain muscle than the original programming practice, it indicates critical engagement that will still help you learn from the experience. Nevertheless, you will eventually fall into classical human traps (normalisation of deviance, alert fatigue, etc.) that will reduce your efficacy in this eventually.
(Used to such posts being submitted by authors. Feel free to replace 2nd person pronouns with 3rd :p)
"Cognitive debt" is real. As someone who wants to understand what LLMs can do, I have been putting each new generation through its paces for a few years now. (Mostly on a backlog of minor utility projects that I want to use but don't especially feel motivated to write. I have cooler things to write myself.) And what I noticed was a clear generational picture:
Now, personally, I'm not going to start retyping LLM code. I can type code really fast with modern IDE tooling. And if you give me a few-lines-at-a-time completion model like Zed's Zeta2, I can go faster still. (Zeta2 will autocomplete a few lines of boilerplate but only if it's really predictable.) So if I'm going to type the code at all, I'll write it myself. My main personal use case for LLMs is "that code is basically boring and predictable and I don't wanna type it all out."
But I agree that the trend line around cognitive debt is pretty worrisome, and that the incentives all point towards taking the human further out of the loop. This is a WALL-E future we're looking at, folks. And I don't blame programmers for being horrified by it. I certainly am.
But the Fall 2025/Sonnet 4.5 class models were really interesting, in terms of cognitive debt. You know that saying that "the best way to really learn something is to teach it to someone else?" A Sonnet 4.5-class LLM was sort of an eternal student that never actually learned anything.
For the local LLM crowd, the people who want MIT-licensed weights and a whole stack they control from end-to-end, here's how I'd classify the top local models as of this week:
I am honestly struggling to care about whatever Anthropic and OpenAI are up to this week. Sure, they're the only shop in town if I want the "full WALL-E experience", complete with float chairs and giant sodas, or if I want entire custom Android apps built while I'm in the kitchen. But the mid-tier MIT-licensed weights are good enough for a wide range of work. Or maybe they're even already too good if you're worried about cognitive debt.
I also think we're reaching the point where ideologically-driven free software projects that do allow AI should be seriously thinking about MIT-licensed weights and free software harnesses. Outsourcing everything to Anthropic or ChatGPT is starting to feel far too much like outsourcing everything to Microsoft in the 90s.
How are you running and using local models? I'm familiar with running models in Llama.cpp, but for coding I've only ever tried Claude (which I cancelled when they partnered with Elon)
OK, everything you never wanted to know about local LLMs, current as of this weekend.
Open harnesses. I normally use llama.cpp's llama-server, plus the Pi agent and a custom Linux sandbox tool based on bwrap and pasta. Pi is a little bit unusual: It starts out with only 4 tools and a 1k token system prompt, but it's solid. And the tiny system prompt actually makes modern models benchmark better than 10k or 20k system prompts. Then, if you want more features, you can either install various Pi extensions, or just ask it to write its own extensions. This works great for people who want "just the core" of Claude Code, plus maybe one or two specific features. It won't work for people who want all the stuff in Claude Code. Open Code comes with more "batteries included". But it also has a much bigger system prompt, which slightly degrades model performance on some benchmarks. Still, it might be a good choice for some people!
Model choice & hardware. The two sweet spots are Qwen3.6 27B and DeepSeek V4 Flash 0731. (Qwen3.6 35B A3B is sort of usable as a coding agent, but the 27B is really where it gets useful.) For Qwen, you need a bare minimum of 24GB of VRAM. Configure it with a 4-bit quant from Unsloth, an 8-bit K/V cache, no mmproj (disabling vision) and 128k context, and it will just fit with slightly degraded quality. 32GB of VRAM would be better, and 48GB would be luxurious. Consider an AI PRO R9700 (32GB) or a used RTX 3090 (24GB), or a frankenbox with two smaller cards (but that quickly gets tricky). Price: US$1,200 to $1,700, depending on what hardware prices are this week, in your country. Just toss the GPU into a gaming PC or Linux server with an adequate PSU and decent cooling.
For DeepSeek V4 Flash 0731, you've got a bunch of options to run it locally, and most of the simple ones cost about as much as a used car in the current brutal RAM market. :-( See antirez's DwarfStar for Mac Studios (or MacBooks with 128GB), or llama-server, or vllm. The full sized model uses 4/8-bit weights, but the 3-bit quants are solid, and some people run the 2-bit quants in 96GB of fast system RAM. This is all literally improving daily right now. It's all very "Linux in 1995."
See above for what each option gets you: The Qwen is sort of like Sonnet 4.5 (a good minion), and the DeepSeek is sort of like Opus 4.5 (a pair programmer that's smart enough to tempt you into going hands-off when you shouldn't).
Renting servers/buying tokens. You can also host on a cloud server with one or two RTX Pro 6000 Blackwell cards, which are available from many vendors. Or you can buy API tokens from one of the providers on Open Router. The API is actually a decent route: A heavy day of coding might cost $0.50. And even if you don't control the server, at least you theoretically could move to an AWS instance or an expensive workstation under your desk whenever you wanted. Or just switch to one of 20 other vendors. Yay commodities.
To get started, the easy way. Stick $10 on an Open Router account, try DeepSeek V4 Flash 0731, and set up either Pi or OpenCode. Then ask it to write some utility you're never going to get around to. If you are satisfied by the experience, then you can start lamenting VRAM prices and desperately trying out quants like the rest of us, lol.
How I feel about all this. It's complicated. Yes, AI is making a mess of programming as a profession, and going local doesn't entirely fix this. But at the same time, the whole space is fun in the same slightly masochistic way that early Linux was fun. And honestly, if a computer is going to steal my job, I'd at least like the option of owning the computer, you know? Because leasing it all from Anthropic at steep prices under constantly changing rules is frankly ick.
But as I've mentioned before, I think local is ultimately the way to go if you're going to mix free software and AI. I even think there's an interesting free software argument for coding agents: We've always wanted to give users the freedom to control their machines. But in practice, few users had the skill or the time. For all their faults, LLMs do allow people with very minimal programming skills to build funky custom stuff, stuff that they control, without spyware. And if they could run the model on the machine they're customizing, that's at least a more interesting vision than what OpenAI and Anthropic are selling. (At least until you get into Mythos class or smarter models, which I personally don't think anyone should be building for lots of reasons.)
Thank you for the advice! My wallet is a bit too empty for a new GPU, but I'll give OpenRouter Qwen and DeepSeek a try.
This is not exactly the same but a lot of people, rightly I think, express concern that they will lose all their skills through lack of exercise with LLM-assistance.
I rarely see people note that skill re-acquisition is typically much more efficient than original learning. I'm not saying that I'm not concerned about the erosion of my skills but that this is a mitigating factor.
As a former competitive cyclist, even when I am basically completely untrained I notice that my unconditioned baseline is usually above my peak before I learned how to train for competition.
I think something similar is in play with computering, at least for me.
You never forget how to ride a bike.
Yeah, my metaphor breaks down if you notice I was comparing programming to conditioning rather than "riding a bike" which I think usually means the basic interaction of proprioception, your inner ear and vestibular system, and the gyroscopic stability that makes biking feel like magic.
But I mean conditioning. Conditioning is the "use it or lose it" of cycling and feels much more similar to that of programming skills, at least for me. I left Rails for 8 years and was very embarrassed to rediscover that uh 0 is truthy or something.
This to me feels like a slightly more awkward way of switching to "Manual" mode in Claude Code (which, for those who are delightfully unaware of these machines, pauses output at every edit made by the LLM, shows you the diff, and allows you to accept, abort, or ask for something else).
My personal approach (at work, because I made a point not to use LLMs at home) which I feel achieves the same purpose as OP, but without (what at least to me appears to be) hassle is to strive to use the machine mostly just ask questions and write the code myself. And, in the exceptions where if I do want it to write code, I always use Manual or Plan mode, not only because manual gives you a chance to understand what's going on while auto-edit will make anyone's eyes glaze over, but also because it gives you zero opportunity to steer the model in a different direction, if you realize it's going in a completely wrong way.
I feel this has made me more productive than before, because my baseline remains the same, but if I get stuck, I generally don't have to pester my colleagues as much as before and before I present my work to them, I have a reasonably good filter that lets me iron out the obvious issues that would have caused multiple commit-rereview cycles before.
Interesting approach. A piece to comment on:
Using LLMs this way allows me to work faster than not using LLMs at all, but I'm still slower than those who are willing to allow the machine to think for them. Instead of being 10x faster, I'm probably only 2x faster. But what I lose out on in terms of speed, I gain in terms of a deeper understanding of my code.
Have you thought about writing all the code by hand and mainly chatting with an LLM about the design, possible edge cases and API/library examples for what you are not familiar with? To be honest, that is the sweet spot that has been working wonderfully for me:
Using something akin to it, treating LLMs as thinking assistants, I find myself stuck much less often, which probably gives me like 2 - 3x productivity boost (depending on the task), but still retaining the exact same - deeper even, I would argue - understanding of the things I am implementing and working with :) It is pretty interesting and fun to be honest as well!
I think there are other approaches we can use by following people working in psychology and neurosciences: I've posted this article from Dr. Cat Hicks which I think is extremely relevant, as well as the articles she links. In general, she's really pushed for people to interact with the LLMs to build understanding instead of taking the code as is. We'll need to include that in our practices in a way or another.
This paper How AI Impacts Skill Formation ¶Adopting AI Advice: Pasting vs Manual Code Copying (p.16) states that there was no difference in skill formation, measured by quizz score between the groups that copy-pasted and the groups that re-typed the generated code.
I used chtgpt in a similar way. Asked it to write pythonlike pseudo code and I write it in C. Advantage is you can use free version for this. 😀
That's an interesting idea, but from my perspective I think I still get as much value in having AI agents autonomously sumbit PRs, and then review them rigorously, just as I would do to PRs from a junior human peer.
I treat LLM code as code Ive been asked to review.
But how thoroughly do you review code sent over for review? LLM code bears much deeper review because the level of thinking isn’t comprehensive around edge cases (unless you already made it make a full suite) and it really doesn’t have any taste, and frankly unlike a human there’s no reason not criticize its designs on the basis of taste and get something more coherent.
How thoroughly varies because I’m human, but I don’t distinguish because a human is signing the commits.
Work policy is to make small commits and that helps.
It has been an issue with code authors responding to reviews with AI responses. It’s a bit of the culture we have to sort out.
So far for code that I’m showing to other people as part of a larger project, I’ve been doing deep review, challenging the LLM and insisting that it write tests that convince me the code is correct. It takes a while but I’d say that the changes I’m making are more ambitious than if I weren’t using a very capable agent.
For code I’ve just been vibecoding…I have almost no idea. I spot check occasionally but if I had to make targeted changes I’d need an LLM to write me a reading guide and really dedicate time to it. In fact I’ve tried to do that before and not found the time to do that. I know what I specced, and I’ve built in much more observability tooling than normal to understand what I’ve actually got.