Live data from Hacker News

Prevent cognitive debt by manually retyping LLM-generated code

ankursethi.com

231–240 of 479 posts

Re: Prevent cognitive debt by manually retyping LLM-generated code

#231
post #89

You are cooked if you can’t actually write better code than llm. Try reading some books or documentation

Frontier LLMs write better code at CRUD tasks than 95% of developers today. They’ll get to 95% of most niche coding domains by December and likely all coding tasks sometime next year; 99% better at all tasks by December 2028. You may be correct now and it doesn’t matter one bit.

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

Re: Prevent cognitive debt by manually retyping LLM-generated code

#232

Earlier quoted context omitted.

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…

So... AGI in 6 months?

Re: Prevent cognitive debt by manually retyping LLM-generated code

#233
post #120

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 nu…

> 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 lik…

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

Re: Prevent cognitive debt by manually retyping LLM-generated code

#234

You are cooked if you can’t actually write better code than llm. Try reading some books or documentation

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.

Re: Prevent cognitive debt by manually retyping LLM-generated code

#235
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.

Re: Prevent cognitive debt by manually retyping LLM-generated code

#236

Earlier quoted context omitted.

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.

Re: Prevent cognitive debt by manually retyping LLM-generated code

#238

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 con…

Perhaps typing the code by hand means you are more deliberate and less likely to have the LLM produce thousands of lines of diarrhea.

Re: Prevent cognitive debt by manually retyping LLM-generated code

#239

Earlier quoted context omitted.

> 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…

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…

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.

Re: Prevent cognitive debt by manually retyping LLM-generated code

#240

Earlier quoted context omitted.

> 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 lik…

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 wi…

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.

Post reply on HN