8 niveles de ingeniería de agentes inteligentes

Autor: Bassim Eledath

Traducido por: 宝玉

La capacidad de programación de la IA está superando nuestra capacidad para controlarla. Por eso, todos esos esfuerzos por puntuar alto en SWE-bench no están alineados con los indicadores de productividad que realmente importan a los líderes de ingeniería. El equipo de Anthropic lanzó Cowork en 10 días, mientras que otro equipo usando el mismo modelo no pudo siquiera crear un POC (prueba de concepto): la diferencia está en que uno ya ha cerrado la brecha entre capacidad y práctica, y el otro todavía no.

Esa brecha no desaparecerá de la noche a la mañana, sino que se reducirá gradualmente por niveles. En total, hay 8 niveles. La mayoría de quienes leen esto probablemente ya han pasado los primeros niveles, pero tú deberías estar ansioso por alcanzar el siguiente, porque cada nivel representa un salto enorme en productividad, y cada mejora en la capacidad del modelo amplifica aún más esos beneficios.

Otra razón importante para preocuparse es el efecto de colaboración en equipo. Tu producción depende más de los niveles de tus compañeros de lo que imaginas. Supón que tú eres de nivel 7, y mientras duermes, un agente inteligente en segundo plano te ayuda a preparar varios PRs. Pero si tu repositorio requiere que un colega apruebe para fusionar y esa persona todavía está en nivel 2, revisando PRs manualmente, tu rendimiento se verá limitado. Por eso, ayudar a tus compañeros a subir de nivel también te beneficia a ti.

A partir de conversaciones con muchos equipos e individuos sobre sus prácticas de programación asistida por IA, aquí está la ruta de progresión por niveles (el orden no es absoluto):

Niveles de ingeniería con IA

Nivel 1 y 2: Autocompletado con pestañas y IDE inteligente

Estos niveles los mencionaré brevemente, solo para dejar constancia completa. Puedes saltártelos si quieres.

El autocompletado con pestañas es el punto de partida. GitHub Copilot inició esta tendencia: con solo presionar Tab, se completa automáticamente el código. Muchos quizás ya lo hayan olvidado, y los nuevos en la industria quizás ni lo hayan experimentado. Es más útil para desarrolladores con experiencia, que primero estructuran el esqueleto del código y luego dejan que la IA rellene los detalles.

Los IDE especializados, como Cursor, han cambiado el juego al conectar chat y repositorios de código, facilitando la edición entre archivos. Pero el límite siempre es el contexto. El modelo solo puede ayudar con lo que ve, y lo frustrante es que a veces no ve el contexto correcto o ve demasiado de él, incluyendo información irrelevante.

En este nivel, la mayoría también experimenta con modos de planificación: convertir una idea vaga en un plan estructurado para el LLM, iterar ese plan varias veces y luego ejecutarlo. Funciona bien en esta etapa y es una forma razonable de mantener control. Pero en niveles superiores veremos que la dependencia en la planificación disminuye.

Nivel 3: Ingeniería de contexto

Aquí empieza lo interesante. La ingeniería de contexto (Context Engineering) se ha convertido en la palabra de moda en 2025, porque el modelo ahora puede seguir instrucciones razonables de forma confiable, siempre que tenga el contexto adecuado. El ruido en el contexto es tan problemático como la falta de él, así que el trabajo clave es aumentar la densidad de información por token. “Cada token debe luchar por su lugar en la prompt” — esa era la consigna en ese momento.

La misma información, menos tokens — la densidad de información es la clave (Fuente: humanlayer/12-factor-agents).

En la práctica, la ingeniería de contexto abarca más de lo que muchos creen. Incluye tus prompts y reglas (como .cursorrules, CLAUDE.md), cómo describes las herramientas (que el modelo lee para decidir qué usar), la gestión del historial de diálogos para evitar que agentes largos se pierdan, y la selección de qué herramientas exponer en cada turno para no abrumar al modelo, como lo hace un humano.

Hoy en día, ya no se habla mucho de ingeniería de contexto, porque la tendencia se inclina hacia modelos que toleran contextos más ruidosos y en escenarios más caóticos (una ventana de contexto más grande ayuda). Pero aún así, el consumo de contexto sigue siendo importante. En estos escenarios, puede convertirse en un cuello de botella:

• Modelos pequeños son más sensibles al contexto. Las aplicaciones de voz, por ejemplo, usan modelos más pequeños, y el tamaño del contexto afecta la latencia y la velocidad de respuesta.

• Tokens consumidos por herramientas. Protocolos como MCP (Model Context Protocol) y entradas de imágenes consumen tokens rápidamente, haciendo que en Claude Code se llegue antes a un estado de “conversación comprimida”.

