Certo na Teoria, Inútil na Prática: IA, Dívida de Conhecimento e o Sujeito Oculto da Liderança Técnica

Há um gênero literário que floresceu nos últimos dois anos e que os antigos teriam classificado sem hesitação: o diagnóstico impecável. Ele começa com uma distinção correta, apresenta um dado real, conclui com uma frase de efeito sobre o novo papel do engenheiro e não custa absolutamente nada a quem o escreve. É retórica deliberativa no sentido aristotélico, discurso sobre o que deve ser feito, com uma particularidade notável: o sujeito da ação nunca aparece.

O exemplar mais comum desse gênero, em 2026, argumenta o seguinte. Sistemas pequenos e descartáveis podem ser entregues à IA quase por inteiro; sistemas legados, críticos e integrados exigem supervisão próxima. Alguém precisa acompanhar o código sendo gerado, entender o que ele altera na arquitetura, validar segurança e escopo. Cabe a quem lidera tecnologia separar a resistência desproporcional daquela que sinaliza risco real. E o papel do engenheiro de software deixa de ser escrever tudo para decidir, sistema a sistema, quanta autonomia aquele código pode ter.

Está certo. Cada proposição, isoladamente, é verdadeira. E é exatamente por isso que vale a pena examinar o que falta: porque a distância entre um diagnóstico correto e uma organização capaz de executá-lo é o assunto de um dos textos mais desconfortáveis de Kant, e o tema deste ensaio.

O sujeito oculto

Comecemos pela gramática, que costuma ser mais honesta que a intenção.

"Alguém precisa acompanhar de perto." O português chama isso de sujeito indeterminado. A liderança técnica chama de estratégia. É a construção sintática que permite enunciar uma obrigação sem alocá-la, descrever um trabalho sem orçá-lo, e transferir uma responsabilidade sem transferir junto a capacidade de exercê-la.

Porque a pergunta operacional não é se alguém precisa acompanhar. É: quem, com qual conhecimento prévio, em qual fração do dia, e com qual autoridade para dizer não?

Se a resposta for "o time", convém verificar se esse time conhece a arquitetura do sistema que herdou. Se conhece as decisões que produziram aquele acoplamento estranho entre dois módulos. Se sabe por que existe aquela transação distribuída feia que ninguém ousa tocar. Se entende que a tabela com nome errado é assim desde a migração de 2019 e que três integrações dependem daquele nome errado.

Quando a resposta a essas perguntas é não, e frequentemente é, porque o time entrou depois, herdou o código sem herdar o contexto e recebeu a IA como compensação pela ausência de onboarding, a frase "alguém precisa acompanhar de perto" não descreve um processo. Descreve uma esperança.

Kant e o ditado comum

Em 1793, Kant publicou um ensaio cujo título é longo demais para caber em post: Sobre o ditado comum: isto pode estar certo na teoria, mas nada vale na prática. O alvo dele era a desculpa favorita dos pragmáticos de todos os séculos, a ideia de que a teoria é bonita, mas a realidade é outra coisa.

A resposta de Kant é surpreendentemente dura, e vale invertida aqui. Ele argumenta que se uma teoria correta não funciona na prática, o problema não está na prática, está na teoria, que é incompleta. Falta-lhe alguma coisa. E o que costuma faltar, diz ele, é o termo intermediário: a faculdade do juízo (Urteilskraft), a capacidade de subsumir o caso particular sob a regra geral.

O detalhe cruel é o seguinte: para Kant, a faculdade do juízo não pode ser suprida por mais regras. Se você acrescentar uma regra que explique como aplicar a primeira, precisará de uma terceira que explique como aplicar a segunda, e assim ao infinito. O juízo é um talento natural que só se desenvolve com exercício sobre casos concretos. É por isso, observa Kant em outro lugar, que um médico pode saber toda a teoria e ainda assim errar o diagnóstico do paciente à sua frente.

Traduzindo para 2026: a política de "supervisionar a IA em sistemas críticos" é uma teoria correta. Se ela não funciona na sua empresa, o problema não é que os desenvolvedores sejam preguiçosos ou resistentes. É que a teoria está incompleta, falta o termo intermediário, que é o conhecimento particular daquele sistema. E esse conhecimento não se transmite em reunião de alinhamento, não vem em documento de arquitetura desatualizado e, definitivamente, não vem no contexto de um prompt.

Popper e a ordem "observe"

O texto do gênero diagnóstico costuma trazer uma instrução operacional específica, e ela merece atenção: não basta revisar no final, é preciso observar o código sendo criado.

