O código é um passivo (não um ativo). Os chefes de tecnologia não entendem isso. Eles acham que IA é ótima porque produz 10.000 vezes mais código que um programador, mas isso só significa que está gerando 10.000 vezes mais responsabilidades. 1/

Se você quiser uma versão em formato de ensaio deste tópico para ler ou compartilhar, aqui está um link para ele em , meu blog sem vigilância, sem anúncios e sem rastreadores: 2/

A IA é o amianto que estamos empurrando para dentro das paredes da nossa sociedade de alta tecnologia: Código é um risco. As *capacidades* do código são ativos. 3/

O objetivo de uma empresa de tecnologia é ter um código cujas capacidades gerem mais receita do que os custos associados a manter esse código funcionando. 4/

Por muito tempo, as empresas alimentaram a falsa crença de que o código custa menos para ser executado ao longo do tempo: após um período inicial de ajuste em que os bugs do código são encontrados e corrigidos, o código deixa de precisar de manutenção significativa. 5/

Afinal, código é uma máquina sem partes móveis – ela não se desgasta; Nem se desgasta. Esta é a tese do livro de Paul Mason, *Postcapitalism*, de 2015, que envelheceu notavelmente mal (embora, talvez, não tão mal quanto a própria credibilidade política de Mason). 6/

O código não é uma máquina infinitamente reproduzível que não exige trabalho. Na verdade, é uma máquina frágil que exige medidas cada vez mais heroicas para mantê-la em bom estado de funcionamento, e que eventualmente "se desgasta" (no sentido de precisar de uma refatoração completa). 7/

Para entender por que o código é um problema, você precisa entender a diferença entre "escrever código" e "engenharia de software". "Escrever código" é um passatempo incrivelmente útil, divertido e envolvente. 8/

Envolve dividir tarefas complexas em etapas discretas, tão precisamente descritas que um computador pode executá-las de forma confiável, otimizando o desempenho ao encontrar maneiras inteligentes de minimizar as demandas que o código impõe aos recursos do computador, como RAM e ciclos do processador. 9/

Enquanto isso, "engenharia de software" é uma disciplina que engloba "escrever código", mas com foco nas operações de longo prazo do *sistema* do qual o código faz parte. 10/

Engenharia de software preocupa-se com os processos a montante que geram os dados recebidos pelo sistema. Ela se preocupa com os processos posteriores para os quais o sistema emite informações processadas. 11/

Ela se preocupa com os sistemas adjacentes que recebem dados dos mesmos processos a montante e/ou emitem dados para os mesmos processos a jusante para os quais o sistema está emitindo. 12/

"Escrever código" é sobre criar um código que *roda bem*. "Engenharia de software" é sobre criar código que *falha bem*. Trata-se de criar código legível – cujas funções possam ser compreendidas por terceiros que possam ser solicitados a mantê-lo. 13/

Essas terceirizadas podem ser solicitadas a adaptar os processos a jusante, a montante ou adjacentes ao sistema para evitar que o sistema quebre. 14/

Essa é a questão: qualquer código não trivial precisa interagir com o mundo exterior, e o mundo exterior não é estático, é *dinâmico*. O mundo exterior destrói as suposições feitas pelos autores de software *o tempo todo* e toda vez que isso acontece, o software precisa ser corrigido. 16/

Lembra do Y2K? Aquela era uma época em que código perfeitamente funcional, rodando em hardware perfeitamente funcional, parava de funcionar – não porque o código mudava, mas porque *o tempo avançava*. 17/

Estamos a 12 anos do problema do Y2038, quando as versões de Unix de 32 bits deixarão de funcionar, porque também terão ficado sem segundos computáveis. 18/

A existência do "mundo" é um fator inescapável que desgasta o software e exige sua reconstrução, muitas vezes a um custo enorme. Quanto mais tempo o código estiver em operação, maior a chance de ele encontrar "o mundo". 20/

Pegue o código que os dispositivos usam para informar sua localização física. Originalmente, isso era usado para coisas como faturamento – determinar qual operadora ou rede de provedor você estava usando e se estava em roaming. 21/

Depois, nossos dispositivos móveis usavam esse código para ajudar a determinar sua localização e fornecer direções passo a passo em aplicativos de navegação. Depois, esse código foi reaproveitado novamente para nos ajudar a encontrar nossos dispositivos perdidos. 22/

