AI en desarrollo de software senior: el coste que aparece después
A principios de año me propuse revisar con calma qué decisiones técnicas habían funcionado de verdad y cuáles solo parecían buenas sobre el papel. En ese repaso, la inteligencia artificial en programación apareció rápido. Casi siempre aparece. La conversación suele empezar hablando de productividad y termina, curiosamente, en silencio.
El silencio llega más tarde, cuando el sistema ya está en producción. Cuando la velocidad inicial se ha agotado y lo único que queda es el código. No el que se pensó escribir, sino el que quedó. El que ahora hay que mantener, entender y evolucionar.
Con el tiempo he llegado a una idea bastante simple: la AI no introduce un cambio puntual en el ciclo de vida del software. Introduce una asimetría permanente. Escribir cuesta casi cero. Entender cuesta lo mismo de siempre.
Ese desfase no es teórico. Lo he visto materializarse en arquitectura, en mantenimiento y en decisiones que, una vez tomadas, ya no se pueden deshacer sin pagar intereses. Este artículo nace de ese aprendizaje: de separar lo que suena bien de lo que sigue funcionando cuando pasan los meses.
La falsa neutralidad de la generación de código
La generación automática de código no es neutra. Nunca lo ha sido.
Cada fragmento que aparece “funcionando” arrastra decisiones implícitas: estructura, responsabilidades, acoplamientos, contratos no declarados. Cuando ese fragmento no nace de un diseño consciente, alguien hereda esas decisiones sin haberlas tomado.
En equipos senior esto no produce caos inmediato. Produce algo peor: confianza silenciosa.
El código pasa revisiones porque parece razonable. Cumple el caso de uso. No rompe tests.
Lo que no hace es explicar por qué existe así.
Ese tipo de código no falla hoy. Falla cuando el sistema crece.
Optimización del ciclo de vida… o del arranque
La AI optimiza el inicio del ciclo, no el ciclo completo.
Acelera el primer commit, el segundo, el tercero. Reduce el tiempo hasta la demo. Reduce fricción cognitiva en tareas repetitivas. Todo eso es real.
Lo que no reduce es:
- el coste de cambio cuando el dominio se mueve
- el coste de lectura cuando el autor ya no está
- el coste de refactorización cuando la presión aprieta
El resultado es un ciclo de vida con un pico de velocidad artificial seguido de una meseta de mantenimiento más cara de lo habitual.
No por mala intención. Por acumulación.
Técnicas de codificación avanzada… sin criterio avanzado
La paradoja aparece rápido: cuanto más senior es el equipo, más daño hace el uso acrítico.
Un desarrollador junior rompe cosas de forma visible.
Uno senior puede aceptar una abstracción mediocre sin darse cuenta… porque “funciona” y hay otras prioridades.
La AI propone soluciones plausibles, no óptimas. Y la plausibilidad es peligrosa en sistemas complejos.
Se empiezan a ver patrones repetidos con ligeras variaciones. Lógicas casi iguales con nombres distintos. Decisiones locales que no conversan entre sí.
Nada de eso parece grave aislado.
Todo junto forma una base de código difícil de gobernar.
Gestión de deuda técnica: cuando la deuda ya no se reconoce
La deuda técnica clásica se asumía conscientemente. Se sabía dónde estaba.
Con AI, parte de la deuda nace sin ser identificada como deuda. No hubo atajo explícito. No hubo “ya lo arreglaremos”. Solo hubo generación rápida y aceptación tácita.
El problema no es la deuda. Es la pérdida de trazabilidad sobre por qué existe.
Cuando llega el momento de escalar, nadie recuerda qué partes eran experimentales, qué partes eran provisionales, qué partes estaban “bien así”.
Todo parece definitivo.
Nada lo es.
Diseño de arquitectura escalable bajo presión de velocidad
La arquitectura necesita fricción. No mucha. La justa.
La AI elimina demasiada fricción en fases donde pensar lento era una ventaja. Propone estructuras completas antes de que el dominio esté claro. Y lo hace con una seguridad sintáctica que invita a aceptar.
El resultado frecuente no es una mala arquitectura. Es una arquitectura precoz.
Demasiado formada para el conocimiento real disponible en ese momento. Demasiado específica para evolucionar sin dolor.
Escalar después implica desmontar piezas que ya están en producción. Y desmontar siempre cuesta más que construir.
Alta disponibilidad y rendimiento: donde la AI no sufre las consecuencias
En entornos AWS, la AI sugiere configuraciones que funcionan.
No que optimizan costes.
No que minimizan estados intermedios.
No que reducen superficies de fallo.
Propone lo estándar. Lo documentado. Lo habitual.
Eso está bien hasta que el sistema vive meses bajo carga real. Hasta que los picos aparecen donde no se esperaban. Hasta que el coste mensual deja de ser anecdótico.
La AI no paga la factura.
El equipo sí.
Seguridad en aplicaciones AI: correcta por defecto, frágil en contexto
El código generado suele cumplir reglas básicas: validaciones, sanitización superficial, manejo genérico de errores.
Lo que no entiende bien es el contexto de amenaza específico del sistema. Las zonas donde un fallo no es un bug, es un incidente.
La seguridad real no se basa en patrones genéricos, sino en entender qué no puede fallar. Y eso requiere conocimiento del negocio, no del lenguaje.
Aquí la AI necesita supervisión constante. No como excepción. Como norma.
Codificación basada en confianza: el error cultural
Se empieza confiando en la herramienta.
Se termina desconfiando del código.
Ese desplazamiento es sutil. El equipo deja de sentirse autor. Pasa a ser revisor pasivo. El código ya no es una extensión del razonamiento, es un artefacto que se valida.
Cuando eso ocurre, la calidad baja aunque el número de tests suba. Porque nadie “siente” el sistema.
La confianza correcta no es en la AI.
Es en la capacidad del equipo para decir no.
Análisis de impacto real en software vivo
La inteligencia artificial no mata la calidad. La desplaza.
Parte del esfuerzo que antes se invertía en diseño pasa a invertirse en revisión, contención y corrección posterior. No es necesariamente peor, pero es distinto.
Los equipos que no ajustan procesos acaban con:
- más código
- más churn
- menos claridad sistémica
Los que sí ajustan aceptan una verdad incómoda: escribir ya no es el cuello de botella. Decidir sigue siéndolo.
Refactorización y mantenimiento: el lugar donde se paga todo
El mantenimiento es donde la AI muestra su límite más claro.
Refactorizar exige intención. Exige entender qué se puede romper y qué no. Exige memoria histórica del sistema.
La AI puede ayudar a ejecutar refactorizaciones. No a decidirlas.
Cuando la base de código creció sin una narrativa clara, refactorizar se convierte en arqueología. Y ninguna herramienta acelera eso de verdad.
Gestión del conocimiento técnico en equipos que usan AI
El riesgo no es que el equipo se vuelva dependiente. Es que el conocimiento deje de circular.
Si la solución viene generada, nadie la explica.
Si nadie la explica, nadie la interioriza.
Si nadie la interioriza, el bus factor baja sin que nadie lo note.
Los equipos senior sobreviven por conocimiento compartido, no por velocidad individual.
Aquí la AI obliga a rediseñar rituales: diseño explícito, decisiones documentadas, revisiones que discuten intención, no solo sintaxis.
Desarrollo de software responsable: una decisión adulta
Usar AI no es moderno. Usarla con criterio, sí.
El desarrollo responsable no pasa por prohibir herramientas ni por celebrarlas. Pasa por saber dónde no deben decidir.
La AI es útil en ejecución.
Es peligrosa en definición.
Cuanto antes se entienda esto, menos caro será el sistema dentro de dos años.
Lo que queda cuando se va el ruido
La inteligencia artificial no sustituye al desarrollador senior. Lo expone.
Expone si hay criterio arquitectónico.
Expone si se entiende el dominio.
Expone si se sabe decir “esto no”.
La ventaja competitiva ya no está en escribir rápido.
Está en construir algo que siga siendo entendible cuando la velocidad deje de importar.
Y siempre deja de importar.