This will cause cognitive debt anyway. As mentioned in https://arxiv.org/pdf/2509.21972v1: "When students rely
on these outputs as a substitute for their own reasoning or critical engagement, the learning process is fundamentally
compromised. Genuine learning requires the active construction of meaning, integration of knowledge, and reflective
engagement with content. These processes cannot occur through passive consumption of syntactically correct but
semantically hollow responses. Without this deeper cognitive work, learners risk mistaking linguistic fluency for
understanding, thereby undermining the very goals of education".
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...
What do you think would be the effect on people that already have the skills and abilities. The LLM would build these systems using the skills that are largely understood by the programmer but piece them in new ways suitable for the system. This could lead to new enmergent behaviors that are not understood by the programmer.
I still think that you can build this model in your head even with LLM's but I'm not sure neither one way or the other.
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 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.
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 initial improvements to its requirement that code got written line-by-line. I still maintain the habit of rote text copying as a way to pick up new tools and commands (i.e. copying documentation examples exactly into my editor), and also when people make an assertion like:
> It's like trying to retype calculus solutions — you don't learn from it.
Maybe not everyone learns that way, but I sure did!
Very much similar experience to yourself, when I was learning from YouTube tutorials I refused to copy/paste from their repos and instead typed everything out. Maybe changing variable names or structure.
I can definitely say it helped me learn a lot more than just blindly copy/pasting everything over.
Except that you do. Otherwise you could just sit in school or university and just listen and do nothing, but that way you just learn A LOT less, instead of taking down the lecture/lesson.
Taking down the lesson/lecture does relatively little, you can do it on autopilot. If anything, it distracts from listening to the content. When I took computer science at university (mid naughties) we were given digital lecture notes anyway. (Mathematics lectures did have to be written down but there were no typed notes to start with so it was just out of necessity.) It's the exercises afterwards that are useful for learning. Or summarising notes in your words.
Yes some people teach C this way, for a little while, I don’t forget semicolons as much as people around me later seemed too, may or may not be related
I'm not sure I agree about retyping calculus solutions. I often find that writing out a proof or derivation forces me to engage with some minor detail that I hadn't fully appreciated beforehand. That usually raises productive questions.
In which case it would be the engagement with minor details that does the productive work. Retyping is merely a gateway to (sometimes) trigger the engagement.
The solution in TFA feels like an on-ramp to cargo culting somehow; observing that manual typing and good results often go together, but then thinking that it's the typing that directly causes the good results rather than the thought process that accompanied the typing.
There's a much better article hiding inside the current one that's titled "Prevent cognitive debt by understanding deeply the code that your LLM spits out", but that sounds like hard work and would probably not be very popular. It's much better for audience engagement to provide a simple solution that anyone can do and does not require a lot of deep thought like "manually retype everything the LLM generated", even if it doesn't actually work.
Writing reinforces. You won't learn from blind uncomprehending rewriting, sure, but when you already know the field, writing gives you the space to comprehend and digest. Certainly more than copying and pasting or blind acceptance of generated code. It doesn't have to be fun to be better.
At the beginning of my professional journey I was coding along youtube tutorials to learn, and I can tell you for a fact that all writing reinforces is syntax, which is reinforced regardless when you build your own projects while you develop your decision making skills at the same time.
Writing certainly reinforces more than that when you're not just starting out. It's a poor learning tool. When you have no grasp at all of the meaning, yes, it'll only enforce the syntax you can grasp at that point. I'll maintain that it's a good reinforcement tool, especially to the ends mentioned in the article.
I had fun and also learned a lot when I retyped programs from magazines back in the day. I am not sure if it's suitable now but there is certainly some merit to the idea.
I'll note this one down. I was under the impression that yes, retyping helps learning something about a language and architecture, but I found myself forgetting it after a while...
Trying it first sounds slower, but definitely better for cognitive training :)
You have implicit assumption that the person rewriting does nothing else. Understanding intention and solution is in there too for most people.
A lot of calculus is rewriting blocks of solutions and applying them to problems. There is a huge chasm between how calculus and real analysis are taught. By your logic calculus should be of very low value. Yet somehow it opens a lot of doors for people to learn other things based on it.
> Retyping things is inefficient for learning. It's like trying to retype calculus solutions
Says who? You're saying this unequivocally like you have research that supports this.
I used to re-write the notes I took for studying and it was like night and day for how well I did on tests. IT also gave me a chance to tighten the information I was receiving. And it's exactly what's happening here.
I had to re-read it a few times to make sure I was actually interpreting it correctly because I couldn't believe someone would make a claim like that for everyone.
It’s very common here on HN from the threads I’ve engaged in - everybody has an idea how learning works but it’s usually based on perceived personal experience and not actual research. I.e. you’re completely right with calling it vibe learning.
One thing it taught me was that sometimes the corrections would be in next month's edition, so I had that long to figure out for myself why the program didn't work as stated.
Good advice yesterday, good advice today, and good advice tomorrow.
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.
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.
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, and the goal back then also wasn't to keep retyping a GCC output to keep the skill fresh. It was to get to a higher level of control and think about the organization of structured code, code maintenance issues, thinking at the level of how to make the C++ implementation.
With AI, our role also shifts. It's mainly to know what to spend effort on, to set priorities and, to be able to verbalize requirements, missing social context and unwritten rules, to anticipate what additional documents the agent needs, to prioritize deadlines, feature necessity, and other judgment calls.
We are right at the stage where our coding ability and review ability is still needed though, but this stage won't last long. Soon there will be as little point to a human diving into the code as to trying to beat a chess engine, or humans constructing buildings by hand. Of course the discussion and prioritization may involve looking at the code itself, to get a better idea of why the agent says that a certain feature would be tedious to implement in the current architecture, but then most people will just learn to take its word for it, just as you may want to understand a chess engine's step, but you typically wouldn't want to override it.
What I did is kinda similar, I downgraded to $20 plan and just ask questions and almost never let it write the code, and if I can I use the web ui like the good old days and not spend my CLI tokens.
As an aside, back in the days of Stack Exchange I would always type out manually whatever answer I found to make sure I understood WTF I was adding to the system.
As someone who, at a point, would copy homework from someone else, copy book reports from online, and use the answer sheets to complete assignments, I can tell you this strategy is long known to accumulate and not prevent cognitive debt
I don’t think so, because it’s being used as a way to try to remedy one of the new problems brought in by agentic coding - loss of context of what code does.
This is what I'm doing right now to learn Electron, I essentially had Opus write me a tutorial to write the application I want to have, and I'm modifying bits and pieces as I go. It's been enlightening thus far, and the bot isn't always right so I still need to look up documentation on occasion.
I am also worried about "cognitive debt". I hardly remember what I had Claude do, even hours later. Back in May, I advised of a similar mitigation, citing the "generation effect" as the reason typing the code would make you remember it better:
> 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.
I'm taking a slightly different approach. I've started a project where I intentionally don't use agentic coding. I use LLMs for researcher and to learn, but write all the code by hand.
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.
It's better than nothing perhaps, but reminds me of UK highschool in the 80's (is it any different now?) where we had to manually copy everything down that the teacher was writing on the blackboard rather than the teacher giving handouts so you could pay attention to the teaching. The act of copying everything down was a negative rather than a positive.
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 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.
Frontier LLMs write better code at CRUD tasks than 95% of developers today. They’ll get to 95% of most niche coding domains by December and likely all coding tasks sometime next year; 99% better at all tasks by December 2028.
You may be correct now and it doesn’t matter one bit.
I think there are far more people who can't write better code than an LLM. Of course, there are a few exceptions, but it's a fact that LLMs are already handling PhD-level mathematics and papers.
I also think I write better code than an LLM in certain areas, but in most programming domains, the LLM knows more than I do across many dimensions. As prompts get deeper, LLMs are already producing PhD-level code—and that's been shown in research. The vast majority of people don't have that level of education. Of course, having a PhD doesn't guarantee good coding, but at least it's clear that LLMs can handle that level of capability.
People might disagree, but my view is firm on this.
> I also think I write better code than an LLM in certain areas, but in most programming domains, the LLM knows more than I do across many dimensions.
Remember that the quality of the LLMs code in the areas you don’t know is as good as the quality as the area you do know. You’re only able to gauge the quality of what you do know.
Your main target seems to be the view that software quality is a matter of 'aesthetic intuition,' but I see it differently. I think because it's 'engineering,' there must be measurable indicators.
Executable specifications
Unit, integration, and property tests
Official API documentation
All of these provide ways to judge quality. There are so many metrics that the problem is actually choosing which ones to use.
1.Does it produce output A for input B?
2.Can it process 100,000 records within 5ms?
3.Is memory usage within the defined limit?
4.Does the protocol handle error conditions properly?
You don't need to be an expert to test these. People forget that programming is one of the few fields where judgment criteria can be easily translated into machine executable tests.
The biggest problem with epistemological objections is that they often assume a binary: 'experts can judge, non-experts cannot.' But in reality, it's a continuous process.
You run the code, notice something odd, look up the terminology, compare it with official documentation and reference implementations, add tests, and gradually build up judgment in that area. Rewriting LLM generated code compresses that entire learning curve.
In the past, entering an unfamiliar domain meant starting from a blank file and reading documentation. Now, you start with a working hypothesis and modify it. That's far cheaper than starting from scratch.
If you treat LLM generated code as executable teaching material and a falsifiable hypothesis, it's a very powerful resource.
I feel uncomfortable when people reduce programming to aesthetic quality alone. We were all trained to measure things.
My "aesthetic" sense is more about how modular the code is, how DRY (which is also an aesthetic balancing act), how clean the abstractions are and how well they fit the domain and the workflow.
Also, error handling.
Tests, specs, and docs are are all downstream of that.
So far I've found that AI does an adequate-to-very-good job up to a certain amount of code, then things tend to fall apart. The solution is modularity and clean interfaces - as it always was.
I'm not really sure. I'm mostly thrown into existing codebases and just modify things to fit the existing style, so I'm almost always evaluated purely by metrics. I do think your (TheOtherHobbes) standards are really good, though.
>You’re only able to gauge the quality of what you do know.
That's not true. You can follow the logic step by step, search for similar domains, and form a comparison group.
Realistically, if we take this logic to its conclusion, it's like asking: 'You're just a spectator, so can you really judge whether a football player is good at football?
Realistically, LLMs write code well. I'm a C# programmer, and as you know, the current trend in modern programming is to refine error handling—using try/catch at higher layers, working with monads, preserving computable contexts, and branching accordingly. That kind of code typically takes 1 to 2 hours of modeling before you even start writing.
But an LLM can do it in just 5 minutes.
So I think the opposite way: if LLMs can do this well in a domain I'm familiar with, they're probably just as capable in other domains too. And that makes them feel trustworthy.
And more importantly, no matter how great a human programmer is, once you step outside your domain, you're in unknown territory. In those areas, LLMs are surprisingly helpful.
Epistemologically, it might be true that you can't evaluate code in a domain you don't know. But people keep forgetting the fact that you can learn through that code. This very post is itself an example of learning through LLM-typed code.
And programming actually provides clearer results than many other domains. It's not based on subjective UX like UI design. You have:
1.Executable specifications
2.Performance measurements
3.Comparisons with official documentation
These are clear engineering outcomes that allow for objective comparison. For example, you can verify whether a program produces results within 5ms when executed.
Many epistemological arguments tend to overlook this.
A lot of code is open source. You can find mature implementations anywhere. Finding a repo from someone claiming 10 or 20 years of experience and running a differential comparison is not difficult at all."
Related, a writing advice I stole from Neal Stephenson is to write the first draft by hand. The thing is, there are a lot of small corrections where you kinda should change the text but nah, and if you already committed to copy the entire thing than you are already working at that sentence anyhow.
I don't know if retyping is the solution, but for me is clear that we need something additional to a terminal and a code editor. I envision a software that an agent can use and showcase to you how it did implement the changes and why.
The same way a colleague would do, focusing on the important bits, then ending with the trivial stuff. Something in between pair programing and code reviews.
Right. I want an AI that sees my screen, sees my mouse cursor, has my audio transcript synced to the mouse movements, and it can similarly do TTS and and pointer movements or put things like circles and rectangles and background highlights on things while it talks, and slows down if I say so etc, like a human discussion partner.
Diffity has a “tour” feature that can be directed to explain a local code change. Walks you through the important bits of the change with explanations.
As others mentioned retyping is not fun. My approach is to let it write the code, but only in small portion. Not "implement this feature". But "open this file and make these changes". Each small change is easily reviewable and often times I end up asking it about better options and iterate a bit. Still feels like I'm in charge. Still feels like I'm learning stuff.
This resonates with me. The concept of cig it I've debt was something I've been experiencing but didn't have a name for it.
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!
> 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!
It does, to me. Been burned enough times that I now, at minimum, audit the source code of third-party libraries before I use them.
When I was younger and took over a codebase I open it up in one window and then type it back into another window. Not only did I catch/fix a crazy number of bugs, but I became a near expert overnight. Doing the typing would cause me to question everything, ask why we import something, why x is used and not y, etc.
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?
I've used LLMs in a similar way and I'm reminded of learning to draw / paint.
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 never had so little free time as I have these days. Most of my time is spent at work or with my lovely family.Love my family, and work is great.
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.
Alternatively, what I tend to do after receiving generated code is a lot of asking "why?".
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.
This is the workflow that Vs Code Copilot does. All the AI generated code changes are in a git worktree and you can step through them all. This is what I missed after Claude forced third parties to start charging API pricing and now I have to use Claude directly and I have to do this same review process in a clunkier way via my git client.
Manually typing in code is an underappreciated trick in a lot of circumstances. It's one of the fastest ways to get to grips with a certain piece of code, a new library, or some methodology.
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.
I already wrote my opinion on this, which I don't think anyone read, but my idea is to let AI code the working system, and then prompt it to teach you, give you challenges, and grade your work.
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.
My counterpoint to that is, you never know when the factuality of its analysis is mistaken because you're making it the point of authority over knowledge you should be working to acquiring.
In math classes back at school, it didn't matter how much the math professor explained how the formula works. What mattered is me putting in the effort to understand it. The implication to your example is, I should already be familiar enough to understand the generated code to the point where all the explanation that it's doing is effectively a "Quality of Life feature".
I wonder how effective it finally will be. At first glance it reminds me painting by numbers a d I'm not sure if that will help the real painter to keep his skills and surely won't teach aspiring painter much about the craft.
This is not about an aspiring painter though. This method is intended for an already accomplished painter. Not saying how effective it is but your comparison is not relevant.
Pair programming with the LLM is a better approach. You can take either role and even take turns. It’s slower but gives ample time to read everything and push back on decisions or receive feedback and review on your own decisions.
My rule is: I only let AI code for me, I don’t let it think for me.
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.
If you can afford it, why not. For certain phases of projects like a proof-of-concept, you need to move fast and validate several ideas. Once it's locked down, rewrite from scratch, and here, if you can afford it, type or write the code manually.
Would one retype assembly language for C generate code?
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.
Nice workflow! I'll give it a try.
I'm struggling with building mental model of AI-generated code. And code review fatigue is real. This may be the way.
I like the "cognitive debt" term. With the latest models, what I've observed is that they are really good, but I don't use them to write main code because I need to know what I'm doing.
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.
When I got my first corporate job, I was placed in a group of 20 trainees in a rigorous COBOL course. We were given assignments and a schedule to complete them.
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.
For learning? You can use llms to help you with stuff and still learn new things in the process. Its really surprising that so many people don't understand this.
Are people really out there just mass copy pasting llm code without even trying to understand it! lol
But this way you move way slowly even on personal projects, like you will not even get the basic UI for the app done in a few days? Is that OK for you?
Depends what they're doing... I can crack out a basic UI in a few hours at my job, and I don't use LLMs at all, and I wouldn't class myself as an expert developer or anything
No you misunderstand me. I support such a view but cannot hold it because my pace at work is so much fast. And hand coding like this will make personal projects s slow and choreful with no visible progress. Like where is the joy in that?
Without an active harness (eg. Appium) that can end-to-end deterministically verify the changes you make continue to work correctly it is almost impossible to continue to keep the same pace on the app.
Unsupervised LLMs (even fabel) are categorically
incapable of running parallel unsupervised mobile app feature development.
That is my personal, first hand experience working in a team in this space.
What you are (I guess?) experiencing is user-in-the-loop light touch LLM development where you can 80% most tasks quite quickly (much faster than without assistance!) with a small number of human developers working on largely unrelated features and manually verifying they are correct and manually fixing the platform specific issues you encounter.
Maintaining a strong appium end-to-end test suite is still extremely challenging with notifications and maps.
Honestly, it blows my mind you could even being to claim that of all things, native apps using obscure languages like swift are suitable for this, compared to the much much easier path of web + react.
You might say “yeah yeah, but one month? Come on!”
…but have you actually seen how much code fabel can write in a month?
Its a lot.
So sure, you say, work at a slower pace. Don't just endlessly run a frontier model in unsupervised feature development mode.
Yes… you see, thats the point. Thats what the op is saying.
Move more slowly, and you can avoid building a spaghetti castle (ok sure! If you dont wanna, maybe don't retype every character by hand, but the point of that practice is not upping your wpm typing speed. :p It is to take the time to think, design and collaborate, not rush rush rush)
Do you really find your typing speed to be the bottleneck in getting things done? I suppose that's pretty easily fixed, at least.
Anyway the author did address that
> 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.
Funny that there's another trending post titled, "Don't be a meat proxy," just above this proposal that we literally meat-proxy all the code.
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!"
I don't think it's bad to manually retype code as a way of learning.
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.
I don’t disagree with this if you code for a hobby.
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”
I use LLM code for hobby/fun projects only (I also don't code for a living) and I still wouldn't want to type up the code it gives me. Instead what I dream of doing is one day to rewrite all the little things from scratch (well, with a blueprint of a working result). Your management wouldn't even talk to me, rightly so :P
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.
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.
This will cause cognitive debt anyway. As mentioned in https://arxiv.org/pdf/2509.21972v1: "When students rely on these outputs as a substitute for their own reasoning or critical engagement, the learning process is fundamentally compromised. Genuine learning requires the active construction of meaning, integration of knowledge, and reflective engagement with content. These processes cannot occur through passive consumption of syntactically correct but semantically hollow responses. Without this deeper cognitive work, learners risk mistaking linguistic fluency for understanding, thereby undermining the very goals of education".
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...
What do you think would be the effect on people that already have the skills and abilities. The LLM would build these systems using the skills that are largely understood by the programmer but piece them in new ways suitable for the system. This could lead to new enmergent behaviors that are not understood by the programmer.
I still think that you can build this model in your head even with LLM's but I'm not sure neither one way or the other.
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 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.
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 initial improvements to its requirement that code got written line-by-line. I still maintain the habit of rote text copying as a way to pick up new tools and commands (i.e. copying documentation examples exactly into my editor), and also when people make an assertion like:
> It's like trying to retype calculus solutions — you don't learn from it.
Maybe not everyone learns that way, but I sure did!
[0] - https://www.amazon.co.uk/iPhone-iPad-Apps-Absolute-Beginners...
Very much similar experience to yourself, when I was learning from YouTube tutorials I refused to copy/paste from their repos and instead typed everything out. Maybe changing variable names or structure.
I can definitely say it helped me learn a lot more than just blindly copy/pasting everything over.
> you don't learn from it
Except that you do. Otherwise you could just sit in school or university and just listen and do nothing, but that way you just learn A LOT less, instead of taking down the lecture/lesson.
Taking down the lesson/lecture does relatively little, you can do it on autopilot. If anything, it distracts from listening to the content. When I took computer science at university (mid naughties) we were given digital lecture notes anyway. (Mathematics lectures did have to be written down but there were no typed notes to start with so it was just out of necessity.) It's the exercises afterwards that are useful for learning. Or summarising notes in your words.
Even better would be to rewrite it by hand with a pen.
Yes some people teach C this way, for a little while, I don’t forget semicolons as much as people around me later seemed too, may or may not be related
I started programming this way as a kid with books and notes that I'd then periodically would be able to enter into a computer to see if it runs.
I'm not sure I agree about retyping calculus solutions. I often find that writing out a proof or derivation forces me to engage with some minor detail that I hadn't fully appreciated beforehand. That usually raises productive questions.
Retyping calculus solutions is a great way to remember your LaTeX.
In which case it would be the engagement with minor details that does the productive work. Retyping is merely a gateway to (sometimes) trigger the engagement.
The solution in TFA feels like an on-ramp to cargo culting somehow; observing that manual typing and good results often go together, but then thinking that it's the typing that directly causes the good results rather than the thought process that accompanied the typing.
There's a much better article hiding inside the current one that's titled "Prevent cognitive debt by understanding deeply the code that your LLM spits out", but that sounds like hard work and would probably not be very popular. It's much better for audience engagement to provide a simple solution that anyone can do and does not require a lot of deep thought like "manually retype everything the LLM generated", even if it doesn't actually work.
> you don't learn from it.
I strongly disagree. I used this strategy for learning how to reverse engineer and hook functions in a game with C++ and learned a ton.
I also used this strategy to learn Imgui and it worked great. Before LLMs I did this when learning from books too.
Writing reinforces. You won't learn from blind uncomprehending rewriting, sure, but when you already know the field, writing gives you the space to comprehend and digest. Certainly more than copying and pasting or blind acceptance of generated code. It doesn't have to be fun to be better.
At the beginning of my professional journey I was coding along youtube tutorials to learn, and I can tell you for a fact that all writing reinforces is syntax, which is reinforced regardless when you build your own projects while you develop your decision making skills at the same time.
Writing certainly reinforces more than that when you're not just starting out. It's a poor learning tool. When you have no grasp at all of the meaning, yes, it'll only enforce the syntax you can grasp at that point. I'll maintain that it's a good reinforcement tool, especially to the ends mentioned in the article.
I had fun and also learned a lot when I retyped programs from magazines back in the day. I am not sure if it's suitable now but there is certainly some merit to the idea.
I'll note this one down. I was under the impression that yes, retyping helps learning something about a language and architecture, but I found myself forgetting it after a while...
Trying it first sounds slower, but definitely better for cognitive training :)
You have implicit assumption that the person rewriting does nothing else. Understanding intention and solution is in there too for most people.
A lot of calculus is rewriting blocks of solutions and applying them to problems. There is a huge chasm between how calculus and real analysis are taught. By your logic calculus should be of very low value. Yet somehow it opens a lot of doors for people to learn other things based on it.
> Retyping things is inefficient for learning. It's like trying to retype calculus solutions
Says who? You're saying this unequivocally like you have research that supports this.
I used to re-write the notes I took for studying and it was like night and day for how well I did on tests. IT also gave me a chance to tighten the information I was receiving. And it's exactly what's happening here.
OC out here denying the actual learning and reinforcement research because of vibes
I had to re-read it a few times to make sure I was actually interpreting it correctly because I couldn't believe someone would make a claim like that for everyone.
It’s very common here on HN from the threads I’ve engaged in - everybody has an idea how learning works but it’s usually based on perceived personal experience and not actual research. I.e. you’re completely right with calling it vibe learning.
For fun I typed out code from old old magazines and it taught me quite a few things.
Also essays too and other texts non code from llm or books, it helps.
One thing it taught me was that sometimes the corrections would be in next month's edition, so I had that long to figure out for myself why the program didn't work as stated.
Good advice yesterday, good advice today, and good advice tomorrow.
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.
Sounds like a devious plan to turn me from a self diagnosed 10x developer (& Founder, CEO, Serial Entrepreneur) into a plain old 1x regular Joe.
> 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 already eliminating these assembly line, JIRA-ticket-taker software jobs en masse.
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, and the goal back then also wasn't to keep retyping a GCC output to keep the skill fresh. It was to get to a higher level of control and think about the organization of structured code, code maintenance issues, thinking at the level of how to make the C++ implementation.
With AI, our role also shifts. It's mainly to know what to spend effort on, to set priorities and, to be able to verbalize requirements, missing social context and unwritten rules, to anticipate what additional documents the agent needs, to prioritize deadlines, feature necessity, and other judgment calls.
We are right at the stage where our coding ability and review ability is still needed though, but this stage won't last long. Soon there will be as little point to a human diving into the code as to trying to beat a chess engine, or humans constructing buildings by hand. Of course the discussion and prioritization may involve looking at the code itself, to get a better idea of why the agent says that a certain feature would be tedious to implement in the current architecture, but then most people will just learn to take its word for it, just as you may want to understand a chess engine's step, but you typically wouldn't want to override it.
What I did is kinda similar, I downgraded to $20 plan and just ask questions and almost never let it write the code, and if I can I use the web ui like the good old days and not spend my CLI tokens.
As an aside, back in the days of Stack Exchange I would always type out manually whatever answer I found to make sure I understood WTF I was adding to the system.
As someone who, at a point, would copy homework from someone else, copy book reports from online, and use the answer sheets to complete assignments, I can tell you this strategy is long known to accumulate and not prevent cognitive debt
> I can tell you this strategy is long known to accumulate and not prevent cognitive debt
When you say "long known" it sounds like this is established science. Is there a link you can share?
How so?
u sure?
This is a new form of prayer for those who can't break their religious addiction to LLM code generators.
It could easily be the other way around - religious addiction for people can't let go of the code.
I don’t think so, because it’s being used as a way to try to remedy one of the new problems brought in by agentic coding - loss of context of what code does.
This is what I'm doing right now to learn Electron, I essentially had Opus write me a tutorial to write the application I want to have, and I'm modifying bits and pieces as I go. It's been enlightening thus far, and the bot isn't always right so I still need to look up documentation on occasion.
I am also worried about "cognitive debt". I hardly remember what I had Claude do, even hours later. Back in May, I advised of a similar mitigation, citing the "generation effect" as the reason typing the code would make you remember it better:
> 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/
I'm taking a slightly different approach. I've started a project where I intentionally don't use agentic coding. I use LLMs for researcher and to learn, but write all the code by hand.
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.
It's better than nothing perhaps, but reminds me of UK highschool in the 80's (is it any different now?) where we had to manually copy everything down that the teacher was writing on the blackboard rather than the teacher giving handouts so you could pay attention to the teaching. The act of copying everything down was a negative rather than a positive.
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 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.
You are cooked if you can’t actually write better code than llm. Try reading some books or documentation
Frontier LLMs write better code at CRUD tasks than 95% of developers today. They’ll get to 95% of most niche coding domains by December and likely all coding tasks sometime next year; 99% better at all tasks by December 2028.
You may be correct now and it doesn’t matter one bit.
You are cooked if you think the end goal was the quality of the code and not the quality of the product.
What is "better code"?
I think there are far more people who can't write better code than an LLM. Of course, there are a few exceptions, but it's a fact that LLMs are already handling PhD-level mathematics and papers.
I also think I write better code than an LLM in certain areas, but in most programming domains, the LLM knows more than I do across many dimensions. As prompts get deeper, LLMs are already producing PhD-level code—and that's been shown in research. The vast majority of people don't have that level of education. Of course, having a PhD doesn't guarantee good coding, but at least it's clear that LLMs can handle that level of capability.
People might disagree, but my view is firm on this.
> As prompts get deeper, LLMs are already producing PhD-level code—and that's been shown in research.
This is not a compliment, in fact it's the opposite. Have you ever looked at the code of research papers?
> I also think I write better code than an LLM in certain areas, but in most programming domains, the LLM knows more than I do across many dimensions.
Remember that the quality of the LLMs code in the areas you don’t know is as good as the quality as the area you do know. You’re only able to gauge the quality of what you do know.
Your main target seems to be the view that software quality is a matter of 'aesthetic intuition,' but I see it differently. I think because it's 'engineering,' there must be measurable indicators.
Executable specifications
Unit, integration, and property tests
Official API documentation
All of these provide ways to judge quality. There are so many metrics that the problem is actually choosing which ones to use.
1.Does it produce output A for input B? 2.Can it process 100,000 records within 5ms? 3.Is memory usage within the defined limit? 4.Does the protocol handle error conditions properly?
You don't need to be an expert to test these. People forget that programming is one of the few fields where judgment criteria can be easily translated into machine executable tests.
The biggest problem with epistemological objections is that they often assume a binary: 'experts can judge, non-experts cannot.' But in reality, it's a continuous process.
You run the code, notice something odd, look up the terminology, compare it with official documentation and reference implementations, add tests, and gradually build up judgment in that area. Rewriting LLM generated code compresses that entire learning curve.
In the past, entering an unfamiliar domain meant starting from a blank file and reading documentation. Now, you start with a working hypothesis and modify it. That's far cheaper than starting from scratch.
If you treat LLM generated code as executable teaching material and a falsifiable hypothesis, it's a very powerful resource.
I feel uncomfortable when people reduce programming to aesthetic quality alone. We were all trained to measure things.
My "aesthetic" sense is more about how modular the code is, how DRY (which is also an aesthetic balancing act), how clean the abstractions are and how well they fit the domain and the workflow.
Also, error handling.
Tests, specs, and docs are are all downstream of that.
So far I've found that AI does an adequate-to-very-good job up to a certain amount of code, then things tend to fall apart. The solution is modularity and clean interfaces - as it always was.
I'm not really sure. I'm mostly thrown into existing codebases and just modify things to fit the existing style, so I'm almost always evaluated purely by metrics. I do think your (TheOtherHobbes) standards are really good, though.
>You’re only able to gauge the quality of what you do know.
That's not true. You can follow the logic step by step, search for similar domains, and form a comparison group.
Realistically, if we take this logic to its conclusion, it's like asking: 'You're just a spectator, so can you really judge whether a football player is good at football?
Realistically, LLMs write code well. I'm a C# programmer, and as you know, the current trend in modern programming is to refine error handling—using try/catch at higher layers, working with monads, preserving computable contexts, and branching accordingly. That kind of code typically takes 1 to 2 hours of modeling before you even start writing.
But an LLM can do it in just 5 minutes.
So I think the opposite way: if LLMs can do this well in a domain I'm familiar with, they're probably just as capable in other domains too. And that makes them feel trustworthy.
And more importantly, no matter how great a human programmer is, once you step outside your domain, you're in unknown territory. In those areas, LLMs are surprisingly helpful.
Epistemologically, it might be true that you can't evaluate code in a domain you don't know. But people keep forgetting the fact that you can learn through that code. This very post is itself an example of learning through LLM-typed code.
And programming actually provides clearer results than many other domains. It's not based on subjective UX like UI design. You have:
1.Executable specifications
2.Performance measurements
3.Comparisons with official documentation
These are clear engineering outcomes that allow for objective comparison. For example, you can verify whether a program produces results within 5ms when executed.
Many epistemological arguments tend to overlook this.
A lot of code is open source. You can find mature implementations anywhere. Finding a repo from someone claiming 10 or 20 years of experience and running a differential comparison is not difficult at all."
Related, a writing advice I stole from Neal Stephenson is to write the first draft by hand. The thing is, there are a lot of small corrections where you kinda should change the text but nah, and if you already committed to copy the entire thing than you are already working at that sentence anyhow.
I don't know if retyping is the solution, but for me is clear that we need something additional to a terminal and a code editor. I envision a software that an agent can use and showcase to you how it did implement the changes and why. The same way a colleague would do, focusing on the important bits, then ending with the trivial stuff. Something in between pair programing and code reviews.
Right. I want an AI that sees my screen, sees my mouse cursor, has my audio transcript synced to the mouse movements, and it can similarly do TTS and and pointer movements or put things like circles and rectangles and background highlights on things while it talks, and slows down if I say so etc, like a human discussion partner.
Diffity has a “tour” feature that can be directed to explain a local code change. Walks you through the important bits of the change with explanations.
https://github.com/nilbuild/diffity
As others mentioned retyping is not fun. My approach is to let it write the code, but only in small portion. Not "implement this feature". But "open this file and make these changes". Each small change is easily reviewable and often times I end up asking it about better options and iterate a bit. Still feels like I'm in charge. Still feels like I'm learning stuff.
This resonates with me. The concept of cig it I've debt was something I've been experiencing but didn't have a name for it.
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!
> 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!
It does, to me. Been burned enough times that I now, at minimum, audit the source code of third-party libraries before I use them.
When I was younger and took over a codebase I open it up in one window and then type it back into another window. Not only did I catch/fix a crazy number of bugs, but I became a near expert overnight. Doing the typing would cause me to question everything, ask why we import something, why x is used and not y, etc.
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?
I've used LLMs in a similar way and I'm reminded of learning to draw / paint.
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 never had so little free time as I have these days. Most of my time is spent at work or with my lovely family.Love my family, and work is great.
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.
Alternatively, what I tend to do after receiving generated code is a lot of asking "why?".
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.
Hard disagree, it's proven that its the actual discovery process that's makes us improve at tasks. Blindly typing will make you just good at typing.
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.
This is the workflow that Vs Code Copilot does. All the AI generated code changes are in a git worktree and you can step through them all. This is what I missed after Claude forced third parties to start charging API pricing and now I have to use Claude directly and I have to do this same review process in a clunkier way via my git client.
Manually typing in code is an underappreciated trick in a lot of circumstances. It's one of the fastest ways to get to grips with a certain piece of code, a new library, or some methodology.
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.
"Prevent sub-optimal code by manually retyping compiler-generated assembly"
I don't think this is a practice which will be sustainable for very long
LLMs are plenty far from compilers.
I already wrote my opinion on this, which I don't think anyone read, but my idea is to let AI code the working system, and then prompt it to teach you, give you challenges, and grade your work.
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.
My counterpoint to that is, you never know when the factuality of its analysis is mistaken because you're making it the point of authority over knowledge you should be working to acquiring.
In math classes back at school, it didn't matter how much the math professor explained how the formula works. What mattered is me putting in the effort to understand it. The implication to your example is, I should already be familiar enough to understand the generated code to the point where all the explanation that it's doing is effectively a "Quality of Life feature".
The most I enjoy working with AI is my special workflow.
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.
Whenever I don't know something, I ask it for a tutorial, programming-magazine style. Then I just follow the tutorial.
I wonder how effective it finally will be. At first glance it reminds me painting by numbers a d I'm not sure if that will help the real painter to keep his skills and surely won't teach aspiring painter much about the craft.
This is not about an aspiring painter though. This method is intended for an already accomplished painter. Not saying how effective it is but your comparison is not relevant.
We're living in such a stupid time.
It’s just bonkers
Pair programming with the LLM is a better approach. You can take either role and even take turns. It’s slower but gives ample time to read everything and push back on decisions or receive feedback and review on your own decisions.
My rule is: I only let AI code for me, I don’t let it think for me.
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.
If you can afford it, why not. For certain phases of projects like a proof-of-concept, you need to move fast and validate several ideas. Once it's locked down, rewrite from scratch, and here, if you can afford it, type or write the code manually.
Would one retype assembly language for C generate code?
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.
Nice workflow! I'll give it a try. I'm struggling with building mental model of AI-generated code. And code review fatigue is real. This may be the way.
I like the "cognitive debt" term. With the latest models, what I've observed is that they are really good, but I don't use them to write main code because I need to know what I'm doing.
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.
If you copy/paste code from a teaching book, you will probably not learn as well as if you type it.
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?
When I got my first corporate job, I was placed in a group of 20 trainees in a rigorous COBOL course. We were given assignments and a schedule to complete them.
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.
Why use LLMs at all if you're doing this?
For learning? You can use llms to help you with stuff and still learn new things in the process. Its really surprising that so many people don't understand this.
Are people really out there just mass copy pasting llm code without even trying to understand it! lol
But this way you move way slowly even on personal projects, like you will not even get the basic UI for the app done in a few days? Is that OK for you?
Depends what they're doing... I can crack out a basic UI in a few hours at my job, and I don't use LLMs at all, and I wouldn't class myself as an expert developer or anything
It is meant to offset not knowing why everything degrades and you can't make progress after the first month. Is that OK for you?
No you misunderstand me. I support such a view but cannot hold it because my pace at work is so much fast. And hand coding like this will make personal projects s slow and choreful with no visible progress. Like where is the joy in that?
The bottleneck is very rarely the typing.
Has this been your first hand experience?
And if so, in what work, and have you tried debugging issues with SOTA models?
From my experience it is certainly not the case that you cannot make progress after the first month.
I work on native mobile applications.
I work on mobile native applications.
Without an active harness (eg. Appium) that can end-to-end deterministically verify the changes you make continue to work correctly it is almost impossible to continue to keep the same pace on the app.
Unsupervised LLMs (even fabel) are categorically incapable of running parallel unsupervised mobile app feature development.
That is my personal, first hand experience working in a team in this space.
What you are (I guess?) experiencing is user-in-the-loop light touch LLM development where you can 80% most tasks quite quickly (much faster than without assistance!) with a small number of human developers working on largely unrelated features and manually verifying they are correct and manually fixing the platform specific issues you encounter.
Maintaining a strong appium end-to-end test suite is still extremely challenging with notifications and maps.
Honestly, it blows my mind you could even being to claim that of all things, native apps using obscure languages like swift are suitable for this, compared to the much much easier path of web + react.
You might say “yeah yeah, but one month? Come on!”
…but have you actually seen how much code fabel can write in a month?
Its a lot.
So sure, you say, work at a slower pace. Don't just endlessly run a frontier model in unsupervised feature development mode.
Yes… you see, thats the point. Thats what the op is saying.
Move more slowly, and you can avoid building a spaghetti castle (ok sure! If you dont wanna, maybe don't retype every character by hand, but the point of that practice is not upping your wpm typing speed. :p It is to take the time to think, design and collaborate, not rush rush rush)
I have no idea what "an active harness" is referring to, Appium looks like a cross platform testing framework.
I doubt it brings any advantage over XCUITest here.
What is supposed to be the problem with parallel development? I use worktrees, and it works just fine with five agents in parallel.
Automated end-to-end testing on mobile is notoriously flaky, but that's nothing new, and I think it is now much easier to deal with.
AKA preventing cognitive debt
Do you really find your typing speed to be the bottleneck in getting things done? I suppose that's pretty easily fixed, at least.
Anyway the author did address that
> 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.
nah thanks;
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)
Funny that there's another trending post titled, "Don't be a meat proxy," just above this proposal that we literally meat-proxy all the code.
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!"
I don't think it's bad to manually retype code as a way of learning.
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.
I don’t disagree with this if you code for a hobby.
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”
I use LLM code for hobby/fun projects only (I also don't code for a living) and I still wouldn't want to type up the code it gives me. Instead what I dream of doing is one day to rewrite all the little things from scratch (well, with a blueprint of a working result). Your management wouldn't even talk to me, rightly so :P
I just give them smaller tasks
This method doesn't seem bad.
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.
I feel like this will do almost nothing?
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.
...what, that's terrible advice. If you gonna waste time on that just waste time on writing the code from scratch
there is a simpler way, make a complete mental model of the changes and ask questions to confirm your understanding. so much faster.