PTENES
Inicio / Ruta 4 / Módulo 4.1
🌱
MÓDULO 4.1 Ruta 4 — Construye el tuyo

🌱 El prompt mínimo viable

Lo mínimo que funciona. Antes de escribir cualquier regla, escribes el núcleo irreducible — solo identidad y un contrato — y define una prueba concreta que demuestra que funciona. Este es el prompt-v0: el punto de partida de tu laboratorio.

📋6 temas
⏱~30 min
🎯Práctico
🧪Laboratorio
🌰 La semilla (núcleo) Identidad "You are X" + 1 contrato 🧪 1 prueba "¿funciona?" → sí 🌱 El brote prompt-v0 punto de partida del repo ⏳ Reglas pospuestas — solo se aplican cuando falla una prueba (Módulo 4.2) formato · rechazos · casos límite · tono — NO te adelantes

Contenido detallado

1

Por qué empezar con lo mínimo

El impulso de todo principiante es el mismo: abrir un archivo en blanco y volcar todas las reglas de una vez — formato, tono, seguridad, casos especiales, todo antes de haberlo ejecutado una sola vez. Ese impulso es el enemigo número uno de un prompt robusto. Toda la Ruta gira en torno a resistirlo.

🧭 El principio

Los mejores system prompts de 2026 no son los más largos — son los más consolidados y justificados. Llegaron a un estado conciso después para crecer y podar, no antes. No puedes podar lo que aún no existe. Por eso empezamos con el núcleo más pequeño posible y dejamos que el prompt revele qué necesita realmente, guiado por pruebas que fallan, no por suposiciones.

  • •Cada regla que escribes «por si acaso» es una regla que nadie probó.
  • •Un prompt corto es fácil de leer, fácil de depurar y fácil de explicar.
  • •El comportamiento que no puedas demostrar con una prueba, no lo controlas.
💡

Robusto porque es simple, no a pesar de ello

Un prompt conciso tiene menos superficie para conflictos internos, menos reglas que se contradicen y menos líneas que compiten por la atención del modelo. La simplicidad no es un punto medio: es la fuente de la robustez.

🌱
Primero el núcleo
lo mínimo que funciona
✂️
Recortar > rellenar
crece por necesidad
🧪
Guiado por pruebas
no por suposición
🛡
Robustez
proviene de la simplicidad
2

Identidad + 1 contrato — el núcleo irreducible

El núcleo mínimo tiene exactamente dos partes: quién es el agente (identidad) y a qué se compromete (un contrato). Todo lo demás —formato, negativas, casos límite— es opcional en la v0. Si eliminas cualquiera de estas dos partes, el agente deja de tener sentido. Eso es «irreductible».

🪪 Identidad

Una frase: quién es y, cuando sea útil, en qué contexto opera. Es el ancla que impide que el modelo se desvíe de la persona.

You are a triage assistant for a support inbox.

📄 1 contrato

Una promesa de comportamiento observable: qué entrega, en qué formato y con qué garantía. Un contrato, no cinco.

For each message, output exactly one label: urgent, normal, or spam.

Qué hace que algo sea un «contrato»

Un contrato es una afirmación que puede ser verificada: «la salida tiene exactamente una etiqueta de entre tres». Compáralo con una regla vaga («sé útil y responsable»): esa no se puede probar, así que no es un contrato, sino decoración. La regla práctica: si no puedes escribir una prueba que falle cuando se rompe el contrato, el contrato todavía no está bien definido.

🪪
Identidad
quién es, una frase
📄
Un contrato
promesa observable
🔍
Verificable
se puede probar
🧱
Irreducible
quitar cualquier cosa = se rompe
3

El peligro de anticiparse

Anticipar es escribir una regla para un problema que todavía no ha ocurrido. Parece prudencia, pero es deuda: cada regla anticipada es una regla sin pruebas, sin contexto real y, muchas veces, equivocada, porque adivinaste el problema en vez de observarlo.

✓ Reaccionar ante un problema real

  • •Se ejecutó, falló, viste el fallo → escribe la regla
  • •Cada regla nace con una prueba que la justifica
  • •El prompt crece en la dirección de los problemas que existen
  • •Siempre sabes por qué está ahí cada línea

✗ Anticipar un problema imaginario

  • •"Mejor avisar desde ya que nunca use emojis" — antes de ver uno
  • •Las reglas sin pruebas se acumulan y se contradicen
  • •El prompt se infla alrededor de miedos, no de hechos
  • •Nadie recuerda por qué existe la mitad de las líneas

⚠️ El síntoma del prompt anticipado

Abres un prompt y encuentras reglas para casos que el producto nunca ha visto, prohibiciones de cosas que el modelo nunca ha intentado hacer e instrucciones que nadie puede explicar. Ese es el prompt inflado — y será el villano de la Ruta. El antídoto empieza aquí: nace mínimo.

