Ahora el código lo escriben los agentes. Esto es en lo que se ha convertido el oficio del desarrollador.

La pregunta sale en todas las mesas donde alguien tiene un desarrollador en la familia: si la máquina escribe el código, ¿qué queda?

La respuesta honesta es que la pregunta apunta a la parte equivocada del oficio. Escribir código nunca fue todo el oficio. Era la parte visible, la que parecía trabajo para cualquiera que pasara por delante de la mesa. Y era también, casi todas las semanas, la más pequeña.

Lo que se ha automatizado nunca fue todo el oficio

Todo lo que llega a producción pasa por seis eslabones:

1. Alguien quiere algo, y lo explica mal.
2. Alguien decide que merece la pena, y cuándo.
3. Alguien lo convierte en una descripción lo bastante precisa como para actuar sobre ella.
4. Alguien lo construye.
5. Alguien comprueba que no ha roto otra cosa.
6. Alguien lo publica y avisa a quien lo pidió.

Los agentes se han llevado el eslabón cuatro. Se lo han llevado de forma convincente, y van a seguir mejorando en él. Lo que casi nadie dice en voz alta es lo que eso les hace a los otros cinco: los vuelve más pesados, no más ligeros.

La razón es el caudal. Cuando construir costaba dos semanas, los cinco eslabones de alrededor tenían dos semanas para ocurrir. Eran lentos porque el centro era lento, y nadie se daba cuenta de que eran lentos. Cuando construir cuesta una tarde, todo lo demás se convierte en el cuello de botella, de golpe.

Un eslabón se ha hundido. Los otros cinco cargan ahora con el peso que ese eslabón escondía.

Esa es toda la historia, y el resto de este artículo es qué aspecto tiene cada uno de los cinco cuando te toca hacerlo de verdad todos los días.

Eslabón 1: escuchar qué construir, sin perder la mitad por el camino

El nuevo modo de fallo es concreto y es caro: puedes construir cualquier cosa, así que construyes lo que no toca más rápido.

Las peticiones llegan de todas partes. Un mensaje en un hilo de soporte. Una frase al final de una llamada. Una queja en una red social. Un reporte de bug que en realidad es una petición de funcionalidad disfrazada. Históricamente daba bastante igual, porque de todos modos solo podías construir una cosa cada dos semanas, y la evidente solía ser la correcta. Ahora que puedes construir cinco cosas por semana, la diferencia entre las cinco correctas y las cinco equivocadas es la mayor parte de tu año.

Tienen que pasar dos cosas, y son cosas distintas.

Primero, recoger tiene que salirle barato a quien pide. Si un usuario tiene que crear una cuenta, buscar un formulario y describir el problema dos veces, la mayoría no se molestará, y los que sí lo hagan no son una muestra representativa. Un tablero público de feedback donde cualquiera puede dejar una petición, adjuntar una captura y seguir qué pasa con ella elimina ese roce. La gente que usa el producto escribe las peticiones ella misma, con sus palabras y con el contexto adjunto.

Segundo, ordenar tiene que ser automático, porque el feedback en bruto no sigue siendo útil mucho tiempo. Veinte mensajes que dicen más o menos lo mismo parecen veinte problemas hasta que alguien lee los veinte y ve que son uno. Ese es justo el trabajo para el que nadie tiene tiempo. Idea Radar es nuestra respuesta: las señales en bruto aterrizan intactas, se agrupan solas en temas, los duplicados se emparejan antes de convertirse en dos construcciones, y cada idea lleva el número de personas distintas que la han pedido. El texto literal no se reescribe nunca, porque las palabras exactas que usó alguien son el dato.

Lo que sale de este eslabón no es un backlog. Es un corpus que se puede leer.

Eslabón 2: decidir, que es ahora el recurso escaso

Un tablero de ideas no es un plan. Convertir el uno en el otro es el juicio que antes se repartía a lo largo de un trimestre y que ahora tiene que ocurrir cada semana.

Aquí importan dos movimientos.

