Desarrollo de software en la era agéntica

El IDE bajo presión

Durante décadas, el IDE fue el motor silencioso del desarrollo de software. Su propuesta de valor era clara: la integración ahorra tiempo. La combinación de un editor de texto, un compilador, un depurador y un sistema de control de versiones en una única interfaz gráfica convirtió a herramientas como Eclipse, IntelliJ y VS Code (con su ecosistema de extensiones) en el eje central de la jornada de trabajo de los desarrolladores. Pero a medida que la definición de "desarrollo" se amplió para incluir la contenedorización, los despliegues nativos de la nube y la integración profunda de la IA, el IDE ha comenzado a flaquear en su integralidad e indispensabilidad.

La principal queja de los ingenieros sénior es el consumo de recursos. Un IDE moderno, cargado con extensiones para cada marco de trabajo de la pila de un proyecto, puede requerir cientos de megabytes de RAM; en algunas configuraciones, se ha informado que solo los complementos de IA elevan el uso de la CPU por encima del 500%. Esa sobrecarga resulta cada vez más difícil de justificar cuando la IA realiza la mayor parte del trabajo generativo.

Si un agente genera varios cientos de líneas de código bien estructurado a partir de un "simple" prompt, el desarrollador ya no necesita (o tal vez poco) esa compleja barra de opciones que caracteriza la experiencia dentro de un IDE. Al igual que un escritor —analogía que hacía mi colega en nuestra conversación— que se da cuenta de que, hace meses, poco ha tenido que recurrir a la barra de herramientas de formato de textos porque una IA se encarga del diseño, los desarrolladores están descubriendo que un editor de código básico es suficiente para la revisión final antes de publicar el código.

_____

⚠️ Nota: Sabemos que algunas personas podrían argumentar que VS Code, por ejemplo, no es un IDE por defecto, sino que se convierte en uno al instalar extensiones. Por lo tanto, podemos pensar en un IDE como un marco que incluye una serie de herramientas preinstaladas para facilitar la edición, la revisión y el despliegue de código.

_____

Más allá del uso excesivo de recursos, existe un problema de diseño fundamental: los IDE actuales tratan a la IA como un elemento secundario: una barra lateral, una ventana de chat, un complemento añadido a una interfaz diseñada décadas antes de que existieran los LLMs. Este enfoque no aprovecha todo el potencial de los flujos de trabajo de los agentes. Cuando una IA es capaz de depurar, refactorizar y explicar sistemas completos de forma autónoma, confinarla a un rincón de la pantalla se percibe como una restricción del pasado. Hemos visto que el verdadero desarrollo nativo de IA requiere que el entorno se estructure en torno al agente y no al revés.

El regreso de la terminal

La terminal, de forma algo inesperada, ha reclamado su papel como centro de mando para el desarrollo de alta velocidad. Herramientas como Claude Code, Aider y la CLI de Gemini han demostrado que, en flujos de trabajo con agentes, una CLI (interfaz de línea de comandos) suele ser superior a una GUI (interfaz gráfica de usuario). Tres propiedades explican por qué.

Primero, la capacidad de composición (composability) nativa de texto. La filosofía Unix, en la que la salida de un programa se convierte en la entrada de otro, es el lenguaje nativo de los LLM. Un agente de CLI puede encontrar todos los archivos TypeScript, filtrar por un import específico y ejecutar un script de reemplazo mediante un comando de shell, sin necesidad de integraciones complejas de API.

Segundo, la gestión progresiva del contexto. Uno de los mayores desafíos en el desarrollo asistido por IA es la contaminación del contexto. En un IDE, los agentes a menudo ingieren todo el árbol de archivos o los esquemas persistentes en la ventana de contexto, lo cual resulta costoso en tokens y distrae al modelo. Las herramientas de CLI tratan el contexto como un recurso escaso; utilizan búsquedas dirigidas para encontrar archivos relevantes, leen solo lo que necesitan y gestionan la ventana de contexto con precisión.

