- Início
- The Thinking Wire
- O Gap do Pensamento É um Gap de Governança
O Gap do Pensamento É um Gap de Governança
Sophie Koonin, Engenheira Principal no Monzo Bank, publicou na semana passada um ensaio que circulou amplamente entre desenvolvedores: “Stop generating, start thinking.” A tese central é direta — geração de código por IA prejudica mais do que ajuda. Engenheiros perdem tempo com prompts, abrem mão do raciocínio crítico, e o código resultante perpetua vulnerabilidades, problemas de acessibilidade e práticas ruins.
São preocupações sérias, vindas de uma profissional séria. E merecem uma resposta séria — não uma refutação, mas um re-enquadramento.
Porque cada problema que Koonin descreve é real. O diagnóstico é preciso. Mas a prescrição — parar de usar IA — confunde o sintoma com a causa. É como observar acidentes de trânsito e concluir que o problema são os automóveis, não a ausência de semáforos.
O Que Koonin Observa (e Por Que Ela Não Está Errada)
Vale enumerar os problemas que o ensaio levanta, porque a tentação de quem trabalha com IA é descartá-los. Não deveríamos.
Engenheiros que não entendem o código que entregam. Koonin argumenta que código gerado por IA é código que o desenvolvedor não escreveu e, portanto, não compreende plenamente. Uma pesquisa da Clutch de junho de 2025 confirma: 59% dos desenvolvedores admitiram usar código gerado por IA que não entendiam completamente. Não é alarmismo. É dado.
Qualidade que piora, não melhora. Estudos do CodeRabbit, publicados no The Register em dezembro de 2025, encontraram 1,75x mais erros lógicos e 2,74x mais vulnerabilidades XSS em código gerado por IA comparado a código escrito manualmente. A IA não está apenas automatizando — está amplificando padrões ruins em escala.
Accountability que evapora. Quando um modelo gera código, quem é responsável pelo resultado? O desenvolvedor que pediu? A empresa que fornece o modelo? A organização que colocou em produção sem revisar? A pergunta não é retórica. É operacional. E a maioria das empresas não tem resposta.
Consumo de energia crescente. A IEA estima que data centers consumiram aproximadamente 415 TWh em 2024, com projeção para 945 TWh até 2030. Koonin está certa em apontar que o custo ambiental merece escrutínio.
O caso Post Office Horizon. Koonin referência o escândalo do Post Office britânico — onde um sistema de software com defeito levou à condenação injusta de centenas de funcionários — como alerta sobre confiança cega em sistemas automatizados.
Cada um desses pontos é verificável. Cada um descreve algo que acontece em empresas reais, agora.
O Erro Está na Atribuição, Não na Observação
Aqui é onde o re-enquadramento importa.
Koonin atribui esses problemas à tecnologia em si. LLMs são não-determinísticos, portanto não confiáveis. LLMs não raciocinam, portanto terceirizam o pensamento. A comparação com a Revolução Industrial é falha porque máquinas a vapor eram determinísticas e LLMs não são.
Mas considere: cada problema que ela lista existe independentemente da IA.
Desenvolvedores que não entendem o código que entregam? Isso é realidade em qualquer empresa com dependências npm que ninguém audita, com código copiado do Stack Overflow sem contexto, com bibliotecas de terceiros aceitas na fé. A IA amplificou o problema. Não o criou.
Código com vulnerabilidades de segurança e acessibilidade? Pré-IA, o OWASP Top 10 já listava as mesmas categorias de falhas há duas décadas. XSS não surgiu com ChatGPT. Surgiu com desenvolvedores que não tratam input de usuário — com ou sem IA.
Accountability difusa? Pergunte a qualquer empresa que usa software offshore ou bibliotecas open source quem é responsável quando algo falha. A cadeia de responsabilidade já era frágil. A IA a expôs.
O caso Post Office Horizon é particularmente revelador. O sistema Horizon não era IA. Era software tradicional, determinístico, escrito por humanos. E mesmo assim produziu uma das piores injustiças relacionadas a tecnologia na história britânica. O problema não foi a natureza do software. Foi a ausência de governança — de processos de auditoria, de mecanismos de contestação, de accountability quando o sistema produzia resultados questionáveis.
Se algo, Horizon argumenta a favor de governança rigorosa, não contra uma tecnologia específica.
O Mapa de Governança: De Sintoma a Estrutura
Quando você olha as preocupações de Koonin com olhos de governança, cada uma mapeia para uma lacuna estrutural específica — não para uma deficiência inerente da tecnologia.
“Engenheiros não entendem o código” → Falta política de code review adaptada para código gerado por IA. Quando uma organização trata saída de IA como contribuição de um desenvolvedor não confiável — exigindo revisão linha a linha, testes de integração obrigatórios, e documentação de decisões de design — o problema de compreensão se endereça sistematicamente. Não porque os engenheiros passam a entender cada linha, mas porque o processo exige que entendam antes de aprovar.
“LLMs perpetuam más práticas” → Faltam restrições arquiteturais embutidas nos prompts de sistema. Quando você define em um arquivo CLAUDE.md ou equivalente que o agente deve seguir padrões específicos de acessibilidade (WCAG 2.2), que SQL deve usar queries parametrizadas, que input de usuário deve ser sanitizado — o modelo opera dentro de guardrails. Não porque raciocina sobre segurança, mas porque as restrições são parte do contexto. A qualidade do output é função da qualidade da governança do input.
“Accountability colapsa” → Falta cadeia de responsabilidade definida. Organizações maduras em governança de IA tratam o modelo como ferramenta, não como autor. O desenvolvedor que aceita a sugestão é responsável. O tech lead que aprova o PR é responsável. A organização que define (ou não define) os critérios de aceitação é responsável. Accountability não evapora quando existe estrutura para capturá-la.
“LLMs são não-determinísticos” → Faltam frameworks de validação e teste. Não-determinismo não é exclusivo de IA. Sistemas distribuídos, APIs externas, race conditions — engenharia de software lida com não-determinismo há décadas. A resposta nunca foi “não use sistemas não-determinísticos.” Foi: crie testes, valide resultados, monitore em produção. As mesmas disciplinas se aplicam.
A Evidência de Que Governança Funciona
Se a tese fosse apenas conceitual, seria apenas mais uma opinião. Mas os dados sustentam uma conclusão específica.
A Veracode, em seu relatório de 2026, encontrou que 97% das organizações já têm código gerado por IA em produção. Mas apenas 19% têm visibilidade sobre onde esse código está e como foi validado. E 80% das organizações reportam comportamentos arriscados de agentes de IA em seus ambientes.
Leia esses números juntos: quase toda empresa já usa IA para gerar código. Quase nenhuma sabe o que acontece com esse código depois. E a maioria já encontrou problemas.
Essa é a lacuna que Koonin observa. Mas a resposta não é parar de usar — é governar o uso.
Organizações que implementaram frameworks de governança para IA reportam 81% de melhoria na qualidade do código produzido. Não porque a tecnologia mudou. Porque o processo ao redor da tecnologia mudou.
A diferença entre uso governado e não governado não é marginal. É categórica.
O Centauro Invertido e a Epistemologia Centopeia
Koonin referência dois conceitos que merecem atenção.
O primeiro é o “centauro reverso” — termo do Guardian para descrever a situação onde, em vez de um humano amplificado por IA, temos uma IA servida por um humano que apenas valida outputs sem pensar. Maggie Appleton expandiu a ideia com sua “epistemologia centopeia humana”: uma cadeia onde humanos passam informação gerada por IA adiante sem verificação, cada elo assumindo que o anterior validou.
São metáforas úteis. Mas descrevem o que acontece na ausência de governança, não na presença de IA.
Um centauro reverso é um engenheiro sem processo de revisão. Uma epistemologia centopeia é uma organização sem cadeia de validação. Adicione revisão obrigatória, adicione verificação em cada elo, e as metáforas perdem aplicabilidade — não porque o risco desaparece, mas porque a estrutura o endereça.
Mikayla Maki, no blog do editor Zed, ofereceu a formulação mais precisa: LLMs automatizam a digitação, não o pensamento. É uma distinção que Koonin deveria abraçar, não combater — porque ela implica que o pensamento contínua sendo responsabilidade humana. E governança é o mecanismo que garante que essa responsabilidade se cumpra.
O Que Organizações Precisam Fazer (Não Escolher)
A estrutura que Koonin propõe — “pare de gerar, comece a pensar” — é uma falsa dicotomia. Pensar e gerar não são mutuamente exclusivos. São complementares, quando existe governança.
Três movimentos concretos separam uso governado de uso negligente:
Primeiro: trate código de IA como código de contribuidor não confiável. Todo output passa por code review com critérios explícitos. Testes automatizados cobrem não apenas funcionalidade, mas padrões de segurança e acessibilidade. Nenhuma sugestão de IA vai direto para produção. Isso não é burocracia — é engenharia.
Segundo: embuta restrições no contexto, não na esperança. Defina padrões arquiteturais em arquivos de configuração de agentes (system prompts, CLAUDE.md, regras de projeto). Quando o modelo opera dentro de guardrails documentados, a saída reflete os guardrails. Quando opera sem restrições, reflete o treinamento médio — que inclui todo código ruim da internet.
Terceiro: mantenha o humano como autor, não como aprovador. A distinção é sutil mas fundamental. O engenheiro dirige o raciocínio. Define a arquitetura. Toma as decisões de design. A IA executa a digitação. Quando o fluxo se inverte — a IA decide e o humano apenas aceita — é sinal de governança ausente, não de tecnologia defeituosa.
Post Office Horizon: O Argumento Que Koonin Não Percebeu
O caso Horizon merece uma análise separada porque Koonin o usa como argumento contra IA — mas ele argumenta precisamente a favor da nossa posição.
Horizon era software determinístico. Escrito por humanos. Sem IA, sem LLMs, sem não-determinismo. E ainda assim produziu uma catástrofe. Por quê?
Porque os processos ao redor do software falharam. Auditorias inexistentes. Mecanismos de contestação suprimidos. Accountability concentrada em quem não tinha incentivo para questionar. Os correios e a Fujitsu trataram o software como fonte de verdade infalível — e quando ele falhou, não havia estrutura para detectar ou corrigir o erro.
Se Horizon tivesse sido construído com IA, o problema seria exatamente o mesmo. E se tivesse sido construído com governança — auditorias regulares, canais de contestação, revisão independente — o desastre teria sido prevenido ou mitigado cedo.
O caso Horizon não é um argumento sobre tecnologia. É um argumento sobre governança. E é o argumento mais forte que existe para nunca, em nenhuma circunstância, operar software sem os controles adequados — seja esse software escrito por humanos, gerado por IA, ou qualquer combinação dos dois.
A Pergunta Certa
Koonin pergunta: devemos gerar código com IA?
A pergunta certa é outra: como governamos o que geramos?
59% dos desenvolvedores não entendem o código que usam. 97% das organizações têm código de IA em produção. 81% das organizações que governam esse código reportam melhoria de qualidade. 80% das que não governam encontram comportamentos arriscados.
Os números não dizem “pare de usar IA.” Dizem “governe o que você usa.”
As preocupações de Koonin são válidas como diagnóstico. Mas parar de usar IA em 2026 não é uma opção realista para a maioria das organizações — e os dados sugerem que não é necessário, se a governança for tratada como arquitetura e não como burocracia.
O gap não é de pensamento. É de governança. E esse gap tem solução.
Fontes
- Sophie Koonin. “Stop generating, start thinking.” localghost.dev, fevereiro 2026.
- Clutch. “Developer adoption and comprehension of AI-generated code.” Junho 2025.
- CodeRabbit / The Register. “Logical errors and XSS vulnerabilities in AI-generated code.” Dezembro 2025.
- Veracode. “State of Software Security 2026: AI-Generated Code in Production.”
- IEA (International Energy Agency). Data centre energy consumption projections, 2024-2030.
- Maggie Appleton. “The Human Centipede Epistemology.”
- Mikayla Maki. “LLMs automate typing, not thinking.” Zed Blog.
- The Guardian. “The reverse centaur: when humans serve AI.”
- Post Office Horizon IT inquiry. Ongoing public record.
Se isso faz sentido, vamos conversar
Ajudamos empresas a implementar IA sem perder o controle.
Agendar uma Conversa