IA na programação: o problema é a falta de pensamento crítico

A IA na programação já escreve funções, cria testes e sugere arquiteturas em poucos segundos. Só que produzir código ficou mais fácil do que decidir qual problema merece ser resolvido. Como mostra este guia sobre programação com Claude Code, velocidade ajuda, mas não substitui contexto, critérios e responsabilidade técnica.

Um código que compila, afinal, ainda pode partir de requisitos errados, ignorar dados sensíveis ou criar uma dívida difícil de pagar. O risco maior aparece quando alguém aceita uma solução plausível sem entender suas premissas, seus limites e seus efeitos no produto.

Este artigo defende uma posição simples: use IA para ampliar seu raciocínio, não para aposentá-lo. A ferramenta pode explorar alternativas, automatizar tarefas repetitivas e encontrar casos-limite. A decisão, contudo, continua sendo sua.

Gerar código responde à pergunta “como implementar?”, mas resolver um problema também exige definir “o quê”, “para quem” e “com quais limites”. Uma solução pode funcionar no exemplo enviado e falhar no sistema real. Ela pode ignorar regras de negócio, custos operacionais, privacidade ou a arquitetura já existente.

A diferença parece óbvia até a tela mostrar uma implementação elegante. O código tem nomes bons, testes verdes e uma explicação convincente. Ainda assim, quem definiu o objetivo? Quem confirmou os dados de entrada? Quem avaliou o que acontece quando o usuário faz algo inesperado?

Segundo a Anthropic, usuários experientes tomam cerca de 70% das decisões de planejamento em sessões típicas com Claude Code, enquanto o modelo assume aproximadamente 80% das decisões de execução. A divisão mostra onde a supervisão humana gera mais valor: decidir o caminho, não apenas acompanhar a digitação.

O texto “You Don’t Have an AI Problem, You Have a Thinking Problem” coloca a questão de forma direta. Muitas frustrações atribuídas à IA nascem de problemas mal definidos. Quando o pedido não explicita objetivo, contexto e critérios de sucesso, o modelo preenche as lacunas com suposições.

Essas suposições podem parecer razoáveis porque foram escritas em linguagem segura. O modelo não sabe, por conta própria, que uma tabela tem milhões de linhas, que determinada coluna contém dados pessoais ou que uma operação precisa ser idempotente. Se você não informa essas condições, a resposta pode seguir um caminho tecnicamente possível e operacionalmente inadequado.

Uma função de busca pode retornar resultados corretos em um banco pequeno. Em produção, porém, talvez provoque consultas repetidas, consuma memória demais ou permita uma injeção. Uma API pode responder com o status esperado e, ao mesmo tempo, vazar informações no log.

O problema não está na existência de erros. Humanos também erram. A diferença é que a automação aumenta a quantidade de mudanças que chegam até a revisão. Se o desenvolvedor só verifica se o código executa, deixa de avaliar se ele deveria existir daquela forma.

A pesquisa da Anthropic também associa experiência específica na tarefa a melhores resultados. Em sessões classificadas como iniciantes, cerca de 19% terminam abandonadas quando surgem problemas, contra algo entre 5% e 7% nos demais níveis. A análise da Anthropic sugere que experiência ajuda a redirecionar o agente quando a primeira tentativa falha.

Essa é a diferença entre pedir uma resposta e conduzir uma investigação. O desenvolvedor que entende o domínio reconhece uma premissa estranha, formula uma pergunta melhor e interrompe uma implementação antes que ela se espalhe. A IA acelera o trabalho, mas não escolhe sozinha o que merece confiança.

Terceirizar o pensamento para a IA costuma reduzir a autonomia antes de aumentar a produtividade. A pessoa passa a aceitar soluções que não consegue explicar, encontra mais dificuldade para depurar e aprende apenas a repetir padrões. O problema cresce quando velocidade vira critério único de sucesso.

A dependência raramente começa com um grande projeto. Ela aparece em pequenas decisões: pedir a função inteira, aceitar a primeira arquitetura, copiar uma correção de erro e seguir adiante. Depois de algumas semanas, o código funciona como uma colcha de retalhos que ninguém domina completamente.

