Prevent cognitive debt by manually retyping LLM-generated code
ankursethi.com328 points by mpweiher 11 hours ago
328 points by mpweiher 11 hours ago
Big no for retyping llm generated code by hand.
But a big yes for still typing code by hand, and not leaving it to the llm. Except it has to be the code generated by your brain.
That is what will create new neurons and new connections, which is what will keep away the cognitive decline.
And the constraint of not having to use llms will enhance creativity.
Actually, the constraints llms add to your code are more in 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/
I disagree. Before coding agents really took off, back in like 2022, I was trying to learn how to create grammars in Treesitter. One evening I sat down with ChatGPT and had it generate a grammar for me. But because it was on ChatGPT, I had to manually write everything it spit out.
What ended up happening is that I was typing, I'd notice little weird bits here and there, and I'd ask questions about it, explore alternatives, etc. So the end result was partially generated by ChatGPT, but also partially influenced by me.
But the biggest win was that within 3-4 hours, I was comfortable enough with the syntax that I was writing it entirely by hand, without AI assistance.
Now, if all you're doing is literally typing the characters and not thinking at all about what you're typing, and if you accept the LLMs output verbatim, then yes I'd say that you aren't really learning anything. But this is no different than just copying things from Stack Overflow. That behavior is nothing new.
The core distinction, as always, is whether you are exercising your brain.
> 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.
100% agree with this.
The problem is, your employer doesn’t care whether your brain is creating new neurons and connections. They care about productivity and profit.
I feel like the folks that believe we can continue to write code by hand are either in denial that LLMs will eventually (if not already) outperform handwritten code, or are in denial that employers will be ok with lower levels of productivity.
If you have the luxury of working for an employer that either doesn’t care or is oblivious to this, then 100% continue writing code by hand.
Or if you do work on the side (whether for fun or for profit) and are ok with lower productivity, then yes, stick to handwritten code.
But just because handwriting code is better for your brain and cognitive development, doesn’t mean that the industry will be in support of it.
I feel like there is an unspoken assumption of long term maintainability when it comes to LLM generated software. We are still very early in this, so I don't want to make assumptions. In principle, it shouldn't be impossible to both write and maintain stable software, purely with agents.
At least, I'm not aware of any actual reasons, backed by a proper theory.
On the other hand. I've noticed some persistent issues with code generated by agents, especially poorly supervised agents. If engineers become less vigilant, agents never get to the point of not needing supervision and juniors never pick up required skills, this could lead to real trouble.
> long term maintainability
Did business ever cared about this? Like ever?.. I've seen too many code bases with awful code by humans, now AI simply exacerbated the issue but this is nothing new in our field.
I just don't see how this is going to be a battle engineering departments can win. As long as AI is brining money to the business, they are not going to listen.
LLMs aren't perfect and they have problems, but often they write better code than humans. At least this human.
It seems they run into problems with larger concepts and general organization and need guidance at the moment but for a single code file they often do better then I would have.
If an LLM writes better code than you, that says more about you than anything else (either your ability to write code or your ability to evaluate LLMs). The code they write is garbage.
They write garbage if you turn off your brain. They write code as good as yours if you work together.
I broadly agree with you about improving quality through working together. But even with tons of discussion, they still write code that seems fine from a distance but is weird when you actually get down to actually reading it and thinking about it, line by line. It is not junk but sure as hell I can write tighter and cleaner code and I am a very mediocre programmer. The abundance and frequency of "what, why?!" and "why not just..." reactions I have at LLM code throughout the day has made that much clear to me.
> The code they write is garbage.
This is trolling right?
No. Sometimes they produce code that's ok in small units, but definitely not all the time.
I agree with everything you said.
I’m simply playing devil’s advocate, because engineers can believe one thing, but until employers believe it, it doesn’t matter much.
I’m also not convinced that the reality of LLMs will never catch up with what employers think they can do.
It may never happen, but it very well could.
Either way, I feel the days of employers being ok with handwriting code are limited.
The complexity of code is combinatorial. Code is harder to understand than it is to create. The LLMs will be creating code that they will not (nor will any human) be able to understand later, or it won't be the same understanding that was used to create it. We'll find that systems that were created with LLM code will be impossible for LLMs to contextualize, or will be cost-prohibitive to do so.
The wages for the LLM will increase as the codebase gets larger, the only inhibitor is how fast customers are willing to pay for new features. I don't think that cost ever goes higher than human wages for maintainable software.
In theory (never happens) the software will become feature complete and you only pay the LLM for security updates.
It's a moot point. In Mag7 companies internal code gets thrown away within 2 years on average because of contract negotiations, new opensource projects that obviate need for the internal codebase, license changes, layoffs, etc, etc. We don't need long term maintainability because its already on its way to the garbage bin. Frankly it's always been this way.
Its' the exact opposite ... Google, nVidia, Amazon, Apple, etc. all have a deep bench of code that is a moat. They have lots of throwaway code too, but those companies are precisely the ones that pay attention to code quality, and comprehensibility by experts
A rough proxy for this would be if they say contribute to the C++ standards process, which Google Microsoft nVidia do, and basically zero "normal" companies (say SaaS) do. It means they are investing in multi-decade maintenance of their codebase
"Contribute" is an interesting word, since those companies are so big they can just dictate the standards they prefer. Also they are so big and have so much cash pouring in that they can afford to pay employees with nothing better to do than spend time drafting C++ standards. The average normal SaaS company is hoping they can make payroll next month.
Is google still a big contributor to the c++ standard? I thought they are far less involved than a decade ago.
I’m talking back of house, you’ve sort of mistakenly missed my point and made a rebuttal to some completely different question and I agree with you.
> The problem is, your employer doesn’t care whether your brain is creating new neurons and connections. They care about productivity and profit.
It was/is a struggle to get them to recognize and balance tech dept, we must now push to balance cognitive dept as well.
Some employers will eventually get it as they have with tech dept. And those will be the ones we see succeed.
> The problem is, your employer doesn’t care whether your brain is creating new neurons and connections. They care about productivity and profit.
I feel like this is an odd thing to be reticent about. You're working for someone who doesn't care about you and, in this changing landscape, you're compartmentalizing that in order to determine how best to care for yourself. Logically, to care for yourself you'd need to find an environment in which your needs aren't being neglected.
> or are in denial that employers will be ok with lower levels of productivity.
More like sweeping the dust under the rug for later. The initial productivity boost is massive but at the cost of massive upfront tech debt. Given that LLMs aren't as good at removing code as they are at generating it, this is a problem.
Not shocked to see here that people believe "manually writing code" is the way to build brain power.
How about moving up the stack?
Well there’s a lot of middle ground between “don’t use AI” and “generate everything, exclusively.”
When the bill for the latter lands with a heavy thud, moderation and common sense start to look like a pretty good idea.
> Well there’s a lot of middle ground between “don’t use AI” and “generate everything.”
Sure, but again, this assumes both that handwriting code sometimes outperforms LLMs, and also that your employer agrees with this.
I think it’s only a matter of time (again, if we’re not already there) before LLMs outperform handwritten code nearly all of the time.
And, even if that’s not the case, I’m pretty convinced nearly all employers believe this is true, whether it is or not.
So your employer only sees a “middle ground” as room for higher productivity.
this pure speculation. maybe you're right that it's a matter of time but /maybe you're wrong/. neither of us can actually know, because you're making predictions about the future rather than claims about what is true today
Perhaps the thing we’re going to learn to leave behind after all the dust settles … will be shitty management at shitty companies?
Because to be honest, more and more it seems many businesses have no real purpose other than to act as a sort of adult daycare for otherwise useless people.
> The problem is, your employer doesn’t care whether your brain is creating new neurons and connections. They care about productivity and profit.
Which is why businesses, tech and otherwise, are falling apart constantly unless they achieve gigafuck scale status, at which point they're unkillable no matter how much of this cancer infests their management.
I don't know how we arrived at a social norm where it's just completely fine that leadership in massive companies is just absolutely useless at their jobs, but the firms that last another hundred years are going to be the ones that figure out how to fire them all.
It is game theory optimal to use LLMs as little as possible even if your employer wants you to use it. The less you use it, the more competitive you are in the market, and probably also in your current workplace, LLM usage metrics notwithstanding. This fact will remain true forever, even if LLMs always outperform handwritten code and all employers want you to use them.
Probably what you want to do is use it a lot when you first start a job to establish some productivity credence, then as you become ready to switch jobs, use it less and less until you're writing everything by hand and taking interviews.
Interesting idea. I hope you're right: but have you tested this idea on the job market?
> I feel like the folks that believe we can continue to write code by hand are either in denial that LLMs will eventually (if not already) outperform handwritten code...
They certainly don't today. Perhaps they will in the future, but based on the lack of improvement thus far it seems unlikely that they will get to this point. But whether or not they do improve to that point, the reality is that today, LLMs do not give you a productivity boost unless you give up on quality and just YOLO stuff the LLM gives you without actually checking it. And nobody should be willing to do the latter, because that is how you get software/infrastructure that doesn't actually work.
> I feel like the folks that believe we can continue to write code by hand are either in denial that LLMs will eventually (if not already) outperform handwritten code, or are in denial that employers will be ok with lower levels of productivity.
Cooking a steak and then flushing it straight down the toilet outperforms all the slow and tedious business of eating and digesting it, too.
Why should I use an LLM to write code? It cannot do the job I want it to. It cannot type the code I've already written and it cannot generate correct code.
> Cooking a steak and then flushing it straight down the toilet outperforms all the slow and tedious business of eating and digesting it, too.
That would be more equivalent to writing the code and immediately deleting it.
Except this code is being deployed, and it is still (mostly) functional, at least functional enough to satisfy your employer (their “hunger” in your analogy).
> Why should I use an LLM to write code? It cannot do the job I want it to.
Because your employer is convinced that it can do the job they want it to (whether it does the job you want it to do is irrelevant, unless you're the employer, in which case 100% handwrite your code).
> Except this code is being deployed, and it is still (mostly) functional, at least functional enough to satisfy your employer (their “hunger” in your analogy).
Bzzzt. Wrong. I don't give a fuck who's satisfied by my code. I only care about writing it.
> Because your employer is convinced that it can do the job they want it to
Bzzzt. Wrong. The code is incorrect because it is not precisely the code I would have written.
LLMs are useless to me because they don't solve the problem of actually typing the code I've written into a computer.
Again, unless you’re the employer, then you’re getting paid by someone that cares more about productivity than whether you think LLMs produce incorrect code.
All that matters is whether they agree with you.
The only control you have over this is to either a) work for yourself, or b) keep looking until you find an employer that agrees with you.
My argument is that the number of employers that fall under (b) is shrinking.
> My argument is that the number of employers that fall under (b) is shrinking.
That's great. Sucks to be them. I've doubled my prices and doubled my time estimates and I'm still turning work away.
Thing is, companies don’t care if it’s not your code or your view of it. If it works, that’s what they want. Since I stopped typing code I’ve been using my time to play some video games, read some books etc while the agents do the boring stuff (work itself). I get paid, the company is more productive, I got a bonus and a raise, everyone’s happy.
With the rise and rise of LLM slop in code, I've just had to jack my prices through the roof.
The first thing I do when I'm asked to clean up the LLM slop is "rm -rf ." and start from scratch.
You will pay a fortune for this.
"I am the world hence everything i say must be correct and there can be no counter opinions because i know everything. bzzzt."
> It cannot do the job I want it to.
I mean in your case, you are not able to use LLMs effectively to build features, so you should type the code by hand.
However, upper management is excited about AI because it can push features quickly to production. Granted, they will be giant balls of slop but they don't care. As long as it works in the UI, they are happy.
If no one could get anything done with AI, there wouldn't be billions invested i n it.
> I mean in your case, you are not able to use LLMs effectively to build features, so you should type the code by hand.
I never write code sitting at a computer. Mostly I write it in the car, when I have no distractions. I just type it in when I'm sitting at the computer.
I've been using Claude as an experiment for some "fun" projects that I'm unlikely to release, just to see how it is.
The thing is, at least for the stuff where it's getting deep into the far edges of synthesizer firmware, disk image decoding, audio generation and the like, Claude is mostly just quoting my own github repositories back to me.
So, I guess I'm doing something right then, or maybe I'm doing it wrong.
I think people use these tools in varying ways, sometimes in the same session, and there are no hard-and-fast correct answers.
For example:
Sometimes I just need to blast something out which works well enough so I can either consider the output or play with the tool it generated to see if I'm on the track for solving my bigger problem. In these instances, I just say, do it, and don't focus too much on the code it produces.
Sometimes I am using languages or tools I am not an expert in. In many of these cases, I do manually type out the LLM's suggestions so that I am more intimately familiar with the syntax, libraries and idioms being used. Frequently pausing to look at actual documentation or find examples of sample code. It's a more interactive version of what I might have been doing a couple years ago googling solutions on stack overflow.
An entire generation of programmers was created in the 1980s from typing code from magazines. OTOH the only way to run it was to first type it in. Today people have too many options to be bothered I suppose.
I used to type in the programs from Commodore 64 Magazine back in the day. If you just touch type them in you learn very little. If I wanted to understand them, I wouldn't do it while typing. Sure a bit rubs off and probably more if you have to understand where to put the code rather than just start typing from the top, but still not enough. If you "make it your own" then you're probably at the right level of understanding.
I would love an agentic tool that simply finds code locations and opens them in my editor, so that I can write the implementation. I find this to be the most tedious and disorienting part, especially in languages without strong typing, that de-emphasize navigable references between classes. For example, wouldn’t necessarily need this tool for Java. Would like it for Ruby.
I don't think OP is telling people to literally type verbatim what the LLM generated, I think he is still implying that during the typing you are also thinking and possibly tweaking the code you are typing out, it is already a big step up from copy-paste
There are jobs where llms can massively speed up delivery. Think about tiny/one man indie games for example, they can also get (stolen) assets almost for free. Helping with hobby projects, a subtype of that one man show.
Then there are sluggish corporate jobs. Here, even 10x speed up of development won't change delivery dates significantly or at all. I am in one such job, team leader has claude code higher tier and basically uses it for some more complex bash scripts and thats mostly it. Given this topic, I dont complain much, I value my long term senior skills way more than those new agentic ones.
The middle is... well somewhere middle.
so don't use LLMs? You cannot get away from it now, the skill lies in how to generate code small enough for you to digest, as opposed to vibe coder where they generate so much code, there is no way to read it but to accept the run test.
It is somewhat accepted that typing does nothing for memory versus handwriting, so I'm not sure why we're even bothering tbh.
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.
To repeat their last two sentences:
> 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...
There's always some component of a skill that is not merely knowing something but practising something seemingly procedurally. Even if I understand integration well and have done it thousands of times, if I don't continually practise it from scratch, I begin to forget tiny bits and pieces and that accumulates to an eventually lack of understanding. So it is true for all mental tasks. There really isn't such a thing as understanding something completely without working it out by hand, from scratch. AI exacerbates a lack of understanding in this regard, although admittedly layers of abstraction in the coding realm already do that to some extent...
Perhaps typing the code by hand means you are more deliberate and less likely to have the LLM produce thousands of lines of diarrhea.
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.
> 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.
It seems like an exercise to force you to attend to the details. I had a similar experience with a "certified X programmer" exam my employer bought for me. I wouldn't say passing such an exam makes anyone a good programmer, but it was an unexpectedly valuable experience because it forced me to attend to a broad set of details (instead of getting a spotty command of them, due to path-dependent experience).
Similar thing happens with notes: I rarely reference them but taking them keeps my mind from wandering.
I like coding katas (or even trying leetcode problems) when learning new languages.
> 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.
Of course you learn more if you retype material than if you do nothing, but it's still a waste of time, comparatively speaking, because there are much better ways of engaging with the material like solving practice problems.
Having to spend 95% of the time taking notes of things that could be distributed in a PDF has only ever hindered me academically. It's mechanical and boring, my mind tunes out and I get nothing out of it.
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.
When I did a CS degree in the 1980s we had one lecturer who handed out copies of hand-written notes but then would talk about stuff that wasn't really in the notes - sort of verbal annotations.
Guess what he would ask about in the exams?
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 programmed this way my first year of community college because I didn't have a computer. I'd retype all of my work in the computer lab.
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.
I think the disconnect here is that you can't only retype the solutions. You have to already sort-of know what's going on and you have to also care to understand the gaps.
So transcription can definitely be helpful when part of a broader, intentional process, while also being insufficient to do much on its own.
And the next logical question to ask is whether there's a better form of intentional behavior that might be more effective.
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.
It is far, far less effective than deriving the solution yourself. Don't take my word for it:
> If you absolutely cannot do it then go home and think but for heavens sakes don't look it up in a book till you give up. Looking it up in a book is giving up. > > Paul Halmos (https://www.robots.ox.ac.uk/~adutta/blog/quotations-powerful...)
> 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.
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.
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.
After typing in the program, I found that single stepping the program in a debugger greatly helped with understanding.
I think it depends on what type of cognition you want to stimulate. It's probably useful to familiarize yourself with a suite of API calls, or get a big picture view of how an algorithm runs.
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 :)
Everyone learns differently. Retyping was extremely helpful for me. The key, for me, was to look up what I didn't understand.
Wouldn't it maybe make more sense to try to use Cursor-style auto complete if you are trying to learn a language in this day and age?
Having Codex/Claude write all of it won't really benefit you imho.
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.
> 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
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.
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.
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.
Lots of reactions here, but if it works for you then that's great.
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.
I feel like you think the car analogy was a clever parallel to draw here but looking at a car centric north american population and the dimensions of a non trivial slice of them that are unable to walk a 5k, id say you made the opposite point.
You have a point based on the way I wrote it. What I was trying to get at:
If you're going to walk to the store, don't push you car there! Just walk. So if you want to write code, don't retype what the LLM said, create your code from your own brain.
Unfortunately coding is a perishable skill, unlike walking which is at least partially ingrained into our DNA.
Managers famously get dumber but think they get smarter and then start to write army metaphors.
Don’t good generals know how everyone else in their army does their jobs? At the very least to the extent they can see through the bullshit.
For example, I don’t handwrite the code that the compiler produces, but I know how to troubleshoot the IR/assembly and fix optimization issues that arise occasionally. That makes me better at my job of directing the compiler.
I am currently betting on LLMs being significally better than even top engineers with good 'taste' within the next 5 years so I am focused on learning how to drive AI better. Anyone thing I should alter my apporoach/thinkig?How?
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.
I did this too. Almost always I'd rename variables, change formatting, add or remove comments, etc..
Unfortunately this feels less easy to do with modern tools. For example, Claude Code expects to edit your actual source files, and the Claude chat is much worse at writing code.
I use zed for this (you can use vscode as well), just use the side panel chat, take away write permissions, prompt it with "answer with code in chat" or similar, then you can use it as a personalized StackOverflow for your codebase. Even if it outputs an entire new file, you can take your time and go function by function.
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
> would copy homework from someone else
I was pretty good at it - mostly remembered to change the name at the top of the paper too.
Struggled at moderated exams; think it must have been the time pressure or something.
If you do it mindlessly, I'm sure you are right. But one could try to understand and integrate each piece of code as they "copy" it over. May be hard to sustain though.
> 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?
In my love(?)-hate relationship with "vibecoding", even I tried this approach. For a while it worked, though that "while" didn't last as long as the months OOP has been riding this wave. Though, the vibes have usually been off, so I wish I could keep both thinking of and writing that code which adds negligibly to shareholder value. I say "wish" because a part of me has definitely been hijacked, in much the same way as the addictive type of social media. Sometimes I feel like I need a serious intervention.
> 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.
> 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.
Did you not do that before AI? It’s so strange to me when people are calling out these kind of tasks like they were not already a requirement for the job. What were you doing before?
> 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
Chess is way less complex than coding. The rules are like a few pages. While the specs for an 8 bit chip like the AVR is in the hundreds of pages. Books like “The Linux Programming Interface” are thousand pages long.
Also humans are using tools for building. Tools that do exactly what you control them to do. When you use a drill for a hole, you don’t have to worry that pressing the trigger have a good chance of sending the bit in your guts.
> Did you not do that before AI? It’s so strange to me when people are calling out these kind of tasks like they were not already a requirement for the job. What were you doing before?
No, you didn't have to explicitly say it in words. My mind doesn't run on internal monologue. Many people can just do their work without ever having reflected on it in words. Tacit knowledge, routines, shared assumptions and culture in a team, common knowledge etc. People have a hard time using AI because they are bad at modeling the knowledge state / information context from the AI POV. You need good theory of mind for this, and being a good programmer is distinct from that soft skill. Yes yes blabla soft skills are more important than hard skills blabla, I don't buy it. It used to be valuable to be great at the hard skills even with mid-tier soft skills. You can have a ton of smooth talkers who are attuned to feel each others emotion and desires super well, but the thing has to actually work too.
> What were you doing before?
Wrote code. Yes, you have to explain the outcome to your boss or your team at some point, but people generally have better developed theories of mind for people than for AI.
> Also humans are using tools for building. Tools that do exactly what you control them to do. When you use a drill for a hole, you don’t have to worry that pressing the trigger have a good chance of sending the bit in your guts.
Right. I'm not sure how to reconcile the two though. A tool whose job is to do some of the thinking part seems to be a contradiction to me. If I so much know what there is to do that it's pure execution and can reliably be executed in a way that basically ensures no potential surprises to me, then I wouldn't need more thinking. But I agree, it would be better to somehow find a hybrid that is both doing thinking and feels more like a tool also while using it.
Llms are a relational responsive reasoning interface, not a mind.
The point is that you have to have an idea of what it has access to in its context. Many expect it to work like an omniscient genie and then give up once it turns out that it can't read your mind and you have to be able to halfway-coherently state what you want.
> No, you didn't have to explicitly say it in words. My mind doesn't run on internal monologue. Many people can just do their work without ever having reflected on it in words.
Were you a solo developer? I think the amount of reports and explanations (either written or verbal) dwarfs by large the amount of code I’ve written. From training juniors to drafting a design specs for a feature. That is why people say code is the trivial part of the job because it’s easy. I’m pretty sure the mailing list of the Linux kernel is bigger than the code itself.
I'm in academic ML research. Coding is mostly scoped to myself. And it's often nontrivial. My communication is more in papers, reports on experimental results, deciding what to try next, but how the code is organized is rarely the focus of discussion. Of course this may be entirely different in a software shop building routine features where the difficulty is indeed the social part and the software itself is more clearly understood. But I'd say that's when AI can be even more effective since it can do mundane coding even better proportionally than research code. Of course Amdahl's law kicks in and even if you reduce that drudgery to 0, the proportion is small when taking total work effort into context.
> Of course this may be entirely different in a software shop building routine features where the difficulty is indeed the social part and the software itself is more clearly understood. But I'd say that's when AI can be even more effective since it can do mundane coding even better proportionally than research code
And here’s another fallacy that is always thrown around. Always underestimating the other’s tasks when you are not an expert in it and don’t know intimately what’s involved.
So which is it? Is the coding part easy or hard? If it's easy and the task is mainly all the song and dance with the client, the stakeholders, getting approval and whatnot, then AI can take care of that easy coding and at least save that time. But then that is proportionally not much. I do have friends in industry, and they do sit quite a lot of hours in front of an IDE typing and fighting compilation issues, etc. It's not like they are always in meetings. I know people who work in the computer vision industry, 3D perception, and they have relatively few meetings and report to their boss occasionally, are not micromanaged, there is little red tape. They are getting real benefits from AI. It has eliminated several efficiency problems in their code that nobody took the time to fix, like consolidating repeated computations to just being done once, or similar things. They have solved a lot of CI pain with it, where they used to have an entire employee just taking care of keeping the CI in shape and updating it and remembering all the quirks, it's no longer a full time job, though also not fully automated. The CI person of course doesn't like the fact that his arcane knowledge has become un-moated. (I've worked on maintaining servers myself and I was the only one who really knew how it worked or how to fix it when it was broken, how to use it in specific special contexts, e.g. in context of a Slurm cluster. Today a lot of that hard-earned detailed knowledge is obviated by Claude, because it can answer similarly well to how I could, or better. So I have experienced such things myself too.)
I don't think we should be making sweeping claims. But everyone generalizes. The person on top claimed that productivity doesn't increase for competent people and that coding is anyway very easy. That may be true in some contexts but not in others. Some software jobs require a lot of face-to-face, others less. Some managers micromanage, others just care about results on a longer timeframe. Some people build technically difficult, computationally heavy code, deployed on special hardware with efficiency requirements, others deploy website-like iPhone apps and CRUD webapps all day. There's no single shape for a software-related job.
The thing is coding is very much like translating. And we do have machine translation. And they do fine for simple sentences. And even with more substantial paragraphs, you can get the gist of what it’s being said. But no one will say that it does a better job than a professional translator. And if you go and translate something from a foreign language, it wouldn’t be the kind of English you’d write. So assume that English to a foreign language is equally strange for someone that speaks that language.
So comes the programmer as a translator. Why the translation itself takes some effort, but most of the intellectual works is understand the intent of the change request or the specs (nothing to do with the code) and grasping the semantics of some features of the platform (library docs,…). Once that’s done coding is fairly easy as long as you follow the consistency of the code (architecture and other design patterns).
So on one side you get the formal world of computing and buggy libraries (backed by electronics which is a bit more chaotic) and on the other side you got natural languages, the various jargons, and other formal notations. The programmer translates one to another and overtime become proficient in both.
You then add AI into the mix and the same ickiness appears. While non speakers are enjoyed that they can write code, all programmers are saying that the code is bad. Not because of syntax, but because it lacks any consistency with the program which is the formal representation of the specs/solution. Thus the rise of harness and agents. But the machine translation still does have a lot of issues that professional programmers have to clean up.
> Some software jobs require a lot of face-to-face, others less.[…] There's no single shape for a software-related job.
But there’s one fact. Code is a formal notation for an algorithm, and that notation can be executed by a computer, thus making the process have a tangible effect in the real world. That effect is what is useful and making it controllable, thus modeling it and designing an interface is a worthwhile effort. Once that’s done, you can formally write it. But we have found that it is hard to do it in one go, so incremental approach is best.
So everything about software development is about modeling and having a suitable interface. The code itself is only a tool. Just like a ruler is only a tool to get a straight line. The straight line is what’s valuable. Not the ruler.