iadevprogramar con IA · con método

Tutorial de programación con IA · en español · desde cero

Programa con IA con método, no cruzando los dedos.

Un agente de código escribe en segundos algo que parece correcto. Que lo sea es otra historia. Este tutorial enseña una forma de trabajar que lo comprueba: primero la especificación (SDD), después los tests (TDD) y solo entonces el código. Paso a paso y sin dar nada por sabido.

Prueba el ciclo en vivoVer el itinerario →
  • 10 capítulos
  • 10 demos interactivas
  • 0 líneas aceptadas a ciegas
1 spec · lo que debe pasar
Dado el título "¿Qué es TDD?"
Entonces el slug es "que-es-tdd"
2 test · primero falla
slug("¿Qué es TDD?") === "que-es-tdd"
✗ falla: aún no hay código
3 código · lo justo para pasar
function slug(titulo) { … }
✓ 7 de 7 tests en verde
El orden importa: la spec dice qué se quiere, el test lo convierte en algo comprobable y el código llega el último, con una red debajo.

Demo · se ejecuta en tu navegador

Rojo, verde, refactor. Aquí mismo.

Hay que escribir slug(titulo), la función que convierte un título en un trozo de URL. La spec son siete criterios y cada uno tiene su test. Recorre el ciclo con los botones o edita el código: los tests se ejecutan con cada tecla.

Los tests están escritos y la función aún no hace nada: fallan todos. Ese rojo es la prueba de que los tests comprueban algo.

La spec, criterio a criterioRojo · 0 de 7

  1. Minúsculas, y guiones en vez de espacios

    slug("Hola Mundo") → "hola-mundo"

    obtenido: undefined

  2. Sin acentos

    slug("Programación con IA") → "programacion-con-ia"

    obtenido: undefined

  3. Sin signos de puntuación

    slug("¿Qué es TDD?") → "que-es-tdd"

    obtenido: undefined

  4. Separadores seguidos: un solo guion

    slug("spec → test") → "spec-test"

    obtenido: undefined

  5. Sin guiones al principio ni al final

    slug(" -Hola- ") → "hola"

    obtenido: undefined

  6. Los números se conservan

    slug("Top 10 errores") → "top-10-errores"

    obtenido: undefined

  7. Un título sin letras ni números es un error

    slug("¡¡!!") → lanza un error

    obtenido: undefined

Activa JavaScript para editar el código y ver cómo cambian los tests.

  • El rojo va primero. Un test que nunca has visto fallar no demuestra nada: quizá pasa siempre. Por eso el ciclo empieza con todo en rojo, y por eso a la IA se le exige confirmarlo antes de escribir una línea.
  • El código plausible engaña. Carga «A ojo, sin tests»: dos líneas razonables que cualquiera daría por buenas. La spec dice lo contrario, criterio a criterio y sin discusión.
  • Los tests son la red. Con la suite en verde se puede reescribir el código sin miedo. Y da igual quién lo reescriba: tú, un compañero o un agente a las tres de la mañana.

Itinerario

Diez capítulos, del prompt suelto al método.

Cada capítulo explica una idea con palabras normales, la deja probar en una demo y enseña cómo se aplica con un agente de código: qué se le pide, qué se le exige y qué se revisa. Se irán publicando uno a uno.

  1. 01

    El problema: programar con IA sin método

    La IA escribe código plausible en segundos. Que sea el que querías depende de lo que no le dijiste.

    Demo · Un prompt vago, tres programas distintosPróximamente
  2. 02

    Qué es SDD: la spec es el contrato

    Nada se implementa si no está especificado. Por qué escribir antes ahorra reescribir después.

    Demo · Detector de ambigüedades en una specPróximamente
  3. 03

    Escribir la spec con la IA

    Que la IA te entreviste a ti: de una idea de una frase a criterios que se pueden comprobar.

    Demo · Constructor de criterios Dado / Cuando / EntoncesPróximamente
  4. 04

    Qué es TDD: rojo, verde, refactor

    Primero el test que falla, después lo mínimo para que pase. El rojo demuestra que el test prueba algo.

    Demo · El ciclo completo, paso a pasoPróximamente
  5. 05

    De criterios a tests

    Un criterio de la spec, al menos un test. También los casos negativos, que son los que la IA se salta.

    Demo · Matriz criterio ↔ test que marca los huecosPróximamente
  6. 06

    El contexto del agente

    Lo que el agente no lee, no existe. Qué poner en AGENTS.md o CLAUDE.md y qué dejar fuera.

    Demo · Monta un AGENTS.md y mira qué cambiaPróximamente
  7. 07

    El bucle: tarea, test, código

    Una sesión de trabajo entera con un agente: tareas pequeñas, rojo confirmado, verde y commit.

    Demo · Una sesión real repetida commit a commitPróximamente
  8. 08

    Revisar lo que hace la IA

    Tests debilitados, valores fijados a mano, casos borrados. Las trampas típicas y cómo cazarlas en el diff.

    Demo · Encuentra la trampaPróximamente
  9. 09

    Cambiar requisitos sin romper nada

    El cambio empieza en la spec, no en el código. Qué tests y qué ficheros arrastra cada frase que tocas.

    Demo · Cambia la spec y mira qué se iluminaPróximamente
  10. 10

    Calidad continua

    ¿Y quién prueba los tests? Mutation testing, la suite entera en cada cambio y cuándo fiarse del verde.

    Demo · Muta el código: ¿lo detectan los tests?Próximamente