Isso se tornou uma forma de localizar dispositivos *roubados*, um caso de uso que diverge drasticamente de encontrar dispositivos perdidos. Ao localizar um dispositivo perdido, você não precisa lidar com a possibilidade de um agente malicioso ter desativado a função "encontrar meu dispositivo perdido". 23/

Esses casos de uso adicionais – upstream, downstream e adjacentes – expuseram bugs no código original que nunca surgiram nas aplicações anteriores. 24/

Por exemplo, todos os serviços de localização devem ter algum tipo de comportamento padrão no (muito comum) caso de que eles não tenham certeza de onde estão. 25/

Talvez eles tenham uma solução geral – por exemplo, sabem a qual antena celular estão conectados, ou sabem onde estavam na *última* vez que conseguiram uma localização precisa – ou talvez estejam totalmente perdidos. 26/

Acontece que, em muitos casos, os aplicativos de localização desenhavam um círculo ao redor de todos os lugares onde *poderiam* estar e depois definiam a localização no meio desse círculo. 27/

Isso é aceitável se o círculo tiver apenas alguns pés de diâmetro, ou se o aplicativo rapidamente substituir essa aproximação por uma localização mais precisa. Mas e se a localização tiver quilômetros e quilômetros de largura, e a correção de localização *nunca* melhorar? 28/

E se a localização de qualquer endereço IP sem uma localização definida for dada como *o centro dos EUA continentais* e qualquer aplicativo que não saiba onde ele está informar que está em uma casa no Kansas? 29/

E na minha cidade de Burbank, onde o serviço de compartilhamento de localização do Google uma vez nos contou que nossa filha, então de 11 anos (cujo telefone não conseguíamos alcançar), estava a 12 milhas de distância, em uma rampa de rodovia em uma área não incorporada do condado de Los Angeles. 32/

(Ela estava em um parque próximo, mas fora do alcance, e o app estimou sua localização como o centro da região onde a fixou pela última vez.) (Foram algumas horas difíceis.) 33/

O código subjacente – o código que usa algum padrão antes inofensivo para manipular locais desconhecidos – precisa ser atualizado *constantemente*, porque os processos a montante, a jusante e adjacentes conectados a ele estão mudando *constantemente*. 34/

Quanto mais tempo esse código fica ali, mais superaposentados seus comportamentos originais se tornam, e mais barrocos, grosseiros e obscuros se tornam os patches sobrepostos a ele. 35/

Código não é um ativo – é um passivo. Quanto mais tempo um sistema de computador está funcionando, mais dívida tecnológica ele representa. Quanto mais importante for o sistema, mais difícil é derrubá-lo e refazê-lo completamente. 36/

Em vez disso, novas camadas de código são sobrepostas a ele, e onde quer que as camadas de código se encontrem, há fissuras em que esses sistemas se comportam de maneiras que não correspondem exatamente. 37/

Pior ainda: quando duas empresas são fundidas, seus sistemas de TI fissurados e costurados são esmagados juntos, de modo que agora existem fontes *adjacentes* de dívida tecnológica, assim como fissuras a montante e a jusante: 38/

É por isso que grandes empresas são tão suscetíveis a ataques de ransomware – elas estão cheias de sistemas incompatíveis que foram coaxados para uma cópia de compatibilidade com várias formas de massa digital de massa, fios e arame de fardo. 39/

Eles não são estanques e não podem ser feitos à prova d'água. Mesmo que não sejam derrubados por hackers, às vezes simplesmente caem e não podem ser levantados novamente. 40/

Lembra quando os computadores da Southwest Airlines travaram durante toda a semana de Natal de 2022, deixando milhões de viajantes presos? 41/

As companhias aéreas são especialmente ruins, porque informatizaram cedo e nunca conseguem desligar os computadores antigos para substituí-los por novos. É por isso que os apps deles são tão ruins. 42/

É por isso que é tão ruim que as companhias aéreas tenham demitido o pessoal de atendimento ao cliente e exigido que os passageiros usem os aplicativos para *tudo*, mesmo que os aplicativos não funcionem. Esses aplicativos nunca vão funcionar. 43/

