El código es una responsabilidad (no un activo). Los jefes técnicos no entienden esto. Piensan que la IA es genial porque produce 10.000 veces más código que un programador, pero eso solo significa que genera 10.000 veces más responsabilidades. 1/

Si desea leer o compartir una versión en formato de ensayo de este hilo, aquí hay un enlace a él en , mi blog sin vigilancia, sin publicidad, sin rastreadores: 2/

La IA es el amianto que estamos empujando en las paredes de nuestra sociedad de alta tecnología: El código es una carga. Las *capacidades* del código son activos. 3/

El objetivo de una empresa tecnológica es tener código cuyas capacidades generen más ingresos que los costes asociados a mantener ese código en funcionamiento. 4/

Durante mucho tiempo, las empresas han alimentado la falsa creencia de que el código cuesta menos ejecutarse a lo largo del tiempo: tras un periodo inicial de ajuste en el que se detectan y corrigen los fallos del código, el código deja de necesitar mantenimiento significativo. 5/

Al fin y al cabo, el código es una máquina sin partes móviles: no se desgasta; ni siquiera se desgasta. Esta es la tesis del libro de Paul Mason de 2015 *Postcapitalism*, un libro que ha envejecido notablemente mal (aunque quizás no tan mal como la propia credibilidad política de Mason). 6/

El código no es una máquina infinitamente reproducible que no requiera trabajo. Más bien, es una máquina frágil que requiere medidas cada vez más heroicas para mantenerla en buen estado de funcionamiento, y que eventualmente se "desgasta" (en el sentido de necesitar una refactorización completa). 7/

Para entender por qué el código es una carga, tienes que entender la diferencia entre "escribir código" y "ingeniería de software". "Escribir código" es un pasatiempo increíblemente útil, divertido y absorbente. 8/

Consiste en descomponer tareas complejas en pasos discretos, tan precisamente descritos que un ordenador puede realizarlos de forma fiable, optimizando el rendimiento al encontrar formas ingeniosas de minimizar las demandas que el código impone a los recursos del ordenador, como la RAM y los ciclos del procesador. 9/

Por otro lado, la "ingeniería de software" es una disciplina que engloba "escribir código", pero con un enfoque en las operaciones a largo plazo del *sistema* del que forma parte el código. 10/

La ingeniería de software se ocupa de los procesos ascendentes que generan los datos que recibe el sistema. Se ocupa de los procesos posteriores a los que el sistema emite información procesada. 11/

Se ocupa de los sistemas adyacentes que reciben datos de los mismos procesos aguas arriba y/o emiten datos a los mismos procesos aguas abajo a los que el sistema emite. 12/

"Escribir código" consiste en hacer código que *funcione bien*. "Ingeniería de software" consiste en crear código que *falle bien*. Se trata de crear código legible, cuyas funciones puedan ser entendidas por terceros a quienes se les pueda pedir mantenerlo. 13/

A esos terceros se les podría pedir que adapten los procesos aguas abajo, aguas arriba o adyacentes al sistema para evitar que el sistema se rompa. 14/

Esa es la cuestión: cualquier código no trivial tiene que interactuar con el mundo exterior, y el mundo exterior no es estático, es *dinámico*. El mundo exterior desmonta las suposiciones hechas por los autores de software *todo el tiempo* y cada vez que lo hace, el software necesita ser arreglado. 16/

¿Recuerdas el Y2K? Fue un día en que el código perfectamente funcional, ejecutándose en hardware perfectamente funcional, dejaba de funcionar, no porque el código cambiara, sino porque *el tiempo avanzaba*. 17/

Estamos a 12 años del problema de Y2038, cuando las versiones de Unix de 32 bits dejarán de funcionar, porque ellas también se habrán quedado sin segundos computables. 18/

La existencia de "el mundo" es un factor ineludible que desgasta el software y requiere su reconstrucción, a menudo a un coste enorme. Cuanto más tiempo esté en funcionamiento, más probable es que se encuentre con "el mundo". 20/

Toma el código que usan los dispositivos para informar sobre su ubicación física. Originalmente, esto se usaba para cosas como la facturación: determinar qué red de operador o proveedor estabas usando y si estabas en roaming. 21/

Luego, nuestros dispositivos móviles usaron este código para ayudar a determinar tu ubicación y así darte indicaciones paso a paso en las aplicaciones de navegación. Luego, este código se reutilizó de nuevo para ayudarnos a encontrar nuestros dispositivos perdidos. 22/

