Diagram first, then Cline
The tip he wishes he'd shared earlier: before any vibe coding, spend at least 20% of the time planning, argue the architecture with Gemini until it survives as a Mermaid diagram, then hand Cline the diagram, and the prototype falls out fast.
// trace: where this idea came from
- ↳ video diary @ 1:03 (el 20% mínimo de planeación)
- ↳ video diary @ 3:41 (el diagrama como detector de errores)
- ↳ video diary @ 4:13 (la entrega: tenga en cuenta este diagrama)
The lesson opens with a number: when vibe coding, “intente meterle como un 20% mínimo de tiempo a pensar los detalles” before generating anything ▸ 1:03, and with a scope rule attached, a prototype exists to test the idea, so the eyes and the delights are details to postpone, not specify.
His planning artifact, being “una persona visual” ▸ 2:00, is a Mermaid diagram of Severo’s backend, generated by Gemini, rendered in VS Code through a Markdown extension ▸ 2:28. The diagram isn’t documentation; it’s an instrument: laid out as boxes and arrows, the design exposes its own nonsense, “de repente tú dices: no tiene sentido enviar los datos de aquí acá y después acá” ▸ 3:41, and each objection becomes another round of dialogue with Gemini until the flow holds ▸ 4:10.
discute con el diagrama antes de discutir con el código →
Then the handoff that makes the method pay: the finished diagram goes to Cline as the spec, “hagamos esto, tenga en cuenta este diagrama” ▸ 4:13, and the prototype “lo hice muy rápido, gracias a eso” ▸ 5:07. It’s the exact inverse of the yolo migration two days earlier: there, the agent generated freely and nothing ran; here, the human spends the cheap currency, boxes and arrows, before spending the expensive one. The diagram is where design mistakes cost one message instead of one day…
// continued in
no entry has continued this idea yet: the arc is still open