Codificación de disparo y olvido: El auge de los agentes en segundo plano en 2026

La semana pasada le di un ticket a un agente, cerré el portátil y me fui a comer. Cuando volví había un pull request esperando — tests en verde, un resumen breve, un diff que tocaba once archivos. Funcionó. Lo fusioné.

Los otros tres que desplegué esa mañana no fueron tan bien. Uno borró silenciosamente un feature flag porque "no se referenciaba" (sí se hacía, desde un archivo de configuración que el agente nunca llegó a leer). Uno quemó unos cuantos dólares redescubriendo que nuestra suite de tests necesita un contenedor de base de datos que no podía iniciar. Uno produjo un diff tan plausible y tan equivocado que casi lo apruebo desde la pantalla del móvil.

Esa es la forma honesta que tienen los agentes en segundo plano en 2026. La buena ejecución se siente como hacer trampa. Las malas se sienten como gestionar a un junior que trabaja a las 3 de la mañana, nunca hace preguntas y tiene muchísima confianza.

Versión corta: los agentes en segundo plano han resuelto básicamente el problema de "escribir código mientras no estoy mirando." Lo que no han resuelto — lo que se podría argumentar que han empeorado — es la revisión. El cuello de botella se ha desplazado. Antes era lo rápido que un modelo podía escribir. Ahora es lo rápido que tú puedes leer, confiar y fusionar el trabajo que no viste generarse. Si no construyes un proceso para eso, no obtienes un multiplicador de fuerza; obtienes una acumulación de PRs a medio hornear.

Qué significa "agente en segundo plano" ahora mismo

Un agente en segundo plano es un agente de codificación asíncrono que se ejecuta en algún lugar fuera de tu atención principal — normalmente una VM en la nube — hace la tarea y te entrega un resultado más tarde. Asignas el trabajo y te vas. Ese es todo el argumento de venta, y a mediados de 2026 todos los grandes harnesses incluyen alguna versión de esto.

Cursor reconstruyó completamente su interfaz alrededor de esto en la versión 3.0. La nota de lanzamiento es directa sobre el nuevo centro de gravedad: puedes "ejecutar muchos agentes en paralelo en repositorios y entornos: localmente, en worktrees, en la nube y en SSH remoto" (cursor.com/changelog/3-0). Sus agentes en la nube se ejecutan en sandboxes, "iteran hasta que han validado su output," y convierten issues de Linear o Jira directamente en PRs (cursor.com/cloud). La lectura de Futurum sobre el seguimiento 3.2 llamó al IDE "reenmarcado como un runtime de ejecución de agentes" (futurumgroup.com) — cercano al marketing, pero direccionalmente cierto.

Claude Code fue por el mismo camino pero mantuvo el vocabulario preciso. Su documentación distingue cuatro formas de paralelizar: subagentes (trabajadores delegados dentro de una sesión), agent view (claude agents — "despachar y monitorear sesiones ejecutándose en segundo plano," una vista previa de investigación), agent teams (un líder coordinando trabajadores, "experimental y desactivado por defecto"), y dynamic workflows (un script que despliega en abanico muchos subagentes y los verifica cruzadamente) (code.claude.com/docs/en/agents). Los cuatro no son intercambiables, y los nombres están haciendo un trabajo real.

Devin, que prácticamente inició esta categoría, pasó 2026 convirtiendo un agente autónomo en muchos. Su lanzamiento del 19 de marzo añadió "Devin Manages Devins" — una sesión coordinadora que delimita el trabajo y delega a "un equipo de Devins gestionados que trabajan en paralelo," cada uno en su propia VM aislada (docs.devin.ai/release-notes/2026).

El hilo común: entorno aislado, entrega asíncrona, PR al final. Las diferencias están en cuánta cuerda obtienes y cómo aterriza la revisión de vuelta en ti.

En qué son genuinamente buenos

Sé específico sobre dónde esto vale la pena, porque el hype lo aplana todo.

Los agentes en segundo plano son buenos en trabajo acotado, bien especificado y verificable. El punto óptimo es una tarea donde (a) puedes describir "hecho" en una frase, (b) un test o un verificador de tipos puede probarlo, y (c) no requiere criterio. Actualizaciones de dependencias con una suite que pasa. Añadir un campo a través de un stack conocido. Escribir los tests unitarios obvios. Refactorizaciones mecánicas en muchos archivos — el tipo de cosa para la que está construida la habilidad /batch de Claude Code, dividiendo "un cambio grande en 5 a 30 subagentes aislados en worktrees que cada uno abre un pull request" (code.claude.com/docs/en/agents).