A razão pela qual o aplicativo da British Airways exibe "Um erro desconhecido ocorreu" 40-80% das vezes não é (apenas) que eles demitiram toda a equipe de TI e terceirizaram para licitantes mais baixos no exterior. 44/

É isso, claro – mas também porque os primeiros computadores da BA rodavam com válvulas eletromecânicas, e tudo desde então precisa ser compatível com um sistema que um dos protegidos de Alan Turing roeu um tronco inteiro com seus próprios dentes da frente. 45/

O código é um passivo, não um ativo (o novo app da BA está anos atrasado). Código é um risco. Os servidores dos terminais Bloomberg que transformaram Michael Bloomberg em um bilionário que funcionava com chips RISC. 46/

Isso significa que ela está presa a usar um número cada vez menor de fornecedores especializados de hardware e data centers, pagar programadores especializados e construir cadeias de código frágeis para conectar esses sistemas RISC aos seus equivalentes menos exóticos no mundo. Código não é um ativo. 47/

A IA pode escrever código, mas a IA não pode fazer engenharia de software. Engenharia de software é toda sobre pensar através do *contexto* – o que virá antes desse sistema? O que virá depois? O que vai acompanhar isso? Como o mundo vai mudar? 48/

Engenharia de software exige uma "janela de contexto" muito ampla, algo que a IA não tem, e não pode ter. A janela de contexto da IA é estreita e rasa. Aumentos lineares na janela de contexto da IA requerem expansões *geométricas* nas demandas computacionais: 49/

Escrever código que funciona, sem considerar como vai falhar, é receita para a catástrofe. É uma forma de criar dívida tecnológica em larga escala. É empurrar amianto para dentro das paredes da nossa sociedade tecnológica. 50/

Os chefes *não sabem* que o código é um problema, não um ativo. É por isso que eles não param de falar dos chatbots que produzem 10.000 vezes mais código do que qualquer programador humano. 51/

Eles acham que encontraram uma máquina que produz *ativos* a uma taxa 10.000 vezes maior que um programador humano. Eles não fizeram. Eles encontraram uma máquina que produz *responsabilidades* a uma taxa 10.000 vezes maior que qualquer programador humano. 52/

A manutenção não é apenas uma questão de experiência conquistada com esforço ensinando onde estão as armadilhas. 53/

Também exige o cultivo do "Fingerspitzengefühl" – a "sensação na ponta dos dedos" que permite fazer palpites razoáveis sobre onde armadilhas nunca antes vistas podem surgir. 54/

É uma forma de conhecimento de processo. É inevitável. Ele não está latente nem mesmo no maior corpus de código que você poderia usar como dados de treinamento: *Nossa* como chefes de tecnologia não entendem isso. 55/

Veja a Microsoft. A grande aposta deles agora é na "IA agente". Eles querem instalar um spyware no seu computador que capture cada teclado, cada comunicação, cada tela que você vê e envie para a nuvem da Microsoft e dê acesso a uma variedade de chatbots. 56/

Eles dizem que você pode dizer ao seu computador: "Reserve um trem para Cardiff e encontre aquele hotel que o Cory mencionou no ano passado e reserve um quarto lá" e que ele vai fazer isso. Essa é uma ideia incrivelmente inviável. 57/

Nenhum chatbot é remotamente capaz de fazer todas essas coisas, algo que a Microsoft estipula livremente. Em vez de fazer isso com um chatbot, a Microsoft propõe dividir isso em dezenas de chatbots, cada um dos quais a Microsoft espera trazer até 95% de confiabilidade. 58/

Esse é um padrão totalmente implausível para chatbots por si só, mas considere isto: as probabilidades são *multiplicativas*. Um sistema contendo dois processos que operam com 95% de confiabilidade tem uma confiabilidade líquida de 90,25% (0,95 * 0,95). 59/

Divida uma tarefa entre algumas dezenas de bots com 95% de precisão e a chance de que essa tarefa seja realizada corretamente reduz a *zero*. 60/

Enquanto isso, um executivo da Microsoft teve problemas em dezembro passado quando postou no Linkedin anunciando sua intenção de fazer a IA reescrever *todo* o código da Microsoft. 63/

Refatorar a base de código da Microsoft faz muito sentido. A Microsoft – assim como a British Airways e outras empresas tradicionais – tem muito código muito antigo que representa dívidas tecnológicas insustentáveis. 64/