Tercero, los bucles de retroalimentación binarios. Los agentes autónomos necesitan señales claras para autocorregirse. En una CLI, un comando finaliza con 0 o 1; esto permite que un agente ejecute una prueba, observe el fallo en 'stderr' (flujo de salida preconectado usado por los programas informáticos para mostrar mensajes de error o diagnósticos) e itere sobre una solución sin intervención humana. Replicar este bucle en una GUI es significativamente más complejo y propenso a la fricción.

Nada de esto significa que la terminal gane en todas partes. Los agentes de CLI destacan en tareas paralelas, automatización e integración de CI/CD; los IDE "agénticos" (basados en agentes) como Cursor y Windsurf conservan ventajas claras para la depuración visual, el onboarding y el trabajo de frontend, donde ver el resultado renderizado importa. La cuestión no es tanto qué herramienta es universalmente mejor, sino qué herramienta se adapta a la tarea en cuestión.

Mi colega, por ejemplo, dice que el valor principal que le aporta una herramienta como Zed es el 'diff'. Podría usar el comando git diff en la terminal o una de las muchas herramientas especializadas diseñadas para mostrar fácilmente los cambios antes y después en un repositorio para su revisión (p.ej., GitKraken o VS Code con su vista de Git y extensiones como GitLens). Sin embargo, dice que recurre a Zed porque también le ofrece una forma cómoda de explorar la base de código justo en el momento en que el agente de IA la está editando; puede navegar por la estructura de archivos y buscar modificaciones específicas con facilidad.

Tres paradigmas, no uno

El desarrollo asistido por IA abarca actualmente tres enfoques distintos. Estas distinciones importan porque definen cómo se gestionan la autonomía, el contexto y la colaboración.

Los IDE agénticos amplían las funciones de los editores tradicionales mediante capacidades de inteligencia artificial. Ofrecen sugerencias en línea, generación de código y automatización limitada en varios pasos, pero siguen operando dentro de las restricciones de un único espacio de trabajo y de un operador humano principal.

Los agentes de CLI dependen de comandos "componibles" (composable), del acceso al sistema de archivos y de la automatización. Son particularmente efectivos en flujos de trabajo programados, como los pipelines de CI, la respuesta a incidentes y el mantenimiento repetitivo.

Los entornos de desarrollo agénticos (ADE) van más allá al situar la orquestación en el centro. A diferencia de un IDE derivado que añade funciones de IA, un ADE se construye desde cero para la coordinación de agentes. Los componentes clave incluyen el aislamiento del espacio de trabajo mediante worktrees de Git separados (herramientas como Warp y Antigravity de Google usan este patrón para que varios agentes trabajen en diferentes ramas sin contaminar el sistema de archivos), una superficie de gestión que reemplaza el editor de código con un tablero para generar y monitorear agentes, y motores de contexto semántico que utilizan indexación consciente de dependencias para que, cuando un agente modifique una librería compartida, el sistema comprenda los efectos dominó en toda la arquitectura. En un ADE, el sistema mismo se convierte en la interfaz principal; el desarrollador interactúa con un plano de control en lugar de una sola herramienta.

De conductor a orquestador

La industria ha adoptado una nueva terminología para describir la evolución del papel del desarrollador: primero un codificador, luego un "conductor" y ahora un "orquestador".

Un conductor o director trabaja estrechamente con un solo agente de IA enfocado en una tarea dentro de un bucle de retroalimentación síncrono y estrecho, aprobando o ajustando cada sugerencia. Este es el modelo de "programador en pareja con IA", al que ya se le atribuyen ganancias de productividad del 25-30%. Es efectivo para la implementación a nivel micro, pero sigue siendo lineal.

Un orquestador, por su parte, supervisa a múltiples agentes de IA que trabajan en paralelo. En este paradigma, un ingeniero podría asignar tareas de backend a un agente, actualizaciones de frontend a otro y la generación de pruebas a un tercero. El desarrollador define objetivos de alto nivel, resuelve conflictos entre agentes y revisa las solicitudes de extracción (pull requests, PRs) resultantes. El flujo de trabajo se vuelve asíncrono: para cuando el desarrollador revisa, varios PRs ya están listos para su evaluación.

