Manu llegó a Mate & Build sin ninguna expectativa. Su equipo tardaba días en crear un email de marketing — desde la idea hasta el HTML final listo para Braze por el dinamismo del día a día y la cantidad países. Tres horas después, lo hacían en 10 minutos. Esto es lo que construimos, por qué lo armamos así, y qué se rompió en el camino.
"Armar un email nos lleva días y pasa por 3 equipos"
Manuela Fernández del Tejo trabaja como Fintech Marketing Strategist en PedidosYa, manejando brand, content y media. Su dolor era concreto: crear un email marketing para Braze requería coordinar contenido, diseño y maquetado HTML — un pipeline que consumía días entre idas y vueltas con distintas áreas.
Llegó a Mate & Build — las sesiones semanales de problem-solving con AI que organiza Patricio Iturraspe — con 3 problemas. Uno era demasiado complejo para 3 horas. Nos enfocamos en los 2 que compartían el mismo eje: la creación de emails en Braze.
Lo que me dijo al sentarse fue honesto: no le tenía nada de fe. Cero expectativa.
El pipeline completo era el problema, no la redacción
Cuando nos sentamos a desarmar el proceso paso a paso, apareció lo que el ritmo del día a día nunca deja ver. No era solo redactar el contenido. Era pensar la estructura, escribir para múltiples segmentos con variables dinámicas de Braze, convertir todo a HTML production-ready compatible con Outlook, Gmail y Apple Mail — con condicionales MSO, VML para botones, responsive design — y cargar todo con los custom attributes correctos.
Cada pieza de ese proceso vivía en una persona o equipo distinto. Ahí se iba el tiempo.
La pregunta dejó de ser "cómo automatizamos la escritura" y pasó a ser "cómo armamos un sistema que cubra el pipeline completo y que mejore solo con el uso".
Por qué 2 skills separados y no un pipeline monolítico
La decisión de diseño más importante fue separar responsabilidades. Podríamos haber armado un solo skill que tomara un brief y escupiera un HTML. Elegimos no hacerlo por una razón práctica: cuando algo falla en un monolito, no sabés dónde se rompió.
Dos skills en Claude Code y un reference file permanente.
email-drafter redacta el contenido en texto plano estructurado — HERO + CUERPO + CTA. Soporta múltiples segmentos y variables dinámicas de Braze. Output limpio: solo lo que dice el mail, sin HTML, sin diseño.
email-to-html toma ese texto plano y lo convierte en HTML production-ready. Tablas para layout, inline styles, condicionales MSO para Outlook, VML para botones CTA, responsive con media queries. La estructura tiene 10 rows: logo, hero con versiones mobile/desktop, cuerpo, tagline, cards, cierre, ayuda y footer.
html-structure-reference no es un skill — es un reference file permanente. Documenta la estructura HTML como patrones (~3k tokens) en vez de pegar HTMLs reales de producción (~10-15k tokens). Los dos skills lo consultan como fuente de verdad para colores, assets y especificaciones de cada componente.
Si el contenido está bien pero el HTML sale mal, solo tocás el skill 2. Si agregás un segmento nuevo, solo tocás el skill 1. No rompés lo que ya funciona.
7 iteraciones fallidas fueron la parte más valiosa
Acá viene la parte que nadie cuenta.
Las primeras iteraciones no funcionaban. Los custom attributes de Braze se mapeaban mal, el HTML salía roto, la estructura no respetaba las especificaciones. Fueron casi 7 iteraciones hasta lograr un mail production-ready. Cada una enseñó algo que las anteriores no podían mostrar.
Y el error más revelador: al principio le dimos el template de referencia en PDF. Parecía lógico — es el formato en el que el equipo lo tenía. Pero Claude Code no podía parsear bien la estructura desde un PDF. Los estilos se perdían, la jerarquía de rows se confundía, los componentes no se distinguían.
Recién cuando le dimos templates HTML reales como referencia, la calidad del output subió drásticamente. La lección es un patrón que aplica a cualquier skill: la calidad de lo que le das como referencia define exponencialmente la calidad de lo que sale. Un PDF "se parece" al resultado final pero no tiene la información estructural que el sistema necesita. Un HTML tiene la verdad completa.
"Realmente no lo puedo creer. Realmente me sorprendió. Pensé que iba a solucionarme un 80%, pero la verdad que fue un 98. Increíble." — Manu
Por qué elegimos que el sistema aprenda solo
Lo que realmente separó este build de una automatización común fueron los self-modifying prompts. Podríamos haber entregado 2 skills y un reference file estáticos que funcionan bien hoy. Elegimos agregarle la capa de aprendizaje porque el valor real no está en resolver el problema de hoy — está en que el sistema resuelva mejor los problemas de mañana.
Tres archivos hacen el trabajo: prompts que se modifican solos, lessons que se acumulan, y memoria persistente. Cada vez que un skill genera un mail y tiene un error — un campo dinámico mal mapeado, un estilo que no renderiza, una estructura que rompe en Outlook — el sistema lo guarda como lesson. La próxima vez que corre, consulta esas lessons antes de generar.
No repite el mismo error dos veces.
El sistema que Manu se llevó ayer no es el mismo que va a tener en un mes. Va a ser mejor. Cada mail que genere lo entrena. Cada corrección que haga el equipo se convierte en conocimiento permanente.
De días a 10 minutos — y lo que queda
Sin el sistema: idea del mail, redacción con el equipo de contenido, diseño, maquetado HTML, carga en Braze con custom attributes. Días.
Con el sistema: idea del mail, email-drafter (2 min), email-to-html (3 min), revisión rápida, carga en Braze. 10 minutos.
Y la calidad sube porque cada skill trabaja con especificaciones precisas, no con interpretaciones de un brief. La html-structure-reference es la fuente de verdad que elimina la ambigüedad entre lo que contenido pidió y lo que desarrollo interpretó.
El tercer problema que Manu trajo — el más complejo — quedó afuera del scope. Es el próximo paso natural. También hay espacio para iterar: más templates de referencia, más lessons acumuladas, y eventualmente conectar el output directo a la API de Braze para eliminar el paso manual de carga.
Pero eso es optimización. Lo que tiene hoy ya cambió el juego.
Takeaways
- Separar responsabilidades > monolito: 2 skills + 1 reference file donde cada pieza hace una cosa bien.
- Referencia en el formato final, siempre: un PDF "se parece" al resultado pero un HTML tiene la verdad estructural.
- Self-modifying prompts convierten herramientas en sistemas: lessons y memoria hacen que cada error se convierta en mejora permanente.
- Iterar no es fallar: 7 iteraciones hasta production-ready.
- El valor más grande es la replicabilidad: Manu se llevó la estructura para que su equipo en PedidosYa cree skills nuevos siguiendo el mismo patrón.
Conceptos aplicados acá
- File system para IA — 2 skills + reference file en lugar de un mega-prompt monolítico.
- Context engineering — self-modifying prompts y memoria persistente que mejoran el sistema con cada uso.
- IA para marketing — cómo un equipo de marketing en una empresa LATAM construye su propio sistema sin depender de IT.