La tradición oral que dio origen al software podría no sobrevivir a la IA

Hasta que me convertí en ingeniero de software a los 32 años, toda mi vida profesional giró en torno a la palabra escrita. Era historiador, firmemente arraigado en libros, archivos y artículos. Cambié de carrera por razones que no vienen al caso y sobre las que he escrito en otros lugares; baste decir que el mercado laboral para los historiadores era tan malo que quise hacer otra cosa. Me hice ingeniero de software porque me gustaban los aspectos de resolución de problemas y diseño. Trabajo como ingeniero de backend para Hagerty Insurance. De alguna manera, he logrado adaptarme, e incluso destacar en ello. Pero lo que sigue desconcertándome de muchas maneras en este trabajo es que se escribe muy poco.

La tradición del desarrollo de software

La realidad es esta: el desarrollo de software es una tradición oral. Especialmente cuando uno empieza como ingeniero, no trabaja con código completamente nuevo; probablemente se encuentre en una base de código heredada. Se enfrentará a más preguntas que respuestas sobre qué hace cada cosa o por qué se escribió de esa manera, y cuando busque respuestas, no encontrará mucha información escrita. Tal vez exista un documento de diseño inicial, pero luego resulta que todo se revisó sustancialmente antes de que comenzara el trabajo. Quizás haya algunas páginas wiki que expliquen problemas conocidos, algunos de los cuales se resolvieron hace mucho tiempo y otros que se han quedado olvidados en el código. Alguien podría haber dejado un comentario en el propio código, pero normalmente es una advertencia para no cambiar algo o algo más se romperá.

A este nivel, ser historiador resultó ser una ventaja cultural inesperada. Los historiadores están acostumbrados a reconstruir historias a partir de fragmentos, en lugar de buscar explicaciones claras en los archivos. Así que, cuando llega el momento de realizar un cambio en un código desconocido, normalmente se recurre a otro desarrollador para pedir ayuda. Llevan el tiempo suficiente en el puesto como para comprender lo que sucede internamente y podrían explicar por qué cambiar algo aparentemente inofensivo podría convertirse en una muy mala idea.

La ingeniería de software mantiene una relación ambivalente con la documentación. En teoría, todos coinciden en que la documentación es importante, pero en la práctica resulta inconsistente, obsoleta o inexistente. Parte de esto se debe a la simple inercia: escribir documentación suele ser menos interesante que escribir el código en sí. Pero también hay una cuestión ideológica. El movimiento Agile surgió, en parte, como reacción contra la metodología Waterfall, que requería una documentación excesiva, y uno de sus valores fundamentales prioriza explícitamente el “software funcional sobre la documentación exhaustiva“. Al escapar de la sobredocumentación burocrática, la industria también normalizó la falta de documentación.

La documentación contra la IA

Esta comparación podría hacer estremecer a algunos de mis amigos que aún estudian en la universidad. Los ingenieros de software no ejecutamos nuestro código; no lo contamos como una historia, y si alguien me pregunta por qué escribimos un procedimiento almacenado en lugar de otra cosa, no voy a responder en verso. Pero las tradiciones orales sí tienen un componente didáctico, y a ese nivel se reproduce entre los ingenieros. Ciertos patrones o implementaciones de desarrollo de software se priorizan sobre otros, o se despriorizan (los ingenieros suelen tener secciones de un código que utilizan como advertencia de lo que no se debe hacer). Esta es una parte fundamental de cómo se forma a los nuevos ingenieros.

No es que el conocimiento oral sea malo ni que la documentación sea intrínsecamente buena. Las sociedades que dependían de la tradición oral para transmitir cultura e información lo hicieron de forma estable durante miles de años en muchos casos. Desarrollaron métodos muy precisos para transmitir la información. Pero en un aspecto, la ingeniería de software es muy diferente: la rotación de ingenieros de software. Las sociedades que dependían de la tradición oral no perdían a sus narradores cada cinco o siete años, pero los empleadores, incluso en empresas tecnológicas prestigiosas, pueden esperar razonablemente perder ingenieros cada pocos años. Me sorprendió descubrir que, tras unos pocos años en un trabajo, había proyectos en los que yo podía ser la única persona que había trabajado originalmente en ellos. Y la clave, más allá de “¿qué hace esto?”, es “¿por qué se escribió de esta manera y qué pasará si cambio algo?”. 

El resultado es una constante pérdida de conocimiento del dominio que empeora con la IA. No solo dificulta la incorporación de nuevos empleados, sino que también complica enormemente la solución de la deuda técnica arraigada. Si personas nuevas en un código base se lanzan a realizar cambios, se corre el riesgo de introducir una gran inestabilidad. Cada intento de solucionar la deuda técnica, que de por sí es un problema creciente desde hace décadas, resulta mucho más difícil y arriesgado, lo que hace que abordarla sea aún menos atractivo. Además, dificulta y prolonga la incorporación de nuevos empleados, e incrementa la probabilidad de cometer errores perjudiciales.

Cómo intervendrá la IA

Por lo tanto, resulta tentador pensar que la IA generativa intervendrá y resolverá este problema. Al fin y al cabo, incluso si no se desea utilizar un modelo de lenguaje complejo (MLC) en una base de código heredada (y existen muchas razones para no hacerlo), que genere documentación sobre el propio código podría parecer una solución ante la falta de información escrita. La IA sin duda, puede resumir el código.

Pero un momento con esa idea. Más allá de las alucinaciones de IA, existe un problema más profundo: la documentación forma parte del proceso de pensamiento. Ya sea que esté escribiendo historia o software, plasmar un enfoque por escrito me ayuda a refinarlo antes de dedicarle horas a su implementación. La documentación también refleja la intención. Un modelo de lenguaje natural de IA (MLN) puede resumir la función de un código fuente, pero no puede explicar con certeza por qué un desarrollador eligió un enfoque u otro, ni qué ventajas y desventajas influyeron en esa decisión. 

Además, es una oportunidad para que alguien más entienda por qué hiciste lo que hiciste. Si planean cambiar lo que escribí (especialmente dentro de unos años), podrían comprender por qué necesitaba escribirlo de esa manera y qué se perdería si lo eliminas. Una IA puede leer el código que he escrito. Incluso podría escanear una base de código extensa y resumir con precisión su funcionamiento. Pero no puede evaluar la intención del autor.

La solución

La solución no reside en delegar el trabajo mental, al menos si se busca reducir la deuda técnica y facilitar la incorporación de nuevos usuarios. En cambio, se trata de recuperar la importancia de la palabra escrita, o al menos de lo que nos resulte útil. Así como existe una cultura de la oralidad en el sector tecnológico, también existe una cultura de la palabra escrita, y ambas pueden coexistir. Uno de los mejores ejemplos se dio durante el desarrollo de ARPANET, donde los ingenieros crearon una cultura en torno a las RFC (Requests for Comments): memorandos informales utilizados para debatir estándares, problemas, propuestas y mejores prácticas. Algunos eran serios, otros humorísticos, pero todos estaban escritos para otros ingenieros. Imagínese tratar la documentación de la misma manera: no como una tarea burocrática para los gerentes, sino como una forma de comunicación con quienes heredarán su código en el futuro. 

Rechazar la documentación es un grave error. Ya se ha hecho mal en el pasado: Waterfall fracasó en gran medida porque los ingenieros redactaban informes y documentos para los gerentes de proyecto y los administradores. Podemos dejar que ellos redacten su propia documentación, y deberían hacerlo. Por nuestra parte, debemos redactar la nuestra.