Este artículo nace de una conversación. El 29 de octubre por la noche, al volver del gimnasio, me puse a debatir por voz con Leonardo, mi asistente de IA en Grok Bot, sobre cómo está cambiando mi oficio. Salieron muchas cosas, pero hubo una idea que me dejó pensando más que el resto, por qué planificamos cómo planificamos. Y la respuesta corta es por dinero.
Construir ya no es lo caro
Durante años, construir software fue caro. Cada funcionalidad eran semanas o meses de varias personas, y lo que una empresa quería, con toda la razón, era certidumbre sobre lo que iba a costar. De ahí vienen las estimaciones, los roadmaps, la planificación por sprints y buena parte de las ceremonias. Todo eso sirve para lo mismo: saber cuánto vas a gastar antes de gastarlo. Pero ahora desarrollar con IA es mucho más barato. Y cuando construir deja de ser lo caro, el modelo cambia. Pasamos de planificar a experimentar.
De planificar a experimentar: cuando construir deja de ser lo caro, cambia la pregunta.
Fíjate en lo que implica eso. Si antes la pregunta era «¿cuánto nos va a costar construir esto?», ahora es «¿merece la pena probarlo?». Una variante que antes llenaba un sprint puede estar lista en una tarde, así que lo razonable ya no es discutir durante semanas si una idea es buena, sino ponerla delante de los usuarios y ver qué pasa.
Aquí tengo que ser honesto: no tengo métricas que demuestren que vamos más rápido, y las que hay no me lo ponen fácil. Un estudio controlado de METR de 2025 encontró que los desarrolladores experimentados tardaban un 19 % más con IA. Sin embargo, en una actualización de febrero de 2026, sus propios autores explicaron que ese resultado inicial había quedado desfasado y que sus nuevos experimentos sufrieron fuertes sesgos de selección, ya que muchos desarrolladores se negaban directamente a trabajar sin herramientas de IA. Todo apunta a que hoy el impacto real es distinto y probablemente positivo en velocidad, aunque resulta cada vez más difícil de medir con métodos tradicionales. Lo que sí tengo claro es que el coste de desarrollo baja. Y mi impresión, aunque no la pueda medir, es que tener varios agentes trabajando en paralelo nos hace ir más rápido. Hay algo que también es evidente: un prototipo no es lo mismo que llevar algo a producción. Lo que se abarata de verdad es probar; lo que se queda en producción sigue pidiendo el cuidado de siempre.
Hay otro matiz clave: barato no significa gratis. Las herramientas cuestan, alguien tiene que revisar lo que generan y, sobre todo, está el coste real del desarrollo con IA frente a los precios subvencionados. Las suscripciones actuales difieren enormemente de las tarifas por API a escala. Aunque Anthropic o OpenAI modifiquen sus planes y límites, en grandes empresas el coste se traslada directamente al uso real. La cuestión central no es si hoy parece barato a nivel individual, sino si esta estructura económica sostiene el modelo de experimentación continua a gran escala. No tengo la respuesta cerrada, y creo que nadie la tiene todavía. Pero incluso con esa duda, la dirección me parece clara.
Un equipo en dos círculos
Si el modelo es experimentar, el equipo no puede organizarse igual que cuando el modelo era planificar. En mi opinión, se debe reorganizar en dos círculos. En el primero están los stakeholders, producto, el diseñador, el manager y los ingenieros más seniors. Su trabajo es decidir qué merece la pena probar, formular la hipótesis, elegir la métrica que debería moverse y dejar escrito por qué. En el segundo está el resto del equipo, que es el que ejecuta: convierte esa hipótesis en un cambio en producción, ahora con agentes que escriben buena parte del código, y lo entrega preparado para medirse.
Los dos círculos: uno decide qué probar y por qué; el otro lo ejecuta con agentes y devuelve un resultado medible.
Entre ambos círculos no se comparte una lista de tareas, sino una hipótesis explicada. Para ello, se utilizan los registros de decisiones: notas breves con el contexto, la decisión elegida y sus consecuencias. A cambio, lo que regresa es un resultado medible. La clave del modelo es evaluar al equipo por el impacto real del experimento.
¿Y cómo pasa una hipótesis de un círculo al otro sin quedarse esperando? Desde luego, no con sprints. Si una tarea pasa de un círculo a otro constantemente, pierden su sentido. Los sprints nacieron para ofrecer previsibilidad cuando programar era costoso; hoy en día, hacer que un cambio ya terminado espere al final de la iteración solo frena el aprendizaje. Lo que conviene es apostar por un flujo de entrega continua mediante un tablero donde cada hipótesis avance a su ritmo, limitando el trabajo en curso para evitar acumular experimentos a medias. Esto no va en contra de Agile, sino que vuelve a su esencia: el Manifiesto Ágil prioriza responder al cambio antes que seguir un plan. Las reuniones no desaparecen, pero cambian su propósito: ahora sirven para alinearse sobre qué probar y dejar documentado el motivo.
Sé que esta forma de trabajar va a recibir críticas, y conviene tomarlas en serio. Habrá quien diga: Separar un círculo que decide de otro que ejecuta suena a waterfall encubierto. La objeción tiene sentido, pero creo que confunde la forma con el fondo. Un waterfall tiene un objetivo final fijado de antemano, y lo que desarrolla es un plan de trabajo para llegar hasta él. Aquí no hay un objetivo final cerrado ni un plan que cumplir. Lo que pasa del primer círculo al segundo es una hipótesis, y lo que buscamos al probarla es aprender. Así que el segundo círculo no recibe órdenes: recibe una hipótesis y decide el camino para probarla. Experimentas, mides, y lo que aprendes se convierte en el conocimiento que decide el siguiente paso. Si el experimento sale mal, ese paso no es el que estaba escrito, sino el que te dicen los datos. Un waterfall no tiene vuelta. Este modelo es, precisamente, la vuelta.
Waterfall sigue un plan fijo, Scrum itera sobre un plan sprint a sprint y el ciclo de experimentos deja que la métrica decida el siguiente paso.
El criterio se transmite
Los registros de decisiones intentan guardar algo que el código nunca va a guardar: el porqué. En el código lo que tienes son resultados plasmados. Imagina una incidencia, un problema en producción. Para llegar al fix se ha pasado por un proceso: descubrimiento, debate, una solución, un error, otra solución. Ese proceso vive en el colectivo del equipo, no en el código. Y si no hay una documentación adecuada, tampoco va a estar en la memoria del modelo, porque al final la memoria del modelo no es más que documentación.
Se puede objetar, con razón, que una IA podría reconstruir buena parte de ese porqué leyendo commits, tickets e hilos de chat. Hoy los modelos se mueven por el historial de Git mejor que muchos desarrolladores. Lo acepto: podría reconstruirlo. Pero no fue partícipe de la conversación en ese momento. No tiene memoria de ella. Reconstruir no es haber estado. Es como entrar en una casa reformada: ves la pared terminada, pero no sabes que detrás reventó una tubería dos veces ni por qué el fontanero cambió el recorrido. Por eso la vivencia de las personas dentro de un equipo, el tiempo en el sitio y el know-how siguen siendo fundamentales.
De ahí sale la idea que, para mí, es la más importante de todo este artículo: la transmisión del criterio. El criterio se construye con experiencias propias, con las decisiones que tomas y los errores que cometes, pero también se puede absorber. Se absorbe estando en la conversación donde se decidió algo, escuchando por qué alguien descartó una opción, viendo cómo razona quien lleva años en el sitio. Y cuando el agente escribe buena parte del código, esa transmisión deja de ser algo que pasa por casualidad y se convierte en algo que hay que trabajar a propósito. Eso vale también para el segundo círculo: si nunca está en la conversación donde se decide qué probar, nunca va a absorber ese criterio. Con los perfiles junior esto pesa todavía más: ya hay datos que confirman una menor contratación en las áreas más expuestas a la IA. Ese debate daría para otro artículo, pero tengo claro que su gran reto será poner en valor el factor humano para demostrar su valía. Estoy convencido de que trabajar esa transmisión es una de las cosas más importantes que las empresas tienen que empezar a hacer ya: crear criterio en sus empleados, no solo contratar a quien ya lo trae y obviamente conservar a quien ya lo tiene.
Medir decide
El ciclo de experimentos solo se cierra si mides. El trabajo no termina con el merge, sino al comprobar el impacto del cambio. Además, los criterios de éxito deben definirse antes de empezar: la métrica a mover, el cambio mínimo relevante y el tiempo de espera. Interrumpir el experimento apenas el panel muestra un resultado «significativo» es engañarse con los datos.
Medir cambia cómo vemos el gasto. Probar algo que no funciona no es perder dinero. En Microsoft vieron que solo un tercio de sus ideas mejoraba el resultado esperado; otro tercio no cambiaba nada y el resto lo empeoraba. Lo verdaderamente caro es lanzar sin medir. Microsoft tardó ocho meses en detectar un cambio en Office Online que redujo las respuestas más de un 80 %. En cambio, una pequeña idea guardada en Bing durante seis meses aumentó los ingresos un 12 % tras probarla: más de 100 millones de dólares al año en Estados Unidos. Aprender del resultado justifica la inversión.
El desarrollador multipotencial
Volviendo al inicio del artículo, todo esto me lleva a replantearme el rol del desarrollador. Y la cuestión clave es: ¿sigue teniendo sentido la superespecialización? Backend, frontend, mobile, cada uno en su casilla. Durante años, el mercado premió a quien se encerraba en su silo de conocimiento y lo dominaba. Hoy, si un agente de AI se encarga de buena parte de la parte del trabajo sucio, lo que queda es criterio, y el criterio se alimenta de saber un poco de muchas cosas.
Que el criterio pese más no significa que el código deje de importar. Las buenas prácticas siguen siendo lo que separa un producto que aguanta de uno que se rompe a la segunda iteración. Lo que cambia es dónde pones las manos: le das el trabajo a la IA, pero te sigue importando el código, su complejidad y sus tests, y eso, sigue siendo programar. Revisar lo que genera un agente exige saber más, no menos.
Saber más, y de más cosas. Es como la vuelta a un perfil muy antiguo. Aristóteles escribió de lógica, física, biología, ética, política y poesía, y nadie le pedía que eligiera una sola disciplina. Newton inventó el cálculo, explicó la gravedad y la composición de la luz, dedicó años a la alquimia y a la teología, y terminó su vida dirigiendo la Casa de la Moneda de Inglaterra. Durante siglos, el conocimiento avanzó gracias a gente que cruzaba disciplinas, hasta que llegó la especialización y con ella los silos. Por eso creo que el desarrollador del modelo de experimentación tiende a ser multipotencial, muy distinto a un full stack: alguien que entiende lo que dice el diseñador, lo que preocupa al stakeholder y lo que cuesta construirlo. Es el perfil para el que, en mi opinión, está escrito Microexperimentos, de Anne-Laure Le Cunff, un libro que propone cambiar las metas lineales por un modelo circular en el que pruebas, aprendes y ajustas. Que es, curiosamente, lo mismo que le pedimos ahora a un equipo.
Aprender a decidir con IA proactiva
Eso sí, cubrir tantas áreas y asumir una mirada más amplia exige replantear cómo aprendemos. Hoy resulta facilísimo encerrarse a solas con un modelo de IA y no salir de ahí, perdiendo el contacto con el equipo y con la realidad del negocio. Sin embargo, en ese proceso de aprendizaje, las herramientas juegan un papel sustancialmente distinto según cómo funcionan y la actitud con la que las abordamos.
Una herramienta no proactiva como Claude Code espera a que le pidas algo y lo ejecuta. Su valor principal es que amplía tu criterio técnico existente: te permite llevar lo que ya sabes decidir muchísimo más lejos y a una velocidad sin precedentes. Por contra, un bot proactivo opera de manera totalmente diferente: toma la iniciativa, te trae propuestas terminadas y sugiere los siguientes pasos. Es exactamente lo que me sucede con Leonardo, el asistente con el que comenzó este debate: me presenta trabajo ya elaborado e ideas concretas, colocándome en la posición de evaluar y decidir qué se aprueba y qué se descarta.
A primera vista, podría objetarse que supervisar trabajo ajeno te hace perder práctica técnica. Es una advertencia antigua y muy válida: cuando una persona pasa a vigilar a la máquina, corre el riesgo de perder «la mano» en la ejecución directa. Sin embargo, esa objeción piensa en un operador pasivo. Lo que pone a prueba un bot proactivo es la otra dimensión del perfil senior: la toma de decisiones, la gestión de riesgos, la priorización y el criterio estratégico frente al negocio. Esa capacidad directiva y reflexiva no se atrofia por delegar la ejecución, sino que se entrena activamente con cada propuesta aceptada o rechazada. Mientras tanto, el dominio técnico más fino se sigue ejercitando y puliendo al interactuar con las herramientas pasivas que aguardan tus instrucciones directas.
En última instancia, el verdadero riesgo no es delegar la tarea, sino delegar la responsabilidad del juicio. Si dejamos que la IA decida sin confrontar sus propuestas con nuestro propio criterio, el aprendizaje se detiene. De modo que el aprendizaje moderno del desarrollador ya no consiste sólo en memorizar sintaxis o patrones de código, sino en convertir la supervisión crítica en un hábito diario: dudar, validar contextualmente y ejercitar continuamente la toma de decisiones para que el criterio siga siendo, indiscutiblemente, humano. Y para eso hay que salir a menudo de la conversación con el modelo y volver a la del equipo.
La certidumbre cambia de sitio
Todo esto suena muy bien para quien disfruta aprendiendo así, pero no todo el mundo vive cómodo en un ciclo. Hay personas que necesitan certidumbre, en la vida y en el trabajo, para saber qué tienen que hacer mañana. Y es una necesidad legítima, no un defecto. El modelo de planificación se la daba: un roadmap, un sprint, una lista de tareas con fecha. Si eso desaparece, ¿qué les queda?
Mi respuesta es que la certidumbre no desaparece, cambia de sitio. Ya no está en un roadmap ni en un objetivo final fijado de antemano, sino en la tarea misma: tu trabajo es iterar sobre tu tarea hasta mover la métrica, o hasta demostrar que no se mueve, independientemente de cómo lo consigas. Sabes qué tienes que conseguir y sabes cómo se va a medir. El camino lo decides tú, y puedes cambiarlo cuantas veces haga falta. Es lo mismo que le pasa al segundo círculo: no recibe órdenes, recibe una hipótesis y decide cómo llegar. En mi opinión, esa es la certidumbre de la experimentación, y para mucha gente puede llegar a ser más tranquila que la del plan, porque no depende de que el plan acierte. Lo que cambia, de alguna manera, es cuándo esperas el resultado: ya no al final del plan, sino en cada prueba. Lo que cambia es la preferencia temporal del negocio.
Empecé preguntándome por qué planificamos cómo planificamos, y la respuesta corta era el dinero. Pero a la larga va más allá: lo que estamos viviendo no es solo una nueva herramienta, sino un cambio de paradigma, y esos no se adoptan, se habitan. Me imagino las empresas del futuro cercano con compañeros de equipo virtuales: agentes que proponen, construyen y prueban mientras dormimos. En ese mundo, los equipos ya no se organizan por lo que cada uno sabe hacer, sino por lo que sabe decidir. El rol del desarrollador no desaparece, sino que se ensancha: se parece menos al especialista y más a aquel Aristóteles que conectaba distintas disciplinas para entender el conjunto. Todavía estoy aprendiendo a trabajar así con inteligencias que rediseñan mi oficio. Por eso me hago de vez en cuando la misma pregunta y te la comparto: si la mitad de tu equipo fuera virtual, ¿qué parte de tu trabajo seguiría siendo tuya y en qué tendrías que transformarte para seguir aportando valor?