Tus sistemas ya tienen puntos ciegos. La IA solo los empeora.

En 2022, antes de que las herramientas de codificación generativa formaran parte de nuestro trabajo diario de ingeniería, escribí sobre mi filosofía en la selección de herramientas. Ha resultado mejor de lo que esperaba. En aquel entonces, argumentaba que se debía comenzar con los problemas que realmente estaban resolviendo, conocer sus debilidades y priorizar cómo usar las herramientas en lugar de lanzarse a cualquier herramienta que suene mejor y esperar que funcione. Conócete a ti mismo y a tus objetivos, para que puedas establecer expectativas adecuadas para tus herramientas.

En ese momento, estaba pensando en la expansión descontrolada de SaaS, no en código generado por IA. Pero hoy mi filosofía es aún más urgente y más importante de defender.

Muchos de nosotros hemos leído el 2025 DORA report, que encontró que, a diferencia del año anterior, la adopción de IA ahora se correlaciona positivamente con el rendimiento de entrega. El hallazgo subyacente fue que la inestabilidad en la entrega siguió aumentando, y probaron si las ganancias de velocidad la compensaban. No lo hacen. Eso coincide con nuestra experiencia. Nuestro equipo adoptó el desarrollo de software agente y vio un aumento del 48 % en el rendimiento durante dos trimestres, seguido de un aumento del 16 % en los problemas de estabilidad. Diez personas es una muestra pequeña, pero también es una muestra que me permite ver el panorama completo, y el patrón se mantuvo. 

La adopción de IA ya no es realmente una cuestión. O estás empezando o estás en medio de ello. Lo que cambia ahora es que se espera que los líderes de ingeniería adopten IA y también demuestren que está dando resultados. El CEO, la junta y finanzas quieren saber cómo optimizar su inversión en IA. Preguntan si las herramientas que elegiste están resolviendo problemas reales de manera eficiente. 

La brecha siempre estuvo allí. La IA solo la amplió.

Como CTO, paso una buena parte de mi tiempo hablando con otros líderes de ingeniería, incluidos clientes, prospectos y colegas, para comparar logros y quejas sobre lo que estamos experimentando con la IA. Después de suficientes de esas conversaciones, he comenzado a ver patrones en la adopción de IA y sus resultados.

La observación principal no es mía. DORA la ha destacado durante dos años: la IA amplifica lo que ya está sucediendo en la organización, tanto fortalezas como debilidades. Un equipo con arquitectura limpia y hábitos de revisión saludables se vuelve más rápido. Un equipo que ha manejado una bola enredada de deuda técnica lo suficiente para lanzar código ahora descubre que la deuda técnica está convirtiéndose en un obstáculo importante. Lo que ese enfoque no captura, sin embargo, es por qué esto sorprende a tantos equipos. La IA no ocultó esas debilidades; los sistemas en los que confiábamos nunca las expusieron.

La pila de tickets y reportes en la que operan la mayoría de las organizaciones de ingeniería se construyó para responder preguntas que los humanos tienen, a velocidad humana, por personas que entendían aproximadamente qué significaba \”listo\” para una pieza de trabajo determinada. Nunca fue un registro perfecto. Siempre fue una aproximación, completada por alguien que resumía algo más caótico debajo. Ahora, la IA añade volumen y nuevos insumos que generan nueva actividad. Ninguno de los sistemas (o herramientas) usados para los métodos tradicionales de desarrollo, sin IA, fue creado para eso. 

Sin embargo, seguimos siendo responsables de los mismos objetivos. Aún controlas la velocidad, la calidad, el gasto y cómo está realmente tu equipo. Simplemente ya no puedes aceptar los paneles del año pasado por fe.

Hay una objeción válida aquí. DORA’s 2026 ROI report describe una curva en J: una caída de productividad justo después de la adopción, impulsada por la curva de aprendizaje, el costo de verificar el código generado por IA y los procesos posteriores que no se han puesto al día. Lo llaman el “costo de matrícula” de la transformación, y advierten a los líderes que no lo confundan con un fracaso. Es razonable. Pero la matrícula y un problema real se ven idénticos en un panel construido a partir de tickets. Si no puedes saber en cuál estás, no estás siendo paciente. Estás adivinando.

Necesitamos volver a lo básico. Conócete a ti mismo. Conoce a tu equipo. Conoce los problemas que estás resolviendo. 

¿Cómo puedes “conocerte a ti mismo” con IA?

De mis conversaciones, he identificado cinco áreas principales donde los sistemas convencionales, construidos para trabajo generado y reportado por humanos, son ciegos. Ignorarlos implica arriesgarse a amplificar tus debilidades al seguir adoptando IA.

Punto ciego 1: Teatro de velocidad

Más commits y más PR pueden parecer progreso, y a menudo lo son. La IA eleva ambos recuentos automáticamente. Un Stanford case study mostró que la adopción de IA aumentó el número de PR en un 14 %. Pero lo que se está pasando por alto es cuánto de esa actividad es trabajo de funcionalidades que se entrega versus mantenimiento, retrabajo o churn de una refactorización que no se mantuvo.

