Claude + Cursor: cómo cambié mi relación con el código de prototipos.

Durante años, el brief fue un objeto discreto: un documento que abríamos al principio del proyecto, volvíamos a leerlo a mitad con cierta culpa, y lo cerrábamos al final para compararlo contra lo entregado. En 2026 esa relación ya no funciona. Cuando una parte significativa del trabajo se hace con un modelo — uno que responde, corrige y propone — el brief deja de ser un contrato y empieza a parecerse a una conversación larga.

Esta semana probé tres formatos distintos con el equipo de Ofelia Labs. El objetivo era simple: ¿puedo mantener dirección creativa sin matar la parte útil de la sorpresa? Comparto lo que sí funcionó, lo que no, y una cuarta versión que apareció por accidente.

01El brief como sistema operativo

La primera versión intenta tratar al modelo como a un diseñador junior muy capaz pero sin contexto. El documento tiene cuatro bloques fijos: principios, restricciones, referencias y criterios de éxito. Es predecible y ayuda a alinear, pero pronto descubrí el problema: convierte cada interacción en una negociación de alcance, no en una colaboración.

El brief debe ser lo suficientemente estricto para orientar, y lo suficientemente blando para que todavía ocurran cosas que no habíamos anticipado.Nota del sábado 12 · ABR

Qué conservé

• Los principios, escritos como frases imperativas cortas.
• Una lista de no objetivos — más útil que la lista de objetivos.
• Un solo criterio de éxito, no cinco.

02El brief como guion

La segunda versión eliminó el documento y lo reemplazó por una lista de preguntas ordenadas. El modelo respondía; yo respondía; iterábamos. Funcionó bien en proyectos cortos, pero se derrumbó en cuanto intentamos aplicarlo a un sistema de diseño — demasiado ruido, poco acumulado.

Lo que aprendí

1. Un guion funciona cuando el trabajo tiene principio y fin claros.
2. No funciona cuando el proyecto tiene que sobrevivir al proyecto mismo.
3. Para productos vivos, necesitas algo más parecido a una constitución.

03El brief como manifiesto

La tercera versión — la que se quedó — es una mezcla entre el documento y el guion. Empieza con un manifiesto corto (cinco frases, máximo), seguido por ejemplos concretos de lo que sí queremos ver y lo que no. El resto es una conversación registrada, revisada cada viernes.

# brief.md — Ofelia Labs · análisis facial

manifiesto:
  - Cada recomendación debe poder justificarse con una medida.
  - La confianza del sistema se comunica, no se esconde.
  - El texto es material, no decoración.
  - Nunca sustituimos la opinión del médico.
  - Si dudamos, callamos.

ejemplos_si: dashboards/Ofelia-03, Teenage Eng. OS
ejemplos_no:apps de “belleza”, filtros, AR gimmicks

Por qué funcionó

Porque convierte al modelo en un colaborador con memoria compartida, no en un ejecutor de prompts. El manifiesto se lee antes de cada sesión. Los ejemplos corrigen cuando las palabras no alcanzan. Y el registro permite que el proyecto tenga historia propia.

04La cuarta versión, por accidente

Un viernes le pedí al modelo que reescribiera el manifiesto con sus propias palabras. El resultado era peor — más verboso, más genérico — pero el ejercicio obligó a clarificar tres puntos que el equipo no había discutido del todo. Desde entonces, una vez al mes reescribimos el manifiesto a cuatro manos. Nunca usamos la versión del modelo. Pero la conversación previa vale más que el documento final.

Y ahí está el accidente útil: el brief más poderoso no es el que le das al modelo. Es el que escribes con él.

05Qué me llevo

• Escribir menos. Corregir más.
• El manifiesto antes que el documento.
• Los ejemplos contradictorios son más útiles que los ejemplos “buenos”.
• Cualquier plantilla que no se actualice cada semana, ya está vieja.
• El silencio ocasional del modelo es, a veces, la mejor señal de que vamos bien.

— MF · 13 · dic · 2025 · Ciudad de México