Son buenos en amplitud en paralelo. El /best-of-n de Cursor ejecuta la misma tarea en múltiples modelos, "cada uno en su propio worktree aislado, luego compara los resultados" (cursor.com/changelog/3-0). Para un bug complicado donde genuinamente no sabes el enfoque correcto, lanzar tres intentos y quedarte con el mejor es un uso real de poder ejecutar cosas que no estás mirando.

Y son buenos en dejar que una persona haga más de una cosa a la vez. Como constructor en solitario, la limitación nunca fueron las ideas — es que solo puedo estar en un archivo a la vez. Despachar la mitad aburrida mientras hago la mitad interesante es la victoria real. No "la IA construye mi app" — eso sigue siendo una fantasía. "La IA limpia mi acumulación de cosas pequeñas y obvias mientras pienso" es algo que se puede enviar hoy.

En qué son malos, honestamente

Los modos de fallo no son exóticos. Son aburridos y se repiten.

Inanición de contexto. Un agente en segundo plano solo sabe lo que recopiló antes de comenzar a ejecutarse. No puede hacerte una pregunta de aclaración a mitad de ejecución — o si puede, estás comiendo. Así que adivina. Mi incidente del-feature-flag-borrado fue pura inanición de contexto: el agente razonó correctamente sobre los archivos que tenía y llegó a una conclusión equivocada porque el hecho relevante vivía en algún lugar que nunca miró. La solución está al principio: mejor encuadre de la tarea, un AGENTS.md que le diga dónde viven las cosas, enlaces al issue. Basura dentro, basura confiada afuera.

Deriva silenciosa. El fallo aterrador no es el PR que está obviamente roto — ese lo captarás. Es el que es 90% correcto y sutilmente equivocado, con un resumen limpio que describe el comportamiento correcto mientras el diff hace otra cosa. El resumen se genera desde la intención, no desde lo que el código hace. Confía en el diff, no en la descripción.

Conflictos de fusión y pisarse unos a otros. Ejecuta seis agentes contra un repositorio y colisionarán. La respuesta de toda la industria es el aislamiento de worktree — cada agente obtiene su propio checkout de git para que las sesiones en paralelo "nunca editen los mismos archivos" (code.claude.com/docs/en/agents). Eso resuelve los agentes peleando durante la ejecución. No hace nada con respecto a seis ramas que aterrizan en main el martes por la tarde, cada una ligeramente obsoleta. El conflicto simplemente se mueve al momento de la fusión, lo que equivale a decir que se mueve a ti. Devin lanzó la detección de conflictos de fusión en la revisión en febrero precisamente porque aquí es donde el sueño paralelo se encuentra con la realidad (docs.devin.ai/release-notes/2026).

Coste descontrolado. Async significa que nadie vigila el contador. Los agentes en segundo plano se apoyan en los modelos más caros, y una comparación honesta midió un "PR fácil" en el agente en segundo plano de Cursor en torno a $4.63 durante la vista previa (aitechfy.com). Eso está bien para un ticket real y es absurdo para una errata. Los costes "se vuelven impredecibles en trabajo novedoso," y el gasto por tarea "permanece opaco a menos que compruebes el panel de uso" (techsy.io). La propia documentación de Anthropic lo dice claramente: ejecutar varios agentes a la vez "multiplica el uso de tokens" (code.claude.com/docs/en/agents). Establece límites de gasto antes de disparar y olvidar, no después de la factura.

El cuello de botella real es la revisión, y ahora es tuyo

Aquí está la parte que los demos omiten. Cuando la generación era el paso lento, la revisión era gratuita — veías el código aparecer línea a línea y lo aprobabas según llegaba. Los agentes en segundo plano rompen eso. El código aparece mientras estás fuera. Ahora eres un revisor del trabajo que no viste, con el volumen de los agentes que despachaste.

Los proveedores claramente lo saben, porque el envío más interesante de 2026 no fue en generación — fue en revisión. Devin lanzó todo un producto de revisión en enero que agrupa cambios relacionados, "detecta código copiado, bugs y problemas de seguridad," y añadió fusión automática y un botón "Auto-fix with Devin" en abril (docs.devin.ai/release-notes/2026). Eso te dice dónde está el dolor.

Pero ten cuidado con lo que deseas. La misma comparación que puso precio a estas herramientas también señala que "todos los equipos que conocemos requieren revisión humana antes de fusionar" y llama a la fusión automática "un arma de fuego apuntada al pie" (techsy.io). Estoy de acuerdo. El punto de un agente revisando a otro agente es clasificar tu cola — señalar las tres PRs que necesitan tus ojos y aprobar con sello de goma las dos aburridas — no eliminarte a ti. El día que dejes que un agente apruebe el trabajo de otro agente en main sin supervisión es el día que has automatizado la producción de bugs sutiles.