• Agentes con decenas de herramientas. El modelo gasta más tokens en analizar definiciones de herramientas que en realizar tareas reales.

En resumen, la ingeniería de contexto no ha desaparecido, solo evoluciona. Ahora se centra en asegurar que el contexto correcto aparezca en el momento adecuado, en lugar de filtrar el “ruido”. Este cambio allana el camino para el nivel 4.

Nivel 4: Ingeniería de composición

La ingeniería de contexto mejora la sesión actual. La ingeniería de composición (Compounding Engineering), propuesta por Kieran Klaassen, mejora cada sesión futura. Para mí y muchos otros, fue un punto de inflexión: nos hizo entender que programar por intuición no es solo hacer prototipos.

Es un ciclo de “planificar, delegar, evaluar y consolidar”. Planificas tareas, proporcionas suficiente contexto al LLM para que tenga éxito, delegas, evalúas los resultados y, lo más importante, consolidar lo aprendido: qué funcionó, qué falló, qué patrones seguir en el futuro.

El poder está en la etapa de “consolidar”. El LLM es sin estado. Si ayer reintrodujo una dependencia que tú eliminaste, mañana lo hará otra vez, a menos que le digas que no. La solución más común es actualizar tu archivo CLAUDE.md (o reglas similares), para que las lecciones aprendidas se integren en futuras sesiones. Pero ojo: sobrecargar las reglas con demasiadas instrucciones puede ser contraproducente (demasiadas instrucciones equivalen a ninguna). Mejor aún, crea un entorno donde el LLM pueda descubrir por sí mismo qué es relevante, por ejemplo, manteniendo un directorio docs/ actualizado (detallado en nivel 7).

Quienes practican la ingeniería de composición suelen ser muy sensibles al contexto que alimentan al LLM. Cuando cometen errores, su reacción instintiva no es culpar al modelo, sino revisar si falta algo en el contexto. Esa intuición hace posible avanzar en niveles 5 a 8.

Nivel 5: MCP y habilidades

Los niveles 3 y 4 abordan el contexto. El nivel 5 se enfoca en la capacidad. MCP y habilidades personalizadas permiten que tu LLM acceda a bases de datos, APIs, pipelines CI, sistemas de diseño, herramientas como Playwright para pruebas en navegador, Slack para notificaciones, etc. El modelo ya no solo piensa en tu código, sino que puede actuar directamente.

Hay muchos recursos excelentes sobre MCP y habilidades, así que no los repetiré. Pero algunos ejemplos que uso: un skill compartido para revisión de PRs, que activa agentes especializados según el tipo de PR; uno para verificar la seguridad de integraciones con bases de datos; otro para análisis de complejidad y detección de redundancias; y uno más para chequear la salud de los prompts, asegurando que cumplen con los estándares del equipo. También ejecuta linters y Ruff.

¿Por qué invertir tanto en habilidades de revisión? Porque cuando los agentes producen PRs en masa, la revisión manual se vuelve un cuello de botella. Latent Space argumenta que la revisión de código tradicional está muerta. Lo que viene es una revisión automatizada, consistente y basada en habilidades.

En MCP, uso Braintrust MCP para que el LLM consulte logs de evaluación y haga cambios automáticamente. También DeepWiki MCP, que permite al agente acceder a documentación de repositorios open source sin tener que incluirla manualmente en el contexto.

Cuando varios miembros del equipo crean sus propias habilidades, es útil consolidarlas en un registro compartido. Block, por ejemplo, construyó un mercado interno de habilidades con más de 100, con paquetes específicos para roles y equipos, con pull requests, revisiones y control de versiones, igual que el código.

Una tendencia interesante es que los LLM usan cada vez más herramientas CLI en lugar de MCP (y muchas empresas lanzan sus propias versiones: Google Workspace CLI, próximo de Braintrust). La razón principal es la eficiencia en tokens: el MCP inyecta toda la definición de herramientas en cada ronda, aunque no se usen todas. La CLI, en cambio, ejecuta comandos específicos, y solo la salida relevante entra en el contexto. Uso mucho agent-browser en lugar de Playwright MCP por esta razón.

Antes de seguir, recordemos: los niveles 3 a 5 son la base para todo lo que viene. Los LLM son sorprendentemente buenos en algunas tareas y muy deficientes en otras. Necesitas desarrollar una intuición sobre estos límites para poder agregar más automatización. Si tu contexto es ruidoso, tus prompts son imprecisos o las descripciones de herramientas son vagas, los niveles 6 a 8 solo amplificarán esos problemas.

Nivel 6: Ingeniería de harness

Aquí empieza la verdadera aceleración.

Mientras la ingeniería de contexto se enfoca en qué ve el modelo, la ingeniería de harness (Harness Engineering) se ocupa de construir todo el entorno: herramientas, infraestructura y ciclos de retroalimentación, para que los agentes puedan trabajar de forma confiable sin intervención humana. No solo un editor, sino un ciclo completo de feedback.

