Detén a tu agente cada 100 líneas para probar
Nunca dejes que tu agente de código escriba más de cien líneas antes de probar. Un agente que corre sin supervisión durante 500 líneas se siente productivo — hasta que lo ejecutas y algo está roto. Ahora el error podría estar en cualquier parte de esas 500 líneas, y cada rebanada construida sobre una primera rebanada defectuosa hereda la falla. No tienes un error; tienes una montaña.
Por qué 100 líneas
El número no es mágico — es un indicador de "lo suficientemente pequeño como para que una falla sea fácil de ubicar." Cuando pruebas después de ~100 líneas y algo se rompe, la región sospechosa es diminuta. Cuando pruebas después de 100 líneas y pasa, has asegurado una base conocida y sólida antes de apilar más encima.
La alternativa se acumula. Un error sutil en la capa de datos parece estar bien hasta que la capa de interfaz lee de ella, que parece estar bien hasta que la validación corre contra ella. Para cuando el síntoma aparece, tres capas de código escrito por el agente asumen que el comportamiento roto es correcto. Depurar eso significa deshacer las tres.
Trabaja en rebanadas verticales delgadas
Una rebanada vertical es una pieza completa de funcionalidad que atraviesa todas las capas que necesita — datos, lógica, interfaz — en lugar de construir todo el código de datos, luego toda la lógica, luego toda la UI. Cada rebanada deja el sistema funcionando y comprobable.
| Paso | Qué haces | Por qué importa |
|---|---|---|
| Implementar | Un comportamiento estrecho, ~100 líneas | Lo bastante pequeño para razonarlo |
| Probar | Ejecútalo — prueba automatizada o verificación manual | La falla es local, no global |
| Verificar | Confirma que hace lo que pediste | Detecta el "funciona pero está mal" |
| Confirmar (commit) | Guarda el estado conocido y bueno | Un punto de reversión barato |
| Siguiente rebanada | Repite con la siguiente pieza | Construye sobre terreno sólido |
El paso del commit es la red de seguridad. Si la rebanada cinco se tuerce, un git reset a la rebanada cuatro te cuesta segundos, no una tarde de depuración. Los commits pequeños también hacen que el diff sea revisable — de verdad puedes leer 100 líneas y atrapar un error que las pruebas no detectaron.
Hazlo trabajo del agente, no solo tuyo
No tienes que contar líneas a mano. Integra el ritmo en cómo diriges al agente:
- Pide una rebanada a la vez. Solicita un solo comportamiento con su prueba, no "construye toda la funcionalidad." Los agentes sobreproducen cuando la tarea es abierta.
- Exige una prueba en verde como condición de salida. "Implementa X, agrega una prueba para X, ejecútala, muéstrame que está en verde" hace que el agente se detenga y verifique en lugar de seguir de largo.
- Confirma (commit) entre rebanadas tú mismo. Mantén los puntos de control bajo tu control para que una rebanada mala nunca contamine una buena.
- Mantén el contexto ligero. Una rebanada bien delimitada cabe en la ventana de contexto de un agente con espacio de sobra, lo que mejora la precisión — los archivos irrelevantes cuestan tokens y atención.
Esta es la misma disciplina detrás del código auto-verificable (self-testing code) y la integración continua: pasos frecuentes, pequeños y verificados le ganan a un solo gran salto. Precede a los agentes de IA por décadas. Los agentes solo hacen que la tentación de saltárselo sea mucho más fuerte, porque generar 500 líneas ahora no cuesta nada — y 500 líneas de código no verificado son una responsabilidad de 500 líneas.
Recursos
- Continuous Integration — Martin Fowler (código auto-verificable, commits pequeños y frecuentes)
- AI-Assisted Greenfield Development: Vertical Slices — CODE Magazine
- Incremental Implementation skill — addyosmani/agent-skills
- The Codebase Is the Prompt: Vertical Slices and AI-Assisted Development — Jeremy Miller
¿Construyes con agentes de IA? Yeda AI diseña, audita y despliega sistemas LLM y flujos de trabajo con agentes en producción.