Como observó Karpathy, cofundador de OpenAI, los bits aportados directamente por el programador se están volviendo escasos. El nuevo nivel programable implica la gestión de subagentes, prompts, memoria y permisos.

Ejecutar múltiples agentes en paralelo plantea desafíos reales. Las tareas deben estar aisladas para evitar conflictos, típicamente mediante espacios de trabajo o ramas separadas. Sin dicho aislamiento, las modificaciones concurrentes pueden interferir entre sí, lo que conduce a resultados inconsistentes. La gestión del contexto se vuelve crítica: los agentes necesitan acceso a información relevante sin verse abrumados por el ruido, y los sistemas avanzados abordan esto organizando el contexto en capas que combinan conocimiento persistente, datos específicos de la tarea y restricciones de tiempo de ejecución.

Adicionalmente, los modelos de permisos deben ser granulares, abarcando desde el acceso de solo lectura hasta acciones que requieren aprobación humana explícita. Los flujos de trabajo con intervención humana (human-in-the-loop) son esenciales en los puntos de decisión de alto impacto. Y es que existen casos documentados que muestran que los agentes autónomos pueden provocar cambios destructivos cuando se mantienen sin supervisión.

Volviendo a la experiencia concreta de mi colega, me compartió detalles sobre su espacio de trabajo actual: utiliza el enfoque de "multi-clauding", es decir, ejecuta Claude Code en múltiples terminales, asignando diferentes tareas a cada una para ejecutarlas en sus propios espacios de trabajo de Git (worktrees).

Así, los agentes de IA trabajan (documentando su razonamiento y sus modificaciones), validan los cambios con linters, envían el código (donde se ejecutan linters adicionales mediante Git Hooks) y, una vez en GitLab, el pipeline de CI comienza a ejecutarse. Si falla, David informa del error a los agentes para que puedan entender el problema e iterar.

En última instancia, es él quien revisa los cambios en el repositorio y decide si son aceptables o requieren mejoras. Del mismo modo, es él quien define cuándo abrir la merge request (MR, donde tiene lugar la revisión por pares) y quien asume la responsabilidad de las modificaciones realizadas por los agentes; al final del día, esos commits quedan registrados a su nombre.

En el caso de David, Zed, el editor de código, se convierte en una ventana a los mundos paralelos de los agentes, permitiéndole revisar cómodamente el 'diff' y explorar la base de código en un punto específico del historial del desarrollo de software para comprenderla y evaluarla.

¿CLI vs. MCP?

En el ecosistema agéntico, a ratos se hace alusión a un debate referente a las CLIs frente a los servidores MCP (Model Context Protocol). Sin embargo, plantearlo como una elección de uno u otro parece perder de vista el punto de su complementariedad.

Las CLI ofrecen ventajas claras cuando las herramientas involucradas ya están bien representadas en los datos de entrenamiento. Utilidades como 'git', 'curl' y 'grep' (utilidades de línea de comandos empleadas para el control de versiones, la transferencia de datos y el procesamiento de texto, respectivamente) pueden invocarse con un contexto adicional mínimo y los agentes pueden acceder a la documentación de ayuda progresivamente en lugar de cargar todas las definiciones de herramientas por adelantado. Sin embargo, estas ventajas disminuyen al utilizar herramientas personalizadas o API propietarias, en las que los agentes requieren instrucciones detalladas que anulan cualquier ahorro de tokens.

Los servidores MCP abordan un conjunto distinto de problemas. Al centralizar herramientas y API detrás de un protocolo estandarizado, simplifican la autenticación (las claves de API sensibles permanecen en el servidor; los desarrolladores se autentican vía OAuth), mejoran la auditabilidad (cada llamada a una herramienta por parte de un agente es registrada y rastreable) y permiten la entrega dinámica de conocimiento (las organizaciones pueden enviar mejores prácticas y documentación actualizadas a los agentes en todo el equipo a través de un único punto de acceso). También garantizan la coherencia: los prompts, recursos y definiciones de las herramientas pueden actualizarse centralmente para que cada usuario interactúe con la versión más reciente.