🔮
Anticipación
regla sin problema
🎯
Reacción
regla tras un fallo real
🎈
Prompt inflado
el villano de la ruta
💳
Deuda
regla sin probar
4

Definir «funciona»: una prueba concreta antes de escribir más

"Funciona" no es un sentimiento. Antes de agregar la siguiente línea al prompt, necesitas un criterio concreto que indique, sin ambigüedad, si la v0 cumple el contrato. Ese criterio es tu primera prueba, y viene antes de cualquier regla adicional.

Del contrato a la prueba, en 3 pasos

1

Toma el contrato y haz que sea observable

Contrato: "la salida es exactamente una etiqueta de entre tres". Observable: dada una entrada, la salida debe ser urgent, normal o spam — nada más.

2

Elige 1 caso concreto con una respuesta esperada

Entrada: "¡El servidor se cayó, los clientes no tienen acceso ahora!" → esperado: urgent. Un caso real e inequívoco basta para la v0.

3

Define aprobado/fallido sin subjetividad

Se considera aprobado si la salida es exactamente urgent. Cualquier explicación adicional, etiqueta fuera de la lista o texto adicional = falla. Criterio binario, no "quedó bien".

💡

La prueba es la definición de terminado

Mientras la prueba pase, el v0 está listo: no lo toques. Solo vuelves a editar el prompt cuando un nuevo prueba de fallo. Así es como el crecimiento se mantiene honesto (Módulo 4.2).

📐
Observable
contrato → salida verificable
🎫
1 caso real
entrada → esperado
⚖️
Aprobado/reprobado
binario, sin opinión
✅
Definición de listo
prueba en verde = listo
5

Ejemplo guiado: el MVP de un agente simple

Vamos a armar uno prompt-v0 de principio a fin para nuestro agente de clasificación de inbox. Fíjate en que tiene solo identidad + 1 contrato — ninguna regla de formato adicional, ningún rechazo anticipado. Es lo mínimo que funciona.

prompt-v0.txt núcleo irreducible · 4 líneas
You are a triage assistant for a support inbox.

Contract:
For each incoming message, output exactly one label on a single line —
one of: urgent | normal | spam. Output nothing else.

Por qué esto es un buen v0

  • •Identidad clara: una frase ancla la personalidad y el dominio.
  • •Un contrato verificable: "exactamente una etiqueta, nada más" — se puede probar de inmediato.
  • •Cero anticipación: nada sobre tono, emoji, idioma o casos raros; solo se incluyen si una prueba lo requiere.
test-01.txt 1 prueba · binaria
INPUT:    "Servidor caiu, clientes sem acesso agora!"
EXPECTED: urgent
PASS IF:  output == "urgent" (exato, sem texto adicional)
💡

Ejecuta antes de mejorar

Pega el prompt-v0 en un playground, ejecuta el test-01. ¿Pasó? Detente. Resiste la tentación de "darle un retoque". ¿Falló? Ahora tienes un problema real para corregir — y de eso trata exactamente el Módulo 4.2.

📝
v0 = 4 líneas
id + contrato
🧪
test-01
entrada → esperado
▶️
Ejecuta
antes de mejorar
🛑
Aprobado → detente
no adornes
6

Entregable: prompt-v0 + 1 prueba

El resultado de este módulo es el punto de partida de tu laboratorio: dos archivos pequeños, versionados en git, que serán la primera entrada de tu «repo de evolución». Todo lo que venga en las próximas clases será un diff sobre esto.

📦 Qué entregar

①
prompt-v0 — solo identidad + 1 contrato. Sin reglas anticipadas.
②
1 prueba concreta — entrada + salida esperada + criterio binario de pasa/falla.
③
commit inicial — git commit -m "prompt-v0: triagem de inbox + test-01"

✓ Buen entregable

  • •Cabe en la pantalla — lees todo el prompt de una vez
  • •La prueba pasa cuando ejecutas
  • •Puedes explicar cada línea en una frase

✗ Señales de que te anticipaste

  • •Ya tiene reglas de tono/idioma/emoji en v0
  • •Más de un contrato compitiendo por la atención
  • •Ninguna prueba: solo «me pareció que estaba bien»
📦
prompt-v0
el núcleo
🧪
1 prueba
prueba que funciona
🗂
git commit
repo de evolución
🚀
Punto de partida
base de los diffs

📌 Resumen del módulo

✓
Empieza con lo mínimo — el prompt más pequeño que funciona, no el más completo que imaginas.
✓
Núcleo irreducible — identidad + 1 contrato; quitar cualquiera de los dos rompe el agente.
✓
No te adelantes — una regla para un problema que no existe es deuda, no prudencia.
✓
Define «funciona» — una prueba concreta, con resultado binario de aprobado/reprobado, antes de escribir más.
✓
Entregable — prompt-v0 + 1 prueba, con commit: el punto de partida del laboratorio.

Siguiente: Módulo 4.2

Evolución mediante diff y rondas de consolidación — crecer por necesidad real (no por anticipación) y consolidar antes de inflar.