O futuro da engenharia
de software:
escrever ficou barato,
garantir não

1.1 O que esta apostila é — e o que ela não é

1.2 As três camadas: sinal, tendência, incerteza

Repare: o sinal é verificável, a tendência é uma leitura defensável, e a incerteza é honestamente aberta. Confundir os três é o que produz manchete.

1.3 O erro clássico das previsões nesta área

Praticamente toda previsão sobre programação nos últimos sessenta anos previu substituição e o que aconteceu foi adição e deslocamento. O COBOL foi anunciado como o fim da necessidade de programadores — "gerentes escreverão os programas". As ferramentas de geração visual dos anos 1990 idem. A programação declarativa, idem. Em todos os casos: a barreira caiu, a demanda cresceu, a natureza do trabalho mudou, e a profissão ficou maior — não menor.

Mas há um contra-argumento honesto, e ele precisa ficar registrado: o fato de o padrão ter se repetido não garante que se repita. Ondas anteriores subiram o nível de abstração com ferramentas determinísticas — um compilador dá sempre a mesma saída e ela é verificavelmente correta pela construção. Esta onda é diferente: a ferramenta é probabilística. Se essa diferença importa ou não é justamente uma das incertezas do cap. 8.

1.4 Horizonte e confiança

Horizonte: ~6 anos (2032). Cada projeção vem com grau de confiança declarado — alta, média ou baixa. Onde eu não sei, digo que não sei; num tema com esta densidade de hype, essa é a parte mais útil do documento.

2.1 Na produção de código

• Geração assistida virou padrão de ferramental — completar, gerar função a partir de descrição, traduzir entre linguagens, explicar código alheio.
• O ganho é real e desigual. Maior em código repetitivo, de fronteira bem definida e em linguagem/biblioteca popular; muito menor em sistema grande, antigo, com contexto implícito e regras de negócio idiossincráticas.
• Estudos e relatos convergem num ponto incômodo: a percepção de ganho de velocidade é sistematicamente maior que o ganho medido. Programadores sentem que foram mais rápidos mais do que de fato foram.
• Agentes que executam tarefas de várias etapas (ler o repositório, alterar vários arquivos, rodar teste, abrir proposta de mudança) saíram da demonstração para o uso real — com taxa de sucesso muito dependente do tamanho e da qualidade do repositório.

2.2 Na revisão e na qualidade

• O volume de código submetido a revisão cresceu sem aumento proporcional na capacidade de revisar.
• Revisão superficial de código gerado é um problema reconhecido: aprovar o que parece plausível é mais fácil do que aprovar o que se entende.
• Geração de teste ficou barata — e com isso apareceu um risco novo: teste gerado a partir do código apenas descreve o que o código faz, inclusive o defeito. Teste que não vem da intenção não verifica nada.
• Tipagem estática, contratos e verificações em tempo de compilação ganharam valor relativo — são a parte da garantia que não depende de alguém ler.

2.3 Na estrutura do trabalho

• O tempo de escrever caiu; o de entender, integrar, revisar e operar não. Onde o gargalo já era comunicação e decisão, o ganho total é pequeno.
• Cresceu a importância do que o modelo consegue "ver" — repositório organizado, testes existentes, tipos, documentação e convenções explícitas passaram a ter valor operacional direto.
• Sistemas antigos continuam sendo o grosso do trabalho real — e são exatamente onde a assistência ajuda menos.

2.4 Na segurança e na procedência

• Preocupação com procedência e licenciamento do código gerado, ainda sem resolução definitiva em vários mercados.
• Inventário de componentes de software passou a ser exigência em contratos e compras públicas em mercados relevantes.
• Ataques à cadeia de dependências continuaram crescendo — e a facilidade de gerar código aumenta a superfície de risco de dependências adicionadas sem escrutínio.

3.1 A cadeia inteira, e onde o custo estava

3.2 A consequência contraintuitiva

Quando escrever fica barato, a quantidade de código tende a crescer — e código é passivo, não ativo. Cada linha precisa ser entendida, mantida, migrada, auditada e eventualmente apagada. Uma equipe que produz três vezes mais código com a mesma capacidade de revisão e operação não ficou três vezes mais produtiva: ficou mais endividada.

