- El desarrollo asistido por IA hace que la velocidad de producción de código supere la velocidad de comprensión humana, generando “deuda cognitiva”
- Aunque el código funcione correctamente y pase las pruebas, se acumula un estado en el que los propios desarrolladores no entienden la estructura ni el porqué del código
- Las limitaciones de los revisores, la pérdida del conocimiento tácito en la organización y las carencias de aprendizaje de los desarrolladores junior aceleran esta deuda
- Las organizaciones solo miden métricas centradas en la velocidad (DORA, story points, etc.) y no logran detectar la falta de comprensión
- Cuanto mayor es la brecha entre productividad y comprensión, mayor es el riesgo a largo plazo de fallas de mantenimiento, ruptura del conocimiento y estancamiento en el crecimiento de los ingenieros
El desfase de comprensión (The Comprehension Lag)
- La codificación manual realiza al mismo tiempo dos procesos: producción y asimilación, y la fricción de teclear impulsa el pensamiento
- Al escribir código, se forman de manera natural modelos mentales e intuición
- El desarrollo asistido por IA separa ese proceso, por lo que la velocidad de salida se dispara, pero la velocidad de comprensión sigue atada a los límites humanos
- Esa brecha entre salida y comprensión es precisamente la deuda cognitiva y, a diferencia de la deuda técnica, no se ve en las métricas de velocidad
- El problema aparece más tarde en métricas de confiabilidad como aumento del MTTR y mayor tasa de fallos por cambio
Lo que realmente miden las organizaciones (What Organizations Actually Measure)
- Las organizaciones solo miden resultados visibles (cantidad de funciones, commits, velocidad de revisión, etc.)
- En el pasado, el resultado y la comprensión estaban conectados, así que se asumía que si una función se desplegaba, también existía comprensión
- Pero en la era de la IA, es posible desplegar funcionalidades con solo una comprensión superficial, por lo que esa suposición ya no es válida
- Las métricas organizacionales no capturan la falta de comprensión, distorsionando los sistemas de evaluación y recompensa
El dilema del revisor (The Reviewer’s Dilemma)
- Con la IA, un junior puede generar código más rápido que un senior
- Los revisores senior no tienen tiempo para examinar en profundidad volúmenes enormes de código, por lo que terminan sacrificando la profundidad de la revisión
- Como resultado, se derrumba la premisa de que “código revisado = código comprendido”
- Como la presión organizacional prioriza la velocidad, se fortalece una cultura centrada en el volumen procesado más que en la calidad de la revisión
El patrón de burnout (The Burnout Pattern)
- Los ingenieros que usan herramientas de IA experimentan un cansancio en el que conviven alta producción y baja confianza
- El código funciona, pero persiste la ansiedad de no comprender por completo el sistema que ellos mismos construyeron
- Un sistema de evaluación centrado en la velocidad hace que invertir tiempo en una comprensión profunda se convierta en una desventaja, acelerando la deuda cognitiva
El colapso de la memoria organizacional (When Organizational Memory Fails)
- El conocimiento organizacional está compuesto por conocimiento explícito documentado y conocimiento tácito en la mente de los desarrolladores
- El desarrollo con IA acorta el proceso de formación del conocimiento tácito (la experiencia de implementación directa), por lo que no se produce acumulación de conocimiento
- Como resultado, el sistema funciona, pero cada vez quedan menos personas capaces de entenderlo
- Cuando surge un problema, se llega a un estado en el que nadie puede explicar el contexto del sistema
Cómo se acumula la deuda (How the Debt Compounds)
- Primero, cuanto más antiguo es el código, mayor es el riesgo: el código que ya se entendía de forma incompleta cuando se escribió termina volviéndose totalmente opaco
- Segundo, el tiempo de recuperación ante incidentes se dispara: aparece la situación de depurar “una caja negra creada por otra caja negra”
- Tercero, la ausencia de futuros ingenieros senior: la dependencia de la IA elimina la curva de aprendizaje y provoca un vacío de liderazgo a largo plazo
La visión del director (The Director’s View)
- La dirección solo percibe señales positivas como mejora de productividad, reducción de plazos y eficiencia del personal
- Como no existen métricas para medir la “profundidad de comprensión” o la “capacidad de explicación”, la deuda cognitiva no se reporta
- Por eso, la toma de decisiones basada en datos es racional pero incompleta, y el riesgo real queda oculto
Dónde falla este modelo (Where This Model Breaks)
- El concepto de deuda cognitiva no se aplica de la misma forma a todas las tareas
- Puede ser adecuado para tareas repetitivas simples o experimentos rápidos
- En el pasado también existían diferencias individuales en el nivel de comprensión, por lo que podría tratarse más de un desplazamiento en la distribución que de un fenómeno totalmente nuevo
- También existe la posibilidad de que, en el futuro, mejores herramientas y documentación reduzcan la brecha de comprensión
El problema de la medición (The Measurement Problem)
- Las organizaciones solo optimizan aquello que pueden medir
- La velocidad se puede medir, pero la comprensión no
- Mientras la comprensión no se refleje en el sistema de evaluación, seguirán vigentes los incentivos centrados en la velocidad
- Esto no es un fracaso individual ni gerencial, sino el resultado de un sistema de medición heredado de una era pasada que ya no coincide con la realidad actual
- Al final, es probable que esta brecha se manifieste en mayores costos de mantenimiento, demoras en la respuesta a incidentes y exposición de vulnerabilidades del sistema
- El texto concluye con la idea de que “los sistemas se optimizan según lo que se mide. Pero lo que medimos ahora ya no captura lo que realmente importa”
3 comentarios
Últimamente he estado pensando en algo parecido, así que ayer escribí una entrada de blog sobre la deuda cognitiva. Parece que todos estamos haciéndonos preocupaciones similares.
¿Cómo deberíamos evaluar la comprensión del código? ¿Habría que medirla incluso haciendo cuestionarios basados en la base de código interna?
Comentarios en Hacker News
La experiencia de los últimos meses me hizo sentir muy identificado con el artículo
El proyecto en el que trabajo ha crecido de forma constante, pero la cantidad de ingenieros incluso ha disminuido
Aumentamos la dependencia de las pruebas y cambiamos a desarrollo basado en simuladores. Rara vez validamos en el sistema real, y cuando lo hacemos, siempre tocamos las partes más complejas
Desde el año pasado empecé a notar que incluso los detalles de funciones en las que trabajé durante meses se me olvidaban rápido. Y eso fue antes de que los agentes de código se adoptaran en serio
Cuando entraron los agentes, la revisión de PR se volvió mucho más implícita, así que tengo que concentrarme de forma deliberada porque el contexto no se me queda en la cabeza. Mis compañeros de equipo reportan lo mismo
Ahora estamos probando varias cosas, como hacer commit del plan del agente junto con el código. Gracias a eso, el proceso se está volviendo más sistemático y explícito
Pero parecía que el gerente de ingeniería casi no era consciente de este aumento de la carga cognitiva
La premisa del texto, “el desarrollador recuerda el código que escribió hace 6 meses”, es falsa
Desde antes, entender el código al escribirlo era más fácil que al leerlo. Joel Spolsky también dijo que “leer código es más difícil que escribirlo”
El problema del “código que no se entiende” ya existía antes de la IA
Por ejemplo, como en el caso de eliminación del código de Pinball de Microsoft, hubo veces en que código antiguo subcontratado era tan complejo que nadie podía entenderlo y al final se abandonó la funcionalidad
El caso de la base de código de Oracle RDBMS es parecido
Me llamó la atención la frase “un sistema extraño que funciona con normalidad”
Se parece a lo que siente un desarrollador al pasar a un rol de gerente. Cuanto más te alejas del código, más abstracta y fragmentada se vuelve la comprensión
Lo más doloroso fue la idea de que “los ingenieros que intentan entender a fondo se quedan atrás en las métricas de velocidad”
El mercado prioriza la velocidad por encima de la calidad, y al final los ingenieros cuidadosos terminan siendo despedidos
Tal vez ya sea hora de entrar en la era de “LGTM, LLM”
La industria siempre se va al extremo y luego encuentra un equilibrio. El problema es la expectativa imposible de exigir 20 veces más productividad y a la vez 100% de responsabilidad
Al final, o se renuncia a la comprensión, o solo se acepta una mejora de productividad de alrededor del 20% como máximo
Esto me recordó la filosofía Worse Is Better de Richard Gabriel
El código de IA a menudo elige la simplicidad antes que la exactitud, pero ese enfoque realista de “si funciona, gana” podría terminar imponiéndose
Una vez que existe un sistema que funciona, se puede mejorar de forma gradual
Nuestro equipo también vivió exactamente el mismo fenómeno del que habla el artículo durante los últimos 6 meses
La frase central, que el desarrollo asistido por IA interrumpe la acumulación de conocimiento implícito, es completamente acertada
Aun así, este fenómeno podría ser una etapa transitoria
A largo plazo, los LLM podrían ofrecer un valor de meta nivel al organizar bien la estructura del código y ayudar a que los humanos solo necesiten entender a fondo cuando haga falta
Si falta documentación, el equipo de soporte del producto también se ve muy afectado
Cuando los clientes preguntan cómo funciona el producto, si ni los ingenieros entienden bien el código que escribieron, es difícil responder
Si las actualizaciones van demasiado rápido, a otros equipos les cuesta seguir el ritmo
Cuando aparecieron los lenguajes de alto nivel pasó algo parecido, pero al final salió bien
Entonces, ¿también estaría bien que los LLM abstraigan la comprensión del código?
La diferencia es que los compiladores son determinísticos pero los LLM son probabilísticos