---
title: "O mundo não vem com código-fonte"
description: "Todo sistema começa desmontando um mundo que ninguém documentou. O que se perde nesse desmonte não some do software: some da vida."
author: "Anderson Henrique"
date: "2026-08-08T00:00:00Z"
updated: "2026-08-13T11:35:33.588526Z"
category: "philosophy"
tags: ["Engenharia Reversa","Engenharia Social","James C. Scott","Modelagem de Dados","Ciência da Computação","Dados Abertos","NTLabs"]
canonical: "https://www.ntlabs.dev/blog/mundo-nao-vem-com-codigo-fonte"
locale: "pt"
---

*Engenharia reversa, o resíduo que o esquema apaga e a fronteira fina com a engenharia social.*

A primeira coisa que se aprende ao tentar fiscalizar o Estado brasileiro é que ele não vem documentado. Você baixa uma base de contratos públicos esperando ler dados e descobre que está lendo ruína: campos cujo significado não corresponde ao dicionário oficial, uma coluna de texto livre onde deveria haver um código padronizado e que, por isso mesmo, virou o lugar onde a informação de verdade se esconde. Valores negativos que só podem ser estornos, embora nenhum documento diga isso. Datas que se contradizem porque duas repartições diferentes preenchem o mesmo campo com regras diferentes, e nenhuma das duas sabe da outra.

Ninguém está mentindo. Não há conspiração ali. O que existe é um sistema em produção há décadas cuja especificação nunca foi escrita, e que só pode ser compreendido pelo comportamento que emite. Para auditar o Estado, é preciso primeiro fazer engenharia reversa dele.

Levei um tempo para perceber que essa não era a parte anômala do trabalho. Era o trabalho. E que quase tudo o que fazemos em engenharia de software é exatamente isso, só que raramente chamamos pelo nome.

## Todo requisito é um desmonte

Chamamos de engenharia reversa uma prática estreita: pegar um binário sem fonte, observar suas entradas e saídas, inferir a lógica, reimplementar. É o que se faz com um protocolo proprietário, com um driver sem documentação, com um formato de arquivo que uma empresa morta levou consigo.

Descreva o mesmo procedimento sem usar a palavra "binário" e você terá descrito o levantamento de requisitos.

Existe um sistema rodando em produção. Ele se chama cartório, pronto-socorro, cozinha de restaurante, secretaria de obras, feira de terça. Não tem código-fonte. Ninguém detém sua especificação completa, nem mesmo quem o opera todos os dias, porque boa parte de suas regras nunca foi verbalizada: foi aprendida no corpo, transmitida por imitação, sedimentada em décadas de exceções que funcionaram. Esse sistema tem estados ocultos, tratamento de erro não documentado, casos de borda que só aparecem em dezembro, e uma quantidade generosa de comportamento que os operadores negariam se perguntados diretamente.

O cientista da computação chega, observa, entrevista, mede, infere as regras a partir do comportamento, e produz uma reimplementação. Um modelo de dados é uma hipótese sobre como o mundo funciona, escrita numa linguagem que não admite ambiguidade. Um diagrama de estados é uma afirmação sobre quais situações podem existir na vida real e quais transições entre elas são legítimas. Uma constraint de banco é uma proibição ontológica: isto não pode acontecer.

Nada disso é neutro, e nada disso é "técnico" no sentido inofensivo da palavra. É antropologia com poder de execução.

## O que o desmonte não captura

Todo desmonte tem perda. Essa é a parte que a nossa profissão prefere tratar como detalhe de implementação.

James C. Scott, em *Seeing Like a State*, conta a história da silvicultura científica prussiana do século XVIII. O Estado precisava saber quanta madeira tinha, e a floresta real (com sua confusão de espécies, idades, arbustos, fungos, animais, gente coletando lenha e ervas) era ilegível para a contabilidade. A solução foi tornar a floresta legível: fileiras retas de uma única espécie, mesma idade, tudo mensurável, tudo previsível. O modelo funcionou lindamente. A primeira rotação foi um sucesso técnico e fiscal.