É também um caso do padrão que economistas chamam de paradoxo de Jevons: baratear o uso de um recurso costuma aumentar o consumo total dele, não reduzir. Projeção (confiança alta): o volume de código em existência cresce mais rápido que a capacidade humana de compreendê-lo — e a diferença entre os dois é a variável central desta apostila.

3.3 Para onde o trabalho escasso se muda

4.1 Por que a revisão humana não escala

Ler código é mais difícil do que escrevê-lo — porque escrever é reconstruir uma intenção que você tem, e ler é reconstruir uma intenção que você não tem. Com volume crescente, a revisão degrada de forma previsível: de "entendi e concordo" para "parece razoável" e daí para "os testes passaram". E código gerado é especialmente ruim para revisão superficial, porque ele é plausível por construção — foi produzido para parecer com código correto. Os defeitos que sobrevivem são exatamente os que não parecem defeitos.

4.2 O arsenal de garantia, do mais fraco ao mais forte

4.3 A armadilha do teste gerado

4.4 A incerteza crítica

Incerteza crítica nº 1: a garantia acompanha a geração? Isto é — surgem meios baratos, confiáveis e amplamente adotados de saber que o código faz o que deveria, sem depender de leitura humana proporcional ao volume? Há razões para otimismo (tipos, propriedades e verificação formal são técnicas maduras e subutilizadas; e a mesma tecnologia que gera pode ajudar a especificar) e razões para pessimismo (verificação exige que exista uma especificação, e escrever especificação continua sendo trabalho humano difícil que ninguém quer fazer). Confiança sobre a resposta: baixa. É por isso que ela é um eixo, e não uma projeção.

5.1 As subidas anteriores e o padrão

O padrão: em todas, a camada de baixo virou descartável mas auditável — você normalmente não lê a saída, mas pode ler quando precisa, e ela é sempre a mesma para a mesma entrada. E em todas, a profissão cresceu.

5.2 As três diferenças que a analogia esconde

5.3 A projeção honesta

Projeção (confiança média): uma subida de abstração acontece, mas parcial e desigual — muito clara em software novo, de escopo delimitado e baixo risco; muito lenta em sistema grande, antigo e crítico, onde o código continua canônico até 2032. A ideia de um corte limpo em que "ninguém mais lê código" é improvável no horizonte desta apostila; a de que "nada muda" é igualmente improvável.

E a condição que decide: a subida só se completa se a camada de baixo virar confiável o bastante para não ser lida — que é dizer que o eixo da abstração depende do eixo da verificação. Eles são ortogonais como incertezas, mas ligados como mecanismo: é por isso que o cenário 2 do cap. 8 (abstração sem garantia) é o mais desconfortável dos quatro.

6.1 O software é uma teoria, não um texto

Há uma ideia antiga e pouco lembrada de Peter Naur: programar é construir uma teoria. O código é o registro parcial de um entendimento que existe na cabeça de quem o construiu — por que estas fronteiras, o que foi tentado e descartado, quais casos importam de verdade. Quando essa teoria se perde, o código continua rodando mas fica irremediavelmente difícil de modificar, porque cada mudança pode violar uma razão que ninguém sabe mais que existia.

Esta é a lente mais útil para pensar o problema desta força: a questão não é se o código gerado é bom, é se a teoria existe em algum lugar. Código gerado, revisado superficialmente e integrado sem que ninguém tenha construído a teoria correspondente nasce como sistema legado.

6.2 O que se perde e o que compensa

Repare que a coluna da direita é a mesma lista do cap. 4.2. Não é coincidência: o que serve para verificar é o que serve para preservar entendimento. Ambos são formas de tirar conhecimento da cabeça das pessoas e colocá-lo num lugar que não vai embora.

6.3 Propriedade e responsabilidade

Uma pergunta que as equipes ainda não responderam bem: quem responde pelo código que ninguém escreveu? A resposta que funciona é a mesma de sempre — quem integrou responde. Aprovar uma mudança é assumi-la, independentemente de quem ou o que a produziu. Isso soa óbvio e é rotineiramente violado na prática, com o "foi a ferramenta que gerou" funcionando como diluição informal de responsabilidade.

Projeção (confiança média-alta): equipes que mantêm a regra de propriedade explícita — quem aprova, responde — atravessam qualquer um dos quatro cenários melhor do que as que a diluem, porque essa regra é o que impede o volume de virar passivo silencioso.

