Claude Code demonstra que os agentes de IA são mais engenharia do que magia

O que são as ferramentas de codificação agêntica

Os primeiros assistentes de codificação potencializados por IA ajudavam sobretudo no momento de escrever código. As ferramentas de autocompletar sugeriam linhas ou funções, e as ferramentas baseadas em chat respondiam a perguntas e geravam fragmentos de código. As ferramentas de codificação agêntica vão além. Não se limitam a sugerir; elas agem. Podem inspecionar um repositório, procurar arquivos relevantes, executar uma suíte de testes, editar múltiplos arquivos, ler os resultados, ajustar o plano e continuar avançando até chegar a um ponto de parada plausível.

A documentação do Claude Code descreve isto como um ciclo agentivo com três fases sobrepostas: recolher contexto, agir e verificar os resultados. Uma correção de erro pode passar repetidamente pelas três. O modelo decide o que fazer com base no que aprendeu no passo anterior, enquanto o usuário permanece livre para interromper e orientar. De forma geral, podemos falar numa arquitetura em duas camadas: modelos que raciocinam e ferramentas que agem, com o Claude Code como a armação agêntica que fornece essas ferramentas, gerencia o contexto e executa o ambiente.

Essa divisão é fundamental para entender o artigo de Liu et al. O Claude Code não é um modelo flutuando livremente pela sua máquina. O modelo não acessa diretamente o sistema de arquivos, não executa comandos de shell nem realiza solicitações de rede. Em vez disso, emite solicitações estruturadas de uso de ferramentas. A armação as analisa, verifica as permissões, despacha as ações aprovadas para as ferramentas e devolve os resultados à próxima chamada do modelo. O artigo destaca essa separação como um limite de segurança: o raciocínio e a aplicação de controles vivem em rotas de código distintas, de modo que aquilo que o modelo "quer" fazer não é o mesmo que aquilo para o qual ele tem permissão.

Uma analogia útil não é a de um robô com mãos, mas a de um especialista sentado em uma sala de controle. O especialista propõe ações. A sala de controle contém telas, ferramentas, listas de verificação, travas, registros e operadores. O especialista importa, mas é a sala de controlo que determina o que pode acontecer.

Um agente de codificação não é apenas um modelo. O modelo é um ponto de decisão dentro de uma estrutura de engenharia mais ampla que controla contexto, permissões, execução, recuperação e auditabilidade.

A afirmação viral: em grande parte verdadeira, mas fácil de interpretar mal

O vídeo que, em parte, me motivou a escrever este post fazia várias afirmações: que a "parte de IA" do Claude Code é pequena; que o núcleo é essencialmente um ciclo que chama um modelo; que o restante consiste em permissões, ferramentas, compressão de contexto e sistemas de recuperação; e que os vencedores na IA agêntica serão diferenciados pela infraestrutura, e não apenas pela escolha do modelo.

O artigo de Liu et al. respalda em grande medida essa interpretação. Ele diz que a análise em nível de código-fonte identificou um ciclo central simples rodeado por subsistemas de segurança, extensibilidade, gestão de contexto, delegação e persistência. Também relata um sistema de permissões com sete modos e um classificador de machine learning, um pipeline de compactação de contexto de cinco camadas, quatro mecanismos de extensibilidade e um armazenamento de sessões orientado à adição.

Ainda assim, "98% não é IA" pode induzir à confusão se for tomado de forma literal demais. O modelo continua sendo o lugar onde ocorrem a interpretação da tarefa, a compreensão do código, o planejamento e a seleção de ferramentas. Se o modelo for removido, a armação se torna uma carcaça sofisticada de regras, esquemas e registros. Se a armação for removida, o modelo é um consultor conversador sem uma forma confiável de agir. A lição que o Claude Code ensina não é que o modelo seja trivial; é que a utilidade do modelo depende da arquitetura não-modelo que o envolve.

