- En desarrollo de software, el Bus Factor es un concepto que indica cuántas personas deben poseer cierto conocimiento para que el proyecto pueda mantenerse; antes, el peor caso era 1
- Sin embargo, desde la publicación de ChatGPT (30 de noviembre de 2022), a medida que la IA generativa fue adoptada masivamente, muchas personas dejaron de preservar el conocimiento por sí mismas y comenzaron a depender de la IA, creando en la práctica una situación de bus factor 0
- En el trabajo de programación, cada vez más desarrolladores usan tal cual el código y las funcionalidades generadas por LLM, renuncian al esfuerzo de entender la base de código y pasan al “vibe coding”
- Como resultado, al corregir bugs, aplicar parches de seguridad o ampliar funcionalidades, pueden enfrentarse a una situación en la que nadie sabe por qué el código fue escrito de esa manera
- Esto plantea riesgos graves para la confiabilidad y la seguridad del software, y existe una limitación fundamental hasta que llegue el día en que la IA genere código perfecto de forma perfecta
El concepto y la historia del bus factor
- El bus factor es un concepto que expresa numéricamente entre cuántas personas se comparte cierto conocimiento
- Ejemplo: si 3 personas saben cómo restaurar un respaldo de base de datos, el bus factor de esa función es 3
- Tradicionalmente, el peor valor era 1; si una persona perdía ese conocimiento, el proyecto no podía mantenerse
- La humanidad ha difundido ese conocimiento para superar esto mediante documentación, enseñanza, transferencia de conocimiento, seminarios, escuelas y muchos otros métodos
- Esto ha llevado a intentos sistemáticos de transmitir y preservar el conocimiento, invirtiendo enormes recursos humanos y tiempo
La adopción de la IA y el bus factor 0
- Con el lanzamiento de ChatGPT en noviembre de 2022, se abrió la era “AI First”
- En el proceso de generar código y funcionalidades, la IA ha excluido a muchas personas como sujetos de preservación del conocimiento, y estas comenzaron a depender de lo generado por la IA, reduciendo drásticamente su comprensión del proyecto
- Como resultado, aparece una situación en la que ya no hay nadie que posea el conocimiento, es decir, un escenario de bus factor 0
- Los programadores muestran una tendencia a no escribir ni comprender por sí mismos el código y las funcionalidades, sino a delegarlo por completo en la IA
- En este proceso, los desarrolladores evitan comprender la base de código y documentarla, y pasan a un patrón de simplemente volver a pedirle explicaciones a la IA
Problemas de programar con LLM
- Incluso dejando de lado los problemas de calidad del código, el punto clave es que leer y mantener código es intrínsecamente más difícil que escribirlo
- Antes, al menos un mentor o la documentación brindaban una ayuda mínima, pero en un entorno dependiente de la IA incluso esa red de seguridad desaparece
- En el desarrollo basado en LLM, el proceso de generación de código no queda registrado y ni siquiera la propia IA recuerda el contexto del código que generó
- Al final, los desarrolladores quedan en la situación de tener que analizar y modificar código escrito por la IA pero con un contexto poco claro
- Esto provoca un estado en el que nadie puede conocer la intención ni la estructura del código al resolver bugs, parchear vulnerabilidades de seguridad o actualizar dependencias
Riesgos desde la perspectiva del usuario
- No solo los desarrolladores, también los usuarios quedan expuestos al riesgo
- El software al que se suben documentos personales, información de tarjetas de crédito, fotos privadas o pensamientos íntimos podría haber sido creado con código cuyo propósito y estructura interna nadie conoce
- Esto implica riesgos graves en términos de protección de datos y confiabilidad, y genera dudas sobre la estabilidad del servicio
Conclusión
- El vibe coding que provoca un bus factor 0 es un enfoque fundamentalmente defectuoso
- Esta es una limitación inevitable mientras la IA no pueda generar código 100% correcto a partir de prompts 100% correctos
- Por lo tanto, en la situación actual, además del uso de la IA, no se puede pasar por alto la importancia de la preservación del conocimiento y la comprensión del código, y es indispensable mantener sistemas de gestión del conocimiento y documentación
3 comentarios
¿No sería que el bus factor se volvió infinito?
Si los desarrolladores de la empresa no tienen conocimiento, el bus factor converge a 0.
Opiniones en Hacker News
Usar un LLM para simplemente escupir una enorme cantidad de código sin revisar es una mala forma de usarlo; significa que esos proyectos están estructuralmente mal encaminados o que, en cuanto aparezcan bugs complejos, pronto se volverán imposibles de mantener. La verdadera fortaleza de los LLM está en situaciones como estas: cuando hay que aplicar algoritmos conocidos a estructuras de datos complejas ya existentes, cuando hay que levantar datos de prueba o el esqueleto de pruebas unitarias con muchas dependencias, cuando se crea un editor web visual y una API de backend con persistencia en sqlite, o cuando se deben aplicar cambios repetitivos a gran escala en una base de código usando algo que ni siquiera con expresiones regulares complejas sería fácil. En la práctica, gracias a los LLM puedes empezar en 2 minutos algo que normalmente te tomaría medio día o 3 días. Lo importante es que, aunque un LLM no pueda resolver problemas muy difíciles, aun así puede aumentar mucho la productividad. Te libera del trabajo repetitivo y aburrido para que te concentres en problemas más interesantes.
Pensé que un LLM terminaría en 2 minutos cambios repetitivos sobre una base de código grande, pero tras probarlo directamente con varios modelos grandes vi que, mientras más complejo se vuelve el contexto, más se acumulan los errores, y a veces incluso hace cambios no relacionados, así que al final no fue confiable. Es perfecto en ejemplos pequeños, pero se queda corto a medida que escala. Se puede mejorar usando un agentic loop, pero entre ejecutar y revisar repetidamente termina tomando mucho más tiempo. Es mucho más confiable pedirle al LLM que escriba un programa que automatice esos cambios.
Todos los ejemplos que diste suenan bien, pero en realidad hay muchos más casos de uso posibles. Tú hablaste de ejemplos propios de un desarrollador experimentado, pero incluso la gente con menos habilidad técnica o que apenas está aprendiendo ahora puede hacer muchas más cosas gracias a los LLM. Cosas por las que antes tenías que pagar 100 dólares, ahora puedes intentar hacerlas tú mismo en 3 minutos. Que el resultado sea perfecto y mantenible pasa a ser menos importante; mostrar lo que es posible tiene más valor.
Estoy de acuerdo con tu opinión, pero quería compartir una experiencia reciente que me dio risa. Le pedí a Claude que escribiera pruebas unitarias y, al revisar, resultó que mi código sí tenía un bug y la prueba lo detectó. Pero en lugar de corregir el bug, Claude intentó hacer que la prueba pasara simplemente evitando ejecutar esa prueba fallida; una anécdota bastante divertida de la vida real. Los LLM son débiles para definir requisitos, diseñar arquitectura y redactar especificaciones alineadas con los requisitos, pero son fuertes en tareas de alcance claro e impacto acotado, como escribir código.
Probé una etapa intermedia donde la AI hacía automáticamente la revisión del PR y luego yo hacía la revisión manual. La generación del código toma entre 5 y 10 minutos, y la revisión más commits adicionales normalmente toma entre 1 y 3 horas, pero lo he aplicado con éxito en varios proyectos (10~20k LOC, unas 100 archivos) usando este método. Si le das una buena especificación, muchas funciones quedan implementadas casi correctamente sin grandes cambios, y la mayor parte del trabajo posterior es refactorización basada en feedback. Claro, cuando no funciona bien, a veces resolverlo puede tomar casi un día, pero en general es una mejora de productividad de 3 a 5 veces. Para proyectos grandes, parece mejor dividir y modularizar.
Expresiones como “terminé x días de trabajo en 2 minutos con un LLM” son un poco exageradas porque no incluyen el tiempo de revisión. Si sumas el proceso real de revisar y validar, toma mucho más tiempo. Incluso puedes terminar cayendo justamente en el “método incorrecto” del que hablaste al principio.
Este artículo presenta varios problemas de la generación de código con AI, pero parece no considerar soluciones que ya existen o que podrían aparecer en el futuro. Antes también, si un equipo hacía aunque fuera un esfuerzo mínimo sobre su base de código, eso ayudaba a que una persona nueva pudiera entenderla. Me pregunto si no tiene experiencia con código legacy, o si de verdad cree que no se puede corregir el hecho de que la AI “olvide todo el contexto del proceso original de escritura”. También malinterpreta el problema de Bus Factor 0 como si solo pudiera resolverse con precisión perfecta al 100%, cuando en realidad los humanos tampoco son correctos al 100% todo el tiempo y aun así confiamos en ellos.
Sentí que el artículo ve el problema de una forma demasiado resumida. La realidad de no poder hacer siempre todo junto con la persona autora ya existe desde el principio. La sola existencia de un compañero o de una AI que te lo explique ya es un avance enorme. Parece que imagina un mundo sin humanos, pero en la práctica ya vivimos algo parecido muchas veces.
Yo soy el autor; estoy de acuerdo con la primera observación y creo que la AI irá cerrando esa brecha con el tiempo. Pero para entonces, algunos problemas quizá ya se hayan materializado. También está el problema de que quede código sin contexto lógico ni historial de decisiones. Se habla mucho de que la AI “siempre aprende”, pero en la práctica no aprende nada hasta que aparece un nuevo modelo. Los humanos tampoco somos correctos al 100%, pero no somos Bus Factor 0; además, es más fácil identificar y resolver problemas. Si también se resuelven los demás problemas, entonces el problema del bus factor también disminuirá.
He pensado que me habría encantado tener herramientas de AI cuando analizaba código legacy en el pasado. Hubo situaciones absurdas de verdad, tipo: “la última persona que editó este archivo Perl ahora es gerente de sucursal, ¿tengo que agendarle una reunión directamente?”.
Sobre la pregunta “¿por qué tendría que ser 100% exacto?”, creo que quienes son críticos de la AI a veces esperan justamente que la AI sea una solución mágica y perfecta. Se parece un poco al tono de alguien que se opone al tipado estático porque “ni siquiera detecta errores lógicos”.
Últimamente hay demasiadas imágenes hechas por AI en los blogs y, en vez de ayudar, muchas veces distraen y no aportan nada al contenido.
Hace poco me uní a un equipo con una base de código desastrosa; la mayoría de los desarrolladores anteriores ya se habían ido, y quienes quedaban tampoco conocían bien el código. Era literalmente Bus Factor 0. Sorprendentemente, gracias a la AI mejoraron mucho la velocidad para entender el código, captar la intención y depurar. Empezamos a extraer documentación directamente del código usando AI. La documentación o la tradición oral pueden distorsionarse, pero el código en sí es la verdad. Con ayuda de la AI pudimos crear un entorno donde el código se explicaba a sí mismo, y la mejora de productividad fue grande.
El Bus Factor siempre fue un problema, incluso antes de los LLM. La mayoría de las empresas no estructuraban el trabajo para que varias personas entendieran al menos una parte de él. Aunque hubiera varias personas asignadas a distintas áreas, el volumen de trabajo seguía creciendo y al final se repetía la situación en la que nadie lograba entenderlo todo. Evitar esto por completo requiere una gestión de ingeniería enorme, como rotar a la gente dentro de la base de código, y por lo general no se logra a la perfección por la presión de avanzar rápido. Organicé mis reflexiones como CTO sobre esto en un libro aquí, disponible sin importar el precio. Creo que, en el fondo, el principio de construir sistemas con LLM no es muy distinto del de trabajar con 10 desarrolladores externos.
El Bus Factor ya era un problema antes de los LLM y es un término técnico que existe desde hace mucho. El TFA (artículo original) critica la tendencia de pasar de un Bus Factor de 1 a uno de 0.
Lo que pasa es que el volumen de trabajo sigue creciendo, pero no porque el trabajo vaya avanzando hacia una forma más recomendable, sino porque solo se repite el patrón de terminarlo a medias para cumplir la fecha límite. Poner algunos obstáculos de proceso no resuelve eso.
Nuestro cerebro tiende a ahorrar energía con la información que no usa frecuentemente, así que cuanto más te alejas de algo, peor lo entiendes o más lo olvidas. Incluso si haces tú mismo toda la revisión del código, tus habilidades pueden terminar degradándose. Es parecido a cuando un ingeniero pasa demasiado tiempo haciendo trabajo de management y ya casi no puede resolver problemas técnicos. En la automatización de autos también pasa que mantener al humano involucrado de forma continua en las etapas intermedias (level2→5) es difícil, y si la máquina no es 100% confiable al final aparecen problemas.
Hay un punto realmente importante en esta discusión: en realidad estas herramientas y flujos de trabajo apenas están empezando. Estoy convencido de que en el futuro la AI podría resolver este tipo de problemas mejor que los humanos. También he experimentado usando LLM, con algunos éxitos y algunos fracasos, pero en ciertos ámbitos muestran capacidades claramente sobresalientes. Los LLM no se cansan de actualizar con cuidado la documentación, los comentarios, el README y hasta los ADR. Si tienen suficiente guía y estructura, una base de código hecha con LLM podría incluso ser más fácil de abordar a largo plazo, precisamente porque tiende a estar mejor documentada.
Creo que el artículo pasa por alto que incluso el código por sí mismo permite leer bastante bien la intención. Los humanos, y probablemente también los LLM, somos seres bastante predecibles. Normalmente resolvemos problemas parecidos de maneras parecidas. Si ves cómo está escrito el código, puedes encontrar pistas sobre por qué, quién y cuándo resolvió cierto problema. Claro, hay mucha información que se pierde, pero eso también ocurre en organizaciones donde el personal cambia con frecuencia.
Creo que el proceso de pensamiento humano termina reflejándose en el código, pero aun así es un proceso muy inferior a tener a alguien a quien puedas preguntarle directamente. La ingeniería inversa normalmente solo se hace cuando es estrictamente necesaria, y con código legacy al final todos terminan haciéndola. Pero en términos de productividad no es algo bueno. Y en una base de código hecha con LLM no hay una intención única, sino una mezcla de intenciones de muchas personas distintas, así que ver solo algunos fragmentos puede volver aún más confuso cuál era el propósito original. Incluso puede llevar a la ilusión de que el código generado por AI tiene exactamente el mismo significado riguroso que el escrito por humanos, y eso hace que interpretarlo sea todavía más difícil.
La capacidad de inferir intención solo viendo el código depende del alcance y de la escala. Si se trata de algo como Arduino con un límite de 32kB, entenderlo es fácil. Pero en una plataforma compleja con decenas de microservicios entrelazados, especialmente si fue hecha en modo “vibe coding”, si me tocara hacerme responsable yo simplemente querría rendirme.
Estoy de acuerdo con el punto central y la conclusión del artículo, pero durante 20 años he pasado varias veces por situaciones parecidas (entornos donde no había nadie a quien preguntar, o donde la persona realmente responsable ya se había ido). Con los LLM esto puede acelerarse un poco, pero me parece más una aceleración de un problema viejo que un problema completamente nuevo. Aprecio que se ponga el tema sobre la mesa.
También puede pasar lo contrario. Si dejas bien documentados, probados y configurados los codebases para que la AI pueda trabajar bien con ellos, esperaría que dentro de un año un agente de AI pueda hacer esas mismas tareas más rápido.
Me intriga cómo una AI Coding Tool llegaría a adoptar la misma actitud de algunos desarrolladores de decir “todo el código anterior está mal, así que hay que reescribirlo completo”. También sería interesante si en el futuro el propio sistema de CI/CD terminara reescribiendo proyectos enteros con AI.
Yo soy el autor, y si eso ocurre, entonces el Bus Factor ya estaría subiendo. Es decir, lo esencial es que la información deje de quedar solo en la cabeza de alguien y pase a almacenarse y preservarse de distintas formas.