La IA que responde vs la IA que ejecuta
Llevo meses usando IA a diario para desarrollar software. Primero como todo el mundo: pegando código en ChatGPT, copiando la respuesta, probándola, volviendo al chat cuando fallaba. El ciclo clásico. Al principio me parecía revolucionario. Comparado con buscar en Stack Overflow, tener un modelo que te genera código a medida era un salto enorme.
Pero con el tiempo empecé a notar el techo. No era un problema del modelo en sí, sino de la dinámica: yo era el mensajero entre la IA y mi entorno de desarrollo. Cada iteración pasaba por mis manos, y eso se convertía en el cuello de botella.
Hasta que probé herramientas como Claude Code, Codex CLI o Gemini CLI, que se ejecutan directamente en tu terminal, con acceso a tu proyecto, tu sistema de archivos y tus comandos.
Y la diferencia no es incremental. Es otra cosa. No mejor o peor, sino distinta en naturaleza. Como la diferencia entre leer una receta y tener a alguien cocinando contigo.
El chatbot como consultor
Los chatbots (ChatGPT, Claude en su web, Gemini) son buenos en lo suyo: generar código, explicar conceptos, proponer arquitecturas, revisar fragmentos que les pegas. Pero todo pasa dentro de una ventana de chat. No ven tu proyecto. No ejecutan nada. No saben qué hay en tu package.json ni por qué ese test falla.
Tú eres el intermediario obligatorio. Copias, pegas, ejecutas, copias el error, vuelves al chat. Si el código tiene dependencias con otros archivos del proyecto, tienes que pegarlos todos tú, uno a uno, dándole contexto manualmente.
Y hay un problema más sutil: el contexto se degrada. Le pegas un archivo, luego otro, luego el error. Para cuando le das el tercer archivo ya no recuerda bien el primero. Le explicas la relación entre módulos y aun así genera código que no encaja porque no tiene la foto completa. Acabas gastando más tiempo dando contexto que escribiendo el código tú mismo.
Funciona para cosas puntuales. Pero en cuanto el problema cruza más de un archivo, la fricción se acumula rápido. Y en proyectos reales, casi todo cruza más de un archivo.
Hay otra limitación que se nota con el uso: la falta de feedback directo. Le pides que te genere un componente de React. Te lo da. Lo pegas en tu editor y resulta que no compila porque usa una versión de una API que no coincide con la que tienes instalada. Vuelves al chat, le pegas el error, te da una corrección. La pegas. Ahora compila pero el test falla. Vuelta al chat. Cada iteración te cuesta un minuto o dos de copiar y pegar. Multiplica eso por las veces que iteras al día y el tiempo se va sin que te des cuenta.
Cuando la IA toca tu terminal
Un agente con acceso al terminal hace algo fundamentalmente distinto: opera sobre tu proyecto real. Puede leer tus archivos, entender la estructura, ejecutar comandos, ver los errores y corregirlos por su cuenta.
Le dices “crea una API REST con estos endpoints” y no te devuelve un bloque de código para que copies. Crea los archivos, instala las dependencias, ejecuta los tests, ve que algo falla, lo arregla y vuelve a ejecutar. Un ciclo cerrado en el que tú supervisas en lugar de hacer de intermediario.
El otro día le pedí a Claude Code que refactorizara un módulo que tocaba seis archivos. En un chatbot habría sido una pesadilla de contexto: pegar cada archivo, explicar las relaciones, aplicar los cambios uno a uno. En terminal lo resolvió en un par de minutos, leyendo todo el árbol del proyecto por su cuenta.
Lo más interesante es lo que pasa cuando falla. En un chatbot, un error rompe tu flujo: tienes que copiar el mensaje, pegarlo, esperar respuesta, aplicar el cambio. Con un agente en terminal, el error es parte del proceso. Lo ve, lo interpreta, ajusta el código y vuelve a ejecutar. Tú solo ves el resultado final, o intervienes si ves que va por mal camino.
Otro ejemplo concreto: configurar un proyecto desde cero. Un chatbot te puede dar los pasos, pero tú tienes que ejecutar cada comando, resolver los conflictos de versiones, ajustar la configuración cuando algo no encaja. Un agente en terminal ejecuta npm init, instala lo que necesita, crea la estructura de carpetas, configura el linter, añade los scripts al package.json y al final te enseña lo que ha hecho para que lo revises. En diez minutos tienes un proyecto configurado que a mano te habría llevado media hora o más.
Lo que realmente cambia
No es que el modelo sea más listo. Muchas veces es exactamente el mismo modelo. Lo que cambia es el acceso:
- Puede leer todo tu proyecto, no solo lo que le pegas.
- Ejecuta linters, tests, builds. Ve los errores reales, no los que tú le describes.
- Corrige y vuelve a ejecutar hasta que funciona.
- Trabaja con Git directamente.
- Puede encadenar tareas sin tu intervención en cada paso.
En la práctica, pasa de ser un consultor al que le preguntas a un colaborador que trabaja contigo en el mismo entorno.
Esto tiene una consecuencia importante en cómo formulas las peticiones. Con un chatbot tiendes a pedir cosas pequeñas y concretas: “dame una función que haga X”. Con un agente en terminal puedes pedir objetivos más amplios: “añade autenticación JWT a esta API, con tests”. El agente se encarga de descomponer el objetivo en pasos, ejecutarlos y validar que todo funciona junto.
Eso no significa que le puedas pedir cualquier cosa sin más. Cuanto más claro sea el objetivo y mejor documentado esté tu proyecto, mejores resultados vas a obtener. Pero el nivel de ambición de lo que puedes delegar es otro.
Yo he pasado de pedir “genera una función que valide emails” a pedir “refactoriza el sistema de validación para que use schemas de Zod, actualiza los tests y asegúrate de que pasan”. Es otro registro.
No es magia: tiene sus límites
Dicho esto, no quiero pintar una imagen idílica. Los agentes con acceso al terminal no son infalibles. A veces entran en bucles intentando resolver un error de una forma que no funciona. Me ha pasado ver a un agente intentar la misma solución tres veces seguidas esperando un resultado diferente. En esos casos tienes que intervenir, redirigir o directamente decirle “para, prueba otra cosa”.
Otras veces hacen cambios que técnicamente cumplen lo que pediste pero no encajan con la lógica de tu proyecto porque no entienden la intención de negocio detrás del código. Resuelven el problema inmediato pero crean deuda técnica. Por eso es importante revisar lo que hacen, no aceptarlo a ciegas.
También hay que tener cuidado con los permisos. Darle a una IA acceso a tu terminal implica que puede ejecutar comandos reales en tu máquina. Las herramientas serias tienen sistemas de permisos por niveles: puedes dejar que lea archivos libremente pero que te pida confirmación antes de ejecutar comandos o modificar código. Es importante configurar eso bien, especialmente al principio, hasta que entiendas qué hace y cómo lo hace.
Otro punto: la calidad del resultado depende mucho de cómo esté tu proyecto. Si tienes un repo bien estructurado, con tests, con un README que explica cómo arrancar las cosas, el agente rinde mucho mejor. Si tu proyecto es un caos sin documentar, el agente va a generar código que encaje con ese caos. Basura entra, basura sale, igual que con cualquier otra herramienta.
Y hay tareas donde simplemente no aporta tanto. Si necesitas pensar un diseño de sistema, evaluar trade-offs de arquitectura o decidir entre dos enfoques, un chatbot conversacional sigue siendo mejor. El agente en terminal es una herramienta de ejecución, no de reflexión.
Dónde tiene sentido cada uno
No todo requiere un agente en terminal. Para preguntas conceptuales, explorar ideas o pedir opinión sobre un diseño, el chatbot sigue siendo perfecto. Es rápido, directo, sin fricción. También para aprender: si quieres entender cómo funciona algo, una conversación es mejor que ver cómo un agente lo implementa sin explicarte nada.
El agente en terminal brilla cuando hay que tocar código real: refactorizaciones que cruzan archivos, configurar un proyecto desde cero, automatizar tareas repetitivas, depurar problemas que requieren ejecutar cosas para entenderlos. Básicamente, todo lo que implica un ciclo de escribir-ejecutar-corregir.
En mi caso, he acabado con un flujo bastante natural: pienso y diseño en el chatbot, ejecuto con el agente en terminal. Si tengo una duda conceptual, abro el chat. Si tengo que implementar algo, abro la terminal. Cada herramienta donde aporta más.
Un caso que ilustra bien esto: el otro día estuve media hora en un chatbot explorando distintas formas de estructurar la autenticación de un proyecto. Hicimos y deshicimos, comparamos enfoques, descartamos ideas. Cuando tuve claro el camino, le pasé la decisión al agente en terminal y en quince minutos estaba implementado, con tests y todo. Pensar en un sitio, ejecutar en otro.
Cómo cambia tu forma de trabajar
Hay algo que no esperaba y que merece la pena mencionar: usar agentes en terminal cambia cómo piensas sobre tu propio trabajo.
Antes, cuando tenía que hacer una tarea tediosa como renombrar un patrón en quince archivos o escribir tests unitarios para funciones de utilidad, lo hacía con desgana pero lo hacía. Era parte del trabajo. Ahora, antes de ponerme con algo así, me pregunto: “¿puede hacer esto el agente?” Y la respuesta suele ser que sí.
Empiezas a ver las tareas en dos categorías: las que requieren criterio humano y las que son ejecución mecánica.
Cuando llevas un tiempo así, te das cuenta de algo: resulta que muchas tareas que parecían requerir criterio eran en realidad ejecución disfrazada. Configurar un entorno, migrar una sintaxis vieja a una nueva, añadir tests para código que ya existe, actualizar imports después de mover un archivo. Todo eso lo puede hacer un agente si le das el contexto suficiente.
Lo que queda para ti es lo que realmente importa: decidir qué construir, cómo debería funcionar, qué trade-offs aceptar. El trabajo de diseño y decisión, que es donde un desarrollador aporta más valor.
No digo que la ejecución no tenga valor. Obviamente la tiene. Pero si puedes delegarla a una herramienta que la hace bien y dedicar tu tiempo a pensar mejor los problemas, el resultado neto es mejor software en menos tiempo. Al menos esa es mi experiencia hasta ahora.
También cambia la relación con los errores. Antes, un error en producción significaba abrir el repo, buscar el problema, hacer el fix, correr tests, hacer commit. Con un agente en terminal, le puedes dar el log del error y decirle “encuéntralo y arréglalo”. No siempre acierta a la primera, pero el tiempo entre “sé que hay un bug” y “está arreglado con tests” se reduce bastante.
La línea que importa
Si me preguntan cuál es la distinción relevante en herramientas de IA para desarrollo, no es qué modelo usan. Es qué pueden hacer con tu entorno. Un modelo encerrado en una ventana de chat, por bueno que sea, depende de ti para cada acción. Uno con acceso a tu sistema puede actuar.
Esa es la diferencia que más impacto tiene en mi productividad hoy. No el modelo, sino el nivel de acceso.
Si todavía usas IA solo en formato chat, prueba una de estas herramientas en un proyecto real. No tienes que cambiar todo tu flujo de un día para otro. Empieza con una tarea concreta: una refactorización, montar un proyecto nuevo, añadir tests a un módulo existente. Ahí es donde la diferencia se siente de verdad.
Cuando lo pruebes, fíjate en una cosa: la cantidad de veces que no necesitas copiar y pegar nada.
Ese es el indicador más claro de que algo ha cambiado.