Além disso, os pesquisadores citam uma pesquisa interna da Anthropic, realizada com 132 engenheiros e pesquisadores, segundo a qual aproximadamente 27% das tarefas em que o Claude Code foi utilizado não teriam sido tentadas sem a ferramenta. Esse é, talvez, o argumento mais sólido contra interpretar "98% não é IA" como "o modelo não importa": a arquitetura permite fluxos de trabalho qualitativamente novos, não apenas versões mais rápidas dos já existentes.

Isso não surpreenderia alguém que tenha construído sistemas de produção. Um banco de dados não é valioso porque seu otimizador de consultas é brilhante; ele é valioso porque armazenamento, indexação, transações, permissões, backups e observabilidade funcionam em conjunto. Uma aplicação segura não é segura porque uma função de autenticação faz seu trabalho; ela é segura porque identidade, autorização, validação, logging, monitoramento e recuperação operam de forma coordenada. A IA agêntica segue o mesmo padrão.

A armação é onde a confiança é negociada

Para as equipes de segurança, a parte mais interessante do Claude Code pode muito bem ser seu sistema de permissões. Segundo Liu e seus colegas, as solicitações de ferramentas passam por um modelo deny-first: as regras de negação prevalecem sobre as regras de pergunta, as regras de pergunta prevalecem sobre as regras de autorização, e as ações desconhecidas são escaladas em vez de serem permitidas silenciosamente. O artigo identifica até sete modos de permissão: plan, default, accept edits, auto, don't ask, bypass permissions e um modo bubble interno para a escalação de subagentes.

A documentação voltada ao usuário apresenta uma versão mais simples da mesma ideia. O Claude Code permite que os usuários alternem entre modos de permissão como Default, Auto-accept edits, Plan mode e Auto mode. Também permite autorizar comandos específicos na configuração, como comandos de teste confiáveis.

Isso importa porque, na prática, humanos não são máquinas confiáveis para verificar permissões. Os pesquisadores citam um achado da própria Anthropic segundo o qual os usuários aprovaram aproximadamente 93% das solicitações de permissão, o que sugere que essas solicitações muitas vezes se tornam rituais e não revisões significativas. Um controle ao qual os usuários quase sempre dizem sim não é realmente um controle; parece mais um quebra-mola. A equipe de engenharia da Anthropic calcula que o uso de ambientes isolados (sandboxing) reduziu a frequência das solicitações de permissão em aproximadamente 84%, o que recoloca o problema em termos de fatores humanos: a resposta arquitetônica diante de uma aprovação pouco confiável consiste, antes de tudo, em reduzir o número de decisões que as pessoas precisam tomar. Por isso, sistemas de agentes úteis precisam de defesas em camadas: ferramentas pré-filtradas, avaliação de regras, modos de permissão, classificadores, hooks, sandboxing, não restauração de permissões obsoletas e registros de sessão.

Para os analistas de segurança, isso amplia o objetivo de revisão muito além de "o modelo rejeita prompts ruins?" Ele também precisa cobrir onde a confiança começa, quais ferramentas o modelo pode ver, se as regras de negação se comportam de maneira determinística, se as permissões sobrevivem aos limites de sessão, se os comandos de shell são executados em um sandbox, se os hooks podem modificar as entradas das ferramentas e se os conectores externos ampliam silenciosamente a superfície de ataque.

O contexto é um recurso escasso

Uma segunda grande lição é a gestão do contexto. O Claude Code pode parecer que "entende toda a base de código", e a documentação diz que ele pode trabalhar entre arquivos porque vê o projeto do usuário, o terminal, o estado do Git, as instruções de CLAUDE.md, a memória automática e as extensões configuradas. Mas nenhum modelo leva literalmente uma organização de engenharia inteira na cabeça. Cada chamada ao modelo tem uma janela de contexto, e essa janela se preenche com instruções, conteúdo de arquivos, saídas de comandos, mensagens anteriores, esquemas de ferramentas, memória e resumos.

