No todo necesita agentes de IA: el criterio de ingeniería sigue importando
Hay algo que se está repitiendo mucho con la IA: como ahora podemos crear agentes para casi todo, empezamos a tratar cada tarea como si necesitara uno. Y si un agente funciona, parece que el siguiente paso natural es montar cinco más para que se revisen entre ellos.
Yo no lo veo así.
He visto usar el modelo más caro disponible para redactar un mensaje de commit. También he visto tareas pequeñas pasar por agentes, handoffs y revisiones que cuestan más que resolver el problema directamente. Técnicamente funciona, pero eso no la convierte en una buena decisión.
En ingeniería no basta con decir que el problema quedó resuelto. También importan el costo, la confiabilidad, el tiempo y la complejidad que dejamos detrás. Para mí, ahí está el valor del criterio técnico: saber qué conviene automatizar y hasta dónde tiene sentido hacerlo.
Lo que realmente significa dejar de leer el código
Robert C. Martin, el autor de Clean Code, ha dicho que ya no lee el código que producen sus agentes. La frase suena extrema, sobre todo viniendo de alguien que pasó años hablando sobre cómo escribir código para que otros pudieran entenderlo.
Ahora bien, su proceso no consiste en pedir código y aceptarlo a ciegas. En SwarmForge hay especificaciones, TDD, pruebas de aceptación, cobertura, mutation testing, métricas de complejidad, revisión arquitectónica y QA. Hay prompts, pero también scripts y comprobaciones deterministas.
Es decir, Martin no dejó de revisar. Cambió lo que revisa y la forma de obtener confianza.
En esa parte estoy de acuerdo. La IA puede producir más código del que una persona alcanza a leer con atención. Si intentamos revisar manualmente cada línea, la revisión termina siendo el cuello de botella y, muchas veces, un trámite. El problema es convertir esa forma de trabajo en una solución general.
Una buena solución también puede ser demasiado
El flujo más completo de SwarmForge separa el trabajo entre seis agentes: uno especifica, otro programa, otro limpia, uno revisa arquitectura, otro endurece las pruebas y uno hace QA. Para un proyecto grande, con suficiente riesgo y varias tareas que realmente se pueden separar, puedo entenderlo.
Para resolver una función pequeña, no.
Ahí ya no estamos hablando de calidad. Estamos metiendo una capa de coordinación que también consume tokens, tiempo y contexto. Cada agente tiene que entender el trabajo, recibir un handoff, revisar algo y dejar información para el siguiente. Todo eso tiene un costo aunque no aparezca dentro del código final.
El propio repositorio ofrece flujos de dos, cuatro y seis agentes según el tamaño del trabajo. Me parece una decisión razonable porque reconoce algo que a veces olvidamos: más agentes no significa automáticamente mejor ingeniería.
Lo mismo aplica al ejemplo del commit. Si solo necesito resumir un cambio en una línea, quizá basta con una plantilla, un modelo más económico o escribirlo yo mismo. No necesito darle acceso a medio repositorio al modelo más costoso para ahorrarme unos segundos.
Lo determinista no debería gastar tokens por costumbre
Muchas de las comprobaciones que rodean a un agente no necesitan otro agente. Ejecutar pruebas, validar el formato de un handoff, medir cobertura, correr el linter o comprobar que un archivo existe son tareas deterministas.
Si puedo expresar la regla de forma exacta, prefiero ponerla en código:
- un hook de Git para una validación local;
- un linter o analizador estático para reglas de código;
- una prueba automatizada para comportamiento verificable;
- un pipeline para bloquear cambios que no cumplen condiciones;
- un script pequeño para formatos y archivos obligatorios.
Luego puedo usar un agente para interpretar el resultado, investigar un fallo o proponer una corrección. Ahí sí aporta. Lo que no tiene sentido es pagar razonamiento generativo para decidir algo que un if puede responder siempre de la misma manera.
Un caso real: este blog
Este mismo blog me sirve como ejemplo. Desde que lo migré de WordPress a Astro, he ido separando las decisiones editoriales de las validaciones que puede ejecutar una herramienta. Para crear o reescribir un artículo sí uso un agente, porque hay que entender una idea, ordenar argumentos, revisar fuentes y tomar decisiones. No todo eso se puede reducir a una regla.
Pero no uso otro agente para decidir si el seoTitle es demasiado largo, si falta una imagen o si la hero mide 720x340. Tampoco le pregunto a una IA si el sitio compila. Esas comprobaciones ya tienen una respuesta exacta y las ejecuto así:
node ./scripts/validate-blog-post.mjs --file src/content/blog/no-todo-necesita-agentes-ia-criterio-ingenieria.mdxpnpm buildgit diff --checkEl validador comprueba el frontmatter, las rutas de las imágenes, sus copias y las dimensiones de la hero. El build verifica el sitio real. Si algo falla, entonces el agente puede leer el resultado y corregirlo. La decisión importante fue separar lo que necesita criterio de lo que simplemente necesita una condición que siempre se cumpla.
Mi regla se puede resumir así:
Regla estable y repetible -> script, prueba o pipelineTarea acotada con ambigüedad -> un agenteTrabajo complejo e independiente -> varios agentesSeguridad, dinero o datos -> revisión humana explícitaNo es una fórmula matemática. Es una forma rápida de evitar que la herramienta más llamativa se convierta automáticamente en la primera opción.
No empezaría por la orquestación para después buscarle un problema.
No revisar todo tampoco significa no revisar nada
Tampoco quiero defender la revisión tradicional como si funcionara perfectamente. Un pull request con miles de líneas no se revisa de verdad mirando el diff durante unos minutos. Se aprueba, pero eso no quiere decir que alguien entendió cada cambio.
Ahora, pasar de ahí a no revisar nada también es un extremo. Las pruebas verifican lo que pensamos en probar. La cobertura dice qué código se ejecutó, no si el comportamiento es correcto. El mutation testing ayuda, pero tampoco conoce todas las reglas del negocio. Ninguna métrica puede decidir por nosotros si una arquitectura tiene sentido para la empresa que la va a mantener.
Yo haría la revisión proporcional al riesgo. Una actualización mecánica de dependencias no merece la misma atención que un cambio en autenticación, dinero, permisos, concurrencia o migración de datos.
Pondría la atención humana en:
- la especificación y los criterios de aceptación;
- los límites de seguridad y los permisos;
- las decisiones arquitectónicas difíciles de revertir;
- los cambios de datos y contratos públicos;
- las partes donde un fallo tiene consecuencias importantes;
- el comportamiento real del sistema una vez desplegado.
El resto puede apoyarse mucho más en automatización. No necesito leer todo con la misma intensidad, pero sí necesito saber dónde un error sería costoso y dónde las validaciones automáticas no son suficientes.
Clean Code fue una referencia, no una receta
Nunca he sido muy fanático de seguir Clean Code al pie de la letra. Tiene cosas buenas y puso sobre la mesa ideas importantes sobre legibilidad y diseño. Mi problema siempre ha sido tratar el libro como una receta.
Sobre el papel muchas reglas se ven correctas. En la práctica, aplicarlas sin contexto puede terminar en más capas, más abstracciones y más código para mantener. Ya pasaba con la arquitectura antes de la IA. Ahora corremos el riesgo de hacer lo mismo con el proceso de desarrollo: agregar agentes y controles porque se ven bien en el diagrama, no porque el problema los necesite.
Además, para llegar al punto de no leer el código primero necesitas mucho criterio. Hay que saber qué restricciones definir, qué medir, qué riesgo no cubren las pruebas y qué decisiones no conviene delegar. Copiar un framework es fácil. Saber si ese framework es demasiado para tu problema es otra cosa.
Para mí, ahí está el valor del background técnico. No en saber configurar la mayor cantidad de agentes, sino en reconocer cuándo esa complejidad no devuelve nada.
El criterio es parte de la solución
Antes de añadir otro agente a un flujo, me haría preguntas bastante simples:
- ¿Qué riesgo concreto reduce?
- ¿Qué puede hacer mejor que una prueba, un script o un único agente?
- ¿Cuánto contexto, tiempo y dinero consume?
- ¿Cómo sabremos que tomó una decisión incorrecta?
- ¿Quién entiende y mantiene el proceso cuando falle?
- ¿El problema tiene suficiente tamaño o paralelismo para justificar la coordinación?
Si no tengo respuestas claras, probablemente estoy comprando complejidad sin saber qué valor me devuelve.
No creo que el camino sea leer manualmente cada línea producida por IA. Tampoco creo que sea entregar todo a una cadena de agentes y confiar en que más pasos significan más calidad. Hay cosas que conviene delegar, cosas que conviene validar con herramientas y cosas que todavía necesitan una decisión humana.
La ingeniería no es solamente lograr que algo funcione. Es lograrlo con un costo razonable, con suficiente confianza y sin dejar un sistema que nadie entiende. Los agentes pueden ayudar mucho, pero decidir cuánto es suficiente sigue siendo nuestro trabajo.
Si quieres seguir aprendiendo sobre estos temas te invito a ver mis otras publicaciones.
