Un ciclo pensado para IA

Rosa Méndez, a quien todo el barrio conoce como la Güera, tiene una tortillería en Puebla desde hace quince años. Cada mañana salen de su máquina unos 300 kilos de tortilla de maíz. La mitad se vende en mostrador y la otra mitad va a fondas, taquerías y algunas familias que piden por WhatsApp. Su sobrino anota los pedidos en una libreta, a veces en el celular, y cada semana hay un error: una taquería que pidió 8 kilos para las 9:00 y recibió 3 a las 11:00.

Rosa quiere una app sencilla para tomar pedidos. Tú eres la persona que la va a construir, con ayuda de un agente de IA. Podrías abrir el agente y escribir "hazme una app de pedidos para una tortillería". En diez minutos tendrías algo que corre. La pregunta es si sería lo que Rosa necesita, si podrías mantenerlo y si sabrías qué hace cada parte.

Este curso trata de eso: un proceso de desarrollo pensado para cuando una IA escribe buena parte del código.

Al terminar podrás:

• explicar qué cambia en el trabajo de desarrollo cuando el código lo escribe un agente;
• separar lo que decides tú de lo que delegas;
• describir los seis pasos del ciclo y el archivo que deja cada uno;
• preparar tu entorno para seguir el proyecto del curso.

Qué cambia cuando la IA escribe el código

Durante décadas, escribir código fue la parte más cara del desarrollo. Los procesos que conoces (estimaciones, revisiones, ramas) giraban alrededor de esa escasez. Con un agente, escribir código se vuelve barato y rápido. Lo que no se vuelve barato es lo demás:

• Decidir qué construir. El agente no sabe que las taquerías piden la víspera ni que la tortillería cierra los domingos. Si no se lo dices, lo inventa.
• Comprobar que funciona. Un agente produce código que se ve correcto con mucha seguridad. Que se vea correcto no es lo mismo que serlo.
• Entender lo que quedó. Si aceptas cambios que no entiendes, en tres semanas tienes un sistema que nadie en el equipo sabe explicar.

Hay además tres rasgos de los agentes que conviene tener presentes desde hoy:

1. No recuerdan entre sesiones. Cada sesión empieza con contexto nuevo. Lo que acordaron ayer en el chat no existe hoy, salvo que esté escrito en un archivo que el agente lea.
2. Llenan huecos con suposiciones. Si la tarea es ambigua, el agente no se detiene a preguntar casi nunca: elige una interpretación razonable y sigue. A veces acierta.
3. Se degradan con contexto largo. Mientras más larga la conversación, más fácil es que olvide una instrucción del principio. Las sesiones cortas y enfocadas salen mejor.

El método de este curso responde a esos tres rasgos: escribir lo importante en archivos, quitar ambigüedad antes de implementar y trabajar en tareas pequeñas.

Lo que haces tú y lo que hace el agente

No se trata de que el agente haga "lo fácil" y tú "lo difícil". Se trata de que tú te quedes con lo que requiere juicio, contexto del negocio o responsabilidad, y delegues lo que se puede comprobar.

La última fila es la que más importa. Si mañana la app le promete a una taquería un pedido que la tortillería no puede cumplir, no sirve decir "lo escribió la IA". Tu nombre está en el commit.

El ciclo de seis pasos

El ciclo que seguimos en todo el curso tiene seis pasos. Cada uno deja un archivo o un registro en el repositorio, para que cualquier sesión del agente (o cualquier persona del equipo) pueda retomar el trabajo.

1. Especificar   ->  docs/SPEC.md          Qué se construye y cómo sabremos que funciona
2. Planear       ->  docs/PLAN.md          Tareas pequeñas, en orden, cada una verificable
3. Implementar   ->  código + commits      Una tarea por sesión, un commit por tarea
4. Probar        ->  tests/                Pruebas que expresan los criterios de aceptación
5. Revisar       ->  notas de revisión     Lectura del diff por ti y por un revisor separado
6. Entregar      ->  CI + despliegue       Integración continua, documentación, release

Algunas ideas clave de cada paso:

Especificar. Una página, no veinte. Lo esencial son los criterios de aceptación: frases que se pueden comprobar con un sí o un no. "El pedido mínimo es de medio kilo" se puede probar. "La app debe ser fácil de usar" no.

Planear. El agente propone, tú corriges. Cada tarea debe caber en una sesión y terminar con una verificación concreta, normalmente un comando de pruebas.

Implementar. Pocas cosas a la vez. Una tarea, una sesión, un commit. Si la sesión se enreda, se descarta y se empieza de nuevo con un pedido mejor.

