O que você vai aprender aqui
Este texto é para quem já usa um agente de código para tarefas pequenas e quer entender o que muda quando ele passa a fazer tarefas grandes. São cinco conceitos, na ordem em que fazem sentido para quem está aprendendo. O último é o mais importante e é o que quase todo mundo deixa para depois.
Se você só tiver cinco minutos, leia o conceito 5 e o checklist do final.
1. O ponto de inflexão: de autocomplete a feature inteira
A primeira forma de usar um modelo para programar foi como autocomplete. Você escrevia a função, ele completava a linha. O problema conhecido dessa fase é que corrigir a saída frequentemente custava mais tempo do que escrever o código sozinho.
O que mudou é a unidade de trabalho. Agora a unidade é a feature, não a linha. Um agente de código lê o repositório, entende onde as coisas ficam, escreve o teste, roda o teste, ajusta o que falhou e integra a mudança. Você não está mais completando código, está delegando uma entrega com critério de conclusão.
Isso muda a pergunta que você faz. Antes era "como escrevo isso?". Agora é "como descrevo o que pronto significa para que o agente saiba quando parar?".
2. Spec-driven: troque a conversa pelo contrato
Quando a tarefa é grande, conversar em ciclos curtos com o modelo custa caro. Cada ida e volta reinterpreta o que você quis dizer, e modelos diferentes interpretam a mesma instrução de formas diferentes. O resultado é aquela negociação em que você repete o pedido com outras palavras até sair algo aceitável.
A alternativa é escrever a especificação antes: os requisitos, os comportamentos esperados e o que caracteriza a entrega como concluída. Com isso, o agente trabalha contra um documento estável em vez de contra a sua última frase.
Na prática, uma spec útil tem quatro partes:
- Objetivo: o problema que a entrega resolve.
- Comportamento esperado: o que deve acontecer em cada situação relevante, incluindo erro.
- Fora de escopo: o que você não quer que ele faça.
- Critério de pronto: como você vai verificar que terminou.
O item 3 é o que a maioria esquece. Sem ele, o agente decide sozinho o que faz parte da tarefa, e você descobre isso na revisão.
3. De implementar para conduzir
Durante décadas, o gargalo de entregar software foi escrever o código e escrever bem. As empresas contratavam quem resolvia os problemas mais difíceis de programação, porque era isso que limitava a velocidade.
Esse gargalo se deslocou. Modelos já conhecem as linguagens e resolvem tarefas de implementação com competência razoável. O que limita agora é a decisão: qual arquitetura sustenta isso daqui a um ano, o que entra primeiro, o que fica de fora, quando parar de prototipar.
O nome que se usa para esse papel é condução, e ele é menos sobre escrever e mais sobre dirigir. Na prática você faz três coisas: define o objetivo, quebra em marcos verificáveis e decide os pontos que terão consequência duradoura.
A parte desconfortável é que essa habilidade não se aprende lendo sobre ela. Ela vem de ter visto decisões ruins cobrarem caro seis meses depois.
4. Contexto e loop: pare de empurrar o agente
Dois conceitos explicam a diferença entre um agente frustrante e um agente útil.
Engenharia de contexto é entender que a janela do modelo é um recurso limitado e que disputam espaço com o seu código várias outras coisas: ferramentas, arquivos de instrução, dados externos, resultados de buscas. Quanto mais informação irrelevante entra, menos atenção sobra para o que importa. Organizar o que entra é parte do trabalho, não detalhe de configuração.
Três peças ajudam nisso:
- Arquivos de instrução com o que é estável do projeto: convenções, comandos, o que não fazer.
- Automações para o que precisa acontecer sem você pedir, como rodar verificação a cada mudança.
- Sub-agentes para investigação isolada: você manda alguém pesquisar como uma biblioteca funciona e voltar com a resposta, sem trazer toda a pesquisa para a conversa principal.
Engenharia de loop é a mudança de postura. Em vez de você empurrar o agente a cada passo, você desenha um ciclo que se repete sozinho até a condição de conclusão. Você define o propósito e o critério de parada. O ciclo cuida da iteração.
Isso só funciona se o critério de parada for verificável. "Deixar o código bom" não é critério. "Todos os testes passam e o build está limpo" é.
5. Segurança: injeção de prompt não é hipótese
Este é o conceito que decide se você vai ter um incidente.
Um agente de código tem três coisas ao mesmo tempo: acesso a dados sensíveis, acesso à web e capacidade de enviar informação para fora. Isolar qualquer uma delas reduz o risco. As três juntas criam uma classe de ataque que só existe nesse formato.
O cenário é simples de entender. O agente lê um pull request, um ticket ou uma página qualquer. Esse conteúdo contém uma instrução escondida. O agente, que não distingue instrução de dado, obedece. Se ele tem credenciais e rede, ele pode mandar essas credenciais para fora sem que ninguém perceba, porque nada falhou: não houve erro, não houve exceção, o trabalho continuou.
Vale comparar com o que já se sabe sobre segurança de aplicações. Injeção de SQL é um problema antigo e conhecido, com defesas estabelecidas. Injeção de prompt é o mesmo problema em um sistema que lê texto e obedece, e as defesas ainda estão sendo construídas.
O que você pode fazer hoje, sem depender de fornecedor:
- Rode agentes em ambiente descartável, para que o dano não sobreviva à sessão.
- Dê o menor conjunto de credenciais que permita a tarefa.
- Trate todo conteúdo externo como não confiável, incluindo pull requests e issues.
- Prefira agentes que pedem confirmação antes de ações com efeito externo.
Um detalhe técnico que explica muita confusão
Se você perguntar a um modelo quanto tempo leva para construir um jogo, ele responde em semanas ou meses. Se você pedir o jogo a um agente, ele entrega algo funcionando em minutos. Parece contraditório, e não é: o modelo não tem experiência de tempo nem de memória como você tem. Ele estima a partir de texto que leu sobre projetos parecidos, não a partir de já ter feito.
Saber como o modelo funciona por dentro evita esse tipo de mal-entendido. Os pesos ficam carregados na memória da GPU e o cache de contexto cresce conforme a conversa avança. Isso explica por que janelas longas ficam caras e por que qualidade cai quando o contexto enche de material irrelevante. Não é mística, é orçamento de recurso.
Por que isso não significa o fim do trabalho técnico
Quando a eletricidade passou a alimentar casas e fábricas, o trabalho ligado a ela não desapareceu. Apareceu uma camada inteira de gente que mantém a rede funcionando, atende emergências, garante acesso e cuida da qualidade do fornecimento. A tecnologia virou infraestrutura, e infraestrutura exige manutenção.
Com agentes tende a acontecer o mesmo. A parte de digitar código perde peso, e o trabalho de manter sistemas confiáveis, seguros e compreensíveis ganha. Quem entende de arquitetura, de risco e de decisão fica mais valioso, não menos.
Checklist antes do próximo agente
Use isto antes de abrir a tarefa:
- Escrevi o objetivo em uma frase?
- Defini o que conta como pronto, de forma verificável?
- Listei o que está fora de escopo?
- O agente tem só as credenciais que essa tarefa exige?
- O ambiente é descartável se algo der errado?
- Todo conteúdo externo que ele vai ler é tratado como não confiável?
- Sei quais decisões vou querer revisar antes de aceitar?
Se você marcou tudo, a tarefa está pronta para ser delegada. Se faltou o item 7, você provavelmente está delegando uma decisão que ainda é sua.
