there is a simpler way, make a complete mental model of the changes and ask questions to confirm your understanding. so much faster.
Prevent cognitive debt by manually retyping LLM-generated code
21–30 of 479 posts
Re: Prevent cognitive debt by manually retyping LLM-generated code
#22If 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.
Re: Prevent cognitive debt by manually retyping LLM-generated code
#23As 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.
Re: Prevent cognitive debt by manually retyping LLM-generated code
#24Earlier quoted context omitted.
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…
> 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.
>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."
Re: Prevent cognitive debt by manually retyping LLM-generated code
#25But 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?
AKA preventing cognitive debt
Re: Prevent cognitive debt by manually retyping LLM-generated code
#26Whenever I don't know something, I ask it for a tutorial, programming-magazine style. Then I just follow the tutorial.
Re: Prevent cognitive debt by manually retyping LLM-generated code
#27We're living in such a stupid time.
Re: Prevent cognitive debt by manually retyping LLM-generated code
#28I'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.
Re: Prevent cognitive debt by manually retyping LLM-generated code
#29Earlier quoted context omitted.
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?
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)