Uma das frases mais provocativas sobre agentes de programação é que escrever código era o trabalho antigo e construir loops seria o novo. Ela aparece no vídeo que motivou este post, uma conversa com Boris Cherny publicada no X.

Se o player não carregar, o vídeo continua disponível no post original no X .

Vale tomar cuidado com a frase. Ela é útil como provocação, mas ruim como profecia. Programar não virou uma habilidade dispensável; continua sendo o modo mais direto de entender uma máquina, revisar uma mudança e perceber quando uma solução está só com boa aparência. O que mudou é o centro de gravidade do trabalho.

Quando um agente consegue explorar o repositório, alterar arquivos e produzir uma primeira implementação, o gargalo deixa de ser apenas digitar a próxima linha. Passa a ser decidir o que deve ser feito, sob quais restrições, como reconhecer que ficou pronto e como corrigir o rumo quando a primeira tentativa falhar.

Em outras palavras: menos energia em fabricar texto de código, mais engenharia para transformar intenção em resultado confiável.

A IA não elimina o trabalho; ela desloca o gargalo Link para o cabeçalho

Um agente pode produzir bastante código em poucos minutos. Isso não significa que ele sabe o que a empresa precisa, conhece a exceção fiscal escondida numa regra de negócio ou entende por que uma tela aparentemente simples precisa funcionar no celular ruim do cliente.

Essa diferença importa porque software não é uma competição de linhas produzidas. É uma tentativa de mudar um sistema sem quebrar o que já funciona, dentro de prazos, custos, políticas e expectativas reais de pessoas.

Uma pesquisa da Anthropic sobre uso prático de agentes de programação descreve uma divisão de trabalho interessante: pessoas tendem a tomar mais decisões de planejamento — o que fazer, qual resultado esperar e quando considerar terminado — enquanto o agente toma mais decisões de execução. A mesma pesquisa associa maior conhecimento do domínio a mais sucesso nas sessões. Não é uma lei da natureza, nem uma garantia para toda ferramenta, mas é um bom lembrete: saber fazer perguntas continua valendo muito.

O relatório DORA de 2025 chega a uma conclusão compatível em outro nível. A IA funciona como amplificador: equipes com processos saudáveis extraem mais valor; equipes com contexto ruim, validação frágil e handoffs confusos conseguem errar com uma velocidade admirável.

1. Aprenda a definir o problema antes de pedir uma solução Link para o cabeçalho

Um pedido como “crie uma tela de cadastro de clientes” parece objetivo só até alguém perguntar o básico:

  • quem pode cadastrar e editar;
  • quais dados são obrigatórios;
  • o que acontece com duplicidades;
  • que regra de negócio vem antes de salvar;
  • como a operação será validada;
  • que comportamento é aceitável quando uma integração estiver indisponível.

Sem essas respostas, a IA não está resolvendo um problema. Está preenchendo lacunas com hipóteses. Às vezes as hipóteses são ótimas. Em produção, esse não é um critério particularmente reconfortante.

Antes de abrir o agente, vale escrever um mini-contrato de entrega:

Elemento Exemplo prático
Objetivo Permitir que o cliente atualize o próprio telefone.
Restrições Não exibir outros dados pessoais; manter a autenticação atual.
Critério de aceite Número inválido gera mensagem clara; alteração fica registrada; testes passam.
Fora de escopo Não criar uma área completa de perfil nesta entrega.

Isso não é burocracia para impressionar a IA. É uma forma de o time descobrir que ainda não sabe o que está pedindo. O agente só torna essa descoberta mais rápida — e, em alguns dias, mais cara.

2. Aprenda a fornecer o contexto que muda a resposta Link para o cabeçalho

Modelos entendem padrões gerais. Seu sistema, infelizmente ou felizmente, é específico.

O contexto que altera uma implementação não costuma ser “use Python” ou “faça bonito”. É saber onde está a regra, quais convenções o projeto adota, que comando valida a alteração, quais dados são sensíveis e onde o agente não deve tocar.

Arquivos como AGENTS.md, CLAUDE.md e instruções equivalentes servem justamente para transformar conhecimento disperso em contexto operacional. Eles podem registrar comandos de teste, padrões de código, integrações perigosas, convenções de branch e limites de acesso. Não fazem milagre: um arquivo enorme e genérico também vira ruído. Mas um conjunto curto de instruções específicas reduz a quantidade de adivinhação.

Contexto também é escolher o que não entregar. Log de produção, chave de API, banco de clientes e arquivo .env não são matéria-prima para um prompt melhor. Quanto mais poder a ferramenta recebe, mais importante fica o princípio do menor privilégio.

3. Aprenda a construir verificação, não apenas instruções Link para o cabeçalho

O melhor prompt do mundo não é uma prova de correção.

As boas práticas da Anthropic para Claude Code colocam isso de maneira simples: dê ao agente um meio de verificar o próprio trabalho. Pode ser uma suíte de testes, um build, um linter, um script de comparação, uma captura visual ou uma revisão independente. O formato muda; o princípio é o mesmo.

