Para que o agente fisicamente não consiga fazer merda

ilustração

Em 1961 o engenheiro japonês Shigeo Shingo chegou a uma fábrica da empresa Yamada Electric, onde se montavam pequenos interruptores. Cada interruptor devia ter, sob os seus dois botões, duas molinhas minúsculas, e de vez em quando os operários esqueciam de pôr uma delas. O interruptor sem mola ia para o cliente, o cliente o devolvia, e a fábrica perdia dinheiro e reputação. A direção resolvia o problema como ele é resolvido em quase todo lugar: explicava aos operários que era preciso prestar mais atenção e punia quem errava.

Shingo propôs outra coisa. Antes de montar cada interruptor, o operário agora tirava da caixa comum exatamente duas molinhas e as punha num pratinho, e só depois as colocava no lugar. Se depois da montagem sobrava uma molinha no pratinho, uma tinha sido esquecida, e isso se via na hora, sem precisar de atenção nenhuma. Os erros quase desapareceram. Shingo primeiro chamou esses dispositivos de baka-yoke, que significa literalmente “à prova de idiota”, e depois os rebatizou com o nome mais educado de poka-yoke, “à prova de erro involuntário”. Com esse nome eles entraram em todos os manuais de gestão da produção.

À nossa volta há dispositivos assim de sobra, só que não os notamos. O chip do celular tem um canto cortado, por isso é impossível colocá-lo no telefone do jeito errado. O carro com câmbio automático não deixa tirar a alavanca da posição de estacionamento enquanto você não pisar no freio. O pen drive do tipo mais novo pode ser encaixado de qualquer lado e funciona. Em todos esses casos ninguém pede à pessoa que preste mais atenção: o dispositivo é feito de tal modo que é fisicamente impossível errar.

Os agentes precisam do mesmo pratinho: não adianta pedir a eles “por favor, escreva código limpo”; é preciso construir um ambiente que simplesmente não aceite um resultado sujo.

---

Um ambiente assim é montado em camadas, e cada camada pega o seu tipo de erro. A maioria dessas ferramentas é décadas mais velha que os modelos de linguagem; elas foram inventadas para pessoas, e as pessoas as usavam de má vontade, porque elas irritam. Com os agentes tudo mudou, mas disso falo daqui a pouco; primeiro vamos passar pelas camadas, começando pelas mais simples.

A primeira camada cuida da aparência e dos pontos suspeitos. Um programa chamado formatador põe todo o código num único padrão: a mesma indentação, as mesmas aspas, a mesma ordem. Parece bobagem até você tentar ler um projeto em que quinze agentes escreveram, ao longo de um mês, cada um do seu jeito. Um programa chamado linter funciona como um revisor muito implicante: ele não sabe se o programa resolve a tarefa corretamente, mas nota os lugares que costumam acabar sendo erros, como uma variável que foi declarada e nunca usada, ou uma comparação que sempre dá o mesmo resultado. As duas ferramentas rodam em segundos e não custam quase nada.

Acima da aparência vêm os tipos. Nas linguagens de programação com tipos, cada valor tem um rótulo que diz o que ele é: o telefone da cliente é texto, o preço é um número em rublos, a data da visita é uma data. Um programa que verifica os tipos se recusa a montar um código em que se tenta somar o preço com o telefone ou passar uma data para onde se espera um número. Parece proteção contra erros bobos demais, mas nos programas reais há muitíssimos erros assim. Em 2017 pesquisadores da University College London e da Microsoft pegaram algumas centenas de bugs corrigidos em projetos abertos escritos em JavaScript, uma das linguagens mais difundidas, que por padrão não tem tipos, e verificaram quantos deles um sistema de tipos teria pegado se fosse usado. Deu cerca de quinze por cento, um em cada sete, e os autores frisavam que a estimativa era por baixo. Para o agente os tipos são especialmente valiosos, porque a mensagem de erro de tipo chega na hora e aponta o lugar com exatidão.