Vibe coding works great. Until you need to onboard someone else to the project.
I've been building with Cursor and Claude Code for a few months now. It's incredible for speed. I can go from idea to working prototype in days.

But last week, I hit something I wasn't prepared for.
I needed to bring another developer onto the project. Someone who hadn't been in the chat history. Who didn't know the 47 prompts that shaped the architecture.
And I realized: I couldn't explain how the codebase worked.
The problem:
When I vibe code, I'm in a conversation. The AI and I go back and forth. It suggests something, I correct it, it refines, we iterate.
But all that context lives in chat history. Not in the code.
The code works. But the decisions behind the code aren't documented anywhere.
Why is this function structured this way?
What assumption led to this architecture?
Why did we choose this approach over the other one?
I know the answers. But they're in my head (and in 6 different chat sessions).
What I'm trying:
Writing "decision logs" after each major AI session
Using comments in the code to explain why, not just what
Asking the AI to summarize its own design choices
But honestly? It's slow. And it feels like it defeats the purpose of vibe coding.
Question:
If you've vibe-coded a project that someone else later had to work on: how did you handle the knowledge transfer?
Or if you're working solo: do you even worry about this, or is it a problem for "future you"?
Replies