A Anthropic observou que uma sessão típica de usuário iniciante dispara cerca de cinco ações do agente e produz aproximadamente 600 palavras de saída. Em sessões de usuários experientes, são cerca de 12 ações e 3.200 palavras. O dado não prova causalidade, mas indica uma interação mais longa, específica e orientada por contexto.

A diferença entre acelerar e abandonar responsabilidade é prática. Acelerar significa deixar a ferramenta cuidar de tarefas mecânicas enquanto você mantém a intenção, os critérios e a revisão. Abandonar significa transformar a saída do modelo em decisão final, mesmo sem compreender as consequências.

O termo vibe coding descreve um modo de desenvolvimento em que a pessoa fornece instruções de alto nível e deixa a IA produzir grande parte da implementação. Porém, ele não representa um único comportamento. Há uma escala entre aceitar sugestões de autocomplete e delegar arquitetura, módulos, testes e correções a um agente.

O NCSC recomenda calibrar a supervisão conforme o risco. Protótipos, demonstrações e ferramentas internas podem tolerar mais automação. Autenticação, autorização, credenciais, dados pessoais e sistemas críticos exigem uma posição mais próxima da programação manual e da revisão cuidadosa.

Essa gradação é útil porque evita dois exageros. Um deles trata toda assistência como ameaça. O outro trata toda automação como segura. Você não precisa revisar cada caractere de um script descartável com a mesma intensidade dedicada a um fluxo de pagamento. Mas precisa saber em qual categoria está trabalhando.

O aprendizado também sofre quando a IA remove todo o esforço produtivo. Resolver um bug exige formar hipóteses, observar evidências e testar explicações. Se a ferramenta entrega a resposta antes que você formule uma hipótese, você perde justamente a prática que constrói autonomia. Que tipo de programador se forma sem enfrentar problemas suficientes para reconhecer padrões?

Use IA na programação como parceira de investigação: defina o problema, registre uma abordagem inicial, explicite restrições, peça alternativas e valide o resultado. A OpenAI recomenda usar o Codex para decompor tarefas, criar testes, analisar falhas e acelerar partes específicas do ciclo, em vez de substituir todo o processo.

Um método simples ajuda a preservar autonomia. Antes de abrir o chat ou o agente, escreva em poucas linhas o objetivo, as entradas, as saídas esperadas e o que não pode acontecer. Depois, formule uma hipótese. Mesmo que ela esteja incompleta, você terá uma referência para comparar a resposta recebida.

Segundo a OpenAI, o Codex pode gerar testes para casos-limite como entradas vazias, tamanho máximo e estados válidos pouco comuns. Esse uso desloca a ferramenta da função de “autor automático” para a de examinadora, capaz de ampliar a cobertura do raciocínio humano.

1. Defina o problema antes do prompt. Escreva qual comportamento precisa mudar e qual resultado será considerado correto. Evite começar por “crie uma função”. Comece por “preciso impedir que pedidos duplicados gerem duas cobranças”.

2. Explicite requisitos e restrições. Informe linguagem, versões, dependências permitidas, volume de dados, limites de latência, regras de privacidade e convenções do projeto. A IA não adivinha o ambiente. Quanto mais crítica a decisão, menos espaço deve existir para suposições ocultas.

3. Peça uma proposta antes da implementação. Solicite que a ferramenta liste hipóteses, riscos e alternativas. Em seguida, escolha uma abordagem ou corrija o entendimento. Esse pequeno intervalo impede que uma implementação prematura pareça inevitável.

4. Divida o trabalho. Separe investigação, desenho, implementação, testes e revisão. A OpenAI relata que equipes que trabalham com agentes precisaram quebrar objetivos grandes em blocos menores de design, código, revisão e teste.

5. Teste o comportamento, não apenas a compilação. Inclua casos normais, entradas inválidas, limites, concorrência, falhas externas e permissões. Um teste verde prova que aquele cenário passou. Não prova que os cenários relevantes foram escolhidos.

6. Explique o resultado sem consultar a ferramenta. Tente descrever o fluxo, as decisões e os riscos. Se você não consegue explicar por que uma dependência foi usada ou por que um timeout tem aquele valor, a revisão ainda não terminou.

