Cuando hace no mucho tiempo aparecieron los primeros modelos de Inteligencia Artificial, hablar de IA y programación era más o menos imaginar a un developer frente a su editor de código, con un copiloto de IA al lado. Poco más. El programador escribía una función, la IA proponía otra, se corregía un error y se generaba algún test...Pero ahora todo eso está cambiando por completo.
La siguiente generación no consiste en tener un agente de IA que programa contigo, sino en tener varios agentes trabajando simultáneamente en un mismo proyecto, o lo que se ha venido a llamar en el argot de nuestro sector "agent swarms", que son básicamente equipos de agentes de inteligencia artificial.
La idea es bastante sencilla de entender. En lugar de pedir a una única IA que te lo haga todo, lo que ahora podemos hacer es dividir un mismo proyecto en diferentes responsabilidades, donde dentro de una misma tarea un agente concreto puede encargarse de analizar los requisitos necesarios, otro puede hacer ocuparse del backend, otro del frontend, otro de las pruebas, y al final otro diferente que se encarga de revisar el código al 100%. Incluso puede existir un agente "coordinador" que distribuya todo el trabajo y decida qué hacer después.
La diferencia respecto al tradicional asistente de programación "de toda la vida" es enorme, porque en este esquema de más arriba, la IA deja de ser una herramienta que simplemente espera nuestras instrucciones y empieza a ser básicamente un equipo completo de trabajo digital capaz de hacer y coordinar casi todo.
Uno de los experimentos más impresionantes al respecto publicados hace poco fue el que hizo Cursor, que estuvo experimentando con este método de agent swarms para trabajar en proyectos de software de gran complejidad.
En una de sus pruebas, el sistema recibió la documentación de SQLite (835 páginas!) y tuvo que construir desde cero una versión en Rust, sin acceso al código fuente de SQLite ni a sus tests.
De lo que se consiguió con el experimento, lo más interesante no fue que se consiguiera avanzar en el proyecto en si mismo, sino la manera o el método en que se hizo. Básicamente, el sistema utilizaba agentes planificadores, generalmente apoyados por modelos más potentes, que dividían el problema en tareas. Después, otros agentes trabajadores, más rápidos y mucho más baratos, ejecutaban esas tareas previamente marcadas.
Es una idea muy parecida a la estructura de un equipo humano tradicional, pero traspasado a la IA...En equipos humanos, también alguien diseña la estrategia y también otras personas ejecutan diferentes partes del trabajo, pero hay una diferencia bastante importante, y es que en el contexto de la IA, una máquina no necesita dormir.
Y además hay otro problema, y es que poner a 100 programadores en una habitación a trabajar no multiplica por 100 la productividad, porque si tenemos a cien o a doscientos agentes trabajando al mismo tiempo, también tenemos cien o doscientas posibilidades de que dos agentes modifiquen el mismo archivo, tomen decisiones incompatibles o hagan exactamente el mismo trabajo. La coordinación básicamente se convierte en el verdadero problema porque al final está el factor humano.
Cursor llegó a experimentar con sistemas capaces de alcanzar alrededor de mil commits por segundo. A esa escala, las herramientas tradicionales de control de versiones dejan de estar pensadas para lo que está ocurriendo.
Por eso los agent swarms están obligando a replantear algo que los desarrolladores damos por sentadoo, y es simplemente la manera en que colaboran los propios agentes sobre el código. Porque ya no basta con escribir código rápidamente sino que hay que saber quién puede modificar qué, cómo se resuelven los conflictos y cómo se transmite el conocimiento entre agentes.
Y otro dato que también es interesante es que no todos los agentes necesitan ser igual de inteligentes, algo de lo que Cursor se dio cuenta al comprobar que utilizar un modelo muy potente para absolutamente todas las tareas resultaba mucho más caro que reservarlo para las decisiones realmente difíciles y utilizar modelos más rápidos y económicos para ejecutar el trabajo, como hemos descrito anteriormente. En una de las configuraciones analizadas, el coste total llegó a variar desde unos 1.500 dólares hasta más de 10.500 dólares, dependiendo de la combinación de modelos.
La lógica es bastante clara, y es que un arquitecto puede necesitar mucha capacidad de técnica para decidir cómo construir una aplicación, pero una vez tomada una decisión concreta, quizá no tenga sentido utilizar el modelo más caro para generar cien pequeños cambios perfectamente definidos. Es exactamente la misma razón por la que una empresa no necesita que su director general escriba personalmente cada línea de código.
El nuevo cuello de botella no será escribir código, y aquí es donde está probablemente la conclusión más importante de todo este asunto. Con los agentes de IA, esa relación empieza a invertirse y empezamos a ver qué el código puede producirse muchísimo más rápido. Lo escaso pasa a ser algo muy diferente, que es básicamente definir bien qué es exactamente lo que queremos construir.
Una especificación que genere confusión o no esté clara puede provocar que diez agentes trabajen durante horas en la dirección equivocada, y al mismo tiempo una buena especificación puede permitir que esos mismos agentes avancen de forma coordinada, por eso el prompt empieza a quedarse pequeño como concepto y el futuro apunta hacia algo más parecido a una especificación de producto que los agentes puedan interpretar, dividir, ejecutar y validar.
Todo esto por supuesto no significa que los programadores van a desaparecer, pero sí que va a cambiar profundamente el trabajo de nuestros equipos.
El developer del futuro tendrá menos protagonismo como "persona que escribe cada línea" y más como arquitecto, supervisor y responsable de las decisiones técnicas.
Tendrá que saber dividir problemas, establecer límites para los agentes, revisar resultados y detectar cuándo una solución aparentemente correcta está tomando un camino equivocado.
La evolución de esto no tiene freno y ya hay muchos investigadores estudiando incluso agentes capaces de mejorar sus propias herramientas, memoria, habilidades y formas de colaboración a partir de experiencias anteriores.
Frente a todo este nuevo escenario, desde luego es impresionante imaginar cómo será un equipo de desarrollo cuando cada desarrollador tenga detrás a decenas de agentes trabajando en paralelo...Lo que sí parece claro es que estamos pasando de una primera etapa en la que la IA nos ayuda a escribir código, a otra mucho más ambiciosa donde es la propia IA quien organiza y ejecuta partes enteras del proceso de desarrollo de software. Todo esto, para las empresas que construyen aplicaciones, productos digitales y plataformas, es un cambio que puede ser mucho más importante de lo que podíamos prever, porque todo indica que el próximo gran salto de productividad no consistirá en tener un programador con una buena IA sino en tener un programador dirigiendo un equipo de IA.
Top comments (0)