El código es un pasivo (no un activo). Los jefes de tecnología 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 está produciendo 10,000 veces más pasivos. 1/

Si deseas una versión en formato de ensayo de este hilo para leer o compartir, aquí tienes un enlace a mi blog, libre de vigilancia, sin anuncios y sin rastreadores: 2/

La IA es el asbesto que estamos metiendo en las paredes de nuestra sociedad de alta tecnología: El código es un pasivo. Las *capacidades* del código son activos. 3/

El objetivo de una tienda de tecnología es tener un código cuyas capacidades generen más ingresos que los costos asociados con mantener ese código en funcionamiento. 4/

Durante mucho tiempo, las empresas han alimentado una falsa creencia de que el código cuesta menos de ejecutar con el tiempo: después de un período inicial de ajuste en el que se encuentran y abordan los errores en el código, este deja de necesitar un mantenimiento significativo. 5/

Después de todo, 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 *Postcapitalismo*, un libro que ha envejecido notablemente mal (aunque no, quizás, tan mal como la propia credibilidad política de Mason). 6/

El código no es una máquina reproducible infinitamente que no requiere 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 reestructuración completa). 7/

Para entender por qué el código es un pasivo, 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/

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

Mientras tanto, "la ingeniería de software" es una disciplina que abarca "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 de upstream que generan los datos que el sistema recibe. Se ocupa de los procesos de downstream a los que el sistema emite información procesada. 11/

Se ocupa de los sistemas adyacentes que están recibiendo datos de los mismos procesos de upstream y/o emitiendo datos a los mismos procesos de downstream a los que el sistema está emitiendo. 12/

"Escribir código" se trata de hacer código que *funcione bien*. "Ingeniería de software" se trata de hacer código que *falle bien*. Se trata de hacer código que sea legible, cuyas funciones puedan ser entendidas por terceros que podrían ser solicitados para mantenerlo. 13/

Es posible que se les pida a esos terceros 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 rompe las suposiciones hechas por los autores de software *todo el tiempo* y cada vez que lo hace, el software necesita ser corregido. 16/

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

Estamos a 12 años del problema Y2038, cuando todos los sabores de Unix de 32 bits dejarán de funcionar, porque también habrán agotado los segundos computables. 18/

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

Toma el código que los dispositivos utilizan 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 utilizando y si estabas en itinerancia. 21/

Luego, nuestros dispositivos móviles usaron este código para ayudar a determinar tu ubicación con el fin de darte direcciones paso a paso en las aplicaciones de navegación. Luego, este código se reutilizó nuevamente para ayudarnos a encontrar nuestros dispositivos perdidos. 22/

Esto se convirtió en una forma de localizar dispositivos *robados*, un caso de uso que diverge 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 se encuentran. 25/

Quizás tengan una solución general, por ejemplo, saben a qué antena celular están conectados, o saben dónde estaban la *última* vez que obtuvieron una ubicación precisa, o tal vez están completamente perdidos. 26/

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

Está bien si el círculo tiene solo unos pocos pies de diámetro, o si la aplicación reemplaza rápidamente esta aproximación con una ubicación más precisa. Pero, ¿qué pasa si la ubicación abarca millas y millas, y la fijación de la ubicación *nunca* mejora? 28/

¿Qué pasaría si la ubicación de cualquier dirección IP sin una ubicación definida se da como *el centro de los EE. UU. continentales* y cualquier aplicación que no sepa dónde está informa que está en una casa en Kansas? 29/

Y en mi ciudad de Burbank, donde el servicio de compartición de ubicación de Google nos dijo una vez que nuestra hija de 11 años (cuyo teléfono no podíamos alcanzar) estaba a 12 millas de distancia, en una rampa de la autopista en un área no incorporada del condado de Los Ángeles. 32/

(Ella estaba en un parque cercano, pero fuera de alcance, y la aplicación 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 difíciles.) 33/

