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

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

A IA é o amianto que estamos a enterrar nas paredes da nossa sociedade de alta tecnologia: O código é uma responsabilidade. As *capacidades* do código são ativos. 3/

O objetivo de uma loja de tecnologia é ter código cujas capacidades gerem mais receita do que os custos associados à manutenção desse código em funcionamento. 4/

Durante 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 erros no código são encontrados e corrigidos, o código deixa de precisar de manutenção significativa. 5/

Afinal, o código é uma máquina sem peças móveis - não se desgasta; não se desgasta nem um pouco. Esta é a tese do livro *Postcapitalismo* de Paul Mason, um livro 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 requer trabalho. Em vez disso, é uma máquina frágil que requer 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 é uma responsabilidade, 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 realizá-las de forma confiável, otimizando o desempenho ao encontrar maneiras inteligentes de minimizar as exigências que o código impõe aos recursos do computador, como RAM e ciclos de processador. 9/

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

A engenharia de software preocupa-se com os processos a montante que geram os dados que o sistema recebe. Preocupa-se com os processos a jusante que o sistema emite informações processadas. 11/

Diz respeito aos sistemas adjacentes que estão a receber dados dos mesmos processos a montante e/ou a emitir dados para os mesmos processos a jusante para os quais o sistema está a emitir. 12/

"Escrever código" é sobre fazer código que *funciona bem*. "Engenharia de software" é sobre fazer código que *falha bem*. É sobre fazer código que é legível - cujas funções podem ser compreendidas por terceiros que possam ser solicitados a mantê-lo. 13/

Esses terceiros podem ser solicitados a adaptar os processos a montante, a jusante ou adjacentes ao sistema para evitar que o sistema quebre. 14/

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

Lembram-se do Y2K? Foi um dia em que um código perfeitamente funcional, a correr em hardware perfeitamente funcional, deixaria de funcionar - não porque o código mudasse, mas porque *o tempo avançou*. 17/

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

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

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

Então, os nossos dispositivos móveis usaram este código para ajudar a determinar a sua localização, a fim de lhe fornecer direções passo a passo em aplicações de navegação. Depois, este código foi reutilizado novamente para nos ajudar a encontrar os nossos dispositivos perdidos. 22/

Isto tornou-se uma forma de localizar dispositivos *roubados*, um caso de uso que diverge acentuadamente de encontrar dispositivos perdidos. Ao localizar um dispositivo perdido, não tem de lidar com a possibilidade de que um ator malicioso desativou a funcionalidade "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) evento de não terem certeza de onde estão. 25/

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

Acontece que, em muitos casos, os aplicativos de localização desenharam um círculo em torno de todos os lugares onde *poderiam* estar e, em seguida, definiram sua localização para o meio desse círculo. 27/

Está tudo bem se o círculo tiver apenas alguns pés de diâmetro, ou se o aplicativo rapidamente substituir esta aproximação por uma localização mais precisa. Mas e se a localização tiver milhas e milhas 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 continental* e qualquer aplicativo que não saiba onde está relatar que está numa casa no Kansas? 29/

E na minha cidade de Burbank, onde o serviço de compartilhamento de localização do Google uma vez nos disse que a nossa filha de 11 anos (cujo telefone não conseguimos alcançar) estava a 12 milhas de distância, numa rampa de autoestrada em uma área não incorporada do condado de LA. 32/

(Ela estava num parque próximo, mas fora de alcance, e o aplicativo estimou sua localização como o centro da região onde a tinha fixado pela última vez.) (Foi um par de horas difíceis.) 33/

O código subjacente - o código que usa um padrão anteriormente inofensivo para disfarçar locais desconhecidos - precisa ser atualizado *constantemente*, porque os processos a montante, a jusante e adjacentes a ele estão mudando *constantemente*. 34/

Quanto mais tempo aquele código ficar ali, mais superadas se tornam as suas comportamentos originais, e mais barrocas, desatualizadas e ofuscadas se tornam as correções sobrepostas a ele. 35/

O código não é um ativo - é um passivo. Quanto mais tempo um sistema informático estiver em funcionamento, mais dívida técnica 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 aplicadas sobre isso, e onde as camadas de código se encontram, há fissuras nas quais esses sistemas se comportam de maneiras que não correspondem exatamente. 37/

Pior ainda: quando duas empresas são fundidas, os seus sistemas de TI emaranhados e fissurados são esmagados juntos, de modo que agora existem fontes *adjacentes* de dívida técnica, bem como fissuras a montante e a jusante: 38/

É por isso que as grandes empresas são tão suscetíveis a ataques de ransomware - estão cheias de sistemas incompatíveis que foram persuadidos a formar uma cópia de compatibilidade com várias formas de massa de modelar digital, corda e arame de amarração. 39/

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

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

As companhias aéreas são especialmente más, porque se informatizaram cedo e nunca conseguem desligar os antigos computadores para os substituir por novos. É por isso que as suas aplicações são tão péssimas. 42/

É por isso que é tão horrível que as companhias aéreas tenham despedido o seu pessoal de atendimento ao cliente e exijam 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 "Ocorreu um erro desconhecido" 40-80% do tempo não é (apenas) porque despediram todo o seu pessoal de TI e subcontrataram para licitantes de baixo custo no exterior. 44/

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

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

Isto significa que está preso a um número decrescente de fornecedores de hardware especializado e de centros de dados, pagando programadores especializados e construindo cadeias de código frágeis para conectar esses sistemas RISC aos seus equivalentes menos exóticos no mundo. O código não é um ativo. 47/

