«En Dios confiamos; todos los demás que aportan datos». Este principio ha guiado mi enfoque al evaluar herramientas de programación de IA, pero me di cuenta de que necesitaba predicar con el ejemplo.
Hace años, realicé la capacitación sobre Proceso de Software Personal (PSP) e incluso la adapté para impartirla en la Universidad ORT Uruguay. El valor educativo de esta experiencia lo publiqué con mis alumnos en 2011 (véase Dymenstein, Martin, Alfredo Etchamendi, Fernando Maidana, Santiago Matalonga y Tomás San Feliu. «Hacia un enfoque orientado al estudiante para la enseñanza de la disciplina PSP»).CIESC 2011(Quito), CLEI, 2011.)
Entonces, para evaluar mi interacción con los asistentes de codificación de IA, decidí aplicar la disciplina del Proceso de Software Personal (PSP) a mi propio trabajo de desarrollo asistido por IA y rastrear cada defecto.
Durante cuatro semanas de desarrollo —creación de cuadernos Jupyter para el análisis de investigación, desarrollo de ejercicios de programación para mi docencia y desarrollo de una herramienta de extracción de datos de LLM (para un artículo en revisión)— registré meticulosamente cada defecto que se me escapó en las fases iniciales de desarrollo y prueba. Los resultados ofrecen una visión realista que valida las preocupaciones que he planteado sobre la inversión en herramientas, las mediciones de productividad y la necesidad de una evaluación rigurosa (en mis publicaciones anteriores).
Los datos: 16 defectos, 160 minutos, duras verdades
Entre el 9 de mayo y el 5 de junio de 2025, trabajando con GitHub Copilot en proyectos de Python, Java y LaTeX, registré 16 defectos que requirieron depuración tras considerar completada la tarea de desarrollo. El desglose cuenta una historia que todo director de tecnología que invierta en herramientas de IA debería comprender:
Atribución de defectos:
– Defectos causados por LLM: 12 (75%)
– Defectos causados por el hombre: 4 (25%)
Tiempo total de depuración:160 minutos
– Tiempo promedio por defecto LLM: 8,7 minutos
– Tiempo promedio por defecto humano: 4,25 minutos
Un caso atípico notable: pasé 45 minutos intentando configurar GitHub Actions usando Visual Studio Code y, durante la mayor parte de ese tiempo de depuración, asumí que el problema estaba en mi archivo YAML, cuando en realidad no lo estaba.
Tipos de defectos LLM más comunes:
– Casos de límite/borde no previstos: 5 ocurrencias
– Errores de sintaxis: 4 ocurrencias
– Problemas de inicialización/tipo de variable: 3 ocurrencias
Puede acceder a la hoja de cálculo de Google aquí:https://docs.google.com/spreadsheets/d/1dqriQs0l1UZzwZjMxb7wFI8797vK2OnjYrOCAmyAaDI/edit?usp=sharing
El costo oculto de la “productividad”
Estos datos muestran la brecha entre las ganancias de productividad prometidas y la realidad del desarrollo asistido por IA. Si bien Copilot sin duda me ayudó a escribir código más rápido, los 135 minutos dedicados a depurar los defectos generados por LLM representan una carga oculta para esa productividad.
Más preocupante es el patrón de tipos de defectos. Los casos límite y las condiciones límite —el tipo de programación defensiva que distingue el software robusto de las demostraciones frágiles— obstaculizaban constantemente la IA. No se trata de errores tipográficos ni descuidos simples; son lagunas fundamentales en la comprensión del contexto y los requisitos que requieren juicio humano para resolverse.
El hecho de que los defectos de LLM tardaran el doble en depurarse en promedio (8,7 frente a 4,25 minutos) también sugiere algo importante: los errores generados por la IA suelen ser más sutiles y difíciles de diagnosticar que los errores humanos. Cuando cometo un error de copiar y pegar, normalmente lo detecto rápidamente. Cuando Copilot genera código con versiones de API incorrectas o indicaciones malinterpretadas, el proceso de depuración requiere una investigación más profunda.
El problema del contexto se materializó
En mi opinión, esta experiencia refuerza los argumentos que he presentado en artículos anteriores sobre las limitaciones de las mediciones actuales de productividad. La sesión de depuración de 30 minutos para un defecto de “Generación incorrecta”, donde el LLM malinterpretó mi instrucción, ilustra a la perfección por qué medir la velocidad de codificación sin tener en cuenta la comprensión del contexto arroja resultados engañosos.
Considere este patrón: escribía una instrucción, Copilot generaba código aparentemente correcto (incluida mi revisión), lo integraba en mi proyecto y solo durante la ejecución descubría que la IA había pasado por alto contexto crucial sobre mi caso de uso específico. Los errores de condición de borde (cinco ocurrencias distintas) seguían el mismo patrón: la IA optimizaba para el caso común, ignorando las condiciones límite que los desarrolladores humanos aprenden a anticipar con la experiencia.
El desafío de la integración
Lo que estos datos no captan —pero mi experiencia lo destacó— es la sobrecarga cognitiva que supone trabajar con la asistencia de IA. Cada sugerencia requiere una evaluación: ¿Es correcta? ¿Se adapta a mi contexto? ¿Resolverá casos excepcionales? Esta evaluación constante genera una carga mental que no se refleja en las métricas de productividad, pero que afecta a la eficacia general del desarrollo.
Por ejemplo, al desarrollar ejercicios de programación para estudiantes, los defectos de caso límite creados por Copilot habrían afectado directamente la calidad educativa. Un error sutil en la gestión de excepciones o la inicialización de variables en un ejercicio estudiantil podría confundir a los estudiantes o enseñarles patrones incorrectos, con consecuencias que se extienden mucho más allá de los 5 a 10 minutos necesarios para corregir el error.
Conectando con la realidad organizacional
Estos datos personales ayudan a explicar la paradoja de la productividad que observo en mis proyectos de coaching. Los mismos patrones que afectaron mis proyectos a pequeña escala (malinterpretación del contexto, fallos en los casos límite, sobrecarga de ingeniería rápida) se amplifican en entornos organizacionales donde varios desarrolladores utilizan herramientas de IA con distintos niveles de habilidad y prácticas inconsistentes. Las prácticas de DevOps actúan como ecocámaras para estos errores y los trasladan a producción.
Un director de tecnología que se ocupe de requisitos poco claros descubrirá que las herramientas de IA amplifican la ambigüedad en lugar de resolverla. Una organización en expansión con problemas de coordinación no los resolverá generando código más rápido si este introduce defectos sutiles que aparecen durante la integración. Un Scrum Master que monitoree la velocidad podría ver una mejora en las tasas de finalización de los puntos de historia, mientras que las métricas de calidad se deterioran.
El imperativo de la medición
Este ejercicio reforzó la importancia de la medición objetiva sobre las promesas de los proveedores o las exageraciones del sector. La disciplina de registrar cada defecto, categorizar su origen y monitorear el tiempo de resolución proporcionó información que sería imposible obtener con métricas de productividad de alto nivel o impresiones subjetivas.
Para las organizaciones que invierten en herramientas de desarrollo de IA, la lección es clara: implementar sistemas de medición que capturen la perspectiva completa de costo-beneficio. Monitorear no solo la velocidad de generación de código, sino también el tiempo de depuración, las tasas de defectos, la sobrecarga por cambio de contexto y las métricas de calidad. Medir lo que importa en su contexto específico, no lo que les conviene a los proveedores de herramientas.
El camino equilibrado hacia adelante
No estoy en contra de las herramientas de programación de IA; los datos demuestran que aportan un valor genuino. Pero este ejercicio de PSP demuestra por qué el enfoque equilibrado que he defendido en artículos anteriores sigue siendo esencial. Las herramientas de IA son potentes amplificadores que requieren una implementación rigurosa, una medición cuidadosa y expectativas realistas.
Los 160 minutos que pasé depurando representan el costo oculto de “La era de las herramientas.Es hora de que los estudios de productividad de los proveedores no capturen los resultados que la investigación académica tiene dificultades para medir y las métricas organizacionales a menudo pasan por alto. Pero también es tiempo bien invertido en comprender el verdadero impacto de estas herramientas en la efectividad del desarrollo.
Las empresas que tendrán éxito con los asistentes de codificación de IA serán aquellas que los implementen con la misma disciplina que aplicarían a cualquier otra inversión en productividad: criterios de medición claros, expectativas realistas y evaluación sistemática de los resultados reales en lugar de los beneficios prometidos.
Los datos de su organización serán diferentes a los míos: herramientas diferentes, contextos diferentes, patrones de defectos diferentes. Pero el principio sigue vigente: en un entorno saturado de afirmaciones sesgadas y métricas incompletas, la información más valiosa proviene de la medición rigurosa de su propia experiencia. Confíe en los datos, especialmente cuando los recopile usted mismo.
Contactame para evaluar y mejorar tu sistema de medición en la organisación.
Discover more from The Software Coach
Subscribe to get the latest posts sent to your email.