Karl Popper gostava de começar suas aulas dando aos alunos uma ordem simples: "Observem!". Os alunos, previsivelmente, perguntavam: observar o quê? O ponto de Popper é que não existe observação sem uma expectativa prévia que a organize, sem um problema, uma hipótese, um quadro teórico que determine o que conta como relevante. Norwood Russell Hanson formalizou isso em 1958 na tese de que toda observação é carregada de teoria: Tycho Brahe e Kepler, olhando para o mesmo nascer do sol, não veem a mesma coisa.

Aplicado a um diff gerado por IA, isso deixa de ser epistemologia e vira operação. Duas pessoas revisam a mesma alteração de trinta linhas. A primeira conhece o sistema: vê que a mudança introduz uma segunda fonte de verdade para o status do pedido, que o novo join vai passar por uma tabela que cresce trinta mil linhas por dia, que aquele retry silencioso vai gerar cobrança duplicada em um dos três consumidores da fila. A segunda pessoa vê trinta linhas de código sintaticamente corretas, bem nomeadas, com testes que passam.

As duas "observaram de perto". Uma revisou. A outra assistiu.

Determinar que o time observe o código sendo gerado, sem antes construir a teoria que torna a observação possível, é dar a ordem de Popper e esperar ciência.

Aristóteles: a prudência exige o particular

Aristóteles trata desse problema exato no Livro VI da Ética a Nicômaco, e a passagem é constrangedoramente atual. A phronesis, prudência, sabedoria prática, não é conhecimento de princípios universais. É a capacidade de deliberar bem sobre o que é bom em circunstâncias particulares, e por isso, diz ele, jovens podem ser excelentes matemáticos, mas não podem ser prudentes: a matemática se abstrai da experiência, ao passo que a prudência lida com particulares, e particulares só se conhecem pela experiência acumulada.

Note-se o que isso significa para a tese de que o engenheiro passa a ser quem decide o grau de autonomia de cada sistema. É uma tese correta e uma promoção real, mas ela transfere para o time precisamente a virtude que Aristóteles considera impossível de adquirir sem tempo no particular. Um engenheiro que entrou há quatro meses em um sistema de dez anos não pode calibrar o risco desse sistema, não porque lhe falte inteligência ou princípios, mas porque lhe falta o único insumo do qual a prudência é feita.

Há um segundo ponto, no Livro III, sobre responsabilidade. Aristóteles distingue a ignorância do particular, que torna o ato involuntário e desculpável, da ignorância que o próprio agente é responsável por ter produzido, e cita o legislador que pune duplamente o bêbado, porque a causa da ignorância estava em seu poder. É uma distinção que a liderança técnica pode achar interessante. Quando uma organização coloca em um sistema crítico um time sem background, dissolve o conhecimento arquitetural em rotatividade, não financia onboarding, não escreve ADRs, não mantém testes de caracterização e distribui licenças de IA como se fossem experiência, a ignorância resultante não é do time. É da organização, e ela é culpável.

Cobrar prudência de quem foi estruturalmente impedido de desenvolvê-la é a versão corporativa de punir o bêbado sem nunca ter proibido a bebida.

Naur: o programa é uma teoria, e teorias morrem

Em 1985, Peter Naur escreveu o texto que deveria ser leitura obrigatória antes de qualquer discussão sobre IA e sistemas legados: Programming as Theory Building. Apoiando-se explicitamente na distinção de Gilbert Ryle entre saber-que e saber-como, Naur argumenta que o produto essencial da programação não é o código nem a documentação. É uma teoria, a compreensão, existente na mente dos programadores, de como o mundo do problema se mapeia no artefato, por que as coisas são como são, e quais modificações são coerentes com a estrutura.

A consequência que Naur extrai é brutal e empiricamente verificável em qualquer empresa com mais de dez anos de código: quando o grupo que detém a teoria se dispersa, o programa morre, ainda que cada byte-fonte permaneça intacto. Um novo time, munido do código e da documentação, não reconstrói a teoria original. Reconstrói uma teoria diferente, mais pobre, e a partir dali passa a modificar o sistema com base em um modelo que não corresponde ao que o sistema é. As alterações "funcionam" individualmente e degradam o todo, exatamente o padrão que qualquer um reconhece em sistemas legados mal mantidos.

E aqui está o ponto que o gênero diagnóstico não alcança: a IA generativa não constrói teoria, ela consome e produz texto. Ela lê o código, que Naur trata como a documentação, não como o conhecimento, e produz alterações plausíveis em relação a esse texto. Não tem acesso ao porquê. Não sabe que aquele campo redundante existe porque a integração com o ERP nunca foi corrigida. Não sabe que aquela regra aparentemente arbitrária é uma exigência regulatória.

