Beyond recall and the illusion of competence
7 points by tuxie_
7 points by tuxie_
An alternative take to the more pessimistic AI coding will prevent expertise - the latter honestly resonated more with me. The core difference is that this author believes you can outsource friction to AI and still come out with a strong mental model capable of debugging problems that AI wasn't able to.
You inherit a service from another team. Someone who left the company wrote half of it. Three people contributed to the part you're responsible for, and you don't even remember who wrote which function. Yet after working with the system for long enough, you start to think of it as yours. Why?
Not because you wrote every line. Because you understand it.
The critical piece here seems to be: what counts as "working with the system" if one of the goals is to build understanding and intuition? How much does assistance hamper that process? Generally if I took ownership of something whose original author had left, I wouldn't feel like I really owned it until I had actually rewritten sizeable parts of it - not all, but you can't avoid getting your hands dirty and engaging with details yourself.
Very much on point. The focus should be on ownership. It doesn't matter how the code is produced, what matters is that there is a human who can be held accountable for it, and who is ultimately responsible for the project. Building understanding of how the project is structured, and how things fit together is absolutely a prerequisite for being responsible for it.
My view is that nothing really fundamentally changed about programming with the introduction of LLMs. These tools help you generate boilerplate, they make it much easier to track down problems, wire things together, but you still have to understand your problem domain, the algorithms being used, data modelling, and all the other things that make you a good programmer to apply these tools effectively.
I agree so much.
We have always worked on systems we didn't write.
What's this "we" business? I've worked on systems that I wrote. I've even worked on a system where I wrote the underlying operating system. Not everyone works on Enterprise code (but damn, it sure seems like the industry as a whole is hell-bent on forcing everyone into the Enterprise). I wonder what other assumptions the author has made.