Peça contraexemplos. Pergunte quais premissas podem estar erradas, que situação quebraria a solução e quais custos apareceriam em escala. Também vale pedir uma comparação entre duas abordagens, com impacto em manutenção, performance, segurança e observabilidade.

A boa interação não é uma competição para conseguir o prompt perfeito. É uma conversa que torna o raciocínio visível. Quando a ferramenta critica uma hipótese concreta, você tem algo para avaliar. Quando apenas entrega uma função pronta, o trabalho intelectual continua escondido.

Bons prompts nascem de decisões já parcialmente pensadas. “Escreva uma função em Python” deixa quase tudo em aberto. “Implemente uma função que remova duplicatas preservando a ordem, aceite até um milhão de itens, mantenha compatibilidade com Python 3.11 e inclua testes para entradas vazias” oferece um problema verificável.

A forma do pedido importa, mas o conteúdo importa mais. Fórmulas prontas podem organizar a mensagem, porém não substituem conhecimento sobre o produto, os dados e os limites técnicos. Um prompt longo, cheio de adjetivos, continua fraco se não define o que deve ser medido.

A OpenAI apresenta exemplos de uso do Codex para localizar chamadas repetidas de banco, sugerir otimizações e ampliar testes. Em todos esses casos, a tarefa fica melhor quando o pedido aponta o contexto, a suspeita e o tipo de evidência esperado.

Um pedido genérico seria: “Crie uma API para cadastrar usuários”. A ferramenta terá de inventar autenticação, formato de erro, validação, persistência e permissões. O resultado pode até rodar, mas cada decisão escondida vira uma hipótese não revisada.

Um pedido mais útil seria: “Analise este endpoint existente. Usuários autenticados podem atualizar apenas o próprio nome. Preserve o contrato de resposta, rejeite campos desconhecidos, não registre o e-mail no log e proponha testes para autorização, payload vazio e tentativa de alterar outro usuário”.

O segundo pedido não garante código correto. Ele melhora a superfície de avaliação. Você consegue comparar o resultado com regras observáveis. Também consegue identificar o que ainda falta decidir. Esse é o ganho real de especificar bem.

A IA pode responder essas perguntas, mas não deve respondê-las sozinha. Use a ferramenta para descobrir lacunas e depois confirme cada decisão com documentação, testes, métricas ou conhecimento do domínio. Perguntar melhor é consequência de pensar melhor.

Sim, principalmente quando o código afeta segurança, dados, custos, performance ou regras de negócio. A revisão não exige memorizar cada detalhe, mas exige compreender o fluxo, as dependências e os modos de falha. Em tarefas de baixo risco, a automação pode ser maior. Em tarefas sensíveis, a responsabilidade não pode ser delegada.

O IBM Think cita uma análise segundo a qual equipes assistidas por IA entregaram código quatro vezes mais rápido, mas também enviaram dez vezes mais falhas de segurança. A proporção não deve ser lida como uma regra universal, mas reforça uma conclusão: velocidade sem controle amplia problemas junto com entregas.

A revisão precisa acompanhar o impacto da mudança. Um script temporário para renomear arquivos pode ser validado com uma cópia dos dados e alguns exemplos. Já um módulo que trata tokens, pagamentos ou informações pessoais demanda revisão de ameaça, análise estática, testes de autorização e observação após a publicação.

Contexto e dependências. Confira se bibliotecas, versões e APIs existem. Modelos podem sugerir pacotes inexistentes ou desatualizados. O risco de instalar um pacote falso, conhecido como slopsquatting, aparece quando alguém aceita o nome sem consultar o repositório oficial.

Regras de negócio. Leia o caminho feliz e os caminhos de exceção. A implementação respeita limites, permissões, cancelamentos e reprocessamentos? Uma função correta em termos sintáticos pode violar uma regra comercial importante.

Segurança. Procure segredos expostos, validação insuficiente, controle de acesso ausente, consultas vulneráveis e logs com dados sensíveis. O IBM Think recomenda tratar código derivado de IA como entrada não confiável e submetê-lo a controles específicos, incluindo análise estática.