O artigo explica que o maior desafio do Claude Code é gerenciar seu "espaço de memória" — ou contexto —, que é limitado. Para evitar o desperdício desse recurso, o sistema utiliza vários truques: carrega as instruções do projeto apenas quando é absolutamente necessário, oculta os detalhes técnicos sobre as ferramentas até que elas sejam realmente utilizadas, solicita aos subagentes resumos breves em vez de relatórios extensos e estabelece "orçamentos de dados" para os resultados das ferramentas. Também aplica cinco estratégias de redução de contexto antes das chamadas ao modelo, partindo da premissa de que nenhum método de compactação por si só consegue lidar com todo tipo de pressão de contexto. Além disso, cada camada funciona com uma relação custo-benefício diferente, e as camadas iniciais, que são mais econômicas, são executadas antes das mais custosas.

Enquanto isso, a Anthropic diz de forma mais direta: à medida que o contexto se enche, o Claude Code apaga primeiro saídas antigas de ferramentas e resume a conversa, se necessário; as regras persistentes deveriam ficar em CLAUDE.md em vez de serem deixadas nos primeiros turnos da conversa, porque instruções detalhadas de momentos anteriores de uma sessão podem se perder. As definições de ferramenta MCP são adiadas por padrão, e os subagentes têm seus próprios contextos novos, de modo que seu trabalho não sobrecarrega a conversa principal.

Nada disto é propriamente uma novidade do Claude Code; é mais uma confirmação. Como referimos no nosso texto anterior sobre desenvolvimento de software na era agentiva, os agentes CLI já "tratam o contexto como um recurso escasso", usando buscas direcionadas para encontrar os arquivos de que precisam, lendo apenas o que é relevante e gerenciando a janela de contexto com precisão. O que o artigo acrescenta é uma visão detalhada de como essa disciplina acaba se materializando quando está conectada a um agente de produção real.

Para os desenvolvedores, a conclusão prática é deixar de tratar um agente de codificação como um colega que tudo vê. Trate-o, em vez disso, como um colega com uma memória de trabalho muito grande, mas ainda assim limitada. Coloque as regras duradouras do projeto em arquivos versionados. Dê a ele testes, exemplos e restrições. Peça que ele explore antes de implementar quando a tarefa for complexa. Faça com que a verificação faça parte do prompt. A resposta do modelo só poderá ser tão boa quanto o contexto operacional que a armação conseguir montar no momento em que for solicitada.

Para os executivos, a gestão do contexto também é uma preocupação de custos e de governança. O trabalho de IA de longa duração consome tokens, chamadas a ferramentas e atenção humana. Se se espera que os agentes operem sobre grandes bases de código, as equipes precisam de convenções sobre o que deveria entrar na memória persistente, o que deveria pertencer às instruções do projeto, o que deveria ser recuperado sob demanda e o que nunca deveria ser exposto ao agente.

As ferramentas fazem o trabalho; o modelo escolhe entre elas

O modelo do Claude Code não edita arquivos com mãos invisíveis. Ele usa ferramentas. O artigo relata até 54 ferramentas integradas, com 19 sempre incluídas e 35 incluídas condicionalmente, de acordo com feature flags, variáveis de ambiente e tipo de usuário. Em seguida, essas ferramentas integradas são combinadas com ferramentas fornecidas pelo MCP, e a superfície de ação resultante é filtrada, deduplicada e moldada antes que o modelo a veja.

Esse detalhe ajuda a explicar comentários como os que afirmam que os agentes não passam de mais uma ferramenta a adicionar a um projeto e que toda solução real para problemas continua sendo uma solução de engenharia integral. Há algo de verdadeiro nisso, embora isso subestime o modelo. Os agentes de IA não são apenas uma ferramenta no mesmo sentido em que grep o é; são motores de raciocínio flexíveis que podem decidir quais ferramentas usar, em que ordem e com base em que feedback. Mas ainda assim precisam da maquinaria de software tradicional por trás deles para fazer qualquer coisa de maneira confiável.

