Agentic AI: How AI Agents Transformed My Work as a Software Engineer and CEO

Introducción

Hola a todos, me llamo Simon Harrer. Soy doctor en sistemas distribuidos y pasé siete años en INNOQ como arquitecto de software y consultor. Desde 2025 soy Co-Founder y CEO de Entropy Data, un spin-off de INNOQ.

Además, soy coautor del libro "Java by Comparison" y cotraduje el libro "Data Mesh" al alemán. También soy co-maintainer de las herramientas open source mob.sh y Data Contract CLI. Y formo parte del Technical Steering Committee del proyecto BITOL de la Linux Foundation, dedicado a los estándares de Data Contracts y productos de datos.

Hoy quiero hablar de cómo los agentes de IA han transformado por completo mi forma de trabajar, tanto de ingeniero de software como de CEO.

Mi momento IA personal

Era abril de 2025. Iba en un tren a Berlín con André Deuerling. Gracias a Deutsche Bahn acumulamos más de dos horas de retraso. Así que nos instalamos en el vagón restaurante y fuimos pidiendo cervezas. André ya usaba Claude Code, así que decidimos probarlo juntos.

La tarea: construir un servicio Spring Boot que se conectara a una base de datos MariaDB, leyera todos los esquemas, tablas y columnas, y enviara esos metadatos a la API de nuestro producto. La regla era simple: cero líneas de código escritas a mano. Solo prompts.

Estuvimos unas dos horas con ello. Revisábamos lo que generaba, seguíamos prompteando, replanteábamos decisiones de arquitectura. Luego conseguimos las API keys, configuramos un par de cosas a mano, lo arrancamos y funcionó. Todo funcionó a la primera.

Ese fue mi momento IA personal. El instante en que entendí que algo fundamental había cambiado.

¿Qué es un agente?

¿Y qué es un agente? En realidad es muy sencillo: un LLM que usa herramientas en un bucle.

Claude Code es exactamente eso. Hay un LLM corriendo por detrás con acceso a un conjunto de herramientas: puede hacer llamadas por CLI, leer y escribir archivos, buscar en internet, ejecutar tests, compilar código. Incluso la memoria es una herramienta más, básicamente una lista de tareas a la que el agente accede a través de una interfaz de herramienta.

Ese es todo el concepto. Un LLM que usa herramientas en un bucle. Y aun así, como verás, este concepto tan simple lo cambió todo en mi manera de trabajar.

Los primeros pasos

Después de aquella experiencia empecé a usar Claude Code cada vez más. Y voy a ser honesto: al principio no todo salía bien. A veces tiraba el código generado entero y volvía a programar a mano. Pero seguí insistiendo.

Me suscribí al plan de 20 $ al mes. Se sentía como una suscripción a Netflix: poco compromiso y mucho margen de ganancia.

El punto de inflexión: los modelos Opus

Entonces llegó Opus 4.5, en noviembre de 2025. Ese fue el verdadero punto de inflexión.

Déjame enseñarte el benchmark de METR. Mide la duración de las tareas que los LLM completan con éxito al menos el 50 % de las veces. GPT-5.1 y Codex Max se quedan en torno a las tres horas. Opus 4.5 saltó a unas cinco horas, un salto enorme. La curva es exponencial.

Luego llegó Opus 4.6 en enero y volvió a duplicarlo, hasta unas doce horas. La diferencia se nota muchísimo al trabajar con él. Tareas grandes y complejas que antes la IA no podía abordar ahora están a tiro.

La duración de las tareas se duplica cada seis meses

El patrón está claro: la duración de las tareas se duplica más o menos cada seis meses. Lo que antes parecía imposible se convierte enseguida en lo normal.

En cuanto vi esto, pasé al plan de 100 $ al mes sin pensarlo. Es multiplicar por cinco el gasto, y no hubo ni un segundo de debate interno. El valor era evidente.

Para qué uso los agentes

Vamos con los casos de uso concretos. Uso agentes para:

• Desarrollar funcionalidades con tests: el pan de cada día.
• Pruebas de UX con el Playwright MCP Server: tests automatizados en el navegador.
• Aprovisionar infraestructura con Terraform: ya no tengo que leer la documentación de Terraform nunca más.
• Optimizar rendimiento con el MCP Server de Dash0: conectado a logs, trazas y métricas de OpenTelemetry. Puedo decirle «analiza mi rendimiento, mira el código, ¿podemos mejorarlo automáticamente?» y lo hace.
• Implementar tickets con la CLI de GitHub: el agente lee el ticket y lo implementa.
• Generar el changelog a partir de los commits de git.
• Documentación con capturas de pantalla automatizadas: se acabó contratar a gente para escribir manuales de usuario.
• Pruebas exploratorias: buscar bugs en la app en producción, incluidos los visuales y el cumplimiento de la guía de diseño.
• Redactar patentes: escribí una patente con un colega usando IA. Un abogado de patentes sencillamente no entraba en el presupuesto.
• Revisar contratos de clientes enterprise.

El abanico es enorme. Y cada semana crece un poco más.

Cómo ha cambiado mi trabajo

Ya no escribo mensajes de commit. Digo «claude push» y lo genera a partir del contexto. Tampoco escribo código: dejo que se escriba y luego lo reviso. Mucho. Esa es hoy mi actividad principal: dar instrucciones y revisar.

Y voy a ser sincero: ya no lo reviso todo. Reviso de forma selectiva, en función del riesgo. Es un trade-off y soy consciente de ello. Pero te adelanto el spoiler: sin ese trade-off, el software directamente no existiría. Habría tardado demasiado.

También trabajo con dos o tres terminales en paralelo, porque hay tiempos muertos naturales mientras la IA procesa. Mientras un agente avanza con una tarea, yo estoy revisando o prompteando en otra.

Modo YOLO

Desde hace unas tres o cuatro semanas tengo el modo YOLO activado. Es decir, Claude puede hacer lo que quiera, salvo tocar producción.

Antes tenía activado el modelo de seguridad, en el que Claude pide permiso antes de ejecutar comandos. Pero acabé desarrollando lo que llamo «fatiga de aprobación». La IA se paraba a preguntar trivialidades del tipo «¿puedo ejecutar este comando find?». Y me descubría pulsando Intro sin leer siquiera lo que ponía. Llegados a ese punto, el modelo de seguridad es puro teatro, no seguridad.

Así que le di la vuelta: dejo que la IA trabaje de forma autónoma hasta que considera que la tarea está lista. No quiero volver atrás. Me sigue faltando un modelo de seguridad mejor, porque la seguridad no da igual, pero hoy por hoy este es el mejor equilibrio en términos de productividad.

Un momento para reflexionar

Paremos un momento. Han sido muchos cambios y en muy poco tiempo.

Trabajé de la misma manera durante diez años. Y luego, en apenas once meses (de abril de 2025 a marzo de 2026), cambió todo. Sigo construyendo un producto de software. Pero la forma en que ese software se crea es completamente distinta.

Y no es más que «un LLM que usa herramientas en un bucle». Nada más. Y aun así lo cambió todo.

Subagentes y equipos de agentes

Pero la cosa no acaba ahí. La siguiente evolución son los subagentes: el agente principal lanza agentes más pequeños para tareas de investigación. Por ejemplo: «averigua cuál es la mejor forma de instrumentar esta librería». El subagente se va, investiga y devuelve los resultados. Así el contexto del agente principal se mantiene limpio de ruido. Parte de esto ya ocurre de forma automática, por ejemplo con el investigador que Claude lleva integrado.

Más allá están los equipos de agentes: montas un equipo con un arquitecto que critica el diseño, alguien de UX que critica la interfaz y un programador que construye. Los dejas interactuar e iterar. Lo he probado un par de veces. Todavía es pronto para valorarlo y consume bastantes más tokens. Pero la dirección está clara.

El salto a la nube

El camino lleva de forma natural a la nube. Todo lo que he descrito hasta ahora pasaba en mi MacBook local. Pero ahora hay una interfaz web. Puedo lanzar tareas desde el móvil o desde el navegador. Puedo poner trabajo en marcha antes de irme a dormir, en un viaje o incluso justo antes de una keynote como esta.

El agente trabaja y, cuando termina, me muestra algo así como «69 líneas añadidas, 5 borradas». Puedo revisar los cambios y crear un pull request. El agente trabaja mientras yo no estoy delante del escritorio.

Agentes orientados a eventos