Performance e custo. Estime complexidade, número de chamadas externas, uso de memória e comportamento com volume real. Peça à IA uma análise, mas confirme com benchmark ou métricas. Uma explicação convincente não substitui medição.

Manutenção. Verifique nomes, coesão, duplicação, acoplamento e documentação. Código difícil de ler custa mais na próxima alteração, independentemente de ter sido escrito por uma pessoa ou por um modelo.

A experiência da OpenAI com um repositório construído por agentes oferece uma pista relevante. A equipe relata cerca de um milhão de linhas, aproximadamente 1.500 pull requests e uma evolução de três para sete engenheiros. O sistema usou linters, testes estruturais e regras arquiteturais para manter dependências previsíveis, segundo o relato da OpenAI.

A lição não é deixar um agente escrever tudo. É criar condições para que mudanças automáticas possam ser avaliadas. Limites de arquitetura, verificações no CI, pull requests menores, logs e critérios de aceite tornam o trabalho legível para humanos e máquinas.

Quanto maior a autonomia da ferramenta, mais explícitos precisam ser os guardrails. Sem eles, cada prompt vira uma exceção. Com eles, a equipe consegue delegar execução sem perder a capacidade de interromper, comparar e corrigir.

A IA tende a substituir partes do trabalho, sobretudo tarefas repetitivas de implementação, documentação e testes iniciais. Ela não elimina a necessidade de definir problemas, negociar requisitos e assumir decisões. Na pesquisa da Anthropic, usuários ainda tomam cerca de 70% das decisões de planejamento em sessões típicas com agentes.

Defina o objetivo antes da ferramenta, escreva uma hipótese, informe restrições e peça alternativas. Depois, teste e explique a solução com suas próprias palavras. Um fluxo baseado em decomposição, revisão e validação mantém você responsável pela decisão. O guia do Codex da OpenAI reúne exemplos de testes, análise de performance e correção de bugs.

Vibe coding é um estilo de desenvolvimento em que a pessoa descreve uma intenção ampla e deixa a IA produzir grande parte do código. O NCSC explica que existe um espectro entre autocomplete supervisionado e autonomia ampla sobre arquitetura e testes. O nível adequado depende do risco, dos dados e do impacto da falha.

Comece pelo comportamento esperado e pelos casos de falha. Depois confira dependências, permissões, validações, segredos, performance, observabilidade e manutenção. Rode testes automatizados, análise estática e revisão humana. O IBM Think relata que pull requests maiores e mudanças espalhadas dificultam encontrar falhas, então prefira alterações pequenas e focadas.

Ela atrapalha quando remove a tentativa, a depuração e a explicação. Pode ajudar quando funciona como tutora: pede uma hipótese antes da resposta, oferece pistas, cria contraexemplos e compara abordagens. A Anthropic encontrou abandono em cerca de 19% das sessões de usuários aparentemente iniciantes quando surgem problemas, contra 5% a 7% nos demais grupos.

Quando escrever código fica mais barato, compreender problemas, fazer boas perguntas e avaliar trade-offs ganha valor. A IA pode ampliar a capacidade de um desenvolvedor, mas não remove a necessidade de julgamento. O diferencial não será produzir mais linhas, e sim saber qual solução merece ser construída e por quê.

A programação sempre envolveu mais do que sintaxe. Envolve modelar processos, entender usuários, proteger dados, prever falhas e escolher compromissos aceitáveis. A IA acelera a expressão dessas decisões, mas não torna as decisões menos necessárias.

O próximo passo lógico é transformar essa postura em prática diária. Se você quer explorar ferramentas e fluxos de desenvolvimento assistidos por IA, veja também o guia para começar com o Cursor. Compare abordagens, crie pequenos experimentos e registre o que a ferramenta acerta ou inventa.

A pergunta útil não é se você usa IA. É se consegue continuar pensando quando ela oferece uma resposta pronta. Se a resposta for sim, a ferramenta trabalha a seu favor. Para receber discussões como esta sobre dados, engenharia e inteligência artificial, inscreva-se na newsletter do Data Hackers.