Agentic Engineering - 47 horas aprendiendo a trabajar con un equipo de agentes

Un equipo que no es un equipo.

“Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.” - Ian Malcolm ¹

Hace unos meses escribí que era demasiado viejo para esto. Ahora llevo casi 47 horas construyendo software con un pequeño equipo de agentes de IA, y quiero dejar por escrito lo que he aprendido antes de olvidar lo equivocado que estaba al principio.

El proyecto aquí no importa (es un proyecto personal para Android, nada especial). Lo que importa es el proceso: cuánto tiempo me llevó, cuántos tokens quemé, qué intenté arreglar y si el arreglo funcionó de verdad. Como siempre, este es un blog sobre procesos, no sobre objetivos.

Ten paciencia (otra vez)

Todo el mundo habla de agentes, así que antes de seguir aclaremos qué es un agente, al menos para mí.

Un chat LLM responde. Tú escribes, te devuelve texto y tú decides qué hacer con él. Eres tú quien copia el código, lo ejecuta y vuelve a pegar el error.

Un agente actúa. Simon Willison tiene la definición más corta que conozco:

“Un agente LLM ejecuta herramientas en bucle para alcanzar un objetivo.” - Simon Willison ²

Lee ficheros, ejecuta comandos, comprueba el resultado y decide el siguiente paso por sí mismo, una y otra vez hasta cumplir el objetivo (o hasta perderse). Anthropic hace una distinción útil entre workflows, donde los pasos los fija el código, y agentes, donde el LLM dirige “sus propios procesos y el uso de herramientas” ³.

Esa libertad tiene un precio, y el precio son tokens. Anthropic midió que los agentes usan unas 4 veces más tokens que un chat, y los sistemas multiagente unas 15 veces más ⁴.

Del vibe coding a la agentic engineering

El 2 de febrero de 2025 Andrej Karpathy acuñó el término vibe coding: “déjate llevar por completo por las vibraciones, abraza lo exponencial y olvida que el código siquiera existe” ⁵.

Solo han pasado 20 meses desde entonces, e internet está lleno de defensores y detractores, ambos bandos con “datos” y “pruebas” que respaldan su opinión. Hay demasiados datos para tratarlos aquí (porque no tengo tiempo de verificar todas las historias), pero te recomiendo de verdad que investigues un poco.

Mientras tanto, las herramientas cambiaron. La conversación pasó de “la IA escribe código” a “la IA hace tareas”. El 4 de febrero de 2026 el propio Karpathy eligió un nombre nuevo: agentic engineering. “Agentic” porque orquestas agentes en lugar de escribir tú el código el 99% del tiempo, y “engineering” porque hay “un arte, una ciencia y una pericia en ello” ⁶.

Solo 12 meses separan ambos términos, pero este mundo va muy rápido y tienes que adaptarte, aunque nadie tenga claro de qué estamos hablando.

Y el mercado laboral se dio cuenta:

• El grupo de habilidades “Agentic AI” pasó del 0,06% de las ofertas de empleo de EE. UU. en 2024 al 0,23% en 2025, un crecimiento de más del 280% (~90.000 ofertas) ⁷. Todavía es poco, pero crece rápido.
• Indeed indica que las ofertas de desarrollo de software en EE. UU. crecieron casi un 15% desde el lanzamiento de Claude Code, mientras que el total de ofertas cayó un 7%, y el 71% de ese crecimiento vino de puestos senior ⁸.

Mi lectura: las empresas ya no buscan gente que use IA, eso es lo mínimo. Buscan gente capaz de hacer que los agentes produzcan software fiable a un coste razonable. Que es justo lo que yo no sabía hacer.

Mi “media vida como senior” no vale nada, y tengo que aprender o extinguirme.

El proyecto

El objetivo: crear un workflow de agentic engineering y usarlo para desarrollar una app móvil de principio a fin (ahora mismo no está terminada, acabo de llegar al MVP).

Tomé como referencia el workflow que presenta Kun Chen en este vídeo ⁹, porque mientras investigaba qué es realmente la agentic engineering y por qué todo el mundo habla de ella, este vídeo fue el que me ayudó a entender de verdad cómo debería funcionar. Probablemente fue algún tipo de “sesgo de confirmación”, pero necesitaba un primer paso sobre el que empezar a trabajar.

Los números