O que uma organização faz ao colocar IA em um sistema crítico sem preservar a teoria não é acelerar o desenvolvimento. É acelerar a taxa de modificação de um artefato cuja teoria já morreu. Naur previu o resultado sem precisar da IA; a IA apenas ajustou a escala.

O que os números realmente dizem

Os dados costumam ser citados nesses posts como evidência de calibração madura de risco. Vale relê-los.

A pesquisa da Stack Overflow de 2025, com 49 mil respondentes em 166 países, mostra que 84% dos desenvolvedores usam ou planejam usar ferramentas de IA, contra 76% em 2024, enquanto 46% declaram não confiar na precisão dos resultados, salto expressivo frente aos 31% do ano anterior. A confiança declarada ficou em 33%, e apenas 3% dizem confiar muito. Entre os experientes, o quadro é mais nítido: apenas 2,6% confiam muito e 20% desconfiam fortemente. E o dado que explica o resto: 66% relatam que as respostas ficam "quase certas, mas não exatamente", e 45% perdem tempo significativo depurando código gerado.

Interpretar isso como calibração de risco é generoso, e revela o problema. Calibrar pressupõe um padrão de referência. Um instrumento se afere contra algo cujo valor se conhece. Desconfiança sem conhecimento do sistema não é calibração: é ansiedade. E ansiedade não escala, não se documenta e não passa em auditoria.

O relatório DORA de 2025, com quase 5.000 profissionais, é ainda mais direto: o papel primário da IA é o de amplificador, magnificando as forças de organizações de alto desempenho e as disfunções das que já vão mal. Em times em dificuldade, a estabilidade de entrega caiu 7,2% e o throughput 1,5%, mesmo com ganhos individuais de produtividade. A IA não cria organizações excelentes; ela as revela.

E há o experimento que fecha o argumento. Em julho de 2025, o METR (Model Evaluation and Threat Research) conduziu um ensaio controlado randomizado com 16 desenvolvedores experientes em 246 tarefas reais nos próprios repositórios, com média superior a 22 mil estrelas e mais de um milhão de linhas. Eles previram uma aceleração de 24%; mesmo após vivenciarem a lentidão, ainda estimavam ter sido 20% mais rápidos. A medição mostrou que ficaram 19% mais lentos com acesso à IA. O próprio METR revisou o desenho do estudo em fevereiro de 2026, ponderando que efeitos de seleção tornaram os dados posteriores pouco confiáveis e que provavelmente há mais aceleração hoje, ressalva importante, que não desfaz o achado central.

Esse achado central não é a lentidão. É o desvio de 39 pontos entre percepção e medição, em profissionais experientes, trabalhando em código que conheciam profundamente. Se pessoas que dominam a teoria do sistema erram a própria produtividade nessa magnitude, a pergunta que se impõe é evidente: qual é o erro de percepção de um time que não domina a teoria do sistema, ao avaliar se o código gerado respeita uma arquitetura que nunca lhe foi explicada?

A instrução "observe de perto" pressupõe um observador calibrado. Os dados sugerem que o observador é o instrumento menos confiável da cadeia, e que ele não sabe disso.

O que a engenharia de software já sabia

O incômodo do gênero diagnóstico não é estar errado. É apresentar como descoberta de 2026 aquilo que o cânone resolveu operacionalmente há décadas, e parar exatamente antes da parte que dá trabalho.

Conway (1968) já observava que a estrutura do sistema espelha a estrutura de comunicação da organização que o produz. Um time sem canal de comunicação com quem detém a teoria do sistema produzirá, com ou sem IA, um sistema com essa desconexão gravada na arquitetura.

Parnas e Clements (1986) mostraram que o processo racional de design é impossível de seguir na prática, mas indispensável de simular, documentar as decisões como se tivessem sido tomadas racionalmente, porque é o registro, e não a memória, que sobrevive à rotatividade. É o antídoto direto ao problema de Naur, e a razão pela qual ADRs não são burocracia.

Feathers (2004) definiu código legado como código sem testes, e ofereceu a resposta técnica ao problema da teoria perdida: testes de caracterização, testes que não descrevem o comportamento desejado, mas capturam o comportamento atual, transformando conhecimento tácito em asserção executável. É assim que se dá a um time novo, e a uma IA, uma teoria parcial do sistema com a qual é possível trabalhar.

Evans (2003) insistiu que o modelo de domínio e a linguagem ubíqua precedem a implementação. Sem eles, não há critério para julgar se uma alteração respeita o escopo, há apenas opinião, que é o que sobra quando não há teoria.