As extensões do Claude Code ilustram o mesmo ponto. Os usuários podem conectar serviços externos por meio do MCP, guardar instruções de projeto em CLAUDE.md, criar skills para fluxos de trabalho repetíveis e usar hooks para executar comandos antes ou depois de ações do Claude Code. O produto também suporta subagentes e agentes personalizados para trabalho delegado. Os pesquisadores mapeiam esses mecanismos em uma visão mais arquitetônica: os servidores MCP adicionam ferramentas externas, os plugins empacotam componentes, as skills injetam instruções específicas de domínio e os hooks interceptam eventos do ciclo de vida.

Em outras palavras, o "agente" não é uma única coisa. É uma composição de chamadas ao modelo, esquemas de ferramentas, verificações de permissões, arquivos, saídas de comandos, prompts, hooks, memórias, resumos e registros. A inteligência do modelo é real, mas a confiabilidade do produto vem de como essas peças são compostas.

Porque isto importa para a AppSec

Para a segurança de aplicações (AppSec), a mudança mais importante é passar da detecção à ação. Uma ferramenta que só consegue identificar uma vulnerabilidade ainda deixa a remediação, a validação e a implantação nas mãos de humanos. Um agente de codificação poderia fazer mais: inspecionar o caminho de código vulnerável, escrever um patch, executar testes, atualizar dependências, produzir um pull request e documentar o raciocínio. Isso o torna poderoso, mas também arriscado.

Antes havíamos levantado um ponto relacionado. Na nossa discussão sobre o Claude Mythos, argumentámos que a descoberta de vulnerabilidades orientada por IA não termina com a cibersegurança; acelera tendências já em curso, deixando a correção como um desafio complexo e dependente do contexto. O Claude Code se encaixa nesse panorama mais amplo. Ele pode acelerar fluxos de trabalho de remediação, mas apenas quando suas ações estão restritas, revisadas e verificadas.

Portanto, as equipes de segurança deveriam avaliar as ferramentas de codificação agêntica por meio de várias perguntas: a ferramenta consegue prestar contas de quais arquivos leu, quais comandos executou e por quê? Ela pode ser restringida a um planejamento somente leitura antes de fazer qualquer mudança? Os comandos perigosos são negados por padrão? Os serviços externos conectados por meio do MCP são revisados como parte do modelo de ameaças? Há registros de sessão disponíveis para auditoria? As mudanças podem ser revertidas? As correções geradas são testadas contra casos relevantes para exploração e não apenas contra testes unitários happy-path? A organização consegue definir políticas centralmente, em vez de deixar que o julgamento local de cada desenvolvedor carregue todo o peso?

Essas perguntas não são anti-IA. São as condições sob as quais a assistência de IA se torna útil no trabalho de segurança. Em programas maduros de AppSec, o objetivo não é deixar que agentes "façam segurança" por conta própria; é colocá-los dentro de processos que já sabem lidar com evidência, risco, reprodutibilidade e responsabilidade.

O que os líderes deveriam entender da cifra de 98%?

A cifra de 98% é útil sobretudo porque desloca a conversa para onde o investimento deveria ir. Se as empresas supõem que a adoção da IA agêntica consiste principalmente em comprar acesso ao melhor modelo, subestimarão o trabalho necessário. O modelo é um componente. O sistema que o rodeia é o que determina se o modelo pode agir de uma forma segura, mensurável e alinhada aos objetivos da organização.

Por isso, uma estratégia séria de adoção precisa incluir engenharia para a armação: políticas de permissões, sandboxing, registros aprovados de ferramentas, governança de contexto, configurações seguras de MCP, logs de auditoria, rotas de reversão, integração com CI, suítes de avaliação e procedimentos de revisão humana. Também deve incluir treinamento para que os usuários não apenas "escrevam prompts melhores", mas supervisionem melhor: que definam restrições, forneçam objetivos de verificação, inspecionem diffs, entendam modos de falha e saibam quando não delegar. Isso é, em muitos sentidos, a mesma mudança que descrevemos em nosso post anterior sobre desenvolvimento agentivo: o engenheiro tornando-se um orquestrador que supervisiona múltiplos agentes, define objetivos de alto nível, resolve conflitos entre eles e revisa os pull requests resultantes, em vez de ser um programador inclinado sobre cada linha.