A segunda geração de árvores adoeceu. O que o esquema havia descartado como ruído (o sub-bosque, a diversidade de espécies, a fauna do solo, os fungos que faziam a ciclagem de nutrientes) era exatamente a infraestrutura que sustentava a produtividade contabilizada. A perda não estava no relatório porque, por definição, o relatório era feito das coisas que cabiam nele. Os alemães acabaram tendo que cunhar uma palavra para o resultado: *Waldsterben*, a morte da floresta.

Scott dá um nome ao conhecimento que essa operação destrói: *mētis*. É o saber prático, local, adquirido pela experiência, que não se codifica sem virar outra coisa. O jeito do pescador de ler a maré. O ponto exato em que o chef sabe que a carne virou. A intuição do servidor que, olhando o processo, sente que está faltando um documento antes de conferir a lista.

Todo sistema que construímos faz a operação da floresta prussiana em escala menor. O formulário aceita dois sobrenomes porque o desenvolvedor tinha dois. O campo de endereço exige logradouro e número, o que resolve a vida de quem mora numa rua nomeada e apaga do mapa quem mora no beco quatro, casa sem número, referência ao lado da igreja. O cadastro de família tem um campo "responsável", singular, e o arranjo doméstico real (avó, tia, vizinha que cria a criança na prática) não tem onde entrar. O sistema de agendamento não modela "encaixe", que é como a fila realmente funciona.

Nada disso é bug. É perda de tradução, e ela é inevitável. Um mapa que não perdesse nada teria o tamanho do território, como no conto do Borges, e seria inútil pela mesma razão que seria perfeito.

O problema não é a perda. É o que acontece depois dela.

## Quando a reimplementação vira o original

Na engenharia reversa clássica, você reimplementa um sistema e o original continua existindo. Se sua reimplementação erra, ela é que está errada, e o binário permanece lá como referência para você conferir.

Na engenharia reversa do mundo social não é assim. A reimplementação **substitui** o original. E, a partir do momento em que entra em produção, ela deixa de descrever o mundo e passa a prescrevê-lo.

Se o sistema não aceita seu endereço, você não mora em lugar nenhum. Se não há campo para o seu arranjo familiar, sua família não existe para efeito de benefício. Se o cadastro exige um documento que a sua realidade não produz, você é informal, e "informal" é apenas o nome que damos ao que sobrou de fora do esquema. As pessoas então fazem o que sempre fizeram diante de sistemas rígidos: se deformam para caber. Inventam um número para a casa. Declaram uma responsável que não é a real. Aprendem qual resposta o formulário quer ouvir.

O caso brasileiro mais bonito e mais triste disso é a cor. Em 1976, a PNAD fez uma pergunta aberta sobre cor da pele, e os brasileiros responderam com mais de cento e trinta denominações diferentes: morena, morena-clara, queimada de sol, canela, parda-escura, meio-branca. Era um povo se descrevendo com um vocabulário próprio, cheio de nuance, negociação e história. O esquema oficial aceita cinco categorias. E hoje, cinquenta anos depois, o debate racial brasileiro, as políticas públicas, as cotas, as estatísticas de violência, tudo isso acontece dentro daquelas cinco caixas. O esquema não descreveu a realidade racial do país: ele a reorganizou. Passamos a nos pensar na gramática que o formulário aceitava.

É por isso que insisto que modelagem de dados não é requisito de software. Um esquema é uma proposta sobre quais formas de existir serão reconhecidas. Quando ele entra em vigor num sistema que medeia acesso a saúde, crédito, benefício ou justiça, ele deixa de ser uma opinião sobre o mundo e vira uma condição do mundo. O cientista da computação, queira ou não, está no ramo de decidir o que de um povo sobrevive à tradução.

## A outra engenharia reversa: a que desmonta pessoas

