"Let me show you the best way to vibecode today without agents making a mess." The post developer sammwy put on X passed 90,000 views and 2,600 likes in a day. It's a one-line tip that's hard to call news, but the size of the response is also evidence that many people are struggling with the same problem. You know the experience: you tell a coding agent "build this," the first few hours go astonishingly well, and then at some point it starts pouring out code that doesn't hang together.
The Moment the Conversation Ends, the Context Goes with It
The point where vibe coding falls apart is usually the same. As you toss out and revise requirements on the fly in a chat window, "what we decided to build" ends up scattered somewhere in the conversation log. The agent has to re-infer the flow of that conversation from scratch every time, and when a session grows long or work is handed to another agent partway through, the details agreed on earlier vanish wholesale. The output goes off the rails not because the agent is incompetent but because the instructions it received were vague and volatile to begin with.
The Process of Condensing a Conversation into a Spec Document
The fix sammwy proposes isn't a new tool. It's changing the order. First, open an ordinary chat window like ChatGPT, talk freely about what you want to build, and refine the idea iteratively. This stage isn't about writing code. It's closer to a process of making clear to yourself what you're going to build.
Once the outline takes shape, ask it to organize all the technical content from that conversation into a SPECS.md file. Things like screen structure, data flow, exception handling, and priorities get condensed from prose conversation into document form at this point. Then put that SPECS.md file in your project folder and hand it as-is to a coding agent like Claude Code to implement. When requirements change midway, instead of going back to chat to refine again, updating SPECS.md itself and having the agent read it again is far more stable.
Why One Document Beats a Vague Conversation
The principle is simple. A conversation is context stacked in time order, so contradictions creep in easily, and the agent has to reread and reinterpret the whole thing every time. A spec document, by contrast, is a static reference point with only the conclusions left. From the agent's side, it only has to check "what has been decided," not "what needs to be judged," so it uses less of its context window and produces more consistent results. In that it separates the language used when people talk to agents from the language used when agents collaborate with agents, it also lines up with the "spec-driven development" trend that has spread widely in the Claude Code and Codex ecosystems recently.
But this workflow isn't the only right answer. On team projects, an issue tracker or an RFC document is often used as the spec reference instead of SPECS.md, and how detailed to make the spec varies with the nature of the project. We also can't tell from the publicly visible part of the original thread what specific tips came after this step. Even so, the three-step structure of "organize your thinking in conversation, condense it into a document, hand it to the agent" is a habit worth trying right away, regardless of tools or project size.