Mapa de la ruta
Contenido detallado
🌱 El prompt mínimo viable
El prompt más pequeño que pasa la primera prueba: identidad + un contrato. Resiste la tentación de anticiparte y define «funciona» antes de escribir más.
El impulso del principiante es volcar todas las reglas de una vez. Empezar con lo mínimo es lo contrario: el prompt más pequeño que ya aporta valor.
Cada regla que no necesitas sigue siendo una deuda —código muerto que confunde al modelo y oculta la causa real de los errores.
Mínimo viable · superficie pequeña = depuración fácil · agrega solo cuando haya una necesidad real.
Solo dos partes: quién es el agente (identidad) y qué se compromete a hacer (un contrato). Todo lo demás es opcional.
Es el núcleo que no puede faltar. Sin él, no hay prompt; si agregas algo más en el v0, ya estás anticipándote.
Identidad · contrato único · núcleo irreducible.
Anticipar es escribir una regla para un problema que aún no ha ocurrido. Parece prudencia, pero es deuda acumulada.
Las reglas especulativas inflan el prompt, crean conflictos y ocultan cuáles son realmente importantes.
YAGNI en el prompt · reglas solo ante fallas reales · evitar la acumulación especulativa.
"Funciona" no es un sentimiento. Es un criterio concreto —entrada + comportamiento esperado— que indica sin ambigüedad si el v0 cumple el contrato.
Sin una prueba de referencia, agregas reglas a ciegas y nunca sabes si la siguiente línea ayudó o perjudicó.
Criterio objetivo · caso de entrada→salida · ancla antes de crecer.
Armamos un prompt-v0 completo para un agente de clasificación de inbox: solo identidad + 1 contrato, nada más.
Ver el MVP armado vuelve tangible el concepto: reconoces qué es esencial y qué sería anticiparse demasiado.
Agente de clasificación · prompt conciso · un caso de prueba pareado.
Dos archivos pequeños versionados en git: el prompt-v0 y la primera prueba que supera.
Es la base de tu laboratorio personal: la primera y más importante línea base del repo de evolución.
prompt-v0 · prueba-ancla · primer commit.
🔁 Evolución mediante diff y consolidación
El motor del prompt: probar → encontrar un fallo real → corregir con UN patrón del catálogo. En cada ronda, consolidar y versionar en git con changelog.
Los prompts evolucionan con el uso. El motor es un ciclo corto y honesto: ejecútalo en un caso real, observa el fallo, corrígelo.
Sin el ciclo, "mejoras" el prompt a ciegas. Con él, cada cambio nace de una falla observada de verdad.
Ciclo corto · caso real · fallo observado, no imaginado.
La corrección madura aplica un único patrón del catálogo de la Trilha 1 — no acumula reglas aisladas.
Es lo que diferencia a un prompt que envejece bien de una «cebolla de reglas» cada vez más difícil de mantener.
Un patrón por corrección · catálogo · evitar la acumulación por capas.
Un ritual programado: cada N ciclos, dejas de agregar y fusionas, recortas o reescribes las reglas redundantes.
Agregar es fácil; eliminar exige valentía. Sin el ritual, el prompt solo crece y nunca se reduce.
Ritual programado · fusionar/recortar · prompt que respira.
El diff de Opus 4.8 a Fable 5: se agregó mucho contenido nuevo y, aun así, el prompt quedó más conciso donde importaba.
Es la prueba real de que la evolución y la consolidación conviven: el proveedor agrega y poda en la misma ronda.
Diff oficial · agregar y podar · referencia viva.
Cada ciclo y cada consolidación se convierten en un commit. Git transforma el prompt en un artefacto con un historial rastreable.
Sin control de versiones, pierdes el historial y no puedes revertir una regla que empeoró las cosas.
Commit por cambio · diff legible · reversibilidad.
Cada entrada del changelog etiqueta el cambio según el patrón aplicado y el fallo que lo motivó.
El commit guarda qué cambió; el changelog guarda por qué, y ese porqué permite revisar la decisión después.
Motivo registrado · patrón + falla · decisión revisable.
✅ Pruebas y el porqué documentado
La regla de oro: cada regla necesita un porqué documentado Y una prueba que fallaría. Sin eso, no se incluye. Medir con pruebas, no con opiniones.
Una sola frase sostiene el recorrido: toda regla agregada necesita un porqué documentado Y una prueba que la justifique.
Es el filtro que mantiene el prompt conciso y auditable; sin él, las reglas se agregan por costumbre y nunca se eliminan.
Porqué + prueba · filtro de entrada · prompt auditable.
No es una prueba unitaria de código: es un caso de entrada + comportamiento esperado que, sin la regla, fallaría.
Si no puedes escribir la prueba que fallaría, la regla no tiene un efecto medible y probablemente sea innecesaria.
Prueba que fallaría · entrada→salida · efecto medible.
El prompt tiene una puerta y la prueba es la llave. Las reglas sin prueba quedan en la fila, no en el prompt.
Parece rígido, pero es lo que evita que vuelva la acumulación: nada se incorpora sin pruebas de que marca la diferencia.
Puerta de entrada · prueba = clave · regla en espera vs. en el prompt.
Se conecta directamente con el Patrón 3 (Regla con porqué): una prohibición tajante se obedece al pie de la letra, pero falla fuera del caso exacto.
El porqué le da al modelo el principio, no solo el caso concreto: es lo que hace que la regla se aplique a casos que no escribiste.
Principio > prohibición tajante · generalización · Patrón 3.
El entregable: una suite mínima de pruebas vinculada al changelog: una prueba por cada regla que merece existir, ni más ni menos.
Vincula cada regla con su evidencia y su motivación, cerrando el ciclo entre prompt, prueba e historial.
Suite mínima · 1 prueba por regla · trazabilidad prompt↔changelog.
La regla de oro refleja la dirección de los proveedores: la industria pasó de "más reglas" a "reglas medidas".
Las decisiones basadas en pruebas son reproducibles y defendibles; las decisiones basadas en opiniones son un debate interminable.
Evidencia > opinión · reproducibilidad · alineado con el mercado.
🚀 Proyecto final versionado
Todo converge: prompt + registro de cambios etiquetado por patrón + conjunto de pruebas en un repo con control de versiones. Criterio final: menos líneas, mismo comportamiento.
Todo lo que construiste en las Rutas 1 a 4 converge en un solo repo: el prompt, el registro de cambios y las pruebas conviven allí.
Un artefacto coherente y con control de versiones es lo que llevas al mundo real: listo para el mantenimiento y la revisión.
Repo cohesivo · prompt + changelog + pruebas · artefacto final.
Cada entrada del changelog apunta exactamente a un patrón del catálogo de la Ruta 1 — no basta con «agregué una regla».
Etiquetar según el patrón conecta tu práctica con la teoría y permite verificar cada decisión con respecto al catálogo.
Etiqueta del patrón · catálogo T1 · decisión trazable.
Las pruebas no verifican el texto del prompt — verifican el comportamiento que produce. Cada prueba es una promesa.
Probar el comportamiento (no las palabras) permite reescribir y simplificar el prompt sin miedo a romper lo que importa.
Contrato de comportamiento · input→output · refactorizar de forma segura.
El criterio de aprobación es contraintuitivo: el prompt entregado debe tener menos líneas que el borrador intermedio.
Reducir manteniendo todas las pruebas en verde demuestra madurez: dices lo mismo con menos.
Densidad > volumen · suite en verde · concisión como objetivo.
No es cuestión de gustos, es un procedimiento: ejecuta la suite (base en verde), recorta o combina y vuelve a ejecutarla: solo sirve si sigue en verde.
Consolidar midiendo con pruebas elimina el miedo a recortar: la suite te dice enseguida si rompiste algo.
Línea de base verde · cortar→volver a ejecutar · procedimiento medido.
El repo entregado no es el final — es el comienzo de tu práctica, el lugar donde aplicas los rituales del recorrido de ahora en adelante.
Internalizar los rituales (ciclo, consolidación, regla de oro) es lo que distingue a quien hizo el curso de quien mantiene prompts de verdad.
Repositorio vivo · rituales continuos · práctica más allá del curso.