Promover es deliberado. Una idea se convierte en ticket del backlog cuando alguien decide que merece la pena construirla, no cuando se deja escrita. Todo lo demás sigue visible en el radar con su número de peticionarios, que es el estado honesto de las cosas: escuchado, no programado. Los backlogs donde el ochenta por ciento de las líneas no se construirá jamás no son planes, son archivos con una maquetación engañosa.

El acotado ocurre antes de construir, no durante. Un feedback difuso se convierte en una maqueta validada que quien lo pidió puede mirar y confirmar. Cinco minutos de confirmación ganan a una tarde construyendo la pantalla equivocada, y ese trato mejoró muchísimo el día en que aquella tarde de construcción pasó a ser una tarde de tiempo de agente que podrías haber dedicado a otra cosa.

Eslabón 3: el encargo, el oficio que ha sustituido al tecleo

Aquí es donde se ha ido la destreza de verdad.

Un agente no discute una instrucción ambigua como haría un colega. No va a decir «espera, ¿cuál de los dos flujos de pago?». Rellena el hueco con una suposición plausible y te entrega algo coherente y equivocado. El coste de la ambigüedad antes era una conversación. Ahora es un diff.

Lo que separa a quien obtiene buenos resultados de quien se pelea con sus agentes todo el día no es el ingenio con los prompts. Es el contexto reutilizable. Cuatro tipos, en orden decreciente de lo que devuelven.

Contexto que los agentes leen antes de explorar. Archivos de convenciones versionados (CLAUDE.md, AGENTS.md) y una memoria de proyecto que guarda las decisiones de arquitectura, las trampas del pasado y el motivo por el que las cosas son como son. Se escribe una vez, lo lee cada agente en cada máquina, para siempre. Es la escritura que más rinde de todas las que hace hoy un desarrollador, y casi nadie le reserva tiempo.

Procedimientos, guardados como procedimientos. La décima vez que explicas tu lista de comprobación de publicación no estás redactando un encargo, estás volviendo a teclear. Una biblioteca de skills convierte un procedimiento recurrente en algo que un agente carga cuando la tarea encaja, y una biblioteca de prompts hace lo mismo con los encargos en sí.

Enseñar en vez de describir. Un párrafo que describe un botón mal alineado es peor que una imagen del botón mal alineado. Envía una región de la pantalla directamente, o dibuja encima para señalar aquello de lo que hablas. Para una página web, darle al agente el DOM en vivo gana a describirlo, siempre.

Hablar en vez de teclear. Un encargo hablado de tres frases lleva más matiz que la única frase que te habrías molestado en escribir. Dictado por voz para una instrucción rápida, modo de voz cuando quieres el ida y vuelta sin tocar el teclado. Esto suena a comodidad. En la práctica es ancho de banda: la gente dice más de lo que escribe, y a los agentes los limita lo que les cuentas.

Las tres primeras se pagan en cada tarea. La cuarta se paga una vez y se cobra para siempre.

Eslabón 4: pilotar el trabajo, en la máquina adecuada

Un agente es una herramienta. Varios agentes son un sistema, y los sistemas necesitan un operador.

Las preguntas prácticas no tienen ningún glamur, y son el oficio. ¿Qué puede correr en paralelo sin que dos agentes editen el mismo módulo? ¿Qué tarea merece tu atención mientras corre y cuál no? ¿Qué debería estar corriendo mientras duermes?

Esa última decide dónde se ejecuta el trabajo. Todo lo que puedas necesitar interrumpir, corregir o reconducir sobre la marcha se queda en la máquina que tienes delante. El trabajo largo, bien especificado y sin ambigüedad se va a otro sitio: otra máquina tuya o un servidor por SSH, para que un trabajo de dos horas no te secuestre el portátil. El trabajo recurrente se va a tareas programadas. La pregunta que decide no es nunca la potencia bruta, es cuántas probabilidades hay de que tengas que intervenir.

