Anthropic, OpenAI y Cursor: los ocho niveles de madurez de la ingeniería agéntica

Habr AI ha publicado la traducción de un artículo sobre los ocho niveles de la ingeniería agéntica, una práctica que convierte a un LLM de asistente de autocompletado en un equipo de desarrolladores casi autónomo. La idea principal del texto: un salto en la calidad de los modelos no garantiza por sí solo un aumento de la productividad si el equipo no ha construido contexto, reglas, herramientas y retroalimentación.

De las sugerencias a los agentes

El autor considera ya habituales los dos primeros niveles: tab complete y agent IDE. En esta etapa la IA acelera tareas locales: completa fragmentos de código, ayuda con ediciones en varios archivos y elabora un plan a partir de una idea. Pero el verdadero punto de inflexión llega en el tercer nivel, donde el context engineering pasa al centro. Ya no se trata de un prompt ingenioso, sino de disciplina: qué archivos, reglas y descripciones de herramientas recibe el modelo, qué hay en el historial de la sesión y cuánto ruido innecesario consume la ventana de contexto. Cuanta menos basura, más estable el resultado.

«Cada token debe ganarse su lugar en el prompt».

El cuarto nivel es el compounding engineering: el equipo no solo usa el modelo, sino que convierte los hallazgos útiles en un sistema. Si el agente se equivoca, las conclusiones se registran en archivos de reglas, documentación y patrones de trabajo para que la siguiente sesión no repita los mismos fallos.

El quinto nivel añade herramientas de acción: MCP, skills, acceso a API, bases de datos, CI y navegador. A partir de aquí el LLM deja de ser solo un interlocutor sobre código y empieza a modificar de verdad la base de código, a probarla y a participar en las revisiones.

Dónde crece el rendimiento

El autor considera el sexto nivel el punto en que la programación con IA se vuelve realmente productiva. Aquí importa no solo el contexto, sino todo el entorno que rodea al agente: pruebas, linters, tipado, registros, verificaciones en el navegador y otros feedback loops. Gracias a ellos el modelo no se limita a generar un parche: puede detectar un error, comprobarse a sí mismo y hacer otra iteración sin intervención humana.

El artículo lo llama harness engineering: diseñar un entorno de ejecución en el que el agente pueda ver las consecuencias de sus propios cambios y chocar con restricciones concretas, no con instrucciones vagas.

• archivos de reglas y documentación que fijan el contexto
• herramientas CLI o MCP para acceder a datos, pruebas e interfaz
• backpressure automático: tipos, linters, hooks, CI
• separación de roles entre ejecutor y revisor, para que el agente no se revise a sí mismo

De ahí surge el séptimo nivel: los agentes en segundo plano. Si el modelo sabe trazar un plan, orientarse en el repositorio y validar el resultado por sí mismo, ya no hace falta mantenerlo en una pestaña interactiva. El agente puede trabajar de forma asíncrona: explorar la base de código, escribir una función, ejecutar las comprobaciones, abrir un PR y volver solo con preguntas o con el resultado. Para el equipo esto cambia la forma misma de trabajar: el desarrollador malabarea menos tareas a mano y actúa cada vez más como orquestador que define la intención, las restricciones y las prioridades.

Hacia dónde va el mercado

Lo que viene después parece, por ahora, más la vanguardia que la práctica cotidiana. El octavo nivel son los equipos de agentes autónomos, donde varios LLM se coordinan directamente entre sí y no a través de un único operador central. El texto cita ejemplos de Anthropic y Cursor: se han usado agentes en paralelo para escribir un compilador de C, construir un navegador y ejecutar grandes migraciones en una base de código.

Pero con la escala reaparecen enseguida los viejos problemas del desarrollo: regresiones, conflictos, bloqueos, exceso de cautela y un coste de cómputo creciente. Por eso el autor plantea una conclusión sobria: a la mayoría de los equipos les conviene más llegar a un séptimo nivel maduro que soñar con departamentos de IA totalmente autónomos. Es decir, construir un contexto limpio, acumular reglas, skills de calidad, ciclos de verificación fiables y orquestación en segundo plano. Ahí, en su opinión, está la ganancia práctica más cercana. Y ahí la diferencia entre un equipo de IA sólido y uno débil se hace especialmente visible: unos aceleran sus lanzamientos, otros se ahogan en el caos que ellos mismos automatizaron.

Qué significa

El artículo de Habr AI es útil porque traslada la conversación sobre los «modelos inteligentes» a la de la madurez de la ingeniería. El mercado de la programación con IA no avanza hacia un botón mágico, sino hacia sistemas en los que los modelos reciben el contexto correcto, herramientas operativas y controles de verificación estrictos. Ganarán no quienes simplemente tengan un modelo más nuevo, sino quienes construyan antes una cadena de trabajo funcional a su alrededor.