Escrito originalmente en francés. Traducido por IA — se ha preservado el sentido, no la prosa.
No escribo estas líneas como desarrollador en activo.
Durante mucho tiempo trabajé en el mundo del código, luego pasé al otro lado, hacia el Product Management. Sigo trabajando con desarrolladores, veo sus limitaciones, sus herramientas, sus arbitrajes, también su cansancio. Y aunque el desarrollo ya no sea mi actividad principal, no puedo evitar preguntarme cómo van a evolucionar los oficios del software con la IA.
Este texto no es una verdad definitiva. Es el punto de vista de un observador curioso, algo inquieto, que ha conocido suficientemente el código para sentir ciertas señales débiles, y que ahora observa la producción de software desde el producto. Al fin y al cabo, un Product Manager que deja de ser curioso sobre cómo se fabrican los productos probablemente deja de hacer bien su trabajo.
Desde hace un tiempo, llevo experimentando con los asistentes de desarrollo. He generado scripts, avanzado en pequeños proyectos y luego trabajado más en serio en una aplicación. Y la conclusión es a la vez impresionante e inquietante: la IA puede producir muchísimo, muy rápido. En pocos días, puedes obtener algo que se parece a una aplicación real.
Pero durante todo ese tiempo, también dediqué una energía considerable a corregirla.
No solo en detalles. En fundamentos. Archivos que crecen demasiado. Tests ausentes. Lógica de negocio metida en las API. Decisiones de arquitectura demasiado complejas para lo que se necesita. Soluciones que funcionan ahora, pero que podrían volverse frágiles mañana. Lo más extraño es que cuando le pido explícitamente que haga las cosas de otra manera, sabe hacerlo. Sabe escribir tests. Sabe separar el dominio de la capa operacional. Sabe proponer una solución más sencilla. Sabe reconocer que existe una opción mejor.
Lo sabe. Pero no siempre lo hace de forma espontánea.
Y ahí es donde el tema se vuelve interesante.
La IA no inventa los malos vicios del software
Hay que empezar siendo justos: la IA no ha inventado la deuda técnica. No ha inventado la sobreingeniería. No ha inventado las arquitecturas contradictorias, los tests olvidados, las decisiones implícitas, los productos mal definidos ni las refactorizaciones que se postergan demasiado.
Todo eso ya existía.
Algunos desarrolladores ya sabían construir una catedral para colocar una estantería. Algunos equipos ya sabían ir despacio hacia el muro. Algunas empresas ya sabían confundir velocidad de delivery 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, que sirva a un uso real.
La IA no crea, pues, un problema completamente nuevo. Cambia su escala.
Acelera lo que ya iba demasiado rápido. Hace menos visible lo que ya estaba mal comprendido. Permite apilar más rápidamente decisiones que nadie ha tomado realmente. 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 han adquirido la experiencia necesaria para saber 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 antes se necesitaban varios días, a veces varias semanas, ahora bastan unas pocas horas. El efecto psicológico es muy potente. Ves pantallas. Haces clic. Responde. Existe una base de datos. Una API está en marcha. 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 realmente. Puede superar algunos escenarios favorables sin ser robusta. Puede responder en una demo sin estar lista para producción. Puede contener cientos de decisiones técnicas que nadie sabe explicar, porque fueron generadas, aceptadas, parcheadas y luego olvidadas.
Antes de la IA, parte de esta fragilidad ya existía. Pero tenía a menudo 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 se hacía antes de seguir adelante.
Con la IA, ese límite desaparece.
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 forma
Gran parte de la experiencia técnica se construye en el error.
No cualquier error, claro está. Se puede sufrir mucho sin aprender nada. El dolor solo no forma. Pero en el desarrollo, el aprendizaje profundo viene a menudo de un bucle muy concreto: intentas, te equivocas, buscas, comprendes, corriges, y luego te quedas con algo de esa corrección.
A veces te bloqueas media hora. A veces un día entero. A veces no encuentras la solución ese mismo día, vuelves al día siguiente, y es precisamente 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 ocultar un coste. Aprendes que un bug no es solo un obstáculo, sino una parte del sistema que se resiste y pide ser comprendida.
La IA puede romper este bucle.
Cuando aparece un problema, puedes decirle: busca tú la solución. Encontrará algo. Quizás una buena solución. Quizás una solución terrible pero funcional. En ambos casos, si no te tomas el tiempo de entender, avanzas sin aprender.
El riesgo no es solo que el error se retrase. Es que llegue a una escala en la que ya no sea analizable. El sistema ha crecido. Las capas se han apilado. Las decisiones son implícitas. Los tests, cuando existen, quizás validan una comprensión errónea del requisito. Y cuando todo se derrumba, ya no se sabe bien por qué.
Entonces se parchea.
No se entiende mejor. Solo se pone un parche más sobre una arquitectura que nunca se ha habitado de verdad.
El núcleo del problema: la desaparición del primer peldaño
Probablemente es el punto que más me preocupa.
La cuestión no es solo saber si la IA va a reemplazar a los desarrolladores juniors. Esa pregunta es importante, pero oculta otra más profunda: ¿qué ocurre si la IA reemplaza las tareas que formaban a los juniors?
En muchos equipos, el aprendizaje se hacía por gradación. Había un lead, desarrolladores experimentados, perfiles intermedios y luego juniors. No se le confiaba de inmediato a un junior 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. Un test. Un refactor modesto.
Esas tareas no eran solo trabajo a realizar. Eran los primeros peldaños de la escalera.
Permitían aprender a base de tropiezos sin poner en riesgo 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 otro lugar. Permitían entrar progresivamente en el oficio.
Y son precisamente esas tareas las que la IA automatiza mejor.
El boilerplate, los pequeños scripts, las correcciones simples, los tests estándar, las integraciones evidentes: todo eso puede generarse 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 los primeros peldaños desaparecen, ¿cómo se llega a ser senior?
Puede responderse que los juniors aprenderán de otra forma, con la IA como tutor socrático. Es posible. Un buen uso de la IA puede ayudar a explicar, comparar, hacer verbalizar, generar ejercicios, simular una revisión de código. Pero esa posibilidad requiere disciplina, curiosidad y un marco claro. También requiere que la empresa acepte pagar tiempo de aprendizaje.
Y ahí es donde la pregunta económica se vuelve brutal.
Si un senior aumentado por IA produce diez veces más, ¿cuántas empresas aceptarán todavía que un junior vaya diez veces más despacio porque está aprendiendo? ¿Cuántas aceptarán que alguien pase un día entero en un problema que la IA puede esquivar en pocos minutos? ¿Cuántas preservarán la lentitud necesaria para la formación, 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 solo necesitan código. Necesitan personas capaces de diagnosticar, simplificar, mantener, asegurar, arbitrar e inventar. Y esas personas no nacen del simple pilotaje de un asistente. Se construyen a través de años de práctica, de errores, de revisiones, de decisiones difíciles y de los retornos de la realidad.
Si la IA aumenta a los seniors existentes pero fragiliza la formación de los juniors, no amenaza solo algunos 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?
A menudo se habla de las buenas prácticas como si formaran un stock estable. Bastaría con documentarlas, meterlas en archivos de directrices para la IA y luego pedirle 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 determinado mundo del software. Luego el cloud, los sistemas distribuidos, lo asíncrono, los microservicios, las arquitecturas orientadas a eventos hicieron emerger otros problemas. Hubo que inventar nuevas formas de pensar: idempotencia, retries, circuit breakers, sagas, observabilidad, resiliencia distribuida.
Esas prácticas no aparecieron porque alguien simplemente se las pidiera a una herramienta. Nacieron de sistemas reales, de fallos, 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á inventarlos sola, antes de que el terreno los haya hecho necesarios y comprensibles?
No estoy seguro.
Para inventar una buena práctica no basta con conocer las antiguas. Hay que sentir por qué ya no son suficientes. Hay que haber sido expuesto a la resistencia de la realidad. Hay que saber cuándo un pattern es una respuesta elegante y cuándo no es más que complejidad innecesaria.
La simplicidad en sí misma es una competencia senior.
Una IA puede proponer una solución demasiado compleja y luego reconocer de inmediato que una solución más sencilla es mejor si se le hace notar. Pero 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 adecuada.
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 por la IA en una noche. ¿Pero quién las relee? ¿Quién verifica los impactos? ¿Quién entiende las decisiones? ¿Quién prueba los escenarios tortuosos? ¿Quién decide qué debe ir 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.
Existe 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 un prototipo generado puede convertirse rápidamente en código de producción, ¿quién tendrá el valor de decir: paremos, todavía no está suficientemente limpio?
Pero el software no es solo una carrera hacia la cantidad. Un producto se vuelve rápidamente ilegible, tanto para sus usuarios como para sus equipos, si se añaden funcionalidades más rápido de lo que se comprende su uso. La complejidad no se mide solo en el código. También se mide en la adopción, el soporte, la documentación, la coherencia de la experiencia, la capacidad de la organización para explicar lo que fabrica.
La IA desplaza, pues, 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 siendo limitadas. Quizás incluso se vuelven más críticas.
La reconstruibilidad como criterio de calidad
En mi propio uso 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 conjuntos de tests, y luego la pirámide de tests, antes de desarrollar. Intenté mantener una separación clara entre el dominio de negocio y la capa operacional técnica. No llegué a una aproximación DDD completa, porque el proyecto no lo justificaba, pero me negué a que la lógica de negocio quedara dispersa en los endpoints.
¿Por qué?
Porque un sistema realmente comprendido es un sistema que sabrías reconstruir.
Si mañana tuviera que migrar 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 los tests que describen el comportamiento esperado. No todo es perfecto, pero el sistema no es solo un montón de código generado. Contiene asideros. Referencias. Líneas de separación.
Quizás es un criterio central para el desarrollo asistido por IA: no preguntarse solo "¿funciona?", sino "¿sabría reconstruirlo?"
Si la respuesta es no, entonces falta algo.
Reintroducir voluntariamente la dificultad
No basta con aprender a desarrollar con la IA. También hay que aprender, a veces, sin ella.
No por nostalgia. No para defender una visión heroica del desarrollador que sufre para merecer su oficio. Sino porque una competencia que nunca encuentra la dificultad se vuelve frágil.
Esta idea se acepta bien en otros contextos. En matemáticas, la calculadora es útil, pero aprender sin hacer nunca una operación por uno mismo produce dependencia. En el deporte, se añaden voluntariamente restricciones, peso, resistencia, porque es esa resistencia la que desarrolla los músculos.
El desarrollo necesitará la misma lógica.
Dojos sin IA. Ejercicios con IA limitada. Revisiones donde hay que explicar el código sin pedírselo al asistente. Momentos en los que se toma deliberadamente el tiempo de leer, comprender, simplificar.
El objetivo no es ralentizar en todas partes. El objetivo es ralentizar en el lugar correcto.
Quizás los equipos del futuro tendrán que asumir un ritmo híbrido: producir muy rápido una parte del tiempo, pero reservar tiempo largo para entender lo que se ha producido. Un día de mejora continua. Momentos a solas frente al código. Revisiones de arquitectura. ADR. Refactors lentos. Post-mortems de generación fallida.
Antes de la IA, ese tiempo largo ya faltaba con demasiada frecuencia. Muchos desarrolladores seguían con la cabeza agachada, produciendo sin tomar suficiente distancia para desarrollar su competencia. La IA puede agravar este problema si solo sirve para llenar todo el espacio ganado con aún más producción. Pero también puede convertirse en una oportunidad si nos obliga a distinguir mejor el tiempo de hacer y el tiempo de comprender.
Algunas reglas simples para mantener el control
Si los equipos quieren usar la IA sin perder su profundidad, probablemente 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. Si un equipo acepta código incomprendido, acepta una deuda de comprensión.
Luego, prever un pequeño presupuesto de comprensión por feature: el contrato, los tests, la decisión de arquitectura, los límites conocidos. No una documentación interminable. Solo lo suficiente para que el razonamiento siga siendo humanamente transmisible.
También hay que vincular los tests al funcional. Un test generado puede ser muy limpio y validar una comprensión errónea del requisito. El bucle debería ser: funcional, tests, código, vuelta al funcional. Cuanto más expresan los tests el uso esperado realmente, más posibilidades tiene el código de mantenerse cerca del valor.
Hay que mantener un mapa de los patterns autorizados por el equipo. ¿Cómo se hace una API? ¿Cómo se gestionan los errores? ¿Cómo se escribe un job asíncrono? ¿Cómo se prueba una llamada externa? Sin eso, cada feature generada puede inventar su propia manera de hacer las cosas, y el equipo mantendrá varias arquitecturas sin razón.
Por último, hay que analizar los fallos de la IA. Cuando produce una solución demasiado compleja, cuando olvida los tests, cuando pone la lógica de negocio en el lugar equivocado, no basta con corregir. Hay que entender la señal que faltó, ajustar las directrices, enriquecer las prácticas.
La IA puede escribir código. Pero el equipo debe seguir siendo propietario del razonamiento.
Entender diez veces mejor
No creo que el desarrollo de software vaya a hundirse por la IA.
Creo, en cambio, que algunos equipos se van a ahogar en código que no comprenden suficientemente. Habrán producido rápido. Habrán entregado cosas visibles. Incluso puede que hayan impresionado a su mercado durante un tiempo. Luego descubrirán que la velocidad no sustituye la arquitectura, que los tests solo valen si expresan el requisito correcto, que la seguridad vive en los casos tortuosos, que el legacy exige una comprensión histórica, y que los seniors no se fabrican eliminando las tareas que formaban a los juniors.
El verdadero desafío no es rechazar la IA. Sería absurdo. Es demasiado útil, demasiado potente, demasiado presente ya.
El verdadero desafío es no abandonarle 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. De lo contrario, no habremos solo acelerado el desarrollo de software. Habremos acelerado el olvido de lo que permite desarrollar bien.
Para saber más
Code centric La calidad pertenece a quienes entregan Cero bugs: dejemos de gestionar inventarios de defectos