Para abordar esto, vigila la división entre trabajo de funcionalidades y mantenimiento, y observa la frecuencia de despliegues y el tiempo de entrega en comparación con tu propia línea base histórica, no con un promedio de la industria. Sin esa división, estás reportando progreso que no puedes sustentar realmente.

Punto ciego 2: Deuda de revisión

La capacidad de revisión no se escala automáticamente junto con la producción. El impuesto de verificación no es una fase que se supera; es parte del costo permanente del desarrollo agente. Una encuesta reciente de líderes de ingeniería encontró que el 80 % de los equipos dedica al menos el 10 % de su tiempo a la revisión, y aproximadamente uno de cada diez dedica más del 40 %. Bajo esa carga, los equipos oscilan entre una acumulación creciente y la aprobación automática, y ninguna es una solución real.

La limitación para lanzar ya no es la rapidez con que se escribe el código. Es qué tan rápido un ser humano puede estar realmente seguro de que un cambio es correcto, qué tan rápido y con precisión se pueden detectar y corregir los defectos. Observe cómo la carga de revisión se distribuye realmente entre su equipo; de lo contrario, corre el riesgo de sobrecargar a sus ingenieros senior, retrasar sus lanzamientos o causar problemas graves de producción.

Punto ciego 3: Trabajo oculto

Los refactorings y los cambios de arquitectura tienden a ocultarse dentro de otros tickets, si es que aparecen en el sistema de tickets. La IA produce más de este tipo de trabajo, no menos. Un agente no duda en tocar doce archivos para corregir un error, mientras que un humano podría detenerse y reconsiderar. El trabajo que omite el sistema de registro también omite la planificación, lo que significa que su modelo de capacidad es incorrecto, y cada pronóstico construido sobre él también lo es. 

Para entender cuánto trabajo se está realizando realmente, necesita observar cuánto está cambiando realmente en la base de código y en el historial de pull requests. Sin eso, su plan de capacidad se basa en lo que la gente recordó registrar, no en lo que realmente hizo. 

Punto ciego 4: Deriva de calidad

La misma encuesta encontró que casi la mitad de los líderes de ingeniería tienen dificultades para detectar problemas de seguridad semana a semana. La complejidad, la duplicación y las dependencias que no encajan se acumulan a lo largo de muchos cambios pequeños y razonables individualmente. Ninguno de ellos parece alarmante por sí solo. En el mismo estudio de caso de Stanford, la calidad del código cayó un 9 % y su variación se más que triplicó. Mientras que el promedio cambió un poco, la dispersión (la parte que usted nota) cambió mucho. Con el volumen de IA, se acumulan más rápido de lo que la mayoría de los procesos de revisión pueden detectar. La deriva tiende a manifestarse como una alerta en guardia vinculada a una dependencia que nadie recuerda haber revisado. Para cuando esto ocurre, existe una buena probabilidad de que un cliente lo haya notado primero.

Observe las tendencias en hallazgos de seguridad, dependencias y fallos y recuperaciones, no el commit individual. La complejidad y la duplicación que se van acumulando durante varias semanas importan más que cualquier cambio que sea señalado en la revisión. Sin eso, detecta la deriva de la manera en que la mayoría de los equipos aún lo hacen: después de que ya ha causado un incidente. 

Punto ciego 5: Gasto no comprobado

Una vez que la adopción de IA deja de ser un debate, el gasto en IA y el ROI se convierten en la cuestión en la que todos se centran. Finanzas quiere saber qué es capitalizable versus operativo. La dirección quiere saber en qué resultó la inversión. La mayoría de los equipos todavía toman decisiones sobre herramientas, licencias y personal basándose en la intuición, no en pruebas del vínculo entre el dinero y el trabajo entregado.

Observe a dónde fluye realmente el esfuerzo de ingeniería en la propia base de código, trimestre tras trimestre, no donde la hoja de ruta dice que debería fluir. Sin ese vínculo, está defendiendo el presupuesto del próximo año con anécdotas, y las anécdotas no sobreviven a una conversación dura con el CFO.

Comienza con lo que no puedes ver

La pregunta de Finanzas sobre el gasto capitalizado y una página de guardia a las 2 a.m. parecen no estar relacionadas, pero no lo están. Ambas pueden ser “estimadas” a partir de la actividad. Pero ambas son realmente respondibles, con evidencia, a partir del propio código.

La respuesta de DORA a todo esto es el propio sistema de ingeniería: calidad de la plataforma, claridad del flujo de trabajo, alineación del equipo. Así es, y tampoco es el paso uno. No puedes arreglar un sistema que no puedes ver. Cada una de esas cinco áreas es algo que debes poder observar antes de poder argumentar una inversión en ella.

El primer paso útil no es una herramienta nueva ni un proceso nuevo. Es conocerse a uno mismo, con honestidad, y determinar cuáles de estas cinco áreas son puntos ciegos donde carece de evidencia real. La mayoría de los líderes pueden identificar de inmediato (y están prestando atención a) problemas en una de estas áreas. Sin embargo, son las áreas donde tiene menos información las que probablemente aparezcan y le causen problemas a medida que continúa adoptando IA.