Cómo encaja todo

Una funcionalidad, de la idea al commit.

La IA escribe casi todo el código. Tú decides qué se construye y compruebas que es eso lo que se ha construido: las dos cosas que no se pueden delegar.

  1. Tú

    La idea, en una frase

    Qué quieres y para quién. «Las entradas del blog necesitan una URL legible» es suficiente para empezar; todavía no se habla de código.

  2. Tú + IA

    La spec

    La IA te entrevista: ¿qué pasa con los acentos?, ¿y con un título vacío? De las respuestas sale un fichero en specs/ con criterios que se pueden comprobar. Nada se implementa si no está ahí.

  3. Tú

    Revisas el contrato

    Leer siete criterios cuesta dos minutos. Descubrir el mismo malentendido en el código cuesta una tarde. Este es el momento barato para corregir el rumbo.

  4. IA

    Tests primero, y en rojo

    Un criterio, al menos un test; los casos negativos también. El agente los ejecuta y enseña que fallan: es la prueba de que comprueban algo.

  5. IA

    Lo mínimo para el verde

    Ahora sí, el código. Solo el necesario para que pasen los tests, y sin tocarlos: cambiar un test para que pase es hacer trampa.

  6. IA

    Refactor con la suite entera

    Se limpia el código y se ejecuta todo: los tests del repo completo, el linter y el formateador. No solo lo que se ha tocado.

  7. Tú

    Revisión y commit

    Lees el diff, pruebas la historia completa en el sistema real y haces commit. Spec, tests y código viajan juntos; si el cambio contradice la spec, la spec se actualiza en ese mismo commit.

Pruébalo

Empieza hoy, en el repo que ya tienes.

No hace falta ninguna herramienta nueva. El método cabe en tres sitios de tu repositorio y en la forma de pedir las cosas: en vez de «hazme una función slug», un encargo que dice qué leer, cómo trabajar y cuándo está terminado.

specs/
El contrato: qué hace el sistema, criterio a criterio
AGENTS.md
Las reglas de la casa que el agente lee siempre
tests/
La spec convertida en algo que se ejecuta

Sirve con cualquier agente de código: Claude Code, Codex, Cursor… Lo que cambia de uno a otro es el nombre del fichero de reglas, no el método.

# Qué leer antes
Lee AGENTS.md y specs/003-slug.md antes de tocar nada.

# La tarea
Implementa slug(titulo) según la spec. Los siete criterios
de aceptación están en ella.

# El método
TDD: escribe primero un test por criterio, ejecútalos y
enséñame que fallan. Después, lo mínimo para el verde.
No modifiques un test para que pase.

# Los límites
Solo puedes tocar src/slug.js y tests/slug.test.js.
Sin dependencias nuevas.

# Terminado es
La suite completa en verde y el linter sin avisos.

# El informe
Al acabar: ficheros tocados, decisiones que has tomado
y cualquier desviación de la spec.

Qué cambia

La misma IA, con otra forma de pedir.

El modelo es el mismo en los dos casos. Lo que cambia es cuánto tiene que adivinar y cómo te enteras cuando adivina mal.

Sin método

  • El prompt es la única especificación, y se pierde al cerrar el chat
  • «Funciona» significa que lo probaste una vez con un ejemplo
  • Cada cambio puede romper algo que ya iba, y nadie avisa
  • Revisar es leer cientos de líneas buscando no se sabe qué

Con spec y tests

  • La spec vive en el repo. Cualquier agente, o cualquier persona, se pone al día leyéndola. No depende de la memoria de nadie.
  • «Funciona» es que la suite lo demuestra. Un criterio, un test. Lo que no tiene test no está prometido.
  • Lo que se rompe, se rompe en rojo. Y en segundos, no en producción tres semanas después.
  • Revisar es comparar con el contrato. ¿Están los tests de cada criterio? ¿Alguno se ha tocado para que pase? El diff tiene preguntas concretas.

Lo que el método no hace. No vuelve infalible a la IA ni te ahorra pensar. Unos tests en verde solo prueban lo que la spec pide: si la spec está mal, tendrás el programa equivocado, muy bien probado. Por eso la spec la decides tú y el diff lo revisas tú.