Los tres modos, tal como los definen los propios fabricantes
| Modo | Descripción oficial |
|---|---|
| Sugerencia en línea | «Sugerencias de código mientras escribes» |
| Chat | «Respuestas, exploración de la base de código, pensar el enfoque» |
| Inline chat | «Ediciones acotadas en el editor o en la terminal» |
| Agent | «Implementar o verificar un cambio de varios pasos en varios ficheros» |
| Modo plan | «Explorar un cambio complejo y revisar el enfoque antes de implementarlo» |
En la tabla hay cinco etiquetas, pero detrás hay tres modos: se emparejan por autoridad. La sugerencia en línea es el autocompletado mismo. El chat y el inline chat son el mismo modo en dos sitios — uno en el panel de conversación, el otro justo donde está el cursor —, pero en los dos preguntas tú y decides tú qué acaba en el fichero. El agent y el modo plan también son pareja: el modo plan es el agent con el freno puesto, que primero explora y espera tu aprobación antes de tocar tus fuentes. Vale la pena fijarse en el orden: no crece por capacidad, crece por autoridad. El primero sugiere, el segundo conversa, el tercero hace.
Un cambio de terminología que despista a mucha gente: la expresión «chat mode» ha caído en desuso. La documentación de los fabricantes dice hoy que los agents personalizados «antes se conocían como chat modes». Si lees una descripción antigua, tradúcetela.
El primer modo ya no es lo que era
La palabra «autocomplete» induce a error. Según la descripción del propio fabricante, el autocompletado de hoy modifica varias líneas, añade los imports que faltan y propone ediciones coordinadas en trozos de código relacionados — e incluso predice ediciones entre ficheros, a partir de tus últimos cambios, del código de alrededor y de los errores del linter.
O sea, la frontera del primer modo se ha difuminado hacia el tercero. Lo que hoy llamamos «autocompletado» hace unos años se habría llamado «refactorización».
Esto tiene una consecuencia práctica: pulsar Tab es hoy una decisión mayor que antes. El mismo gesto, pero cambia más cosas.
El agent: aquí empieza la diferencia de verdad
Esta es la parte que conviene entender con precisión, porque no es cuestión de gustos, sino de permisos.
Por defecto, un agent trabaja así:
NO PREGUNTA:
leer un fichero, buscar en la base de código
(en el directorio de trabajo y en las carpetas añadidas)
PREGUNTA:
ejecutar un comando de shell (salvo un conjunto corto de solo lectura)
escribir y modificar ficheros
descargar una página web (salvo dominios de docs preaprobados)
búsqueda web
Y los modos de aprobación — estos nombres cambian según la herramienta, pero la lógica es la misma:
- Manual. Pregunta la primera vez que usa cada herramienta. Es el valor por defecto.
- Aceptar ediciones. Acepta automáticamente los cambios de ficheros y los comandos habituales del sistema de ficheros, y pregunta el resto.
- Plan. Lee y ejecuta comandos de solo lectura, pero no reescribe tus fuentes. Para explorar, este es el modo correcto.
- Automático, con control de seguridad. Aprueba por su cuenta, pero un clasificador aparte revisa si la operación encaja con lo que has pedido.
- Saltárselo todo. La advertencia del propio fabricante: «úsalo solo en un entorno aislado, por ejemplo un contenedor o una máquina virtual, donde no pueda causar daños».
En otra familia de herramientas lo mismo aparece como niveles de sandbox: el nivel por defecto lee, escribe y ejecuta dentro del directorio de trabajo — sin acceso a la red — al lado hay un nivel de solo lectura, y hay un nivel «sin sandbox y sin aprobación».
Esta línea conviene grabársela: tener la red apagada por defecto no es una incomodidad, es la protección más importante que existe. Un agent que no puede llamar hacia fuera puede estropear muchísimo menos.
Un agent en el IDE y un agent en la nube no son lo mismo
Los propios fabricantes distinguen estas dos cosas y, aun así, en las conversaciones del gremio se mezclan.
- Agent en el IDE: corre en tu máquina, en tu copia de trabajo. Lo que estropee lo ves, y lo deshaces con
git checkout. - Agent en la nube: un servicio de servidor que explora el repositorio, escribe un plan, hace commit en una rama y abre un PR. Lo que estropee aterriza en un pull request.
Los dos tienen perfiles de riesgo distintos, y también modelos de aprobación distintos. En la versión en la nube la red suele venir apagada por defecto durante la fase de agent — justamente porque ahí no estás mirando en directo lo que hace.
¿Para qué sirve cada modo?
Aquí toca ser honesto: no encontramos ninguna medición controlada que empareje tipos de tarea con modos. Lo que hay es experiencia práctica y recomendaciones de los fabricantes. El reparto utilizable es este:
SUGERENCIA EN LÍNEA
código conocido, patrón conocido, trabajo de teclear
sabes qué quieres - solo quieres escribirlo más rápido
CHAT
"qué hace esta función", "por qué no compila", "qué
diferencia hay entre los dos enfoques"
-> entender y decidir, no ejecutar
AGENT
cambio bien acotado, ABURRIDO y de VARIOS FICHEROS
que tenga tests, que puedas revertir y que puedas
leer entero al final
LO QUE NO ENCAJA EN NINGUNO
el cambio en el que no sabes decir cuál es el resultado
correcto. Eso tienes que decidirlo tú antes.
Sobre lo extendidos que están sí hay datos recientes y de muestra grande: en una encuesta a más de 15.000 desarrolladores profesionales, en el verano de 2026 el 90 % usaba un coding agent al menos una vez por semana y el 68 % a diario.
Y una cifra lateral muy reveladora de esa misma encuesta, comparada con su oleada de medio año antes: se recolocó la cabeza de carrera. Una herramienta pasó del 3 % al 16 %, otra del 18 al 39, mientras que el anterior líder del mercado cayó del 29 al 21. Si eliges herramienta ahora, cuenta con que dentro de medio año el panorama será otro — lo detalla el post elegir tu entorno de programación , con los matices.
La tasa de aceptación, y lo que no sabemos de ella
La cifra que más se cita: los usuarios aceptan alrededor del 30 % de las sugerencias de código. La muestra es enorme, 934.533 usuarios — pero hay dos cosas que hay que saber al lado.
Una, que es telemetría del fabricante, sin metodología publicada: no queda claro si «aceptación» significa el momento de la inserción o que el código siguiera ahí después. Entre las dos cosas hay mucha diferencia.
La otra, que esta es la foto de 2022–2023. No encontramos ninguna cifra pública reciente igual de creíble — y eso que desde entonces el propio autocompletado se ha transformado.
Errores habituales
- «El agent usa un modelo más listo.» El mismo modelo corre en los tres. La diferencia está en la autoridad, no en la capacidad.
- «El autocomplete es inofensivo.» El autocompletado de hoy modifica varias líneas, añade imports y propone también entre ficheros. Tab es hoy una decisión mayor que antes.
- «El modo plan es una vuelta de más.» Es el único modo que no reescribe tus fuentes mientras explora. En una base de código desconocida, hay que empezar por ahí.
- «Me salto las aprobaciones, así voy más rápido.» La documentación del propio fabricante dice que eso solo vale en un entorno aislado. No es exceso de prudencia: la advertencia está en el producto.
- «El agent en la nube es lo mismo, solo que corre en otro sitio.» Su riesgo es otro y su modelo de aprobación también. Lo que estropee te llega como PR, no en tu pantalla.
Lo que conviene llevarse
Los tres modos se diferencian en su autoridad, no en su capacidad. Elige según cuánto estés dispuesto a deshacer: con el autocompletado una línea, con el chat un pegado, con el agent un commit entero. Y la configuración de aprobación del agent no es un detalle — es lo que decide cuándo pasan la shell y el sistema de ficheros a manos de la herramienta.
Qué tamaño conviene darle a esa primera tarea lo aterriza el post tu primera tarea con un agent , con cifras; y para el panorama más amplio, qué cambió de verdad, ahí está el post el balance de la programación , de principio a fin.