La mayoría de devs operan a su agente fuera del rango donde funciona bien. Esto es lo que cambió cuando empecé a tratarlo como un sistema, no como un chat.
Son las once de la noche. Llevas tres horas con Claude Code o Cursor. La feature estaba casi lista hace una hora. Ahora el agente sugiere cambios que contradicen lo que él mismo escribió antes del café. Rompe un módulo que funcionaba. Vuelve a romper. Te promete que esta vez sí.
Miente.
No es mala suerte. No es un mal modelo. Es física.
Por qué tu agente se vuelve tonto
Los LLMs sufren de algo llamado atención cuadrática. En la práctica: cada token nuevo tiene que "mirar" a todos los anteriores. Mil tokens, un millón de comparaciones. Diez mil tokens, cien millones. Veinte mil, cuatrocientos millones. La curva no sube, despega.
El umbral práctico es alrededor de los 100k tokens. No importa que tu ventana sea de 200k o de un millón: cruzando esa línea, el modelo entra en lo que algunos llaman la Dumb Zone. Empieza a perder hilos, a olvidar lo que decidieron juntos hace veinte mensajes, a confundir patrones. No está "alucinando". Está saturado.
Tu trabajo no es comprar la ventana más grande. Es mantener cada tarea lo suficientemente pequeña para que el agente no salga de la Smart Zone.
Compactar es veneno. Limpia.
Cuando la conversación se alarga, la tentación obvia es pedirle al agente que "resuma el historial". Mal.
Compactar deja un sedimento turbio: una versión borrosa de decisiones, malentendidos a medio resolver, código que cambió tres veces. El agente sigue arrastrando ese barro a cada respuesta.
La estrategia correcta es limpiar. Borrón y cuenta nueva. ¿Te acuerdas del personaje de Memento, el que se tatúa lo importante porque sabe que va a olvidar todo lo demás? Eso es lo que necesitas: una nota corta, técnicamente precisa, con el estado actual del trabajo. Cargas eso. Descartas lo demás. Sigues.
Suena drástico. Lo es. Y funciona mejor que cualquier resumen.
El concepto de diseño viene antes que el código
Hay una idea peligrosa rondando por ahí: specs-to-code. Tiras un documento de especificaciones a una caja negra, sale software. Es una fantasía. Lo que sale en realidad es deuda de diseño que vas a pagar el martes con intereses.
Yo divido el día en dos turnos:
Day shift (tú): alineamiento, decisiones, criterio. Night shift (el agente): ejecución, paralelización, trabajo pesado.
El day shift no es opcional. Y su herramienta principal no es escribir código, es dejarse interrogar.
Antes de aceptar cualquier plan, le digo al agente algo así:
Interrógame sobre este diseño hasta que no queden suposiciones. Una pregunta a la vez. No empieces a programar hasta que yo lo autorice.
Las primeras preguntas son obvias. Las siguientes empiezan a doler:
¿Los puntos del sistema de gamificación son retroactivos para usuarios que ya terminaron el curso?
"No. Solo para nuevas actividades."
¿Y si un usuario repite una lección que ya hizo antes de implementar esto?
"Eh… no había pensado en eso."
Ahí. Ese hueco. La pregunta 47 es la que te salva el lunes siguiente. Apunta a entre 40 y 80 preguntas antes de tocar código real. Cuando lleguen, tendrás algo que ningún PRD te iba a dar: un concepto de diseño compartido.
El PRD pasa a ser una formalidad. Yo casi no lo releo. Ya estamos en la misma página.
Atraviesa el sistema antes de construirlo por capas
El siguiente error clásico: dejar que el agente programe horizontal. Primero todo el schema de la base de datos. Después toda la API. Después la UI. Cuatro horas más tarde descubres que el modelo de datos no soporta el flujo que querías. Y ahora hay que rehacer tres capas.
Construye vertical. Una rebanada delgada que atraviese todo el sistema de punta a punta.
Si estás haciendo gamificación: que un usuario complete una lección y vea un punto en su dashboard. Eso es todo. Una tabla, un endpoint, un componente. Funciona o no funciona. Si funciona, ya validaste la arquitectura entera con el costo de una feature pequeña.
Hay un nombre viejo para esto: balas trazadoras. Las balas con fósforo que dejan una estela visible y sirven para corregir la puntería antes de gastar el cargador entero. En desarrollo asistido por IA, la rebanada vertical es eso. Sin ella, tu agente está disparando a ciegas durante horas.
La arquitectura es el techo de tu agente
Aquí está la parte incómoda: el código mediocre produce agentes mediocres.
Cuando le pides a una IA que trabaje sobre una base con módulos pequeños, interfaces complicadas y dependencias enredadas, el agente tiene que cargar todo ese grafo en su contexto solo para entender qué hace una función. Adivina qué pasa con su Smart Zone.
John Ousterhout lleva años predicando los módulos profundos: interfaces simples que esconden implementaciones complejas. Una clase con tres métodos públicos y mil líneas adentro vence a quince archivos con cincuenta métodos cada uno, conectados con cinta. Para humanos. Y, resulta, también para agentes.
Diseña interfaces estrechas. Esconde la complejidad detrás. Tu agente trabaja en una "caja gris": tú diseñas el contrato del módulo, él implementa el contenido. Mantienes el control de la arquitectura. Delegas el trabajo pesado.
TDD: no negociable, sobre todo con agentes
Los agentes hacen trampa. No por maldad, por optimización. Si les pides un test y la implementación al mismo tiempo, escriben ambos para que pasen juntos. Si el test falla después, mueven el test. Es eficiente. Es horrible.
Fuerza el ciclo de tres tiempos, en orden, sin atajos:
Rojo. El test existe y falla. El agente lo ejecuta y te muestra que falla.
Verde. Implementación mínima. Apenas lo necesario para que pase.
Refactor. Limpieza con la red de seguridad puesta.
En un sandbox (Docker, contenedores efímeros, lo que prefieras), puedes correr varios agentes en paralelo sobre tareas que no se bloquean entre sí. Un tablero kanban, no una lista secuencial. Mientras duermes, tres agentes están en su respectivo red-green-refactor, cada uno en su caja gris, cada uno dentro de su Smart Zone porque la tarea es pequeña.
Por la mañana lees los diffs.
El humano es el guardián del gusto
Esto es lo que nadie quiere oír: si delegas el QA al 100%, pierdes el software.
No el archivo, no el repo. El software como artefacto con propósito. Si dejas de leer tu propia base de código, dejas de tener una. Tienes un montón de archivos que pasan tests y que, en algún momento que no viste venir, dejaron de hacer lo que querías que hicieran.
Tu trabajo no es escribir cada línea. Tu trabajo es imponer criterio. Decir "esto está bien" y "esto es slop", y notar la diferencia. Para eso necesitas mantener lo que algunos llaman codebase sense: el feel por tu sistema. Y eso solo se mantiene leyendo, no solo aprobando.
La caja gris ayuda. El TDD ayuda. Las rebanadas verticales ayudan. Pero al final del día hay alguien que decide si lo que el agente entregó merece existir. Ese alguien eres tú.
Lo paradójico
Pensábamos que la IA iba a hacer obsoletos los fundamentos de ingeniería de software. Está pasando lo contrario.
Módulos cohesivos. Interfaces limpias. Tests sólidos. Diseño antes que código. Esas prácticas de los últimos veinte años no eran solo para que los humanos pudiéramos colaborar entre nosotros. Eran, sin que lo supiéramos, el manual de instrucciones para mantener a un agente dentro de su Smart Zone.
El código sigue siendo el campo de batalla. Cambió el ejército, no el terreno.
Y la pregunta que me hago ahora, todos los días, no es "¿qué puede hacer la IA por mí?". Es otra:
¿Mi código es lo suficientemente bueno como para merecer un agente que lo respete?
Una nota personal
Escribo esto porque es lo que hacemos todos los días en Codridge. Ayudamos a equipos de ingeniería y a empresas medianas a implementar IA dentro de su operación — sin reemplazar lo que ya funciona, sin prometer milagros, y sin dejarlos en la Dumb Zone seis meses después. Si tu empresa está en ese momento de "queremos hacer algo con IA pero no sabemos por dónde", ese es exactamente el problema que resolvemos.
![Guía Práctica: Cómo Crear tu Micro SaaS Rentable en 2025 [Con Ejemplos Reales]](https://assets.basehub.com/738aee4b/dceddb716406ffe524c6e1523d52774d/7elgp9drbcfcegvjjcjao.webp)