El sistema de herramientas Codex de OpenAI, por ejemplo, integra DevTools, sistemas de observabilidad y navegación en el runtime del agente, permitiéndole hacer capturas de pantalla, controlar UI, consultar logs y verificar sus propias correcciones (Fuente: OpenAI).

Mi equipo desarrolló converse, una CLI que permite a cualquier LLM interactuar con nuestro backend en diálogos iterativos. Tras modificar código, el LLM puede probar en línea, iterar, y en ocasiones, realizar ciclos de auto-mejora que duran horas. Cuando los resultados son verificables, esto es especialmente potente: el diálogo sigue un flujo, o llama a herramientas específicas en casos particulares (como transferir a atención humana).

El concepto clave aquí es el backpressure — mecanismos automáticos de retroalimentación (sistemas de tipos, tests, linters, hooks pre-commit) que permiten detectar y corregir errores sin intervención humana. Para tener autonomía, necesitas estos mecanismos; sin ellos, solo obtienes una máquina de producción basura. También en seguridad: los agentes, sus códigos y tus claves deben estar en dominios de confianza separados, porque un ataque de inyección en logs puede hacer que el agente robe tus credenciales. La frontera de seguridad es el backpressure: limita lo que el agente puede hacer si se sale de control.

Dos principios que clarifican esto:

• Diseñar para throughput, no para perfección. Exigir perfección en cada envío genera que el agente se quede atrapado en bugs, cubriéndose unos a otros. Mejor tolerar errores menores y hacer una revisión final antes del despliegue. Lo mismo con colegas humanos.

• La restricción es mejor que instrucciones. Dar instrucciones paso a paso (“haz A, luego B, después C”) está en desuso. En mi experiencia, definir límites claros es más efectivo que listas de tareas, porque el agente se obsesiona con ellas y ignora lo que está fuera. La mejor estrategia es decir “quiero este resultado, y sigue haciendo hasta que pase todas las pruebas”.

Otra parte de harness engineering es garantizar que el agente pueda navegar en el repositorio sin tu ayuda. OpenAI mantiene los archivos AGENTS.md en menos de 100 líneas, como índice a otros documentos estructurados, y la vigencia de estos documentos se integra en CI, en lugar de depender de actualizaciones temporales.

Una vez que tienes todo esto en marcha, surge la pregunta: si el agente puede verificar su trabajo, navegar en el repositorio y corregirse solo, ¿por qué seguir sentado allí?

Un aviso: para quienes aún están en niveles anteriores, lo que sigue puede parecer ciencia ficción (pero guárdalo, y vuelve a leerlo después).

Nivel 7: Agentes en segundo plano

Crítica: el modo plan está desapareciendo.

Boris Cherny, creador de Claude Code, dice que el 80% de sus tareas aún comienzan con un modo plan. Pero con cada nueva generación de modelos, la tasa de éxito tras un solo plan aumenta. Creo que estamos cerca de un punto crítico: el modo plan, como paso de intervención humana, irá desapareciendo. No porque no sea importante, sino porque los modelos ya son lo suficientemente inteligentes para planear por sí mismos. Pero esto solo funciona si has hecho bien los niveles 3 a 6: contexto limpio, reglas claras, descripciones completas, ciclos cerrados. Si no, seguirás necesitando supervisión.

El plan como práctica general no desaparecerá, solo cambiará de forma. Para novatos, sigue siendo la entrada correcta (niveles 1 y 2). Pero para funciones complejas en nivel 7, “planear” ya no significa hacer un esquema paso a paso, sino explorar: revisar código, hacer prototipos en worktree, entender el espacio de soluciones. Y cada vez más, esa exploración la hacen agentes en segundo plano.

Esto es clave, porque desbloquea los agentes en segundo plano. Si un agente puede generar un plan confiable y ejecutarlo sin tu firma, puede trabajar en paralelo mientras tú haces otras cosas. Es un cambio fundamental: de “yo cambio entre varias pestañas” a “hay trabajo avanzando sin mí”.

El ciclo Ralph es un ejemplo popular: un ciclo autónomo que ejecuta repetidamente CLI de programación hasta completar todos los ítems del PRD, creando instancias con contexto nuevo en cada iteración. En mi experiencia, hacer que funcione bien requiere que las descripciones sean precisas; cualquier error en el PRD puede arruinarlo. Es un poco “lo lanzas y ya”.

Puedes correr múltiples ciclos Ralph en paralelo, pero cuantos más inicies, más tiempo gastarás en coordinar, ordenar tareas, revisar salidas y avanzar. Ya no programas, ahora eres un gestor intermedio. Necesitas un orquestador para gestionar la programación, para centrarte en la intención, no en la logística.

