Las mejoras de productividad que ofrece la IA agéntica son cada vez más difíciles de negar. Dale a un agente de programación capaz una solicitud clara, contexto suficiente y un código base con fundamentos sólidos, y podrá producir una enorme cantidad de trabajo útil. La experiencia amplifica esa ventaja: la seniority ayuda a definir el problema, reconocer una solución plausible, detectar riesgos ocultos y saber qué merece una inspección más profunda.
Sin embargo, mi primera reacción a esta nueva forma de trabajar no fue completamente positiva. Por momentos me sentía menos como un desarrollador y más como un revisor esperando que otra persona terminara.
El ciclo era simple: escribir una solicitud, esperar al agente, inspeccionar el resultado y luego aceptarlo o pedir otra iteración. Comparado con el ritmo continuo de escribir código por mi cuenta, ese ciclo contenía extraños espacios vacíos. El agente estaba trabajando, pero yo no. Había eliminado un cuello de botella y, sin querer, había convertido mi propia atención en capacidad ociosa.
La pregunta más interesante, entonces, no es solo cuánto más rápido puede ayudarnos un agente a programar. Es cómo deben cambiar los desarrolladores cuando programar se vuelve asíncrono.
Cuando la implementación se vuelve asíncrona, el rol del desarrollador se expande desde la ejecución hacia la orquestación.
La espera es un problema de flujo de trabajo
Nuestros hábitos anteriores fueron moldeados por la ejecución directa. Manteníamos un problema en la cabeza, escribíamos código, lo ejecutábamos, observábamos el resultado y repetíamos. El ciclo de retroalimentación mantenía nuestra atención ocupada casi de forma continua.
Un agente rompe ese ritmo. Una vez delegada una tarea, puede que no haya nada útil que hacer en esa misma tarea hasta que llegue el resultado. Mirar fijamente la terminal no hace que termine antes. Llenar ese espacio con redes sociales tampoco mejora el proyecto.
Mi error inicial fue conservar una mentalidad síncrona alrededor de una herramienta asíncrona. Usaba al agente como si fuera un par de manos más rápidas conectadas a mi propio cerebro. Un mejor modelo mental es un equipo pequeño o, quizás, un sistema con varios procesos en ejecución. Mientras un flujo implementa un componente, otro puede investigar una integración, mejorar la documentación, escribir pruebas o explorar un proyecto independiente.
Ahí es donde el paralelismo comienza a importar.
De programador a planificador
Los procesadores modernos logran un rendimiento extraordinario, en parte, al mantener múltiples operaciones en curso en vez de esperar que cada una termine antes de iniciar la siguiente. El desarrollo agéntico invita a un cambio similar en la forma de organizar nuestro trabajo.
La analogía es útil, pero imperfecta. La atención humana no es un núcleo de CPU. Cambiar de contexto tiene un costo real. Olvidamos supuestos, perdemos la forma del problema y necesitamos tiempo para reconstruir por qué una decisión era importante. Ejecutar diez agentes a la vez puede crear diez flujos de resultados, pero también puede crear una cola de revisión lo bastante grande como para sepultar al desarrollador responsable.
El objetivo no es llevar la multitarea al máximo. Es lograr concurrencia controlada.
El trabajo paralelo solo genera rendimiento cuando los flujos se mantienen independientes y la revisión sigue siendo deliberada.
Para mí, eso significa mantener en movimiento una cantidad pequeña de flujos de trabajo independientes y hacer que cada uno sea fácil de retomar. Una tarea útil tiene un objetivo claro, un área acotada del código, un resultado esperado y una forma de verificarlo. Cuando faltan esas condiciones, el trabajo paralelo tiende a producir colisiones, esfuerzos duplicados o cambios que parecen razonables de manera aislada, pero no encajan entre sí.
El desarrollador se convierte progresivamente en un planificador:
- Decide qué trabajo puede realizarse en paralelo de forma segura.
- Entrega a cada tarea contexto suficiente para avanzar de manera independiente.
- Conserva el estado y la intención de cada flujo.
- Revisa los resultados según su riesgo, no solo según su volumen.
- Integra las piezas en un sistema coherente.
Esto sigue siendo ingeniería. El trabajo simplemente subió de nivel.
La seniority no desaparece; cambia dónde genera valor
La IA agéntica es útil en muchos niveles de experiencia, pero contar con fundamentos sólidos vuelve sus resultados mucho más valiosos. Un desarrollador senior normalmente puede describir límites con mayor claridad, identificar qué tareas son independientes, anticipar modos de falla y cuestionar una respuesta que solo parece convincente.
Ese último punto importa. Aceptar código generado porque compila no equivale a entender si pertenece al sistema. Un agente puede acelerar la implementación, pero no elimina la responsabilidad sobre la arquitectura, la seguridad, la mantenibilidad o la intención del producto.
De hecho, una generación más rápida puede volver el criterio todavía más importante. Cuando producir código era costoso, la velocidad de implementación solía ser el factor limitante. Cuando el código se vuelve barato, decidir qué debería existir y validar que se comporte correctamente se convierte en el recurso escaso.
Por lo tanto, la seniority no es una ventaja mágica para escribir prompts. Es el apalancamiento construido a partir de modelos mentales: saber cómo fallan los sistemas, qué atajos se vuelven permanentes, qué probar y cuándo una solicitud está resolviendo el problema equivocado.
La mente necesita un nuevo tipo de entrenamiento
Trabajar de esta manera requiere flexibilidad mental, pero no creo que la respuesta sea entrenarnos para sostener una cantidad ilimitada de tareas. Eso confundiría estar ocupado con tener un buen desempeño.
La habilidad más útil es recuperar el contexto de manera rápida y confiable. Antes de cambiar de tarea, necesito dejar un punto de control compacto: qué intentamos lograr, qué se decidió, qué sigue siendo incierto y qué resultado espero a continuación. Cuando regrese, ese punto debería restaurar las partes importantes del problema sin obligarme a reconstruirlo todo desde la memoria.
Los límites adecuados también importan. Dos agentes que editan el mismo módulo central no están trabajando realmente en paralelo si luego hay que desenredar sus cambios. Las funcionalidades independientes, la investigación, las pruebas, la documentación y las correcciones aisladas son mejores candidatas. El paralelismo funciona mejor cuando las tareas comparten un destino, pero no una zona de colisión.
También estoy aprendiendo a ajustar la profundidad de revisión al riesgo. Un cambio de texto y una migración de base de datos no merecen el mismo nivel de escrutinio. Tampoco las pruebas generadas y la lógica de autenticación. Si cada resultado recibe una revisión rápida y superficial, el paralelismo solo nos ayuda a producir errores más rápido.
Un ritmo práctico
Esta es la parte que quiero convertir en hábito. La recuerdo con seis verbos: dividir, iniciar, cambiar, guardar, revisar y limitar.
- Dividir: separar el trabajo en resultados que puedan verificarse de manera independiente.
- Iniciar: lanzar solo una o dos tareas de agente, cada una con límites y criterios de aceptación claros.
- Cambiar: usar el tiempo de espera en una tarea realmente independiente, no en otro cambio dentro de la misma área frágil.
- Guardar: antes de cambiar de contexto, registrar el objetivo, las decisiones, las preguntas abiertas y el próximo resultado esperado.
- Revisar: comprender el trabajo terminado antes de iniciar otro flujo.
- Limitar: mantener la cantidad de tareas abiertas lo bastante baja como para seguir entendiendo el sistema completo.
La regla es simple: mantén una o dos tareas independientes en curso, deja un punto de control antes de cada cambio y revisa el resultado antes de crear más trabajo.
Esto es menos emocionante que lanzar una flota de agentes, pero es más sostenible. El propósito del paralelismo no es maximizar la cantidad de código generado. Es acortar el tiempo entre una idea y un resultado confiable.
La próxima brecha de rendimiento
Creo que la IA agéntica puede generar enormes mejoras, especialmente para desarrolladores con fundamentos técnicos sólidos. Pero la herramienta por sí sola no hará que todos sean igual de productivos. La diferencia puede depender cada vez más de qué tan bien descomponemos el trabajo, comunicamos la intención, gestionamos varios hilos asíncronos y aplicamos criterio cuando llegan los resultados.
En esta etapa del desarrollo de la IA, un desarrollador de alto rendimiento podría parecerse menos a la persona más rápida frente al teclado y más a alguien que dirige un sistema de ingeniería pequeño y disciplinado. Sabe cuándo delegar, cuándo mantener el foco, cuándo cambiar y cuándo dejar de crear trabajo nuevo hasta haber comprendido el existente.
Todavía estoy entrenando esa parte de mi cerebro. Los incómodos espacios de espera no demostraban que el agente me hubiera quitado el trabajo. Eran una señal de que mi antiguo flujo ya no coincidía con la velocidad ni con la forma de las nuevas herramientas.
El siguiente paso no es aprender a escribir más rápido. Es aprender a dirigir.