Existe uma profissão inteira dedicada a fazer isso com seres humanos, e ela tem nome ruim por bons motivos.

A engenharia social, no sentido do atacante, é engenharia reversa aplicada a protocolos humanos. Kevin Mitnick construiu sua fama demonstrando que quase nunca precisava quebrar a criptografia: bastava desmontar o procedimento social que a cercava. Ele mapeava a hierarquia (quem pode contrariar quem), a pressa (ninguém audita direito na sexta às seis), o medo de parecer incompetente, o desejo genuíno de ajudar um colega. A partir desses achados, construía uma reimplementação: um roteiro de telefonema que executava o protocolo humano com precisão de compilador.

Repare que o método é idêntico ao nosso. Observar o comportamento, inferir as regras não escritas, encontrar o caso de borda, explorar a diferença entre o processo oficial e o processo real. A diferença entre o engenheiro social e o analista de requisitos não está na técnica. Está no que cada um faz com o mapa.

E é aqui que a coisa fica desconfortável para quem constrói produto. O mesmo estudo dos vieses cognitivos que produz um onboarding gentil produz um *dark pattern*. A mesma leitura fina da ansiedade que gera uma notificação útil gera o gatilho que impede o cancelamento da assinatura. A economia comportamental aplicada ao design é engenharia reversa do humano, e a fronteira entre servir e capturar é uma decisão ética tomada por alguém, não uma propriedade do método. Quem trabalha com interface trabalha com a mesma alavanca que o atacante, apenas apontada para outro lado. Fingir o contrário é a forma mais comum de ingenuidade profissional que conheço.

## Popper e a cerca

Há ainda um terceiro sentido de engenharia social, o mais antigo: projetar sociedade.

Popper distinguia dois modos de fazê-lo. A engenharia social utópica parte de um projeto integral da sociedade ideal e reconstrói tudo a partir dele. A engenharia social gradual altera uma peça por vez, mede, corrige. A objeção de Popper à primeira não era moral, era epistemológica: não sabemos o suficiente. O sistema é complexo demais, nossas hipóteses sobre ele são frágeis demais, e um projeto total não deixa como detectar em que ponto errou.

Traduzindo para o nosso vocabulário: engenharia social utópica é um *rewrite from scratch* de um sistema legado em produção sem ler o código antigo. Todo desenvolvedor com alguma quilometragem sabe como isso termina. O código legado é feio porque está cheio de correções para casos que você ainda não encontrou. Cada `if` estranho é um incidente que alguém viveu. Reescrever sem entender é apagar uma década de aprendizado empírico e reintroduzir, uma a uma, todas as falhas que aquelas linhas evitavam.

É a cerca de Chesterton, que é literalmente um argumento de engenharia reversa: você encontra uma cerca no meio do campo e não vê utilidade nela. A resposta apressada é derrubá-la. A resposta madura é não tocar nela até descobrir por que alguém a construiu.

Traga isso para o dia a dia do ofício e a lição é imediata. Aquela planilha paralela que o setor mantém "porque o sistema não faz" não é indisciplina: é a especificação que ninguém te contou. A gambiarra é o relatório de bug mais honesto que a sua arquitetura vai receber. O processo informal que todo mundo usa, e que o manual proíbe, está lá porque o processo formal falha em algum caso real e recorrente. Se sua migração apaga a gambiarra sem entender a cerca, você não modernizou nada: você reintroduziu o problema original com um front-end melhor.

## A objeção que eu mesmo faria

Seria fácil terminar aqui com a moral de que precisamos "compreender profundamente antes de construir". Só que essa conclusão é vaga o bastante para ser inútil, e há duas objeções sérias contra ela.

A primeira é que compreensão total é impossível, e a busca por ela é uma forma elegante de paralisia. Nenhum levantamento captura o *mētis*, por definição, porque o que é codificável já não é *mētis*. Se a condição para construir fosse entender tudo, não se construiria nada, e a inação também tem vítimas: quem hoje não tem sistema nenhum, e por isso não tem acesso a nada.

