Inicializar es otra fase

Empezar a levantar paredes sin cimientos

Abres una sesión y dices: «añade una búsqueda». El agente se lanza a programar. A los 20 minutos descubre que el entorno de pruebas no está bien configurado. Pierde 10 más arreglándolo. Luego falla un script de migración. La búsqueda acaba funcionando, pero casi toda la sesión se fue en entender cómo funciona el proyecto.

Es como levantar las paredes mientras el hormigón de los cimientos aún no ha fraguado. Todo parece avanzar, hasta que hay que demoler.

Dos trabajos con objetivos distintos

La fase de implementación busca más funciones verificadas. La fase de inicialización busca que todo lo posterior sea fiable y rápido. Si las mezclas, el agente tiende a lo visible: escribe código de funciones (se ve) y descuida la infraestructura (su valor aparece más tarde). Los costes de mezclar son concretos:

• Cimientos flojos: pruebas configuradas pero nunca comprobadas, lint demasiado laxo, ningún archivo de progreso.
• Código sin verificar acumulado: lo escrito antes de tener pruebas puede estar mal diseñado, y te enteras tarde.
• Presupuesto de sesión gastado: la primera sesión acaba a medias y la segunda empieza de cero.
• Suposiciones sin anotar: si nadie escribe qué framework de pruebas se eligió, la sesión siguiente puede decidir lo contrario.

Anthropic describe justo este enfoque: una primera sesión de inicializador que prepara un script de arranque, un archivo de progreso, una lista de funciones y un primer commit. Las sesiones de código posteriores leen ese estado y trabajan función a función.

Qué produce la sesión de inicialización

La salida no es código de negocio, es infraestructura:

1. Entorno ejecutable: el proyecto arranca y las dependencias están instaladas.
2. Pruebas verificables: al menos una prueba de ejemplo pasa, lo que demuestra que el sistema de pruebas funciona. Es el pilar de prueba sobre los cimientos.
3. Contrato de arranque (lo vemos en la próxima lección).
4. Desglose de tareas con criterios de aceptación claros.
5. Un commit limpio como punto de control.

Arranque en frío o en caliente

Empezar desde un directorio vacío (arranque en frío) obliga al agente a adivinar la estructura. Empezar desde una plantilla o proyecto existente (arranque en caliente) ya trae carpetas, dependencias y pruebas. Es la diferencia entre llegar a una obra con agua y luz, o a un solar vacío. Siempre que puedas, parte de una plantilla.

Cómo saber que la inicialización terminó

No se mide en líneas de código sino en cuatro condiciones: puede arrancar, puede probar, se ve el progreso, se pueden retomar los siguientes pasos. La lección propone esta lista de aceptación:

## Lista de aceptación de la inicialización
- [ ] El comando de instalación funciona desde cero
- [ ] Hay al menos una prueba y pasa
- [ ] Una sesión nueva sabe cómo arrancar y probar solo leyendo el repo
- [ ] Existe un archivo de desglose con al menos 3 tareas
- [ ] Todo está en un commit de git

¿Compensa?

En el ejemplo de la lección, con un proyecto React, la sesión que mezclaba todo dejó a la segunda sesión unos 20 minutos infiriendo la estructura; la que hizo inicialización dedicada tardó menos de 3 minutos en reconstruirse. Son cifras de un caso ilustrativo, no una medición general, pero la idea es clara: el tiempo invertido al principio se recupera en las siguientes sesiones.