Alguns de vocês *são* engenheiros de software que acharam chatbots incrivelmente úteis para escrever código para vocês. Esse é um paradoxo comum da IA: por que algumas pessoas que usam IA acham isso realmente útil, enquanto outras a detestam? 66/

Será que as pessoas que não gostam de IA são "ruins em IA"? Será que os fãs de IA são preguiçosos e não se importam com a qualidade do trabalho deles? 67/

Sem dúvida há um pouco de ambos acontecendo, mas mesmo que você ensine todos a serem especialistas em IA e elimine todos que não se orgulham do seu trabalho da amostra, o paradoxo ainda permanecerá. 68/

A verdadeira solução para o paradoxo da IA está na teoria da automação, e no conceito de "centauros" e "centauros reversos": 69/

Na teoria da automação, um "centauro" é uma pessoa assistida por uma máquina. Um "centauro reverso" é alguém que foi recrutado para *ajudar uma máquina*. 70/

Digamos que você seja um engenheiro de software que usa IA para escrever código rotineiro que você tem tempo e experiência para validar, implantando seu conhecimento do Fingerspitzengefühl e do processo para garantir que ele seja adequado ao propósito. 71/

É fácil entender por que você pode achar útil usar IA (quando você escolhe, do jeito que escolhe, no ritmo que prefere). Mas digamos que você seja um engenheiro de software que foi ordenado a produzir código a 10x, 100x ou 10.000 vezes a taxa anterior. 72/

Suponha que a única forma de fazer isso seja via IA, e não exista nenhuma maneira humana de você revisar esse código e garantir que ele não quebre no primeiro contato com o mundo, você vai odiar: 73/

(Você vai odiar ainda mais se for transformado no sumidouro de responsabilidade da IA, pessoalmente responsável pelos erros da IA.) Há outra forma pela qual engenheiros de software acham o código gerado por IA incrivelmente útil: quando esse código está *isolado*. 74/

Se você está fazendo um único projeto – por exemplo, converter um lote de arquivos para outro formato, só uma vez – não precisa se preocupar com processos a jusante, a montante ou adjacentes. Não existem. 75/

Você está escrevendo código para fazer algo uma vez, sem interagir com nenhum outro sistema. Muita programação é esse tipo de projeto utilitário. É tedioso, ingrato e pronto para automação. 76/

Muitos projetos pessoais se encaixam nesse grupo e, claro, por definição, um projeto pessoal é um projeto centauro. Ninguém obriga você a usar IA em um projeto pessoal – sempre é sua escolha como e quando você faz uso pessoal de qualquer ferramenta. 77/

Mas o fato de que engenheiros de software às vezes conseguem melhorar seu trabalho com IA não invalida o fato de que o código é um passivo, não um ativo, e que o código de IA representa a produção de responsabilidades em larga escala. 78/

Na história do desemprego tecnológico, há a ideia de que a nova tecnologia cria novos empregos mesmo tornando os antigos obsoletos: para cada ferreiro desempregado pelo automóvel, há um emprego esperando como mecânico. 79/

Nos anos desde que a bolha da IA começou a inflar, ouvimos muitas versões disso: a IA criaria empregos para "engenheiros de prompts" – ou até mesmo empregos que não conseguimos imaginar, porque eles não existirão até que a IA tenha mudado o mundo além do reconhecimento. 80/

Eu não apostaria em conseguir trabalho em um ofício fantasioso que literalmente não pode ser imaginado porque nossas consciências não foram tão alteradas pela IA a ponto de adquirirem a capacidade de conceituar esses novos modos de trabalho. 81/

Mas se você *está* procurando um emprego que a IA certamente vai criar, aos milhões, tenho uma sugestão: remoção digital de amianto. 82/

Código de IA – escrito a 10.000 vezes a velocidade de qualquer programador humano, projetado para funcionar bem, mas sem falhar com graça – é o amianto digital com que estamos enchendo nossas paredes. Nossos descendentes passarão gerações cavando esse amianto das paredes. 83/

Haverá muito trabalho para consertar as coisas que quebramos graças à psicose mais perigosa da IA de todas – a crença alucinatória de que "escrever código" é a mesma coisa que "engenharia de software". 84/

No ritmo que estamos indo, teremos emprego pleno para gerações de removedores de amianto. 85/