How do you stay familiar with the code when it's written by an LLM?<br>Articles<br>Culture<br>Careers<br>Aha!'s GitHub organizationFind our posts on Hacker NewsAha! engineering blog RSS feed<br>Aha! Develop is the agile tool that links strategy to delivery.

Learn more

Justin Weiss · 2026-07-16 · ai, engineering<br>How do you stay familiar with the code when it's written by an LLM?<br>If you used an LLM to write code you shipped a month ago, how well do you remember it? Would you realize if the code you committed today would break it? If a customer reported a bug, would you quickly think, "Oh, I know what that is" in the same way you used to?

As you have LLMs write more code, you'll quickly realize you're less familiar with the code you ship. You have a harder time remembering the decisions you made. You no longer instinctively know where the code lives. If someone asks you a question about it, you have to go back to the LLM instead of answering off the top of your head. Over time, you have to delegate more work and more understanding to the LLM. Your guidance to the LLM gets worse as you lose knowledge of the code. And when the LLM struggles to write the next feature, you don't even know what the cause is, let alone how to help.

Is this just what software development is now? How can you be responsible for code you don't understand?

Does it matter?

Maybe you don't care! Maybe next month's LLM will just solve the problems caused by this month's model. Maybe you are entirely outcome-focused, and the code doesn't matter as long as it solves your problem. Maybe this is a one-off project that just replaces something you would have downloaded a package for, if only it existed — you wouldn't have looked at that code, right?

But if this is an app you or your company depend on, that you are crafting over time, it does matter. People rely on what you produce, and the work you do today has to live on indefinitely.

You have to care about the how, and not just the what.

Writing the code by hand, creating and fixing problems, deciding where this new code goes, refactoring old code to make it better — all these build your intuitive understanding of the code. When someone finds a bug and you immediately guess the answer, it's based on that intuition. It's how you know that changing a value over here will need a migration over there. It's why you have teams that focus on different areas of the code. And if you're not careful, code-generating LLMs will keep you from building that intuitive understanding until it's too late.

Meanwhile, AI uses three signals to decide how to write code: training data, the code it sees in your codebase, and your guidance. As you lose your ability to guide the LLM, and as it sees more of the code it wrote and less of the code you wrote, it doesn't matter what your programming processes and philosophies are. It's dragging your codebase to the mean.

So how can you stay familiar with the code as you write less of it?

Make mistakes

Have you ever answered something embarrassingly wrong on a test and still remember the right answer today? As programmers, that failure-to-surprise feeling is why a lot of obscure pieces of information stick with us. When an LLM is generating the code, you don't get to feel that. The process is too smooth.

It's like reading the answers in the back of the book without thinking about the questions first.

Instead, you have to cultivate that feeling of surprise. Look for opportunities to detect mistakes, or even create them. Tell an LLM to try a wild optimization, think about why it won't work, and then see if you're right. Have the LLM give you options without feedback, identify the pros and cons of each, then send it in the best direction (or, because it's an LLM, many directions at once!) and see what comes out. Create opportunities to be surprised and get things wrong. Those will be the parts that stick with you.

Type it yourself

LLMs are much faster than me at the initial implementation of a plan, but much slower at small refinements. When you were first getting used to LLMs, it was nice to push them anyway so you could practice guiding them. Now that you use them all the time, take some of that agency back.

Just like writing your notes helps you remember them, typing your code helps you remember it. If you're making small changes yourself, you have to understand what the LLM has done so far, just like you have to understand enough of any codebase in order to change it. You'll more strongly remember the code you typed and the code you had to learn about to get there.

Ask questions

There are an infinite number of ways to implement a feature. So if you try, you can think of an infinite number of questions about it. Ask these to yourself. How would I have implemented this? How did the LLM do it? Why did it do it that way? Did it miss anything I know about the code? Did I? What other options were there? Why did it pick that variable name? Is there a cleaner way to separate...