En mi segundo post prometí que mediría el tiempo como es debido. Esta vez lo hice, o mejor dicho, le pedí a Claude Code que lo midiera a partir de sus propios registros de sesión: cualquier actividad cuenta como un bloque continuo salvo que pasen más de 30 minutos sin actividad. Incluye el tiempo en que los agentes trabajan solos mientras yo estoy delante de la pantalla, pero no el tiempo pensando o planificando fuera.

Total: 46,9 horas en 14 días (del 2026-09-20 al 2026-10-18), aproximadamente 1,2 semanas de trabajo a tiempo completo.

Sobre el dinero: una vez estable la configuración, cada pull request mergeada me cuesta unos 4 $ en tokens. La semana más cara subió a ~5,6 $ por PR (8 PRs, ~45 $). Más abajo explico por qué.

Aprendizajes

1. Copié un equipo humano y obtuve problemas de equipo humano

“Cualquier organización que diseña un sistema producirá un diseño cuya estructura es una copia de la estructura de comunicación de la organización.” - Melvin Conway ¹⁰

Yo hice lo mismo (o algo parecido): diseñé un equipo de agentes como copia de una especie de pequeño equipo humano. Mi primer diseño tenía cuatro agentes: un Brain que hablaba conmigo para analizar el proyecto y planificar roadmaps. Una vez clara la imagen, crearía las tareas y actuaría como orquestador, creando un “trío de trabajo” para cada tarea: un planner para planificar la tarea o tomar decisiones si hacía falta, un executor que ejecuta (obviamente) y un reviewer que comprueba el resultado sin el sesgo ni el contexto de sus dos compañeros. Alguien que planifica, alguien que construye, alguien que revisa, todos hablando entre sí. Como un equipo de verdad.

Y el sistema reprodujo los problemas de coordinación de un equipo humano.

• Qué pasó: en la primera tarea real, el planner se convirtió en un segundo Brain. Mandaba tareas al executor, leía su trabajo, verificaba el entorno por su cuenta y reenviaba información al reviewer. Brain hacía las mismas comprobaciones. La mayor parte del tiempo el planner solo reenviaba una lista de tareas que ya estaba escrita en un fichero.
• Coste: ~9,3M de tokens de caché leídos por Brain (sobre todo en bucles de polling) y ~1,3M por el planner, para una sola tarea pequeña.
• Medida: eliminé el planner. Ahora Brain es el único hub: planifica conmigo por adelantado, el plan vive en ficheros, y executor y reviewer nunca hablan entre sí. Las transiciones entre ellos son un comando bash y un fichero de estado, cero tokens.
• ¿Funcionó? Sí. Una semana después tenía varias tareas ejecutándose en paralelo. Es el mismo patrón hub-and-spoke que describen Anthropic y Cognition ^{4 11}.

La lección: los agentes son agentes, no personas. Hablar es barato para los humanos y caro para los agentes: cada mensaje cuesta tokens y cada salto pierde contexto. Un agente no necesita un mando intermedio, necesita un plan cerrado y un contexto limpio. Y un agente parado no cuesta nada, así que no hace falta “tenerlo ocupado”: crea uno por tarea y tíralo al terminar.

2. Medir antes de optimizar

• Qué pasó: un día el executor costó 10,5 $, más que Brain. Estaba haciendo trabajo real de UI con muchas capturas de pantalla, así que la conclusión obvia fue “las imágenes son caras”. Incluso pedí un deep research sobre cómo reducir el coste de las imágenes.
• Medida: antes de aplicar nada, medí los transcripts.
• Resultado: las imágenes solo eran el ~10% de ese coste (1,1 $ de 10,5 $). Tras 7 tareas más, estaban entre el 1% y el 9% (18% en una tarea con 26 capturas). El coste real era el contexto de texto que crece dentro de las sesiones largas: el 55-70% del coste del executor estaba en su primera ronda, con el contexto pasando de ~20k a 150-226k tokens.
• ¿Funcionó? La optimización nunca se aplicó, y ese fue el éxito. La investigación sirvió para descartar una mejora “obvia” que no lo era. Viniendo del tipo que escribió que las comprobaciones visuales le quemaron todos los tokens en 10 minutos ¹², me hace gracia.

La lección: mide mucho, mídelo todo. Si hay una tarea en la que la IA es buena, es midiendo. Todas mis sesiones las analizó una sesión aparte de Claude Code: no un agente, ni siquiera en el mismo proyecto. Los agentes solo saben de la app que están construyendo, pero tengo otra sesión como observadora externa, tomando métricas y hablando conmigo sobre el proceso.