A segunda é a que já apontei: engenharia reversa é a ferramenta do atacante. Defender a prática em abstrato é defender também quem a usa para desmontar pessoas.

Aceito as duas, e elas mudam a tese em vez de derrubá-la. O objetivo não é eliminar a perda de tradução, que é constitutiva do ato de modelar. O objetivo é saber **onde** a perda está e **quem** paga por ela. Uma perda documentada é engenharia. Uma perda invisível é ideologia, e passa a operar como se fosse a natureza das coisas. A diferença entre o engenheiro e o ideólogo não é o tamanho do erro: é se ele deixou como descobri-lo.

## O ofício, então

Do que ficou dito, algumas coisas se seguem para quem faz software de verdade, com prazo e orçamento.

Observe comportamento, não discurso. O que as pessoas dizem que fazem é o manual; o que fazem é o binário. Levantamento de requisitos feito só por entrevista é leitura de documentação de terceiros, e você já sabe o quanto ela vale.

Trate a exceção como especificação. Toda planilha paralela, todo caderno embaixo do balcão, todo campo de observação usado como se fosse banco de dados é uma funcionalidade que o mundo exige e o seu esquema recusou.

Registre o que você jogou fora. Adotamos ADRs para decisões de arquitetura, e quase nunca registramos a decisão mais consequente de todas: o que este modelo se recusa a representar, e quem fica de fora quando ele se recusa. Uma lista de perdas conhecidas vale mais que um diagrama bonito, porque é ela que permite auditar o dano depois.

Construa sistemas desmontáveis. Se um sistema medeia direitos, ele precisa ser reversível por quem depende dele: log legível, decisão explicável, dado exportável, critério auditável. Explicabilidade não é enfeite acadêmico, é engenharia reversa institucionalizada, oferecida pelo próprio sistema em vez de arrancada dele à força. É por isso que caixa-preta em decisão pública não é um problema de performance: é uma decisão política sobre quem pode contestar o quê.

## O direito de desmontar

O que me leva ao ponto que considero o mais importante, e que extrapola a engenharia.

Nossa legislação já reconhece pedaços disso, mesmo sem usar a palavra. A Lei de Acesso à Informação existe para que o cidadão possa examinar o funcionamento do Estado. A LGPD prevê que se peça revisão de decisões tomadas automaticamente e informação sobre os critérios usados, com as ressalvas de sigilo comercial que a própria lei estabelece. São, no fundo, dispositivos de engenharia reversa: garantias de que sistemas que decidem sobre a sua vida possam ser abertos e questionados.

Reduzir isso a *compliance* é perder o que está em jogo. Um povo cujas relações são mediadas por sistemas que ele não pode desmontar não é um povo mal atendido pela tecnologia: é um povo que perdeu acesso à gramática da própria vida em comum. As regras que organizam quem recebe benefício, quem entra na fila da cirurgia, quem tem crédito negado, quem é sinalizado como suspeito, essas regras já foram escritas em algum lugar, por alguém, a partir de alguma leitura do que somos. Se não podem ser lidas de volta, deixaram de ser decisões coletivas e viraram fatos naturais. E contra fatos naturais não se argumenta: apenas se sofre.

É por isso que penso na engenharia reversa como uma competência civil, e não como uma técnica de nicho para quem gosta de desmontar binário. Ela é o gesto de recusar que um sistema seja o mundo. É a diferença entre habitar uma realidade e ser executado por ela.

O mundo não vem com código-fonte. A cada esquema que escrevemos, entregamos uma versão dele para as pessoas viverem dentro. O mínimo que devemos é deixar a tampa aberta.

---

*Este texto faz parte da reflexão sobre **engenharia transparente** na NTLabs: como construímos, o que decidimos representar e o que assumimos estar deixando de fora.*