[datsci_est_2015]

Sounds like you wrote very poor quality (edit: or trivial) code, or you’re exaggerating a bit for effect.

I too forget the details of most of the code I write, but the most important 10-20% of the code that I write encodes my mental model of the problem I’m trying to solve. Sometimes it’s a class representation of a digital or physical entity. Sometimes it’s a job with tasks that map to subproblems. Those abstractions almost immediately launch me into the mindset of my former self, even years (or a decade!) after the fact.

AI-generated code does not tend to create those kinds of abstractions in my experience. It will likely, with encouragement, solve the problem you’re asking it to - but it won’t magically cause you to understand how to solve the problem. You must take the initiative to understand it yourself. You are the camel that the AI has taken to water, and it can’t force you to drink it.

[andai]

So the way I write code is that, my understanding is local. Okay, we need a function that does this (high level). It'll call these functions to do that. And then I just continue until there's nothing left to write and the thing works (after a few rounds of debugging).

I understand each piece and what it talks to. But I can't hold them all in my mind at once, because there's too many pieces. (I think chunking helps here, but it seems to require a certain level of fluency with the entire codebase that I'm not sure it's feasible to hit with anything past a certain line count. I am working on this new memory software though...)

The transformer on the other hand, just loads it into context (they can do about 10K LoC these days without performance degradation), cross references everything against everything (that's how the transformer works! That's why they're so expensive) and just tells me what talks to what, what the full chain is, and also btw you have 3 bugs you didn't notice because they involve how distant parts of the chains interact, you're welcome!

I've been looking for ways to build up that mental model. The Feynman technique seemed like a good place to start. I did it on a section of my codebase. It took half an hour of poking around to connect all the pieces. The transformer was able to do it instantly.

I'm not sure if there was added value to me poking around manually or if those 30 minutes would have been better spent just memorizing what it told me.

(After verification of course! To clarify, I don't think they're infallible, but their perception is broader than ours due to how they're structured, and I'm learning to utilize that more effectively.)

Also, in the absence of that costly verification, the model my Feynman technique produced turned out to be wrong (though it sounded correct!). So I'm leaning in the direction of, the way to actually verify your mental model is to make a modification to the codebase. Make reality push back!

--

On some projects/subprojects I do build an explicit mental model beforehand, and then I do generally remember it pretty well, at least for a while. Others take a more iterative approach to the design. (I'm on the 5th damn iteration of my netcode right now.)

So there's two distinct issues here, the model building process and the human forgetting curve.

[datsci_est_2015]

That’s fair I guess. I’m pretty consistently surprised by the wide variety of tasks that everyone under the “programming” moniker tackles. I consider myself a programmer by trade, even though I’m not a SWE. Your first paragraph couldn’t really be further from my personal experience. I haven’t thought in terms of functions in years, mostly “jobs”, “tasks”, “workflows”, “data flows”, “modeling”, “labeling”, etc.

Some people really do have jobs that I wouldn’t be surprised that LLMs will nearly completely automate away. And those people will be forced to move “up the stack” in terms of abstraction… but that’s already where I’m at. And LLMs are helpful, but I don’t feel threatened by them at all. If they take my job, I think computers will be declared obsolete. No more keyboards and mice.