3. Menos pasos, menos tokens

• Qué pasó: estaba usando la skill de OpenSpec, para aprenderla y para organizar el trabajo. Decidí que archivar cada tarea terminada sería una PR aparte, porque quería comprobarlo yo mismo. Yo era el “humano en el bucle” y no quería dar una tarea por cerrada hasta que yo, “el poderoso humano”, la validara (como si pudiera: no he usado Kotlin en mi vida, así que mi validación no es… la mejor). Esto requería su propia PR, con su propio agente, revisión y run del gate, solo para mover ficheros. Costaba tiempo y tokens.
• Medida: ahora archivar es el último paso de la tarea, dentro de la misma PR.
• ¿Funcionó? Sí, un ciclo completo menos por tarea.

La lección: lo que funciona para los humanos no funciona para los agentes. En un post anterior hablé de la documentación que van a leer las IAs, y parece que los procesos siguen la misma regla. Diseña el proceso para IAs, no copies los procesos humanos.

4. Localiza los nuevos cuellos de botella

• Qué pasó: la primera vez que ejecuté dos tareas realmente en paralelo, ambas se pelearon por el único emulador de Android (bloqueadas dos veces, una validación en vivo que nunca se hizo) y por el único hueco del gate.
• Medida: todavía ninguna. Esto es interesante porque los cuellos de botella en un equipo humano son bastante distintos de los de un equipo de agentes. Al principio el cuello de botella era yo: no era capaz de revisar el trabajo y responder a Brain más rápido de lo que los workflows generaban cambios. Cuando encontré mi ritmo, descubrí que los recursos limitados (en este caso el emulador) hacían esperar a mis agentes. No es un gran problema, porque un agente parado no tiene coste, pero es una de las cosas que quiero aprender a resolver. Para aprovechar de verdad el poder de tener varios workflows trabajando en paralelo, tengo que encontrar la manera de solucionarlo.

5. Los cambios grandes se comen las rondas de revisión

• Qué pasó: una PR superó el límite de 400 líneas (una medida que elegí para ayudarme con mis revisiones de código manuales) y la acepté como excepción. Necesitó 4 rondas de revisión y 5 runs del gate en dos días. Cada ronda encontraba un bug de concurrencia distinto en la misma clase, así que mi regla de “el mismo hallazgo dos veces se escala” nunca saltó.
• Coste: esta PR es la razón por la que esa semana pasó de ~4 $ a ~5,6 $ por PR.
• Lección: el aviso de tamaño tenía razón. Debería haberle hecho caso.

6. Pequeñas cosas que funcionaron

• Política de bugs sin preguntar: cada vez que se encontraba un bug, todo se paraba esperando mi aprobación. El humano en el bucle debería tener sus límites. No podemos dejar que el agente vaya hasta el final hasta alcanzar su objetivo, pero si el agente está tan limitado que necesita tu validación para todo, colapsarás en cuanto lances 7 workflows en paralelo. Así que los bugs que introduce la PR siempre se corrigen automáticamente. Los que ya existían se corrigen en la misma PR si son pequeños y están en código que la PR toca; si no, se abre un issue nuevo. Menos preguntas para mí, menos interrupciones.
• Limpieza de contexto: el contexto de Brain crece sin control. Necesita hablar conmigo, enviar entradas y leer las salidas de todos los demás agentes, y eso resultó ser un problema. Así que cuando el contexto llega a un tamaño clave, escribe un fichero de checkpoint, yo limpio el contexto, Brain empieza de cero y ahorramos muchos tokens sin perder calidad.

Conclusión

Cuarenta y siete horas después, mi principal aprendizaje no es técnico. Con agentes, la estructura de comunicación la diseño yo, nada viene dado. Lo que mi seniority puede aportar es diseñar el proceso, no el código. Pero no puedo copiar un equipo humano: los costes, las herramientas, las formas de trabajar… todo debe diseñarse según cómo trabajan los agentes.

Y no he hablado de skills ni de modelos (cada agente tiene un conjunto distinto según la tarea que necesita hacer). Afinar la configuración es una tarea eterna que solo puede hacer el humano, y todavía tengo que aprender a hacerlo (voy de camino).

Y recuerda: la intuición es barata, medir es más barato. Dos veces estaba seguro de adónde iban los tokens, y dos veces me equivoqué. Mi intuición curtida necesita recalibrarse; mientras tanto, mide como un developer loco.

Espero que lo hayas disfrutado.

Gracias por leer.