Así que la habilidad que realmente importa en 2026 no es el prompting. Es gestionar una cola de revisión sin ahogarse. Concretamente:

• Clasifica antes de leer. Señal barata y mecánica primero: ¿pasaron los tests, pasó el verificador de tipos, es pequeño el diff? Un PR que falla su propia puerta no ha ganado tu atención todavía.
• Lee el diff, nunca el resumen. El resumen es la intención del agente. El diff es lo que ocurre. Divergen silenciosamente.
• Haz que "hecho" sea demostrable. Si no puedes escribir una verificación que confirme la tarea, no tienes una tarea para agente en segundo plano — tienes algo que vigilarás de todas formas. Empuja la verificación a la ejecución del agente para que se auto-pruebe; los agentes en la nube de Cursor "iteran hasta que han validado su output" (cursor.com/cloud), y esa puerta vale más que cualquier ajuste de prompt.
• Limita la profundidad de la cola. Más agentes no es más output más allá del punto en que puedes revisar. Si las PRs aterrizan más rápido de lo que las resuelves, has construido un generador de atrasos, no un multiplicador de fuerza.

Un día en la vida que realmente funciona

Aquí está el bucle que ejecuto como constructor en solitario. Es mundano a propósito.

Por la mañana: clasifico mi propia lista de issues en dos categorías — apropiadas para agentes (acotadas, comprobables, aburridas) y apropiadas para mí (juicio, arquitectura, cualquier cosa que toque dinero o autenticación). Despacho tres o cuatro tickets apropiados para agentes, cada uno en su propio worktree o sandbox en la nube, con una descripción real y un enlace al issue. Luego cierro esa ventana y voy a trabajar en un problema apropiado para mí mismo, en primer plano, a la manera tradicional.

No me siento a mirarlos. El punto entero es lo asíncrono. Mirar un agente en segundo plano es simplemente un agente síncrono con pasos adicionales y una vista peor.

A media mañana, las PRs empiezan a aterrizar. Ejecuto el pase de clasificación: estado de la puerta primero, luego diffs pequeños antes que grandes. Las dos que pasaron limpiamente y tocan diez líneas, las leo y fusiono en cinco minutos cada una. La que "tuvo éxito" pero reescribió más de lo esperado, la leo con cuidado — ahí es donde se esconde la deriva. La que falló sus propios tests, o la reencuadro con el nuevo contexto y la redespacho, o la bajo a local y termino a mano. Un agente quemando cuarenta minutos en un entorno de tests roto solo me está diciendo que mi configuración es el problema; lo arreglo una vez y la siguiente ejecución es limpia.

Fusiono ramas de agentes de una en una, haciendo rebase sobre la marcha, no en un lote al final del día — así es como evitas el amontonamiento de conflictos del martes por la tarde. Y mantengo una regla rígida: nada relacionado con autenticación, facturación o migraciones sale de una ejecución en segundo plano sin que yo lea cada línea. No es apropiado para mí porque sea difícil. Es apropiado para mí porque el radio de explosión es grande y el agente no siente la consecuencia.

Resultado neto del día: quizás seis tickets cerrados donde habría hecho dos. No porque los agentes sean listos — algunos de esos PRs fueron retrabajo — sino porque la mitad aburrida se resolvió en paralelo mientras yo gasté mi atención real en la mitad que necesitaba a un humano.

La perspectiva equilibrada

Los agentes en segundo plano son reales, funcionan, y el bucle de VM-en-paralelo-en-la-nube-a-PR funciona lo suficientemente bien como para cambiar cómo un constructor en solitario pasa el día. Eso no es hype. Lo que es hype es el "y entonces ya no tienes que hacer nada" implícito. Sí tienes que hacerlo. El trabajo simplemente cambió de forma — de escribir código a especificarlo, controlarlo y revisarlo.

Trátalos como un equipo junior rápido que trabaja mientras duermes y produce una pila de PRs para la mañana: algunas excelentes, algunas silenciosamente equivocadas, todas confiadas. La recompensa es real si construyes el músculo de revisión para igualar la generación. Si te saltas eso, no te has comprado un equipo. Te has comprado una cola.

Empieza con un agente, un ticket acotado, una definición demostrable de hecho. Haz que el bucle de clasificación funcione en profundidad uno antes de desplegarte a cuatro. La generación nunca iba a ser la parte difícil.