As someone who’s been programming for 20 years, I have to say that programming itself often causes a kind of brain rot. I’m very glad that I can now focus on other aspects of software development. It was only with Claude Code that I realized I never actually enjoyed programming—I enjoyed building things. You can live a perfectly mentally healthy life without programming.
Fully agree that programming for me brings along "a kind of brain rot". Hard to describe, but working deep in code just shifts the mind to a state that's ... less open, more focused, more obsessive ... and seeps into daily life.
Vernor Vinge's concept of "focus" in "A deepness in the sky" really clicked with me and put into words what I'd always had at the back of my mind. A highly recommended read.
I read it because Elon Musk mentioned it as a favorite. It’s a good book and you can see how the concept of controlling ubiquitous tech is a thing he tries to do
How do you mean building things? To be honest, I don't get excited about most products that I'm working on - that is what the money is for. The enjoyment comes mostly from technological problem solving.
I get excited for the things I built. I built them for my clients and I love that clients are genuinely happy with what I built for them. And then I send an invoice which is followed by a payment. I love that too, I love both.
I dont't love doing some obscure integration of an API that should have been dead years ago but somehow still lives. I don't like squishing bugs because something doesn't work when the Sun is in the third house of Uranus on February 31st. Those are technical problems I don't like solving.
My point is that you and I both love something else and that is totally fine. But I'm not sure if you can keep making money with only solving technical problems.
I would say any programmer has found themselves so deep in the metaphorical woods that they forgot what they were actually trying to achieve in the first place. For example, you start because your boss told you to implement a new feature, but you realized there was no module you could place the feature in, then by looking at the existing module structure you realized it had become completely unsuitable in general, then you started trying to split some and rename others, then you noticed a circular dependency would appear if you didn’t add a third module between two you just split, and now all you can remember is that you’re fixing the circular dependency. The feature you were supposed to work on is a vague memory now.
I think this is a sort of brainrot which explains why a lot of times things take unjustifiably long to implement. LLMs can help so much with stuff like this if you know how to yield one. But it can also let you more quickly hang yourself if you don’t even care about “which modules even exist” ( to continue with my example).
Programming, as in manually typing the code, is a means to an end.
While I do enjoy coding, building things is what was rewarding, not actually laying down brick after brick after brick after brick.
I've done that for 10+ years. The fact that I don't have to do that anymore is a relief that cannot be overstated. I only have to check on the code that The Ideal Intern produces while I focus on what actually matters, and that is: Building The Thing.
It's all about how you use it and how careful you are with it, and the fact that today there are people IN THE FIELD that still question this baffles me.
Good for you! Personally I'm not so much interested in building things. On the other hand, my ideal life would be to make a computer do new cool tricks all day.
> Poor coders have always existed. You're not the first and won't be the last.
Did you get so emotionally hurt by another person saying they didn't want to actually type code anymore, that you felt the need to tell them they're likely a "poor coder"? You can still continue to type code if you'd like, no need to put others down because you prefer a different way of working.
Sorry, I'm not here to talk about your feelings. I am not "emotionally hurt", nor should you be. This is HackerNews and you're a grown ass adult (I assume). If you disagree with me, then feel free to outline your disagreement, or just ignore and move on.
My disagreement comes from feeling the need to put others down because they said something you didn't like. Nothing in their comments talks about if they're a good/bad programmer, clearly your putdown comes from a place of hurt. But no worries, lets ignore it from now on out, hope it gets better for you mate!
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.
Also... if your workflow is "think hard, let LLM write it, read what AI wrote, think hard about what AI wrote, re-type what AI wrote, fix what AI wrote"...
Where in the heck are the efficiency gains? Couldn't you just drop the LLM part of it and save the company a trillion dollars in tokens?
LLM speedups have always been predicated on not understanding the code they produce as well as if you wrote it yourself. Reviewing even well written code to understand it in depth, has always taken longer than simply writing it yourself - let alone sloppy LLM code that you have to fix
People are, in heavy LLM systems, realising that the most valuable commodity is engineers knowing WTF is going on, and that loss of understanding of your codebase is the #1 blocker to actually getting things done. Any senior engineer knows this all too well
Its why I suspect we never tend to see any longer term LLM productivity stats being published, and why I extra suspect that LLMs have failed to achieve any kind of penetration into open source code. If you take away the pressure to produce bad code, writing by hand clearly wins massively in the long term. Its classic short term gains for a long term penalty
> the most valuable commodity is engineers knowing WTF is going on, and that loss of understanding of your codebase is the #1 blocker to actually getting things done
Perfectly said. It was true before LLMs too.
As I've been reviewing more and more LLM code, I've noticed that while good developers can use LLMs to produce good code maybe 1x-5x faster (depending on circumstances), bad developers can use LLMs to produce bad code 1000x faster. And if you are collecting metrics that only capture that 1000x number, I bet you feel great about what you're doing.
> People are, in heavy LLM systems, realising that the most valuable commodity is engineers knowing WTF is going on, and that loss of understanding of your codebase is the #1 blocker to actually getting things done. Any senior engineer knows this all too well
I've been pushing against this "maximum LLM driven speed" in our infrastructure as well and been working on a middle ground:
We can generate a change to Ansible or terraform code in half or a third of the time, sure. But we don't use this to make three times the changes in the same time frame. We rather use the freed up time to discuss the change, the context and the affected systems with 2-3 engineers maintaining them. And yes, at times this means us three are sitting around half a day discussing and drawing diagrams about our systems.
I'm just happy to work in a company understanding the value of speeding up less than we could in the feature direction, but investing this time in the direction of control and understanding of the infrastructure.
Yup, this is how I see teams who care about quality, design and architecture seems to use LLMs, not to "produce more and faster" but to retain same speed but with a lot more confidence and reliability. Hoping this will spread eventually, some companies seem to take a more... hazardous approach to the whole thing.
"""People are, in heavy LLM systems, realising that the most valuable commodity is engineers knowing WTF is going on, and that loss of understanding of your codebase is the #1 blocker to actually getting things done."""
Very much this. It is also true for non-LLM code bases. I still remember my first job at a company with a bigger codebase than my typical "university project code base". It was a full fledged ERP system and just learning the lay of the land and understanding what lives where and why took quite a bit of time.
Interestingly, I think LLMs can be used for this "self-onboarding" and codebase-browsing/understanding. I've experimented a bit with treating an LLM as a guide of a bigger codebase it has "ingested" and having dialogues about it. Works reasonably well, I'm curious if there are companies out there that use this approach.
> LLM speedups have always been predicated on not understanding the code they produce as well as if you wrote it yourself. Reviewing even well written code to understand it in depth, has always taken longer than simply writing it yourself - let alone sloppy LLM code that you have to fix
I am at least 3x more productive by letting an LLM write my code and I review and understand every single line it writes.
Also, Fable 5 came up with some amazing solution and designs that I would have never been able to do myself.
I can say with 100% surety that my current project at work is MUCH better with an LLM compared to if I wrote it myself.
> LLM speedups have always been predicated on not understanding the code they produce as well as if you wrote it yourself. Reviewing even well written code to understand it in depth, has always taken longer than simply writing it yourself - let alone sloppy LLM code that you have to fix
I don't think this personal opinion holds well when contrasted with reality. The truth of the matter is that in moderately large codebases, which is the norm in any production setting, at best you have a T-shape understanding of the system: in specific areas you might have somewhat deep understanding, but for the vast majority of the system you have at best a high level understanding of the software architecture.
This is why software engineering frames things like design patterns, principle of least surprise,single responsibility, etc as premium design and code quality traits: they allow developers to effectively extrapolate their high level understanding of the project onto components they know nothing about.
In any software development setting,you will find that the most successful and even senior engineer is that which successfully and skillfully manages this uncertainty, and is able to hit the ground running on environments they never touched. I had a colleague who once was a senior software development engineer at a FANG that mastered this art, and called it JIT onboarding.
So why are you pretending this is something new or novel?
I think this blend of criticism only serves to allow inexperienced developers to stand out by complaining that a very mundane aspect of working on projects as a member of a sizeable team is somehow a novel development caused by LLMs.
And don't get me started on the "slop" nonsense. Have you actually browsed through code written by people?
Thank you for writing exactly why people who complain about LLMs making it harder to understand what’s going on are so off. Nothing helps more than asking LLMs to tell you exactly what’s going on! They are insanely good at that. I wrote the plugin system in my product, but many people added to it over a decade and today I have only high level knowledge of it. But if I need to know something about a very specific part of it, I ask Claude and now I know exactly what I needed to know. I could even write the code by hand now, and sometimes I do for the fun of it, but Claude has just explained to me, so it also knows exactly how to do it so why not let it do it?? I can understand as much as I need to by reading the code , asking questions, carefully analyzing the tests, much more than I would if I had needed to focus on every single detail that is irrelevant to the task. Sometimes I even do some minor refactoring just to try and feel like I’m “inside” the code as I used to. But I know I will likely be out of the loop again in 3 or 4 years, as I just can’t remember everything I ever did. But now I have a LLM ready to help me get into it again whenever needed again.
>So why are you pretending this is something new or novel?
Because as the OP of this thread and LLM users are rediscovering, that understanding is the most critical part of software development
>I don't think this personal opinion holds well when contrasted with reality. The truth of the matter is that in moderately large codebases, which is the norm in any production setting, at best you have a T-shape understanding of the system: in specific areas you might have somewhat deep understanding, but for the vast majority of the system you have at best a high level understanding of the software architecture.
I suspect a lot of people haven't worked on a system with engineers who've been there for 20 years working on it. There's simply no substitute for that kind of deep institutional knowledge, and it'll take you 5-10 years to be as productive as them simply because of that level of extreme knowledge about a codebase. It isn't as sexy as swapping jobs every 2 years though, so you have to go outside of the big tech bubble
I will say that yes, sadly, I have browsed through code written by people, and sadly also have browsed through code written by LLMs. Who do you suppose wrote the code the LLM was trained on? Divinity?
I'm being tongue and cheek, but as someone who uses these things extensively in work and personal projects, I want to point out that it's new or novel that generating lots of plausible code is now vastly cheaper than it once was, so the scales are quite different.
And yes, slop is an apt moniker for something that requires lots of careful prompting and configuration and guardrails (which is extremely sensitive to small changes in these initial conditions in ways that can be fairly nonobvious) to produce something that will in most cases read at least a little bit worse than if a human had written it. And it will still go off the rails sometimes!
To be clear I don't really agree that typing out the code generated by LLMs is a reasonable counterweight, it largely defeats the purpose. I agree that at a certain point you have to treat parts of your code base like a black box and enforce modularity. But this is still nontrivial, especially in more specialized domains with lots of nuance
> I will say that yes, sadly, I have browsed through code written by people, and sadly also have browsed through code written by LLMs. Who do you suppose wrote the code the LLM was trained on? Divinity?
Training is a red herring. The root cause is constraints, or lack thereof. If you lock a junior dev in a basement and force him to deliver the same features that these LLMs output, you will see exactly the same type of slop. The root cause is that junior devs are inexperienced and oblivious to best practices and guidelines and even the team's internal standards. They output code unconstrained by these guidelines and thus output big balls of mud.
> I'm being tongue and cheek, but as someone who uses these things extensively in work and personal projects, I want to point out that it's new or novel that generating lots of plausible code is now vastly cheaper than it once was, so the scales are quite different.
I agree, but we need to be mindful of what is the actual root cause. I argue it's not AI coding agente but the diverse source of these code changes, which we also see in production settings in projects managed by large teams. In teams manned by junior devs you see very much the same slop building up to a big ball of mud in a few iterations. This is nothing new. What changed is that now ai coding assistants grant everyone access to what amounts to a large team of junior devs.
I’m guilty of using this approach too and noticed that an (obvious?) side-effect is that I get fewer wonderful, human, “aha” moments with my colleagues.
I mentioned this at a stand-up and only then did others think about it and notice the same of themselves.
This, to me, is one of the major downsides of all this: less collaboration, more individualism
I think that's true. One caveat: If you're a solo coder like me, you almost never get to talk about implementation details with anyone who (a) understands or (b) gives a flying fuck. I'm more likely to have a meaningful convo about code structure with someone on a laptop sitting next to me at the coffeehouse. So sometimes a stand-in bot to bounce your ideas off of can illuminate corners you're missing, even if it's in some ways no operating just as a chat with yourself.
> This, to me, is one of the major downsides of all this: less collaboration, more individualism
Or put another way, it's replacing collaboration and human connection with your team with a subscription service that isolates you, makes you emotionally and cognitively dependent on the service while making your performance numbers look good. I really don't like the sound of that.
It has been the opposite for us. It is now being weaponized by PMs and leads to add more work for developers and not less in terms of documentation and sign-offs.
Now stories automatically have additional 10 subtasks for documentation and tracking. These are created automatically through "skills" and the task of detailed documentation and updating those extra tasks is a chore. When complained, they just say "use AI". Every JIRA task these days feels like submitting a petition to the government bureaucracy.
PMs are happy because they did something new, leaders are happy for more tracking, developers are expected to be happy with "productivity gains" due to not having to write much code.
I stopped writing code completely about a year ago, stopped reading code completely about 8 months ago, and I feel like I stopped thinking hard about anything at work about 6 months ago. To clarify - I still produce code for a living - all day, every day. Not sure about efficiency gains but I got promoted 3 weeks ago :)
The LLM is, in many ways, smarter than you and I: it can perform feats of advanced mathematics that have eluded mathematicians for decades. It's not at all unreasonable to think that an LLM could produce an idea better than you could have, but that reading it and typing it in gives you some better understanding of how it works.
knowledge, by doing that I retrieve the knowledge from LLM, I learn faster, write code faster, do things more careful... The efficiency is the better design, better code quality, higher test coverage, less bugs. Because LLM let me gain knowledge faster than previous tools.
I think there's some confusion in your post. You're seeing people claiming that the rate their code changes is so fast that they find it hard to keep their mental model up to date and in sync with the actual codebase. They frame this as a LLM issue, but those of us who worked in large teams will understand how it feels to be faced with a dozen changes popping up in critical areas of a code base each time we prepare to submit our own code change.
Once you understand this, you'll easily understand where all the efficiency gains are manifesting. Today's lone cowboy developers are experiencing the same type of struggles to keep up with a project that in the recent past affected projects worked on by large teams.
I mean, think about it for a second: what do you think is behind this higher rate of change?
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.
Haha, your analogy reminds me of one I often make to highlight just how much we undervalue fossil fuels.
Imagine filling your car with $1 worth of fuel and then driving it on flat terrain as far as it will take you. Now get out and push your car back. Friction and momentum aside, that's the astounding amount of energy/work we get from a dollar's worth of fuel.
Now imagine your car is actually an LLM model. It gets you a great distance on $1 worth of tokens but what happens when you run out and for whatever reason (I can imagine quite a few) further LLM use is not possible. You have to push your car/LLM back all by yourself to finish what was supposed to be a quick, convenient trip to the grocery store. Might've been better off walking.
Seriously though, I do think there is a real risk that LLMs are going to lure a lot of people far beyond their ability to swim back. It might even be the case that LLMs help strand people in situations that even the LLMs can't help rescue them from.
I've gotten into a situation multiple times where an LLM (usually a low-end free model) will write a whole bunch of code and then be unable to make any more correct changes to it because it can't hold enough context. Super easy to get into a duplicative spaghetti mess - exactly like I've seen human developers do countless times, but even worse.
No, in that it's something inherently much more unstable than a bicycle and needs a trained human onboard to have any hope of getting anywhere without falling over spectacularly
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.
> Don’t good generals know how everyone else in their army does their jobs?
They most certainly do, but on a mid-higher level. They don't probably know every single motion and definitely lack hands-on experience. But they know enough to be able to manage them efficiently.
I think this characterization misses the feedback loop that exists.
The OP is not sitting in a one-way flow of info:
LLM->human->code
but rather a the center of a feedback loop:
LLM<-->human<-->code.
Human-is-the-loop, not human-in-the-loop. Each iteration of that loop is fully driven by the human. Human creativity is involved in both directions.
I'd argue that anytime we drive an LLM through more than one turn (and/or more than one session) we are really doing a human-is-the-loop thing. The OP's extreme case of begin the only thing editing code is on a spectrum with the other extreme being vibe coding (never looking at output code, but still interacting with that output in some way).
Off the spectrum is what I call LLM-vomit. A human one-shots something and puts it out for others to see, suffer and clean up or ignore. This is code that is encountered literally out of context and can only be further improved (if that is even attempted) by approaching it from first principles. Such code is akin to people using LLM to generate an answer delivered to another human. Both flavors (sorry) of LLM-vomit are bad. I can prompt my own LLM to do that, don't do it for me.
I think some sort of visual paradigm is where we will end up. Something like Star Trek, where the system architecture and modules are visually represented in 3D space, and you see how the organization changes with realtime low-latency animation representing the changes as they are made. So you are still in control but just at a higher level. I see some prototypes and weak implementations of this sort of thing but surprised at how little is out there.
I kno you're not suggesting the visual system would drive coding at all or that it'd be a way to visually code (see: scratch). You seem to mean it as a visualization of the current code base. I'm hoping Google's code wiki is the first step in this direction. One thing I always thought was a problem with visual systems like this was understanding the codebase's architectural design at a level yu can't programmatically get out via a syntax tree analysis. Google's code wiki seems to be using an LLM to figure out the high-level structure of the code and then building the flowchart and diagrams from that understanding. Obviously there's gonna be issues and misunderstanding but I think that's the first step in the direction you're talking about. First it's text, mermaid diagrams and 2d. Next it's a 3d visual world of your codebase. AWESOME stuff. Someone @ Google.
The problem with all existing GUI coding system is that they make it really hard to make anything other than the types of things they were designed to make. You could do it, but you have to leave the path and get into the weeds of how the system works, which usually has several layers of opinionated code structures on top of the underlying language it's compiling to.
An AI visual/GUI coding system might be able to address that at a more modular level, but it would still come at the cost of transparency and reproducibility.
I'm not suggesting the visual system would driving the coding at all. I'm saying that it would be a visualization of your current code base as built by the LLM.
Don't worry. No one will want human code in just a few years. This bizarre fixation that humans are decent at coding is a myth. Retype what the machine tells you? I would rather garden or move rocks around.
“The Electric Monk was a labour-saving device, like a dishwasher or a video recorder. Dishwashers washed tedious dishes for you, thus saving you the bother of washing them yourself, video recorders watched tedious television for you, thus saving you the bother of looking at it yourself; Electric Monks believed things for you, thus saving you what was becoming an increasingly onerous task, that of believing all the things the world expected you to believe. Unfortunately”
― Douglas Adams, Dirk Gently's Holistic Detective Agency
Well it's a transitional methodology during the early stages of a major shift in software engineering. Just look at what almost everyone is complaining about with AI coding, and then the inadequacy of their proposed solutions - this is just begging for new tooling that we'll probably consider obvious in a few years.
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...
Its weird how absolutely desperate we are to avoid humans actually using their brains at any step of the coding process. I don't know if we just need to tell people that its fine to need to think about things, and that its actively healthy to do so. Learning is good for you, and no chatgpt isn't good enough to avoid using your meat
If you don't engage your brain, it'll rot. That's far more important in the long term than a 5% productivity boost or something. I have no idea why you'd trade off your entire technical development and skillset training, for the most short term gains, it doesn't even theoretically make sense if you care about long term productivity
In a way it's not so different from learning in school. There were definitely times I read a textbook for a programming or other CS course and reused some example code or whatever to solve homework problems.
I think the helpful part is taking something that already exists, learning how it works, and rewriting it yourself to internalize it.
Again as usual the more important thing is that you know what you're using otherwise it's just copying.
It is different from before. The programmers are used to read the code of smart or creative people, or the code of knolled people working for years to solve a specific problem, and within this process they analyze and learn to improve, thanks to this self-learning path, eureka moments included. This process includes to search (to read the voice of different perspectives and knowledges, to learn to use critical thinking).
Now is being proposed to read LLMs' slope and unrevised code constructed from statistics as the way to learn? This is a big mistake. IMHO.
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.
> 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...
It's simple enough: If you don't use it, you lose it.
The more you have, the more there is to lose and the longer it may take.
But skills and knowledge fade, just as easily as fitness, or a tan.
It's an insidious rule too. Insidious in the sense that you may not realise you're not exercising a skill. You may think that your just doing it slightly differently, but you will adapt. In whatever way you made your life easier, that's where you'll pay, in strength, fluency, depth, whatever.
The key is, as you said, practice. I think it's fine to use AI to write code for you, as long as you occasionally force yourself to write code manually. Not only does it help you retain your skills, but it feels more satisfying than prompting, even if arduous.
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].
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.
> 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.
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.
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.
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.
If you write more good code by hand than by agent in 2026 that says more about you than anything else (either your ability to give instructions or your ability to delegate). The code they write is above average.
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.
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.
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.
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
I'm REALLY REALLY not enjoying this current middle ground where we may be on the cusp of LLMs writing all code better than I could OR we may be on the cusp of realising that this is a chimera.
Mostly I just want to skip forward to the point where we find out which track we're on, because until we know, I feel constantly tense.
> 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.
> 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.
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.
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 mostly do reading in front of the computer (not code, docs), but that's before I'm used to the project. Usually I spend more time on the couch than in front of the computer. Because that's where I think best. If I'm writing code, I already have the solution.
Yup, that's what I do to, although like I say I mostly write my code in the car. I work on things all over Scotland so quite often I'm spending six hours driving to do a ten minute repair, and it is *great*. No, you can't phone me, I'm driving. No, I can't just jump on your teams call real quick, I'm driving? Email? No, driving.
This is what I've been focusing on. Writing good user stories, defining the definition of "done", acceptance testing. Thinking about the high level design decisions. Never thinking about how I'm going to implement feature X is honestly a breath of fresh air.
I've been writing code for nearly 30 years, and I'm done.
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.
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.
There must be some merit to retyping LLM generated code, even verbatim. In school, I would rewrite or re-typeset notes as a study habit. In doing so, I'd review content, detect errors, synthesize concepts simply because rewriting notes forced me to pay attention at the per-word level.
While retyping LLM code is not something I personally do, I'd imagine it could bestow similar benefits.
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
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.
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
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.
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.
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.
> 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.
> 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).
Yes, of course, but a lot of it is boilerplate and just figuring out how some function is called or how exactly it is exposed in the library, dealing with some frustrating but trivially solved inconsistencies or incompatibilities or oh you first have to initialize this or that, or actually this feature is missing from version X but can be emulated by setting an environment variable to this other value and blablabla.
> all programmers are saying that the code is bad.
Ridiculous. When did you last use AI for actual work where you wanted it to actually work? I know it may sound like saying James Randi's negative attitude blocks my telepathy or dowsing skill, but I get this impression of many people. They tried agentic coding a year ago, decided that it doesn't work and if they tried it ever since, they didn't provide context, didn't set it up for a possibility of success then immediately closed the program and sighed a sigh or relief that they are safe. It's not like that. The current frontier is very capable on higher level design tasks as well. If your problem is spiritual or social or economic, then let's skip this "not productive enough" alibi talk.
Machine translation today may not be up to the levels of the best professional translators who work on something with full focus and full effort, given all the time they want to polish it, but it's better than an ordinary (not particularly the top of the top) translator working multiple project with tight deadlines. You have to compare like for like and take cost into account too. There is an immense amount of mistranslations by "professional" translators, not sure if you've ever seen movie subtitles or TV series dubs. Lots of paid professionals hired by production studios make huge mistakes, clearly miss cultural references even sometimes grammatical structures, which modern machine translation aces and even chat models are great at it and know basically all obscure pop culture references that e.g. a regular American audience member is expected to know but a translator working in Estonia may not get. Yes you should have a guy checking the output and doing some light touchups, given the draft and explanations and references provided by the AI, but the time of doing it fully manually and being competitive on the real world translator market has ended.
> The current frontier is very capable on higher level design tasks as well. If your problem is spiritual or social or economic, then let's skip this "not productive enough" alibi talk.
My problem is not about the productivity, it's about how this productivity is measured.
> Yes you should have a guy checking the output and doing some light touchups, given the draft and explanations and references provided by the AI, but the time of doing it fully manually and being competitive on the real world translator market has ended.
Have this been measured that this is actually faster while ensuring a quality baseline? I believe it's still the same "LGTM". And a lot of complaints about low quality text. And bugs in the case of software.
So you got a lot of messaging about how AI is supposed to make you faster. And now everyone is trying to show how fast they are with AI while the products are getting buggier.
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.
You mention further down that you're in academia, and with that knowledge this post makes some kind of sense to me. I used to do academic research. Like you, I almost only worked on my own code and nobody else worked on mine. I also knew I wouldn't have to maintain, usually not even expand it, so I worked accordingly.
None if this holds for programming in business, and this is why you keep hearing people saying that the output of coding agents suck. It does! I won't accept the insinuation that people just dismissed it. I use frontier models daily and try to keep up with best practices. Even under the best circumstances, it still sucks, but you learn to apply it only in places where the suckiness matters less and you can mitigate it.
It's been disclaimed so many times that it's a tired trope already, but no, this is in no way comparable to compilers! Compilers relieve you of a tedious layer of deterministic (!) machine translation. It's offloading drudgery and busywork. What agentic coding is offloading is concept and understanding. Not even remotely the same ballpark! One is using a calculator when doing the maths for the structural engineering of a new bridge. Saves time, is more reliable, gives deterministic results based on the inputs of the engineers. The other is having an intern look up some numbers of how it was done for other bridges. It's unreliable, risks missing context, has an unacceptable error rate, nobody knows how to check the numbers because nobody knows how the heck they were jumbled together, and nobody wants to be responsible when the bridge inevitably collapses. How can anyone get the idea to even try to equate the two?
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?
Ben if you're going to blog about things with relative timestamps you need to provide a base timestamp, and I would also appreciate that for when you update the post. "3 months ago" is unhelpful without that context.
Well done for registering your beliefs publicly and updating them publicly. So many people out here exist in an epistemology-free zone.
I'm seeing what looks like a date in the top-right corner of the header banner. Not sure if it was added in response to the note, so mentioning just in case!
Do mathematicians and physicists put away the calculator and computer (this always reminds me of the last scene from Star Wars) and do the computation by hand? A physicist isn't going to manually invert a 10,000x10,000 matrix.
Exactly as we don't write machine code letting the compiler do that, now and in the near future we won't be writing high level programming language code. We are moving towards working on a higher level of abstraction.
When I ask a frontier model to write a loop 10 different ways in Python and TypeScript and test the performance of each using a 1,000,000 iterations, it isn't creating cognitive debt. For the time being, I'm still racking my brain asking the question, how does garbage collection affect the performance.
I feel like we're doomed to respond to these lazy analogies ad infinitum.
Knowledge abstractions have historically been built by people with a detailed understanding of a problem domain and with a period of vetting the abstraction by many people. That is simply not true with LLM-generated code. We do not really understand what techniques LLMs are using to understand directions, value aesthetic/legibility characteristics, assess tradeoffs, retrieve contextual information, generate output, etc. Embedded in everything LLMs do are small decisions.
If you reach for formulas that you don't understand the applicability of, you will similarly get bad outcomes! But a calculator has almost no resemblance to what happens when you give general instructions to an LLM and get a generated code back, because in between that prompt and the result are many layers of decisions you the developer did not make and likely will not understand without carefully assessing the output!
If you have no discomfort with being culpable for something and doing none of the work to understand it, by all means, don't do anything to understand the output! Don't read the code, don't re-type the result, etc. I have concerns that you'll have a job in a year, but that's your decision to make!
I don't have any delusions about that, LLMs are impressively good. But they bring with them a host of epistemological problems that I think we ignore at our own peril. A society that blindly trusts the output of LLMs to be good and to make decisions that adhere to our own preferences and acceptance criteria is extremely dangerous! There's a growing call to sort of let LLMs cook and get out of the way, and I think there will be catastrophic problems if we give in to that.
As good as they are, they are still fallible. They still write bugs, they still misunderstand instructions. They even get defensive about bad choices! And even in a world where that appears to no longer be true, we will be making society extremely fragile if we give an alien intelligence total autonomy to do what they think is right.
If you're not going to be writing code, you better be a vigilant babysitter. Otherwise I firmly believe that more than your job is at stake.
I've been asked several times how I use AI. My answer is - pretty much the same way I worked with developers on my team. I give a task, review the result for a reasonable amount of time - which might be close to zero for a minor front-end change - and then either accept it, change it myself, or ask for revisions.
That approach works well for me, so why would I retype AI-generated code? I wouldn't do that with code written by another developer, and their code can be just as buggy or weird in theory. You could argue that at least the developer knows how it works. That's true - for a week, a month, or a few years if you're lucky. Until he forgets or leaves.
I'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.
I share the author's sentiment. I also think it's important to fully understand a codebase I own. So much is naturally lost when you let LLMs generate code for you, and the mental model of what the added code does is one of the biggest losses. When you write code by hand, you build that model as you go, and it's enormously helpful later - when adding a feature, or when debugging behavior you didn't expect.
I've been trying to address this by telling LLMs primarily how the code should be structured, rather than only what it should do. Still, any design I hand to an LLM will be underspecified in one way or another (if it were fully specified, it would just be code), and the LLM fills those gaps somehow - which adds to the cognitive debt, slowly but surely.
Retyping LLM-generated code is an interesting solution. You'd certainly end up understanding the generated code better than if you merely reviewed it, but I doubt it produces a mental model as reliable as the one you'd build writing the code yourself. The longer you think, the better your mental model gets - and outsourcing the thinking to an LLM means thinking less.
That said, I've started to wonder whether I'm solving the wrong problem. Should I really insist on an accurate mental model of the code I own? We'd find it strange for a non-engineering manager to try to fully understand every piece of code their reports produce. If that's the right analogy, then as LLMs' agentic capabilities improve, maybe we should stop treating LLMs as tools that boost our own productivity as a software engineer and start treating them as independent agents we manage and steer.
Repayment here means that you eventually need to invest the time to understand the approach used and the code intricacy, to later fix or build upon IF you are to manually/artisanally (for a lack of a better word) go about addressing the issue.
...if you use AI again, then yeah it's a permanent loss.
Ask your AI to chart the data flow through the program. Not that that's a magic solution but it's a pretty good start.
By default, if you ask an AI to "generate documentation for this code" it generates the same broken documentation all the humans do too; an enumeration of all the modules in the code and what their API is. I'm not surprised, the training data is biased probably at least 25:1 in favor of this rather than the useful data flow documentation. Fred Brooks was complaining about this over 50 years ago and the discipline as a whole still gets this wrong.
I'm not saying this is a future solution to all problems, but it is a now solution to some problems.
3D doesn't help. We live in a 3D world but our vision is 2D with a bit of augmentation from a second view point just a bit away. We derive some depth information from that, but we don't really "see in 3D". To do that we'd need to be 4D beings. There's a lot less juice in the 3D squeeze than meets the eye.
This is really the distinction between the mentality of a technical manager and an individual contributor.
Managers never got to write and internalize every line of code anyway. Arguably their essential skill is producing useful stuff without needing to do so. So is that 'cognitive debt'? When I use an agent to code, I do the same things: I validate the direction, organization, and core decisions, but delegate the details. It's an intentional calculation of risk, managing the scope of future problems if there's a failure of implementation somewhere.
It's a question of where you put the value of cognitive focus. I don't understand 'line by line' how my car's ICE works, even though it will likely impact me at some point, because while I might be able to fix it myself if it breaks, the likely applied solution will be to delegate that work anyway.
I empathise with this. I run a little open source project called SmallDocs [1][2] which Claude/Coding Agent invokes to generate easily human readable Markdown documents (and render code files).
You can ask Claude to "sdoc me an annotated code walkthrough of this MR" and it will produce something like this:
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 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.
In the life of the LLM, we're still in the phase where we're all on the floor playing with these toys. It's strange to assume cognitive debt is an absolute outcome in this new paradigm of engineering when nobody really knows what the future holds. Personally, I feel like I have more time to think, not less, but that's also just my experience. Part of the fun of this is that we're all science experiments right now.
I'm just kind of enjoying the feeling of riding on the swell of a gigantic wave for once instead of feeling like I'm starting from behind it.
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.
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.
> 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.
Very much agree with you. My own experience with calculus specifically is that I would attempt a problem or example myself, then review the solutions and if I'm stuck, I would not understand a proof or solution unless I copy out every single line as the lecture/textbook and even add to it.
The act of slowing down to ensure every line makes sense to me is one of the most valuable things for my learning.
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.
> Taking down the lesson/lecture does relatively little
Not my experience.
> you can do it on autopilot
Huh, that sounds magically to me, I certainly can't. Actually taking notes down does the opposite, it forces you to get out of the autopilot, because you must think about the content.
Taking notes down, helps you learn better, because you use way more brain areas to process the information. Instead of just hearing, you need to hear it, understand it, try to rephrase it in your own words, use you motoric skills to write it down, and then see it and the placement of element on your page.
> we were given digital lecture notes anyway
Which you don't learn anything from, because by downloading you processed exactly none of the content yourself. Yeah they are way better to eventually search the information later on, if you already no the topic, but for learning you need to start with understanding it and structure it in your brain, which you would have already done for the first time, if you have taken notes.
> but there were no typed notes to start with so it was just out of necessity
The necessity was created by the teachers in order to get the students to learn. It didn't fell down from the sky.
> Or summarising notes in your words.
Which is what you do, if you take down notes. And that on a real time loop, so you can't slack down or miss something, because the information won't come again.
Fair enough. We all learn differently. For me, having printed lecture notes meant I could listen (imperfectly!) in lectures rather than focusing on copying. It was a revelation after years of exhausting lectures doing nothing but writing.
I now realise that sounds a bit like a contradiction. I said I could copy on autopilot but also I had to focus on it. I suppose it was more like the second one: I was so focused on copying verbatim (as furiously as I could as there was barely time to do it before it was rubbed out!) that I didn't have a chance to think about the content.
> > Or summarising notes in your words.
> Which is what you do, if you take down notes.
I certainly disagree with this. No one I knew was rephrasing the lecturer's notes in their own terms. There was no time for that. That is something you'd have to do in your own time afterwards, at a much slower pace.
> > but there were no typed notes to start with so it was just out of necessity
> The necessity was created by the teachers in order to get the students to learn.
I assure you, the main reason those maths lecturers didn't spend countless hours typing up their handwritten notes in LaTeX was not the best interests of the students!
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.
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.
Am I the only one who enjoys taking notes? But more in the sense of recording knowledge so that I have it in perpetuity.
For instance, I have almost completely forgotten how to solve ODEs, even though I had a good command of it when I learned it (by solving practice problems). In that sense, I wish that my prior self had taken good notes, so that I wouldn't have to dig up source material if I wanted to relearn it again.
Everyone likes nicely typeset LaTeX -- why not apply that craftsmanship to preserving academic notes?
It's not that I don't enjoy taking notes - I liked to take notes, distill knowledge, make "cheatsheets" outside of class.
To this day I still take countless notes when I learn new things, I just find it incredibly distracting to have to take notes during a lecture/class because it doesn't allow me to process the material properly.
>In that sense, I wish that my prior self had taken good notes, so that I wouldn't have to dig up source material if I wanted to relearn it again.
I don't really get it. If you've truly forgotten, you have to relearn it one way or another. What makes you think your past student self improvising a half-assed explanation in the moment could do better than a professional author who was already an expert when they wrote the book?
Because you never truly forget something. If you took effort to generate a rehash of your own mental brain model, first you will recognize it again and thus don't need to relearn everything, and second you already have it in your own brain model, instead of needing to invent it first from someone's else brain model.
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
It confused me at the time, mainly because I had a class with written-out C and one with written-out Pascal in the same semester. The Pascal prof wouldn't mark off for C syntax but the C one would would mark off for Pascal syntax.
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.
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.
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.
> 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.
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.
> It's like trying to retype calculus solutions — you don't learn from it
???
i entirely learned all the math and applied math by working through problems whether myself or copying down from the solutions manual or text book over and over again until it stuck
As time goes on, I become more and more convinced of this also. Also fits in with how many of us already learn via feedback loops - just now it's an LLM instead of a human giving you that feedback.
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 :)
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.
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.
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.
While your competitors ship out million-line software, you are going to write down the LLM code. This approach will make a software engineer homeless in a very short time.
From a marketing perspective, I do not agree. The competitors can claim 100 more features than your "lean" code. That by itself makes you lose customers.
> As I manually type every single line of LLM generated code into my editor, I build up a mental model of how it works and fits into my existing codebase. If I don't understand an API or algorithm, I can stop to look it up, or just ask the LLM to explain it.
This is part of how I learned how to code! Well, sans LLMs. Instead of copypasta-ing code blocks from books, Expert Sexchange and Stack Overflow, I manually retyped everything, looked up what I didn't understand and changed what I could.
What's the right middle ground approach to this? I agree that inevitably my more advanced software approaches at work have been compromised by reliance on LLMs, especially given encouragement from management. Are there specific prompts/instructions people find that allow for learning and iterative development without slowing down the actual development cycle too much? I want to keep learning and keep my skills sharp but it feels like a losing battle.
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."
I've had opportunities to look at code from Korean and Chinese companies, not just academia. From what I've seen, AI generated code is often better than the average code in those codebases.
When I talk about PhD level code, I'm not referring to research code quality. I'm talking about research level algorithms.
Production code is built around reusability, policies, monadic chaining, and various code hygiene practices. Research code isn't. So what I'm saying is: 'Yes, I've collaborated with professors from top Korean universities.'
That said, I'm not writing PhD level code myself. The reason is that I take existing algorithms and apply code hygiene to them. I'm not actually developing new algorithms at a PhD level of understanding
So from what you're saying, it sounds like:
'Are you talking about those horrible research paper codes?'
But what exists in those research papers is:
'The domain modeling itself is difficult.'
I learned about code hygiene in production code—things like using functional approaches, and so on. Research code often lacks those things, so it might look bad. But that means the code quality is bad—not that the modeling itself is bad. And in fact, the core value is in being able to produce modeling at that level of difficulty.
In fact, most programmers, if trained like me, can do these things well enough. But domain modeling is different.
This touches on the distinction Frederick Brooks made in The Mythical Man-Month between 'Essential Complexity' and 'Accidental Complexity.' Code hygiene, functional chaining, monadic structures—these are techniques for reducing accidental complexity. With enough training, you can learn them. But domain modeling deals with essential complexity. It's about how difficult the problem itself is, and it's not easily solved through training alone. That's why the depth of modeling that researchers produce should be evaluated on a different axis from code quality.
This is what we call 'Essential Complexity.' From that perspective, saying code is 'good' usually means that the essential complexity is handled well on average. What I'm calling 'PhD-level' usually refers to modeling problems that are commonly difficult to solve.
I see it 'very often.' Most research paper code has no reusability—they just implement the algorithm.
So I can see why it might be considered low-quality. They don't use things like Result or policy types like we do in production code. But they're modifying or creating new algorithms, right?
The thing is, they don't need to do those things, so it looks lower-level—but the algorithm implementations themselves are actually pretty good, aren't they?
PhD thesis code often looks low-quality simply because there's no reason to reuse it like production code. The tensor computations inside are things that typical programmers can't easily do.
The point I'm making is that the core algorithmic work is something most programmers can't handle. And that's natural—highly skilled programmers have already built deep libraries for that.
When I talk about PhD-level code, I'm not referring to overall code quality. I'm talking about the level of the algorithms themselves.
> there's no reason to reuse it like production code.
This strikes me as a self-fulfilling prophecy. There are probably many people who would like to use the code published with PhD level research, but they don't because the code is not easy to adapt (or sometimes even to get running).
Then a decade later someone implements that same algorithm in a library with a well-designed interface and it suddenly becomes a useful tool for others. So ultimately there was a reason to reuse it, it was the quality of some aspects of the code that held it back.
End-goal seems like making money in this line of thinking so I recommend spinning up some gambling racket or getting into finance, you don't need to program anyways.
This is specifically what people pumping these ideas are doing as you can see like Sam Altman or Dario.
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.
We’ve been hearing the drumbeat that these models are already better than $INVENT_A_NUMBER percentage of developers at $SOME_SMALL_TASK for several years. I haven’t seen that it’s actually true yet personally.
What I do see is that the frontier models can get easy stuff mostly right, but they can’t maintain a small codebase such that it behaves correctly across several mutations. When the going requires a lot of context, tests get rewritten to not do anything and features that manipulate similar data get divergent implementations. That’s fine for goofing around personally, but I see vibe coders getting their asses handed to them when they mistake that for a well maintained codebase and try to sell a product.
Please, don’t mistake an impressive technology for a miracle; there will still be people needed to make codebases healthy for a long time to come.
I hope you're right, but hope is not a process. I'm looking at the obviously exponential charts of capabilities and don't have much to add to that hope.
I'd say as long as we can clearly see the 5% are working better than an LLM, why not strive for it? Shows what humans are capable of, and it's probably achievable to most.
I'm not hanging my hat yet and can still see where LLMs struggle. I think it's the best bet you can make: keep working for the future where you'll still be needed, because you can't prepare for the future where you're not.
I agree about your general assessment, but I don't see my coding skills of, depending on how you count them two or three decades, being needed in 36 months - so I'm trying to upskill LLM piloting, but that also seems a bit of a dead end since LLMs will be perfectly capable of piloting themselves in approximately the same timeframe - we'll see what needs upskilling in by winter...
This reads like it can write a better javascript function that executes a SQL statement and maps the parameters.
> 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.
Basing this prediction on LLMs writing what something like an ORM would generate for you doesn't connect for me.
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.
Pretty crazy idea. I know I sometimes just "wave through the motions" when I'm taking notes.
For example, when I am reading a book, I often take notes of my favorite quotes/sentences/things that stick out or perk up my ears. Usually if I own the book or it's a used copy of mine I make a note of the page number on the very last blank page(s) and write out the full sentence/quote. Then when I go back months or years later I just open to the last page and can find all my favorite/important quotes. Most 200 page books typically have ~20 useful sentences for me to reference [going forward] - it's basically like making your own index or table of contents.
That long aside, just to say, if I'm not "very aware" or "consciously mindful" of what I'm copying down or writing, I'm able to do it very well on autopilot without etching anything into my memory -- as if no recallable moment gets etched into the wet cement of the brain unless I'm actively "hip to it." I wonder if others have this "autopilot" problem.
A better interface for code review would be a pseudocode layer that sits on top of all of your code, at the editor level.
Basically it would convert all of the chunks of your code using an LLM to simple pseudocode with clickable symbols so you can follow function calls, definitions, then you could expand/collapse it to see the real underlying code.
It's easier to skim pseudocode than it is to reason about complex logic. When I say pseudocode I'm talking very high level but structured explanations, and less the sort of traditional pseudocode you'd imagine which is basically just a generalization over syntax.
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.
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.
Agree with this. Small steps towards the feature. Review, iterate, learn and optimise as you go.
If the project is a mountain, I want AI to assist with the climb so I can learn the mountain, its trails and details. Hitching a free helicopter ride to the summit would leave me with little understanding about the mountain other than the view from the top.
I don’t know it feels like some og programmers would say the same thing about people who can’t program machine language
Code quality is only going to get better and to be perfectly honest learning how to get the llm to generate quality output is IMO time much better spent vs some misguided attempt to do something by hand — the prompting is the better skill to develop at this point and if you’re worried about atrophy it’s probably your least developed skill
Instead I focus on reading the plan and making sure I understand it, opening up a second session for second opinions or questions if I have gem
This obviously depends on where in the stack you live but code quality is accelerating at a significant rate - decision making not as much and it’s where your value is imo
I 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".
Few will remember this is how programming started for many, including me. Wait for that issue of Family Computing to show up, so you could manually type in the program for that Turkey game to run.. Appreciate you bringing up the good ol' days.
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.
Today I added a temporary data source to Prometheus to help me monitor a system closely during a tricky ops task. I would not have done that except that the LLM gave me a small script I could quickly check and immediately use. Without it, I'd have roughly spot checked the service via "tail -f".
Our company's policy on LLM use is: use it, disclose it, and take responsibility for the code you commit.
There's no way that typing that tool back in would have done anything useful for me or my organization.
>Typing the code myself forces me to slow down, which means I'm more likely to detect hallucinations or bad design choices the LLM might have made.
I think this depends on your level of expertise with the task.
If I'm writing a language I am extremely familiar with and so second nature to me, for example SQL then I can instantly read llm code.
But if a new language or a new piece of software then llm generating huge amounts of code can make it difficult to improve yourself and also manage the quality.
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.
+ let LLM generate just scaffolds, skeletons
+ do not let it generate code (let it generate leading questions instead of answers)
+ let it test you (try learning-opportunities repo from CatHicks)
I was working on a VS code extension that integrated with claude code to show an overlay for the changes instead of the edit tool calls so you could write everything yourself. The idea was that even if you type 100% of the same code instead of making your own changes, it would still mean you go through the code yourself and have a better understanding that you would have on just skimming through the generated code. Maybe I should start working on it again.
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?
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.
Fair enough... I think it really depends about what dependencies we talking about.
NPM decencies is a bit of dumpster fire, supply chain attacks galore! A well known python (think numpy) certainly is less discomforting, and a "industry standard" C library like GSL or SDL3, I just use it and move on
Generate code using LLM on a small project, then copy manually toward your big project. This reduces the context (and the cost) for the LLM and gives you many small projects where you can experiment ideas with more agility.
"... I don't enjoy reviewing AI-generated PRs. Poring over hundreds of lines of overly-defensive, badly-commented, subtly incorrect code is not fun. I might grudgingly do it for an employer—while making sure said employer becomes an ex-employer as soon as possible..."
I don't know about where you work, but in my neck of the woods if you want to be employed you will be reviewing AI PRs, there is no escaping that.
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.
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.
LLMs don't understand a damn thing. They can't. They're not built to.
An LLM doesn't "understand" its own slop. It can use that slop as further input for generating more slop on top of it, but at no point of the process does anything like a concept or understanding come in.
I’ve got similar concerns about skill rot, but I also have chronic RSI and some hand arthritis. LLM assistance plus modern voice models are a godsend but it’s not the same as typing every character. But I can’t really type every character anymore. I can read it all but…falling into skimming is very hard to avoid.
So I’m grabbing the double-edge sword with my bare hands hoping to stay ahead of the brain rot…somehow.
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.
So I always make sure I take a crack at doing what I want first. Then I ask for an AI review and it usually has a more efficient way to get the job done.
For example I had a working linear decay velocity boost function added to a godot scene and it's suggested refactoring actually reduced lines of code just today. So kind of happy when that works out, but yes I also applied the changes manually so I would grok them and hopefully remember it better.
Same idea with Stack Overflow solutions before that.
But I don't just retype that code verbatim, I rewrite it in my style, add or remove comments, add or remove some checks, sometimes even tweak the algorithm. I want to own the thing. Some copy-pasting may be involved, I am not trying to improve my typing here, but the important thing is to understand every character of it.
Right ... While we do that, let's also retype the assembly code the compiler produces, do the linking manually and check you got the same result as the linker, and then finally write the bytes yourself. Whether or not you manually bit-bang à la Morse code the bits to storage is left as an exercise to the reader.
While I agree on some level, this not a great comparison.
A compiler/linker/etc is an algorithmic, precise, verifiable, repeatable, debuggable, etc, etc, process.
Using an LLM is an inherently stochastic process. It can is very, very helpful, but I think we are arriving at the realization that "vibe coding" wasn't the best idea - unless you are doing a PoC or demo.
In any case, neither absolve you from understanding in detail what is going on.
Maybe we'll get there, and we can fully trust what the LLM produces, but it seems we are not quite there, yet. Until then we'll have to understand everything the LLM produces and that's what the author is getting at.
Retyping LLM code sounds absolutely miserable and soul crushing. Like hand copying the HTML produced by page generators... why would you do that to yourself.
In highschool, my history teacher's home work assignments were to write out the notes he created and handed out for us. Essentially the assignments were to read chapters from the text-book, then copy the notes by hand and hand them in. It seemed odd. But I think their is some wisdom to it. As you writing it out, you are slowly reading what you are writing... even if you do not mean to.
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.
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.
I don't manually retype the code from pull requests of other engineers.
It's important to retain the what why and how as a team to the degree that development can be efficient, extensible, and maintainable. (And ideally a good devx)
Needing to manually touch every line of code is not scalable.
This was true 10 years ago. It's still true today.
Thats nuts. You are fighting a tool that is supposed to offload that. Is like lets not use the power tool, but do it by hand so your muscles won't atrophy, but you should instead use it to free up your muscles for other tasks like better requirements, architecture, tests, UX design.
I do something different, I type everything by hand and have AI provide feedback.
It's one of the best ways to kickstart projects that have intrinsic software complexity as you get your hands wet into the design tensions and constraints early.
To be honest I am thinking of an entirly different situation, ask the llm to create Red tests for you. Then implement them yourself. You don't waste time writing tests but you still need to spec what you implement properly so the llm can write good tests for it
This is really good advice that I've found to be true, especially if you have autocomplete turned on. At the same time, I'm privileged enough to have a fast typing speed and anything less than 60 WPM would make this practice very annoying. Thank you for sharing this.
Seems like an ok solution, but what about doing something like the opposite? Write out the scaffolding and general shape of the code (classes, interfaces, function signatures), and have the LLM fill it in. That seems more important for understanding.
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.
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.
Hah I was just thinking I should switch to colemak that I only let myself continue with for 2 months and re-type out all the domain (types, etc) for this project I'm working on
I simply never ask LLMs questions specific to my codebase (except for finding what function/file does something, because that is annoying), and instead use generic questions.
You do that enough and I bet you'll be labelled "the slow one" in certain circles, so before attempting that as a junior make sure you have some measure of protection.
I got made redundant shortly before the release of LLM code generators, so I've never used one, but I did occasionally do this for short snippets from tutorials and suchlike.
I ask the LLM to generate the code but mask the last token. Then I do softmax and give it an answer. Pretty soon my perceptrons are more connected than ever.
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.
that's a great approach, the bad thing is that (at least I) will forgot my codebase anyway after two more projects. so i'm wondering if it worth the effort. i prefer to impose my vision on the code upfont and then rapidly check the my vision is respected rather than understanding every single line
I still write lots of code. And there's still a lot of code for the LLM to do. I prefer comunicating with an LLM in terms of code, having it grounded by code that I have already written, it can be a function signature, a struct, an interface, a trait, the skeleton of a test suite. It can even be a sequence diagram in mermaid, but I refuse to let it go.
I stubbornly refuse to let the LLM design. I can discuss my design with it, I can even completely discard it, but I am not fucking writing reams of natural language.
And know what? I don't think I am less productive than my "looping" colleagues, because, well, code is way less ambiguous than natural language, a validation rule in code can usually be expressed more economically in a programming language than in english prose. It is easier to create a directory and file layout, sprinkle some declarations here in there than it is to EXPLAIN how the flow of dependencies go. It is easier for me to create a hook because I want users of a certain module to be able to change its behavior without having to change the source of the module than explaining the OC principle to the LLM and seeing it miserably failing to apply it, because it doesn't have a theory of what it is fucking doing.
And as a side effect, when the 30th day of the month comes, and all the company tokens for the month are used, I can still be productive while others wait for the CTO to negotiate a couple tens of thousands more in API with the CFO.
This is not slightly comical, it is very comical. Side projects are not mandatory, if you are using them to learn something, asking LLMs to generate and for you to type it makes no sense - just do it on your own. If you want to offload tedious boilerplate part to LLM, then by definition no need to learn it as it is tedious, so typing it out is useless.
this is how I did "AI coding" (for unfamiliar languages/frameworks/etc.) back in the GPT-3.5/4 days. Except I'd also test each line to verify it actually did what I thought it did.
I don't think it's possible to eliminate cognitive debt when using LLMs, but you can definitely minimize it. Part of this means recognizing that you will only get, say, a 2x productivity boost instead of a mythical 100x increase, the benefit is, you'll actually know what you're doing versus being a brain addled zombie.
First, use the LLM to understand the problem thoroughly. They can be great research aids. I've speed up tons of learning using LLMs. It is essential you ground the discussion in existing texts or code. Ping pong with the LLM asking it to challenge your understanding, how you direct citations for explanations, clarify things, etc.
After you've understood, plan. Develop a plan with the LLM/agent by steering it hard. Read the slop text thoroughly. Give it direct feedback. Don't proceed until you have a complete expectation of what you think the agent will do when implementing the plan.
Let the agent do all the implementation.
Review the agent's work. Again, engage with it and leave direct feedback. Ask for clarification and alternatives if needed. If it was totally off mark, start the process again.
You won't be moving at warp speed with this approach but you'll know a lot more than the one shot prompting loop cowboys out there.
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 much either.
When you are/were developing software without AI, even for pretty large projects you do end up internalizing (memorizing, but not deliberately so) a lot of detail, but from my own experience I'd say it's more the design than the code. The design is what you put effort into, thought about, etc, so is both what you naturally end up memorizing, and is what you need to know to have a mental map of the project and therefore understand how best to modify it. The code itself was naturally always the last thing you did, and followed automatically from the design and module/component interfaces - not something you typically think much about other than while in the flow of just "coding it up".
By retyping LLM-generated code, it seems you are mostly going to be gaining familiarity with the wrong thing - the code and not the design. Memorizing the code is not going to help much in grokking the design.
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.
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.
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
> I fear the software industry is taking on a large amount of cognitive debt that we'll have to pay back very soon. There will come a time when we no longer understand how large parts of our digital infrastructure are put together. I might not personally be able to change the course of the entire industry, but I can at least make sure I completely understand the software I put out into the world. Anything else would be professional malpractice.
"professional malpractice" LOL. This is so dumb. I can't believe this shit is getting upvoted.
Just write the code. This weird obsessive dependence on LLMs doing everything will ruin you as a developer and prevent you from progressing in the industry when the AI bubble/fad pops.
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?
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)
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
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!"
Seems like a much better idea would be to build it yourself first, then have the AI do it for real? If you don't understand what you're building, you're going to get a lot of surprises when you re-type the AI-generated code and realize it subtly mistook your prompt or made decisions you didn't think to specify.
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.
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 don't understand the concern about "cognitive debt". I frequently have to maintain code I wrote, or someone else wrote, weeks/months/years ago and I have NFI what's going on. Now I say to the LLM "tell me what's going on" and it tells me. I can ask it some follow up questions, and build up my understanding. It's SO much faster than grepping through the source myself and I can do it for as multiple issues in parallel. The notion of reading every line of code is absurd to me, the notion of RETYPING it beggars belief. Surely this is satire.
In my current workflow, I've settled into a three tier system when coding:
1. HIGH-VALUE CODE:
I write it all myself. I will occasionally use AI for mostly mechanical changes, like cleaning up variable names or mass-changes when a function signature has changed. Either way, every line is read carefully. Sometimes this means isolating my high-value code as a library in a separate repo. Usually it's just a note in AGENTS.md, or even a well-written comment at the top of certain files. I'm not obsessive about it, though, as it can't hide from git. And learning what it's trying to change is sometimes a useful insight.
That doesn't stop me from using AI as a consultant. This is the one time I'll use a beast like Fable. Ask it to write a technical/security analysis on a section of code and damn it can pull out some impressive insights. It can't write new code particularly well, but it can inspect code like a boss. But that all stays in the chat window. (And despite being so infrequent, they ends up costing significantly more than all my other AI costs combined!)
2. BOILERPLATE/PROCEDURAL CODE:
I'll write the first draft, but once I've set the tone, I'll allow AI to build and maintain it. I keep on top of things like a senior manager, just to make sure it's not doing stupid things. Every few days I tell it to mow its own grass: AI is good at recognising its own stupidity, you just need to give it an opportunity to look.
3. TEST/HARNESS CODE:
Bring on the slop. If I get nothing else from the AI revolution, it's not having to write another stupid test unit. Nothing makes me happier than setting the AI to work writing every permutation of test I can think of. I will slop this code all day, and I won't read a single line of it. Why should I? If I ever doubt whether a particular test is correct, I'll test the test by breaking the code, not by reading the test. But I almost never catch it out. In my experience, AI is especially good at writing tests. Perhaps more than anything else.
Tests don't just take the form of a few mocks and props in a test harness. In one recent case, my project involved writing a library for the API of an obscure commercial microcontroller-powered device. I took the API documentation and made AI build me a complete simulator. I then made it write a full suite of tests using my client library within the test code. I then got it to run that test suite against real hardware and identify any inconsistencies. From there it could recursively modify the simulator until it became unreasonably good at mimicking the real hardware. I haven't read a single line of its code. But it's now core to the library's CI.
I can't reliably confirm that you read my post all the way to the end. I pointed out multiple ways where tests are proven. One is to verify the test by breaking the code under test. Another way is to build a fully independent, highly complex test rig that would never be (commercially) feasible without AI.
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.
But if the code base is constructed in a way which results in strong test suites (human driven), quality evals, robust documentation, and modular implementation, will the human really lose that much context?
Given that those things are checked off, I am having a tough time believing a frontier model, in conjunction with a new dev on a project, can't be immediately valuable to determining what is going on in a repo.
As someone who’s been programming for 20 years, I have to say that programming itself often causes a kind of brain rot. I’m very glad that I can now focus on other aspects of software development. It was only with Claude Code that I realized I never actually enjoyed programming—I enjoyed building things. You can live a perfectly mentally healthy life without programming.
Fully agree that programming for me brings along "a kind of brain rot". Hard to describe, but working deep in code just shifts the mind to a state that's ... less open, more focused, more obsessive ... and seeps into daily life.
Vernor Vinge's concept of "focus" in "A deepness in the sky" really clicked with me and put into words what I'd always had at the back of my mind. A highly recommended read.
I read it because Elon Musk mentioned it as a favorite. It’s a good book and you can see how the concept of controlling ubiquitous tech is a thing he tries to do
How do you mean building things? To be honest, I don't get excited about most products that I'm working on - that is what the money is for. The enjoyment comes mostly from technological problem solving.
I get excited for the things I built. I built them for my clients and I love that clients are genuinely happy with what I built for them. And then I send an invoice which is followed by a payment. I love that too, I love both.
I dont't love doing some obscure integration of an API that should have been dead years ago but somehow still lives. I don't like squishing bugs because something doesn't work when the Sun is in the third house of Uranus on February 31st. Those are technical problems I don't like solving.
My point is that you and I both love something else and that is totally fine. But I'm not sure if you can keep making money with only solving technical problems.
I would say any programmer has found themselves so deep in the metaphorical woods that they forgot what they were actually trying to achieve in the first place. For example, you start because your boss told you to implement a new feature, but you realized there was no module you could place the feature in, then by looking at the existing module structure you realized it had become completely unsuitable in general, then you started trying to split some and rename others, then you noticed a circular dependency would appear if you didn’t add a third module between two you just split, and now all you can remember is that you’re fixing the circular dependency. The feature you were supposed to work on is a vague memory now.
I think this is a sort of brainrot which explains why a lot of times things take unjustifiably long to implement. LLMs can help so much with stuff like this if you know how to yield one. But it can also let you more quickly hang yourself if you don’t even care about “which modules even exist” ( to continue with my example).
That's called yak shaving.
No, it's called not throwing more shit at an already shitty wall just to add feature x_2.
Programming, as in manually typing the code, is a means to an end.
While I do enjoy coding, building things is what was rewarding, not actually laying down brick after brick after brick after brick.
I've done that for 10+ years. The fact that I don't have to do that anymore is a relief that cannot be overstated. I only have to check on the code that The Ideal Intern produces while I focus on what actually matters, and that is: Building The Thing.
It's all about how you use it and how careful you are with it, and the fact that today there are people IN THE FIELD that still question this baffles me.
> It was only with Claude Code that I realized I never actually enjoyed programming
This is so real!
20 or 30 years ago, programming was reserved for people who were truly devoted to it, even when the work was a nightmare of difficulty.
Now, when I talk to programmers in their 20s and 30s and ask which program they first fell in love with, there's usually no answer.
I'm glad they've stopped pretending otherwise.
Nothing really wrong with that though. The amount of tech used by the average person has also increased dramatically in the same time period.
You could argue the same has happened for computer use in general or for many things.
They fell in love with the money.
Good for you! Personally I'm not so much interested in building things. On the other hand, my ideal life would be to make a computer do new cool tricks all day.
[flagged]
> Poor coders have always existed. You're not the first and won't be the last.
Did you get so emotionally hurt by another person saying they didn't want to actually type code anymore, that you felt the need to tell them they're likely a "poor coder"? You can still continue to type code if you'd like, no need to put others down because you prefer a different way of working.
Sorry, I'm not here to talk about your feelings. I am not "emotionally hurt", nor should you be. This is HackerNews and you're a grown ass adult (I assume). If you disagree with me, then feel free to outline your disagreement, or just ignore and move on.
> then feel free to outline your disagreement
My disagreement comes from feeling the need to put others down because they said something you didn't like. Nothing in their comments talks about if they're a good/bad programmer, clearly your putdown comes from a place of hurt. But no worries, lets ignore it from now on out, hope it gets better for you mate!
Are you sure ejaculated is the right word to use for that
Why would it not be
Yes. Why not.
yes, it also exposed lots of hidden talent, which is more important. and fakers are nowhere to go, but LLMs are indeed a litmus test for them.
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.
Also... if your workflow is "think hard, let LLM write it, read what AI wrote, think hard about what AI wrote, re-type what AI wrote, fix what AI wrote"...
Where in the heck are the efficiency gains? Couldn't you just drop the LLM part of it and save the company a trillion dollars in tokens?
LLM speedups have always been predicated on not understanding the code they produce as well as if you wrote it yourself. Reviewing even well written code to understand it in depth, has always taken longer than simply writing it yourself - let alone sloppy LLM code that you have to fix
People are, in heavy LLM systems, realising that the most valuable commodity is engineers knowing WTF is going on, and that loss of understanding of your codebase is the #1 blocker to actually getting things done. Any senior engineer knows this all too well
Its why I suspect we never tend to see any longer term LLM productivity stats being published, and why I extra suspect that LLMs have failed to achieve any kind of penetration into open source code. If you take away the pressure to produce bad code, writing by hand clearly wins massively in the long term. Its classic short term gains for a long term penalty
> the most valuable commodity is engineers knowing WTF is going on, and that loss of understanding of your codebase is the #1 blocker to actually getting things done
Perfectly said. It was true before LLMs too.
As I've been reviewing more and more LLM code, I've noticed that while good developers can use LLMs to produce good code maybe 1x-5x faster (depending on circumstances), bad developers can use LLMs to produce bad code 1000x faster. And if you are collecting metrics that only capture that 1000x number, I bet you feel great about what you're doing.
> People are, in heavy LLM systems, realising that the most valuable commodity is engineers knowing WTF is going on, and that loss of understanding of your codebase is the #1 blocker to actually getting things done. Any senior engineer knows this all too well
I've been pushing against this "maximum LLM driven speed" in our infrastructure as well and been working on a middle ground:
We can generate a change to Ansible or terraform code in half or a third of the time, sure. But we don't use this to make three times the changes in the same time frame. We rather use the freed up time to discuss the change, the context and the affected systems with 2-3 engineers maintaining them. And yes, at times this means us three are sitting around half a day discussing and drawing diagrams about our systems.
I'm just happy to work in a company understanding the value of speeding up less than we could in the feature direction, but investing this time in the direction of control and understanding of the infrastructure.
Yup, this is how I see teams who care about quality, design and architecture seems to use LLMs, not to "produce more and faster" but to retain same speed but with a lot more confidence and reliability. Hoping this will spread eventually, some companies seem to take a more... hazardous approach to the whole thing.
"""People are, in heavy LLM systems, realising that the most valuable commodity is engineers knowing WTF is going on, and that loss of understanding of your codebase is the #1 blocker to actually getting things done."""
Very much this. It is also true for non-LLM code bases. I still remember my first job at a company with a bigger codebase than my typical "university project code base". It was a full fledged ERP system and just learning the lay of the land and understanding what lives where and why took quite a bit of time.
Interestingly, I think LLMs can be used for this "self-onboarding" and codebase-browsing/understanding. I've experimented a bit with treating an LLM as a guide of a bigger codebase it has "ingested" and having dialogues about it. Works reasonably well, I'm curious if there are companies out there that use this approach.
> LLM speedups have always been predicated on not understanding the code they produce as well as if you wrote it yourself. Reviewing even well written code to understand it in depth, has always taken longer than simply writing it yourself - let alone sloppy LLM code that you have to fix
I am at least 3x more productive by letting an LLM write my code and I review and understand every single line it writes.
Also, Fable 5 came up with some amazing solution and designs that I would have never been able to do myself.
I can say with 100% surety that my current project at work is MUCH better with an LLM compared to if I wrote it myself.
> LLM speedups have always been predicated on not understanding the code they produce as well as if you wrote it yourself. Reviewing even well written code to understand it in depth, has always taken longer than simply writing it yourself - let alone sloppy LLM code that you have to fix
I don't think this personal opinion holds well when contrasted with reality. The truth of the matter is that in moderately large codebases, which is the norm in any production setting, at best you have a T-shape understanding of the system: in specific areas you might have somewhat deep understanding, but for the vast majority of the system you have at best a high level understanding of the software architecture.
This is why software engineering frames things like design patterns, principle of least surprise,single responsibility, etc as premium design and code quality traits: they allow developers to effectively extrapolate their high level understanding of the project onto components they know nothing about.
In any software development setting,you will find that the most successful and even senior engineer is that which successfully and skillfully manages this uncertainty, and is able to hit the ground running on environments they never touched. I had a colleague who once was a senior software development engineer at a FANG that mastered this art, and called it JIT onboarding.
So why are you pretending this is something new or novel?
I think this blend of criticism only serves to allow inexperienced developers to stand out by complaining that a very mundane aspect of working on projects as a member of a sizeable team is somehow a novel development caused by LLMs.
And don't get me started on the "slop" nonsense. Have you actually browsed through code written by people?
Thank you for writing exactly why people who complain about LLMs making it harder to understand what’s going on are so off. Nothing helps more than asking LLMs to tell you exactly what’s going on! They are insanely good at that. I wrote the plugin system in my product, but many people added to it over a decade and today I have only high level knowledge of it. But if I need to know something about a very specific part of it, I ask Claude and now I know exactly what I needed to know. I could even write the code by hand now, and sometimes I do for the fun of it, but Claude has just explained to me, so it also knows exactly how to do it so why not let it do it?? I can understand as much as I need to by reading the code , asking questions, carefully analyzing the tests, much more than I would if I had needed to focus on every single detail that is irrelevant to the task. Sometimes I even do some minor refactoring just to try and feel like I’m “inside” the code as I used to. But I know I will likely be out of the loop again in 3 or 4 years, as I just can’t remember everything I ever did. But now I have a LLM ready to help me get into it again whenever needed again.
>So why are you pretending this is something new or novel?
Because as the OP of this thread and LLM users are rediscovering, that understanding is the most critical part of software development
>I don't think this personal opinion holds well when contrasted with reality. The truth of the matter is that in moderately large codebases, which is the norm in any production setting, at best you have a T-shape understanding of the system: in specific areas you might have somewhat deep understanding, but for the vast majority of the system you have at best a high level understanding of the software architecture.
I suspect a lot of people haven't worked on a system with engineers who've been there for 20 years working on it. There's simply no substitute for that kind of deep institutional knowledge, and it'll take you 5-10 years to be as productive as them simply because of that level of extreme knowledge about a codebase. It isn't as sexy as swapping jobs every 2 years though, so you have to go outside of the big tech bubble
I will say that yes, sadly, I have browsed through code written by people, and sadly also have browsed through code written by LLMs. Who do you suppose wrote the code the LLM was trained on? Divinity?
I'm being tongue and cheek, but as someone who uses these things extensively in work and personal projects, I want to point out that it's new or novel that generating lots of plausible code is now vastly cheaper than it once was, so the scales are quite different.
And yes, slop is an apt moniker for something that requires lots of careful prompting and configuration and guardrails (which is extremely sensitive to small changes in these initial conditions in ways that can be fairly nonobvious) to produce something that will in most cases read at least a little bit worse than if a human had written it. And it will still go off the rails sometimes!
To be clear I don't really agree that typing out the code generated by LLMs is a reasonable counterweight, it largely defeats the purpose. I agree that at a certain point you have to treat parts of your code base like a black box and enforce modularity. But this is still nontrivial, especially in more specialized domains with lots of nuance
> I will say that yes, sadly, I have browsed through code written by people, and sadly also have browsed through code written by LLMs. Who do you suppose wrote the code the LLM was trained on? Divinity?
Training is a red herring. The root cause is constraints, or lack thereof. If you lock a junior dev in a basement and force him to deliver the same features that these LLMs output, you will see exactly the same type of slop. The root cause is that junior devs are inexperienced and oblivious to best practices and guidelines and even the team's internal standards. They output code unconstrained by these guidelines and thus output big balls of mud.
> I'm being tongue and cheek, but as someone who uses these things extensively in work and personal projects, I want to point out that it's new or novel that generating lots of plausible code is now vastly cheaper than it once was, so the scales are quite different.
I agree, but we need to be mindful of what is the actual root cause. I argue it's not AI coding agente but the diverse source of these code changes, which we also see in production settings in projects managed by large teams. In teams manned by junior devs you see very much the same slop building up to a big ball of mud in a few iterations. This is nothing new. What changed is that now ai coding assistants grant everyone access to what amounts to a large team of junior devs.
I've found I can get quite a bit of use out of it as a basically ever-present rubber duck.
Using a cheap model, I usually spend < $1-$2 per day (on API billing) using it a model like.
- here's the problem I'm trying to solve:
- here's my initial plan for the design:
- is there anything I'm not thinking about or my plan is missing?
It'll occasionally pop out a suggestion that I like more than my original plan, or it'll give me some new angles to think through the original plan.
I’m guilty of using this approach too and noticed that an (obvious?) side-effect is that I get fewer wonderful, human, “aha” moments with my colleagues.
I mentioned this at a stand-up and only then did others think about it and notice the same of themselves.
This, to me, is one of the major downsides of all this: less collaboration, more individualism
I think that's true. One caveat: If you're a solo coder like me, you almost never get to talk about implementation details with anyone who (a) understands or (b) gives a flying fuck. I'm more likely to have a meaningful convo about code structure with someone on a laptop sitting next to me at the coffeehouse. So sometimes a stand-in bot to bounce your ideas off of can illuminate corners you're missing, even if it's in some ways no operating just as a chat with yourself.
> This, to me, is one of the major downsides of all this: less collaboration, more individualism
Or put another way, it's replacing collaboration and human connection with your team with a subscription service that isolates you, makes you emotionally and cognitively dependent on the service while making your performance numbers look good. I really don't like the sound of that.
I worry about the finger-on-the-scale mean-reversion aspect of this .. the LLM corralling you ever so gently back towards the median.
otoh, LLMs really could become the great illustrated primer for educating kids in science / history / languages etc.
Isn't median code often a good thing in terms of ability for others to understand it?
Yes, but also not necessarily good code(according to some). A lot of people don't buy into the "code should be optimised for reading" stuff.
Well, the objetive right now seems to be other LLMs understand it.
> Where in the heck are the efficiency gains?
It has been the opposite for us. It is now being weaponized by PMs and leads to add more work for developers and not less in terms of documentation and sign-offs.
Now stories automatically have additional 10 subtasks for documentation and tracking. These are created automatically through "skills" and the task of detailed documentation and updating those extra tasks is a chore. When complained, they just say "use AI". Every JIRA task these days feels like submitting a petition to the government bureaucracy.
PMs are happy because they did something new, leaders are happy for more tracking, developers are expected to be happy with "productivity gains" due to not having to write much code.
I stopped writing code completely about a year ago, stopped reading code completely about 8 months ago, and I feel like I stopped thinking hard about anything at work about 6 months ago. To clarify - I still produce code for a living - all day, every day. Not sure about efficiency gains but I got promoted 3 weeks ago :)
The LLM is, in many ways, smarter than you and I: it can perform feats of advanced mathematics that have eluded mathematicians for decades. It's not at all unreasonable to think that an LLM could produce an idea better than you could have, but that reading it and typing it in gives you some better understanding of how it works.
knowledge, by doing that I retrieve the knowledge from LLM, I learn faster, write code faster, do things more careful... The efficiency is the better design, better code quality, higher test coverage, less bugs. Because LLM let me gain knowledge faster than previous tools.
Besides, many companies proactively punish doing anything not by LLM.
in code you do not care enough to read, in experimental code, one off things, tests, reading a codebase with no documentation, re jobs
> Where in the heck are the efficiency gains?
I think there's some confusion in your post. You're seeing people claiming that the rate their code changes is so fast that they find it hard to keep their mental model up to date and in sync with the actual codebase. They frame this as a LLM issue, but those of us who worked in large teams will understand how it feels to be faced with a dozen changes popping up in critical areas of a code base each time we prepare to submit our own code change.
Once you understand this, you'll easily understand where all the efficiency gains are manifesting. Today's lone cowboy developers are experiencing the same type of struggles to keep up with a project that in the recent past affected projects worked on by large teams.
I mean, think about it for a second: what do you think is behind this higher rate of change?
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.
Haha, your analogy reminds me of one I often make to highlight just how much we undervalue fossil fuels.
Imagine filling your car with $1 worth of fuel and then driving it on flat terrain as far as it will take you. Now get out and push your car back. Friction and momentum aside, that's the astounding amount of energy/work we get from a dollar's worth of fuel.
Now imagine your car is actually an LLM model. It gets you a great distance on $1 worth of tokens but what happens when you run out and for whatever reason (I can imagine quite a few) further LLM use is not possible. You have to push your car/LLM back all by yourself to finish what was supposed to be a quick, convenient trip to the grocery store. Might've been better off walking.
Seriously though, I do think there is a real risk that LLMs are going to lure a lot of people far beyond their ability to swim back. It might even be the case that LLMs help strand people in situations that even the LLMs can't help rescue them from.
I've gotten into a situation multiple times where an LLM (usually a low-end free model) will write a whole bunch of code and then be unable to make any more correct changes to it because it can't hold enough context. Super easy to get into a duplicative spaghetti mess - exactly like I've seen human developers do countless times, but even worse.
I agree with your point, I found it makes more sense with the company when they have a problematic product no one can fix.
Ah, I agree with they way you reiterated that, that wasn't my initial read but it makes sense now :)
Of course I push my car to the store! It has the GPS and I've lost the ability to self-navigate. Plus, how else could I carry my groceries.
:)
If a computer is a bicycle for the mind, perhaps LLMs are the cars for the mind…
If a computer is a bicycle for the mind I think LLMs are a unicycle for the computer..
That’s my own personal take on it anyway.
Intriguing. Like the computer instantiated a wheel and rolls off by itself, no humans needed?
No, in that it's something inherently much more unstable than a bicycle and needs a trained human onboard to have any hope of getting anywhere without falling over spectacularly
Managers famously get dumber but think they get smarter and then start to write army metaphors.
lol
Unfortunately coding is a perishable skill, unlike walking which is at least partially ingrained into our DNA.
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.
> Don’t good generals know how everyone else in their army does their jobs?
They most certainly do, but on a mid-higher level. They don't probably know every single motion and definitely lack hands-on experience. But they know enough to be able to manage them efficiently.
y'all have to come up with a better argument than "LLMs are cars"
Try doing the same things now without an LLM.
I know another thing that gives you the same (fake) feeling: Cocaine.
Show us what you've built, general.
So we are reduced to code monkeys mindlessly re-typing what an LLM wrote to increase potential understanding...
Whatever this approaches, it is not a state of software engineering I find desirable.
I think this characterization misses the feedback loop that exists.
The OP is not sitting in a one-way flow of info:
but rather a the center of a feedback loop: Human-is-the-loop, not human-in-the-loop. Each iteration of that loop is fully driven by the human. Human creativity is involved in both directions.I'd argue that anytime we drive an LLM through more than one turn (and/or more than one session) we are really doing a human-is-the-loop thing. The OP's extreme case of begin the only thing editing code is on a spectrum with the other extreme being vibe coding (never looking at output code, but still interacting with that output in some way).
Off the spectrum is what I call LLM-vomit. A human one-shots something and puts it out for others to see, suffer and clean up or ignore. This is code that is encountered literally out of context and can only be further improved (if that is even attempted) by approaching it from first principles. Such code is akin to people using LLM to generate an answer delivered to another human. Both flavors (sorry) of LLM-vomit are bad. I can prompt my own LLM to do that, don't do it for me.
I think some sort of visual paradigm is where we will end up. Something like Star Trek, where the system architecture and modules are visually represented in 3D space, and you see how the organization changes with realtime low-latency animation representing the changes as they are made. So you are still in control but just at a higher level. I see some prototypes and weak implementations of this sort of thing but surprised at how little is out there.
I kno you're not suggesting the visual system would drive coding at all or that it'd be a way to visually code (see: scratch). You seem to mean it as a visualization of the current code base. I'm hoping Google's code wiki is the first step in this direction. One thing I always thought was a problem with visual systems like this was understanding the codebase's architectural design at a level yu can't programmatically get out via a syntax tree analysis. Google's code wiki seems to be using an LLM to figure out the high-level structure of the code and then building the flowchart and diagrams from that understanding. Obviously there's gonna be issues and misunderstanding but I think that's the first step in the direction you're talking about. First it's text, mermaid diagrams and 2d. Next it's a 3d visual world of your codebase. AWESOME stuff. Someone @ Google.
The problem with all existing GUI coding system is that they make it really hard to make anything other than the types of things they were designed to make. You could do it, but you have to leave the path and get into the weeds of how the system works, which usually has several layers of opinionated code structures on top of the underlying language it's compiling to.
An AI visual/GUI coding system might be able to address that at a more modular level, but it would still come at the cost of transparency and reproducibility.
I'm not suggesting the visual system would driving the coding at all. I'm saying that it would be a visualization of your current code base as built by the LLM.
Agreed I want an IDE but only architecture. I suspect it’ll get superseded though eventually too.
[flagged]
Don't worry. No one will want human code in just a few years. This bizarre fixation that humans are decent at coding is a myth. Retype what the machine tells you? I would rather garden or move rocks around.
I used to like listening to music and reading books. Now my AI agent does it for me and it's so much faster at it than I used to be.
“The Electric Monk was a labour-saving device, like a dishwasher or a video recorder. Dishwashers washed tedious dishes for you, thus saving you the bother of washing them yourself, video recorders watched tedious television for you, thus saving you the bother of looking at it yourself; Electric Monks believed things for you, thus saving you what was becoming an increasingly onerous task, that of believing all the things the world expected you to believe. Unfortunately”
― Douglas Adams, Dirk Gently's Holistic Detective Agency
> This bizarre fixation that humans are decent at coding is a myth.
I wonder where the LLMs got their training data from.
It's the state of junior devs who shouldn't have been hired over someone better qualified for the role.
I can easily see a ton of cases of nepotism and EEOC violations being brought to court when the AI is taken away.
Well it's a transitional methodology during the early stages of a major shift in software engineering. Just look at what almost everyone is complaining about with AI coding, and then the inadequacy of their proposed solutions - this is just begging for new tooling that we'll probably consider obvious in a few years.
heaven forbid we use our meat to actually completely understand it in the first place
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...
Its weird how absolutely desperate we are to avoid humans actually using their brains at any step of the coding process. I don't know if we just need to tell people that its fine to need to think about things, and that its actively healthy to do so. Learning is good for you, and no chatgpt isn't good enough to avoid using your meat
If you don't engage your brain, it'll rot. That's far more important in the long term than a 5% productivity boost or something. I have no idea why you'd trade off your entire technical development and skillset training, for the most short term gains, it doesn't even theoretically make sense if you care about long term productivity
In a way it's not so different from learning in school. There were definitely times I read a textbook for a programming or other CS course and reused some example code or whatever to solve homework problems.
I think the helpful part is taking something that already exists, learning how it works, and rewriting it yourself to internalize it.
Again as usual the more important thing is that you know what you're using otherwise it's just copying.
It is different from before. The programmers are used to read the code of smart or creative people, or the code of knolled people working for years to solve a specific problem, and within this process they analyze and learn to improve, thanks to this self-learning path, eureka moments included. This process includes to search (to read the voice of different perspectives and knowledges, to learn to use critical thinking).
Now is being proposed to read LLMs' slope and unrevised code constructed from statistics as the way to learn? This is a big mistake. IMHO.
Perhaps typing the code by hand means you are more deliberate and less likely to have the LLM produce thousands of lines of diarrhea.
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...
It's simple enough: If you don't use it, you lose it.
The more you have, the more there is to lose and the longer it may take. But skills and knowledge fade, just as easily as fitness, or a tan.
It's an insidious rule too. Insidious in the sense that you may not realise you're not exercising a skill. You may think that your just doing it slightly differently, but you will adapt. In whatever way you made your life easier, that's where you'll pay, in strength, fluency, depth, whatever.
I don't know how much I agree, I've been in and out coding for different periods of my life.
At each point few days of practice brought me back where I was.
The key is, as you said, practice. I think it's fine to use AI to write code for you, as long as you occasionally force yourself to write code manually. Not only does it help you retain your skills, but it feels more satisfying than prompting, even if arduous.
A few days multiplied by the number of skills I once had translates to well over two months of lost time.
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/
[1] - https://quii.gitbook.io/learn-go-with-tests
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.
Was copying to the clipboard disallowed back then?
No, but I consciously chose not to do that, because I wanted to gain muscle memory by typing the code by hand.
[flagged]
> 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.
> 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.
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.
If you write more good code by hand than by agent in 2026 that says more about you than anything else (either your ability to give instructions or your ability to delegate). The code they write is above average.
> 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.
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?
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.
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.
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
I'm REALLY REALLY not enjoying this current middle ground where we may be on the cusp of LLMs writing all code better than I could OR we may be on the cusp of realising that this is a chimera.
Mostly I just want to skip forward to the point where we find out which track we're on, because until we know, I feel constantly tense.
So... AGI in 6 months?
> 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.
> 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.
Alright. My company’s money is not my money, so not my problem!
This is cope.
What is "cope"?
"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 mostly do reading in front of the computer (not code, docs), but that's before I'm used to the project. Usually I spend more time on the couch than in front of the computer. Because that's where I think best. If I'm writing code, I already have the solution.
Yup, that's what I do to, although like I say I mostly write my code in the car. I work on things all over Scotland so quite often I'm spending six hours driving to do a ten minute repair, and it is *great*. No, you can't phone me, I'm driving. No, I can't just jump on your teams call real quick, I'm driving? Email? No, driving.
It is *great*.
Businesses demanding high productivity and speed only encourages illicit drug use.
Not shocked to see here that people believe "manually writing code" is the way to build brain power.
How about moving up the stack?
This is what I've been focusing on. Writing good user stories, defining the definition of "done", acceptance testing. Thinking about the high level design decisions. Never thinking about how I'm going to implement feature X is honestly a breath of fresh air.
I've been writing code for nearly 30 years, and I'm done.
[dead]
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.
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.
Copying is not theft.
Can we get that added to the US Constitution and the UN Declaration of Human Rights?
Does it need to be added? I don't think anything legal considers copying theft. Copyright infringement and theft are literally just different crimes.
I don't think copyright should exist at all, but conflating infringement with theft helps no one. Well, maybe Disney and other copyright empires.
> Big no for retyping llm generated code by hand.
There must be some merit to retyping LLM generated code, even verbatim. In school, I would rewrite or re-typeset notes as a study habit. In doing so, I'd review content, detect errors, synthesize concepts simply because rewriting notes forced me to pay attention at the per-word level.
While retyping LLM code is not something I personally do, I'd imagine it could bestow similar benefits.
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
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.
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?
u sure?
How so?
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.
LLMs are addictive, no doubt about it. We've found the cigarette of our time.
Can't agree more, I feel the same.
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.
More like a 0.1x tokenmaxxing subscriber.
> 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.
> 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.
> 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).
Yes, of course, but a lot of it is boilerplate and just figuring out how some function is called or how exactly it is exposed in the library, dealing with some frustrating but trivially solved inconsistencies or incompatibilities or oh you first have to initialize this or that, or actually this feature is missing from version X but can be emulated by setting an environment variable to this other value and blablabla.
> all programmers are saying that the code is bad.
Ridiculous. When did you last use AI for actual work where you wanted it to actually work? I know it may sound like saying James Randi's negative attitude blocks my telepathy or dowsing skill, but I get this impression of many people. They tried agentic coding a year ago, decided that it doesn't work and if they tried it ever since, they didn't provide context, didn't set it up for a possibility of success then immediately closed the program and sighed a sigh or relief that they are safe. It's not like that. The current frontier is very capable on higher level design tasks as well. If your problem is spiritual or social or economic, then let's skip this "not productive enough" alibi talk.
Machine translation today may not be up to the levels of the best professional translators who work on something with full focus and full effort, given all the time they want to polish it, but it's better than an ordinary (not particularly the top of the top) translator working multiple project with tight deadlines. You have to compare like for like and take cost into account too. There is an immense amount of mistranslations by "professional" translators, not sure if you've ever seen movie subtitles or TV series dubs. Lots of paid professionals hired by production studios make huge mistakes, clearly miss cultural references even sometimes grammatical structures, which modern machine translation aces and even chat models are great at it and know basically all obscure pop culture references that e.g. a regular American audience member is expected to know but a translator working in Estonia may not get. Yes you should have a guy checking the output and doing some light touchups, given the draft and explanations and references provided by the AI, but the time of doing it fully manually and being competitive on the real world translator market has ended.
> The current frontier is very capable on higher level design tasks as well. If your problem is spiritual or social or economic, then let's skip this "not productive enough" alibi talk.
My problem is not about the productivity, it's about how this productivity is measured.
> Yes you should have a guy checking the output and doing some light touchups, given the draft and explanations and references provided by the AI, but the time of doing it fully manually and being competitive on the real world translator market has ended.
Have this been measured that this is actually faster while ensuring a quality baseline? I believe it's still the same "LGTM". And a lot of complaints about low quality text. And bugs in the case of software.
So you got a lot of messaging about how AI is supposed to make you faster. And now everyone is trying to show how fast they are with AI while the products are getting buggier.
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.
You mention further down that you're in academia, and with that knowledge this post makes some kind of sense to me. I used to do academic research. Like you, I almost only worked on my own code and nobody else worked on mine. I also knew I wouldn't have to maintain, usually not even expand it, so I worked accordingly.
None if this holds for programming in business, and this is why you keep hearing people saying that the output of coding agents suck. It does! I won't accept the insinuation that people just dismissed it. I use frontier models daily and try to keep up with best practices. Even under the best circumstances, it still sucks, but you learn to apply it only in places where the suckiness matters less and you can mitigate it.
It's been disclaimed so many times that it's a tired trope already, but no, this is in no way comparable to compilers! Compilers relieve you of a tedious layer of deterministic (!) machine translation. It's offloading drudgery and busywork. What agentic coding is offloading is concept and understanding. Not even remotely the same ballpark! One is using a calculator when doing the maths for the structural engineering of a new bridge. Saves time, is more reliable, gives deterministic results based on the inputs of the engineers. The other is having an intern look up some numbers of how it was done for other bridges. It's unreliable, risks missing context, has an unacceptable error rate, nobody knows how to check the numbers because nobody knows how the heck they were jumbled together, and nobody wants to be responsible when the bridge inevitably collapses. How can anyone get the idea to even try to equate the two?
> upper management who are already eliminating these assembly line, JIRA-ticket-taker software jobs en masse
Is there any proof of this?
Some anecdotal trends listed in this report on US demand for Indian tech workers rapidly slowing.
https://thefederal.com/category/news/h1b-visa-indian-tech-wo...
> According to the discussion, foreign hiring at Google has fallen by more than half, while approvals at Amazon have dropped by nearly a third.
> According to Xfino's Active Tech Jobs Outlook, active technology job openings fell to 93,000 in June, down 14 per cent from 108,000 a month earlier.
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 used to do this and called it "Coding with AI the Hard Way" in a nod to Zed Shaw: https://kamens.com/blog/code-with-ai-the-hard-way
I no longer do and blogged my updates for fear of being seen as a luddite:
https://kamens.com/blog/code-with-ai-the-hard-way-update https://kamens.com/blog/code-with-ai-the-hard-way-update-ii
Ben if you're going to blog about things with relative timestamps you need to provide a base timestamp, and I would also appreciate that for when you update the post. "3 months ago" is unhelpful without that context.
Well done for registering your beliefs publicly and updating them publicly. So many people out here exist in an epistemology-free zone.
I'm seeing what looks like a date in the top-right corner of the header banner. Not sure if it was added in response to the note, so mentioning just in case!
ah you're right, it was just subtle, mea culpa
Do mathematicians and physicists put away the calculator and computer (this always reminds me of the last scene from Star Wars) and do the computation by hand? A physicist isn't going to manually invert a 10,000x10,000 matrix.
Exactly as we don't write machine code letting the compiler do that, now and in the near future we won't be writing high level programming language code. We are moving towards working on a higher level of abstraction.
When I ask a frontier model to write a loop 10 different ways in Python and TypeScript and test the performance of each using a 1,000,000 iterations, it isn't creating cognitive debt. For the time being, I'm still racking my brain asking the question, how does garbage collection affect the performance.
I feel like we're doomed to respond to these lazy analogies ad infinitum.
Knowledge abstractions have historically been built by people with a detailed understanding of a problem domain and with a period of vetting the abstraction by many people. That is simply not true with LLM-generated code. We do not really understand what techniques LLMs are using to understand directions, value aesthetic/legibility characteristics, assess tradeoffs, retrieve contextual information, generate output, etc. Embedded in everything LLMs do are small decisions.
If you reach for formulas that you don't understand the applicability of, you will similarly get bad outcomes! But a calculator has almost no resemblance to what happens when you give general instructions to an LLM and get a generated code back, because in between that prompt and the result are many layers of decisions you the developer did not make and likely will not understand without carefully assessing the output!
If you have no discomfort with being culpable for something and doing none of the work to understand it, by all means, don't do anything to understand the output! Don't read the code, don't re-type the result, etc. I have concerns that you'll have a job in a year, but that's your decision to make!
A computer used to be a term for an occupation. [0]
> I have concerns that you'll have a job in a year
Me too because I might be the best TypeScript coder on Earth and there is no demand for those skills. I'm doing a pivot.
[0] https://en.wikipedia.org/wiki/Computer_(occupation)
I don't have any delusions about that, LLMs are impressively good. But they bring with them a host of epistemological problems that I think we ignore at our own peril. A society that blindly trusts the output of LLMs to be good and to make decisions that adhere to our own preferences and acceptance criteria is extremely dangerous! There's a growing call to sort of let LLMs cook and get out of the way, and I think there will be catastrophic problems if we give in to that.
As good as they are, they are still fallible. They still write bugs, they still misunderstand instructions. They even get defensive about bad choices! And even in a world where that appears to no longer be true, we will be making society extremely fragile if we give an alien intelligence total autonomy to do what they think is right.
If you're not going to be writing code, you better be a vigilant babysitter. Otherwise I firmly believe that more than your job is at stake.
I've been asked several times how I use AI. My answer is - pretty much the same way I worked with developers on my team. I give a task, review the result for a reasonable amount of time - which might be close to zero for a minor front-end change - and then either accept it, change it myself, or ask for revisions.
That approach works well for me, so why would I retype AI-generated code? I wouldn't do that with code written by another developer, and their code can be just as buggy or weird in theory. You could argue that at least the developer knows how it works. That's true - for a week, a month, or a few years if you're lucky. Until he forgets or leaves.
I'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.
I share the author's sentiment. I also think it's important to fully understand a codebase I own. So much is naturally lost when you let LLMs generate code for you, and the mental model of what the added code does is one of the biggest losses. When you write code by hand, you build that model as you go, and it's enormously helpful later - when adding a feature, or when debugging behavior you didn't expect.
I've been trying to address this by telling LLMs primarily how the code should be structured, rather than only what it should do. Still, any design I hand to an LLM will be underspecified in one way or another (if it were fully specified, it would just be code), and the LLM fills those gaps somehow - which adds to the cognitive debt, slowly but surely.
Retyping LLM-generated code is an interesting solution. You'd certainly end up understanding the generated code better than if you merely reviewed it, but I doubt it produces a mental model as reliable as the one you'd build writing the code yourself. The longer you think, the better your mental model gets - and outsourcing the thinking to an LLM means thinking less.
That said, I've started to wonder whether I'm solving the wrong problem. Should I really insist on an accurate mental model of the code I own? We'd find it strange for a non-engineering manager to try to fully understand every piece of code their reports produce. If that's the right analogy, then as LLMs' agentic capabilities improve, maybe we should stop treating LLMs as tools that boost our own productivity as a software engineer and start treating them as independent agents we manage and steer.
Not familiar with this term "cognitive debt"
A debt implies repayment. But the loss here is not going to be repaid, it's permanent
Perhaps a more appropriate term might be "cognitive deficit" or "cognitive loss"
Repayment here means that you eventually need to invest the time to understand the approach used and the code intricacy, to later fix or build upon IF you are to manually/artisanally (for a lack of a better word) go about addressing the issue.
...if you use AI again, then yeah it's a permanent loss.
At this stage with AI and how massive AI generated codebases are growing, the chance of fixing anything manually has already reached 0.
It’s an extension of technical debt. They’re both bullshit in my opinion.
That's what I thought
"In theory, theory and practice are the same. In practice, they're not."
I tried this, long ago. I just wasn't getting Haskell, so I'd retype my programs from memory and reconstruction. Obvious for music, why not for code?
All these untested opinions? You'd think we were discussing BMWs.
It seems to me this is the same problem we previously had: how do we understand codebases we didn't write?
Creating while writing allowed us to build a mental context but in a unproductive way, it never scalled.
I believe we need to move onto a new way of reading codebases that go beyond reading line by line.
I know people have explored representing code in 3D spaces. I don't know the solution. But I believe that is the problem.
Ask your AI to chart the data flow through the program. Not that that's a magic solution but it's a pretty good start.
By default, if you ask an AI to "generate documentation for this code" it generates the same broken documentation all the humans do too; an enumeration of all the modules in the code and what their API is. I'm not surprised, the training data is biased probably at least 25:1 in favor of this rather than the useful data flow documentation. Fred Brooks was complaining about this over 50 years ago and the discipline as a whole still gets this wrong.
I'm not saying this is a future solution to all problems, but it is a now solution to some problems.
3D doesn't help. We live in a 3D world but our vision is 2D with a bit of augmentation from a second view point just a bit away. We derive some depth information from that, but we don't really "see in 3D". To do that we'd need to be 4D beings. There's a lot less juice in the 3D squeeze than meets the eye.
This is really the distinction between the mentality of a technical manager and an individual contributor.
Managers never got to write and internalize every line of code anyway. Arguably their essential skill is producing useful stuff without needing to do so. So is that 'cognitive debt'? When I use an agent to code, I do the same things: I validate the direction, organization, and core decisions, but delegate the details. It's an intentional calculation of risk, managing the scope of future problems if there's a failure of implementation somewhere.
It's a question of where you put the value of cognitive focus. I don't understand 'line by line' how my car's ICE works, even though it will likely impact me at some point, because while I might be able to fix it myself if it breaks, the likely applied solution will be to delegate that work anyway.
I empathise with this. I run a little open source project called SmallDocs [1][2] which Claude/Coding Agent invokes to generate easily human readable Markdown documents (and render code files).
You can ask Claude to "sdoc me an annotated code walkthrough of this MR" and it will produce something like this:
https://smalldocs.org/s/Ju9GOmWZ0JXTtzqCVfgt1q#k=6HBrpcCjIu7...
I use this a lot to stay in touch with the code the LLM is producing.
[1] https://smalldocs.org [2] https://github.com/espressoplease/smalldocs
This is really cool, ty for posting it. Gonna try it out
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 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/
In the life of the LLM, we're still in the phase where we're all on the floor playing with these toys. It's strange to assume cognitive debt is an absolute outcome in this new paradigm of engineering when nobody really knows what the future holds. Personally, I feel like I have more time to think, not less, but that's also just my experience. Part of the fun of this is that we're all science experiments right now.
I'm just kind of enjoying the feeling of riding on the swell of a gigantic wave for once instead of feeling like I'm starting from behind it.
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.
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.
Very much agree with you. My own experience with calculus specifically is that I would attempt a problem or example myself, then review the solutions and if I'm stuck, I would not understand a proof or solution unless I copy out every single line as the lecture/textbook and even add to it.
The act of slowing down to ensure every line makes sense to me is one of the most valuable things for my learning.
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.
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.
> Taking down the lesson/lecture does relatively little
Not my experience.
> you can do it on autopilot
Huh, that sounds magically to me, I certainly can't. Actually taking notes down does the opposite, it forces you to get out of the autopilot, because you must think about the content.
Taking notes down, helps you learn better, because you use way more brain areas to process the information. Instead of just hearing, you need to hear it, understand it, try to rephrase it in your own words, use you motoric skills to write it down, and then see it and the placement of element on your page.
> we were given digital lecture notes anyway
Which you don't learn anything from, because by downloading you processed exactly none of the content yourself. Yeah they are way better to eventually search the information later on, if you already no the topic, but for learning you need to start with understanding it and structure it in your brain, which you would have already done for the first time, if you have taken notes.
> but there were no typed notes to start with so it was just out of necessity
The necessity was created by the teachers in order to get the students to learn. It didn't fell down from the sky.
> Or summarising notes in your words.
Which is what you do, if you take down notes. And that on a real time loop, so you can't slack down or miss something, because the information won't come again.
Fair enough. We all learn differently. For me, having printed lecture notes meant I could listen (imperfectly!) in lectures rather than focusing on copying. It was a revelation after years of exhausting lectures doing nothing but writing.
I now realise that sounds a bit like a contradiction. I said I could copy on autopilot but also I had to focus on it. I suppose it was more like the second one: I was so focused on copying verbatim (as furiously as I could as there was barely time to do it before it was rubbed out!) that I didn't have a chance to think about the content.
> > Or summarising notes in your words.
> Which is what you do, if you take down notes.
I certainly disagree with this. No one I knew was rephrasing the lecturer's notes in their own terms. There was no time for that. That is something you'd have to do in your own time afterwards, at a much slower pace.
> > but there were no typed notes to start with so it was just out of necessity
> The necessity was created by the teachers in order to get the students to learn.
I assure you, the main reason those maths lecturers didn't spend countless hours typing up their handwritten notes in LaTeX was not the best interests of the students!
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?
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.
Am I the only one who enjoys taking notes? But more in the sense of recording knowledge so that I have it in perpetuity.
For instance, I have almost completely forgotten how to solve ODEs, even though I had a good command of it when I learned it (by solving practice problems). In that sense, I wish that my prior self had taken good notes, so that I wouldn't have to dig up source material if I wanted to relearn it again.
Everyone likes nicely typeset LaTeX -- why not apply that craftsmanship to preserving academic notes?
It's not that I don't enjoy taking notes - I liked to take notes, distill knowledge, make "cheatsheets" outside of class.
To this day I still take countless notes when I learn new things, I just find it incredibly distracting to have to take notes during a lecture/class because it doesn't allow me to process the material properly.
>In that sense, I wish that my prior self had taken good notes, so that I wouldn't have to dig up source material if I wanted to relearn it again.
I don't really get it. If you've truly forgotten, you have to relearn it one way or another. What makes you think your past student self improvising a half-assed explanation in the moment could do better than a professional author who was already an expert when they wrote the book?
Because you never truly forget something. If you took effort to generate a rehash of your own mental brain model, first you will recognize it again and thus don't need to relearn everything, and second you already have it in your own brain model, instead of needing to invent it first from someone's else brain model.
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.
Me too. And this way you make way fewer bugs, almost none.
It confused me at the time, mainly because I had a class with written-out C and one with written-out Pascal in the same semester. The Pascal prof wouldn't mark off for C syntax but the C one would would mark off for Pascal syntax.
That's what I was referring to, actually.
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.
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...)
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.
Retyping calculus solutions is a great way to remember your LaTeX.
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.
> 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.
> 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.
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.
> It's like trying to retype calculus solutions — you don't learn from it
???
i entirely learned all the math and applied math by working through problems whether myself or copying down from the solutions manual or text book over and over again until it stuck
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.
Working on the problems yourself and have AI in a reviewer/feedback mode is the most productive way to challenge complex software problems.
As time goes on, I become more and more convinced of this also. Also fits in with how many of us already learn via feedback loops - just now it's an LLM instead of a human giving you that feedback.
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 :)
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.
Everyone learns differently. Retyping was extremely helpful for me. The key, for me, was to look up what I didn't understand.
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.
How do you build intuition about something you cannot remember?
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.
While your competitors ship out million-line software, you are going to write down the LLM code. This approach will make a software engineer homeless in a very short time.
LOC is not a good indicator of productivity or quality - or it anything these days it's a negative one. "Million-line software" is meaningless.
From a marketing perspective, I do not agree. The competitors can claim 100 more features than your "lean" code. That by itself makes you lose customers.
> As I manually type every single line of LLM generated code into my editor, I build up a mental model of how it works and fits into my existing codebase. If I don't understand an API or algorithm, I can stop to look it up, or just ask the LLM to explain it.
This is part of how I learned how to code! Well, sans LLMs. Instead of copypasta-ing code blocks from books, Expert Sexchange and Stack Overflow, I manually retyped everything, looked up what I didn't understand and changed what I could.
What's the right middle ground approach to this? I agree that inevitably my more advanced software approaches at work have been compromised by reliance on LLMs, especially given encouragement from management. Are there specific prompts/instructions people find that allow for learning and iterative development without slowing down the actual development cycle too much? I want to keep learning and keep my skills sharp but it feels like a losing battle.
Use it not just as an output tool but as an input as well.
You could try doing the high level design yourself at least. Ask for its review and iterate without asking it to do it all.
Once it has generated some implementation, critique it and ensure you understand its approach And you agree with it, steer it otherwise.
If there’s anything unclear to you say so and have it rewrite it in an easier way to understand.
Yes, use Matt Pocock's /grilling skill to make sure you're thinking about and understanding and signing off on the _technical design_.
We're living in such a stupid time.
Took 36 years to go from computers being a "bicycle for the mind" to manually copy/pasting to prevent brain rot.
It’s just bonkers
You are cooked if you can’t actually write better code than llm. Try reading some books or documentation
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."
> As prompts get deeper, LLMs are already producing PhD-level code—and that's been shown in research.
This gave me a chuckle, "PhD-level code" is gross actually. Have you ever looked at the code of research papers?
I've had opportunities to look at code from Korean and Chinese companies, not just academia. From what I've seen, AI generated code is often better than the average code in those codebases.
When I talk about PhD level code, I'm not referring to research code quality. I'm talking about research level algorithms.
Production code is built around reusability, policies, monadic chaining, and various code hygiene practices. Research code isn't. So what I'm saying is: 'Yes, I've collaborated with professors from top Korean universities.'
That said, I'm not writing PhD level code myself. The reason is that I take existing algorithms and apply code hygiene to them. I'm not actually developing new algorithms at a PhD level of understanding
So from what you're saying, it sounds like:
'Are you talking about those horrible research paper codes?'
But what exists in those research papers is: 'The domain modeling itself is difficult.'
I learned about code hygiene in production code—things like using functional approaches, and so on. Research code often lacks those things, so it might look bad. But that means the code quality is bad—not that the modeling itself is bad. And in fact, the core value is in being able to produce modeling at that level of difficulty.
In fact, most programmers, if trained like me, can do these things well enough. But domain modeling is different.
This touches on the distinction Frederick Brooks made in The Mythical Man-Month between 'Essential Complexity' and 'Accidental Complexity.' Code hygiene, functional chaining, monadic structures—these are techniques for reducing accidental complexity. With enough training, you can learn them. But domain modeling deals with essential complexity. It's about how difficult the problem itself is, and it's not easily solved through training alone. That's why the depth of modeling that researchers produce should be evaluated on a different axis from code quality.
This is what we call 'Essential Complexity.' From that perspective, saying code is 'good' usually means that the essential complexity is handled well on average. What I'm calling 'PhD-level' usually refers to modeling problems that are commonly difficult to solve.
I see it 'very often.' Most research paper code has no reusability—they just implement the algorithm.
So I can see why it might be considered low-quality. They don't use things like Result or policy types like we do in production code. But they're modifying or creating new algorithms, right?
The thing is, they don't need to do those things, so it looks lower-level—but the algorithm implementations themselves are actually pretty good, aren't they?
PhD thesis code often looks low-quality simply because there's no reason to reuse it like production code. The tensor computations inside are things that typical programmers can't easily do.
The point I'm making is that the core algorithmic work is something most programmers can't handle. And that's natural—highly skilled programmers have already built deep libraries for that.
When I talk about PhD-level code, I'm not referring to overall code quality. I'm talking about the level of the algorithms themselves.
> there's no reason to reuse it like production code.
This strikes me as a self-fulfilling prophecy. There are probably many people who would like to use the code published with PhD level research, but they don't because the code is not easy to adapt (or sometimes even to get running).
Then a decade later someone implements that same algorithm in a library with a well-designed interface and it suddenly becomes a useful tool for others. So ultimately there was a reason to reuse it, it was the quality of some aspects of the code that held it back.
The problem is not whether machines think, but whether PhDs do.
You are cooked if you think the end goal was the quality of the code and not the quality of the product.
End-goal seems like making money in this line of thinking so I recommend spinning up some gambling racket or getting into finance, you don't need to program anyways.
This is specifically what people pumping these ideas are doing as you can see like Sam Altman or Dario.
lol What?
No the end goal is providing value to the user. Why is this so hard to accept for people in this field?
You won't get a quality product built on sloppy code.
Absolutely delusional if you think the two aren't related
Many great products run on very sloppy code actually
lol Tell me you've never worked on legacy code without telling me.
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.
We’ve been hearing the drumbeat that these models are already better than $INVENT_A_NUMBER percentage of developers at $SOME_SMALL_TASK for several years. I haven’t seen that it’s actually true yet personally.
What I do see is that the frontier models can get easy stuff mostly right, but they can’t maintain a small codebase such that it behaves correctly across several mutations. When the going requires a lot of context, tests get rewritten to not do anything and features that manipulate similar data get divergent implementations. That’s fine for goofing around personally, but I see vibe coders getting their asses handed to them when they mistake that for a well maintained codebase and try to sell a product.
Please, don’t mistake an impressive technology for a miracle; there will still be people needed to make codebases healthy for a long time to come.
I hope you're right, but hope is not a process. I'm looking at the obviously exponential charts of capabilities and don't have much to add to that hope.
Vera Rubin datacenters aren't even online yet.
I'd say as long as we can clearly see the 5% are working better than an LLM, why not strive for it? Shows what humans are capable of, and it's probably achievable to most.
I'm not hanging my hat yet and can still see where LLMs struggle. I think it's the best bet you can make: keep working for the future where you'll still be needed, because you can't prepare for the future where you're not.
I agree about your general assessment, but I don't see my coding skills of, depending on how you count them two or three decades, being needed in 36 months - so I'm trying to upskill LLM piloting, but that also seems a bit of a dead end since LLMs will be perfectly capable of piloting themselves in approximately the same timeframe - we'll see what needs upskilling in by winter...
How this presents, however, I would think, is that being that top 5% and utilizing LLMs will get you further than either alone.
I think that's a reasonable view. Though I personally see LLMs more as replacers, not as tools to utilize.
> write better code at CRUD tasks
This reads like it can write a better javascript function that executes a SQL statement and maps the parameters.
> 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.
Basing this prediction on LLMs writing what something like an ORM would generate for you doesn't connect for me.
What is "better code"?
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.
Pretty crazy idea. I know I sometimes just "wave through the motions" when I'm taking notes.
For example, when I am reading a book, I often take notes of my favorite quotes/sentences/things that stick out or perk up my ears. Usually if I own the book or it's a used copy of mine I make a note of the page number on the very last blank page(s) and write out the full sentence/quote. Then when I go back months or years later I just open to the last page and can find all my favorite/important quotes. Most 200 page books typically have ~20 useful sentences for me to reference [going forward] - it's basically like making your own index or table of contents.
That long aside, just to say, if I'm not "very aware" or "consciously mindful" of what I'm copying down or writing, I'm able to do it very well on autopilot without etching anything into my memory -- as if no recallable moment gets etched into the wet cement of the brain unless I'm actively "hip to it." I wonder if others have this "autopilot" problem.
A better interface for code review would be a pseudocode layer that sits on top of all of your code, at the editor level.
Basically it would convert all of the chunks of your code using an LLM to simple pseudocode with clickable symbols so you can follow function calls, definitions, then you could expand/collapse it to see the real underlying code.
I know how to program, why do I need things to be converted to pseudo code?
It's easier to skim pseudocode than it is to reason about complex logic. When I say pseudocode I'm talking very high level but structured explanations, and less the sort of traditional pseudocode you'd imagine which is basically just a generalization over syntax.
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.
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.
Agree with this. Small steps towards the feature. Review, iterate, learn and optimise as you go.
If the project is a mountain, I want AI to assist with the climb so I can learn the mountain, its trails and details. Hitching a free helicopter ride to the summit would leave me with little understanding about the mountain other than the view from the top.
I don’t know it feels like some og programmers would say the same thing about people who can’t program machine language
Code quality is only going to get better and to be perfectly honest learning how to get the llm to generate quality output is IMO time much better spent vs some misguided attempt to do something by hand — the prompting is the better skill to develop at this point and if you’re worried about atrophy it’s probably your least developed skill
Instead I focus on reading the plan and making sure I understand it, opening up a second session for second opinions or questions if I have gem
This obviously depends on where in the stack you live but code quality is accelerating at a significant rate - decision making not as much and it’s where your value is imo
I 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".
[dead]
Few will remember this is how programming started for many, including me. Wait for that issue of Family Computing to show up, so you could manually type in the program for that Turkey game to run.. Appreciate you bringing up the good ol' days.
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.
Today I added a temporary data source to Prometheus to help me monitor a system closely during a tricky ops task. I would not have done that except that the LLM gave me a small script I could quickly check and immediately use. Without it, I'd have roughly spot checked the service via "tail -f".
Our company's policy on LLM use is: use it, disclose it, and take responsibility for the code you commit.
There's no way that typing that tool back in would have done anything useful for me or my organization.
>Typing the code myself forces me to slow down, which means I'm more likely to detect hallucinations or bad design choices the LLM might have made.
I think this depends on your level of expertise with the task.
If I'm writing a language I am extremely familiar with and so second nature to me, for example SQL then I can instantly read llm code.
But if a new language or a new piece of software then llm generating huge amounts of code can make it difficult to improve yourself and also manage the quality.
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.
+ let LLM generate just scaffolds, skeletons + do not let it generate code (let it generate leading questions instead of answers) + let it test you (try learning-opportunities repo from CatHicks)
I was working on a VS code extension that integrated with claude code to show an overlay for the changes instead of the edit tool calls so you could write everything yourself. The idea was that even if you type 100% of the same code instead of making your own changes, it would still mean you go through the code yourself and have a better understanding that you would have on just skimming through the generated code. Maybe I should start working on it again.
(posting this here on the off chance someone makes this instead of me so I can just use their version instead)
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?
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 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.
Fair enough... I think it really depends about what dependencies we talking about.
NPM decencies is a bit of dumpster fire, supply chain attacks galore! A well known python (think numpy) certainly is less discomforting, and a "industry standard" C library like GSL or SDL3, I just use it and move on
Good, but my workplace has a metric of AI-written lines of code, so I need to ask LLM to redo all of my changes after I retyped them from it.
We need a master list of companies with such stupid metrics :)
Generate code using LLM on a small project, then copy manually toward your big project. This reduces the context (and the cost) for the LLM and gives you many small projects where you can experiment ideas with more agility.
"... I don't enjoy reviewing AI-generated PRs. Poring over hundreds of lines of overly-defensive, badly-commented, subtly incorrect code is not fun. I might grudgingly do it for an employer—while making sure said employer becomes an ex-employer as soon as possible..."
I don't know about where you work, but in my neck of the woods if you want to be employed you will be reviewing AI PRs, there is no escaping that.
> Personal projects must be fun above all else. The joy of working on personal projects comes from the process, not from the outcome.
I think that's my fundamental difference with the author. I only write programs I actually need. I enjoy the outcome more than the process.
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.
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.
> might not be the most efficient way to work with an LLM, but I value comprehension over productivity.
LLM are becoming so good that they are better than us at understanding code. And it's only going to get worst every year.
I think that the job of 'coding' is done, it's dying and will be effectively dead in a decade.
You better find ways to make yourself usable around LLM work but not by doing what LLM already do.
LLMs don't understand a damn thing. They can't. They're not built to.
An LLM doesn't "understand" its own slop. It can use that slop as further input for generating more slop on top of it, but at no point of the process does anything like a concept or understanding come in.
I’ve got similar concerns about skill rot, but I also have chronic RSI and some hand arthritis. LLM assistance plus modern voice models are a godsend but it’s not the same as typing every character. But I can’t really type every character anymore. I can read it all but…falling into skimming is very hard to avoid.
So I’m grabbing the double-edge sword with my bare hands hoping to stay ahead of the brain rot…somehow.
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.
So I always make sure I take a crack at doing what I want first. Then I ask for an AI review and it usually has a more efficient way to get the job done.
For example I had a working linear decay velocity boost function added to a godot scene and it's suggested refactoring actually reduced lines of code just today. So kind of happy when that works out, but yes I also applied the changes manually so I would grok them and hopefully remember it better.
Same idea with Stack Overflow solutions before that.
But I don't just retype that code verbatim, I rewrite it in my style, add or remove comments, add or remove some checks, sometimes even tweak the algorithm. I want to own the thing. Some copy-pasting may be involved, I am not trying to improve my typing here, but the important thing is to understand every character of it.
Right ... While we do that, let's also retype the assembly code the compiler produces, do the linking manually and check you got the same result as the linker, and then finally write the bytes yourself. Whether or not you manually bit-bang à la Morse code the bits to storage is left as an exercise to the reader.
While I agree on some level, this not a great comparison.
A compiler/linker/etc is an algorithmic, precise, verifiable, repeatable, debuggable, etc, etc, process.
Using an LLM is an inherently stochastic process. It can is very, very helpful, but I think we are arriving at the realization that "vibe coding" wasn't the best idea - unless you are doing a PoC or demo.
In any case, neither absolve you from understanding in detail what is going on.
Maybe we'll get there, and we can fully trust what the LLM produces, but it seems we are not quite there, yet. Until then we'll have to understand everything the LLM produces and that's what the author is getting at.
Retyping LLM code sounds absolutely miserable and soul crushing. Like hand copying the HTML produced by page generators... why would you do that to yourself.
In highschool, my history teacher's home work assignments were to write out the notes he created and handed out for us. Essentially the assignments were to read chapters from the text-book, then copy the notes by hand and hand them in. It seemed odd. But I think their is some wisdom to it. As you writing it out, you are slowly reading what you are writing... even if you do not mean to.
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
"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.
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.
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.
There's value to hand-copying something. Hunter S. Thompson transcribed Hemingway to internalize the cadence of his writing.
However, if you're serious about it, then why not hand-write your LLM-generated code? You'll get much better retention and comprehension than typing.
Whenever I don't know something, I ask it for a tutorial, programming-magazine style. Then I just follow the tutorial.
I don't manually retype the code from pull requests of other engineers.
It's important to retain the what why and how as a team to the degree that development can be efficient, extensible, and maintainable. (And ideally a good devx)
Needing to manually touch every line of code is not scalable.
This was true 10 years ago. It's still true today.
Thats nuts. You are fighting a tool that is supposed to offload that. Is like lets not use the power tool, but do it by hand so your muscles won't atrophy, but you should instead use it to free up your muscles for other tasks like better requirements, architecture, tests, UX design.
I do something different, I type everything by hand and have AI provide feedback.
It's one of the best ways to kickstart projects that have intrinsic software complexity as you get your hands wet into the design tensions and constraints early.
And you get to practice some.
To be honest I am thinking of an entirly different situation, ask the llm to create Red tests for you. Then implement them yourself. You don't waste time writing tests but you still need to spec what you implement properly so the llm can write good tests for it
This is really good advice that I've found to be true, especially if you have autocomplete turned on. At the same time, I'm privileged enough to have a fast typing speed and anything less than 60 WPM would make this practice very annoying. Thank you for sharing this.
That’s just seems like a worst of both worlds to me.
I can see both logic in doing manual coding (perhaps with AI autocomplete) or a vibe based flow. They’re orthogonal approaches though.
Seems like an ok solution, but what about doing something like the opposite? Write out the scaffolding and general shape of the code (classes, interfaces, function signatures), and have the LLM fill it in. That seems more important for understanding.
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.
Replace LLM with “intern” and the absurdity should be more obvious
The fact that we can’t trust the code outright is a bug
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.
Wait you only wanna make llm write the boring parts but after it has written it you retype. Without concrete example this sounds bizarre.
Hah I was just thinking I should switch to colemak that I only let myself continue with for 2 months and re-type out all the domain (types, etc) for this project I'm working on
I simply never ask LLMs questions specific to my codebase (except for finding what function/file does something, because that is annoying), and instead use generic questions.
You do that enough and I bet you'll be labelled "the slow one" in certain circles, so before attempting that as a junior make sure you have some measure of protection.
I got made redundant shortly before the release of LLM code generators, so I've never used one, but I did occasionally do this for short snippets from tutorials and suchlike.
Print this article out and put it in the scrapbook.
File next to that 1970's era classic, "Prevent cognitive debt by manually retyping compiler-generated assembler"
Jack Kerouac famously sat down and typed "Anna Karenina" on a typewriter because he wanted to feel what it was like to "write a great novel".
I think you're thinking of Hunter S Thompson, Kerouac really doesn't seem like the person that would have the time or care about doing that.
You're right! Thanks for the correction.
I ask the LLM to generate the code but mask the last token. Then I do softmax and give it an answer. Pretty soon my perceptrons are more connected than ever.
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.
that's a great approach, the bad thing is that (at least I) will forgot my codebase anyway after two more projects. so i'm wondering if it worth the effort. i prefer to impose my vision on the code upfont and then rapidly check the my vision is respected rather than understanding every single line
I still write lots of code. And there's still a lot of code for the LLM to do. I prefer comunicating with an LLM in terms of code, having it grounded by code that I have already written, it can be a function signature, a struct, an interface, a trait, the skeleton of a test suite. It can even be a sequence diagram in mermaid, but I refuse to let it go.
I stubbornly refuse to let the LLM design. I can discuss my design with it, I can even completely discard it, but I am not fucking writing reams of natural language.
And know what? I don't think I am less productive than my "looping" colleagues, because, well, code is way less ambiguous than natural language, a validation rule in code can usually be expressed more economically in a programming language than in english prose. It is easier to create a directory and file layout, sprinkle some declarations here in there than it is to EXPLAIN how the flow of dependencies go. It is easier for me to create a hook because I want users of a certain module to be able to change its behavior without having to change the source of the module than explaining the OC principle to the LLM and seeing it miserably failing to apply it, because it doesn't have a theory of what it is fucking doing.
And as a side effect, when the 30th day of the month comes, and all the company tokens for the month are used, I can still be productive while others wait for the CTO to negotiate a couple tens of thousands more in API with the CFO.
Cognitive debt is a huge problem but this, personally, is definitely not a solution to it
As someone that learned typing "the proper way", I have doubts about this.
This is like flossing, probably good for you, hardly ever do it.
Lets prevent cognitive debt by manually retyping the assembly that is generated by our compilers...
At that point I feel like you might as well do the implementation yourself and just plan with an LLM
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?
This is not slightly comical, it is very comical. Side projects are not mandatory, if you are using them to learn something, asking LLMs to generate and for you to type it makes no sense - just do it on your own. If you want to offload tedious boilerplate part to LLM, then by definition no need to learn it as it is tedious, so typing it out is useless.
Similar to where we simply ask LLM to leave 20% of the work undone: humantodo.dev
this is how I did "AI coding" (for unfamiliar languages/frameworks/etc.) back in the GPT-3.5/4 days. Except I'd also test each line to verify it actually did what I thought it did.
I don't think it's possible to eliminate cognitive debt when using LLMs, but you can definitely minimize it. Part of this means recognizing that you will only get, say, a 2x productivity boost instead of a mythical 100x increase, the benefit is, you'll actually know what you're doing versus being a brain addled zombie.
First, use the LLM to understand the problem thoroughly. They can be great research aids. I've speed up tons of learning using LLMs. It is essential you ground the discussion in existing texts or code. Ping pong with the LLM asking it to challenge your understanding, how you direct citations for explanations, clarify things, etc.
After you've understood, plan. Develop a plan with the LLM/agent by steering it hard. Read the slop text thoroughly. Give it direct feedback. Don't proceed until you have a complete expectation of what you think the agent will do when implementing the plan.
Let the agent do all the implementation.
Review the agent's work. Again, engage with it and leave direct feedback. Ask for clarification and alternatives if needed. If it was totally off mark, start the process again.
You won't be moving at warp speed with this approach but you'll know a lot more than the one shot prompting loop cowboys out there.
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 much either.
When you are/were developing software without AI, even for pretty large projects you do end up internalizing (memorizing, but not deliberately so) a lot of detail, but from my own experience I'd say it's more the design than the code. The design is what you put effort into, thought about, etc, so is both what you naturally end up memorizing, and is what you need to know to have a mental map of the project and therefore understand how best to modify it. The code itself was naturally always the last thing you did, and followed automatically from the design and module/component interfaces - not something you typically think much about other than while in the flow of just "coding it up".
By retyping LLM-generated code, it seems you are mostly going to be gaining familiarity with the wrong thing - the code and not the design. Memorizing the code is not going to help much in grokking the design.
Better to be a coder in the garden, than a gardener in the code.
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.
At this point, just write the code yourself with your brain.
“prevent cognitive debt by manually setting type.”
we need to move on
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.
this seems redundant as a methodology. just write the damn code yourself at that point.
you definitely have lots of time in your hands
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
Because typing is a small percentage of the time spent writing software.
the article's advice is to type the code yourself instead of pasting it. we used to call that programming.
> I fear the software industry is taking on a large amount of cognitive debt that we'll have to pay back very soon. There will come a time when we no longer understand how large parts of our digital infrastructure are put together. I might not personally be able to change the course of the entire industry, but I can at least make sure I completely understand the software I put out into the world. Anything else would be professional malpractice.
"professional malpractice" LOL. This is so dumb. I can't believe this shit is getting upvoted.
Just write the code. This weird obsessive dependence on LLMs doing everything will ruin you as a developer and prevent you from progressing in the industry when the AI bubble/fad pops.
Don't let your skills atrophy.
agreed!
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?
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.
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
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.
AKA preventing cognitive debt
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!"
Please don't do this
better: before submitting the code, ask LLM to quiz you for understanding the code.
I just give them smaller tasks
There is so much bad science about psychology and cognitive debt posted on Hacker News every day. It’s so exhausting.
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)
Seems like a much better idea would be to build it yourself first, then have the AI do it for real? If you don't understand what you're building, you're going to get a lot of surprises when you re-type the AI-generated code and realize it subtly mistook your prompt or made decisions you didn't think to specify.
The Zed Shaw method!
Filing this away
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.
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 don't understand the concern about "cognitive debt". I frequently have to maintain code I wrote, or someone else wrote, weeks/months/years ago and I have NFI what's going on. Now I say to the LLM "tell me what's going on" and it tells me. I can ask it some follow up questions, and build up my understanding. It's SO much faster than grepping through the source myself and I can do it for as multiple issues in parallel. The notion of reading every line of code is absurd to me, the notion of RETYPING it beggars belief. Surely this is satire.
...what, that's terrible advice. If you gonna waste time on that just waste time on writing the code from scratch
This is the stupidest thing I've ever heard.
"Stay in shape by walking behind your car."
ain't nobody got time for that
The industry does. Not. Care.
64 GB of RAM, nough said?
The cope just keeps coming!
Cognitive debt is an idiotic phrase.
In my current workflow, I've settled into a three tier system when coding:
1. HIGH-VALUE CODE:
I write it all myself. I will occasionally use AI for mostly mechanical changes, like cleaning up variable names or mass-changes when a function signature has changed. Either way, every line is read carefully. Sometimes this means isolating my high-value code as a library in a separate repo. Usually it's just a note in AGENTS.md, or even a well-written comment at the top of certain files. I'm not obsessive about it, though, as it can't hide from git. And learning what it's trying to change is sometimes a useful insight.
That doesn't stop me from using AI as a consultant. This is the one time I'll use a beast like Fable. Ask it to write a technical/security analysis on a section of code and damn it can pull out some impressive insights. It can't write new code particularly well, but it can inspect code like a boss. But that all stays in the chat window. (And despite being so infrequent, they ends up costing significantly more than all my other AI costs combined!)
2. BOILERPLATE/PROCEDURAL CODE:
I'll write the first draft, but once I've set the tone, I'll allow AI to build and maintain it. I keep on top of things like a senior manager, just to make sure it's not doing stupid things. Every few days I tell it to mow its own grass: AI is good at recognising its own stupidity, you just need to give it an opportunity to look.
3. TEST/HARNESS CODE:
Bring on the slop. If I get nothing else from the AI revolution, it's not having to write another stupid test unit. Nothing makes me happier than setting the AI to work writing every permutation of test I can think of. I will slop this code all day, and I won't read a single line of it. Why should I? If I ever doubt whether a particular test is correct, I'll test the test by breaking the code, not by reading the test. But I almost never catch it out. In my experience, AI is especially good at writing tests. Perhaps more than anything else.
Tests don't just take the form of a few mocks and props in a test harness. In one recent case, my project involved writing a library for the API of an obscure commercial microcontroller-powered device. I took the API documentation and made AI build me a complete simulator. I then made it write a full suite of tests using my client library within the test code. I then got it to run that test suite against real hardware and identify any inconsistencies. From there it could recursively modify the simulator until it became unreasonably good at mimicking the real hardware. I haven't read a single line of its code. But it's now core to the library's CI.
> 3. TEST/HARNESS CODE:
> Bring on the slop.
Bring on Volkswagen tests, right. Because reliably confirming that your code work is not a critical port of the project at all. /s
> Because reliably confirming that your code work
I can't reliably confirm that you read my post all the way to the end. I pointed out multiple ways where tests are proven. One is to verify the test by breaking the code under test. Another way is to build a fully independent, highly complex test rig that would never be (commercially) feasible without AI.
[dead]
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.
But if the code base is constructed in a way which results in strong test suites (human driven), quality evals, robust documentation, and modular implementation, will the human really lose that much context?
Given that those things are checked off, I am having a tough time believing a frontier model, in conjunction with a new dev on a project, can't be immediately valuable to determining what is going on in a repo.
[dead]
[dead]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
[dead]
[flagged]
[dead]
[flagged]
[dead]
there is a simpler way, make a complete mental model of the changes and ask questions to confirm your understanding. so much faster.