El código subyacente - el código que utiliza algún valor predeterminado que antes era inofensivo para manipular ubicaciones desconocidas - necesita ser actualizado *constantemente*, porque los procesos ascendentes, descendentes y adyacentes conectados a él están cambiando *constantemente*. 34/

Cuanto más tiempo permanezca ese código ahí, más anticuados se vuelven sus comportamientos originales, y más barrocos, desordenados y oscurecidos se vuelven los parches que se superponen a él. 35/

El código no es un activo, es un pasivo. Cuanto más tiempo ha estado funcionando un sistema informático, más deuda técnica representa. Cuanto más importante es el sistema, más difícil es derribarlo y rehacerlo por completo. 36/

En cambio, se añaden nuevas capas de código sobre él, y donde las capas de código se encuentran, hay fisuras en las que estos sistemas se comportan de maneras que no coinciden exactamente. 37/

Peor aún: cuando dos empresas se fusionan, sus sistemas de TI agrietados y desgastados se juntan, de modo que ahora hay fuentes *adyacentes* de deuda técnica, así como grietas aguas arriba y aguas abajo: 38/

Por eso las grandes empresas son tan susceptibles a los ataques de ransomware: están llenas de sistemas incompatibles que han sido persuadidos para formar un facsímil de compatibilidad con varias formas de plastilina digital, cuerda y alambre de paca. 39/

No son a prueba de agua y no se pueden hacer a prueba de agua. Incluso si no son derribados por hackers, a veces simplemente se caen y no se pueden volver a levantar. 40/

¿Recuerdas cuando las computadoras de Southwest Airlines se colapsaron durante toda la semana de Navidad de 2022, dejando varados a millones de viajeros? 41/

Las aerolíneas son especialmente malas, porque se computerizaron temprano y nunca pueden apagar las viejas computadoras para reemplazarlas por nuevas. Por eso sus aplicaciones son tan malas. 42/

Por eso es tan horrible que las aerolíneas despidieran a su personal de atención al cliente y requieran que los pasajeros usen las aplicaciones para *todo*, aunque las aplicaciones no. funcionan. Estas aplicaciones nunca funcionarán. 43/

La razón por la que la aplicación de British Airways muestra "Ha ocurrido un error desconocido" el 40-80% del tiempo no es (solo) porque despidieron a todo su personal de TI y subcontrataron a los que ofrecían precios más bajos en el extranjero. 44/

Es eso, seguro, pero también que las primeras computadoras 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 mordisqueó de un tronco entero con sus propios dientes delanteros. 45/

El código es un pasivo, no un activo (la nueva aplicación de BA está años retrasada). El código es un pasivo. Los servidores de los terminales de Bloomberg que convirtieron a Michael Bloomberg en un multimillonario funcionan con chips RISC. 46/

Esto significa que está bloqueado en el uso de un número decreciente de proveedores de hardware y centros de datos especializados, pagando a programadores especializados y construyendo 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 se trata de pensar en *el contexto* - ¿qué vendrá antes de este sistema? ¿Qué vendrá después? ¿Qué estará al lado de él? ¿Cómo cambiará el mundo? 48/

La ingeniería de software requiere una "ventana de contexto" muy amplia, cosa que la IA no tiene, y no 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 funcione, sin considerar cómo fallará, es una receta para el desastre. Es una forma de crear deuda técnica a gran escala. Es como meter amianto en las paredes de nuestra sociedad tecnológica. 50/

Los jefes *no saben* que el código es un pasivo, no un activo. Por eso no dejan 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 10,000 veces la tasa de un programador humano. No es así. Han encontrado una máquina que produce *pasivos* a 10,000 veces la tasa de cualquier programador humano. 52/

La mantenibilidad no es solo una cuestión de experiencia adquirida que te enseña dónde están las trampas. 53/

También requiere el cultivo de "Fingerspitzengefühl" - el "sentimiento en la yema de los dedos" que te permite hacer conjeturas razonables sobre dónde podrían surgir trampas nunca antes vistas. 54/

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