En la práctica, las CLI sobresalen en el "bucle interno" (inner loop), donde la velocidad y la flexibilidad son lo más importante; los servidores MCP son más efectivos en el "bucle externo" (outer loop), donde el acceso estructurado a la infraestructura compartida es la prioridad. Los dos son capas complementarias en un ecosistema en maduración.

Las habilidades y principios que importan ahora

En caso de que los agentes de IA estén escribiendo, digamos, el 90% del código, ¿qué quedará para el ingeniero? Y es que incluso se dice que el valor de ser un "políglota de lenguajes" está disminuyendo. Las habilidades diferenciales para los desarrolladores en la actualidad parecen centrarse en tres áreas:

• Descomposición de problemas: dividir requisitos de negocio complejos en tareas bien definidas que un agente de IA pueda manejar con facilidad.

• Arquitectura de sistemas: tomar decisiones de alto nivel sobre stack tecnológico, interacciones entre componentes y servicios, y escalabilidad.

• Verificación y calibración de confianza: desarrollar el juicio para saber cuándo se puede confiar en los outputs de un agente y cuándo es necesario intervenir manualmente.

Las organizaciones se enfrentan a retos paralelos: integrar la IA en arquitecturas heredadas, por ejemplo, que nunca se diseñaron para albergarla, a menudo requiere una reingeniería significativa; un código base monolítico con dependencias estrechamente entrelazadas puede que no siempre se preste a la descomposición de tareas que exigen los flujos de trabajo basados en agentes. Además, los cuellos de botella que ayer eran aceptables ya no son tolerables hoy en día, dado el ritmo de trabajo que permiten estos flujos de trabajo basados en agentes. Por lo tanto, es necesario replantear la planificación, la priorización y el mantenimiento de las rutas por las que fluyen todos los cambios hacia los repositorios de código para mantenerlas libres de congestión.

La calidad de los datos, las fallas de razonamiento y las preocupaciones sobre la propiedad intelectual añaden otra capa de complejidad. Los sistemas de IA dependen de datos de entrenamiento que pueden introducir sesgos o llevar a la replicación no intencionada de contenido protegido. Abordar sabiamente estas problemáticas requiere marcos de gobernanza, transparencia y evaluación continua, en lugar de auditorías puntuales.

La dimensión de la fuerza laboral es igualmente importante: los desarrolladores necesitan nuevas competencias para interpretar el comportamiento de los LLMs, evaluar los resultados de manera crítica e integrar la IA en flujos de trabajo preestablecidos. El aprendizaje continuo se convierte en un prerrequisito, no en un beneficio extra, y la brecha entre los equipos que invierten en esto y los que no, se ampliará rápidamente.

El ciclo de vida continuo y sus implicaciones de seguridad

Hay quienes dicen que otro de los cambios importantes introducidos por el desarrollo agéntico es el colapso de las etapas tradicionales del SDLC (ciclo de vida de desarrollo de software). Los límites entre desarrollo, pruebas y producción parecen desdibujarse. El código se genera, prueba, despliega y reemplaza en ciclos rápidos; los entornos se parecen cada vez más a producción incluso durante el desarrollo, con feature flags y "despliegues canarios" como práctica estándar. Los entornos de desarrollo no desaparecen, pero su papel cambia de etapas claramente definidas a espacios para la experimentación controlada dentro de un flujo unificado y continuo.

Esta continuidad tiene consecuencias directas para la seguridad de los sistemas en desarrollo. Los puntos de control tradicionales, como "escanear antes del lanzamiento", pierden relevancia cuando los lanzamientos se producen de forma continua. La validación del código y las evaluaciones de seguridad de las aplicaciones en funcionamiento deben seguir al mismo ritmo. El concepto mismo de una "puerta de preproducción" asume un límite claro entre desarrollo y producción, y ese límite parece disolverse.