Sem uma verificação executável, o agente termina quando a solução parece pronta. A validação fica por conta da memória e da atenção de alguém que talvez esteja em outra reunião, respondendo “LGTM” entre dois cafés.

Com uma verificação, o fluxo fica bem mais honesto:

  1. definir o comportamento esperado;
  2. implementar uma tentativa;
  3. executar o teste ou a checagem;
  4. ler o resultado;
  5. corrigir e repetir, se necessário.

Esse ciclo não torna o agente infalível. Ele só troca confiança abstrata por evidência. É uma troca excelente.

O teste é necessário, mas não é todo o sistema Link para o cabeçalho

Também seria ingênuo concluir que “passou no CI” significa “está certo”. Testes podem cobrir a regra errada, screenshots podem deixar passar uma interação ruim e métricas podem otimizar o que é fácil de medir. Verificação é uma camada, não um certificado metafísico.

Por isso, uma boa definição de pronto costuma combinar sinais diferentes:

  • testes automatizados para comportamento conhecido;
  • build, lint e análise estática para erros mecânicos;
  • revisão humana para riscos, legibilidade e decisões de produto;
  • observabilidade e feedback de usuários para o que só aparece no uso real.

4. Aprenda a desenhar loops de feedback Link para o cabeçalho

O termo loop pode soar como mais um empréstimo desnecessário do inglês, mas a ideia é antiga: agir, observar, ajustar e repetir.

No vídeo de referência, a conversa enfatiza feedback de usuários e correções rápidas. Isso se aplica a produto, mas também ao desenvolvimento assistido por IA. Um agente melhora quando recebe um sinal claro de que algo deu errado; uma equipe melhora quando esse sinal não desaparece numa fila sem dono.

Um loop saudável tem quatro características:

  • é curto: o erro aparece perto da mudança que o produziu;
  • é observável: alguém consegue ver o resultado, não apenas ouvir que “deu certo”;
  • tem responsável: feedback sem destino vira decoração de ferramenta;
  • altera o próximo passo: registrar um problema sem mudar processo, teste ou instrução repete o problema com mais documentação.

Na prática, isso pode significar adicionar um caso de teste depois de um bug, registrar uma regra recorrente no arquivo de instruções do repositório ou criar uma checagem no CI. Cada correção pequena reduz a dependência de lembrar da mesma armadilha na próxima conversa com a IA.

5. Aprenda a revisar o que parece convincente Link para o cabeçalho

Código gerado por IA tem uma qualidade peculiar: ele costuma parecer plausível antes de ser verdadeiro.

Esse é o motivo para manter fundamentos técnicos. Quem não entende tipos, fluxo de dados, banco, concorrência, segurança ou o domínio atendido fica sem ferramentas para contestar uma resposta elegante e errada. A revisão vira uma leitura de horóscopo em fonte monoespaçada.

Não é preciso memorizar toda API para continuar relevante. Mas é preciso manter a capacidade de investigar:

  • ler um diff e perguntar o que mudou de fato;
  • seguir uma requisição até o banco ou serviço externo;
  • distinguir erro de sintaxe de erro de regra;
  • identificar dados que não deveriam sair do ambiente;
  • comparar a solução com o comportamento que o usuário realmente precisa.

Ferramentas mais autônomas tornam essa capacidade mais importante, não menos. Delegar execução não equivale a delegar responsabilidade.

Um exercício prático para esta semana Link para o cabeçalho

Em vez de tentar automatizar o trabalho inteiro de uma vez, escolha uma demanda pequena e repetível. Pode ser corrigir uma validação, adicionar um endpoint simples ou ajustar uma tela.

Faça o experimento em seis passos:

  1. escreva o problema e três critérios de aceite antes de abrir o agente;
  2. entregue apenas o contexto necessário e indique os limites do repositório;
  3. peça um plano curto antes da alteração;
  4. peça a implementação e a execução das verificações existentes;
  5. revise o diff e teste o caminho de usuário mais importante;
  6. transforme o aprendizado em teste, documentação ou instrução reutilizável.

O sexto passo é o que faz o ganho sobreviver àquela sessão. Sem ele, você teve uma boa conversa. Com ele, começou a construir um sistema de trabalho melhor.

O desenvolvedor continua no centro — só que em outro lugar Link para o cabeçalho

Há uma versão preguiçosa desta história em que o código deixa de importar e todos viram “orquestradores”. Ela tem a vantagem de caber em uma postagem de rede social. Tem também o defeito de ignorar quase tudo que torna software confiável.

Programar continua importante. Só que, quando a implementação fica mais barata, outras habilidades ficam mais visíveis: formular problemas, compreender domínio, projetar restrições, construir evidências, lidar com risco e ouvir quem usa o produto.

A melhor pergunta não é “a IA vai escrever meu código?”. Ela já escreve parte dele. A pergunta melhor é: que sistema eu estou construindo para que esse código seja útil, verificável e seguro?

Essa é uma habilidade que não cabe em um único prompt. E é justamente por isso que vale aprender.

Referências Link para o cabeçalho