Vibe Coding Didn't Skip the Docs: It Skipped the Knowledge.
There are teams right now sitting on internal tools that work—well, some of the time—and nobody can tell you why.
Not “we didn’t write it down.” Not the old kind of underdocumentation, where the knowledge lived in someone’s head and you could at least corner them at lunch and ask. The knowledge isn’t anywhere. The owner typed a prompt. The AI generated something. It ran. They shipped it. No one could walk you through the architecture because they never had to understand it in order to make it.
It’s a headache. It causes nausea and the sweats when you realize no one knows how it works. It’s the vibe coding hangover.
Documentation has always been a convenient thing to defer. Tight sprint, ship the feature, write the docs later—anyone in a documentation role has been there (or should have been there). But the knowledge was still there, somewhere. The developer knew what they’d built, even if they never typed it out. With the clock ticking, the docs were optional; the comprehension was table stakes.
Vibe coding changes the deal. When you build by prompt, describing the vibe, accepting the output, iterating until it works, you can ship something functional without developing a working mental model of it. That’s kind of the point. Moving fast means not stopping to understand. The code runs; knowledge of the thing is a downstream problem.
And then the downstream problem arrives.
What Documentation Actually Is
I’ve spent years meeting and messaging with Product Managers and Engineers to write documentation, and the part of that process people underestimate is the friction. The moment when I’d ask an engineer to walk me through what happens when a user hits a particular edge case. They pause, reach for their laptop, and I’d realize the answer didn’t exist in their head yet either.
That’s not a failure of documentation. That’s documentation doing its job. The act of explaining a thing to someone who wasn’t there forces you to understand it yourself. You can’t write “the system processes the input and returns a result” if you actually need to tell someone what to do when the result is wrong.
Good documentation isn’t the output of knowledge. It’s the process that produces knowledge.
When you vibe-code, you skip that process.
The industry has been noticing this. Mysterious bugs that trace back to logic nobody had reviewed; code that works exactly as the prompt specified—and it specified the wrong thing; the new hire who asked how something worked and learned that the honest answer was “it kind of just does.”
And naturally, the companies that embraced vibe coding fastest were often the same companies that had already gutted their documentation teams. Two careless efficiency moves that made perfect sense on a slide deck, compounding into a big problem downstream.
The technical writer’s job was never just to write. It was to be the person who stopped and said: wait, what does this actually do? The person who forced the system to become legible—who sat with the engineer and kept asking questions until the explanation didn’t fall apart. You cut that person, and then you adopted a development practice that produces illegible systems at scale, and didn’t notice the connection.
Vibe coding is not going away. The productivity gains are real, the accessibility to non-developers is genuinely useful, and some of the tools that shipped are actually good. I’m not nostalgic for the era of expensive, over-engineered nothing.
But there’s a difference between moving fast and moving without any record of what you built or why.
The vibe coding hangover isn’t primarily a code quality problem, even though it looks like one. It’s a knowledge problem. And knowledge problems don’t get better by throwing more AI at them.
Someone has to understand the thing. That work will get harder when the people trained to do it are the ones we decided we didn’t need.