Cómo funcionan los agentes de IA para programar y qué conviene saber sobre ellos

El programador de 2025 escribe cada vez menos código desde cero. Formula la tarea, lanza un agente de IA y observa cómo genera decenas de archivos, refactoriza la arquitectura e incluso ejecuta pruebas. Herramientas como Cursor, GitHub Copilot Workspace, Devin y Claude Code han pasado en el último año de experimentos exóticos a ser parte del día a día de cientos de miles de desarrolladores. Pero pocos usuarios entienden de verdad qué ocurre bajo el capó. Ars Technica ha publicado un análisis detallado de la mecánica interna de los agentes de IA para programación, y sus conclusiones merecen la atención de cualquiera que confíe a una máquina aunque sea una parte de su trabajo.

La base de cualquier agente de programación es un gran modelo de lenguaje, ya sea GPT-4o, Claude 3.5 Sonnet o Gemini. Pero el modelo por sí solo es apenas el motor.

El agente es toda una estructura de ingeniería a su alrededor. El primer problema, y quizá el más crítico, que resuelven los desarrolladores de agentes es el límite de la ventana de contexto. Incluso en los modelos más avanzados es finita: 128 o 200 mil tokens suena impresionante, pero un proyecto de software real puede contener millones de líneas de código.

Los agentes lo resuelven con una serie de trucos: indexan la base de código, construyen mapas semánticos del repositorio, extraen solo los fragmentos relevantes y comprimen el contexto descartando lo que el modelo ya ha «procesado». En esencia, el agente hace de bibliotecario astuto que le acerca al modelo justo los libros que necesita para responder una pregunta concreta, en lugar de volcar toda la biblioteca sobre la mesa.

El segundo mecanismo clave son las cadenas de razonamiento, o chain-of-thought. En vez de generar la respuesta de una vez, el agente divide una tarea compleja en pasos sucesivos. Primero analiza la estructura del proyecto, luego formula un plan de cambios, después implementa cada paso, comprueba el resultado y, si hace falta, corrige el rumbo.

No es un simple recurso de estilo: las investigaciones muestran que el razonamiento paso a paso reduce de forma radical los errores en tareas complejas. Algunos agentes van más allá y usan una arquitectura multiagente: un modelo actúa de «arquitecto» y descompone la tarea, otro escribe el código, un tercero se encarga de la revisión y un cuarto de las pruebas. Se comunican mediante prompts estructurados e imitan el trabajo de un equipo real de desarrolladores.

Así está construido Devin, de Cognition, y varios otros sistemas avanzados.

Pero tras las demostraciones impresionantes se esconden limitaciones serias que conviene recordar. La principal son las alucinaciones. Un agente puede usar con total seguridad una API inexistente, llamar a funciones con argumentos incorrectos o crear código que parece impecable pero contiene errores lógicos sutiles. El problema se agrava porque los agentes actúan de forma autónoma: si un autocompletado clásico, como el primer Copilot, sugería una sola línea que el desarrollador evaluaba al instante, un agente moderno puede generar cientos de líneas en una decena de archivos. Revisar semejante volumen a mano no es trivial, y la tentación de pulsar «aceptar todo» es grande.

La seguridad es un quebradero de cabeza aparte. Distintos estudios ya han documentado casos en que agentes de IA introdujeron vulnerabilidades en el código, desde inyecciones SQL hasta un tratamiento inseguro de la entrada del usuario. El modelo optimiza el código para que «funcione», no para que sea «seguro», y sin un requisito explícito de seguridad puede elegir el camino más simple pero inseguro. Para los equipos que trabajan con datos sensibles o sistemas financieros, esto no es un riesgo abstracto, sino una amenaza concreta.

Hay también un efecto más sutil que la industria apenas empieza a reconocer. Cuando un desarrollador se apoya en un agente para escribir una parte considerable del código, va perdiendo poco a poco el conocimiento profundo de su propia base de código. El código escrito por una máquina suele resultar ajeno al estilo del equipo, usa patrones poco habituales y cuesta más depurarlo. Surge una paradoja: la herramienta pensada para acelerar el desarrollo puede ralentizar el mantenimiento del producto a largo plazo.

Nada de esto significa que haya que renunciar a los agentes de IA. Aceleran de verdad las tareas rutinarias, ayudan a dominar frameworks desconocidos y reducen la barrera de entrada a la programación. Pero conviene tratarlos como a un becario muy capaz pero sin experiencia: puede hacer mucho, aunque cada resultado requiere la revisión de un compañero sénior.

Entender cómo toma decisiones un agente —cómo comprime el contexto, cómo divide una tarea, dónde tiene sus puntos ciegos— deja de ser una curiosidad académica y se convierte en una habilidad práctica. En un mundo donde los agentes de IA escriben cada vez más código, dominar su mecánica será una competencia tan básica para un desarrollador como saber usar Git o leer logs.