Code Documentation Is Dead — and Engineers All Over the World Are Celebrating

I was working with an engineer recently on scoping a new technical project. The work itself wasn’t unusual: we’d need to interface with a codebase that had been written by a different engineering team a few years ago. As we walked through the scope, I kept coming back to the same question, the one anyone who has lived through legacy systems inevitably asks.

What does the documentation look like?

Do we have enough detail to understand how the code works? Are we going to spend weeks scratching our heads trying to figure out how different subroutines, algorithms, and APIs behave across a codebase with thousands of lines of logic?

At one point, the engineer looked at me and said, very matter-of-factly:
“Oh, I’ll just take the whole codebase, plug it into an LLM, and have it generate the documentation.”

And in that moment, something clicked in my understanding of the future of coding. The world of code documentation is dead. And it couldn’t have happened fast enough

.

Engineers are going to celebrate this shift globally, not because documentation was unimportant, but because it was always one of the most painful, time-consuming, and inefficient parts of software development. AI and large language models haven’t just improved documentation. They’ve made the old way obsolete.

To understand why this is such a big deal, you have to understand what documentation actually meant in the past.

When I was writing code, especially early in my career for large financial institutions—the hardest part was rarely the logic itself. Designing the system, figuring out the flow, and writing the code was often the most intellectually interesting part of the job.

The real grind came afterward.

You had to document everything: what the code did, why it existed, who wrote it, when it was written, what dependencies it touched, and how someone else might safely modify it years later. The prevailing philosophy was simple: if an engineer showed up a decade from now, they should be able to understand your work quickly and confidently.

In theory, that made sense. In practice, it was brutal.

I’ll date myself here, but when I was coding COBOL systems on mainframes in the 1990s for major financial institutions, the process was extreme. We’d write the code, then separately document it—often in Lotus Notes or Microsoft Word. That documentation would then be printed, hole-punched, and physically stored in binders.

Not dozens of binders. Thousands of them. Entire walls were stacked floor to ceiling with labeled binders documenting specific parts of the system. Banks and insurance companies ran on massive codebases, heavy security controls, and obsessive documentation practices. And we all joked—half bitterly, half resigned—that for every hour of code we wrote, we spent three hours documenting it.

That was just how the world worked. And to be fair, when documentation failed, the consequences were very real.

In 1997, I was responsible for managing a mainframe system that served as the general ledger and financial accounting backbone for a large insurance company. One day, a controller called and explained that two entries in the database, made years earlier, needed to be reversed. Doing it through the general ledger would be tedious and messy. It would be far easier to delete the entries directly from the database.

This wasn’t some rogue request. The controller had approval from the CFO and internal compliance. The request came through my manager. Everything was by the book.

I researched the issue, went into the database, deleted the two entries, verified they were gone, ran tests, and confirmed the changes. I reported back. Everyone signed off.

The next day, the finance team called and said the entries were still there.

Assuming I’d made a mistake, I repeated the process, this time with another engineer watching every step. We verified the deletions across production, staging, test, and backup environments. Everything looked correct. We pushed the changes again and confirmed success.

The following morning, at 10 a.m., my phone rang.

They were furious. Nothing had changed.

At this point, it was a five-alarm fire. Either we were completely incompetent, or something deeply strange was happening. My manager told us to pull the documentation. We went through binder after binder. Nothing explained what we were seeing.

So we did what engineers always do when the paper trail fails: we went to the code.

After a full day of combing through thousands of lines of code written decades ago, I finally found it. Buried in the system was an undocumented subroutine written years earlier. Its sole purpose was to monitor the production database for manual changes, and silently restore any additions or deletions after midnight.

It was an anti-embezzlement safeguard. Even if someone had access, approval, and intent, the system would quietly undo the change.

Brilliant control. Zero documentation.

We eventually brought everyone into a room—the CFO, the controller, my manager, another engineer, and me. Instead of being angry, they laughed. Whoever wrote that code had done their job extremely well. In the end, the finance team chose to reconcile the books via the GL interface as the system intended, rather than touch the system.

But it cost us days of work to uncover something that proper documentation would have revealed in an hour. That experience burned the importance of documentation into me. And yet, even with stories like that, documentation has always been a losing battle. It decays. It drifts. It falls out of sync with reality.

Which brings us back to today. What’s happening now is not that engineers care less about clarity. It’s that documentation is no longer something humans need to write by hand. Engineers can now build a system, test it, validate it, and then ask an LLM to analyze the entire codebase and generate clear, structured, up-to-date documentation—on demand.

Not summaries written months later. Not binders frozen in time. But living explanations that match the code as it exists.

This will save thousands of hours across the lifecycle of a system. Engineers won’t just be faster at coding, they’ll be dramatically faster at finishing. And the documentation produced will often be more thorough, more consistent, and less error-prone than what humans historically created under time pressure.

People love to talk about being “10x engineers” because of AI. That’s fine. But honestly, what excites me just as much is the quieter gain: engineers no longer spending massive chunks of their careers writing documentation that machines can do better.

So yes, code documentation, as we knew it, is dead.

And as someone who spent years living in binder rooms, fighting undocumented systems, and paying the price for missing context, I couldn’t be happier about it.