El desarrollo basado en agentes también amplía la superficie de ataque de ciertas maneras. Las aplicaciones se están volviendo más distribuidas, las API proliferan, y los modelos de IA están integrados tanto en los entornos de desarrollo como en los de ejecución. Nuevas interfaces, como el chat y la voz, introducen categorías de vulnerabilidades completamente nuevas que no tienen equivalente en las aplicaciones web tradicionales. Los agentes que ejecutan comandos, acceden a sistemas y modifican infraestructura exigen un aislamiento fuerte, control de permisos y auditabilidad. La combinación de ejecuciones autónomas y acceso amplio a los sistemas crea perfiles de riesgo que la mayoría de las herramientas de seguridad existentes no fueron diseñadas para abordar.

En Fluid Attacks, queremos reiterar un principio que merece mantenerse presente hoy: la responsabilidad de la seguridad no se transfiere al agente. El código generado por IA, por muy limpio que sea sintácticamente, aún puede presentar fallas lógicas o ser vulnerable en un entorno real. El análisis estático, incluso potenciado por IA, solo lee el código fuente; no puede detectar vulnerabilidades que surgen durante el tiempo de ejecución, como middleware mal configurado, integraciones de servicios defectuosas o problemas de autenticación que solo se manifiestan cuando el sistema está ensamblado y procesando entradas del mundo real.

Comprender la seguridad en las aplicaciones modernas requiere observar cómo se comportan bajo condiciones realistas, incluyendo cómo podrían analizarlas los atacantes. En la práctica, muchas de las vulnerabilidades más trascendentales no surgen de lo que dice el código, sino de cómo interactúa este con todo lo que lo rodea.

Para adoptar herramientas agénticas de forma segura, las organizaciones deberían implementar

• sandboxing: los agentes deben ejecutarse en contenedores aislados para evitar que comandos alucinados lleguen al host;

• protecciones de permisos: imponiendo listas de permitir/denegar a nivel de shell para que los agentes no puedan acceder a archivos de credenciales o escalar privilegios, y

• ASPM como sistema de registro: una plataforma de gestión de la postura de seguridad de aplicaciones que converja los hallazgos de los escaneos de IA, pruebas automatizadas y pentesting manual en un conjunto de datos gobernados, proporcionando continuidad incluso cuando las herramientas de creación se vuelven transitorias.

Lo que viene después

Aunque aún quedan algunos detalles por resolver, la tendencia es clara: la IA se está convirtiendo en un componente estructural del desarrollo de software, y no solo en un factor que impulsa la productividad. Los desarrolladores aportan el contexto, el criterio y la supervisión; los agentes se encargan de la ejecución y la automatización.

La asociación tiene un potencial real para elevar tanto la eficiencia como la calidad, pero el éxito depende de mantener el equilibrio. La dependencia excesiva de la IA introduce riesgos que se acumulan silenciosamente: degradación de la coherencia arquitectónica, puntos ciegos de seguridad al confiar en la salida del agente sin una verificación adecuada y una erosión gradual de la intuición técnica profunda que solo proviene de trabajar cerca del código base (close to the metal). Por otro lado, una integración insuficiente deja a los equipos compitiendo contra organizaciones que ya han descubierto cómo multiplicar su capacidad de ingeniería.

El ciclo de vida del desarrollo de software ya no es una secuencia de etapas discretas; se ha convertido en un sistema continuo y superpuesto en el que los límites entre escribir, probar, desplegar y asegurar el código se funden en un solo flujo. Navegar ese flujo requiere tratar el desarrollo, las operaciones y la seguridad como una disciplina unificada en lugar de silos adyacentes.

Las organizaciones que lo hagan bien no serán las que adopten más herramientas o desplieguen más agentes. Serán aquellas que comprendan el sistema en su totalidad, reconociendo dónde el juicio humano es insustituible, dónde la automatización reduce realmente el riesgo en lugar de simplemente desplazarlo, y dónde las ganancias de velocidad de los flujos de trabajo agénticos están ancladas a una supervisión de seguridad rigurosa que mantiene esos sistemas confiables una vez que llegan a producción.

En el contexto actual del desarrollo de software, ya no nos define el código que escribimos; somos arquitectos de sistemas autónomos, y la disciplina de ingeniería necesaria para garantizar su seguridad y fiabilidad es la misma que siempre ha distinguido a la construcción reflexiva de la construcción apresurada y descuidada.