Esto se convirtió en una forma de localizar dispositivos *robados*, un caso de uso que difiere drásticamente de encontrar dispositivos perdidos. Al localizar un dispositivo perdido, no tienes que lidiar con la posibilidad de que un actor malicioso haya desactivado la función de "encontrar mi dispositivo perdido". 23/

Estos casos de uso adicionales —aguas arriba, aguas abajo y adyacentes— expusieron errores en el código original que nunca aparecieron en las aplicaciones anteriores. 24/

Por ejemplo, todos los servicios de localización deben tener algún tipo de comportamiento predeterminado en el (muy común) caso de que no estén realmente seguros de dónde están. 25/

Quizá tengan una solución general —por ejemplo, saben a qué antena móvil están conectados, o saben dónde estaban la *última* vez que obtuvieron una localización precisa— o quizá están totalmente perdidos. 26/

Resulta que en muchos casos, las aplicaciones de localización dibujaban un círculo alrededor de todos los lugares donde *podrían* estar y luego colocaban su ubicación en el centro de ese círculo. 27/

Eso está bien si el círculo tiene solo unos pocos pies de diámetro, o si la aplicación sustituye rápidamente esta aproximación por una ubicación más precisa. Pero, ¿y si la ubicación tiene millas y millas de ancho y la corrección de ubicación *nunca* mejora? 28/

¿Y si la ubicación de cualquier dirección IP sin una ubicación definida se indica como *el centro de Estados Unidos continental* y cualquier app que no sepa dónde está indica que está en una casa en Kansas? 29/

Y en mi pueblo de Burbank, donde el servicio de intercambio de ubicación de Google nos dijo una vez que nuestra hija de entonces 11 años (cuyo teléfono no podíamos localizar) estaba a 12 millas, en una rampa de autopista en una zona no incorporada del condado de Los Ángeles. 32/

(Estaba en un parque cercano, pero fuera de alcance, y la app estimó su ubicación como el centro de la región en la que la había fijado por última vez.) (Fueron un par de horas duras.) 33/

El código subyacente —el que usa algún predeterminado antes inofensivo para manipular ubicaciones desconocidas— necesita actualizarse *constantemente*, porque los procesos aguas arriba, aguas abajo y adyacentes conectados a él cambian *constantemente*. 34/

Cuanto más tiempo permanece ese código, más superado se vuelve su comportamiento original, y más barrocos, desagradables y oscuros se vuelven los parches que se le superponen. 35/

El código no es un activo, es una carga. Cuanto más tiempo lleva funcionando un sistema informático, más deuda tecnológica representa. Cuanto más importante es el sistema, más difícil es derribarlo y rehacerlo por completo. 36/

En cambio, se le encierran nuevas capas de código, y dondequiera que se encuentren las capas de código, hay fisuras en las que estos sistemas se comportan de formas que no coinciden exactamente. 37/

Peor aún: cuando dos empresas se fusionan, sus sistemas informáticos cosidos y fissionados se chocan juntos, de modo que ahora hay fuentes *adyacentes* de deuda tecnológica, así como grietas aguas arriba y descendente: 38/

Por eso las grandes empresas son tan susceptibles a ataques de ransomware: están llenas de sistemas incompatibles que han sido inducidos a una copia de compatibilidad con diversas formas de masilla digital de hilo, cuerdas y alambre de empacado. 39/

No son estancas y no pueden hacerse estancas. Aunque no los derriben los hackers, a veces simplemente se caen y no se pueden volver a poner en pie. 40/

¿Recuerdas cuando los ordenadores de Southwest Airlines se estrellaron durante toda la semana de Navidad de 2022, dejando a millones de viajeros varados? 41/

Las aerolíneas son especialmente malas, porque se informatizaron pronto y nunca pueden apagar los ordenadores antiguos para reemplazarlos por nuevos. Por eso sus apps son tan malas. 42/

Por eso es tan terrible que las aerolíneas hayan despedido a su personal de atención al cliente y exijan a los viajeros usar las apps para *todo*, aunque las apps no. funcionan. Estas apps nunca funcionan. 43/

La razón por la que la app de British Airways muestra "Ha ocurrido un error desconocido" entre el 40 y el 80% de las veces no es (solo) que despidieron a todo su personal de TI y externalizaron a licitadores más bajos en el extranjero. 44/