Probar. Las pruebas son el contrato entre tú y el agente. Si el agente puede correrlas, puede comprobar su propio trabajo. Si puede modificarlas a su gusto, el contrato no vale.

Revisar. Lees cada diff antes de aceptarlo. Para cambios importantes, un segundo agente con contexto limpio revisa contra la especificación, porque el autor tiende a confiar en lo que acaba de escribir.

Entregar. La integración continua corre las pruebas en cada cambio. La documentación explica decisiones. El despliegue es repetible.

No es un proceso en cascada. Vas a regresar a la especificación cuando descubras algo en la implementación, y vas a ajustar el plan después de cada tarea. Lo importante es que cada vuelta quede escrita.

Por qué todo vive en el repositorio

Podrías llevar la especificación en Notion, el plan en un chat y las decisiones en tu cabeza. El problema es que el agente no lee nada de eso. Lo que sí lee, en cualquier herramienta, son los archivos del proyecto.

Cuando la especificación está en docs/SPEC.md y el plan en docs/PLAN.md, una sesión nueva puede empezar así:

Lee docs/SPEC.md y docs/PLAN.md. Vamos con la tarea T4 del plan.
No toques nada fuera de lo que pide esa tarea. Cuando termines,
corre pytest y muéstrame la salida.

Esa sesión no necesita que le cuentes la historia. Tampoco la necesita tu compañera que entra al proyecto la próxima semana, ni tú dentro de seis meses.

Funciona con cualquier agente

Los ejemplos del curso usan Claude Code porque trabaja en la terminal, lee el repositorio y ejecuta comandos. Pero el método no depende de él. Cursor, Codex de OpenAI, GitHub Copilot en modo agente y Gemini CLI siguen la misma lógica: leen archivos, proponen cambios, ejecutan pruebas y aceptan un archivo de instrucciones del proyecto.

Lo que cambia entre herramientas son los nombres. Claude Code lee CLAUDE.md y también puede leer AGENTS.md, el archivo de instrucciones que usan varias herramientas. Cada una tiene su forma de planear, de pedir permisos y de correr en modo no interactivo. Cuando mostremos una función específica de Claude Code lo diremos, y la idea de fondo te servirá con la herramienta que uses.

Si nunca has usado Claude Code, toma primero la lección Instala Claude Code en tu computadora y la de Tu primer CLAUDE.md. Aquí no repetimos esa base.

El proyecto del curso: pedidos para La Güera

A lo largo de las doce lecciones construyes la app de pedidos de Tortillería La Güera:

• Qué hace: registra pedidos por kilo, con fecha y hora de entrega, que llegan por la web o que el personal captura desde WhatsApp; muestra al tortillero cuántos kilos debe preparar por hora.
• Stack: Python, FastAPI, SQLite y pytest. Es gratuito, corre en cualquier laptop y lo puedes desplegar sin pagar.
• Resultado final: un repositorio en GitHub con especificación, plan, código probado, integración continua, documentación y una URL pública.

Elegimos un stack sencillo a propósito. El curso no es de FastAPI; es de cómo trabajar con un agente. Con pocas piezas, lo que aprendes se nota más.

Práctica

Prepara tu punto de partida y haz un experimento que vas a recordar el resto del curso:

1. Comprueba que tienes Python 3.12 o superior (python --version), Git y una cuenta de GitHub.
2. Crea una carpeta vacía tortilleria-la-guera e inicializa Git con git init.
3. Abre tu agente en esa carpeta y escribe solo esto: Hazme una app de pedidos para una tortillería. Deja que trabaje sin corregirlo.
4. Cuando termine, no ejecutes nada todavía. Haz una lista de todas las decisiones que tomó sin preguntarte: lenguaje, base de datos, unidades (¿kilos, piezas, paquetes?), horarios, si hay usuarios, si cobra en línea.
5. Marca cuáles de esas decisiones coinciden con lo que Rosa necesita según la descripción de esta lección. Guarda la lista en un archivo notas/experimento-1.md.
6. Borra el código generado (git status te dirá qué archivos son) y conserva solo tus notas. En la próxima lección escribes la especificación que habría evitado esas suposiciones.

Quiz

Resumen

• Con un agente, escribir código es barato; decidir qué construir, verificarlo y entenderlo sigue siendo trabajo tuyo.
• Los agentes no recuerdan entre sesiones, llenan huecos con suposiciones y rinden peor con contexto largo.
• El ciclo tiene seis pasos: especificar, planear, implementar, probar, revisar y entregar, y cada uno deja un archivo en el repositorio.
• El método funciona con Claude Code, Cursor, Codex, Copilot o cualquier agente que lea tu repositorio.
• El proyecto del curso es la app de pedidos de Tortillería La Güera con FastAPI, SQLite y pytest.