Prevent cognitive debt by manually retyping LLM-generated code

I don't remember if I read this advice or just intuited it myself (perhaps after some hard lessons), but it's a programming habit I've kept for as long as I can remember (I started coding in the 90s). If I feel rushed, e.g. someone looking over my shoulder, and I copy+paste something, it always leaves me with a sense of unease. It creates a memory & comprehension hole that sticks out like a sore thumb, even for seemingly simple snippets. You can't really be sure it's simple without stepping through it carefully, and simple can be deceptive because it's usually the interactions and assumptions wrt surrounding code that lead to surprises. Typing out code manually gives you time and space to consider the broader picture.

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?

For me I feel that LLMs have exploded (in a good way) my cognitive capabilities. I'm now the general of an army, rather than playing the role of a soldier. Of course that means that I lose the experience of being the lonely soldier, but it is a no-brainer tradeoff for me.

Anyway, I have to go now so I can push my car to the grocery store (so I don't forget how to walk), me and my giant calves will be back in a few hours.

All meant in good spirit. Keep doing what you're doing, thanks for sharing, and hope people are kind and only give good natured ribbings.

Whatever this approaches, it is not a state of software engineering I find desirable.

Personally, I don't think we will ever be able to reconcile using LLMs and cognitive debt. Even before LLMs we were aware if it: we knew people moving to managerial/PM roles eventually get their coding skills rusted. Well, now we are all in those managerial roles...

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 number than the former. llms code in only the specific ways they've been trained on. So you won't ever come across of other ways.

Off the top of my head.. here's RubyQuiz.com [0] which I came across when I was learning ruby more than a decade ago. Looking at the many user-submitted solutions (you have to download the zip file!) you'll see completely different ways the problems were solved.

Sure, many won't be deemed efficient or standard by today's llm or rubocop checks, but looking at their code.. and retyping them and seeing them work.. was crucial in how I was able to think in Ruby for solving coding problems.

I did the same with Go too, with the "learn go with tests" guide [1].

[0] - http://rubyquiz.com/

[1] - https://quii.gitbook.io/learn-go-with-tests

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 already eliminating these assembly line, JIRA-ticket-taker software jobs en masse.

I also tried where I would print out the code (with color) and then go read it with a red pen. Faster and similar results of forcing me to be able to read it enough to be "an editor" to the code.

And I have done the same for LLM-generated code and text, back in '23 this meant more taking their so-so output and then turning it into my own, but between now and then come up with a number of techniques to improve the AI output to more acceptable out of the gate so more learning than being inspired.

These are good techniques as it causes your own brain to rapidly learn the material, but no matter how good it is I have never met anyone else that does it so the real ponderable is assuming that everyone else doesn't do this and what does that mean?

Exactly as we don't write machine code letting the compiler do that, now and in the near future we won't be writing high level programming language code. We are moving towards working on a higher level of abstraction.

When I ask a frontier model to write a loop 10 different ways in Python and TypeScript and test the performance of each using a 1,000,000 iterations, it isn't creating cognitive debt. For the time being, I'm still racking my brain asking the question, how does garbage collection affect the performance.

I no longer do and blogged my updates for fear of being seen as a luddite:

https://kamens.com/blog/code-with-ai-the-hard-way-update https://kamens.com/blog/code-with-ai-the-hard-way-update-ii

The goal is to maintain the taste, for lack of a better word, that I've developed over decades of programming.

Claude put me on to the concept "Étude", so I've taken to calling it my Étude project.

That approach works well for me, so why would I retype AI-generated code? I wouldn't do that with code written by another developer, and their code can be just as buggy or weird in theory. You could argue that at least the developer knows how it works. That's true - for a week, a month, or a few years if you're lucky. Until he forgets or leaves.

I've been trying to address this by telling LLMs primarily how the code should be structured, rather than only what it should do. Still, any design I hand to an LLM will be underspecified in one way or another (if it were fully specified, it would just be code), and the LLM fills those gaps somehow - which adds to the cognitive debt, slowly but surely.

Retyping LLM-generated code is an interesting solution. You'd certainly end up understanding the generated code better than if you merely reviewed it, but I doubt it produces a mental model as reliable as the one you'd build writing the code yourself. The longer you think, the better your mental model gets - and outsourcing the thinking to an LLM means thinking less.

That said, I've started to wonder whether I'm solving the wrong problem. Should I really insist on an accurate mental model of the code I own? We'd find it strange for a non-engineering manager to try to fully understand every piece of code their reports produce. If that's the right analogy, then as LLMs' agentic capabilities improve, maybe we should stop treating LLMs as tools that boost our own productivity as a software engineer and start treating them as independent agents we manage and steer.

Creating while writing allowed us to build a mental context but in a unproductive way, it never scalled.

I believe we need to move onto a new way of reading codebases that go beyond reading line by line.

I know people have explored representing code in 3D spaces. I don't know the solution. But I believe that is the problem.

A debt implies repayment. But the loss here is not going to be repaid, it's permanent

Perhaps a more appropriate term might be "cognitive deficit" or "cognitive loss"

I tried this, long ago. I just wasn't getting Haskell, so I'd retype my programs from memory and reconstruction. Obvious for music, why not for code?

All these untested opinions? You'd think we were discussing BMWs.

Managers never got to write and internalize every line of code anyway. Arguably their essential skill is producing useful stuff without needing to do so. So is that 'cognitive debt'? When I use an agent to code, I do the same things: I validate the direction, organization, and core decisions, but delegate the details. It's an intentional calculation of risk, managing the scope of future problems if there's a failure of implementation somewhere.

It's a question of where you put the value of cognitive focus. I don't understand 'line by line' how my car's ICE works, even though it will likely impact me at some point, because while I might be able to fix it myself if it breaks, the likely applied solution will be to delegate that work anyway.

You can ask Claude to "sdoc me an annotated code walkthrough of this MR" and it will produce something like this:

https://smalldocs.org/s/Ju9GOmWZ0JXTtzqCVfgt1q#k=6HBrpcCjIu7...

I use this a lot to stay in touch with the code the LLM is producing.

[1] https://smalldocs.org [2] https://github.com/espressoplease/smalldocs

> For your next ticket or feature, engage with your LLM as you normally would to produce a design and implementation plan, but with that plan in hand, make the mechanical edits yourself...You can expect this to improve your knowledge retention compared to merely reading a diff. You want to go slower now so that later you can go at all.

https://www.slater.dev/2026/05/type-your-code/

Most of us read the specs, then raced into the coding phase, hands to IBM mechanical keyboards. One guy took a different approach. He took a legal pad and pencil, and wrote his whole program on paper before he ever approached a terminal. He’d do his own bug checking and syntax checking, instead of having the compiler do it ( compiles took longer in those days, and required JCL ). He avoided the entire compile/wait/read-with-dismay/quickly-try-again loop.

He was one of the top students, of course. And a lot less stressed, as I recall.

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

A better option is to write it yourself first and ask LLMs for better options. They are pretty good at it, especially when you need to optimize hot loops.

At the very beginning stages you might be tempted to trace over an image but this builds a very shallow understanding. Instead you should quickly move onto replicating work you admire by sight. Consider the form, volume and values, conceptualise them in your mind and try to apply them in whatever medium you are using. This helps form your own mental model of the process. Eventually you can start using those techniques on original works.

I'm currently rethinking language learning too in a similar manner. Comprehensible input, shadowing. That sort of thing.

I'm just kind of enjoying the feeling of riding on the swell of a gigantic wave for once instead of feeling like I'm starting from behind it.

This is part of how I learned how to code! Well, sans LLMs. Instead of copypasta-ing code blocks from books, Expert Sexchange and Stack Overflow, I manually retyped everything, looked up what I didn't understand and changed what I could.

Isn't a working program itself the best textbook? It's just a difference in learning methods. Depending on Stack Overflow is also a dependency, and searching for code on GitHub is also a dependency. How much dependency you allow is purely a personal difference, and it varies depending on your own study habits and learning style. Whether your learning method is superior or not likely depends on how your brain works.

People tend to think that the more painful something is, the better it is.

I don't deny that there are talented people who can read the manual and build everything from scratch. But I think that analyzing and rebuilding a working template step by step is also valuable.

I agree with the view that LLMs may cause cognitive decline. But if you go down that path, Socrates already criticized writing for weakening human memory. And how did that turn out? Books became a universal medium for knowledge. Then the internet came along. When Stack Overflow appeared, there was opposition, but it also had explosive adoption. LLMs are just the next step in that sequence.

If there is cognitive decline, I think there's also compensation in other areas. Using LLMs clearly causes some cognitive decline. And I think there are areas that need to be reinforced to compensate.

But having a baseline to work from—modifying already-working code—is genuinely helpful. I don't see what's wrong with using that as a way to learn.

This was true when I first learned to program, and is still true today. And I do find myself manually typing in really critical code. In those cases even if I do have an LLM alongside these days, LLM suggestions also then get manually typed.

For example, when I am reading a book, I often take notes of my favorite quotes/sentences/things that stick out or perk up my ears. Usually if I own the book or it's a used copy of mine I make a note of the page number on the very last blank page(s) and write out the full sentence/quote. Then when I go back months or years later I just open to the last page and can find all my favorite/important quotes. Most 200 page books typically have ~20 useful sentences for me to reference [going forward] - it's basically like making your own index or table of contents.

That long aside, just to say, if I'm not "very aware" or "consciously mindful" of what I'm copying down or writing, I'm able to do it very well on autopilot without etching anything into my memory -- as if no recallable moment gets etched into the wet cement of the brain unless I'm actively "hip to it." I wonder if others have this "autopilot" problem.

If you write, you should write in your own words, to demonstrate your own understanding - the so-called Feynman technique. Never verbatim. That's as true for coding as it is for study notes.

Basically it would convert all of the chunks of your code using an LLM to simple pseudocode with clickable symbols so you can follow function calls, definitions, then you could expand/collapse it to see the real underlying code.

The thing is that, probably like many of you, I love going deep in a side project, even if it lands nowhere. With so little time, working on them has become a very frustrating activity.

This is where I found my trap... do more with very little time by delegating to an LLM. You get dopamine shots, the feeling of achieving something but the cognitive dept is just crazy. So much that the activity becomes almost meaning less. After couple of months doing this, I'm not even sure it's a good use of this time. I get very little satisfaction on the long run.

I don't have a solution to this problem, not even sure there one. I think I have to accept that this is an activity that takes time, and only time gives the real gratification.

I do think there is absolutely no way a learner should be using ai for code generation. I think code analysis is the only acceptable usecase.

I think it is worth noting that not all code is equal... One could argue that adding a library is in some ways similar to copy/pasting code in as much as, one doesn't know what the code is doing, and yet that doesn't leave me with a sense of unease!

So it might be that as I'm working with an LLM there are parts (boring, as the author calls them) that are not worth "knowing" how they work, something uninteresting or that a correct output is all that us needed, I'm totally fine having the agent write that code, but the sections I need to know how they work, I think it might make sense to write those by hand!

Code quality is only going to get better and to be perfectly honest learning how to get the llm to generate quality output is IMO time much better spent vs some misguided attempt to do something by hand — the prompting is the better skill to develop at this point and if you’re worried about atrophy it’s probably your least developed skill

Instead I focus on reading the plan and making sure I understand it, opening up a second session for second opinions or questions if I have gem

This obviously depends on where in the stack you live but code quality is accelerating at a significant rate - decision making not as much and it’s where your value is imo

I've learned things I wouldn't otherwise have learned because I hadn't considered using the tools the LLM recommends. It's also a way to eliminate some hallucinating, given that critical questions are posed as unbiased as possible. For that, I also like to open a new chat with a different model and asking open-ended questions about a recommended tool I don't know much about, to double-check that the original LLM was likely correct in its recommendation in the first place.

Realistically, LLMs write code much better than most people. In my domain, there are areas where I still write better code than an LLM, especially when it comes to physical constraints it might not understand, but there are far more domains where the LLM writes much better code than I do. In that sense, writing code with an LLM and keeping track of it feels more helpful than I expected.

Practicing solo coding for an hour a day often ends up being mechanical and not very useful. This might actually be more helpful.

Our company's policy on LLM use is: use it, disclose it, and take responsibility for the code you commit.

There's no way that typing that tool back in would have done anything useful for me or my organization.

I think this depends on your level of expertise with the task.

If I'm writing a language I am extremely familiar with and so second nature to me, for example SQL then I can instantly read llm code.

But if a new language or a new piece of software then llm generating huge amounts of code can make it difficult to improve yourself and also manage the quality.

For example I had a working linear decay velocity boost function added to a godot scene and it's suggested refactoring actually reduced lines of code just today. So kind of happy when that works out, but yes I also applied the changes manually so I would grok them and hopefully remember it better.

I don't know about where you work, but in my neck of the woods if you want to be employed you will be reviewing AI PRs, there is no escaping that.

So I’m grabbing the double-edge sword with my bare hands hoping to stay ahead of the brain rot…somehow.

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.

I don't think this is a practice which will be sustainable for very long

But I don't just retype that code verbatim, I rewrite it in my style, add or remove comments, add or remove some checks, sometimes even tweak the algorithm. I want to own the thing. Some copy-pasting may be involved, I am not trying to improve my typing here, but the important thing is to understand every character of it.

I ask it to plan the feature in a separate worktree.

In parallel I start coding without being biased by AI and vice versa.

At some point I read its plan and iterate on it all the while I am in implementation mode. This helps me improve my own vision.

Finally I ask the AI to review my implementation. It flags off bugs and gaps which are usually straightforward for it to fix.

It's important to retain the what why and how as a team to the degree that development can be efficient, extensible, and maintainable. (And ideally a good devx)

Needing to manually touch every line of code is not scalable.

This was true 10 years ago. It's still true today.

I think that's my fundamental difference with the author. I only write programs I actually need. I enjoy the outcome more than the process.

However, if you're serious about it, then why not hand-write your LLM-generated code? You'll get much better retention and comprehension than typing.

It's one of the best ways to kickstart projects that have intrinsic software complexity as you get your hands wet into the design tensions and constraints early.

And you get to practice some.

I can see both logic in doing manual coding (perhaps with AI autocomplete) or a vibe based flow. They’re orthogonal approaches though.

File next to that 1970's era classic, "Prevent cognitive debt by manually retyping compiler-generated assembler"

The article is not wrong though that it pays off to have some imagination on how to use the models. For example, I want to use SIMD instructions in an ESP32-P4 CPU. Those instructions are undocumented for the most part, with just a couple of handwavey blog posts and some infuriatingly vague marketing material. So I just asked an LLM to create a `SIMD_P4.md` document with all the details. Lo and behold, it practically reverse-engineered the ISA. Now I can program in assembler by hand all I want and build that skill in my own brain, and whenever I find a slightly unclear op in the document, I ask the LLM to refine the documentation in that op.

The fact that we can’t trust the code outright is a bug

Typing itself is irrelevant, it is the timing spent, even if only seconds, pondering at what each word or syntactic element is and why use it.

Being slower does not automatically make you learn better, focus on the learning is what makes the difference.

If you don't have the opportunity to learn, the time to actually think, then a faster tool is not helping.

TL;DR: what matters is why you are doing something, is it solely to get the task done or is it primary to learn, or both?

I stubbornly refuse to let the LLM design. I can discuss my design with it, I can even completely discard it, but I am not fucking writing reams of natural language.

And know what? I don't think I am less productive than my "looping" colleagues, because, well, code is way less ambiguous than natural language, a validation rule in code can usually be expressed more economically in a programming language than in english prose. It is easier to create a directory and file layout, sprinkle some declarations here in there than it is to EXPLAIN how the flow of dependencies go. It is easier for me to create a hook because I want users of a certain module to be able to change its behavior without having to change the source of the module than explaining the OC principle to the LLM and seeing it miserably failing to apply it, because it doesn't have a theory of what it is fucking doing.

And as a side effect, when the 30th day of the month comes, and all the company tokens for the month are used, I can still be productive while others wait for the CTO to negotiate a couple tens of thousands more in API with the CFO.

Of course agentic coding tools are not trying to peer code or teach/inform you what they are doing, so being present in the moment doesn't help, but I suspect that copying it all down later doesn't help much either.

When you are/were developing software without AI, even for pretty large projects you do end up internalizing (memorizing, but not deliberately so) a lot of detail, but from my own experience I'd say it's more the design than the code. The design is what you put effort into, thought about, etc, so is both what you naturally end up memorizing, and is what you need to know to have a mental map of the project and therefore understand how best to modify it. The code itself was naturally always the last thing you did, and followed automatically from the design and module/component interfaces - not something you typically think much about other than while in the flow of just "coding it up".

By retyping LLM-generated code, it seems you are mostly going to be gaining familiarity with the wrong thing - the code and not the design. Memorizing the code is not going to help much in grokking the design.

First, use the LLM to understand the problem thoroughly. They can be great research aids. I've speed up tons of learning using LLMs. It is essential you ground the discussion in existing texts or code. Ping pong with the LLM asking it to challenge your understanding, how you direct citations for explanations, clarify things, etc.

After you've understood, plan. Develop a plan with the LLM/agent by steering it hard. Read the slop text thoroughly. Give it direct feedback. Don't proceed until you have a complete expectation of what you think the agent will do when implementing the plan.

Let the agent do all the implementation.

Review the agent's work. Again, engage with it and leave direct feedback. Ask for clarification and alternatives if needed. If it was totally off mark, start the process again.

You won't be moving at warp speed with this approach but you'll know a lot more than the one shot prompting loop cowboys out there.

Since writing is thinking, coding is thinking since coding is writing. That means any time I am not certain how I’m gonna implement some feature or bug fix, I have to code it myself because that’s the only way I can force myself to think through it. Only when I get to a point where I’m line “ok I know exactly what to do now- all that’s left to do is type it out” that’s when AI can be employed - essentially as a autocomplete.

This is only for projects where I will be held responsible for outcomes and must understand how it works. For hackathon / personal projects, I vibe away.

I also use AI to brainstorm at the outset of the task when I don’t know where to start at all.

Is this inefficient? My take: no. It’s maximally efficient. Over the long term it gives me an edge over any teammates who just vibe code everything because I actually, you know, understand how stuff works. I become the guy who can save the day at 3am when the team’s business critical app goes down. I become the guy that gets pulled into meetings so the suits can ask “is this possible?”. I see opportunities and problems before my teammates because I have a relationship with our code and system that they never took the time to develop or think about.

Having LLMs write out their design and reviewing it seems more efficient. Have LLMs, maybe with a different model, check that the implementation meets the design.

we need to move on

Whenever I encounter an especially preposterous proposal like this one, I like to imagine a USMC Drill Instructor wandering into the open plan office and having an interaction something like this:

USMC Drill Instructor: "What the actual fuck are you doing?!"

Smelly Recruit: "Sir, I'm hand typing the LLM output. Sir!"

USMC Drill Instructor: "Are you fucking with me recruit?! I said I wanted a SASS App, not a typing tutor! Drop and give me 20!"

Smelly Recruit: "SIR, YES SIR!"

Don't let your skills atrophy.

"professional malpractice" LOL. This is so dumb. I can't believe this shit is getting upvoted.

my workflow:

- ask not only for a solution to a problem but also for specific code (= tell the agent about your mental model of the codebase)

- ask for small stacked 'PRs/branches' and review/refactor heavily also using the agent (= refine your mental model of the codebase)

Mindlessly typing something is not much better than copy and pasting?

I could maybe see it if you asked it to spit out pseudocode you had to rewrite. At least there’s some translation there…

But this is bizarre. Write it yourself at that point. Is it any faster (or faster at all frankly) to prompt what you want, manually write it out, and maybe even make adjustments as you go? I’d argue not.

The way I wrote code in the past was to just first comment out what I wanted to do, and then underneath write the syntax for it. You could maybe do this too? Take the LLM code, and go through commenting what each section does to be able to effectively break it up? It still seems dumb.

Buy if you code for a job, good luck justifying this to management. “Yeah Claude already gave me the solution, I’ll take the rest of the week to type it out”

"Stay in shape by walking behind your car."

64 GB of RAM, nough said?

1. HIGH-VALUE CODE:

I write it all myself. I will occasionally use AI for mostly mechanical changes, like cleaning up variable names or mass-changes when a function signature has changed. Either way, every line is read carefully. Sometimes this means isolating my high-value code as a library in a separate repo. Usually it's just a note in AGENTS.md, or even a well-written comment at the top of certain files. I'm not obsessive about it, though, as it can't hide from git. And learning what it's trying to change is sometimes a useful insight.

That doesn't stop me from using AI as a consultant. This is the one time I'll use a beast like Fable. Ask it to write a technical/security analysis on a section of code and damn it can pull out some impressive insights. It can't write new code particularly well, but it can inspect code like a boss. But that all stays in the chat window. (And despite being so infrequent, they ends up costing significantly more than all my other AI costs combined!)

2. BOILERPLATE/PROCEDURAL CODE:

I'll write the first draft, but once I've set the tone, I'll allow AI to build and maintain it. I keep on top of things like a senior manager, just to make sure it's not doing stupid things. Every few days I tell it to mow its own grass: AI is good at recognising its own stupidity, you just need to give it an opportunity to look.

3. TEST/HARNESS CODE:

Bring on the slop. If I get nothing else from the AI revolution, it's not having to write another stupid test unit. Nothing makes me happier than setting the AI to work writing every permutation of test I can think of. I will slop this code all day, and I won't read a single line of it. Why should I? If I ever doubt whether a particular test is correct, I'll test the test by breaking the code, not by reading the test. But I almost never catch it out. In my experience, AI is especially good at writing tests. Perhaps more than anything else.

Tests don't just take the form of a few mocks and props in a test harness. In one recent case, my project involved writing a library for the API of an obscure commercial microcontroller-powered device. I took the API documentation and made AI build me a complete simulator. I then made it write a full suite of tests using my client library within the test code. I then got it to run that test suite against real hardware and identify any inconsistencies. From there it could recursively modify the simulator until it became unreasonably good at mimicking the real hardware. I haven't read a single line of its code. But it's now core to the library's CI.