Introducción: de la arquitectura al método
Después del trabajo sobre la gestión del contexto y la orquestación, vuelvo a algo más terrenal: el código. Puedo organizar los archivos, aligerar las consignas, aislar los agentes; al final, lo que importa es que la feature responda de verdad a lo que quería construir.
Tenía una constitución clara y archivos de instrucciones bien mantenidos. Sobre el papel, banca. En el código era otra historia: la IA genera, interpreta, a veces olvida una restricción y acumula. Pero el código no es una victoria en sí. Como recuerda Software Engineering at Google, el código también es una carga a mantener. Cuanto más rápido produce el agente, más puede también introducir duplicación, deuda o code smells. Necesitaba barandas, no solo buenas consignas.
En ese momento, sobre todo pongo en marcha herramientas para sostener la calidad. Las consignas no alcanzan: hacen falta bucles de feedback, tests, hooks, controles, retornos lo bastante claros para que el agente vea dónde se rompe y corrija mientras trabaja.
Estado de situación
A esta altura, muchas herramientas ya forman parte de mi día a día como desarrollador. Termino entonces poniéndolas también en el bucle de los agentes: prompts reutilizables, comandos, constitución de proyecto, orquestador, CI que bloquea las PR rotas, y mecánica para generar los archivos de contexto correctos según la herramienta usada.
Mi trabajo sigue siendo de desarrollo, pero se desplaza: paso menos tiempo escribiendo las líneas yo mismo y más tiempo solidificando el entorno en el que los agentes trabajan. El tema ya no es solo apilar mejores consignas. Es volver la calidad verificable.
Cuando las reglas se vuelven ejecutables
A partir de ahí, busco sobre todo acortar el bucle. La IA genera código, el sistema responde. Si se rompe, quiero un retorno claro, en el momento justo, para que el agente corrija enseguida. Saco ciertas reglas repetibles fuera del prompt: se vuelven controles ejecutados por el sistema, después devueltos al agente en forma de feedback accionable.
Se habla seguido de DX, la Developer Experience pensada para humanos. Acá empiezo sobre todo a pensar la experiencia de trabajo del agente: retornos cortos, focalizados, legibles en el contexto restante. A eso le digo AIX. Cuando configuro un linter, un mensaje de error o un script, pienso en el agente que va a tener que leer ese retorno, corregir, relanzar. Si el retorno es claro, sigue. Si es vago o demasiado ruidoso, patina y repite los mismos errores.
En la práctica, el bucle no siempre queda tan prolijo como en el esquema. Formulo una tarea, el agente explora, escribe código, modifica archivos, y los controles empiezan a responder: lint, tipos, tests, hooks, CI. En cada retorno, quiero evitar el muro de logs. Quiero una señal que el agente pueda usar para corregir sin volver al borroso.
En ese bucle, no todas las verificaciones cumplen el mismo rol. Algunas tienen que ser muy rápidas: un formateo, un lint focalizado, a veces un typecheck limitado al archivo o a la zona modificada. Esas pueden dispararse seguido, justo después de una escritura. Otras se parecen más a pequeños pipelines: corren al final de un turno de trabajo, justo antes de que el agente devuelva el control. Pueden relanzar checks más pesados, capturar el estado del diff y los errores, o incluso pedir una revisión a otro agente. En este workflow, el turno no debería terminar con un “terminé” si algo sigue roto. El agente vuelve al bucle.
Atención
Demasiados hooks recrean el problema que intento evitar. Si cada acción dispara un retorno largo, capaz protejo el cuadro, pero también contamino el contexto. Y un contexto contaminado termina degradando la salida. Una buena baranda tiene que devolver una señal útil, no llenar la ventana de ruido.
No se limita al lint o a los tests. Agrego también validaciones caseras: fronteras runtime, migraciones, documentación, contexto, entorno, seguridad. Cada proyecto tiene sus puntos ciegos; las barandas sirven para volverlos visibles antes.
La lista exacta de herramientas cambia de un proyecto a otro. El desplazamiento, en cambio, sigue siendo el mismo: una regla importante no se queda solo en un prompt. Cuando se la puede verificar, busco que la verifique el sistema.
Actualización (abril 2026)
Desde entonces, mis bucles de retorno cambiaron otra vez. Ahora uso más retornos durante la escritura misma: formateo, lint focalizado, a veces typecheck o validación de componente apenas un archivo cambia. Es más rápido que una verificación completa al commit o en CI, pero no la reemplaza. Los dos niveles no tienen el mismo rol.
También publiqué un viejo validador de arquitectura en código abierto: hex-validator. No es una herramienta que presentaría como terminada hoy; más bien una huella de la exploración de la época. Sigo usando técnicas parecidas, adaptadas repo por repo. El repo muestra sobre todo la idea: convertir ciertas reglas de arquitectura en checks ejecutables.
La IA genera código, pero no trabaja en el vacío. Actúa en una pila de contexto: archivos de instrucciones, consignas del usuario, archivos cargados durante la tarea, código existente, comentarios, documentación, hooks y checks. Mi rol se desplaza ahí: mantener esa pila lo bastante limpia como para que el agente pueda actuar sin inventarse el cuadro.
Las barandas no son entonces una capa separada del contexto. Forman parte de él. Transforman una regla, una convención o un error en señal accionable. Cuando esa pila está bien sostenida, el agente puede avanzar mucho más sin que yo tenga que retomar cada decisión a mano.