Toma Microsoft. Su gran apuesta en este momento es por la "IA agentiva." Quieren instalar spyware en tu computadora que capture cada pulsación de tecla, cada comunicación, cada pantalla que ves y lo envíe a la nube de Microsoft, dando acceso a una variedad de chatbots.

Aseguran que podrás decirle a tu computadora: "Reserva un tren a Cardiff y encuentra ese hotel que Cory mencionó el año pasado y reserva 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 hacer esto con un solo chatbot, Microsoft propone desglosarlo entre docenas de chatbots, cada uno de los cuales Microsoft espera llevar hasta un 95% de fiabilidad. 58/

Eso es un estándar de chatbot completamente implausible por 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/

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

Mientras tanto, un ejecutivo de Microsoft tuvo problemas el diciembre pasado cuando publicó en Linkedin anunciando su intención de hacer 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 tradicionales - tiene mucho código muy antiguo que representa una deuda técnica insostenible. 64/

Algunos de ustedes *son* ingenieros de software que han encontrado que los chatbots son increíblemente útiles para escribir código por ustedes. Este es un paradoja común de la IA: ¿por qué algunas personas que usan IA la encuentran realmente útil, mientras que otras la odian? 66/

¿Es que las personas que no les gusta la IA son "malas en IA"? ¿Es que los aficionados a la IA son perezosos y no se preocupan por la calidad de su trabajo? 67/

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

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

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

Digamos que eres un ingeniero de software que utiliza AI para escribir código rutinario que tienes el tiempo y la experiencia para validar, desplegando tu Fingerspitzengefühl y conocimiento del proceso para asegurarte de que es adecuado para su propósito. 71/

Es fácil ver por qué podrías encontrar útil usar AI (cuando elijas hacerlo, de las maneras que elijas, al ritmo que decidas llevar). Pero digamos que eres un ingeniero de software al que le han ordenado producir código a 10x, o 100x, o 10,000x de tu tasa anterior. 72/

Di que la única forma de hacerlo es a través de AI, y que no hay forma humana de que puedas revisar ese código y asegurarte de que no se romperá en el primer contacto con el mundo, lo odiarás: 73/

(Lo odiarás aún más si te has 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 que el código generado por IA es increíblemente útil: cuando ese código está *aislado*. 74/

Si estás realizando un solo proyecto - digamos, convertir un lote de archivos a otro formato, solo una vez - no tienes que preocuparte por los procesos posteriores, anteriores o adyacentes. No hay ninguno. 75/

Estás escribiendo código para hacer algo una vez, sin interactuar con ningún otro sistema. Una *gran* parte de la programación es este tipo de proyecto utilitario. Es tedioso, ingrato y propenso a la automatización. 76/

Muchos proyectos personales caen en esta categoría, y por supuesto, por definición, un proyecto personal es un proyecto centauro. Nadie te obliga a usar AI en un proyecto personal: siempre es tu elección cómo y cuándo haces uso personal de cualquier herramienta. 77/

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

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

En los años desde que comenzó a inflarse la burbuja de la IA, hemos escuchado muchas versiones de esto: la IA crearía empleos para "ingenieros de prompts" - o incluso crearía empleos que no podemos imaginar, porque no existirán hasta que la IA haya cambiado el mundo más allá del reconocimiento. 80/

No contaría con conseguir trabajo en un oficio fantasioso que literalmente no se puede imaginar porque nuestras conciencias no han cambiado tanto 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 definitivamente creará, por millones, tengo una sugerencia: eliminación digital de asbesto. 82/

El código de IA - escrito a 10,000 veces la velocidad de cualquier programador humano, diseñado para funcionar bien, pero no para fallar de manera elegante - es el asbesto digital con el que estamos llenando nuestras paredes. Nuestros descendientes pasarán generaciones sacando ese asbesto de las paredes. 83/

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

A este ritmo, tendremos pleno empleo para generaciones de retiradores de asbesto. 85/