Brooks (1995) advertiu que integridade conceitual é a consideração mais importante em design de sistemas, e que mais mãos não produzem mais velocidade. A IA é a forma mais eficiente já inventada de adicionar mãos sem adicionar entendimento.

Ford, Parsons e Kua (2017) fecham o ciclo com funções de aptidão arquitetural: transformar restrições de arquitetura em verificações automatizadas e executáveis na pipeline. Regras sobre dependências entre camadas, limites de acoplamento, contratos de API, orçamentos de latência, verificações de segurança.

Essa é a diferença entre teorizar e praticar, e ela é bem concreta. A autonomia que um código pode ter não é decidida em reunião: é decidida pelo que o sistema consegue provar sobre si mesmo automaticamente. Um sistema com testes de caracterização, contratos verificados, funções de aptidão e decisões registradas tolera alta autonomia da IA porque a violação é detectada por máquina, não por vigilância humana. Um sistema sem nada disso não tolera autonomia nenhuma, e nenhuma quantidade de "acompanhar de perto" compensa a ausência, porque estamos pedindo a um humano sobrecarregado que execute em tempo real, sem contexto e sob prazo, uma verificação que uma pipeline faria em noventa segundos.

Delegar a supervisão ao juízo humano é, portanto, a decisão arquitetural mais cara disponível. Costuma ser tomada por quem não paga a conta.

A decisão que antecede o diagnóstico

Há, porém, um capítulo que o gênero diagnóstico jamais inclui, e a omissão é elegante demais para ser acidental.

Todo texto sobre o desenvolvedor que pede demissão trata a saída como o evento inicial, o dado bruto a ser interpretado com sobriedade. Não é. É o segundo ato. O primeiro aconteceu antes, em uma planilha, e costuma ter a seguinte forma: uma equipe cara, com anos de convivência com o sistema, é substituída por uma equipe mais barata, mais nova, mais entusiasmada, e equipada com ferramentas de IA, apresentadas como o fator que torna a substituição não apenas viável, mas moderna.

O raciocínio, quando explicitado, é encantador: se a IA gera o código, o conhecimento acumulado vira commodity. Senioridade passa a ser um custo legado, como aquele servidor que ninguém desliga por medo. Contrata-se contexto por assinatura mensal.

O que se compra, na verdade, é uma equipe de altíssima capacidade de execução e nenhuma teoria do sistema. E, no vocabulário de Naur, isso tem um nome preciso: acabou-se de matar o programa e manter a fonte funcionando por inércia. O sistema continua no ar, os deploys continuam saindo, os tickets continuam fechando, e cada alteração é feita contra um modelo mental que não corresponde ao que aquele sistema é. A degradação não aparece no sprint. Aparece no trimestre seguinte, sob outro nome, geralmente "instabilidade".

Seis meses depois, o mesmo executivo que assinou a substituição publica um texto ponderado explicando que sistemas críticos exigem alguém que acompanhe de perto o que a IA gera, entenda o impacto arquitetural e valide o escopo. É um diagnóstico correto. Também é, tecnicamente falando, a descrição do profissional que ele demitiu, redigida na terceira pessoa, com dados de pesquisa e uma conclusão sobre o novo papel do engenheiro de software.

Chesterton contou a parábola da cerca no meio do campo: o reformador que quer removê-la deve primeiro descobrir por que ela foi construída. Em 2026, encontramos a variação corporativa. A cerca é removida no primeiro trimestre por eficiência de custo; no terceiro, publica-se um ensaio sensível sobre a importância das cercas em terrenos críticos; e a conclusão do ensaio é que cabe ao gado desenvolver discernimento sobre onde não pisar.

Conclusão: a assinatura

Voltemos, então, ao desenvolvedor que pede demissão.

A leitura generosa diz que ele não resiste à mudança, está calibrando risco. É melhor que a leitura preguiçosa, mas ainda erra o alvo. Calibrar risco é atividade de quem tem instrumento e padrão de referência. O que ele faz é outra coisa, e mais simples: recusa-se a assinar, em seu próprio nome, uma teoria que nunca lhe permitiram construir.

Ele sabe que, quando o pedido duplicado chegar à produção, a pergunta não será "por que a organização dissolveu o conhecimento arquitetural deste sistema?". Será "quem aprovou este pull request?". A responsabilidade foi transferida na íntegra; a capacidade de exercê-la, não. Esse arranjo tem nome fora da tecnologia, e nenhum deles é lisonjeiro.

