Hay una frase que parece explicar toda la inteligencia artificial aplicada al código: un modelo de lenguaje predice el siguiente token.
La frase es técnicamente útil. También puede resultar engañosa si se utiliza para describir el producto completo.
Un autocomplete toma el contexto cercano al cursor y propone una continuación. Un agente de desarrollo puede recibir un objetivo, explorar un repositorio, consultar documentación, editar varios archivos, ejecutar comandos, observar errores, volver a intentarlo y entregar un diff para revisión.
En ambos casos hay un modelo generando tokens. Lo que cambia es el sistema construido alrededor.
Esa diferencia importa porque Cursor, Codex, Claude Code y Google Antigravity no aportan valor solamente por escribir código más rápido. Su utilidad aparece cuando pueden participar en una parte mayor del ciclo de desarrollo: recuperar contexto, tomar decisiones acotadas, usar herramientas, verificar resultados y devolver trabajo revisable.
También explica sus límites. Un modelo puede producir código convincente y equivocado. Un agente puede convertir ese error en cambios reales. Por eso, cuanto mayor es la capacidad de ejecución, más importantes se vuelven los tests, los permisos, el aislamiento, la observabilidad y la revisión humana.
En resumen
Un LLM genera tokens. Un autocomplete utiliza esa capacidad para proponer una continuación local. Un agente la incorpora a un sistema que puede observar un entorno, seleccionar herramientas, ejecutar acciones y corregirse a partir del resultado.
Eso no convierte al agente en un desarrollador infalible ni elimina la necesidad de una persona responsable. Significa que la unidad de trabajo deja de ser únicamente la siguiente línea y puede pasar a ser una tarea completa, como reproducir un bug, añadir un test, actualizar una dependencia o preparar un pull request.
La utilidad real de estas herramientas depende de cinco condiciones:
- El objetivo está suficientemente acotado.
- El agente recibe el contexto necesario.
- Existen señales verificables, como tests, compilación o comportamiento visible.
- El cambio es reversible y revisable.
- El coste de controlar el resultado es menor que el trabajo evitado.
La pregunta correcta no es si la herramienta “es autocomplete”. La pregunta es qué parte del trabajo puede cerrar de forma verificable y dentro de qué límites.
Un LLM puede predecir tokens sin que el producto sea solo autocomplete
Los modelos base de lenguaje se entrenan para predecir la siguiente unidad de una secuencia. Esa unidad suele expresarse como token, no necesariamente como una palabra completa. A partir del contexto anterior, el modelo asigna probabilidades a posibles continuaciones y produce una salida.
Esa es la mecánica generativa.
Pero un producto de desarrollo incorpora otras capas:
| Capa | Qué aporta |
|---|---|
| Modelo | Interpreta instrucciones, relaciona información y genera código, planes o llamadas a herramientas. |
| Postentrenamiento | Ajusta el comportamiento para seguir instrucciones, utilizar herramientas y respetar determinados límites. |
| Contexto | Aporta archivos, reglas del repositorio, historial, documentación, errores y decisiones anteriores. |
| Agente | Administra el ciclo de trabajo y decide qué información o herramienta necesita a continuación. |
| Herramientas | Permiten leer, buscar, editar, ejecutar comandos, usar Git, consultar APIs o interactuar con otras aplicaciones. |
| Entorno | Devuelve señales reales: tests, compilación, logs, navegador, diff, estado de una tarea o respuesta de un servicio. |
| Controles | Limitan filesystem, red, secretos, comandos, identidad, número de intentos y acciones sensibles. |
| Revisión humana | Comprueba intención, arquitectura, riesgo y alineación con necesidades que no siempre están escritas. |
Reducir todo el sistema a la predicción de tokens es como definir un navegador diciendo que ejecuta instrucciones de procesador. No es falso, pero no permite distinguirlo de una hoja de cálculo, un videojuego o un servidor.
Para evaluar un agente hay que observar el comportamiento del conjunto.
Autocomplete, asistente y agente no son la misma unidad de trabajo
La evolución de estas herramientas no es solamente una escala de “más código generado”.
Autocomplete
Trabaja cerca del cursor. Sugiere cómo continuar una función, una condición, un test o una llamada a una API.
La persona conserva el ciclo completo:
pensar → escribir → ejecutar → interpretar → corregirEl autocomplete reduce parte de la escritura.
Asistente conversacional
Puede explicar una arquitectura, proponer una función, revisar un fragmento o responder preguntas sobre archivos que recibe como contexto.
Amplía la capacidad de análisis, pero muchas veces la persona sigue copiando información hacia el chat y trasladando la respuesta al proyecto.
Agente de desarrollo
Recibe un objetivo y puede operar dentro del entorno:
objetivo
→ inspeccionar el repositorio
→ formular un plan
→ editar
→ ejecutar herramientas
→ observar el resultado
→ corregir
→ verificar
→ entregar para revisiónLa diferencia no es solo de longitud. Es una diferencia de control de flujo.
Un agente puede elegir qué archivo leer, qué comando ejecutar y cuándo la tarea requiere otra iteración. Según la definición utilizada por OpenAI, el LLM controla la ejecución del workflow y selecciona herramientas. Anthropic distingue de forma parecida los workflows con rutas predefinidas de los agentes que dirigen dinámicamente sus procesos y su uso de herramientas.
El feedback del entorno cambia la calidad del trabajo
Un modelo puede generar una función que parece correcta. La terminal puede demostrar que no compila.
Puede proponer una migración. Los tests pueden mostrar que rompe compatibilidad.
Puede afirmar que corrigió un problema visual. Un navegador controlado por el agente puede revelar que el componente sigue desbordando en móvil.
Ese feedback no vuelve determinista al modelo, pero reduce la dependencia de una única respuesta plausible. El sistema puede contrastar la generación con evidencia externa.
Por eso el desarrollo de software es un terreno especialmente adecuado para los agentes:
- existe código estructurado;
- muchas acciones se pueden ejecutar en un entorno aislado;
- los cambios quedan representados como diff;
- los tests ofrecen criterios de aceptación;
- Git permite comparar, revertir y revisar;
- compiladores, linters y analizadores generan señales concretas.
La verificación automática tampoco es suficiente. Un test puede estar incompleto, una especificación puede ser ambigua y una solución puede pasar la suite mientras empeora la arquitectura. El entorno aporta ground truth parcial, no criterio total.
La revisión humana no niega que exista un agente
Un sistema no necesita publicar código sin permiso para ser un agente.
Supongamos que recibe esta tarea:
Localiza por qué el checkout repite un cobro ante un timeout, añade un test de regresión y prepara un cambio revisable.
Durante la ejecución puede:
- buscar la lógica de reintentos;
- reconstruir el recorrido entre varios módulos;
- leer tests existentes;
- reproducir el fallo;
- modificar dos o tres archivos;
- ejecutar la suite;
- corregir un error secundario;
- resumir la causa;
- presentar el diff.
Si una persona revisa ese resultado antes del merge, el trabajo anterior no se convierte retroactivamente en autocomplete.
La revisión define quién tiene autoridad para aceptar el cambio. También protege requisitos que el agente puede no conocer: decisiones de producto, convenciones tácitas, dependencias organizativas, impacto operativo o prioridades futuras.
Conviene separar capacidad de autorización:
| Nivel | Capacidad del sistema | Autorización razonable |
|---|---|---|
| Asistencia | Explica o propone código. | Puede responder directamente. |
| Investigación | Lee y diagnostica. | Acceso de solo lectura. |
| Preparación | Edita en una rama o worktree. | Escritura acotada y tests. |
| Delegación | Completa una tarea y prepara un PR. | Revisión antes de integrar. |
| Automatización | Se ejecuta ante eventos o cron. | Políticas por tipo de tarea y límites de volumen. |
| Operación sensible | Despliega, modifica datos o usa secretos. | Aprobación explícita, identidad separada y auditoría. |
La autonomía útil no es “todo o nada”. Se configura por acción, entorno y riesgo.
Qué aporta Cursor
Cursor combina varias superficies dentro de un mismo producto.
Tab sigue siendo autocomplete: propone continuaciones mientras la persona edita. Agent puede buscar en el codebase, leer y modificar archivos, utilizar terminal y acceder a herramientas MCP. Cursor CLI lleva el agente a la terminal y a scripts. Los agentes cloud pueden trabajar en máquinas aisladas, probar cambios y producir artefactos como capturas, vídeos o logs para acompañar un pull request.
Esa combinación tiene una ventaja práctica: permite cambiar el nivel de delegación sin abandonar el flujo de trabajo.
Una persona puede:
- escribir manualmente una parte sensible;
- aceptar una continuación local;
- pedir una edición sobre varios archivos;
- delegar un bug a un agente cloud;
- revisar el resultado desde el IDE o GitHub.
Cursor es especialmente útil cuando el centro del trabajo sigue siendo el editor y se quiere incorporar agencia de forma progresiva.
Su riesgo también nace de esa fluidez. Es fácil pasar de una sugerencia pequeña a una edición amplia sin redefinir el alcance. Por eso conviene revisar el plan, el diff y los comandos, y distinguir tareas exploratorias de cambios que pueden integrarse.
Qué aporta Codex
Codex CLI trabaja directamente desde terminal. Puede inspeccionar código, modificar archivos, ejecutar comandos, revisar cambios y automatizar trabajo repetible. La configuración permite definir instrucciones del proyecto, permisos y modos de revisión.
Codex cloud cambia la dimensión temporal. Cada tarea puede recibir un entorno aislado y reproducible, continuar mientras la persona trabaja en otra cosa y regresar como un resultado revisable. También permite iniciar trabajo desde GitHub, Linear o Slack y ejecutar varias tareas en paralelo.
Su valor aparece en dos patrones.
Delegación cerrada
La tarea tiene una condición de salida reconocible:
Actualiza esta API, conserva compatibilidad, añade tests y devuelve un diff.
La persona invierte tiempo en especificar y revisar, no necesariamente en ejecutar cada paso.
Paralelismo
Mientras un desarrollador trabaja en una decisión arquitectónica, varios agentes pueden investigar bugs independientes, preparar documentación o probar alternativas.
Ese paralelismo no elimina el coste. Traslada el cuello de botella hacia la especificación, la evaluación y la integración. Si diez agentes producen diez cambios mediocres, la organización no multiplicó su productividad: multiplicó su cola de revisión.
Qué aporta Claude Code
Claude Code se orientó originalmente a la terminal, pero actualmente también funciona en IDE, escritorio y navegador. Puede leer el codebase, editar archivos, ejecutar comandos, trabajar con Git, crear pull requests y conectar herramientas externas mediante MCP.
Su extensibilidad es una parte importante del producto.
Un archivo CLAUDE.md puede aportar reglas persistentes del proyecto. Las skills encapsulan procedimientos reutilizables. Los servidores MCP conectan sistemas como issue trackers, observabilidad o documentación. Los hooks ejecutan controles en puntos específicos del ciclo.
Los hooks muestran bien la diferencia entre modelo y sistema.
No es necesario confiar en que el LLM recuerde ejecutar el formateador después de cada edición. Un hook determinista puede hacerlo siempre. Tampoco es necesario esperar que decida por sí mismo bloquear un comando peligroso: una regla puede validarlo antes de la ejecución.
Claude Code encaja especialmente bien cuando el equipo quiere construir un entorno agéntico alrededor de terminal, Git, scripts y herramientas internas.
Qué aporta Google Antigravity
Google Antigravity separa de forma explícita la edición directa de la coordinación de agentes.
El IDE incluye completado, comandos y un agente capaz de operar sobre editor, terminal y navegador. Antigravity 2.0 añade una superficie de gestión para lanzar, observar y coordinar varios agentes sobre proyectos y workspaces diferentes. Los subagentes pueden dividir partes de un problema, las tareas programadas permiten automatizar trabajos recurrentes y los artefactos muestran planes, resultados y evidencia de verificación.
La abstracción central ya no es “una conversación con el código”, sino una cartera de tareas.
Eso resulta útil cuando el trabajo puede dividirse:
- un agente investiga la causa;
- otro prepara tests;
- otro valida la interfaz;
- otro revisa una migración;
- la persona compara artefactos y decide qué integrar.
El desafío es organizativo. Cuantos más agentes trabajan en paralelo, más importante resulta evitar solapamientos, conflictos, objetivos ambiguos y revisión superficial.
No hay una herramienta universalmente mejor
Las cuatro herramientas se superponen, y sus capacidades cambian con rapidez. La decisión debería partir del flujo, no del ranking.
| Necesidad principal | Herramienta que conviene evaluar | Motivo |
|---|---|---|
| Permanecer dentro del IDE y alternar entre Tab, edición y agente | Cursor | Integra distintos niveles de asistencia en la misma superficie. |
| Trabajar desde terminal y delegar tareas a entornos cloud | Codex | Combina ejecución local, automatización y trabajo aislado en paralelo. |
| Personalizar reglas, hooks, skills y conexiones con sistemas internos | Claude Code | Ofrece una superficie extensible alrededor de terminal y herramientas. |
| Coordinar varios agentes y proyectos mediante artefactos | Antigravity | Prioriza orquestación, subagentes, tareas programadas y gestión de resultados. |
| Automatizar tareas repetitivas en CI o ante eventos | Cursor, Codex o Claude Code | Los tres ofrecen modos programáticos; la elección depende de permisos e integraciones. |
| Mantener máxima supervisión en cambios sensibles | Cualquiera con el entorno correcto | El control depende más de permisos, ramas, tests y aprobaciones que de la marca. |
La comparación debería rehacerse periódicamente. En este mercado, una tabla de funcionalidades envejece rápido. Las preguntas más estables son:
- ¿Dónde vive el contexto?
- ¿Qué herramientas puede usar?
- ¿Cómo aísla la ejecución?
- ¿Qué evidencia devuelve?
- ¿Cómo se revisa el resultado?
- ¿Qué acciones necesitan aprobación?
- ¿Cuánto cuesta operar y controlar el flujo?
De dónde viene la utilidad real
El beneficio no se limita a teclear menos.
Recuperar contexto
Una parte considerable del trabajo técnico consiste en encontrar archivos, reconstruir decisiones, seguir llamadas, leer logs y recordar cómo se ejecuta un proyecto.
Un agente puede reducir ese coste de orientación, especialmente en repositorios desconocidos o tareas que atraviesan varias capas.
Cerrar bucles de verificación
Generar código es barato. Comprobarlo suele ser el trabajo importante.
Cuando el agente puede ejecutar tests, leer el error y corregir, absorbe parte de un ciclo que antes exigía atención continua.
Evitar cambios de contexto
Un bug pequeño puede tardar poco en resolverse, pero interrumpe una tarea más valiosa. Delegarlo a un entorno separado puede aportar más que acelerar sus minutos de implementación.
Abordar el backlog de baja prioridad
Documentación, tests faltantes, migraciones repetitivas, actualizaciones mecánicas y fallos intermitentes suelen aplazarse porque no justifican una interrupción.
Un agente puede reducir el coste de iniciar esos trabajos.
Explorar alternativas en paralelo
Para una decisión reversible, varios intentos independientes pueden revelar soluciones, riesgos o diferencias de implementación antes de comprometer tiempo del equipo.
El paralelismo solo aporta valor si después existe un criterio eficiente para comparar.
La evidencia sobre productividad es mixta
No existe una cifra universal que diga cuánto acelera un agente de desarrollo.
Un ensayo controlado de METR, realizado con herramientas de principios de 2025, encontró que 16 desarrolladores experimentados trabajando en repositorios que conocían tardaron un 19% más cuando podían utilizar IA. Los participantes, sin embargo, creían que habían trabajado más rápido.
Ese resultado no debería extrapolarse sin cuidado. METR lo presenta actualmente como histórico y señala que ya no refleja necesariamente las herramientas de 2026. El estudio se concentró en desarrolladores expertos, repositorios maduros y tareas reales de entre aproximadamente veinte minutos y cuatro horas.
En febrero de 2026, METR publicó datos posteriores con señales de aceleración, pero consideró que la estimación no era fiable. Algunos desarrolladores evitaban participar porque no querían quedar asignados a trabajar sin IA; además, el uso simultáneo de varios agentes volvía difícil medir el tiempo humano invertido.
Un estudio de campo sobre el despliegue de Claude Code y Copilot CLI en Microsoft durante los primeros meses de 2026 encontró que los adoptantes fusionaron aproximadamente un 24% más de pull requests que la estimación contrafactual. Los propios autores advierten que un PR fusionado es un proxy de output, no una medida directa de valor, calidad o impacto.
También hay un coste de aprendizaje. Un ensayo de Anthropic con 52 desarrolladores encontró que el grupo asistido por IA obtuvo un resultado de comprensión un 17% inferior al aprender una biblioteca nueva. Terminó apenas unos minutos antes, pero esa diferencia de tiempo no fue estadísticamente significativa. Quienes utilizaron la IA para pedir explicaciones y construir comprensión conservaron más conocimiento que quienes delegaron la solución.
Estas investigaciones miden situaciones distintas. En conjunto sugieren algo más útil que una cifra promedio:
La productividad depende del tipo de tarea, el conocimiento previo, la herramienta, la forma de uso, la posibilidad de verificar y la métrica elegida.
Dónde suelen funcionar mejor
Una tarea tiene buen encaje cuando reúne varias de estas propiedades.
Objetivo concreto
“Mejora la arquitectura” deja demasiadas decisiones abiertas.
“Extrae esta validación a un módulo, conserva la API pública y añade tests para estos casos” define mejor el alcance.
Resultado verificable
Compilación, tests, lint, tipos, snapshots, benchmarks o comportamiento de navegador permiten comprobar progreso.
Cambio reversible
Una rama, worktree, patch o entorno cloud aislado reduce el coste de un intento fallido.
Contexto accesible
El repositorio incluye instrucciones, comandos, convenciones, ejemplos y decisiones técnicas. El agente no necesita adivinar todo lo que el equipo sabe.
Revisión acotada
El diff es comprensible y el resultado incluye una explicación, los comandos ejecutados y los riesgos pendientes.
Con esas condiciones, suelen ser buenos candidatos:
- bugs acotados con test de regresión;
- refactors mecánicos;
- actualización de dependencias;
- migraciones repetitivas;
- generación o ampliación de tests;
- investigación de errores de CI;
- documentación vinculada al código;
- prototipos desechables;
- análisis inicial de un repositorio;
- preparación de un pull request para revisión.
Dónde pueden empeorar el trabajo
La utilidad cae cuando:
- el requerimiento es ambiguo;
- las reglas de negocio no están documentadas;
- no existe una forma de validar el resultado;
- el cambio atraviesa demasiados sistemas;
- hay decisiones de producto pendientes;
- el repositorio contradice sus propias convenciones;
- el agente recibe permisos o secretos innecesarios;
- revisar el código cuesta más que escribirlo;
- el equipo acepta output que no puede explicar;
- una persona en formación delega precisamente el razonamiento que necesita aprender.
Otro riesgo es medir actividad en lugar de progreso.
Más líneas, commits o pull requests pueden significar más valor. También pueden significar más volumen para revisar, más duplicación y más deuda técnica.
La unidad correcta es trabajo terminado y validado
Para evaluar estas herramientas conviene abandonar la pregunta “¿cuánto código generó?” y observar el flujo completo.
| Dimensión | Métrica útil |
|---|---|
| Velocidad | Tiempo desde la tarea hasta un diff revisable. |
| Atención humana | Minutos activos de especificación, seguimiento y revisión. |
| Aceptación | Porcentaje del cambio conservado sin reescritura sustancial. |
| Retrabajo | Correcciones necesarias después de la primera entrega o del merge. |
| Calidad | Regresiones, incidentes, resultados de tests y defectos encontrados en revisión. |
| Flujo | Tiempo desde issue hasta merge y tiempo bloqueado. |
| Cobertura | Trabajo útil que antes quedaba sin hacer. |
| Coste | Licencias, tokens, infraestructura, ejecuciones y revisión. |
| Riesgo | Permisos excesivos, exposición de datos, acciones externas e incidentes. |
| Aprendizaje | Capacidad del equipo para explicar, depurar y mantener el resultado. |
Una fórmula conceptual sería:
valor neto =
tiempo humano evitado
+ trabajo adicional útil
+ mejora de calidad
+ valor del paralelismo
- tiempo de especificación y revisión
- retrabajo
- coste de ejecución
- riesgo introducido
- pérdida de comprensiónNo todos los términos son fáciles de monetizar. Aun así, la fórmula obliga a mirar más allá de la velocidad aparente.
Cómo lo plantearía Nicolás Torres
No empezaría por comprar una herramienta para todo el equipo ni por exigir una cuota de uso.
Empezaría por elegir tres tipos de tarea reales, frecuentes y comparables. Por ejemplo:
- correcciones pequeñas con test de regresión;
- diagnóstico de errores de CI;
- actualización de documentación o dependencias.
Después establecería una línea base:
- tiempo total;
- tiempo activo humano;
- número de intentos;
- tiempo de revisión;
- retrabajo;
- defectos posteriores;
- coste de interrupción;
- porcentaje de tareas abandonadas.
El piloto utilizaría un entorno acotado:
- instrucciones del repositorio;
- rama o worktree separado;
- filesystem limitado;
- secretos fuera de alcance;
- red controlada;
- comandos definidos;
- tests obligatorios;
- aprobación antes de integrar;
- registro de acciones suficiente.
Tras varias semanas, compararía por tipo de tarea y perfil de usuario. No mezclaría un bug mecánico con una decisión arquitectónica ni a una persona experta en el repositorio con alguien que acaba de incorporarse.
También reservaría espacios de trabajo sin delegación para aprendizaje. Un equipo que produce más código pero pierde capacidad para entenderlo y corregirlo está trasladando riesgo hacia el futuro.
La autonomía crecería únicamente donde el resultado demuestre valor:
leer
→ proponer
→ editar en aislamiento
→ ejecutar bajo riesgo
→ preparar un PR
→ automatizar tareas repetiblesDesplegar, modificar datos reales o usar credenciales sensibles seguiría otro proceso.
Qué debería quedar claro al elegir una herramienta
Antes de comparar modelos o planes, pediría respuestas concretas a estas preguntas:
- ¿Puede trabajar sobre todo el repositorio o solo sobre contexto seleccionado?
- ¿Qué acciones ejecuta localmente y cuáles en cloud?
- ¿Cómo se reproducen dependencias y variables del entorno?
- ¿Qué permisos tiene sobre archivos, terminal, red y herramientas externas?
- ¿Puede separar cada tarea en una rama, worktree o máquina aislada?
- ¿Qué artefactos devuelve para revisar?
- ¿Cómo registra comandos, tool calls y decisiones?
- ¿Qué ocurre cuando falla un test o supera el número de intentos?
- ¿Cómo se evita que lea secretos?
- ¿Cómo se calcula el coste real, incluyendo revisión y retrabajo?
La mejor herramienta no es la que genera la demo más impresionante. Es la que mejora un flujo concreto sin volver opaco el riesgo.
Conclusión
Un modelo de lenguaje predice tokens. Esa descripción explica una parte esencial de su funcionamiento.
No explica por sí sola qué es un agente de desarrollo.
Un autocomplete utiliza la predicción para sugerir una continuación. Un agente la inserta en una arquitectura con contexto, herramientas, estado, ejecución, feedback, permisos y condiciones de salida.
Cursor, Codex, Claude Code y Antigravity son útiles cuando esa arquitectura permite cerrar una parte verificable del trabajo:
comprender
→ actuar
→ comprobar
→ corregir
→ entregarNo son infalibles. No hacen valiosa cualquier tarea. No sustituyen automáticamente el criterio, la arquitectura, el conocimiento de negocio ni la responsabilidad humana.
Pero tampoco se explican correctamente como sistemas que solo escriben la línea siguiente.
La pregunta que debería guiar su adopción es más exigente:
¿Qué trabajo útil puede completar este agente, qué evidencia devuelve, cuánto esfuerzo humano evita y qué límites necesita para que el resultado sea confiable?
Cuando esa pregunta tiene una respuesta medible, la discusión deja de ser semántica. Pasa a ser una decisión de ingeniería.
Preguntas frecuentes
- ¿Un LLM es solamente un autocomplete?
- En su mecanismo generativo, un LLM predice el siguiente token a partir del contexto. Pero esa descripción no alcanza para explicar un producto completo: el postentrenamiento, el contexto, las herramientas, la memoria, el entorno de ejecución y los controles cambian lo que el sistema puede hacer.
- ¿Qué diferencia a un autocomplete de un agente de desarrollo?
- El autocomplete propone una continuación local. Un agente recibe un objetivo, explora el repositorio, selecciona herramientas, edita archivos, ejecuta comandos, observa resultados y puede iterar hasta entregar un cambio verificable.
- ¿Cursor, Codex, Claude Code y Antigravity hacen lo mismo?
- Comparten capacidades agénticas, pero priorizan superficies distintas. Cursor integra completado, IDE, CLI y agentes cloud; Codex combina terminal y delegación en entornos aislados; Claude Code destaca por terminal, extensibilidad, hooks y MCP; Antigravity se orienta a coordinar agentes, proyectos y artefactos.
- ¿Que una persona revise el código significa que el sistema no es un agente?
- No. La revisión humana define autoridad y responsabilidad. Un agente puede investigar, editar, probar y preparar un pull request, y aun así detenerse antes de integrar o desplegar porque esa acción requiere aprobación.
- ¿Estas herramientas siempre aumentan la productividad?
- No. La evidencia muestra resultados distintos según la herramienta, la tarea, la experiencia, el repositorio y la métrica. Pueden acelerar trabajo acotado y verificable, pero también aumentar revisión, retrabajo o pérdida de comprensión.
- ¿Cómo debería evaluarlas una empresa?
- Con tareas reales, una línea base y métricas de trabajo terminado: tiempo activo humano, tiempo hasta un diff revisable, aceptación, retrabajo, regresiones, coste, riesgo y capacidad del equipo para mantener el resultado.