No escribo estas líneas como desarrollador en activo.

Durante años trabajé en el mundo del código y luego me pasé al otro lado, al Product Management. Sigo trabajando con desarrolladores, veo sus limitaciones, sus herramientas, sus arbitrajes y también su cansancio. Y aunque el desarrollo ya no sea mi oficio principal, no puedo evitar preguntarme cómo van a cambiar las profesiones del software con la IA.

Así que este texto no es una verdad definitiva. Es el punto de vista de un observador curioso, algo inquieto, que conoció el código lo bastante como para notar ciertas señales débiles, y que ahora mira la producción de software desde el producto. Al fin y al cabo, un Product Manager que deja de tener curiosidad por la forma en que se fabrican los productos probablemente deja de hacer bien su trabajo.

Desde hace un tiempo juego con los asistentes de desarrollo. He generado scripts, he hecho avanzar proyectos pequeños y luego he trabajado más en serio en una aplicación. Y la conclusión es impresionante y preocupante a la vez: la IA puede producir muchísimo, y muy rápido. En unos pocos días tienes algo que se parece a una aplicación de verdad.

Pero durante todo ese tiempo también he gastado muchísima energía en corregirla.

Y no en detalles. En cosas básicas. Archivos que crecen demasiado. Pruebas que faltan. Lógica de negocio metida en las API. Decisiones de arquitectura más complicadas de lo que pedía la necesidad. Soluciones que funcionan hoy pero que podrían volverse frágiles mañana. Lo más raro es que, cuando le pido explícitamente que lo haga de otra manera, sabe hacerlo. Sabe escribir pruebas. Sabe separar el dominio de negocio de la capa operacional. Sabe proponer una solución más simple. Sabe reconocer que existe una opción mejor.

Lo sabe. Pero no siempre lo hace por su cuenta.

Y ahí es donde el asunto se pone interesante.

La IA no inventa los malos hábitos del software

Empecemos por ser justos: la IA no ha inventado la deuda técnica. No ha inventado la sobreingeniería. No ha inventado las arquitecturas que se contradicen, las pruebas que se olvidan, las decisiones implícitas, los productos mal encuadrados ni las reescrituras que se posponen demasiado tiempo.

Todo eso ya existía.

Había desarrolladores que ya sabían construir una catedral para colgar una estantería. Había equipos que ya sabían estrellarse contra el muro a cámara lenta. Había empresas que ya sabían confundir velocidad de entrega con valor real. El problema del software nunca ha sido solo escribir código. Siempre ha sido producir algo que aguante, que se entienda, que se mantenga, que evolucione y que responda a un uso real.

Así que la IA no crea un problema completamente nuevo. Le cambia la escala.

Acelera lo que ya iba demasiado rápido. Hace menos visible lo que ya se entendía mal. Permite apilar más deprisa decisiones que nadie ha tomado de verdad. Da una apariencia de madurez a sistemas que aún no han pasado por las etapas normales de maduración.

El peligro no es que la IA escriba código. El peligro es que permita producir sistemas mantenidos como prototipos, por personas que no siempre tienen la experiencia necesaria para saber por dónde van a romperse esos sistemas.

La ilusión de madurez

El vibe coding da una sensación embriagadora: pides, el código aparece, la aplicación avanza. Donde hacían falta varios días, a veces varias semanas, bastan unas horas. El efecto psicológico es muy fuerte. Ves pantallas. Haces clic. Responde. Hay una base de datos. Hay una API funcionando. Aparecen funcionalidades.

El producto parece madurar.

Pero lo que madura de verdad, a veces, es sobre todo la superficie.

Una aplicación puede funcionar sin que nadie la entienda de verdad. Puede pasar unos cuantos escenarios felices sin ser robusta. Puede aguantar una demo sin estar lista para producción. Puede contener cientos de decisiones técnicas que nadie sabe explicar, porque se generaron, se aceptaron, se parchearon y luego se olvidaron.

Antes de la IA, parte de esa fragilidad ya existía. Pero solía tener un límite natural: la lentitud. Producir código costaba tiempo. Esa lentitud imponía a veces conversaciones, arbitrajes, revisiones, momentos en los que había que entender lo que estabas haciendo antes de seguir adelante.

Con la IA, ese límite salta.

Puedes ir mucho más rápido que tu propia comprensión. Es útil para explorar. Es peligroso cuando empiezas a confundir exploración con producción.

Cuando el error llega demasiado tarde, ya no enseña nada

Buena parte de la experiencia técnica se construye en el error.