Dispatch, por ejemplo, lanza en paralelo 5 workers en 3 modelos diferentes, manteniendo tu sesión limpia y los agentes trabajando en aislamiento.

Recientemente uso mucho Dispatch, una skill que desarrollé para Claude Code, que convierte tu sesión en un centro de mando. Tú permaneces en un chat limpio, y los workers en contextos aislados hacen el trabajo pesado. El scheduler planifica, delega y hace seguimiento, reservando tu ventana principal para coordinar. Cuando un worker se atasca, lanza preguntas de clarificación en lugar de fallar silenciosamente.

Dispatch corre localmente, ideal para desarrollo rápido y feedback instantáneo, sin infraestructura adicional. Ramp Inspect, en cambio, es para trabajos más largos y autónomos: cada sesión en la nube en un sandbox VM con entorno completo. Si un PM detecta un bug UI, lo marca en Slack, y Inspect se encarga de resolverlo cuando cierras el portátil. La desventaja es la complejidad operativa (infraestructura, snapshots, seguridad), pero obtienes escala y reproducibilidad que un agente local no puede igualar. Recomiendo usar ambos: local y en la nube.

En este nivel, una estrategia poderosa es usar diferentes modelos para tareas distintas. Los mejores equipos no son clones, sino que tienen perfiles diversos, con diferentes fortalezas y entrenamientos. Lo mismo con los modelos: tras diferentes entrenamientos, algunos como Opus se especializan en implementación, Gemini en exploración, Codex en revisión. Es como un grupo de expertos colaborando, pero en código.

Y muy importante: desacoplar los agentes que implementan y los que revisan. Si un mismo modelo hace ambas cosas, puede tener sesgos y autocomplacencia, diciendo que todo está bien cuando no es así. Mejor usar un modelo para implementar y otro, con prompts de revisión, para evaluar. La calidad de la señal mejora mucho.

Los agentes en segundo plano también abren la puerta a CI y AI integrados. Cuando los agentes pueden correr sin supervisión, pueden activarse desde infraestructura existente. Un bot de documentación, por ejemplo, actualiza automáticamente la documentación tras cada merge, enviando PRs. Otro revisa PRs en busca de problemas de seguridad y los corrige. Otro gestiona dependencias, actualizando paquetes y corriendo tests. Todo esto, con reglas, herramientas y ciclos de retroalimentación automáticos, funciona de forma autónoma.

Nivel 8: Equipos de agentes autónomos

Nadie domina todavía este nivel, aunque algunos avanzan hacia él. Es la frontera actual.

En nivel 7, tienes un orquestador que distribuye tareas a agentes en diferentes instancias. En nivel 8, los agentes se coordinan entre sí, sin intermediarios: asumen tareas, comparten descubrimientos, gestionan dependencias y resuelven conflictos, todo en un ecosistema descentralizado.

El experimento de Claude Code con Agent Teams, donde múltiples instancias trabajan en paralelo en un repositorio compartido, es un ejemplo temprano. Anthropic construyó un compilador de Linux en C con 16 agentes en paralelo, y Cursor creó un navegador completo en semanas, migrando su código de Solid a React, con cientos de agentes en acción.

Pero hay problemas. Sin una estructura jerárquica, los agentes se vuelven indecisos y no avanzan. Los intentos de coordinación múltiple aún enfrentan dificultades, y nadie ha encontrado una solución definitiva. La mayoría de los proyectos aún no están listos para esa autonomía total, ya que son lentos, costosos en tokens y poco rentables fuera de casos muy específicos. Para la mayoría, el nivel 7 sigue siendo el máximo realista. Es probable que el nivel 8 se vuelva la norma en el futuro, pero por ahora, enfócate en el nivel 7 (a menos que seas Cursor, cuyo negocio es precisamente esa innovación).

Nivel ? : ¿Qué sigue?

La inevitable pregunta “¿y qué sigue?”

Una vez que domines la coordinación de equipos de agentes sin fricciones, la interfaz no tiene por qué limitarse al texto. La interacción por voz a voz (¿pensamiento a pensamiento?) y los agentes de programación — diálogos con Claude Code, no solo voz a texto — son la próxima etapa natural. Imagina describir en voz alta los cambios que quieres y ver cómo se materializan frente a ti.

Hay quienes persiguen una generación perfecta y única: decir qué quieren y que la IA lo produzca en una sola pasada. Pero eso asume que sabemos exactamente qué queremos. Y no es así. Nunca lo sabemos del todo. El desarrollo de software siempre es iterativo, y siempre lo será. Solo que será mucho más fácil, mucho más rápido y mucho más allá del simple texto.

Entonces, ¿en qué nivel estás? ¿Qué haces para avanzar al siguiente?