Correctness, confidence, and context: Framing software assurance in the AI age

O Grande Enigma do Software: Por que o "Perfeito" Não é o Objetivo

Imagine que você está construindo um castelo gigante e invisível feito de lógica e instruções. É isso que os engenheiros de software fazem todos os dias. Eles escrevem código para fazer os computadores realizarem tarefas, desde pedir uma pizza até voar aviões. Por muito tempo, o sonho era construir esses castelos de forma tão perfeita que eles nunca, jamais, pudessem cometer um erro. Os engenheiros queriam provar matematicamente que cada tijolo estava no lugar certo. Mas aqui está o problema: o mundo real é bagunçado. Ele é cheio de regras não ditas, hábitos culturais e "senso comum" que você não consegue registrar em uma lista de instruções.

Agora, imagine que um novo tipo de ajudante chegou: a Inteligência Artificial (IA). Esta IA é incrivelmente inteligente em adivinhar o que vem a seguir, como um adivinhador superveloz que leu quase todos os livros já escritos. Mas, ao contrário dos engenheiros da velha guarda que queriam provar as coisas, esta IA trabalha com probabilidades. Ela diz: "Estou 90% certa de que esta é a resposta correta", em vez de "Eu sei, com certeza, que esta é a resposta correta". Isso cria um grande problema: Como confiar em um sistema que é construído sobre suposições quando precisamos que ele seja seguro? Este é o enigma que Mary Shaw está enfrentando. Ela quer mudar a forma como pensamos sobre a "correção" do software, afastando-nos do sonho impossível da perfeição e aproximando-nos de uma abordagem mais prática e de engenharia, de garantir que as coisas sejam "boas o suficiente" para o trabalho que precisam realizar.

---

A Grande Ideia do Artigo: Do "Perfeito" ao "Bom o Suficiente"

Nesta apresentação principal para engenheiros de software, Mary Shaw argumenta que precisamos parar de tentar provar que nosso software é 100% perfeito e começar a focar se ele é adequado ao seu propósito. Ela sugere que a antiga forma de pensar — tentar escrever um conjunto perfeito de regras para provar que um programa está correto — está quebrada, especialmente agora que estamos usando IA.

Aqui está a história do argumento dela, dividida em partes simples:

1. O Problema da Sombra: O Que a IA Não Consegue Ver

Imagine que você está tentando descrever um objeto complexo, como um copo de papel dobrável, para um amigo que nunca viu um. Você só pode mostrar a ele as sombras que o objeto projeta em uma parede. De frente, a sombra parece um quadrado. De lado, parece um triângulo. De cima, parece um círculo. Se você tivesse apenas as sombras, poderia adivinhar que é um bloco estranho, mas perderia o fato de que é um copo que pode conter água.

Shaw diz que os modelos de IA são como esse amigo olhando para sombras. Eles são treinados em "sombras digitais" — o texto, o código e os dados que existem online. Mas o mundo real é cheio de conhecimento tácito: coisas que sabemos, mas não escrevemos. Isso inclui a "vibe" de um local de trabalho, as regras não ditas de uma cultura ou o pressentimento de um mecânico experiente ao ouvir um barulho estranho em um motor. Como esse conhecimento não é escrito, a IA não consegue vê-lo. Ela vê apenas a sombra, não o objeto real. Quando a IA tenta construir software, ela pode perder esses detalhes cruciais e invisíveis, levando a erros que um especialista humano teria detectado imediatamente.

2. O "Culto à Cargo" da Programação

Shaw conta a história de pessoas em ilhas que viram aviões pousando com comida durante uma guerra. Quando a guerra acabou e os aviões pararam de vir, os habitantes locais construíram torres de controle de bambu e marcharam em formação, esperando atrair os aviões de volta. Eles copiaram as sombras da atividade (a marcha, as torres), mas perderam a causa real (a logística e o cronograma militares).

Ela alerta que usar IA para escrever código pode, às vezes, tornar-se um "culto à cargo" (cargo cult). Podemos pedir à IA para escrever um código que pareça correto (a sombra) sem entender as razões profundas do porquê o código precisa ser daquela maneira. Se apenas pedirmos por "vibe coding" (escrever código baseado em um sentimento ou um comando simples) sem entender as regras ocultas, podemos construir sistemas que parecem bons, mas que desmoronam quando problemas do mundo real acontecem.

3. As "Credenciais" em vez das "Especificações"

Tradicionalmente, os engenheiros tentam escrever uma "especificação" perfeita — um livro de regras gigante e rígido que diz exatamente o que o software deve fazer. Shaw sugere que isso é impossível porque o mundo muda e não podemos prever tudo.

Em vez disso, ela propõe que tratemos o software como uma pessoa se candidatando a um emprego. Não precisamos de toda a história de vida dela; precisamos apenas de suas credenciais.

• Um mergulhador mostra um cartão dizendo: "Posso mergulhar a 30 metros".
• Um piloto mostra uma licença dizendo: "Posso voar este avião".
• Um sistema de software deve mostrar uma "credencial" que diga: "Tenho 90% de confiança de que posso lidar com 1.000 usuários" ou "Fui testado para ser seguro para esta tarefa específica".

Essas credenciais não são provas perfeitas; são declarações honestas sobre o quão confiantes estamos, de onde veio essa confiança e quais são os limites. É uma forma de dizer: "Nós verificamos isso, e aqui está o quão certos estamos".

4. A Escolha do Engenheiro: Satisficing

O artigo sugere que devemos parar de tentar ser perfeitos e começar a praticar o satisficing. Este é um termo sofisticado para "encontrar uma solução que seja boa o suficiente".

• Se você está construindo um jogo, pode não precisar de 100% de perfeição. Alguns bugs são aceitáveis se o jogo for divertido e barato de produzir.
• Se você está construindo um dispositivo médico, precisa de um nível muito mais alto de confiança.

Shaw argumenta que os engenheiros devem agir como verdadeiros engenheiros: eles devem observar o custo, o risco e o propósito, e então escolher a mistura certa de ferramentas para realizar o trabalho. Às vezes, é mais barato corrigir um problema depois que ele acontece do que tentar evitar que ele ocorra. O objetivo não é eliminar todos os erros (o que é impossível); o objetivo é gerenciar o risco para que o sistema seja seguro e útil para seu trabalho específico.

O Que Isso Significa para o Futuro

Mary Shaw não está dizendo que a IA é ruim. Ela está dizendo que não podemos tratar a IA como uma varinha mágica que resolve tudo. Precisamos ser mais inteligentes sobre como a usamos. Precisamos aceitar que a IA trabalha com suposições (estatística) e que ela não consegue ver as "sombras" invisíveis da cultura e da experiência humana.

Sua mensagem principal é um chamado à ação para a comunidade de software: Vamos parar de fingir que podemos provar que tudo é perfeito. Em vez disso, sejamos engenheiros honestos. Vamos construir sistemas onde saibamos exatamente sobre o que temos confiança, o que não temos e o porquê. Ao fazer isso, podemos usar a IA para nos ajudar a construir softwares melhores, sem cair na armadilha de pensar que resolvemos o insolúvel.

Em resumo, o artigo sugere que o futuro do software não é sobre ser "correto" no sentido de um livro de matemática. É sobre ser adequado ao propósito, conhecer nossos limites e fazer escolhas inteligentes e econômicas para manter nosso mundo digital funcionando com segurança.