Durante años, el trabajo de un desarrollador fue claro: te dan un problema, escribes el código que lo resuelve. Con los agentes de IA, eso está cambiando. El nuevo trabajo no es escribir la función, sino construir el sistema que produce funciones.
Algunos lo llaman “fábricas de agentes”: la infraestructura gobernada que crea, ejecuta y supervisa agentes autónomos a escala.
La brecha de la frontera
Mira el embudo de adopción de IA generativa:
- Miles de millones de personas ya usaron un chatbot.
- Unos 20 millones de profesionales usan modelos de lenguaje para comprimir semanas de trabajo en días.
- Unos 5,000 desarrolladores en el mundo operan en la frontera: enjambres de miles de agentes funcionando todo el día.
Entre el segundo y el tercer grupo hay un abismo. Cerrarlo es la misión del ingeniero de IA moderno.
Esto sigue un patrón conocido. La abstracción en software siempre sube de nivel: de ensamblador a lenguajes de alto nivel, de servidores físicos a la nube, y ahora a sistemas que razonan. En cada salto, el ingeniero deja de hacer la tarea a mano y pasa a construir lo que la hace.
En la práctica se ve así:
- Antes revisabas código manualmente. Ahora construyes un sistema de agentes y evaluaciones que revisa por ti.
- Antes mirabas dashboards buscando errores. Ahora diseñas agentes que leen la telemetría, detectan patrones y proponen correcciones.
La arquitectura de un agente que corre todo el día
Un agente en producción no puede ser un script corriendo en tu laptop. Necesita una arquitectura con cuatro fases:
1. Disparadores
Los agentes no deberían estar esperando indefinidamente. Se despiertan por:
- Horario: un agente que revisa la telemetría cada tres horas.
- Eventos: un mensaje en Slack, un ticket de soporte nuevo, un webhook.
- Métricas: un pico en la tasa de errores.
Si ya usaste cron, colas de mensajes o webhooks, ya conoces la base.
2. Sandbox
La seguridad es la principal barrera para adoptar agentes en una empresa. Cada ejecución debe correr en un entorno temporal aislado, cargado solo con el contexto, el acceso a repositorios y las credenciales necesarias para esa tarea.
Toda comunicación entra y sale por un único proxy, para que no haya fugas de datos y el agente no pueda salirse de su alcance autorizado.
3. Estado durable
Los agentes no son deterministas: pueden fallar a mitad de una tarea compleja. Empezar desde cero cada vez es caro.
La solución es guardar el estado fuera del sandbox. Si una ejecución falla, levantas un sandbox nuevo y continúas donde quedó. Además, una memoria persistente permite que el agente recuerde problemas que ya vio y no repita errores.
4. Cierre y auditoría
Cuando la tarea termina, el sandbox y sus credenciales se destruyen. Pero el rastro de lo que hizo el agente (qué decidió, qué herramientas llamó) se conserva. Ese registro sirve para cumplimiento de seguridad y alimenta la siguiente pieza: la observabilidad.
Los evals: la nueva habilidad central
En software tradicional, un test pasa o falla. Con agentes, la salida es matizada y no determinista. Por eso la habilidad más importante del ingeniero de IA es escribir evaluaciones (evals).
Escribir evals significa definir qué es “bueno” para una salida generada por IA:
- Construyes un dataset de referencia con ejemplos correctos.
- Construyes jueces automáticos que miden qué tan cerca está la salida del agente de esa referencia.
- Verificas que esos jueces decidan igual que lo haría un ingeniero senior. Sí: evalúas a los evaluadores.
Este rigor es lo que permite confiar en un agente para abrir un pull request o modificar una base de datos sin aprobación manual. Definir el criterio de éxito ahora importa más que escribir el código que lo logra.
Si vienes del testing tradicional (Jest, Pytest), los evals son el siguiente paso natural: la misma disciplina aplicada a salidas probabilísticas.
Observabilidad pensada para agentes, no para humanos
Hoy los logs, trazas y métricas están diseñados para que una persona mire un dashboard en Datadog o Sentry. En el mundo de los agentes, el principal consumidor de esa telemetría es el propio agente.
Cuando un agente lee las trazas:
- Puede revisar miles por minuto.
- Detecta patrones de error que una persona pasaría por alto.
- El ciclo entre detectar un problema y corregirlo baja de horas a segundos.
Y se forma un círculo virtuoso: los datos del desempeño de los agentes se convierten en material para los siguientes evals, que a su vez hacen más confiables a los agentes. Por eso conviene trazar todo, no solo la salida final, sino cada paso que dio el agente para llegar ahí.
¿Qué significa esto para tu carrera?
Si estás aprendiendo desarrollo hoy, esto no significa que ya no necesites programar. Significa lo contrario: necesitas bases sólidas para construir sistemas que otros (y otros agentes) usarán.
Las piezas de una fábrica de agentes son, en su mayoría, ingeniería de software clásica:
| Pieza | Lo que necesitas saber |
|---|---|
| Disparadores | Cron, colas, webhooks, eventos |
| Sandbox | Contenedores, Docker, permisos, redes |
| Estado durable | Bases de datos, diseño de esquemas |
| Auditoría | Logging estructurado, almacenamiento |
| Evals | Testing, datasets, métricas |
| Observabilidad | Trazas, métricas, monitoreo |
El ingeniero de IA no reemplaza al desarrollador full stack: es un desarrollador full stack que además sabe orquestar modelos. Backend, bases de datos, despliegue en la nube e integración con APIs de IA son exactamente las habilidades que separan a quien usa ChatGPT de quien construye sistemas con él.
Basado en el artículo original de Ability AI. Adaptado y ampliado para la comunidad DojoFullStack.