No en cualquier error, claro. Se puede sufrir mucho tiempo sin aprender nada. El dolor por sí solo no forma a nadie. Pero en el desarrollo, el aprendizaje profundo suele venir de un bucle muy concreto: pruebas algo, te equivocas, buscas, entiendes, corriges, y luego te quedas con algo de esa corrección.

A veces te atascas media hora. A veces un día entero. A veces no lo encuentras ese mismo día, vuelves al día siguiente, y es justo ese rodeo el que crea experiencia. Aprendes a reconocer las señales débiles en el código. Aprendes que una solución demasiado fácil suele esconder un coste. Aprendes que un bug no es solo un obstáculo, sino un trozo del sistema que se resiste y pide que lo entiendas.

La IA puede romper ese bucle.

Cuando aparece un problema, puedes decirle: apáñatelas, búscame una solución. Va a encontrar algo. Quizá una buena solución. Quizá una solución horrible pero que funciona. En ambos casos, si no te tomas el tiempo de entenderla, avanzas sin aprender.

El riesgo no es solo que el error llegue tarde. Es que llegue a una escala en la que ya no se puede analizar. El sistema ha crecido. Las capas se han apilado. Las decisiones son implícitas. Las pruebas, cuando existen, quizá validen una lectura equivocada de la necesidad. Y cuando todo se derrumba, ya nadie sabe muy bien por qué.

Así que parcheas.

No entiendes mejor. Solo pones un remiendo más sobre una arquitectura que nunca has llegado a habitar de verdad.

El fondo del problema: la desaparición del primer peldaño

Es probablemente lo que más me preocupa.

La cuestión no es solo si la IA va a sustituir a los desarrolladores juniors. Esa pregunta importa, pero esconde otra más profunda: ¿qué pasa si la IA sustituye las tareas que fabricaban a los juniors?

En muchos equipos, el aprendizaje era gradual. Había un lead, desarrolladores con experiencia, perfiles intermedios y luego juniors. A un junior no se le confiaba de entrada la arquitectura completa de un producto crítico. Se le daban tareas pequeñas. Un bug acotado. Un endpoint sencillo. Un script. Una corrección. Una prueba. Una refactorización modesta.

Esas tareas no eran solo trabajo pendiente. Eran los primeros peldaños de la escalera.

Permitían que uno se rompiera los dientes sin poner en peligro todo el sistema. Permitían aprender a leer código existente, a entender un ticket, a pedir ayuda, a recibir una revisión, a descubrir que un cambio local puede tener efectos en otra parte. Permitían entrar poco a poco en el oficio.

Y son justo esas tareas las que la IA automatiza mejor.

El boilerplate, los scripts pequeños, las correcciones simples, las pruebas estándar, las integraciones evidentes: todo eso se genera muy rápido. Desde el punto de vista de la productividad inmediata, es una excelente noticia. Desde el punto de vista de la formación, es mucho más ambiguo.

Si desaparecen los primeros peldaños, ¿cómo se llega a senior?

Se puede responder que los juniors aprenderán de otra manera, con la IA como tutor socrático. Es posible. Un buen uso de la IA ayuda a explicar, a comparar, a hacer que el aprendiz verbalice, a generar ejercicios, a simular una revisión de código. Pero esa posibilidad exige disciplina, curiosidad y un marco. Exige también que la empresa acepte pagar tiempo de formación.

Y ahí es donde la pregunta económica se vuelve brutal.

Si un senior potenciado por la IA produce diez veces más, ¿cuántas empresas van a aceptar todavía que un junior vaya diez veces más despacio porque tiene que aprender? ¿Cuántas van a aceptar que alguien pase un día con un problema que la IA esquiva en unos minutos? ¿Cuántas van a proteger la lentitud que la formación necesita, cuando el mercado empuja a entregar cada vez más rápido?

El riesgo es romper el ciclo de reproducción del oficio.

Las empresas de software no necesitan solo código. Necesitan personas capaces de diagnosticar, simplificar, mantener, asegurar, arbitrar e inventar. Y esas personas no nacen de manejar un asistente. Se construyen con años de práctica, de errores, de revisiones, de decisiones difíciles y de golpes de realidad.

Si la IA potencia a los seniors que ya están y debilita la formación de los juniors, no amenaza solo unos cuantos puestos de entrada. Amenaza la capacidad futura de las empresas de software para producir software de calidad.

¿Quién inventará las próximas buenas prácticas?