Kant estava certo: quando uma teoria correta não funciona na prática, falta alguma coisa à teoria. O que falta ao diagnóstico impecável de 2026 não é sofisticação, é o termo intermediário. Não basta afirmar que sistemas críticos exigem supervisão próxima; é preciso construir as condições materiais da supervisão, e elas se chamam onboarding financiado, decisões documentadas, testes de caracterização, funções de aptidão, tempo de exposição ao particular e permanência de quem detém a teoria. Nada disso cabe em post. Tudo isso cabe em orçamento, e é exatamente aí que a filosofia da liderança técnica costuma encontrar seus limites epistemológicos.

Porque há uma assimetria que convém enunciar sem eufemismo. Ao desenvolvedor, pede-se prudência aristotélica, juízo kantiano, observação popperiana e responsabilidade estóica sobre um sistema cuja história lhe foi sonegada. À liderança, pede-se um post por trimestre. Os dois trabalhos são descritos com a mesma seriedade; apenas um deles é verificável em produção.

Sêneca resumiu o assunto em uma linha, na vigésima carta a Lucílio: facere docet philosophia, non dicere, a filosofia ensina a agir, não a falar. Ele acrescentou algo mais afiado ainda: que a prova de uma doutrina não está no que o homem diz, mas na distância entre o que diz e como vive, e que discursar sobre a virtude enquanto se pratica o contrário é a forma mais completa de não tê-la entendido. Sêneca, é justo lembrar, era riquíssimo, e sabia perfeitamente de quem estava falando.

Resta, portanto, uma proposta modesta. Que o próximo ensaio sobre o novo papel do Software Engineer venha acompanhado de três números: quanto foi investido em onboarding daquele sistema, quantas decisões arquiteturais estão documentadas e qual a cobertura de testes de caracterização no módulo crítico. Não é uma exigência retórica, é o único conjunto de dados capaz de distinguir um diagnóstico de um álibi.

Até lá, o diagnóstico permanece certo na teoria.

E esse é, precisamente, o problema.

Referências

• Aristóteles. Ética a Nicômaco, Livros III e VI.
• Bass, L., Clements, P., & Kazman, R. (2012). Software Architecture in Practice. Addison-Wesley.
• Brooks, F. P. (1995). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
• Chesterton, G. K. (1929). The Thing: Why I Am a Catholic, cap. IV ("The Drift from Domesticity").
• Conway, M. E. (1968). How Do Committees Invent? Datamation, 14(5), 28–31.
• Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.
• Feathers, M. (2004). Working Effectively with Legacy Code. Prentice Hall.
• Ford, N., Parsons, R., & Kua, P. (2017). Building Evolutionary Architectures: Support Constant Change. O'Reilly.
• Fowler, M. (2018). Refactoring: Improving the Design of Existing Code (2ª ed.). Addison-Wesley.
• Hanson, N. R. (1958). Patterns of Discovery. Cambridge University Press.
• Kant, I. (1793). Über den Gemeinspruch: Das mag in der Theorie richtig sein, taugt aber nicht für die Praxis.
• Naur, P. (1985). Programming as Theory Building. Microprocessing and Microprogramming, 15(5), 253–261.
• Parnas, D. L., & Clements, P. C. (1986). A Rational Design Process: How and Why to Fake It. IEEE Transactions on Software Engineering, SE-12(2).
• Popper, K. (1963). Conjectures and Refutations. Routledge.
• Ryle, G. (1949). The Concept of Mind. University of Chicago Press.
• Sêneca. Cartas a Lucílio, Carta 20.

Fontes

Kant, I. On the Common Saying: That May be Correct in Theory, but It is of No Use in Practice (1793). Cambridge Edition of the Works of Immanuel Kant.

Popper, K. Conjectures and Refutations, cap. 1, "Science: Conjectures and Refutations".

Hanson, N. R. Patterns of Discovery, cap. 1, sobre a carga teórica da observação.

Aristóteles, Ética a Nicômaco, VI, 8, 1142a.

Aristóteles, Ética a Nicômaco, III, 5, 1113b.

Naur, P. Programming as Theory Building (1985).

Ryle, G. The Concept of Mind (1949), cap. II, "Knowing How and Knowing That".

Sêneca, Epistulae Morales ad Lucilium, XX.

Stack Overflow. 2025 Developer Survey — AI (jul/2025).

Stack Overflow. 2025 Developer Survey Reveals Trust in AI at an All Time Low (jul/2025).

DORA / Google Cloud. State of AI-assisted Software Development 2025 (set/2025).

METR. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (jul/2025).

METR. We are Changing our Developer Productivity Experiment Design (fev/2026).