7.1 O que já se move

• Inventário de componentes (SBOM) — saber exatamente o que compõe o seu software virou exigência contratual e de compra pública em mercados relevantes.
• Segurança da cadeia de suprimentos — procedência, assinatura de artefatos e construção reproduzível saíram do nicho para a exigência.
• Responsabilidade por defeito de software — a tendência regulatória em vários mercados é reduzir a proteção histórica da indústria, aproximando software de outros produtos quanto à responsabilidade por dano.
• Setores regulados (saúde, financeiro, automotivo, aeroespacial) já exigem rastreabilidade entre requisito, implementação e evidência de teste — e são o laboratório de como isso se parece.
• Procedência do código gerado — licenciamento e origem seguem como questão aberta, com risco concentrado em quem incorpora sem registro.

7.2 Por que isto importa para o futuro da disciplina

Rastreabilidade e responsabilidade empurram na direção oposta à do volume descuidado. Se alguém precisa demonstrar que um requisito virou um comportamento verificado, a especificação deixa de ser opcional — não por virtude, por contrato. E é isso que torna o cenário 4 do cap. 8 possível: a pressão institucional pode fornecer o incentivo que a virtude técnica sozinha não forneceu em cinquenta anos.

Projeção (confiança média-alta): até 2032, a exigência de rastreabilidade entre intenção, implementação e evidência se espalha dos setores regulados para o software corporativo comum — puxada por contrato e por seguro antes de por lei.

8.1 Os dois eixos de incerteza

8.2 Cenário 1 — A dívida acelerada

O que acontece: a geração barateia, o volume triplica, o nível de abstração não sobe e a verificação continua dependendo de leitura humana. Os sistemas ficam maiores, mais rápidos de construir e progressivamente mais difíceis de mudar. O trabalho da profissão migra para arqueologia: entender e consertar código que ninguém escreveu. Sintoma característico: entregar a primeira versão fica muito rápido, e a segunda muito lenta.

Teria de ser verdade: as técnicas de garantia continuarem subutilizadas; a pressão por velocidade vencer a por rigor; nenhuma exigência externa de rastreabilidade.

Sinais precoces: razão entre linhas integradas e horas de revisão subindo; tempo de recuperação de falha piorando enquanto a frequência de entrega melhora; equipes reescrevendo sistemas de dois anos de idade.

O que fazer: investir na metade de baixo da tabela de 4.2 antes de aumentar o volume — é a única defesa, e é barata comparada ao custo de sair depois.

8.3 Cenário 2 — A caixa-preta

O que acontece: a especificação vira a fonte de verdade e o código gerado passa a ser tratado como descartável, mas sem que exista meio confiável de garantir que ele faz o que a especificação diz. Alto poder de produção, baixa garantia. Funciona bem na maior parte do tempo, e falha de forma rara, difícil de diagnosticar e potencialmente grave. É o cenário mais desconfortável dos quatro — e não é implausível, porque a conveniência de não ler chega antes da capacidade de não precisar ler.

Teria de ser verdade: confiança adotada mais rápido que confiabilidade demonstrada; e ausência de um evento suficientemente caro para corrigir o rumo.

Sinais precoces: equipes descartando o código gerado da revisão por política; incidentes cuja causa ninguém consegue explicar; queda no percentual de código que alguém da equipe consegue explicar.

O que fazer: manter a regra de propriedade do cap. 6.3 e exigir que a fronteira crítica do sistema — a parte cuja falha é cara — permaneça verificável por outro meio que não a confiança.

8.4 Cenário 3 — O ofício da garantia

O que acontece: o código continua sendo o artefato canônico, mas o centro do ofício se desloca definitivamente de produzir para garantir. Tipagem forte, contratos, testes de propriedade, verificação formal em partes críticas e observabilidade séria viram o padrão profissional. Escrever é barato e quase irrelevante; saber que está certo é o que se paga. Provavelmente o cenário mais confortável para a profissão como ela existe hoje — e o mais compatível com sistemas antigos, que são a maior parte do software do mundo.

Teria de ser verdade: adoção ampla de técnicas de garantia que já existem e são subutilizadas; e pressão institucional (cap. 7) o bastante para justificar o investimento.

Sinais precoces: crescimento de linguagens e ferramentas com garantias fortes em tempo de compilação; teste de propriedade saindo do nicho; vagas descrevendo verificação como a competência central.