A IA pode escrever código, mas a IA não pode fazer engenharia de software. A engenharia de software é toda sobre pensar no *contexto* - o que virá antes deste sistema? O que virá depois? O que estará ao lado dele? Como o mundo mudará? 48/

A engenharia de software requer 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 exigem expansões *geométricas* nas demandas computacionais: 49/

Escrever código que funciona, sem considerar como ele falhará, é uma receita para catástrofe. É uma maneira de criar dívida técnica em grande escala. É como enterrar amianto nas paredes da nossa sociedade tecnológica. 50/

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

Eles pensam que encontraram uma máquina que produz *ativos* a 10.000 vezes a taxa de um programador humano. Não encontraram. Encontraram uma máquina que produz *passivos* a 10.000 vezes a taxa de qualquer programador humano. 52/

A manutenibilidade não é apenas uma questão de experiência arduamente conquistada que lhe ensina onde estão as armadilhas. 53/

Requer também o cultivo do "Fingerspitzengefühl" - a "sensação de ponta dos dedos" que permite fazer suposições razoáveis sobre onde podem surgir armadilhas nunca antes vistas. 54/

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

Pegue na Microsoft. A grande aposta deles neste momento é na "AI agentiva." Eles querem instalar spyware no seu computador que captura cada tecla pressionada, cada comunicação, cada ecrã que você vê e envia tudo para a nuvem da Microsoft, dando a uma variedade de chatbots acesso a isso. 56/

Eles afirmam que você poderá dizer ao seu computador: "Reserve-me um trem para Cardiff e encontre aquele hotel que o Cory mencionou no ano passado e reserve-me um quarto lá" e ele fará isso. Esta é uma ideia incrivelmente inviável. 57/

Nenhum chatbot é remotamente capaz de fazer todas essas coisas, algo que a Microsoft afirma livremente. Em vez de fazer isso com um único chatbot, a Microsoft propõe dividir isso entre dezenas de chatbots, cada um dos quais a Microsoft espera alcançar 95% de confiabilidade. 58/

Isso é um padrão de chatbot absolutamente implausível em si mesmo, 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 probabilidade de que essa tarefa seja realizada corretamente aproxima-se de *zero*. 60/

Entretanto, um executivo da Microsoft teve problemas em dezembro passado quando publicou no Linkedin anunciando sua intenção de fazer com que a IA reescrevesse *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 uma dívida técnica insustentável. 64/

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

É que as pessoas que não gostam de AI são "más em AI?" É que os fãs de AI são preguiçosos e não se importam com a qualidade do seu trabalho? 67/

Sem dúvida, há um pouco de ambos a acontecer, mas mesmo que ensines todos a serem especialistas em IA e excluas 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 reside na teoria da automação, e no conceito de "centauros" e "centauros reversos": 69/

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

Diga que você é um engenheiro de software que usa AI para escrever código rotineiro que você tem tempo e experiência para validar, utilizando seu Fingerspitzengefühl e conhecimento de processos para garantir que esteja adequado ao propósito. 71/

É fácil ver por que você pode achar útil usar AI (quando você escolher, da maneira que você escolher, no ritmo que você escolher). Mas digamos que você é um engenheiro de software que foi ordenado a produzir código a 10x, ou 100x, ou 10.000x sua taxa anterior. 72/

Diga que a única maneira de fazer isso é através da IA, e que não há maneira humana de você possivelmente rever esse código e garantir que ele não quebrará no primeiro contato com o mundo, você vai odiá-lo: 73/

(Você vai odiar ainda mais se tiver sido transformado no responsável pelas falhas da IA, pessoalmente responsável pelos erros da IA.) Há outra maneira pela qual os 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 - digamos, convertendo um lote de arquivos para outro formato, apenas uma vez - não precisa se preocupar com processos a montante, a jusante ou adjacentes. Não há nenhum. 75/

Você está escrevendo código para fazer algo uma vez, sem interagir com outros sistemas. Um *monte* de codificação é esse tipo de projeto utilitário. É tedioso, ingrato e propenso à automação. 76/

Muitos projetos pessoais caem nesta categoria e, claro, por definição, um projeto pessoal é um projeto centauro. Ninguém o obriga a usar AI em um projeto pessoal - é sempre sua escolha como e quando você faz uso pessoal de qualquer ferramenta. 77/

Mas o fato de que os engenheiros de software podem, às vezes, melhorar seu trabalho com AI não invalida o fato de que o código é um passivo, não um ativo, e que o código de AI representa produção de passivos em escala. 78/

Na história do desemprego tecnológico, existe a ideia de que a nova tecnologia cria novos empregos, mesmo enquanto torna obsoletos os antigos: para cada ferreiro que fica sem trabalho devido ao automóvel, há um emprego à espera como mecânico. 79/

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

Eu não contaria com conseguir trabalho em um comércio fantasioso que literalmente não pode ser imaginado porque as nossas consciências não mudaram tanto com a IA que adquiriram a capacidade de conceituar esses novos modos de trabalho. 81/

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

O código AI - escrito a 10.000 vezes a velocidade de qualquer programador humano, projetado para funcionar bem, mas não para falhar de forma elegante - é o amianto digital que estamos enchendo nas nossas paredes. Os nossos descendentes passarão gerações a retirar esse amianto das paredes. 83/

Haverá muito trabalho a fazer para corrigir as coisas que estragámos graças à mais perigosa psicose de IA de todas - a crença alucinatória de que "escrever código" é a mesma coisa que "engenharia de software." 84/

Ao ritmo que estamos a ir, teremos pleno emprego para gerações de removedores de amianto. 85/