Herramientas de código agéntico con IA, sin el caos

"Agéntico" es la palabra que el sector ha adoptado para las herramientas de código con IA que hacen más que autocompletar. Una herramienta agéntica no solo sugiere la siguiente línea: toma un objetivo, planifica una secuencia de pasos, edita archivos, ejecuta comandos, lee los resultados y continúa hasta que se cumple el objetivo o se atasca.

La diferencia práctica es la autonomía a lo largo del tiempo. Una herramienta de autocompletado te ayuda a escribir. Un agente trabaja mientras haces otra cosa: puede pasar diez minutos o una hora convirtiendo una descripción de trabajo en una rama, un diff y, a menudo, una pull request.

Ese cambio — de asistir tu escritura a hacerse cargo de una tarea — es lo que hace interesante la categoría, y también lo que la hace difícil de gestionar. En el momento en que una herramienta puede trabajar sin supervisión, la pregunta pasa de "¿es buena esta sugerencia?" a "¿era esta la tarea correcta, hecha de la forma correcta?"

Las herramientas de código agéntico se dividen a grandes rasgos en tres formas, y la mayoría de configuraciones serias las combinan. Algunos ejemplos de cada una, sin un orden particular:

La línea entre estas formas se está difuminando: las herramientas CLI ahora también lanzan sesiones en la nube — claude --cloud entrega una tarea desde tu terminal a Claude Code on the web. [2] Los agentes en la nube como el de Cursor ejecutan cada tarea en una VM aislada y te permiten correr muchos en paralelo. [1] Los productos en este espacio cambian de nombre a menudo, así que comprueba la documentación actual de cada proveedor. Nuestra guía sobre Cursor background agents trata en profundidad un ejemplo de agente en la nube.

Pregúntale a cualquiera que haya usado agentes de código durante un mes qué es lo que falla, y escucharás la misma lista corta. El agente resuelve un problema ligeramente distinto al que pretendías. Toca archivos fuera del alcance previsto — como la pull request de 400 líneas que reescribió el flujo de restablecimiento de contraseña cuando el arreglo era una errata en un mensaje de error. [4] Dos agentes en paralelo en un mismo checkout se sobrescriben archivos entre sí o razonan sobre cambios a medio terminar. [3] Y, en nuestra propia experiencia, a veces un agente "termina" debilitando un test en lugar de arreglar el código.

Nada de esto es un fallo del modelo en el sentido tradicional. Son fallos de especificación. Un agente es extremadamente bueno haciendo exactamente lo que la tarea implica — y despiadadamente literal con los vacíos. Una entrada vaga no produce un resultado vago; produce uno confiado, plausible y equivocado.

Este es el cuello de botella del que nadie te avisa: una vez que los agentes pueden correr en paralelo, tu rendimiento queda limitado por lo rápido que puedas escribir buenas tareas y revisar lo que devuelven. Los agentes rara vez son la parte lenta. Tú lo eres.

La solución no es un prompt mejor escrito más rápido. Es tratar la descripción de la tarea como un artefacto en el que vale la pena invertir — igual que los buenos equipos tratan un ticket bien escrito.

Una story bien acotada da a un agente tres cosas que un prompt simple normalmente no da: una definición clara de "hecho", límites explícitos sobre lo que no debe tocarse, y suficiente contexto sobre el sistema circundante para que no reinvente convenciones que ya existen. Los equipos que planifican en Linear ya tienen el hábito y el lugar para esto. Más en nuestra guía de stories para agentes de código.

El beneficio se multiplica con el paralelismo. Un agente con una tarea vaga desperdicia diez minutos. Diez agentes con tareas vagas desperdician esos mismos diez minutos diez veces, y te dejan diez diffs que desenredar. Diez agentes con stories precisas se comportan como un equipo que ha leído el mismo brief — siempre que las stories no se solapen.

Ejecutar agentes en paralelo es hacia donde va la categoría, y eso cambia el flujo de trabajo de nuevo. Dejas de trabajar en pareja con un agente y empiezas a supervisar una flota: poner trabajo en cola, comprobar el estado, desbloquear a los que se atascan, y revisar resultados por lotes.

El punto anterior que más duele en la práctica es la visibilidad. En cuanto llevas más de un par de agentes en la nube en marcha, la pregunta "¿qué está haciendo cada uno, y para qué issue?" se come tu día. La vista Agents de Aerunit la responde en un solo lugar: una lista única de cada sesión de Cursor Cloud Agent en marcha, cada una vinculada a su issue de Linear. Puedes enviar mensajes a varias sesiones a la vez, archivar las terminadas, y las sesiones salen de la lista cuando su issue está hecho.

Aerunit funciona actualmente con Cursor Cloud Agents. Detrás de la lista, también escribe las stories — leyendo cada repositorio que una story toca antes de escribirla — y arranca el siguiente issue en cuanto su bloqueador se fusiona, para que la flota siga ocupada sin que tengas que lanzarla a mano.