Es eso, claro, pero también que los primeros ordenadores de BA funcionaban con válvulas electromecánicas, y todo desde entonces tiene que ser compatible hacia atrás con un sistema que uno de los protegidos de Alan Turing royó un tronco entero con sus propios dientes frontales. 45/

El código es una carga, no un activo (la nueva app de BA lleva años de retraso). El código es una carga. Los servidores de los terminales Bloomberg que convirtieron a Michael Bloomberg en un multimillonario que funcionaba con chips RISC. 46/

Esto significa que está atada a usar un número cada vez menor de proveedores especializados de hardware y centros de datos, pagar a programadores especializados y construir cadenas de código frágiles para conectar estos sistemas RISC con sus equivalentes menos exóticos en el mundo. El código no es un activo. 47/

La IA puede escribir código, pero la IA no puede hacer ingeniería de software. La ingeniería de software consiste en pensar a través del *contexto*: ¿qué vendrá antes de este sistema? ¿Qué vendrá después? ¿Qué se situará junto a ella? ¿Cómo cambiará el mundo? 48/

La ingeniería de software requiere una "ventana de contexto" muy amplia, algo que la IA no tiene, ni puede tener. La ventana de contexto de la IA es estrecha y superficial. Los aumentos lineales en la ventana de contexto de la IA requieren expansiones *geométricas* en las demandas computacionales: 49/

Escribir código que funciona, sin considerar cómo va a fallar, es una receta para la catástrofe. Es una forma de crear deuda tecnológica a gran escala. Es empujar amianto hacia los muros de nuestra sociedad tecnológica. 50/

Los jefes *no saben* que el código es una carga, no un activo. Por eso no paran de hablar de los chatbots que generan 10.000 veces más código que cualquier programador humano. 51/

Creen que han encontrado una máquina que produce *activos* a una velocidad 10.000 veces superior a la de un programador humano. No lo han hecho. Han encontrado una máquina que produce *responsabilidad* a 10.000 veces la velocidad de cualquier programador humano. 52/

La mantenibilidad no es solo cuestión de experiencia ganada a pulso que te enseñe dónde están los escollos. 53/

También requiere cultivar el "Fingerspitzengefühl" —la "sensación de la punta del dedo" que te permite hacer conjeturas razonables sobre dónde podrían surgir trampas nunca antes vistas. 54/

Es una forma de conocimiento de proceso. Es ineludible. No está latente ni siquiera en el mayor corpus de código que podrías usar como datos de entrenamiento: *Vaya* los jefes tecnológicos no entienden esto. 55/

Tomemos Microsoft. Su gran apuesta ahora mismo es la "IA agente". Quieren instalar un spyware en tu ordenador que capture cada pulsación de tecla, cada comunicación, cada pantalla que ves y lo envíe a la nube de Microsoft y dé acceso a una multitud de chatbots. 56/

Dicen que podrás decirle a tu ordenador: "Resérvame un tren a Cardiff y encuentra ese hotel que mencionó Cory el año pasado y resérvame una habitación allí" y lo hará. Esta es una idea increíblemente inviable. 57/

Ningún chatbot es remotamente capaz de hacer todas estas cosas, algo que Microsoft estipula libremente. En lugar de hacerlo con un solo chatbot, Microsoft propone desglosarlo entre decenas de chatbots, cada uno de los cuales espera que Microsoft aporte hasta un 95% de fiabilidad. 58/

Eso es un estándar de chatbot totalmente inverosímil en sí mismo, pero considera esto: las probabilidades son *multiplicativas*. Un sistema que contiene dos procesos que operan con un 95% de fiabilidad tiene una fiabilidad neta del 90,25% (0,95 * 0,95). 59/

Divide una tarea entre un par de docenas de bots con un 95% de precisión y la probabilidad de que se complete correctamente se redondea a *cero*. 60/

Mientras tanto, un ejecutivo de Microsoft tuvo problemas el pasado diciembre cuando publicó en Linkedin anunciando su intención de que la IA reescribiera *todo* el código de Microsoft. 63/

Refactorizar la base de código de Microsoft tiene mucho sentido. Microsoft —al igual que British Airways y otras empresas heredadas— tiene mucho código muy antiguo que representa una deuda tecnológica insostenible. 64/

