Hace un mes decidí intentar algo que muchos están discutiendo pero pocos están usando en producción: desarrollar una feature real utilizando agentes de IA, lo que muchos están llamando hoy en día Agentic Engineering. Existen varias definiciones de esta disciplina, pero me gusta pensarla algo así como:
“Un modelo de trabajo donde el ingeniero deja de ser quien escribe cada línea de código y pasa a orquestar agentes de IA que ejecutan tareas de desarrollo con cierta autonomía”.
Luego de haber utilizado Claude Code, la herramienta de Anthropic para desarrolladores basada en su LLM Claude, me puse a pensar en algunas implicaciones que este nuevo modelo de trabajo tiene para nosotros los ingenieros de software.
El desarrollador como supervisor de agentes
Lo primero que noté al adoptar este nuevo modelo de trabajo es que dejé de ser yo quien escribía el código fuente, delegando esta tarea a un agente de IA.
Comencé a usar Claude Code para pequeñas pruebas, pero luego me mandé de lleno a intentar construir una feature real de nuestra plataforma. Quería probar esta herramienta en código productivo yo mismo antes de pedirle a mi equipo que lo haga.
Diagrama del cambio de paradigma en el rol del desarrollador.
Con la ayuda de Claude Code, comencé a planear y definir la implementación de esta funcionalidad. Noté rápidamente que el agente era un gran compañero de brainstorming. Yo le tiraba ideas, basadas en mi conocimiento de la feature y del código actual, mientras él me daba buenos insights acerca de cómo podríamos implementar la funcionalidad sin romper nada de lo existente.
Luego de eso, el agente comenzó a codear. Quedé fascinado con el resultado. El agente había entendido nuestro estilo de código, bien orientado a objetos, y pudo implementar la feature casi como si lo hubiera hecho yo mismo.
En cierto momento me di cuenta de algo curioso: me sentí como un líder técnico para el agente.
Productividad: ¿cuánto hay de cierto?
¿Aumentó mi capacidad para escribir código? Sí, muchísimo. ¿Se traduce esto inmediatamente en un incremento de la productividad? Es difícil asegurarlo, pero mi sensación es que sí hay un aumento real.
Sin embargo, no veo que este incremento de productividad justifique todo el “hype” que ha generado en la industria.
Después de todo, tanto la generación de código como el despliegue y monitoreo de aplicaciones son problemas que la industria resolvió razonablemente bien desde hace varios años.
El verdadero problema de la ingeniería de software es, y siempre ha sido, definir qué es lo que se debe construir. Lograr definir exactamente lo que una computadora debe hacer sigue siendo la parte que más tiempo consume. Es lo que genera tantas idas y vueltas entre desarrolladores, negocio y producto. Y en ese aspecto, el Agentic Engineering aún no trae soluciones definitivas.
Por eso, si bien soy optimista respecto a este nuevo modelo de trabajo y creo que realmente ayudará a incrementar nuestra velocidad de entrega, tengo una visión moderada del aumento de productividad que genera.
Ownership y responsabilidad
Uno de los principios de trabajo que tenemos en Desarrollo y Tecnología aquí en Macro Securities es el de Radical Ownership.
Es decir, los desarrolladores son dueños de las features que desarrollan, siendo responsables tanto de la implementación como de su correcto funcionamiento en producción.
Nunca ha sido más cierto esto que al introducir Agentic Engineering.
A pesar de que la feature está siendo desarrollada por agentes de IA, si algo se rompe en producción, ¿quién debe responder?
Al menos por ahora, los agentes de IA no pueden asumir responsabilidad por el código que generan ni por las acciones que realizan en ambientes de prueba o producción. El agente no entiende el concepto de responsabilidad. No siente lo mismo que un humano cuando debe hacer un release a producción. De hecho, no siente nada. Y Anthropic tampoco se hará responsable de los errores que cometan sus agentes en los productos de las empresas que utilizan Claude para generar código.
La responsabilidad sigue recayendo sobre el desarrollador.
Por eso debemos estar preparados para responder si algo sucede.
Además, existe tal cosa como el uso negligente de agentes de IA. Con una herramienta capaz de generar miles de líneas de código en una tarde, el potencial para desastres aumenta drásticamente.
Al implementar una feature en una base de código existente, sentí que tenía el modelo mental del microservicio que estaba modificando, y eso hacía relativamente fácil revisar los cambios que el agente iba introduciendo. Pero cuando le pedí crear un microservicio desde cero, sentí que me costaba mucho más construir ese mapa mental.
Por eso decidí guiar mucho más el desarrollo de algo nuevo, para asegurarme de entender lo que estaba ocurriendo en el código. Porque la realidad es que no puedo hacerme responsable de algo que no entiendo cómo funciona.
El desafío para los devs menos experimentados
Mientras todo esto ocurría, un pensamiento se disparó en mi mente.
Yo puedo guiar a los agentes de IA y entender cómo utilizarlos para crear código, integrar sistemas distribuidos, desplegar y monitorear aplicaciones porque llevo más de 16 años haciendo esto sin ayuda de la IA.
Pero ¿cómo podrán los desarrolladores menos experimentados guiar de forma eficiente a los agentes y hacerse responsables del resultado? ¿Con qué criterio lo harán? Mi presentimiento es que hoy, más que nunca, es importantísima la formación de ingenieros capaces de entender los rudimentos de la computación y de la ingeniería de software.
Parte del roadmap de formación de nuevos desarrolladores debería incluir aprender a programar sin asistencia de IA.
Incluso ingenieros curtidos, como es mi caso, debemos buscar entender qué sucede cuando los agentes utilizan skills o herramientas de línea de comando. En un mundo que demanda eficiencia y rapidez, debemos seguir luchando por aprender.
No podemos exigir una aceleración artificial en la formación de nuevos ingenieros. Con paciencia, debemos formar profesionales dedicados a la excelencia.
No es bueno tomar atajos en este sentido. Porque en un mundo donde todos dependemos de sistemas de información, si lanzamos a la próxima generación de desarrolladores a utilizar IA sin que antes comprendan los fundamentos de nuestra profesión, podríamos estar gestando una catástrofe de escala mundial.
Intent-Driven UIs: Un cambio de paradigma
Los agentes de IA no sólo cambian la forma en que construimos software. También están empezando a cambiar qué construimos.
Las experiencias de usuario tradicionales están definidas por nosotros, quienes desarrollamos el producto digital.
Pero sospecho que la forma en que diseñamos interfaces cambiará radicalmente en el corto plazo. Esto se debe a la adopción creciente de agentes de IA por parte de las personas. Cada vez más gente utiliza LLMs para hacer consultas, realizar su trabajo o incluso manejar sus finanzas personales.
Por eso veo dos cambios importantes en la experiencia de usuario:
- la incorporación de interfaces conversacionales en las aplicaciones que usamos todos los días
- la integración de las plataformas digitales en las interfaces de los LLMs más utilizados, como ChatGPT, Claude o Google Gemini
En ambos casos ocurre algo interesante: a través de una interfaz conversacional, son los usuarios quienes definen cómo quieren usar nuestras plataformas.
- Qué datos quieren ver.
- En qué formato.
- Qué acciones desean realizar.
En otras palabras, la experiencia empieza a estar definida por la intención del usuario. De ahí surge la idea de Intent-Driven UIs.
¿Qué significa esto para los equipos de desarrollo?
En vez de diseñar pantallas, empezamos a pensar en restricciones; qué puede y qué no puede hacer el agente. En guardrails de negocio y compliance. En componentes que el agente compone dinámicamente según la conversación. Y sobre todo, en cuándo el agente puede actuar solo y cuándo debe pedir confirmación.
El UX no desaparece. De hecho, se vuelve más crítico y más difícil. Antes podías testear un flujo. Ahora el espacio de flujos posibles es enorme.
La pregunta ya no es “¿es este flujo intuitivo?” sino: ¿son mis restricciones las correctas? ¿qué ocurre cuando el agente interpreta la intención de forma inesperada?
Conclusión
El Agentic Engineering probablemente cambie profundamente la forma en que desarrollamos software.
Pero no cambia, al menos por ahora, lo más difícil de nuestra profesión: entender el problema que estamos resolviendo y asumir responsabilidad por el software que ponemos en producción.
Los agentes pueden escribir código. Pero la ingeniería sigue siendo una actividad humana.
¿Usas Agentic Engineering en tu trabajo?