Como Director de Tecnología e Innovación de Nybble, Leo Rodríguez , durante una sesión interna, afirmó que el reto no es adoptar agentes, sino comprender dónde la autonomía ayuda y dónde genera fricción: «Tenemos que decidir qué podemos delegar y qué no. No a ciegas; ese es el error. Necesitamos entender qué nivel de autonomía nos sigue dando buenos resultados y qué nivel deja de tener sentido. Hay tareas que se pueden delegar con control, y otras en las que solo se agrega ruido».

Este artículo trata sobre ese juicio: dónde los agentes aceleran el desarrollo, dónde lo ralentizan y cómo Nybble aprendió la diferencia a través de un trabajo real, imperfecto y práctico.

Cuando la delegación fracasa: la migración de primavera

Uno de los primeros experimentos de Nybble con un gran uso de agentes fue la migración a una versión más reciente de Spring: una tarea repetitiva, larga y mecánicamente predecible. En teoría, una solución ideal para la automatización.

¿Y la ejecución? Avanzó rápido. Muy rápido. Pero sin el contexto, la planificación y la documentación adecuados, la velocidad inicial se convirtió en trabajo extra más adelante. El agente realizó grandes partes de la migración rápidamente, pero cada pieza requirió ser revisada, probada, corregida y estabilizada.

Leo lo recuerda con claridad: «No planificamos. No preparamos el contexto. Simplemente empezamos a iterar con el agente. Y sí, avanzó rápido, sí, pero esa velocidad se convirtió en el doble de trabajo. Corregir, comprobar, ir y venir. El modelo era bueno, pero sin estructura terminamos haciendo muchas más iteraciones de las necesarias. La velocidad sin planificación es una ilusión, porque luego requiere reelaboración».

Incluso una tarea repetitiva necesita límites. Si un agente trabaja a ciegas, la velocidad se convierte en un bucle en lugar de un atajo.

Cuando la delegación funciona a la perfección: el proyecto de clúster ArgoCD

Luego vino un experimento diferente y un resultado completamente diferente.

Para el proyecto de automatización del clúster de ArgoCD, en lugar de apresurarse, el equipo creó el contexto primero. Documentaron el funcionamiento del clúster, el flujo de las implementaciones, las decisiones tomadas previamente y qué debía (y no debía) tocar el agente.

Y los resultados fueron geniales.

El agente no estaba adivinando; estaba navegando. Una vez implementada la primera aplicación con esta estructura, las demás se implementaron rápidamente. No porque el modelo fuera más inteligente, sino porque el entorno era más claro.

Leo describe por qué funcionó:

Documentamos todo antes de empezar: cómo funcionaba el clúster, cómo se configuró ArgoCD para nosotros, las decisiones que se habían tomado previamente. El agente no codificaba a ciegas; entendía el entorno. Una vez que creamos la primera aplicación y la documentamos bien, todas las demás aplicaciones se desarrollaron rápidamente.

Este fue el punto de inflexión: un contexto claro transforma a un agente de un generador de código en un colaborador que entiende el sistema.

Entonces, ¿cuándo deberías delegar?

De estas experiencias surgió una regla: la delegación no es universal, prospera en las condiciones adecuadas.

Los agentes funcionan mejor cuando el trabajo es repetitivo o mecánico (migraciones, generación de código repetitivo, actualizaciones masivas de código, paneles internos), especialmente cuando la documentación es sólida y el costo de iteración es bajo. Cuando el agente cuenta con un mapa, puede avanzar con confianza sin necesidad de correcciones constantes. En entornos de bajo riesgo, esto genera aceleración en lugar de caos, abriendo espacio para el aprendizaje y la experimentación rápidos.

Delegar no consiste en delegar todo, sino en delegar lo que sea. bien Cosas. Las partes donde la claridad es alta, los riesgos son manejables y la iteración es barata.

Cuando la delegación no tiene sentido

Lo inverso es igual de importante. Si la tarea implica decisiones arquitectónicas, lógica sensible a la seguridad o cualquier aspecto donde un fallo tenga un impacto real, ceder el control a un agente implica más riesgo que recompensa. Cuando el equipo aún no comprende completamente el problema, el agente no puede compensarlo, lo que aumenta la incertidumbre.

La automatización no reemplaza el pensamiento. Acelera lo ya comprendido. Los agentes ayudan mejor cuando las personas lideran: priorizan el diseño, la dirección y la claridad. En el momento en que la responsabilidad se vuelve crucial, la delegación se convierte en supervisión, no en automatización.

La verdadera habilidad: saber qué puede funcionar en piloto automático

El desarrollo agente no consiste en usar IA en todas partes: se trata de usarla inteligentemente. Los equipos se benefician al máximo cuando trazan una línea clara entre lo que se puede automatizar y lo que debe permanecer deliberadamente controlado por el ser humano. Leo lo resumió durante un taller de una forma que toda la sala recordó:

El objetivo no es dejar de programar. Es comprender que hay otra manera de alcanzar el resultado; una en la que nuestra contribución es más valiosa en la arquitectura, la planificación y la preparación del sistema. Los agentes pueden ayudarnos, pero solo si los guiamos con la estructura adecuada.

Ése es el núcleo del trabajo de agencia.

La IA acelera, pero no decide. Ejecuta, pero no imagina. Brilla, pero solo cuando le damos el espacio y la dirección para hacerlo.

Nybble ha aprendido esto no en teoría, sino en la práctica. Delegar es eficaz cuando se elige con cuidado. Y las empresas que dominen ese criterio serán las que construyan con mayor rapidez, inteligencia y confianza en los resultados.

Porque, al final, la verdadera ventaja no reside en usar agentes en todas partes, sino en usarlos con intención. Cuando los equipos eligen con sabiduría, el contexto es claro y la autonomía se define con propósito, los resultados dejan de parecer mecánicos y empiezan a ser realmente extraordinarios.

Así es como abordamos el desarrollo de agentes en Nybble: reflexivos, prácticos y siempre enfocados en crear soluciones que importen.