Cuando un trabajo tiene etapas que de verdad son distintas, un solo agente es la forma equivocada. Una construcción que hay que probar y después revisar son tres trabajos con tres oficios distintos, y los equipos de agentes te dejan dibujar ese relevo de forma explícita en lugar de volver a explicar el contexto en cada paso.

Y como nada de esto exige que estés ahí sentado, pilotarlo desde el móvil deja de ser una curiosidad. Leer la pregunta de un agente y contestarla en veinte segundos desde el tren es la diferencia entre una tarea que terminó y una tarea que te estuvo esperando cuatro horas.

Eslabón 5: revisar, que es donde vive la responsabilidad

Este es el eslabón que no se delega, y el motivo no es técnico.

Los agentes ya han sustituido la mayor parte de la lectura línea a línea. Lo que no pueden llevarse es la firma. La responsabilidad no se transfiere a un modelo. Cuando una migración borra una columna en producción, «lo escribió el agente» no es una frase que acepte nadie, y está bien que sea así.

Lo que cambia es la forma de la revisión, no su existencia. Leer cada línea no sobrevive al contacto con cinco agentes corriendo en paralelo, y un humano que hojea un diff de novecientas líneas a las seis de la tarde produce una firma sin producir conocimiento. La política que aguanta es revisar en proporción al radio de explosión: los textos y los estilos se hojean, mientras que la autenticación, los pagos, los permisos, los datos personales y las migraciones se leen línea a línea, siempre, y las lee alguien que podría haberlas escrito.

Dos cosas hacen que eso sea practicable. Poder ver un diff por agente en lugar de un montón fusionado te dice quién cambió qué cuando tres de ellos han trabajado en el mismo repositorio. Y adjuntar la conversación al commit responde a la pregunta que de verdad cuesta tiempo seis meses después, que no es nunca «qué cambió» sino «por qué».

Para cualquier cosa con interfaz, la comprobación no se para en el diff. Un agente que maneja un navegador de verdad puede recorrer el flujo que acaba de construir y contar lo que ha visto, y eso caza la clase de bug que se lee perfectamente bien en el código fuente.

Le hemos dedicado un artículo entero a dónde gastar esa atención: si todavía hay que revisar el código de tu agente de IA.

Eslabón 6: publicar, y cerrar el círculo

Publicar es la mitad fácil de este eslabón. La mitad que se salta todo el mundo es avisar a quien lo pidió.

Y es también la que más devuelve. Un usuario que reporta algo y más tarde se entera de que ha salido reporta lo siguiente. Un usuario que reporta contra el silencio deja de reportar, y pierdes la materia que alimentaba el eslabón uno. Cuando se cierra un ticket que nació de una petición pública, quien la dejó debería enterarse sin que nadie tenga que acordarse de mandar un correo.

Antes de eso suele haber alguien que necesita verlo funcionar y no tiene tu entorno de desarrollo: un cliente, un diseñador, un compañero en otro continente. Una URL HTTPS pública que apunta a tu máquina local convierte eso en un enlace en lugar de en un despliegue, y el feedback que vuelve entra directo en el eslabón uno.

La cadena se cierra. Eso es lo que hace que sea un oficio y no una cola.

Lo que ha encogido de verdad, y lo que ha crecido de verdad

Lee esa tabla con honestidad y la ansiedad cambia de forma. Las partes que han encogido son las que era más fácil cubrir contratando. Las que han crecido son las que necesitan a alguien que entienda el sistema, a los usuarios y las consecuencias. Eso es un oficio más difícil, no un oficio más pequeño, y es bastante menos solitario que la versión en la que tecleabas todo el día.

Dónde encaja AgentsRoom en todo esto

Construimos la herramienta que sostiene la cadena entera, porque la alternativa son seis herramientas que no saben la una de la otra.

Eso significa que las peticiones aterrizan en un tablero, se ordenan solas en ideas, se promueven a tickets, se acotan hasta convertirse en algo que un agente no puede malinterpretar, las ejecuta un agente o un equipo de ellos en tu máquina o en una remota, se revisan por agente con la conversación adjunta, y se cierran avisando a quien lo pidió. Una ventana, un único sitio donde el estado del trabajo es verdad.

