Tres arquitecturas, no diez productos
El mercado parece abarrotado, pero en realidad hay tres familias.
Basada en el IDE. El agent vive en tu editor. Ves lo que hace, ahí está el diff y git checkout está a una tecla. Es el salto más pequeño respecto a tu forma de trabajar habitual, y lo más fácil de deshacer.
Basada en terminal o CLI. El agent corre en una shell, en tu máquina, en tu directorio de trabajo. Es independiente del editor, se puede guionizar y se puede meter en CI. A cambio enseña menos por su cuenta: lo que no preguntas, no lo ves.
En la nube, asíncrona. Eliges un repositorio y una rama, el proveedor lo copia en una máquina virtual, el agent hace un plan, trabaja y después hace commit en una rama y abre un pull request. Tú mientras haces otra cosa. Lo que estropee te llega como PR.
Las tres no son alternativas entre sí — en la mayoría de los equipos serios están las tres, para trabajos distintos. La elección no es «cuál», sino «cuál para qué».
Lo que cambió en el verano de 2026
Dos hechos que dicen más del mercado que cualquier lista de funciones.
Un nombre de producto desapareció. El 2 de junio de 2026, el fabricante de un editor con IA muy conocido anunció la siguiente generación — con otro nombre. La actualización llegó como una actualización automática normal, y la suscripción, los precios y las extensiones se quedaron igual. También cambiaron el motor de agent: el soporte del antiguo terminó el 1 de julio de 2026.
Una herramienta cambió de dueño. El fabricante de otro editor con IA popular fue comprado por una gran empresa tecnológica; la operación se cerró el 14 de agosto de 2026 y la herramienta pasó a la unidad de IA del comprador. (Esto lo sabemos por fuentes de prensa financiera, no por un comunicado de las partes.)
La lección no es «no elijas herramienta». Es que el coste de salida hay que preverlo: el nombre del producto, el dueño y los precios pueden cambiar en menos de un año. Lo que conviene proteger: que tus instrucciones de proyecto, tu método de trabajo y tus procesos sean independientes de la herramienta. De esa parte habla más a fondo el post las instrucciones de proyecto , con ejemplos.
El precio ya no es una sola cifra
Hay tres modelos de precios compitiendo a la vez, y no son comparables en una sola tabla:
- Cuota mensual fija. Sencilla y previsible, pero los límites están escondidos en otro sitio.
- Créditos o bolsa. Hay créditos mensuales y el exceso se paga aparte. En los planes corporativos los créditos suelen ir a un pool común, y no por persona.
- Ventana de límite de peticiones. No hay créditos, sino N peticiones en una ventana de tiempo. Es la más difícil de planificar.
Lo que vale para las tres: el precio de tarifa no es el coste total. El precio de tarifa anual de un equipo de diez personas se mueve hoy entre unos 2.300 y 7.100 dólares por el mismo trabajo, según el plan — y ahí no está el exceso de consumo. (Cálculo propio, con precios de tarifa de septiembre de 2026, sin impuestos.)
Un ejemplo concreto de lo poco sencillo que es el cuadro: en uno de los grandes proveedores, la opción de residencia de datos y cumplimiento supone un recargo del 10 % en el multiplicador del modelo. Eso no aparece por ninguna parte en la cuota mensual.
La discusión sobre el indexado del repositorio parece resuelta
Durante dos años la pregunta fue cómo encuentra un agent el código en un repositorio grande: índice semántico (una base de datos de embeddings) o búsqueda de texto rápida.
En 2026 la balanza se ha inclinado hacia lo segundo. Según la documentación de uno de los grandes IDE, su indexado de la base de código no se basa en embeddings, sino en un buscador propio que en bases de código grandes rinde incluso mejor que el buscador de texto rápido más establecido, y sin configurar nada. Al lado, el context window de los modelos ha crecido hasta un millón de tokens.
Esto tiene una consecuencia que no es obvia: por eso el agent de terminal se volvió de golpe competitivo frente al IDE. Si no hace falta construir un índice aparte para que el agent encuentre el código, la infraestructura del editor deja de ser una ventaja.
Del lado corporativo, un detalle pequeño que puede salir caro: en uno de los proveedores, el indexado de la base de código está incluido solo en el plan corporativo más alto — en el plan de empresa intermedio, no.
¿Quién entrena con tu código? — cambia según el plan
Esta es la sección más importante del post, porque es concreta, comprobable y la mayoría de los equipos la tiene mal.
El patrón que se repite en todos los grandes proveedores: los planes individuales traen los valores por defecto menos favorables, y los corporativos los mejores.
- En uno de los grandes proveedores, en los planes individuales el proveedor puede usar los datos de uso para entrenar modelos (hay forma de desactivarlo), mientras que en los planes de empresa y corporativos la documentación dice literalmente que no entrena con ellos. La indemnización por propiedad intelectual tampoco existe por debajo del plan de empresa.
- En otro proveedor, en los planes de consumo el entrenamiento ocurre si el ajuste está activado — y entonces el periodo de conservación es de cinco años; si no lo está, de treinta días. En cambio, el código y los prompts enviados bajo las condiciones comerciales no entran en el entrenamiento de modelos, salvo que la empresa se apunte a un programa de partners aparte. La conservación cero de datos hay que activarla aparte, cuenta por cuenta, y no viene de serie en el plan corporativo.
- Y hay proveedores que ofrecen conservación cero del código, atribución de fuentes e indemnización, junto con un despliegue totalmente aislado.
Y una partida de la que casi no se habla: la caché local. Uno de los agents de terminal guarda las transcripciones de las conversaciones en texto plano en la carpeta del usuario, treinta días por defecto. El periodo de conservación es configurable. Si trabajas en un entorno regulado, ese directorio es objeto de auditoría igual que cualquier servicio en la nube — solo que nadie sabe que está ahí.
Dónde están los datos
Existen tres soluciones, de menor a mayor exigencia:
- Residencia de datos en el proveedor. Uno de los grandes proveedores ofrece desde el 13 de abril de 2026 una frontera de datos estadounidense y otra europea (UE + EFTA). Hay dos cosas importantes: viene desactivada por defecto y la tiene que activar el administrador corporativo, y supone un recargo del 10 % en el multiplicador del modelo.
- Inferencia en tu propia nube. A través de las plataformas de modelos de los grandes proveedores de nube, el código no sale de tu propio entorno.
- Despliegue totalmente aislado. También existe la variante air-gapped, sin ninguna red de salida.
Los agents de código abierto ofrecen un camino aparte: se pueden ejecutar en tu propia máquina, con el backend de modelo que quieras. A cambio, la configuración y el mantenimiento son cosa tuya.
El esqueleto de la decisión
1. ¿DÓNDE SE EJECUTA EL CÓDIGO?
en tu máquina (IDE / CLI) vs. en la VM del proveedor (nube)
-> decisión de seguridad, de velocidad y de forma de trabajar
2. ¿CUÁNDO LO MIRAS?
síncrono (lo ves en directo) vs. asíncrono (llega un PR)
-> el agent en la nube compensa si mientras haces OTRA COSA
3. ¿CUÁNTO PREGUNTA?
el modelo de aprobación es el mando de "cuánto me fío"
-> en base de código desconocida, empieza por lo más estricto
4. ¿QUIÉN ENTRENA CON TU CÓDIGO?
cambia según el plan. El plan individual suele traer
el peor valor por defecto. LÉELO, no lo supongas.
5. ¿DÓNDE ESTÁN LOS DATOS?
frontera de datos (opt-in, con recargo) / nube propia / air gap
+ la caché LOCAL, de la que todo el mundo se olvida
6. ¿CUÁNTO CUESTA SALIR?
si mañana cambia de nombre o de dueño: ¿cuánto de tu
trabajo se lleva con él? Las instrucciones de proyecto
y el método de trabajo deben ser independientes.
Qué elegir si hay que decidir ahora
- Solo o en equipo pequeño, sobre una base de código existente: empieza por lo basado en el IDE. Es el salto más pequeño y tienes el diff delante de los ojos.
- Si hay mucho trabajo repetitivo y guionizable: el agent de terminal es más eficiente, y además se puede enchufar a CI.
- Si tienes tareas aburridas, bien descritas y que no corren prisa: el agent en la nube compensa donde la ganancia es el paralelismo — mientras haces otra cosa.
- En un entorno regulado: el orden se invierte. Primero se resuelven los puntos 4 y 5, y solo después se miran las funciones.
Errores habituales
- «Elijo el mejor y ya está.» En medio año se recoloca el panorama, y en menos de un año puede cambiar hasta el nombre del producto. Elige arquitectura, no marca.
- «La cuota mensual es el coste.» Hay tres modelos de precios distintos, y el exceso de consumo, el pool de créditos y el recargo por cumplimiento no están en ninguno.
- «No entrenan con mi código, que para eso pago.» Pagar no lo decide por sí solo. Lo decide el tipo de plan, y los planes individuales suelen traer los valores por defecto menos favorables.
- «Si no hay datos en la nube, no hay riesgo.» Las transcripciones locales de las conversaciones pueden estar semanas en tu máquina en texto plano.
- «La residencia de datos está activada, que tenemos plan corporativo.» En uno de los grandes proveedores viene expresamente desactivada por defecto, y hay que activarla aparte.
Lo que conviene llevarse
Hay tres arquitecturas, no diez productos: el agent corre en tu editor, en tu terminal o en la máquina virtual del proveedor. Que la elección no la decida la lista de funciones, sino cuatro preguntas: dónde se ejecuta el código, cuándo lo miras, cuánto pregunta y quién entrena con él. La respuesta a la cuarta hay que leerla, porque cambia según el plan — y porque la mayoría de los equipos la tiene mal.
Cuándo toca cada uno de los tres modos de trabajo lo ordena el post los tres modos de programar con IA , modo a modo; y de cómo elegir la primera tarea real trata el post tu primera tarea con un agent , paso a paso.