I don't remember exactly what I wrote and how the logic works, but I generally remember the broad flow of how things tie together, which makes it easier to drop in on some aspect and understand where it is code-wise.

I recently did some work on a codebase I last touched 4 years ago.

I didn't remember every line but I still had a very good grasp of how and why it's put together.

(edit: and no, I don't have some extra good memory)

I juggle between various codebases regularly, some written by me and some not, often come back to things after not even months but years, and in my experience there's very little difference in coming back to a codebase after 6 months or after a week.

The hard part is to gain familiarity with the project's coding style and high level structure (the "intuition" of where to expect what you're looking for) and this is something that comes back to you with relative ease if you had already put that effort in the past - like a song you used to have memorized in the past, but couldn't recall it now after all these years until you heard the first verse somewhere. And of course, memorizing songs you wrote yourself is much easier, it just kinda happens on its own.

If I’m learning for the first time, I think it matters to hand code something. The struggle internalizes critical thinking. How else am I supposed to have “taste”? :)

I don’t know if this becomes prod code, but I often feel the need to create like a Jupyter notebook to create a solution step by step to ensure I understand.

Of course I don’t need to understand most silly things in my codebase. But some things I need to reason about carefully.

I still remember the core architecture of code I wrote 20 years ago at my first job. I can visualize the main classes and how they interact even though I haven’t touched it since then.

Meanwhile some stuff Claude wrote for me last week I barely remember what it even did at a high level.

Harder here doesn’t mean slower. Reading and understanding your own code is way faster than writing and testing it, but it’s not easy.

AI tools don’t prevent people from understanding the code they are producing as it wouldn’t actually take that much time, but there’s a natural tendency to avoid hard work. Of course AI code is generally terrible making the process even more painful, but you where just looking at the context that created it so you have a leg up.

This is also an area where AI can help. Don't just tell it to write your code. Before you get going, have it give you an architectural overview of certain parts you're rusty on, have it summarize changes that have happened since you were familiar, have it look at the bigger picture of what you're about to do and have it critique your design. If you're going to have it help you write code, don't have it ONLY help you write code. Have it help you with all the cognitive load.

It’s hard to keep the minutiae in your memory over a long period of time - but I certainly remember the high level details. Patterns, types, interfaces, APIs, architectural decisions. This is why I write comments and have thorough tests - the documentation of the minutiae is critical and gives guardrails when refactoring.

I absolutely feel the cognitive debt with our codebase at work now. It’s not so much that we are churning out features faster with ai (although that is certainly happening) - but we are tackling much more complex work that previously we would have said No to.

Oh come on, that is complete nonsense. I can reunderstand complicated code I wrote a year ago far, far faster than complicated code someone else wrote. Especially if I also wrote tests, accompanying notes, and docs. If you can't understand your old code when you come back to it... including looking through your comments and docs and tests... I'm going to say you're doing it wrong. Maybe it takes a while, but it shouldn't be that hard.

Anyone pretending gen-ai code is understood as well as pre-gen-ai, handwritten code is totally kidding themselves.

Now, whether the trade off is still worth it is debatable, but that's a different question.

I recently spent 1.5 weeks fixing a bug I introduced 20 years ago. Can confirm, I have no idea what I was thinking back then.

OP talks about the increased frequency of such events happening, and not that this is a new problem.

For example, handwritten code also tended to be reviewed manually by each other member of the team, so the probability of someone recalling was higher than say, LLM generated code that was also LLM reviewed.

In the past, it was also an optimistic assumption that your engineers would still be working for you in a year's time? You need some kind of documentation / instructive testing anyway. And maybe more than one person who understands each bit of the system (bus factor).

My experience with Perl. "Write-only" language.

The individual details, probably not. But the high level/broad strokes I definitely remember 6+ months later.

Understanding other people's code is harder than understanding your own code though.

Also the article is AI written itself or AI assisted - there’s a tendency in AI text to bloviate and expound on irrelevant stuff so as to lose the plot

AI spec docs and documentation also have this documentation problem

A lot of bug fixing relies on some mental model about the code. It manifests as rapid "Oh 100% I know what's causing" -heureka moments. With generated code, that part's gone for good. The "black box written by a black box" is spot on on, you're completely dependent on any LLM to maintain the codebase. Right now it's not a vendor lock thing but I worry it's going to be a monopoly thing. There's going to be 2-3 big companies at most, and with the bubble eventually bursting and investor money dying, running agents might get a lot more expensive. Who's going to propose the rewrite of thousands of LLM-generated features especially after the art of programming dies along with current seniors who burn out or retire.

I’m very confused by this statement. I routinely answer questions about why we wrote the code we wrote 6 months ago and expect other people to do the same. In my mind that skill is one of the key differences between good and bad developers. Is it really so rare?

I have been laboriously going through the process of adding documentation and comments in code explaining the purpose and all the interfaces we expect and adding tests for the purpose of making it easier for claude to work with it but it also makes it easier for me to work with it.

Claude often makes a hash of our legacy code and then i go look at what we had there before it started and think “i don’t even know what i was thinking, why is this even here?”