Los fundamentos no han cambiado, tus excusas sí

Mismos compiladores. Mismos servidores. Misma necesidad de entender los sistemas. Lo que ha cambiado es que el backlog de cosas para las que “nunca tuviste tiempo” acaba de perder su mejor defensa.

Hay una tensión que me ha estado rondando mientras uso herramientas de IA más a menudo en mi trabajo diario: en términos prácticos y directos, esto se siente revolucionario. La velocidad con la que puedo hacer el scaffolding, refactorizar y prototipar es genuinamente distinta a la de hace un año. Pero cuando me alejo un poco —cuando miro lo que realmente está corriendo en producción— la historia es la misma. Código compilado desplegado en servidores, manejando peticiones, gestionando estados, fallando de la misma forma en que los sistemas siempre han fallado. Ambas cosas son ciertas simultáneamente, y la pregunta interesante es qué hay entre ellas.

El cobrador de deudas ha llegado

La narrativa convencional sobre las herramientas de codificación con IA se centra en la productividad: construye más rápido, entrega más, haz en una tarde lo que antes tomaba una semana. Y eso es real, pero no es lo más importante que está pasando.

El enfoque más honesto es que las herramientas de IA son un cobrador de deudas. No de deuda financiera, sino de deuda profesional. Esa clase de deuda que todos los equipos cargan y todos los desarrolladores conocen, pero con la que han aprendido a vivir.

Sabes de lo que hablo. Esa migración de librería que ha estado en el roadmap durante tres trimestres y sigue siendo desplazada por el trabajo en nuevas funcionalidades. La cobertura de pruebas que se estancó en el 40% porque escribir tests para código legado era tedioso y poco gratificante. La documentación que solo existe en la cabeza de una persona o, peor aún, en una página de Confluence de 2021 que describe un sistema que ya ni existe. Las mejoras en el pipeline de CI/CD que todos acordaron que eran importantes en la última retro y que nadie priorizó en el siguiente sprint planning.

Estos no son misterios. Cualquier desarrollador con experiencia puede recorrer su base de código y señalar los lugares donde se tomaron atajos, donde el “volveremos a esto después” se volvió permanente, donde se sabía qué era lo correcto pero el tiempo no alcanzaba.

La Encuesta de Desarrolladores de Stack Overflow de 2024 hizo esto dolorosamente concreto: la deuda técnica es la principal frustración en el trabajo para el 63% de los desarrolladores profesionales. Otra encuesta de DX encontró que más de dos tercios de los desarrolladores dijeron perder ocho o más horas por semana debido a ineficiencias causadas por la deuda técnica, documentación insuficiente y procesos de construcción defectuosos. Eso es un día completo de trabajo, cada semana, perdido en el costo acumulado de cosas que debieron hacerse y no se hicieron.

Las herramientas de IA no hacen que estos problemas sean más fáciles de entender. Todo el mundo ya los entiende. Lo que hacen las herramientas de IA es que sean más difíciles de ignorar. Cuando el costo de escribir esos tests faltantes baja de “dos semanas de trabajo tedioso” a “unos pocos días enfocados en generación y revisión”, la decisión de no hacerlo deja de ser una limitación y empieza a ser una elección. La mejor defensa del backlog —“no tenemos tiempo”— acaba de perder casi toda su credibilidad.

Misma base, nueva interfaz

Ahora, quiero ser cuidadoso aquí, porque hay una versión de este argumento que raya en la ingenuidad. Dice algo como: “La IA escribe el código, los desarrolladores solo piensan grandes ideas”. Eso no es lo que está pasando.

El software se sigue construyendo con los mismos compiladores y desplegando en los mismos servidores. Para construir un sistema real —uno que maneje los fallos con elegancia, que escale bajo carga y que no se convierta en un riesgo de seguridad— todavía necesitas entender las mismas cosas de siempre. Redes, despliegue, observabilidad, seguridad, gestión de estado, modelado de datos. Un agente de IA puede cambiar valores de configuración, pero tú necesitas saber qué valores y por qué. Puede generar una migración de base de datos, pero tú debes entender las implicaciones de los bloqueos (locking) en producción.

Lo que ha cambiado es la interfaz de parte de ese trabajo. En lugar de escribir cada línea tú mismo, cada vez estás revisando, guiando y corrigiendo más el output generado por la IA. Esta no es una habilidad menor; es una distinta y, en ciertos aspectos, más difícil.

Werner Vogels lo explicó muy bien en AWS re:Invent 2025: cuando escribes el código tú mismo, la comprensión viene con el acto de creación; cuando una máquina lo escribe, tienes que reconstruir ese entendimiento durante la revisión. Él llamó a esto “deuda de verificación”, y los datos lo respaldan. La encuesta State of Code de Sonar encontró que el trabajo pesado (toil) de los desarrolladores se mantiene constante en cerca del 24% de la semana laboral, sin importar qué tan frecuentemente usen herramientas de IA. El trabajo pesado no se reduce, se desplaza. Menos tiempo escribiendo boilerplate, más tiempo validando sugerencias. Menos tiempo redactando documentación, más tiempo detectando errores sutiles en el código generado.

