Esto es una pieza para cambiar mentalidad y alinear a equipos, managers y clientes cuando entra la IA en el desarrollo de software. Este artículo nace de las evidencias a fecha de publicación que observo en el entorno corporativo cuando los decididores dan luz verde al desarrollo de proyectos reales asistidos por inteligencia artificial.
Con la IA es fácil caer en un espejismo: parece que avanzamos porque vemos cosas moverse. Aparecen pantallas, aparecen commits, aparecen pull requests. La IA hace que sea fácil parecer que avanzas. Y bajo presión, “parecer que avanzas” se confunde rápidamente con “avanzar”.
Aquí va la idea que lo cambia todo y que conviene repetir hasta que cale:
Con IA, el objetivo no es producir más código con menos gente: es entregar software más preciso que cumpla exactamente la expectativa.
Y esa precisión no se compra con más código implementado: se compra con más evidencia y menos incertidumbre.
Ese debe ser el núcleo del cambio de mentalidad en el desarrollo con IA. Por supuesto que la IA acelera la implementación de una feature y, en muchos casos, permite hacerlo con menos gente. De eso no hay duda. La cuestión es otra: si queremos un resultado igual o mejor de calidad, necesitamos invertir tiempo y criterio en cerrar la intención. Identificar qué se pretende exactamente, reducir incertidumbre y tomar las decisiones que la IA necesita para ejecutar sin interpretar. Porque cuando faltan piezas, la IA no se para: rellena huecos. Y ahí es donde la velocidad deja de ser ventaja y empieza a ser riesgo.
La tensión no suele venir de la tecnología. Suele venir de la cultura. En cuanto hay presión, aparece una demanda casi instintiva: “enseñadme código”. Es comprensible. Durante años, el código fue la mejor unidad de medida del avance, de hecho lo sigue siendo hoy. Pero con IA, ese proxy pierde fiabilidad. Ahora el riesgo no es que el código esté mal escrito o el avance de implementación sea lento. Es que esté bien escrito… pero que responda a una intención que nadie acordó ni solicitó.
Intentaré poner palabras a este cambio de mentalidad en el desarrollo con IA, a su impacto organizativo y a las señales nuevas de progreso que necesitamos si queremos trabajar con IA sin humo.
Qué cambia en los proyectos cuando desarrollamos con IA
El cuello de botella se desplaza hacia la intención
En el desarrollo tradicional, gran parte del esfuerzo estaba en convertir intención en implementación. Incluso con buenos requisitos, implementar llevaba tiempo: diseñar, programar, integrar, corregir. Por eso, con el paso de los años, nuestras metodologías y hábitos se fueron inclinando hacia lo visible: lo que se podía planificar, medir y enseñar.
Si pensamos en las metodologías ágiles, estas nacen de la necesidad de hacer entregas paulatinas de lo que hemos implementado de una forma ágil, identificar qué falla en nuestro código de forma rápida y corregirlo, esto es porque la implementación implica un coste de tiempo que muchas veces no se tiene.
Con IA, la fricción de producir implementación baja. No desaparece la complejidad del sistema, pero sí cambia dónde se paga el coste. El trabajo se desplaza hacia algo menos vistoso y, por eso, más fácil de infravalorar: cerrar intención.
Cerrar intención significa que el equipo, el negocio y el cliente comparten una definición suficientemente concreta de lo que “tiene que pasar”. No una narración bonita. Una definición que permita distinguir sin discusión qué es correcto y qué no lo es. Y conviene decirlo de forma explícita para evitar malentendidos: esto no va de documentación larga. No es escribir más. Es escribir lo que evita interpretaciones.
Cuando esto no está cerrado, el desarrollo tradicional ya sufría. La diferencia es que antes el coste de implementar actuaba como freno: la ambigüedad se iba resolviendo a lo largo de semanas y meses, a base de conversaciones y retrabajo. Con IA, ese freno desaparece. La ambigüedad no se resuelve sola, solo se propaga más rápido.
Este es el punto incómodo del cambio de mentalidad en el desarrollo con IA: debemos aprender a reconocer progreso antes de ver “cosas funcionando”. A veces el avance real ocurre cuando eliminamos un malentendido, cerramos una decisión o definimos un criterio que permitirá validar sin discusiones después.
La sensación de «no avanzar»
Lo que nos pasa es casi físico: hoy seguimos entrenados para asociar avance con implementación. Si no hay código, sentimos que el proyecto no se mueve. Y cuando la conversación se alarga en decisiones, requisitos, preguntas incómodas y documentación, aparece la sensación de congelación: “estamos en papeles”, “no estamos construyendo”, “esto no avanza”. Esa sensación es coherente con la mentalidad instalada, porque sabemos que, tarde o temprano, todo eso habrá que traducirlo a código y esa traducción cuesta semanas o meses.
Con desarrollo con IA, esa intuición empieza a fallar. Es fácil mirar un estado donde ya hemos cerrado decisiones, reducido ambigüedades y fijado intención, y pensar: “no hay ni una línea de código, estamos estancados”. Pero ahí está el giro: en este nuevo marco, ese trabajo no es un prólogo del avance, es el avance. Porque si la implementación se abarata de verdad, lo caro ya no es teclear, sino decidir bien.
La sensación correcta, aunque cueste adoptarla, es esta: cuando la intención está cerrada, el proyecto ya ha avanzado de forma sustancial aunque el repositorio esté vacío. Lo que antes percibíamos como “tiempo sin producir” ahora es “tiempo comprando precisión”. Y esa precisión es lo que permite que, cuando toque ejecutar, la IA no tenga que rellenar huecos ni improvisar interpretaciones: simplemente implementa lo que ya está decidido.
Por eso el riesgo no es “documentar demasiado”. El riesgo es medir el avance con el termómetro del paradigma actual, entrar a construir para calmar la ansiedad y descubrir demasiado tarde que lo que faltaba no era código, sino acuerdos. Con IA, un repositorio vacío puede ser estancamiento… o puede ser la señal de que estamos preparando el terreno para que la velocidad posterior no se convierta en retrabajo.
El riesgo ya no es “errores”, es “plausibilidad”
La IA produce resultados plausibles. Es decir, resultados que tienen sentido según patrones comunes. Esa plausibilidad es útil para acelerar, pero es peligrosa cuando tu producto tiene matices. Lo plausible puede ser incorrecto, y lo incorrecto puede pasar desapercibido porque “parece razonable”.
Por eso el riesgo cambia de forma. No se trata solo de bugs evidentes. Se trata de desviaciones sutiles respecto a la intención real. Y esas desviaciones son especialmente caras porque erosionan confianza: primero parece que todo va, y después aparece el “bug raro”, el “esto no era así”, el “pero en la demo funcionaba”.
Cuando esto ocurre, la reacción típica es mirar código. Y muchas veces descubrimos algo incómodo: el código está bien, está limpio, está coherente. El problema es que está implementando una idea distinta de la que el cliente tenía en la cabeza.
Aquí la IA actúa como amplificador. Amplifica velocidad, pero también amplifica el coste de no haber cerrado intención. Si no cambiamos el marco mental, acabaremos confundiendo velocidad de generación con control del producto.
Qué se rompe si no cambias
El progreso visible deja de ser progreso fiable
Con IA, podemos producir implementación antes de haber tomado decisiones. Eso rompe una relación que llevábamos años dando por buena: “si hay código, hay avance”. Ahora puede haber código y no haber avance. Puede haber pantallas y no haber acuerdo. Puede haber integración y no haber control.
Esto es especialmente peligroso cuando hay prisa. Porque la prisa suele pedir símbolos: algo que se pueda enseñar. Y el símbolo clásico es el código. Pero el símbolo no reduce riesgo. Solo reduce ansiedad momentánea.
En un equipo maduro, la ansiedad se gestiona con control, no con teatro. La pregunta no es “¿qué puedo enseñar?”. La pregunta es “¿qué incertidumbre hemos eliminado?”.
Metodologías: no reinventar la rueda, pero sí cambiar el coche
Aquí necesitamos ser explícitos. A veces, para evitar debates ideológicos, decimos “no hace falta una nueva metodología”. Y es verdad en el sentido superficial: no necesitamos bautizar un proceso con un nombre nuevo para que funcione.
Pero también es verdad, en el sentido importante, lo contrario: si el marco cambia, la metodología debe variar. Porque la metodología no es un conjunto de ceremonias; es un sistema de control. Define dónde ponemos el foco, qué consideramos avance, cómo reducimos riesgo y cómo evitamos que la presión nos empuje a decisiones malas.
Pensemos en el cambio de un coche con marchas manuales a uno automático. El destino es el mismo: conducir bien y llegar. Pero si seguimos usando los mismos hábitos, nos equivocamos de palancas, nos distraemos con lo irrelevante y perdemos control donde ahora importa. En un manual, el conductor dedica atención constante al embrague y al cambio; en un automático, esa carga desaparece y la atención se desplaza a otras cosas: anticipación, distancia, lectura del entorno. La conducción no se “simplifica”: cambia el reparto de responsabilidad.
Con IA pasa lo mismo. En el paradigma actual, implementar era caro y muchas metodologías estaban optimizadas para exprimir eficiencia de implementación. Si implementar se abarata, el control tiene que moverse: intención, decisiones, criterios y evidencia. No porque lo anterior estuviera mal, sino porque estaba afinado para otro cuello de botella. Y si no ajustamos el sistema, haremos exactamente lo que haría un conductor empeñado en conducir un automático como si fuera manual: más estrés, más tirones y menos control real.
Cuando el coche cambia de marchas por ti, tu trabajo no es cambiar más rápido: es poner más atención a la circulación que al manejo del vehículo.
Falsas señales tranquilizadoras
Estas señales calman a corto plazo porque enseñan output, pero no demuestran control:
- “Ya hay implementación” sin acuerdo claro de qué debía ocurrir.
- Demos del camino feliz sin haber hablado de excepciones.
- Actividad en repositorio como prueba de avance.
- “La IA ya lo ha generado” como sinónimo de “ya está resuelto”.
- “Vamos rápidos” sin poder explicar qué riesgos se han cerrado.
La primera lista enseña output. No enseña control.
Las verdaderas señales tranquilizadoras
Estas señales también calman, pero lo hacen porque reducen riesgo de forma real:
- Decisiones cerradas por escrito: lo que está decidido y lo que sigue abierto.
- Definición clara de qué significa “correcto” con ejemplos concretos.
- Lista explícita de incertidumbres y cómo se van a resolver.
- Evidencia de que lo importante se demuestra y no se “cree”: pruebas y checks que pasan, y señales observables cuando el sistema corre.
- Límites claros: qué no estamos intentando resolver ahora.
La segunda lista enseña control. Y el control es lo único que escala cuando aceleramos. El último punto me recuerda a como Steve Jobs, uno de los gurús del diseño de productos, ya ponía el foco en que es tan importante decidir qué hacer como decidir qué no hacer.
Quién tiene que cambiar qué
La conversación sobre IA se atasca cuando la reducimos a herramientas. El cambio real es social: cada stakeholder tiene que reajustar qué considera “buen trabajo” y qué exige como prueba. Este reparto de responsabilidades es parte del cambio de mentalidad en el desarrollo con IA: si solo cambia el equipo técnico, el sistema entero empujará hacia los mismos errores.
Desarrolladores: del “picar código” al gobierno del cambio
Los perfiles de desarrollo no van a desaparecer. Se van a transformar. Nuestro papel sigue siendo vital, y seguirá siendo imprescindible conocer lenguajes, frameworks y cómo se construyen sistemas reales. La diferencia es qué parte de ese conocimiento se premia más: en muchos contextos, la ventaja ya no estará tanto en la especialización de “ser quien más teclea más rápido”, sino en quién entiende mejor el sistema y reduce interpretaciones antes de que se conviertan en deuda.
Y esto toca una fibra que no conviene maquillar. Para algunos, el trabajo puede dejar de ser tan cautivador. Hay desarrolladores que disfrutan del bucle de recompensa de escribir código, ejecutar y ver cómo “cobra vida” lo que sale de la energía de sus dedos sobre el teclado. Con IA, ese bucle cambia: la satisfacción ya no viene tanto de producir líneas, sino de afinar intención, anticipar casos borde y conseguir que el sistema haga exactamente lo que debe hacer, sin sorpresas dos semanas después.
Nuestro trabajo se vuelca más en un oficio intelectual de evaluación, criterio y validación. Ya no será “voy a picar el código de este test”, sino “voy a definir qué debe demostrar este test para validar que se cumple lo que se ha pedido”. Y ahí, paradójicamente, el nivel de ingeniería sube: menos artesanía visible, más responsabilidad sobre significado, coherencia y evidencia.
Si asumimos ese giro, dejamos de medir valor por output y lo medimos por control. Con IA, producir más no es sinónimo de contribuir más. Contribuir más es reducir incertidumbre, cerrar decisiones y construir evidencia que haga que la velocidad juegue a nuestro favor.
Perfiles de gestión de proyectos: de medir «código» a medir en «incertidumbre»
A los perfiles de gestión de proyectos les diría esto: durante años habéis hecho bien vuestro trabajo porque el avance era visible y medible en términos de implementación. Backlog, estimaciones, Fibonacci, velocity, capacidad por sprint. Si el equipo entregaba 30 puntos, planificábamos 30 puntos. Y en el paradigma actual eso tiene sentido, porque la implementación suele ser el cuello de botella y el código acaba funcionando como el indicador más tangible de “progreso”.
Con el desarrollo con IA, ese termómetro empieza a fallar. No porque estimar o planificar dejen de ser importantes, sino porque la unidad de medida cambia. La velocidad de implementación puede dispararse o volverse irregular dependiendo de cuánto esté cerrada la intención. Si seguimos midiendo avance solo por “puntos desarrollados” o por “código producido”, corremos el riesgo de gestionar ansiedad en lugar de gestionar riesgo: parece que avanzamos, pero lo que estamos acumulando es interpretación.
La consecuencia práctica es que habrá que seguir haciendo planificación, pero con un panel distinto. Tendremos que empezar a medir y reportar cosas como: cuántos casos de uso están realmente cerrados, cuántas decisiones siguen abiertas, cuánta incertidumbre queda en los puntos críticos, cuántos criterios de aceptación están definidos de forma verificable y qué evidencia existe ya para dar algo por válido. La implementación pasa a ser más colateral: importante, sí, pero menos representativa del estado real del proyecto.
Si queremos que la IA sea una ventaja y no una fuente de frustración, el reporting debe premiar control, no output. No se trata de abandonar Agile ni de dejar de estimar. Se trata de reconocer que, cuando el código se abarata, lo que determina el calendario ya no es “cuánto tardamos en picar”, sino “cuánto tardamos en decidir bien”. Y ahí el rol de gestión de proyectos no pierde relevancia
Jefes y socios: de pedir “código” a pedir control de riesgo
Pedir código como prueba de avance tiene una lógica histórica, pero con IA puede empujar a una falsa sensación de progreso. La pregunta que necesitamos normalizar a nivel directivo es otra: “¿qué riesgo hemos reducido y con qué evidencia?”.
Para bajarlo a tierra, hay una pregunta que funciona especialmente bien porque obliga a hablar de control sin entrar en detalles técnicos: “¿Qué decisiones siguen abiertas y qué evidencia tenemos de lo ya cerrado?”. Si esa pregunta se convierte en rutina, cambia el tipo de avance que se pide y, por tanto, el tipo de avance que se construye.
Cuando management pide control, el equipo se organiza para dar control. Cuando pide teatro, el equipo produce teatro. En proyectos exigentes, esta diferencia define si salimos a producción con confianza o con fe.
Cliente y negocio: decidir antes para acelerar después
Con IA, la aceleración no es gratis. Si aceleramos sin cerrar intención, el sistema avanzará hacia una interpretación. Luego llegará el momento de corregir, y ahí descubriremos que no era “un bug”: era una decisión no tomada.
Por eso el cliente y el negocio tienen un rol activo. Decidir no es burocracia, es parte del trabajo. Cerrar significado antes de acelerar es lo que permite que la velocidad sea una ventaja y no una deuda. Si no interiorizamos este cambio de mentalidad en el desarrollo con IA, acabaremos pidiendo velocidad cuando todavía no hemos decidido rumbo.
Qué hacer: tres artefactos y una metodología que los haga mandar
Si aceptamos que la metodología debe variar, conviene mantenerla simple: no como un manual gigantesco, sino como un conjunto de mecanismos que obligan a que lo importante exista y tenga autoridad.
Para nosotros, lo mínimo que debe “mandar” en un flujo con IA se puede expresar con tres artefactos. Son deliberadamente entendibles por cualquiera, porque si no lo son, no alinean.
Decisiones
Qué está cerrado y qué sigue abierto. Si esto no está claro, el equipo y la IA rellenarán huecos. Y con IA, rellenar huecos ocurre antes de que nos dé tiempo a detectarlo.
Las decisiones no tienen que ser largas. Tienen que ser explícitas. Lo importante es que podamos decir: “esto lo acordamos” y “esto aún no lo hemos acordado”.
Criterios
Qué significa “correcto”. Y aquí la palabra “criterio” no es una formalidad: es la herramienta que convierte intención en algo verificable. Dos ejemplos suelen valer más que diez párrafos.
Un ejemplo de “esto sí” y un ejemplo de “esto parece que sí, pero no” cambian el tipo de conversación. Evitan que el debate sea de gustos y lo convierten en significado compartido.
Evidencia
Cómo lo vamos a demostrar. La documentación no es la verdad del comportamiento. La documentación es el árbitro de intención. La verdad del comportamiento se demuestra con evidencia cuando el sistema ejecuta.
Con IA, lo crítico es conectar intención y evidencia: que lo que decimos que debe ocurrir tenga una forma de demostrarse, y que esa demostración sea parte del flujo, no una auditoría al final.
El papel de la metodología aquí es garantizar que estas tres piezas no sean “un extra”, sino la base sobre la que se considera que hay avance. Ese es, de nuevo, el cambio de mentalidad en el desarrollo con IA: no pedimos más output, pedimos más control.
El ejemplo GTD como historia: cómo nace el “bug raro”
Imaginemos una situación típica en una app GTD, contada como ocurre en la vida real.
El cliente dice: “Las tareas se pueden completar y deben quedar registradas”.
El equipo entiende: “Guardamos un histórico de completadas”.
La IA implementa algo plausible: al completar una tarea, la mueve a una lista de completadas, guarda una fecha y la oculta de pendientes.
La demo funciona. Todos respiran. Hay pantallas, hay movimiento, hay sensación de avance.
Dos semanas después aparece el bug raro: el cliente revisa tareas recurrentes y descubre que “completar” le ha roto el flujo. En su cabeza, completar una tarea recurrente genera la siguiente ocurrencia y conserva histórico por ocurrencia. En el sistema, completar la tarea recurrente la archiva como si fuera una tarea normal y no se genera la siguiente. O se genera, pero el histórico no se comporta como el usuario espera.
El equipo mira código. El código está bien. El problema no es el código.
La causa fue otra: la intención no estaba cerrada. “Registradas” significaba una cosa para el cliente y otra para el equipo. Y como nadie lo cerró, la implementación tomó una decisión plausible.
Cómo habría sido si el flujo obligara a que mandasen Decisiones, Criterios y Evidencia:
- Decisiones: “¿Qué significa ‘registradas’ para recurrentes? ¿Se guarda histórico por ocurrencia? ¿Se crea la siguiente al completar?”.
- Criterios: dos ejemplos claros, uno correcto y uno que parezca correcto pero no lo sea.
- Evidencia: una comprobación automática que falla si no se genera la siguiente ocurrencia o si el histórico no refleja lo acordado.
Lo importante no es el formato. Es que la conversación ocurre antes de que el sistema se llene de interpretaciones. Ese es el tipo de hábito que queremos instalar cuando hablamos de cambio de mentalidad en el desarrollo con IA.
Qué no cambia y dónde no aplica igual
No cambia lo esencial del oficio: necesitamos diseño, revisión, pruebas, control de cambios y criterio. La IA no sustituye responsabilidad. Redistribuye el trabajo hacia lo que decide el significado y hacia cómo lo demostramos.
Y no aplica igual en todos los contextos. Un prototipo para validar UX no necesita el mismo nivel de evidencia que un sistema de pagos. Un script interno de un equipo pequeño no exige la misma disciplina que una integración crítica con datos sensibles. La regla útil es simple: cuanto mayor el riesgo o el impacto, más intención cerrada y más evidencia demostrable necesitamos.
La conversación que debemos ganar
La conversación que se está comiendo la sala no es “qué incertidumbre estamos eliminando”, sino “si antes necesitábamos 5 desarrolladores durante 10 meses, con IA lo hacemos en 3 meses con la mitad de desarrolladores”. Suena espectacular. También es el tipo de frase que convierte un sistema complejo en una diapositiva optimista y luego viene la sorpresa, exactamente en el momento del golpe de realidad en el que nos damos cuenta de todo lo que no se hizo y que provoca que el escenario con el cliente no cabe en el gráfico.
La IA, bien alineada, es una palanca enorme. Nos permite pasar de intención a resultado con una velocidad inédita, iterar sin penalización y materializar decisiones con una eficiencia que hace poco parecía ciencia ficción. Pero hay una condición: esa velocidad tiene que estar guiada por intención cerrada y validación. Si no, estamos acelerando sin rumbo.
Con IA, la ganancia de velocidad tiene que estar guiada por intención cerrada y un plan preciso de validación. Regatear en la fase de discovery ya no será una estrategia beneficiosa.
El choque llega cuando usamos la IA para cubrir huecos en lugar de para ejecutar sobre terreno firme. En consultoría, el patrón de siempre es conocido: discovery superficial, se arranca delivery “para no perder tiempo”, aparecen dudas estructurales, se reabre el alcance y el calendario se convierte en un ejercicio de imaginación creativa.
La conclusión incómoda es esta: con IA, el ahorro real no sale de recortar gente, sale de recortar incertidumbre. Si seguimos optimizando utilización y “código visible”, lo único que estamos haciendo es estrellarnos antes: con más velocidad, más confianza… y menos frenos cuando llegue la curva.