Hablamos a menudo de las buenas prácticas como si fueran un stock estable. Bastaría con documentarlas, meterlas en archivos de directrices para la IA y luego pedir a los asistentes que las apliquen.

Pero las buenas prácticas no están fijadas.

Nacen cuando el terreno cambia. Los design patterns clásicos respondieron a un mundo del software concreto. Después, la nube, los sistemas distribuidos, lo asíncrono, los microservicios y las arquitecturas orientadas a eventos hicieron emerger otros problemas. Hubo que inventar nuevas formas de pensar: idempotencia, reintentos, circuit breakers, sagas, observabilidad, resiliencia distribuida.

Esas prácticas no aparecieron porque alguien se las pidiera a una herramienta. Nacieron de sistemas reales, de caídas, de incidentes, de migraciones difíciles, de restricciones de explotación, de compromisos dolorosos.

La IA probablemente podrá ayudar a formular los próximos patterns. Podrá comparar soluciones, detectar recurrencias, documentar prácticas emergentes. Pero ¿podrá inventarlas sola, antes de que el terreno las haya vuelto necesarias y comprensibles?

No lo tengo claro.

Para inventar una buena práctica no basta con conocer las antiguas. Hay que notar por qué ya no bastan. Hay que haberse expuesto a la resistencia de la realidad. Hay que saber cuándo un pattern es una respuesta elegante y cuándo es solo complejidad inútil.

La simplicidad misma es una competencia senior.

Una IA puede proponer una solución demasiado compleja y luego reconocer al instante que una más simple es mejor, si se lo haces notar. Pero para eso hace falta alguien que lo vea. Hace falta alguien que diga: este problema no merece esta arquitectura. Hace falta alguien que prefiera una solución menos brillante, pero más ajustada.

Producir más, ¿para qué?

La velocidad de generación no es la velocidad de entrega.

Un equipo puede encontrarse con decenas de pull requests creadas durante la noche por la IA. Pero ¿quién las lee? ¿Quién comprueba los impactos? ¿Quién entiende las decisiones? ¿Quién prueba los escenarios retorcidos? ¿Quién arbitra lo que debe salir realmente a producción? ¿Quién se asegura de que el usuario pueda absorber esa complejidad?

Producir más código no es necesariamente producir más valor.

Hay una tentación competitiva evidente. Si un competidor saca una feature en tres días, ¿cómo aceptar que un equipo tarde tres meses? Si una maqueta generada puede convertirse rápidamente en código de producción, ¿quién tendrá el valor de decir: paremos, esto todavía no está lo bastante limpio?

Pero el software no es solo una carrera por la cantidad. Un producto se vuelve rápidamente ilegible, tanto para sus usuarios como para sus equipos, si añades funcionalidades más rápido de lo que entiendes su uso. La complejidad no se mide solo en el código. Se mide también en la adopción, el soporte, la documentación, la coherencia de la experiencia y la capacidad de la organización para explicar lo que fabrica.

Así que la IA desplaza los cuellos de botella.

El código se vuelve más rápido. Pero la revisión, la seguridad, el encuadre funcional, la integración, la comprensión y la absorción humana siguen teniendo un límite. Puede que incluso se vuelvan más críticos.

La reconstruibilidad como criterio de calidad

En mi propia experiencia reciente, lo que me tranquilizó no fue solo haber producido una aplicación. Fue haber impuesto puntos de anclaje.

Insistí en los contratos entre API. Empujé a la IA a producir los juegos de pruebas, y luego la pirámide de pruebas, antes de desarrollar. Intenté mantener una separación clara entre el dominio de negocio y la capa operacional. No llegué hasta un enfoque DDD completo, porque el proyecto no lo justificaba, pero me negué a que la lógica de negocio quedara repartida por los endpoints.

¿Por qué?

Porque un sistema que se entiende de verdad es un sistema que sabrías reconstruir.

Si mañana tengo que llevar esta aplicación a otra tecnología, sé dónde están los contratos, dónde están las reglas de negocio, dónde están las pruebas que describen el comportamiento esperado. No todo es perfecto, pero el sistema no es solo un montón de código generado. Tiene asideros. Tiene referencias. Tiene líneas de separación.

Quizá sea un criterio central para el desarrollo asistido por IA: no preguntar solo "¿esto funciona?", sino "¿sabría reconstruirlo?".

Si la respuesta es no, entonces falta algo.

Reintroducir dificultad a propósito

No basta con aprender a desarrollar con la IA. Hay que aprender también, a veces, sin ella.