O que fazer: é o cenário para o qual vale a pena se preparar mesmo que ele não venha, porque tudo o que ele exige é útil nos outros três.

8.5 Cenário 4 — A nova camada

O que acontece: a subida de abstração se completa. A especificação executável — precisa, versionada, testável — vira o artefato que humanos escrevem e mantêm, e o código gerado passa a ser tratado como saída de compilador: auditável, mas normalmente não lido. Uma nova disciplina se forma acima, com suas próprias práticas de revisão, teste e modularidade. É a repetição literal do que aconteceu com o assembly — e é o cenário mais transformador.

Teria de ser verdade: o problema da verificação resolvido a ponto de a saída ser confiável sem leitura; e a linguagem de especificação ficar precisa o bastante para não ser ambígua — o que, na prática, significa que ela se parecerá menos com português e mais com uma linguagem formal legível. O que reabre uma velha ironia da área: a linguagem de especificação perfeitamente precisa já tem um nome — é uma linguagem de programação.

Sinais precoces: equipes versionando a especificação e regenerando o código a partir dela; ferramentas que garantem a correspondência entre as duas; a conversa que produziu o código sendo tratada como o artefato guardado.

O que fazer: praticar escrever intenção com precisão — que é a competência transferível para este cenário e útil em todos os outros.

10.1 As constantes

10.2 O que a história diz sobre as previsões desta área

• COBOL (1959) — "gerentes escreverão os próprios programas, programadores serão desnecessários". Resultado: uma profissão inteira de programadores COBOL, viva até hoje.
• Ferramentas de geração assistida por computador (anos 1980-90) — prometeram gerar o sistema a partir do diagrama. Resultado: diagramas que envelheciam mais rápido que o código.
• Programação visual e "sem código" (recorrente desde os anos 1990) — prometeram o fim da programação textual. Resultado: uma categoria de ferramenta útil para um conjunto delimitado de problemas, e programadores para todo o resto.
• Metodologias como bala de prata — cada onda prometeu resolver o problema da entrega. Resultado: melhorias reais e incrementais, nenhuma ordem de grandeza.

O padrão: cada onda entregou um ganho real na complexidade acidental, foi anunciada como o fim da profissão, e a profissão cresceu. Aplique o desconto correspondente às projeções desta apostila também — inclusive ao cenário 4, que é o mais entusiasmado dos quatro.

"Nenhum desenvolvimento isolado, em tecnologia ou em técnica de gestão, promete sequer um ganho de uma ordem de grandeza em produtividade, em confiabilidade, em simplicidade."

10.3 As ações robustas

12.1 Plano de treino — 30 dias, ~15 min/dia

12.2 Como montar a sua antena

12.3 Como não cair no hype

• Toda previsão de substituição é uma previsão de deslocamento até prova em contrário. Pergunte "o que barateou, e para onde o escasso se mudou?".
• Separe complexidade acidental de essencial. Ferramenta nova só ataca a primeira, e ela é finita.
• Desconfie de demonstração em problema novo e pequeno. O trabalho real é em sistema antigo e grande, e a diferença de desempenho entre os dois é enorme.
• Exija medição, não sensação. É o achado mais consistente do cap. 2.
• Cobertura não é garantia. Pergunte de onde veio o teste — da intenção ou do código.

12.4 Onde continuar

• Fundamento (envelheceram muito bem): "The Mythical Man-Month" e o ensaio "No Silver Bullet" (Frederick Brooks) · "Programming as Theory Building" (Peter Naur, 1985) · o artigo de Melvin Conway sobre organização e arquitetura (1968)
• Prática: "Accelerate" (Nicole Forsgren, Jez Humble, Gene Kim), sobre medir entrega com indicadores que resistem · "Working Effectively with Legacy Code" (Michael Feathers) · "Software Engineering at Google" (Titus Winters, Tom Manshreck, Hyrum Wright)
• Sobre complexidade: "Out of the Tar Pit" (Ben Moseley & Peter Marks) — o melhor tratamento moderno de essencial vs. acidental
• Nesta casa: O Futuro do Trabalho em Tecnologia (o lado da carreira) · Aceleração de Código com IA (a prática atual) · Testing Moderno & Automação · Arquitetura & System Design · Causa Raiz · Pensamento Sistêmico