El disparador también está cambiando. Ya no es solo una persona diciendo «haz esto». Cuando nos salta una alerta en las herramientas de observabilidad, un agente puede evaluarla automáticamente. Si es una excepción (por ejemplo, alguien usó en una plantilla algo que no existe), el agente puede crear el arreglo y abrir un pull request. Nosotros solo hacemos clic para mergear.

Lo mismo vale para pipelines de CI que fallan, comprobaciones post-commit (como verificar que la documentación sigue alineada con el código) y cron jobs diarios o semanales para agentes. Todo esto corre desde workflows normales de CI/CD en GitHub o GitLab. Los agentes se están convirtiendo en parte de la infraestructura.

Spec-driven development: los agentes trabajan mientras duermes

Me inspiró una oferta de empleo de Anthropic, esa que ofrecía 500.000 $ al año y exigía «uso máximo de Claude». Me hizo pensar: ¿cómo consigo que los agentes trabajen incluso cuando yo no estoy trabajando?

La respuesta es spec-driven development con una herramienta llamada AutoClaude. Es básicamente un tablero Kanban: meto tareas, las describo (la IA incluso me ayuda a redactar las descripciones), pongo un límite de trabajo en curso de tres y lo dejo corriendo toda la noche. Tuve que pasar al plan de 200 €, porque los límites de tokens del plan anterior se me quedaban cortos.

A nivel técnico, clona el repositorio, crea una rama con git worktree para cada tarea y trabaja en local. Lanzo diez tareas antes de acostarme y las reviso por la mañana.

El flujo es: planificar, programar, un bucle de QA, revisión por IA y, por último, revisión humana. La herramienta genera una spec, produce un visto bueno de QA e incluso ayuda a definir la hoja de ruta del producto mediante análisis de la competencia e identificación de carencias funcionales.

La idea clave: el agente trabaja mientras duermo y por la mañana me siento a revisar resultados.

El trade-off de calidad

Quiero ser transparente con algo importante: la calidad no es tan alta como cuando lo programaba todo a mano. La arquitectura no está tan limpia. El naming podría ser mejor. El código no está tan pulido.

Pero aquí está la clave: el software no existiría sin IA. Si me hubiera empeñado en mantener mi estándar anterior, no habríamos llegado a entregar nada.

Si trabajas en un sector donde la perfección absoluta es obligatoria, como los controles de un avión o los sistemas de seguridad ferroviaria, quizá este trade-off no te sirva. Pero ¿para software de negocio B2B? Va más que sobrado. La ganancia en velocidad supera con mucho la diferencia de calidad.

La mirada del CEO: el presupuesto de IA

Cambio de perspectiva y me pongo el sombrero de CEO. Así ha evolucionado nuestro presupuesto de IA por persona y mes:

• 2025: 20 € por persona y mes
• 2026: 100 € (en realidad ya 200)
• 2027: 1.000 € (estimación conservadora)
• 2028: 2.000 €

En Silicon Valley ya hay empresas que calculan el presupuesto de IA como un 10-20 % del salario. Eso son unos 20.000 € al año. Están ya donde yo espero que estemos nosotros en 2028.

¿Ha muerto el IDE?

No vamos a renovar nuestras licencias de IntelliJ. Y eso que teníamos un 50 % de descuento para startups. Pero ya no le veo el valor. Uso IntelliJ solo por costumbre y para revisar cambios de código. ¿Por qué pagar 1.000 € al año solo por eso? Claude Code cuesta 100 € al mes y es una inversión mucho mejor. Es una cuestión de coste de oportunidad. Y como la Community Edition ya no es una opción viable para uso comercial, las cuentas salen aún más claras.

Hace poco vi un post en LinkedIn de Ralf Müller que defendía que "The IDE Is Dead". Tenía 27 likes y más de 53 comentarios (actualización del 12 de marzo de 2026: 113 comentarios), todo el mundo defendiendo su IntelliJ porque lo adora. Es un tema emocional. La gente se encariña con sus herramientas. Pero el cariño no debería decidir el presupuesto.

6 ingenieros = 60

Puedes montar una startup de SaaS B2B con solo seis ingenieros. Esos seis logran lo que antes exigía sesenta. No vamos a contratar a mucha más gente. Las empresas verán un beneficio por empleado mucho mayor. El escalado llega por la vía del gasto en IA, no de la plantilla.

