«ADE» —Agentic Development Environment— aparece en publicaciones de lanzamiento, presentaciones de analistas y mucho contenido SEO, cada uno con una definición ligeramente distinta. La afirmación detrás del término es ambiciosa: que el IDE, una interfaz construida alrededor de archivos y un cursor, está siendo reemplazado por algo construido alrededor de tareas, agentes y revisión.
Fui a investigar si esa afirmación resiste el contraste con las fuentes primarias. La versión corta: el cambio arquitectónico es real y todos los proveedores importantes convergieron en las mismas piezas fundamentales, pero la mayoría rechaza esa terminología y los dos que usan «ADE» ni siquiera coinciden en qué significa la A. Eso quiere decir que la pregunta útil para tu equipo no es «¿deberíamos adoptar un ADE?», sino «¿cuáles de estas piezas necesita realmente nuestro repositorio y en qué orden?».
El 12 de agosto de 2026 revisé fuentes primarias de los proveedores (blogs oficiales, registros de cambios, documentación de productos y metadatos de repositorios), además de tres conjuntos de datos de investigaciones independientes. Las afirmaciones sobre productos que aparecen a continuación tienen fecha. Todo lo que es mi interpretación y no un dato respaldado por una fuente está señalado como criterio editorial.
Transparencia: escribí este artículo dentro de Orca, uno de los productos que se analizan a continuación. He intentado tratarlo con el mismo escepticismo que a los demás, y todo lo que afirmo sobre él se puede verificar en su documentación y repositorio públicos.
Audiencia: ingenieros y arquitectos que deciden qué parte de esta categoría adoptar y en qué secuencia.
TL;DR
- Dos proveedores usan el acrónimo y no coinciden en lo que significa. Warp dice «Agentic Development Environment» (junio de 2025); Orca dice «Agent Development Environment». Cursor, Google, GitHub, AWS Kiro y Factory inventaron terminología diferente.
- Aun así, convergieron en cinco piezas fundamentales, entre junio de 2025 y febrero de 2026: un plano de control para la orquestación, entornos de ejecución paralelos y aislados, puntos de aprobación entre especificación y ejecución, revisión de artefactos y una capa de permisos y auditoría.
- Algunos productos de la categoría no venden un modelo. Orca tiene licencia MIT y es neutral respecto al harness: tú aportas tu propio CLI de agente y tu propia suscripción, así que todo su producto es la capa de orquestación. Esa es una afirmación que hace su arquitectura, no su publicidad (criterio editorial).
- Todo un nivel rechaza ese enfoque. herdr («el runtime donde viven tus agentes de código», 28k estrellas) y cmux («la terminal creada para hacer varias tareas a la vez», 26k estrellas) implementan bien una pieza y siguen siendo explícitamente terminales. Para la mayoría de los equipos, ese nivel es la primera adquisición adecuada (criterio editorial).
- La convergencia real que nadie promociona: herdr, cmux y Orca exponen una API que el propio agente llama, con un límite de seguridad. El humano ya no es el único usuario de la interfaz, lo cual define la categoría mejor que cualquier descripción en los sitios de los proveedores.
- De ahí salieron dos estándares independientes de proveedores:
AGENTS.md(ahora bajo la Agentic AI Foundation de la Linux Foundation) y Agent Client Protocol de Zed. Un simple cambio de marca no produce estándares de interoperabilidad (criterio editorial). - La evidencia sobre los beneficios es realmente contradictoria y cada vez más difícil de medir. METR midió que desarrolladores experimentados de OSS eran 19% más lentos a principios de 2025, aunque creían ser 20% más rápidos. Luego, el 24 de febrero de 2026, abandonó ese diseño de estudio porque demasiados desarrolladores ahora se niegan a trabajar sin IA. DORA 2025 encontró que la IA amplifica las capacidades existentes y sigue correlacionada negativamente con la estabilidad de las entregas.
- La mayoría de los desarrolladores aún no está ahí. En la encuesta de Stack Overflow de 2025, 52% no usa agentes o solo usa herramientas de IA más sencillas, y 38% no tiene planes de adoptarlos.
- Las características que definen la categoría amplían el alcance de los incidentes de seguridad. Una semana después del lanzamiento de Google Antigravity, investigadores demostraron la exfiltración de credenciales mediante inyección indirecta de prompt a través de un subagente de navegador incluido en la lista de permitidos predeterminada.
Qué aprenderás aquí
- Quién usa realmente el término «ADE» y a quién se le aplica la etiqueta, con una tabla de verificación
- Las cinco piezas fundamentales que definen la categoría, cada una vinculada a una fuente primaria con fecha
- Los tres niveles —multiplexor, orquestador y plataforma— y cuál debería adquirir primero tu equipo
- En qué consiste realmente el cambio de UX, más allá del marketing: revisor y orquestador en lugar de autor
- La evidencia en contra de METR, DORA y Stack Overflow, sin tomar partido por ti
- Una lista de prerrequisitos para adoptar las piezas en un orden que funcione en tu repositorio
- Los modos de falla, basados en vulnerabilidades divulgadas y no en hipótesis
1. ¿Quién dice realmente «ADE»?
Esto es lo primero que vale la pena comprobar, porque casi todas las explicaciones sobre el tema lo omiten.
| Proveedor | Cómo se describen | Fecha | ¿Dice «ADE»? |
|---|---|---|---|
| Warp | «el primer Agentic Development Environment» | junio de 2025 | Sí |
| Orca (Stably) | «el Agent Development Environment (ADE) más potente» | repositorio creado el 17 de marzo de 2026 | Sí |
| Cursor | una Agents Window «centrada en los agentes, sin perder la profundidad de un entorno de desarrollo» | 3.0: 2 de abril de 2026 | No |
| Google Antigravity | «plataforma de desarrollo agéntico» | 18 de noviembre de 2025 | No |
| GitHub | «Agent HQ» / «centro de control» | 28 de octubre de 2025 | No |
| AWS Kiro | «un IDE con IA» que realiza «desarrollo basado en especificaciones» | julio de 2025 | No |
| Factory | «Desarrollo de software Agent-Native» | a agosto de 2026 | No |
| herdr | «el runtime donde viven tus agentes de código» | repositorio creado el 27 de marzo de 2026 | No |
| cmux | «la terminal creada para hacer varias tareas a la vez» | repositorio creado el 28 de enero de 2026 | No |
Dos proveedores usan la expresión y desarrollan el acrónimo de forma distinta: el Agentic de Warp describe el carácter del entorno; el Agent de Orca describe para quién es el entorno. Orca es explícito sobre la segunda interpretación: «Los IDE se crearon para ti. Un ADE se crea para ti y tus agentes». Todos los demás inventaron su propia terminología.
La mayoría del contenido que circula para definir el término no proviene de ninguno de estos proveedores. Proviene de explicaciones de terceros y guías SEO de competidores: sirve como evidencia de que se está promocionando el término, no como una definición que debamos adoptar.
Criterio editorial: la divergencia importa más que las coincidencias. Cuando una categoría está realmente consolidada, los competidores convergen en la terminología porque los compradores necesitan poder comparar. Aquí convergieron en la arquitectura y se fragmentaron en los nombres, lo que sugiere ingeniería real bajo una marca en disputa. Un acrónimo cuyos propios usuarios no se ponen de acuerdo sobre su significado todavía no es una categoría; es una apuesta por crearla.
2. Las cinco piezas fundamentales en las que realmente convergieron
Si quitamos los nombres, aparecen las mismas cinco cosas en cada uno de estos productos.
Intent issue / prompt / spec (requirements, design, tasks)
|
Control plane orchestrator: task lifecycle, dependencies, gates, triggers
(Warp Oz | Agent HQ | Cursor Agents Window | Orca Runs)
|
+-------------+-------------+-------------+--------------+
Runtime | agent 1 | agent 2 | agent 3 | subagent fan-out
Isolation| worktree | container | cloud VM | remote SSH
|
Tooling MCP servers | shell | browser | tests | CI
Guardrails allow/deny lists, approval gates, branch restrictions,
network egress allowlists
|
Review surface diffs | artifacts (plans, screenshots, recordings) | PRs
Observability per-run link, transcript, audit trail, metrics
|
Human reviewer / orchestrator — steer, comment, take over locally
2.1 Un plano de control que no es el editor
Cursor 2.0 (29 de octubre de 2025) incorporó paralelismo entre múltiples agentes: hasta ocho agentes a la vez, aislados mediante worktrees de git o máquinas remotas. Cursor 3.0 (2 de abril de 2026) hizo explícita la separación: una Agents Window «centrada en los agentes, sin perder la profundidad de un entorno de desarrollo», que ejecuta agentes localmente, en worktrees, en la nube y por SSH remoto, y eliminó por completo los agentes en la nube del Editor.
Google Antigravity (18 de noviembre de 2025) lanzó una interfaz Editor y una interfaz Manager, y describió el cambio como invertir «el paradigma de agentes integrados en interfaces por uno en el que las interfaces están integradas en el agente».
Agent HQ de GitHub (28 de octubre de 2025) es un centro de control disponible en la web, VS Code, dispositivos móviles y CLI, con agentes de terceros de Anthropic, OpenAI, Google, Cognition y xAI. Los agentes se ejecutan en los recursos de cómputo que elijas —GitHub Actions o runners autoalojados—, con «nuevos controles de ramas que te dan supervisión granular sobre cuándo ejecutar CI y otras verificaciones para el código creado por agentes».
Oz de Warp (10 de febrero de 2026) es el plano de control más explícito del grupo: CLI, API y SDK; entornos Docker; un programador de tareas integrado; autoalojamiento; y soporte para «patrones de orquestación arbitrarios», como topologías con un líder y compañeros de equipo. Vale la pena señalar que Warp argumentó en contra de los agentes en la nube en su publicación sobre ADE de junio de 2025 («los agentes basados en la nube sacan al humano del proceso demasiado pronto») y luego lanzó exactamente eso ocho meses después.
La capa de orquestación de Orca es la que tiene la especificación más formal de las que leí, y vale la pena describirla con precisión porque muestra qué significa «plano de control» cuando deja de ser un término de marketing. Modela un Run (un espacio de nombres persistente y una bandeja de entrada para el coordinador), Tasks con dependencias y una verdadera máquina de estados (pending, ready, dispatched, completed, failed, blocked), Dispatches (un intento de ejecutar una tarea en una terminal, con autoridad sobre su ciclo de vida), Messages tipados (worker_done, escalation, question, heartbeat) y puntos de decisión que bloquean una tarea hasta que un coordinador la resuelve.
Su documentación también aclara que un Run «nunca programa ni asigna workers»: la asignación y la concurrencia quedan a cargo del agente que lo invoca. Criterio editorial: eso es un sustrato de coordinación, no un piloto automático, y es el mismo límite que establece GitHub al dejarte elegir los recursos de cómputo. Vale la pena destacar ambos casos porque el marketing de esta categoría suele sugerir lo contrario.
Si te interesan los patrones de orquestación en sí y no la terminología de un proveedor, este repositorio los cubre en cómo construir un agente de nivel sénior que orqueste subagentes y cuándo usar subagentes en lugar del hilo principal de chat.
2.2 Entornos de ejecución paralelos y aislados
Worktrees, contenedores, máquinas virtuales en la nube, SSH remoto. Cursor aísla los agentes paralelos con worktrees de git o máquinas remotas; Oz de Warp usa entornos Docker; Agent HQ ejecuta agentes en GitHub Actions o runners autoalojados con controles de ramas para el código creado por agentes.
Orca es el caso más claro en el que esta pieza es esencial y no opcional: se describe como «worktree-native», donde cada tarea tiene su propia copia de trabajo en disco y su propia rama, y cada worktree delimita sus propias terminales de agentes, pestañas del editor y pestañas del navegador. Su documentación es directa sobre el motivo: «esto es lo que hace seguros a los agentes paralelos: nunca pisan los archivos de los demás».
El detalle que la mayoría de los equipos subestima es lo que falta en una copia de trabajo limpia. Orca lo resuelve con tres mecanismos que vale la pena adoptar como concepto aunque nunca uses Orca: rutas compartidas que se crean a partir de la copia de trabajo principal (mediante clonación de APFS cuando es posible; de lo contrario, con un enlace simbólico), un archivo orca.yaml versionado en el repositorio que enumera los directorios ignorados por git que se deben compartir y un archivo .worktreeinclude que enumera los archivos ignorados por git que se deben copiar para que cada worktree tenga los suyos.
# orca.yaml — shared, rebuildable, symlinked
worktree:
sharedDirectories:
- node_modules
- .cache
# .worktreeinclude — copied, so each worktree owns its own
.env
.env.local
.vscode/settings.json
La distinción entre ambos archivos es la clave del diseño: comparte lo que es grande y se puede reconstruir; copia lo que es pequeño y mantiene estado específico de cada worktree. Crear un enlace simbólico a .env en diez worktrees significa que la edición de un agente cambia silenciosamente los otros nueve.
Ese patrón es portable y no necesitas ninguno de los productos de este artículo para usarlo. Lo mismo con git puro:
#!/usr/bin/env bash
# new-agent-worktree.sh <branch>
set -euo pipefail
branch="$1"
root="$(git rev-parse --show-toplevel)"
dir="../$(basename "$root")-$branch"
git worktree add -b "$branch" "$dir" origin/main
# share: large, rebuildable, safe to alias
ln -s "$root/node_modules" "$dir/node_modules"
# copy: small, stateful, must not be shared
cp "$root/.env" "$dir/.env"
Quince líneas de shell te dan la pieza de aislamiento. Los productos de este artículo añaden gestión del ciclo de vida, una interfaz y un plano de control encima, algo por lo que vale la pena pagar con diez worktrees y probablemente no con dos (criterio editorial).
Si te interesan los mecanismos y no el argumento sobre la categoría, este repositorio ya los cubre en profundidad en carpetas de funcionalidades para múltiples repositorios con worktrees de git y cómo ejecutar espacios de trabajo agénticos en la nube a escala.
2.3 Especificar y luego ejecutar con puntos de aprobación
AWS Kiro, lanzado en julio de 2025, genera tres artefactos: requirements.md con criterios de aceptación en notación EARS («Easy Approach to Requirements Syntax»), design.md con diagramas de arquitectura y de secuencia, y tasks.md con trabajo ordenado según sus dependencias, con puntos de aprobación entre fases. Su documentación al 4 de agosto de 2026 también describe un modo «Quick Spec» que omite esos puntos de aprobación. GitHub lanzó el modo de planificación en VS Code junto con Agent HQ; Warp lanzó el modo de planificación en 2.0.
De nuevo, los mecanismos ya están cubiertos aquí: reemplazar el modo de planificación con OpenSpec y primeros pasos con GitHub Spec Kit.
2.4 Revisión a nivel de artefacto
Este es el cambio del que menos se habla y, creo, el de mayores consecuencias (criterio editorial). La unidad de revisión de Antigravity es un Artifact —una lista de tareas, un plan, una captura de pantalla, una grabación del navegador—, no un diff. Comentas el artefacto y el agente hace ajustes sin detenerse. Vale la pena citar el razonamiento declarado por Google porque es la explicación más clara del problema que esta pieza busca resolver: «Que un agente pueda completar el 80% del trabajo debería ser útil, pero si no hay una forma sencilla de darle retroalimentación, resolver el 20% restante termina dando más trabajo que beneficio». Oz de Warp hace la misma apuesta desde el otro lado, con una transferencia del agente al humano para que puedas continuar el trabajo localmente.
Orca mantiene el diff como unidad de revisión, pero cierra el ciclo de otra manera: dejas comentarios en Markdown en líneas individuales del diff, los agrupas y devuelves el lote al agente. Además, documenta un ciclo de vida del worktree de crear, trabajar, revisar, entregar y archivar, con creación de PR y verificaciones de CI integradas. También muestra la atribución de autoría en el diff, algo importante cuando ya no recuerdas cuál de los cinco agentes escribió un bloque determinado.
Criterio editorial: estas son dos apuestas realmente distintas. La revisión de artefactos escala mejor y detecta errores de intención; la revisión línea por línea con comentarios agrupados detecta errores de implementación y mantiene a una persona leyendo el código real. La segunda es más lenta y, dadas las conclusiones de seguridad de la sección 7, probablemente sea más segura hoy.
En cualquier caso, quien revisa ya no es el autor. Está leyendo el trabajo de otra persona, en volumen, lo cual es una habilidad distinta que este repositorio ha cubierto en cómo construir un buen revisor agéntico de código.
2.5 Permisos, auditoría y costo
Listas de comandos de shell y servidores MCP permitidos o denegados, restricciones de ramas, listas de destinos de salida de red permitidos, enlaces compartibles por ejecución con transcripciones completas, registros de auditoría y paneles de métricas. Oz cobra tanto por el uso de IA como por el de cómputo, lo que convierte el gasto en agentes en un problema de observabilidad para el que la mayoría de los equipos no tiene hábitos previos (criterio editorial).
La única pregunta arquitectónica dentro de esta pieza que realmente determina tu riesgo es quién escribe la lista de permitidos y si la configuración predeterminada permite o deniega. Una lista de permitidos incluida por defecto es un límite de seguridad elegido por un proveedor que nunca ha visto tu repositorio. La sección 7 muestra qué ocurre cuando eso sale mal: el dominio de exfiltración en las divulgaciones sobre Antigravity no eludió la lista de permitidos; estaba en ella. Si no adoptas nada más de esta sección, adopta una política de denegación por defecto con una lista de destinos de salida que tu equipo controle y revise.
Para conocer el aspecto organizacional de esto —quién es responsable de los límites y cómo se hacen cumplir—, consulta gobernanza de arquitectura para la generación de código con IA.
3. La postura contraria: multiplexores, no entornos
Todo lo anterior describe productos que reúnen las cinco piezas en una sola interfaz. Hay un segundo movimiento, más discreto, que hace lo contrario: toma una pieza, la implementa bien y rechaza explícitamente presentarse como un «entorno». Merece su propia sección porque es el argumento práctico más sólido a favor de adquirir piezas en lugar de categorías.
herdr se llama a sí mismo «el runtime donde viven tus agentes de código». Es un solo binario de Rust, con licencia Apache-2.0 y 28,163 estrellas en GitHub de un repositorio creado el 27 de marzo de 2026. Es un multiplexor de terminal de la familia de tmux, con dos adiciones importantes:
- Estado semántico de los agentes. Detecta 19 CLI de agentes sin configuración adicional y marca cada panel como
working,blockedoidle, con estados agregados por pestaña y espacio de trabajo, para que no tengas que abrir paneles para averiguar quién está atascado. - Un servidor que controla los paneles. Cierra la laptop, pierde la conexión o reinicia: los agentes siguen trabajando y las sesiones se recuperan, localmente o por SSH.
Su posicionamiento rechaza directamente el paquete integrado: «herdr no los envuelve ni los reemplaza; solo controla sus terminales».
cmux es una terminal nativa de macOS construida sobre libghostty —Swift y AppKit, sin Electron—, con 25,974 estrellas de un repositorio creado el 28 de enero de 2026. Sus adiciones incluyen pestañas verticales que muestran la rama, el directorio y los puertos; indicadores de notificación que se activan cuando un panel necesita atención mediante las secuencias de escape estándar OSC 9/99/777; un navegador integrado controlable mediante scripts; restauración de sesiones que sobrevive a un reinicio; y una API de socket. Mitchell Hashimoto, creador de Ghostty, lo describió como dirigido a «personas que usan muchísimos flujos de trabajo agénticos basados en terminal». Su propia sección de preguntas frecuentes es directa sobre el alcance: «cmux es una terminal, así que cualquier agente que se ejecute en una terminal funciona sin configuración adicional».
Una aclaración sobre nombres que refuerza el argumento: hay dos proyectos llamados cmux. El de Coder, presentado en Hacker News en octubre de 2025 como «Cmux — Coding Agent Multiplexer», desde entonces fue renombrado a coder/mux («una aplicación de escritorio para desarrollo agéntico paralelo y aislado», AGPL-3.0, TypeScript). Si buscas cmux encontrarás ambos. Una categoría cuyos productos siguen teniendo conflictos de nombres es una categoría que todavía se está formando.
Lo que demuestra el nivel mínimo
Observa lo que estos dos no tienen: ningún ciclo de vida de worktrees, artefactos de especificación, puntos de aprobación de planes, interfaz de revisión de diffs ni política de merge. Implementan las filas de runtime y observabilidad del diagrama de la sección 2 y nada más.
Y aun así convergen con el nivel más completo en una pieza concreta: agentes que controlan el propio entorno mediante una interfaz de control documentada. herdr incluye un archivo de skill para agentes que solo se activa cuando se establece HERDR_ENV=1, con una medida de protección explícita: si la variable no existe, el agente debe detenerse e indicar que no se está ejecutando dentro de un panel gestionado por herdr. Orca ofrece algo de la misma forma como una skill instalable sobre su CLI. cmux expone todas las acciones mediante un socket Unix y publica una colección de skills.
Criterio editorial: esta es la convergencia más interesante de toda la categoría y nadie la promociona. Tres productos con alcances completamente distintos concluyeron de forma independiente que el entorno necesita una API que el propio agente llama: el humano no es el único usuario de la interfaz. Es una idea realmente nueva en las herramientas para desarrolladores y una mejor definición de «entorno de desarrollo agéntico» que cualquier descripción en los sitios de los proveedores. Si quieres una sola prueba para saber si una herramienta pertenece a esta categoría, usa esta: ¿puede un agente operar esta herramienta como usuario de primera clase, con un límite de seguridad que le impida operar una sesión que no le pertenece?
| Nivel | Ejemplos | Qué obtienes | Cuándo adoptarlo |
|---|---|---|---|
| Multiplexor | herdr, cmux | aislamiento por panel, estado de los agentes, persistencia, API de socket | ya tienes disciplina de revisión y CI, pero no puedes ver qué hacen tus agentes |
| Orquestador | Orca, coder/mux, Warp Oz | ciclo de vida de worktrees, despacho, interfaz de revisión, auditoría | ejecutas agentes en paralelo y pierdes el seguimiento de sus resultados |
| Plataforma | Agent HQ, Antigravity, Cursor | lo anterior más identidad, políticas, cómputo en la nube y controles organizacionales | necesitas gobernanza entre equipos, no solo entre tareas |
Criterio editorial: a la mayoría de los equipos que preguntan «¿deberíamos adoptar un ADE?» les convendría más usar la primera fila durante un trimestre. Es reversible, no cuesta nada y te dice si tu verdadero cuello de botella es la visibilidad, el aislamiento o la revisión, lo cual determina si la complejidad de las filas inferiores vale la pena.
4. El argumento más sólido de que esto es real: interoperabilidad
Las categorías de marketing normalmente no producen estándares independientes de proveedores. Esta produjo dos.
AGENTS.md es un archivo de instrucciones en Markdown plano para agentes de código, originado entre OpenAI, Amp de Sourcegraph, Google Jules, Cursor y Factory, y ahora gestionado por la Agentic AI Foundation bajo la Linux Foundation. InfoQ reportó más de 20,000 repositorios en agosto de 2025; el propio proyecto anuncia más de 60k ejemplos en GitHub a agosto de 2026. El monorepo de OpenAI contiene 88 archivos anidados: el formato permite delimitar instrucciones por directorio.
ACP (Agent Client Protocol) es el protocolo JSON-RPC 2.0 de Zed sobre stdio, modelado explícitamente a partir del Language Server Protocol, que desacopla el agente de la interfaz en la que se ejecuta. Kiro anuncia compatibilidad con ACP. Así como LSP hizo intercambiables los editores para un lenguaje determinado, ACP intenta hacer intercambiables las interfaces para un agente determinado.
Y luego está el tercer dato, que es el que más complica una interpretación cínica.
Orca tiene licencia MIT y no tiene un agente propio que vender. Incluye más de 25 agentes CLI preconfigurados —Claude Code, Codex, Gemini, Copilot, OpenCode, Cursor CLI, Droid, Kiro, Amp, Goose y otros— y sostiene que cualquier agente CLI se puede integrar. Tú aportas tu propia suscripción y tu propio harness.
Hay que tener cuidado con cuánto peso se le da a eso. Orca es un producto de una empresa (Stably), y un núcleo abierto con licencia MIT es uno de los embudos comerciales más comunes en las herramientas para desarrolladores, así que «código abierto, por lo tanto no es marketing» sería un mal argumento. Su repositorio de GitHub superó las 43,000 estrellas para el 12 de agosto de 2026, a partir de un repositorio creado el 17 de marzo de 2026, pero las estrellas miden atención, no adopción ni retención, y una curva rápida de estrellas es exactamente lo que se espera de una campaña de lanzamiento exitosa.
Criterio editorial, y este es el punto clave: el argumento que se sostiene no es la licencia ni las estrellas. Es la neutralidad respecto al harness. Un producto sin modelo ni agente que incluir en un paquete no tiene nada adicional que venderte, lo que significa que toda su propuesta de valor es la capa de orquestación. Una empresa que apuesta su producto solo a eso afirma que la orquestación es un problema separable y, a diferencia de una publicación de lanzamiento, esa afirmación se puede refutar. Si la capa no fuera real, el producto estaría vacío.
Si juntamos los tres elementos —un formato de archivo adoptado por proveedores competidores, un protocolo de comunicación que desacopla el agente de la interfaz y productos cuyo único valor es la capa en sí—, el patrón es una categoría que busca resolver la portabilidad. Eso no es lo que se espera de una estrategia de cautiverio.
5. El cambio de UX, explicado con honestidad
El IDE optimizaba un ciclo: leer código → editar código → ejecutar código. Sus piezas fundamentales —cursor, árbol de archivos, autocompletado, punto de interrupción— sirven para escribir código.
La interfaz agéntica optimiza otro ciclo: describir la intención → despachar → revisar → hacer merge o corregir el rumbo. Sus piezas fundamentales son una lista de agentes, una transcripción de la ejecución, un diff o artefacto, una solicitud de aprobación y un botón de transferencia.
| Dimensión | IDE + plugin de IA | Interfaz centrada en agentes |
|---|---|---|
| Unidad de trabajo | archivo / edición | tarea / ejecución |
| Rol humano | autor, con asistencia | orquestador y revisor |
| Concurrencia | un contexto de trabajo | N ejecuciones aisladas |
| Unidad de revisión | tu propio diff, mientras escribes | el diff o artefacto de otro, después de que se produce |
| Modo de falla | escribes un bug | apruebas un bug |
| Cuello de botella | escritura y razonamiento | capacidad de revisión |
Esa última fila resume todo el argumento (criterio editorial). La capacidad de generación aumentó considerablemente; la capacidad de revisión no cambió en absoluto. Cada pieza de la sección 2 —especificaciones, artefactos, registros de auditoría, puntos de aprobación de planes— es un intento de abaratar la revisión, porque ahí es donde se pierde la capacidad de entrega. Este repositorio ha defendido la misma idea desde el lado humano en qué trabajo sigue siendo humano.
6. La evidencia en contra, que es considerable
No voy a resolver esto por ti. Esto es lo que dicen los datos independientes. Varios de estos números aparecen en otros artículos de este devlog; lo nuevo aquí es la actualización de febrero de 2026, que cambia cuánto peso se le puede dar al resultado principal.
Ensayo controlado aleatorizado de METR (10 de julio de 2025). Dieciséis desarrolladores experimentados de código abierto, 246 tareas reales en repositorios con un promedio de 23,000 estrellas, usando herramientas de vanguardia de principios de 2025 (principalmente Cursor Pro con Claude 3.5/3.7). Los desarrolladores pronosticaron una mejora de velocidad de 24% y después reportaron una mejora de 20%. La medición mostró que eran 19% más lentos (intervalo de confianza de +2% a +39% en la duración de las tareas). Expertos en ML y economía habían pronosticado mejoras de velocidad de 38–39%.
Seguimiento de METR y por qué importa más que el original (24 de febrero de 2026). METR realizó un segundo estudio a partir de agosto de 2025 con 57 desarrolladores, 143 repositorios y más de 800 tareas, y luego lo publicó bajo el título «Estamos cambiando el diseño de nuestro experimento de productividad de desarrolladores». Los resultados brutos mostraron una mejora de velocidad de 18% para los desarrolladores que regresaron (IC de −38% a +9%) y de 4% para los recién reclutados (IC de −15% a +9%). Ambos intervalos incluyen el cero.
Más importante aún, METR declaró que sus propios datos no eran confiables y está rediseñando el estudio. La razón es el hallazgo más interesante de todo este artículo: cada vez más desarrolladores se niegan a participar en la condición que prohíbe el uso de IA. Entre 30% y 50% le dijo a METR que había dejado fuera tareas específicamente porque no quería hacerlas sin IA. Un participante lo expresó directamente: «Siento que me va a explotar la cabeza si intento hacer demasiadas cosas a la antigua, porque es como intentar cruzar la ciudad caminando cuando ya me había acostumbrado a tomar un Uber». La propia interpretación de METR es que los desarrolladores probablemente trabajan más rápido a principios de 2026 que a principios de 2025, pero que sus datos son «evidencia muy débil» de cuánto más rápido.
Criterio editorial: el resumen honesto no es «la IA te hace más lento» ni «se demostró que la ralentización era falsa». Es que la medición rigurosa se volvió más difícil precisamente porque la adopción se profundizó, y el sector actualmente no tiene una estimación controlada y clara del efecto de las herramientas agénticas. Cualquiera que cite hoy la cifra de 19% sin la actualización de febrero de 2026 —incluido el primer borrador de este artículo— está citando un resultado cuyo diseño sus propios autores ya dejaron atrás.
DORA 2025 (23 de septiembre de 2025, ~5,000 encuestados). La IA es un amplificador de la capacidad organizacional existente, no un sustituto: «La IA no arregla un equipo; amplifica lo que ya existe». La adopción está en 90% y más de 80% percibe mejoras de productividad, pero 30% reporta poca o ninguna confianza en el código generado por IA. La adopción de IA ahora se correlaciona positivamente con la capacidad de entrega, pero sigue correlacionada negativamente con la estabilidad de las entregas. Los beneficios se concentran en arquitecturas con bajo acoplamiento y ciclos de retroalimentación rápidos, no en las lentas y fuertemente acopladas.
Stack Overflow 2025 (más de 49,000 respuestas). 84% usa o planea usar IA, pero la confianza cayó de 43% en 2024 a 33%, y la encuesta señala que «más desarrolladores desconfían activamente de la precisión de las herramientas de IA (46%) que los que confían en ella (33%)». Sobre los agentes específicamente: 52% no usa agentes o solo usa herramientas de IA más sencillas, y 38% no tiene planes de adoptarlos. Entre quienes usan agentes, 69% reporta mejoras de productividad, pero solo 17% reporta una mejor colaboración en equipo.
Si quieres realizar esta medición en tu propio repositorio en lugar de discutir los números de otras personas, de la intuición a las métricas es la versión práctica, y paradojas del trabajo con IA explica por qué las herramientas más rápidas suelen sentirse más pesadas.
Criterio editorial: si juntamos todo, el panorama es que esta categoría se está diseñando para un flujo de trabajo al que la mayoría de los desarrolladores aún no ha llegado. Eso no es necesariamente incorrecto —a veces las herramientas se adelantan a la práctica—, pero debería moderar considerablemente la narrativa de que «el IDE está muerto».
7. Modos de falla basados en divulgaciones reales
Aproximadamente una semana después del lanzamiento de Antigravity el 18 de noviembre de 2025:
- PromptArmor (25 de noviembre de 2025) demostró cómo contenido web envenenado llevaba a Gemini a leer un archivo
.envy exfiltrar credenciales de AWS a través del subagente de navegador hacia un dominio que estaba en la lista de permitidos predeterminada de Antigravity. Documentaron otras tres rutas de exfiltración que no requerían herramientas de navegador. Para ser justos con Google, PromptArmor indica que no realizó una divulgación responsable porque Google ya había señalado que conocía los riesgos de exfiltración de datos. - Johann Rehberger (Embrace The Red) documentó cinco problemas, entre ellos ejecución remota de código mediante inyección que eludía la ejecución automática, invocación de herramientas MCP sin intervención humana y exfiltración mediante el renderizado de imágenes Markdown; varios heredados de productos anteriores y conocidos al menos desde mayo de 2025.
- Adam Swanda reportó a Google el 19 de noviembre de 2025 que la etiqueta
<EPHEMERAL_MESSAGE>del prompt de sistema, que instruye al modelo a seguir instrucciones sin reconocerlas, en realidad refuerza las cargas útiles inyectadas. Google lo clasificó como comportamiento previsto el 20 de noviembre de 2025; él publicó los detalles el 25 de noviembre de 2025.
Criterio editorial, y quiero ser directo al respecto: las características que definen un ADE son las mismas que amplían el alcance de un incidente de inyección de prompt. Los agentes paralelos sin supervisión significan que nadie está mirando en tiempo real. Los subagentes de navegador significan que contenido no confiable entra en el contexto. La revisión a nivel de artefacto significa que una línea maliciosa no tiene que pasar por la lectura de una persona. La promesa de UX y la postura de seguridad están en tensión directa, y ningún proveedor ha resuelto eso todavía.
Lectura relacionada en este repositorio: proceso seguro de generación agéntica de código.
8. Qué hacer realmente: un orden de adopción
Deja de lado la pregunta sobre la categoría. Adopta las piezas en un orden en el que cada una haga segura la siguiente. Esta secuencia es mi síntesis del hallazgo de DORA (los beneficios requieren retroalimentación rápida y bajo acoplamiento) y las piezas de los proveedores descritas arriba: considera el orden como criterio editorial y los elementos como respaldados por fuentes.
Etapa 0 — prerrequisitos. No la omitas.
- Una suite de pruebas lo suficientemente rápida y confiable para que una ejecución en verde de un agente signifique algo
- CI que bloquee el merge por sí solo, sin depender de que una persona recuerde revisarlo
- Un nivel de acoplamiento lo suficientemente bajo para que dos agentes puedan trabajar sin interferirse
- Un
AGENTS.mden la raíz y archivos anidados para cualquier directorio con sus propias reglas; consulta repositorios prompt-first
Cada etapa a continuación tiene una señal para avanzar. Si no puedes afirmar honestamente que se cumple, no has terminado esa etapa.
Etapa 1 — un agente, visible. Un agente, una tarea, revisión completa del diff. Avanza cuando: puedas predecir, antes de despachar, qué tipos de tareas resuelve bien este agente en este repositorio.
Etapa 2 — aislamiento. Worktrees o contenedores, para que una ejecución fallida cueste un rm -rf y no una tarde entera.
Avanza cuando: descartar una mala ejecución no requiera tareas de limpieza en las que tengas que pensar.
Etapa 3 — especificaciones y puntos de aprobación. Planificar y luego ejecutar para todo lo que no sea trivial. Avanza cuando: el punto de aprobación del plan esté detectando malentendidos reales antes de que exista código; si nunca detecta nada, es puro teatro.
Etapa 4 — paralelismo. Solo después de que la Etapa 0 realmente se cumpla. Establece tu límite de WIP según las horas disponibles para revisión, no según cuántas sesiones puedas costear. Avanza cuando: la tasa de merges que nadie leyó de verdad se mantenga estable, sin aumentar.
Etapa 5 — gobernanza. Listas de comandos y MCP permitidos con denegación por defecto, restricciones de ramas, listas de destinos de salida permitidos, enlaces de auditoría por ejecución en el cuerpo de cada PR y un presupuesto de gasto con una alerta. Terminas cuando: puedas responder «qué agente cambió esta línea, con la aprobación de quién y a qué costo» sin preguntarle a nadie.
La prueba honesta en cada etapa: si tu equipo no puede revisar de manera confiable los resultados de la etapa N, la etapa N+1 solo producirá más código sin revisar a mayor velocidad.
9. Entonces, ¿es la evolución de la UX?
Mi respuesta, identificada claramente como una opinión: la arquitectura es una evolución genuina; el nombre es una disputa por apropiarse de la categoría que todavía no termina de resolverse.
Lo que realmente cambió es que la interacción principal del desarrollador pasó de escribir código a despachar y revisar, y ese cambio necesitó nuevas piezas —orquestación, aislamiento, especificaciones, artefactos y auditoría— que un editor con una barra lateral de chat no puede proporcionar. Nueve productos que convergen en las mismas piezas en veinte meses, dos estándares independientes de proveedores y un acuerdo no promocionado de que el entorno necesita una API que el agente pueda llamar no son señales de puro marketing.
Pero el nombre sigue sin estar definido, y el desacuerdo es revelador. El «Agentic Development Environment» de Warp describe un entorno que se comporta de manera agéntica. El «Agent Development Environment» de Orca describe un entorno creado para agentes como usuarios. Eso implica productos distintos: el primero quiere ser inteligente en tu nombre; el segundo quiere ser un buen anfitrión para cualquier agente que traigas.
Esa es la distinción que debes llevar a una evaluación de proveedores, y es más útil que el acrónimo que comparten:
| Pregunta | Paquete integrado | Sustrato |
|---|---|---|
| ¿Quién elige el modelo? | el proveedor | tú |
| ¿Por qué estás pagando? | modelo + interfaz | solo la capa |
| ¿Quién controla las medidas de protección? | valores predeterminados del proveedor | tu configuración, en tu repositorio |
| Modelo de costos | licencias por usuario o créditos del proveedor | tus suscripciones existentes más cómputo |
| Forma de salida | cambiar de herramientas | cambiar el CLI del agente |
| Falla gravemente cuando | el modelo incluido empeora | no tienes una postura sobre la orquestación |
Ninguna de las dos columnas es la respuesta correcta para todos. Los paquetes integrados son más rápidos de adoptar y realmente mejores si no quieres tomar estas decisiones; los sustratos son más baratos de abandonar. Criterio editorial: en una categoría tan joven —donde Warp revirtió su propia postura pública sobre los agentes en la nube en ocho meses y dos productos siguen teniendo un conflicto con el nombre «cmux»—, la libertad de elección vale más que el acabado.
Lo que no se ha demostrado es que algo de esto haga a los equipos más rápidos. El único estudio controlado con una medición clara detectó una ralentización; sus autores abandonaron desde entonces ese diseño de estudio porque los desarrolladores ya no quieren trabajar sin IA; la encuesta más grande muestra que la mayoría de los desarrolladores no ejecuta agentes en absoluto; y el producto más promocionado de la categoría filtró credenciales en su primera semana.
Adopta las piezas, comenzando por el nivel más económico que resuelva tu cuello de botella real. Ten claro si estás adquiriendo un paquete integrado o un sustrato. Desconfía del nombre.
Fuentes
- Presentamos Warp 2.0: el Agentic Development Environment — Warp, junio de 2025
- Presentamos Oz y descripción general de Oz Platform — Warp, 10 de febrero de 2026
- Registro de cambios de Cursor 2.0 — 29 de octubre de 2025
- Registro de cambios de Cursor 3.0 y documentación de Agents Window — 2 de abril de 2026
- Orca — sitio del producto, consultado el 12 de agosto de 2026
- Documentación de worktrees de Orca — modelo worktree-native, rutas compartidas,
orca.yaml,.worktreeinclude - Documentación de orquestación de Orca — Runs, Tasks, Dispatches, Messages, puntos de decisión
- Automatizaciones programadas de Orca y registro de skills y MCP
- stablyai/orca en GitHub — licencia MIT (copyright Lovecast Inc.); repositorio creado el 17 de marzo de 2026; 43,628 estrellas al 12 de agosto de 2026
- herdr y herdrdev/herdr en GitHub — Apache-2.0, Rust; repositorio creado el 27 de marzo de 2026; 28,163 estrellas al 12 de agosto de 2026
- Agentes compatibles con herdr y archivo de skill para agentes de herdr — 19 CLI de agentes detectados; la medida de protección
HERDR_ENV=1 - cmux y manaflow-ai/cmux en GitHub — Swift sobre libghostty; repositorio creado el 28 de enero de 2026; 25,974 estrellas al 12 de agosto de 2026
- coder/mux — AGPL-3.0; antes
coder/cmux, presentado en Hacker News en octubre de 2025 como «Cmux — Coding Agent Multiplexer» - Presentamos Google Antigravity — 18 de noviembre de 2025
- Presentamos Agent HQ — GitHub, 28 de octubre de 2025
- Presentamos Kiro — AWS, julio de 2025, y documentación de especificaciones de Kiro — última actualización el 4 de agosto de 2026
- Factory — «Desarrollo de software Agent-Native», consultado el 12 de agosto de 2026
- AGENTS.md y cobertura de InfoQ sobre la adopción de AGENTS.md — agosto de 2025
- Agent Client Protocol — Zed; JSON-RPC sobre stdio, modelado a partir de LSP
- Medición del impacto de la IA de principios de 2025 en la productividad de desarrolladores experimentados de código abierto — METR, 10 de julio de 2025 (arXiv:2507.09089)
- Estamos cambiando el diseño de nuestro experimento de productividad de desarrolladores — METR, 24 de febrero de 2026 — el seguimiento que reemplaza la interpretación del resultado principal de 2025
- Anuncio del informe DORA 2025 — Google Cloud, 23 de septiembre de 2025
- Encuesta de desarrolladores de Stack Overflow 2025: IA
- Google Antigravity exfiltra datos — PromptArmor, 25 de noviembre de 2025
- La seguridad mantiene a Google Antigravity en tierra — Embrace The Red, noviembre de 2025
- Inyección indirecta de prompt en IDE con IA — Adam Swanda, noviembre de 2025