É aqui que se torna importante outro comentário que vi nas redes sociais. Dizia algo como "qualquer pessoa que se surpreenda com isso claramente não entendia os fundamentos dos agentes de IA desde o início". Comentários como esses são duros, mas a ideia de fundo é razoável. Na literatura sobre agentes, o modelo há muito tempo tem sido apenas uma peça de um ciclo que inclui planejamento, memória e uso de ferramentas. O que o Claude Code torna visível é uma versão de produção notável dessa ideia. A parte glamorosa é a resposta do modelo; a parte difícil é tudo o que é necessário antes e depois.

O risco por resolver: as pessoas podem aprender menos enquanto fazem mais

O artigo de Liu et al. não é incondicionalmente entusiasta. Ele levanta uma preocupação quanto à capacidade humana a longo prazo. O Claude Code pode aumentar a produtividade no curto prazo, mas os autores observam que sua arquitetura oferece mecanismos limitados que apoiam explicitamente a melhoria humana no longo prazo, uma compreensão mais profunda e a coerência sustentada da base de código. Eles consideram isso um critério de avaliação mais do que um valor fundamental do design.

Essa preocupação não deveria ser descartada. Se os desenvolvedores se apoiarem em agentes para navegar por bases de código, realizar alterações e corrigir testes, podem entregar mais rápido enquanto entendem menos. Se os analistas de segurança dependerem de agentes para priorizar achados e propor correções, podem processar mais alertas, mas perdem o hábito da investigação manual profunda. E se os executivos medirem apenas o throughput, podem deixar passar uma deterioração gradual da coerência da base de código, da qualidade da revisão ou do desenvolvimento de talentos juniores.

A resposta não é rejeitar as ferramentas agênticas. É desenhar fluxos de trabalho que preservem o aprendizado. Exija que os agentes produzam explicações concisas de cada mudança; peça testes antes das correções; use o modo plan para o trabalho complexo; faça com que os revisores inspecionem não apenas se os testes passam, mas também se o agente respeitou a arquitetura, os modelos de ameaças e as restrições de manutenibilidade, e trate o resultado do agente como um rascunho que deve conquistar a confiança com evidências.

Um bom agente de codificação deveria tornar os profissionais mais capazes, não apenas mais ocupados em um nível mais alto de abstração.

Conclusão: o futuro pertence à armação

O Claude Code é impressionante, em parte, porque o seu modelo é poderoso. Mas a lição mais profunda do artigo referido é que os agentes de produção têm sucesso ou falham consoante a infraestrutura que envolve o modelo. O ciclo pode ser simples; o sistema não é.

Para os desenvolvedores, a conclusão prática é usar ferramentas de codificação agêntica como colaboradoras em um fluxo de trabalho de engenharia, não como substitutas autônomas. Os analistas de segurança têm uma tarefa arquitetônica a realizar: avaliar permissões, ferramentas, contexto, memória, conectores e registros, e não apenas o comportamento de recusa do modelo. E, para os executivos, a pergunta é estratégica: as empresas que mais proveito tirarem dos agentes de IA serão aquelas que investirem na armação, nas políticas e na cultura de verificação que os rodeiam.

A próxima fase da adoção de IA não será definida por uma competição entre humanos e agentes. Será definida por quão bem as organizações desenham o espaço no qual humanos, modelos e sistemas de software trabalham juntos. O exemplo do Claude Code foi muito valioso aqui porque mostra quanta engenharia precisa estar em seu devido lugar antes que um agente possa agir de forma responsável. Em conclusão, os agentes de IA úteis são mais engenharia do que magia.