No por nostalgia. No para defender una visión heroica del desarrollador que sufre para merecerse su oficio. Sino porque una competencia que nunca se topa con la dificultad se vuelve frágil.

Esta idea la aceptamos sin problema en otros terrenos. En matemáticas, la calculadora es útil, pero aprender sin hacer nunca una operación a mano genera dependencia. En el deporte, se añaden cargas a propósito, peso, resistencia, porque es esa resistencia la que desarrolla el músculo.

El desarrollo va a necesitar la misma lógica.

Dojos sin IA. Ejercicios con la IA limitada. Revisiones en las que hay que explicar el código sin pedirle al asistente que lo haga por ti. Momentos en los que te tomas el tiempo, a propósito, de leer, de entender, de simplificar.

El objetivo no es ir más despacio en todo. El objetivo es ir más despacio en el sitio adecuado.

Puede que los equipos de mañana tengan que asumir un ritmo híbrido: producir muy rápido una parte del tiempo, pero blindar tiempo largo para entender lo que se ha producido. Un día de mejora continua. Ratos a solas frente al código. Revisiones de arquitectura. ADR. Refactorizaciones lentas. Post mortems de una generación fallida.

Antes de la IA, ese tiempo largo ya faltaba demasiado a menudo. Muchos desarrolladores se quedaban atrapados en el día a día, produciendo sin tomar la distancia suficiente para crecer. La IA puede agravar el problema si solo sirve para llenar con más producción todo el espacio que ha liberado. Pero también puede ser una oportunidad si nos obliga a distinguir mejor el tiempo de hacer y el tiempo de entender.

Algunas reglas sencillas para no perder el control

Si los equipos quieren usar la IA sin perder profundidad, habrá que inventar una disciplina explícita. No una burocracia. Una higiene de comprensión.

Algunas reglas me parecen ya útiles.

Primero, no hacer merge de código que nadie pueda explicar. Es simple, casi brutal, pero esencial. Un equipo que acepta código que no entiende acepta una deuda de comprensión.

Después, reservar un pequeño presupuesto de comprensión por feature: el contrato, las pruebas, la decisión de arquitectura, los límites conocidos. No una documentación interminable. Lo justo para que el razonamiento se pueda transmitir entre humanos.

Hay que ligar también las pruebas a la necesidad funcional. Una prueba generada puede estar muy limpia y validar una lectura equivocada de la necesidad. El bucle debería ser: necesidad funcional, pruebas, código, vuelta a la necesidad funcional. Cuanto mejor expresen las pruebas el uso esperado, más posibilidades tiene el código de quedarse cerca del valor.

Hay que mantener un mapa de los patterns autorizados por el equipo. ¿Cómo hacemos una API? ¿Cómo gestionamos los errores? ¿Cómo escribimos un job asíncrono? ¿Cómo probamos una llamada externa? Sin eso, cada feature generada corre el riesgo de inventarse su propia manera de hacer las cosas, y el equipo acabará manteniendo varias arquitecturas sin motivo.

Hay que analizar, por último, los fallos de la IA. Cuando produce una solución demasiado compleja, cuando olvida las pruebas, cuando coloca la lógica de negocio en el sitio equivocado, no deberíamos limitarnos a corregir. Deberíamos entender la señal que no dimos, ajustar las directrices, enriquecer las prácticas.

La IA puede escribir código. Pero el equipo tiene que seguir siendo dueño del razonamiento.

Entender diez veces mejor

No creo que el desarrollo de software se hunda por culpa de la IA.

Lo que sí creo es que algunos equipos van a ahogarse en código que no entienden lo suficiente. Habrán producido rápido. Habrán entregado cosas visibles. Puede incluso que hayan impresionado a su mercado durante un tiempo. Y luego descubrirán que la velocidad no sustituye a la arquitectura, que las pruebas solo valen si expresan la necesidad correcta, que la seguridad vive en los casos retorcidos, que el legacy exige una comprensión histórica, y que los seniors no se fabrican eliminando las tareas que formaban a los juniors.

Así que lo que está en juego no es rechazar la IA. Sería absurdo. Es demasiado útil, demasiado potente y ya está demasiado presente.

Lo que está en juego es no cederle los mecanismos que producen la competencia.

Si la IA nos permite producir diez veces más rápido, entonces también debería obligarnos a reservar tiempo para entender diez veces mejor lo que producimos. Si no, no habremos acelerado solo el desarrollo de software. Habremos acelerado el olvido de lo que permite desarrollarlo bien.