Por eso van a surgir muchas empresas pequeñas. Nosotros entregamos funcionalidades a una velocidad brutal porque nuestros ingenieros son product engineers, no solo software engineers. Toman decisiones de producto rápido. Entienden al cliente. Ese es el gran diferencial: poder delegar las decisiones de producto en personas que entienden de verdad tanto la tecnología como al cliente.

Construir hoy es casi gratis. El cuello de botella real es decidir qué construir y delegar la responsabilidad de esas decisiones.

A quién contratamos

Contratamos de forma muy selectiva. Nuestras prioridades son:

• Juniors: son AI-native. No tienen que desaprender flujos de trabajo antiguos. Han crecido con estas herramientas.
• Principals: aportan enfoque de producto, un conocimiento profundo del cliente y pensamiento estratégico. Valen la inversión.
• Seniors: en tercer lugar. No están mal, pero en un mundo AI-native los otros dos perfiles aportan más.

La gran oportunidad: los datos de la empresa

Pero las oportunidades son aún mayores en otro sitio. El agentic coding solo usa código, datos de telemetría y tickets. Los desarrolladores vivimos en nuestro mundo de código, pero la gente de negocio piensa en datos. Lo realmente emocionante llega cuando metes en la ecuación los datos de la empresa.

Imagina preguntar: «¿por qué han fluctuado más los costes energéticos de producción en los últimos doce meses?» (fuente: BARC). Un agente podría responder a esa pregunta en una hora. Analizaría los datos de producción, los cruzaría con los precios de la energía, miraría los patrones de planificación y sintetizaría una respuesta.

Acuérdate: un agente no deja de ser un LLM que usa herramientas en un bucle. También puede responder preguntas de negocio, no solo de programación. Solo que ahora trabaja con datos de la empresa: datos de clientes, de salud, financieros, operativos.

A través de herramientas, los agentes pueden traerse los datos de la empresa y hacer cualquier cosa con ellos. Ahí es donde está el valor real para la mayoría de las organizaciones.

La capa de gobernanza

Viene un ejército de agentes y todos quieren acceso a los datos de la empresa. El ochenta por ciento de los empleados lo quiere. Pero hay retos serios que resolver:

• Control de acceso: ¿quién puede acceder a qué?
• Descubribilidad: ¿cómo encuentran los agentes los datos correctos?
• Semántica de los datos: ¿qué significan realmente estos datos?
• Condiciones de uso: ¿bajo qué condiciones se pueden usar estos datos?
• Calidad de datos: ¿hasta qué punto son fiables?
• SLA y garantías: ¿qué rendimiento y disponibilidad cabe esperar?

Necesitas una capa de gobernanza entre los agentes y los datos y las API de la empresa. Sin ella, o bloqueas a los agentes por completo o te montas una pesadilla de seguridad y cumplimiento.

Demo en directo: los agentes se encuentran con los datos de la empresa

Te enseño una demo en directo. Le pregunto al agente: «¿qué tickets de soporte aparecen con más frecuencia?».

El agente busca entre la oferta de datos disponible y encuentra una tabla relevante en una base de datos. Solicita acceso y se le aprueba automáticamente, porque no son datos sensibles. Después lanza consultas SQL y analiza los datos desde varios ángulos.

El resultado: los incidentes suponen el 40 % de los tickets, seguidos de las peticiones, luego los problemas y por último los cambios. A partir de aquí el agente podría seguir trabajando: profundizar, cruzar con otras fuentes de datos o generar recomendaciones. La capa de gobernanza es lo que hace posible todo esto de forma segura y controlada.

Una llamada a la acción para los arquitectos

Los arquitectos. Tú.

En el fondo, esto es un problema de arquitectura de software. Tiene que ver con objetivos de calidad, integración de componentes, gestión de interfaces, fronteras de seguridad y diseño organizativo. Probablemente sea la tarea arquitectónica más importante de los próximos años.

Los agentes de arriba solo son tan buenos como la capa de gobernanza que tienen debajo. Sin una Data Governance decente, o los agentes no pueden trabajar o no puedes fiarte de ellos.

Mi llamamiento: si en tu organización hay una iniciativa para construir esta capa, métete. Ayuda a darle forma. Va a determinar el futuro. Porque los agentes van a llegar: esto es demasiado potente y demasiado útil como para que no ocurra.