Prefácio
ilustraçãoEnquanto escrevo estas linhas, na janela ao lado um programa que eu não escrevi está refazendo outro programa que eu também não escrevi, e de vez em quando dou uma olhada para lá mais ou menos como o dono da casa olha para o sujeito que está trocando o papel de parede: as paredes parecem retas, os cantos estão no lugar, ninguém cobriu as tomadas, e não há motivo para intervir até o sujeito estender a mão para uma parede estrutural dizendo “aqui vai ficar mais espaçoso”. Uns cinco anos atrás essa cena seria ficção científica; hoje virou rotina de trabalho de centenas de milhares de pessoas, e a maioria delas, pelo que consigo perceber nas conversas, ainda não decidiu se deve comemorar ou começar a procurar outra profissão.
Em 2024 eu ainda estava refazendo um grande programa de servidor em Nest.js, escrito como um bloco único, e nesse trabalho a IA era uma ajudante que sugeria linhas e às vezes escrevia uma função inteira. No dia dois de abril de 2025 eu estava testando um bot de Telegram montado com peças prontas: um modelo de linguagem, a biblioteca LangChain, que ensina o modelo a usar ferramentas, o serviço Composio, que lhe dá acesso a programas de terceiros, e o Kommo, um CRM comum, onde o departamento de vendas guarda as fichas dos clientes. A meu pedido o bot foi sozinho até o Kommo, e poucos segundos depois apareceram num CRM de verdade a empresa INITE, com o número 200794, e um contato chamado Ivan Ivanov, com o número 200800. Ninguém escreveu uma única linha de código para isso: o modelo simplesmente fez o que antes o vendedor fazia clicando num formulário.
Depois o bot tentou preencher alguns campos adicionais da empresa, e tudo desmoronou por causa do formato de uma única string. Ele tentou de novo sem esses campos, a tentativa passou, só que o vínculo entre a empresa e o contato, com o qual eu contava, nunca apareceu. O erro era bobo, mas de um tipo novo: um programa que ninguém escreveu mudou o estado de um sistema real, fez isso pela metade, e agora havia no banco de dados registros que pareciam corretos e não eram. Coube a mim resolver.
Nessa miudeza já estava quase tudo de que este livro trata: o que aconteceu com o desenvolvimento de software quando as máquinas aprenderam a escrever código sozinhas, e por que as pessoas tiraram disso a conclusão que não deviam ter tirado.
Começo pelo fato de que, durante sessenta anos, a profissão de programador foi construída em torno de um único incômodo, que todos tomavam pela sua essência. Uma pessoa tinha uma ideia, por exemplo, “que o banco debite a conta de luz no dia cinco e, se não houver dinheiro, espere até o dia dez e mande uma carta educada”, e essa ideia precisava ser traduzida à mão para uma linguagem que a máquina entendesse, linha por linha, com pontos e vírgulas, parênteses e nomes de variáveis que seis meses depois nem o próprio autor conseguia decifrar. A tradução era lenta, cara e exigia formação especial, e por isso cresceu em volta dela uma indústria enorme, com cursos, entrevistas, salários e piadas sobre o programador que transforma café em código. Visto de fora, parecia que programar era essa tradução, já que era nela que ia a maior parte do dia de trabalho.
Os modelos de linguagem zeraram o custo da tradução. Agora basta explicar a ideia da conta de luz à máquina com palavras comuns, e um minuto depois ela devolve algumas centenas de linhas que, muito provavelmente, até vão rodar. Disso se concluiu quase de imediato que agora qualquer um pode programar, e essa conclusão é repetida em palcos de conferência, em anúncios e em conversas com investidores com tanta segurança que parece ter sido provada.
Na prática aconteceu o contrário, e o livro inteiro, no fundo, explica por quê. Quando escrever código ficou quase de graça, o que passou a faltar foi a capacidade de não escrever nada a mais: entender quais daquelas centenas de linhas são necessárias, o que elas vão quebrar na vizinhança, quem vai responder por elas daqui a um ano e o que acontece quando o banco debita a conta de luz duas vezes porque, em algum lugar no fundo do sistema, a segunda tentativa de enviar o pagamento não se distinguia em nada da primeira.
Este livro foi escrito para pessoas que não escrevem código e talvez nunca tenham escrito. Parto de uma consideração simples: os programas já administram há muito tempo o seu dinheiro, o seu carro, o seu prontuário médico e o que aparece no seu feed, então a pergunta sobre quem os faz agora, e como, diz respeito a você mais ou menos tanto quanto a pergunta sobre quem constrói agora as pontes por onde você passa. Haverá no texto tantas palavras técnicas quantas forem inevitáveis, e cada uma eu vou explicar no momento em que for necessária pela primeira vez.
Meu material vem de duas fontes. A primeira são pesquisas, relatórios e experimentos alheios, e onde eu me apoiar neles ficará claro em quê exatamente. A segunda é a minha própria prática: há muitos anos eu monto sistemas de software, nos últimos anos principalmente com as mãos das máquinas, e boa parte do livro nasceu de erros que eu consegui cometer antes de ler sobre eles nos artigos dos outros. Vou tentar dizer claramente onde terminam os dados e começa a minha opinião, para que você saiba a qualquer momento em que se pode acreditar neste livro sem mais nem menos e o que vale a pena conferir por conta própria.
O caminho aqui é o seguinte. Primeiro vou mostrar de onde veio o jeito atual de escrever programas e por que os seus primeiros resultados embriagam tanto. Depois, onde ele quebra e por que quebra no ponto em que entra em jogo a responsabilidade. Em seguida virá a conversa sobre como se constrói um ambiente em que a máquina pode escrever código sem supervisão e ainda assim não destruir tudo em volta, como funciona a sua memória e o que acontece quando os programas começam a se consertar sozinhos. No fim fica a pergunta sobre as pessoas: o que será de quem escrevia esse código e de onde virão os mestres, se o aprendiz não tem mais motivo para pegar a mão.
O título do livro soa como provocação, e nos primeiros capítulos vai ser isso mesmo. Nos últimos, espero, você vai se convencer de que ele descreve a situação ao pé da letra: o código não sumiu, e hoje se produz mais código do que em qualquer outro momento da história; acontece só que escrever código deixou de ser o acontecimento principal do desenvolvimento de software. Os acontecimentos principais passaram a ser as decisões sobre o que não se pode fazer, a verificação do que foi feito e a responsabilidade pelo resultado.
O desenvolvimento começa onde termina a escrita do código.