Algunos de vosotros *sois* ingenieros de software que habéis encontrado a los chatbots increíblemente útiles para escribir código para vosotros. Esta es una paradoja común de la IA: ¿por qué algunas personas que usan IA la encuentran realmente útil y otras la detestan? 66/

¿Es que la gente a la que no le gusta la IA es "mala en IA"? ¿Es que los fans de la IA son perezosos y no les importa la calidad de su trabajo? 67/

Sin duda hay algo de ambas cosas en juego, pero incluso si enseñas a todos a ser expertos en IA y eliminas a todos los que no se sienten orgullosos de su trabajo de la muestra, la paradoja seguirá existiendo. 68/

La verdadera solución a la paradoja de la IA reside en la teoría de la automatización y en el concepto de "centauros" y "centauros inversos": 69/

En la teoría de la automatización, un "centauro" es una persona asistida por una máquina. Un "centauro inverso" es alguien que ha sido reclutado para *ayudar a una máquina*. 70/

Imagina que eres un ingeniero de software que usa IA para escribir código rutinario que tienes tiempo y experiencia para validar, desplegando tu conocimiento de Fingerspitzengefühl y procesos para asegurarte de que cumple con su propósito. 71/

Es fácil entender por qué puede ser útil usar IA (cuando decides, de la manera que elijas, al ritmo que prefieras). Pero imagina que eres un ingeniero de software al que le han ordenado producir código a 10 veces, 100 o 10.000 veces tu tasa anterior. 72/

Imagina que la única forma de hacerlo es mediante IA, y no hay ninguna forma humana de revisar ese código y asegurarte de que no se rompa al primer contacto con el mundo, lo odiarás: 73/

(Odiarás aún más si te han convertido en el sumidero de responsabilidad de la IA, personalmente responsable de los errores de la IA.) Hay otra forma en la que los ingenieros de software encuentran el código generado por IA increíblemente útil: cuando ese código está *aislado*. 74/

Si haces un solo proyecto —por ejemplo, convertir un lote de archivos a otro formato, solo una vez— no tienes que preocuparte por procesos posteriores, ascendentes o adyacentes. No hay ninguna. 75/

Estás escribiendo código para hacer algo una vez, sin interactuar con ningún otro sistema. Un *montón* de programación es este tipo de proyecto de utilidad. Es tedioso, ingrato y perfecto para la automatización. 76/

Muchos proyectos personales entran en este grupo y, por supuesto, por definición, un proyecto personal es un proyecto de centauros. Nadie te obliga a usar IA en un proyecto personal: siempre es tu decisión cómo y cuándo haces uso personal de cualquier herramienta. 77/

Pero el hecho de que los ingenieros de software a veces puedan mejorar su trabajo con IA no invalida que el código sea una carga, no un activo, y que el código de IA representa una producción de pasivos a gran escala. 78/

En la historia del desempleo tecnológico, está la idea de que la nueva tecnología crea nuevos empleos aunque hace obsoletos los antiguos: por cada herrero que queda sin trabajo por el automóvil, hay un trabajo esperando como mecánico. 79/

En los años desde que la burbuja de la IA empezó a inflarse, hemos escuchado muchas versiones de esto: la IA crearía empleos para "ingenieros de prompt" —o incluso crearía empleos que no podemos imaginar, porque no existirán hasta que la IA haya cambiado el mundo hasta irreconocerlo. 80/

No apostaría por conseguir trabajo en un oficio fantasioso que literalmente no puede imaginarse porque nuestras conciencias no han sido tan alteradas por la IA que hayan adquirido la capacidad de conceptualizar estos nuevos modos de trabajo. 81/

Pero si *estás* buscando un trabajo que la IA creará por millones, tengo una sugerencia: la eliminación digital de amianto. 82/

El código de IA —escrito a 10.000 veces la velocidad de cualquier programador humano, diseñado para funcionar bien, pero sin fallar con gracia— es el amianto digital con el que estamos llenando nuestras paredes. Nuestros descendientes pasarán generaciones excavando ese amianto de las paredes. 83/

Habrá mucho trabajo para arreglar las cosas que rompimos gracias a la psicosis de IA más peligrosa de todas: la creencia alucinatoria de que "escribir código" es lo mismo que "ingeniería de software". 84/

Al ritmo que vamos, tendremos pleno empleo para generaciones de removedores de amianto. 85/