Vibe coding works great. Until you need to onboard someone else to the project.

by

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"?


13 views

Add a comment

Replies

Be the first to comment