A lot of coding wisdom gets passed from one generation of engineers to the next as a kind of meme: highly distilled, compressed lessons learned. NIH syndrome. Don’t rewrite the codebase. Optimize for readability. These are useful shorthands that encode real, hard-won experience into a form that’s easy to remember and easy to pass along. Except that the ground has shifted under us, and because the knowledge is so highly compressed into these acronyms and concepts it’s difficult to tell which parts still apply. Like any good meme they’re optimized for transmission, not for accuracy, and nobody stamped an expiry date on them.

Take NIH (not-invented-here syndrome). This was useful advice for a long time, because it’s a common junior (and not so junior) engineer failure mode: the code is complex, seemingly needlessly so, so you rewrite it. Anyone who’s been through this knows that 9 times out of 10 you discover that the so-called “needless” complexity was actually working around real but non-obvious problems, and you end up either going back to the original “complex” code, or worse, your new simple codebase slowly expands until it’s just as complex as the previous one while you painstakingly relearn the lessons the last generation of engineers had already learned.

Is NIH syndrome still a thing in 2026? I’m honestly not sure. The cost of a rewrite is still not zero, but it’s definitely a lot lower than it was back when the acronym was invented. Whether or not it still matters depends on assumptions that were baked into the acronym so long ago that nobody thinks to question them anymore. NIH might still be good advice. It might also be halfway through its half-life, still looking solid while quietly becoming less true every month.

This is the problem with engineering lore in general. These rules were the right rules, derived from real experience, and then packed down into acronyms and aphorisms so they’d travel cheaply between engineers. But the packing stripped out the assumptions they rested on. The cost of a rewrite has dropped. The maintainer of your code might be an AI, and readability to an AI might mean something very different than readability to a human. The assumptions have changed and you can’t unzip the heuristic to check whether it still holds. You don’t know which of your engineering instincts are still load-bearing and which ones decayed out from under you while you weren’t looking.

Which brings me to the part of this that I find most interesting. Take a fictional example: a smart college grad who majored in a non-technical field, but started to get interested in coding after seeing what the latest agents are capable of building. They would essentially start off vibe coding. Thing is, if they built a few vibe coded systems and stuck with it they’d start learning a lot of lessons about code maintainability and scalability and best practices. And the scar tissue they acquire this way would probably be pretty analogous to the scar tissue a “real” engineer would pick up.

But some of the lessons they learn would be ones we haven’t fully articulated yet. A vibe coder in 2026 is barely going to look at the code. They’re going to read their coding agent’s summaries of the code, and iterate on those summaries. And honestly? This is probably not a bad thing. If your AI is writing the code and your AI is maintaining the code, then optimizing that code for human readability is a kind of nostalgia.

Readability isn’t gone though. It migrated. There used to be one interface: human reads code. Now there are two: the agent reads the code, and the human reads the agent’s description of the code. You need “readability” at both of those boundaries, it’s just that neither one looks like what we used to call readability. Code still needs to be legible to agents, which could mean very different things than what made it lWe don’t even have a transmissible meme for ‘the agent did exactly what you asked and that’s how you found out your instructions were wrong’ yet. Time to make some engineers and vibe coders are converging on this same problem from different directions. The vibe coder hits it from below: they need the agent to explain what’s going on because they can’t read the code themselves. The experienced engineer hits it from above: they can read the code but increasingly shouldn’t have to, because it’s not a good use of their time. Both of them need the same new skill, which is something like: how do you get an agent to talk about a system in a way that lets you actually steer?

The old lore was about how to write and maintain software. The new lore, the memes that this generation will compress down and hand to the next, is going to be about how to specify, verify, and supervise. How to tell the difference between a passing test and a working feature. When to trust the summary and when to dig in. How to write constraints that hold up when an agent runs unsupervised for nine hours. These aren’t coding skills in the way we’ve traditionally understood them, but they are engineering skills, and they’re being learned right now through trial and error by everyone who’s working this way.

The experienced engineer and the vibe coder are in the same position right now: neither of them has lore for this yet. For the vibe coder that’s normal and expected, they’re beginners after all. For the experienced engineer it’s potentially uncomfortable, because the whole value of experience is supposed to be that you’ve seen this before. Nobody has seen this before. And that means it’s time to start paying attention to the lessons we’re learning through trial and error right now, and compressing them down into the next generation of engineering memes before we forget why we learned them. We don’t even have a transmissible meme for ‘the agent did exactly what you asked and that’s how you found out your instructions were wrong’ yet. Time to make some.