Las piezas sueltas existen en otros sitios. Lo que nadie estaba publicando son las conexiones entre ellas, y las conexiones son justo por donde se escapa el trabajo.

Las preguntas que hace la gente

¿La IA va a sustituir a los desarrolladores?

Ha sustituido el tecleo, no el oficio. Escribir código es un eslabón de una cadena que también contiene escuchar lo que necesitan los usuarios, decidir qué merece la pena construir, especificarlo con precisión, pilotar el trabajo, comprobarlo y publicarlo. Los agentes han hundido el coste de un eslabón, y eso ha convertido a los otros cinco en el cuello de botella. Menos gente cobrará por producir líneas. Cada vez más gente cobra por decidir qué líneas deben existir y por responder de ellas una vez están en producción.

¿Qué hace de verdad un desarrollador cuando el código lo escriben los agentes?

Seis cosas, y solo una de ellas se veía antes en una pantalla llena de código. Recoges lo que pide la gente, decides qué merece la pena construir y en qué orden, redactas el encargo con la precisión suficiente para que un agente no pueda malinterpretarlo, llevas varios trabajos a la vez sin perder el hilo, revisas en proporción a lo que cada cambio puede romper, y publicas y avisas a quien lo pidió. El oficio se ha desplazado de producir el cambio a especificarlo y responder de él.

¿Hace falta seguir sabiendo programar?

Sí, y más que antes para leer. Ya no necesitas recordar la sintaxis de un lenguaje que tocas dos veces al año, porque la escribe el agente. Sí necesitas abrir un diff y saber en segundos si una migración es reversible, si se ha movido un control de autenticación, si una consulta aguantará diez veces el tráfico. Quien no sabe leer código no puede revisar a un agente, y quien no puede revisar a un agente no lo está pilotando: solo está confiando en que salga bien.

¿Qué es lo primero que se rompe cuando le pasas el código a los agentes?

La priorización. Cuando construir cuesta una tarde en lugar de dos semanas, el coste de construir lo que no toca desaparece de la vista, así que se construye. Los equipos acaban con más funcionalidades publicadas y ni un problema más resuelto. Lo segundo que se rompe es el circuito de feedback: las peticiones de los usuarios llegan más rápido de lo que nadie puede ordenarlas, así que se acumulan en hilos de chat y se pierden, y la misma petición se construye dos veces porque nadie se dio cuenta de que era la misma.

¿Qué es lo más difícil de esta nueva forma de trabajar?

Redactar un encargo que un agente no pueda malinterpretar. Un agente no discute una instrucción ambigua como haría un colega, así que rellena los huecos con una suposición plausible y entrega algo coherente y equivocado. Quien obtiene buenos resultados no es quien tiene prompts ingeniosos, es quien mantiene contexto reutilizable en su sitio: archivos de convenciones versionados, un procedimiento guardado por cada tarea recurrente, una memoria de proyecto que los agentes leen antes de explorar, y capturas o bocetos en lugar de párrafos que describen una pantalla.

¿Los agentes de código deben ejecutarse en tu máquina o en una remota?

En las dos, y se elige tarea por tarea. Todo lo que quieras mirar, interrumpir o corregir sobre la marcha se queda en la máquina que tienes delante. El trabajo largo, bien especificado y sin ambigüedad se va a otra máquina tuya o a un servidor por SSH, para que un trabajo de dos horas no te secuestre el portátil. La pregunta que decide no es la potencia, es cuántas probabilidades hay de que tengas que intervenir.

La versión corta

El oficio no ha desaparecido. Se ha salido del editor para instalarse en la cadena que lo rodea.

Si solo vas a cambiar una cosa este mes, elige el eslabón uno. Todo lo que hay aguas abajo es esfuerzo desperdiciado cuando apunta al problema equivocado, y es el único eslabón donde una hora de tu atención sigue ganando a una hora de tiempo de agente por un factor que nadie sabe medir.