Los usuarios más frecuentes de IA —los que dependen de ella varias veces al día— reportan, de hecho, más trabajo pesado por gestionar la deuda técnica que los usuarios infrecuentes (44% frente a 34%). La herramienta genera código rápido. Entender y mantener ese código todavía requiere el mismo juicio humano de siempre.

Por esto es que el enfoque de “mismos compiladores, mismos servidores” importa. El conocimiento fundamental no ha sido reemplazado. Lo que se ha añadido es una nueva capa: la capacidad de evaluar y verificar a gran velocidad y volumen. Es el mismo juicio que hace que alguien sea bueno haciendo revisiones de código (code reviews), aplicado a una escala diferente. Si ya eras fuerte leyendo código críticamente, entendiendo el comportamiento del sistema y detectando modos de fallo no obvios, estás bien posicionado. Si tu fuerte era principalmente producir código desde cero, el suelo se ha movido bajo tus pies.

La cuestión de la agencia

Esta es la parte de la conversación que suele mantenerse educada pero que necesita decirse directamente.

En mi post original sobre este tema, escribí que “aquellos que quieran pueden asegurar que cada proyecto tenga mejores prácticas de clase mundial”. Mantengo esa posición, pero he estado pensando en lo que ese “quieran” significa realmente en la práctica.

Tú, como desarrollador individual, podrías ver las herramientas de IA y ver una oportunidad para llevar la cobertura de tests del 40% al 85%. Para finalmente enfrentar la migración de la librería. Para escribir los registros de decisiones arquitectónicas (ADRs) que capturan por qué el sistema se construyó así, antes de que las personas que lo crearon se vayan de la empresa.

Tu organización podría mirar las mismas herramientas y ver una forma de duplicar la velocidad de los sprints. Entregar las siguientes tres funcionalidades del roadmap. Recortar el equipo en un 20% y mantener el mismo nivel de entrega.

Ambas son respuestas racionales. La diferencia es quién captura el valor de la herramienta.

Esta no es una tensión que la IA haya creado. Ha estado ahí cada vez que un desarrollador dijo “realmente deberíamos refactorizar esto” y un product manager dijo “necesitamos esta funcionalidad para el jueves”. La IA solo la hizo más visible, porque la brecha entre “lo que podríamos hacer” y “lo que estamos eligiendo hacer” se volvió más ancha. Cuando la excusa era “no tenemos el ancho de banda”, la tensión era teórica. Cuando el ancho de banda está disponible de repente, la tensión se convierte en una decisión.

No tengo una respuesta sencilla para esto. Creo que los desarrolladores que prosperen en este momento serán los que puedan argumentar —ante sus equipos, sus líderes y sus organizaciones— que invertir en calidad es invertir en velocidad. Que limpiar la deuda técnica no es una distracción para la entrega; es lo que hace posible una entrega sostenible. Los datos respaldan este argumento. El reto es plantearlo en una sala donde el roadmap trimestral está proyectado en la pantalla.

El ajuste de cuentas es la oportunidad

Quiero terminar donde empecé: con la tensión entre lo revolucionario y lo familiar.

Las herramientas de IA no han cambiado lo que necesitas saber para construir sistemas reales. No han cambiado la importancia de entender el stack que hay debajo de tus abstracciones, los modos de fallo de tus dependencias o los trade-offs de tu arquitectura. Los fundamentos son los mismos.

Lo que ha cambiado es el costo de no hacer el trabajo que siempre has sabido que importa. La migración que era demasiado tediosa ahora es alcanzable en días. Los tests que eran demasiado aburridos de escribir pueden ser generados y revisados en una fracción del tiempo. La documentación que nunca se priorizó ahora es extraíble a escala.

Los desarrolladores que definirán la próxima era de esta profesión no son los que usan la IA para escribir código más rápido. Son los que la usan para finalmente hacer todas las cosas que siempre han sabido que deberían hacerse, y que pueden argumentar que hacer esas cosas vale la inversión de la organización, no solo la ambición del desarrollador.

Los fundamentos no han cambiado. Tus excusas sí. Lo que hagas al respecto es la pregunta profesional más interesante de los próximos años.

---

Siguiente paso: Abre el backlog o el gestor de tareas de tu equipo y busca el ítem de deuda técnica más antiguo que todos aceptan que debería hacerse pero que nadie ha priorizado. Estima cuánto tomaría con herramientas asistidas por IA frente a la estimación original. Lleva esa comparación a tu próximo sprint planning. La conversación que surja te dirá mucho sobre si tu organización está lista para capturar el valor real de estas herramientas.

Discusión: ¿Cuál es la mayor pieza de deuda técnica en tu base de código que de repente parece alcanzable con herramientas de IA? Y, siendo honestos, ¿realmente tu equipo te permitirá priorizarla?