Comment by jatins
6 days ago
Everything about that is true but, and that's a big BUT, the code I write with LLM I can only iterate on it with an LLM.
My mind doesn't develop a mental model of that code, I don't know where the relevant parts are, I can't quickly navigate through it and I have to reach the LLM for every small change.
Which is why I like Copilot style editing more than agents as a working model but agents are just so much more powerful and smarter thanks to everything available to them.
This is in line with "Programming As Theory Building"[0] (Peter Naur, 1985) that puts forward the idea that when one is building a system one builds a "theory" (in a sense a mapping of what, where and why) of that system that is essential for continued work on it. Once I internalized this idea it helped me make sense of why rewrites are not "never a good idea" and simultaneously why they are so fraught with peril, as well as what kind of onboarding actually makes sense for work on a system. It's also why I can never get on board with the passive "review code an LLM spits out" type of development; it just does not build theory as reliably, effectively and efficiently.
It's a good, very digestible paper, in my opinion; well worth the read.
[0] - https://gwern.net/doc/cs/algorithm/1985-naur.pdf
This is exactly right. This is what's happened with every vibe coded codebase I've made. As a result, I only selectively use LLMs now with sections of the codebase. Or I'll just relinquish control to the LLM. I think the latter will happen en masse, which is scary.
You can ask the llm to write code the way you think about it. I usually write a little spec document as my first prompt, and in there i'll add some rules on how I want code structured, seperated etc.
If you use cursor, cursorrules can be a good way of doing this.
This still doesn't work for me. I have to actively think about the problem, find a solution, and write the code myself. Outsourcing these efforts makes my learning ineffective.
I will keep using LLMs for 1 week greenfield hobby projects that I don't plan to revisit. But no matter how good LLMs get, I will never use them in my dailyjob, otherwise, I risk losing touch with the codebase.