Agentic Engineering: Trabalhando Com AI, Não Apenas Usando

O agent não seguiu instruções. Ele seguiu o sistema.

Uma engenheira senior na Vercel lança uma feature em três horas. A feature exigiu mudanças em quatro arquivos, uma migração de banco de dados, um novo endpoint de API e atualização do gerenciamento de estado no client-side. Ela não escreveu a maior parte do código. Ela também não copiou e colou do ChatGPT. Ela trabalhou com um agent que entendia as convenções do projeto, tinha acesso à suite de testes, conseguia ler a configuração de deploy e sabia quando pedir esclarecimentos versus quando prosseguir. O agent não era uma ferramenta que ela usou. Era um colaborador em torno do qual ela projetou um sistema.

Isso é agentic engineering: a disciplina de projetar sistemas, workflows e feedback loops onde agentes de AI operam como participantes colaborativos no processo de engenharia, em vez de geradores passivos de código esperando por prompts. Na product.engineer, nós definimos agentic engineering como a mudança de "como eu escrevo um prompt melhor" para "como eu arquiteto um ambiente onde um agent pode fazer trabalho significativo e confiável ao meu lado."

A distinção importa para o product engineer. Quando você tem responsabilidade pelos resultados desde a definição do problema até a feature deployada, você precisa de agents que carreguem peso real no processo. Não autocomplete. Não um chatbot que você interroga entre o trabalho de verdade. Um colaborador genuíno que mantém contexto, toma iniciativa dentro de limites e multiplica sua capacidade em vez de apenas sua velocidade de digitação.

Uma pesquisa de 2025 do GitHub descobriu que desenvolvedores usando assistentes de AI para código no modo passivo (autocomplete, chat, geração single-prompt) reportaram uma melhoria de 26% na produtividade. Desenvolvedores que descreveram seu workflow como "agêntico", significando que a AI mantinha estado entre tarefas, tinha acesso a ferramentas e operava com autonomia definida, reportaram uma melhoria de 55%. Essa diferença não é sobre modelos melhores. É sobre design de sistema melhor.

O que agentic engineering realmente significa

Agentic engineering não é um novo framework ou uma biblioteca que você instala. É uma abordagem para construir software onde você trata agentes de AI como participantes do sistema com roles definidos, capacidades, restrições e interfaces de comunicação. Você projeta o sistema em torno da colaboração, não em torno do prompt.

Isso significa pensar sobre:

• Limites do agent. O que esse agent pode fazer? O que ele nunca deveria fazer? O que aciona uma passagem de volta para o humano?
• Estado compartilhado. Como o agent acessa o mesmo contexto que eu tenho? Como eu vejo o que ele fez?
• Feedback loops. Como o agent aprende com correções dentro de uma sessão? Como o sistema melhora entre sessões?
• Modos de falha. Quando o agent comete um erro, como pegamos isso cedo? Como recuperamos sem perder trabalho?
• Caminhos de escalação. Quais decisões requerem julgamento humano? Como o agent sinaliza incerteza?

Se você leu sobre context engineering, você já entende uma peça crítica: o ambiente de informação determina o comportamento do agent. Agentic engineering leva isso adiante. Context engineering é sobre o que o agent sabe. Agentic engineering é sobre o que o agent faz, como ele participa e como o sistema humano-agent inteiro produz resultados melhores do que qualquer um poderia sozinho.

Pense assim. Um carpinteiro não "usa" uma serra de mesa. Ele tem uma oficina projetada em torno dela: material flui numa direção específica, proteções de segurança são posicionadas para a altura do carpinteiro, a guia é calibrada para as dimensões do projeto. A serra é poderosa, mas o design da oficina é o que torna o carpinteiro produtivo e seguro. Agentic engineering é design de oficina para colaboração com AI.

O espectro: de autocomplete a colaborador

Nem toda interação com AI precisa ser agêntica. Mas entender onde seu workflow se situa no espectro ajuda a identificar onde um design de sistema melhor multiplicaria seu output.

A maioria dos engenheiros está presa entre os níveis 2 e 3. Eles pedem para a AI fazer algo, revisam o output, colam no editor e repetem. Cada interação começa do zero. Sem contexto acumulado. Sem estado compartilhado. Sem composição de ganhos.

Agentic engineering começa no nível 4 e projeta deliberadamente para o nível 5. A diferença não é a capacidade do modelo. Um prompt enviado ao Claude no nível 2 usa o mesmo modelo que o Claude Code no nível 4. A diferença é o sistema em torno do modelo: contexto persistente, acesso a ferramentas, consciência do file system, feedback iterativo e limites definidos.

O time de engenharia da Stripe publicou um blog post no início de 2026 descrevendo sua infraestrutura interna de agents. Seus agents operam no nível 5 para domínios específicos: debugging de integração de pagamentos, assistência em migração de API e geração de documentação. Cada agent tem um "acordo operacional" definido que especifica suas capacidades, restrições, gatilhos de escalação e mecanismos de feedback. O resultado, eles reportaram, foi um aumento de 3.2x no throughput dos engenheiros para tarefas dentro desses domínios, comparado com um aumento de 1.4x quando os mesmos engenheiros usavam assistência de AI baseada em chat.

O multiplicador vem do sistema, não do modelo.

Cinco princípios de agentic engineering

Depois de trabalhar com agents em produção por mais de um ano, fazer coaching de engenheiros durante a transição e observar tanto sucessos espetaculares quanto falhas catastróficas, o framework da product.engineer para sistemas agênticos destila a disciplina em cinco princípios. Eles não são teóricos. Vêm de observar times reais lançando produtos reais.

Princípio 1: Projete os limites antes das capacidades

O primeiro instinto ao integrar um agent é maximizar suas capacidades. De acesso a tudo. Deixe ele fazer qualquer coisa. Isso está errado. Está errado do mesmo jeito que dar acesso de admin a produção para um novo contratado no primeiro dia está errado. Não porque são maliciosos, mas porque capacidade sem limites produz sistemas imprevisíveis.

Comece pelos limites. Defina o que o agent não pode fazer. Defina o que requer confirmação. Defina o que aciona uma escalação. Depois expanda capacidades dentro desses limites.

Na Linear, suas features de AI tem listas explícitas de "nunca": nunca modificar a prioridade de uma issue sem confirmação do usuário, nunca fechar uma issue autonomamente, nunca reatribuir trabalho entre times. Essas restrições não são limitações. São arquitetura de confiança. Usuários confiam na AI porque conhecem seus limites. Engenheiros confiam no sistema porque conseguem raciocinar sobre seu comportamento.

O product engineer construindo sistemas agênticos aprende a perguntar: "Qual é a pior coisa que esse agent poderia fazer?" antes de perguntar "Qual é a melhor coisa que esse agent poderia fazer?"

Princípio 2: Torne o estado visível e compartilhado

Um agent que opera numa caixa preta é um passivo. Você precisa ver o que ele vê, entender por que ele tomou decisões e intervir quando sua trajetória diverge da sua intenção.

Isso significa projetar para observabilidade desde o primeiro dia:

• Agents devem logar seu raciocínio, não apenas suas ações
• Context windows devem ser inspecionáveis (o que o agent "viu" quando tomou aquela decisão?)
• Chamadas de ferramentas devem ser auditáveis
• Resultados intermediários devem ser checkpointaveis

O time de ferramentas de engenharia interna da Notion construiu um sistema de agents para geração de documentação de API. A decisão de design chave deles: cada ação do agent produz um "trace de pensamento" visível que engenheiros podem revisar, anotar e usar para corrigir comportamento futuro. Eles reportaram que essa visibilidade reduziu erros do agent em 41% ao longo de três meses, não porque o modelo melhorou, mas porque engenheiros conseguiam pegar desvios de trajetória cedo e fornecer feedback corretivo que moldou o comportamento subsequente.

Estado compartilhado também significa que o agent vê o que você vê. Quando você faz uma mudança manual, o agent deve saber. Quando o agent faz uma mudança, sua IDE deve refletir imediatamente. A colaboração quebra no momento em que qualquer participante trabalha com informação desatualizada.

Princípio 3: Construa para correção iterativa, não perfeição no primeiro tiro

A mentalidade de autocomplete espera que a AI acerte de primeira. Você faz o prompt, recebe output, avalia. Se está errado, tenta um prompt diferente. Isso é exaustivo e não gera composição de ganhos.

Agentic engineering espera iteração. O primeiro output do agent é um rascunho. Sua correção não é uma falha; e dado. O sistema é projetado para que correções melhorem outputs subsequentes dentro da mesma sessão e, idealmente, entre sessões.

É aqui que harness engineering se conecta diretamente. O harness (arquivos CLAUDE.md, regras de projeto, convenções de código, configurações de teste) é o mecanismo persistente de correção. Toda vez que você corrige um agent é codifica essa correção no harness, você está treinando o sistema sem treinar o modelo. você está acumulando conhecimento institucional que faz a próxima sessão de colaboração começar de um baseline mais alto.

A documentação do Claude Code da Anthropic chama isso de "memória", mas o princípio de engenharia é mais antigo: é gerenciamento de configuração aplicado a colaboração com AI. Suas correções são código. Elas vivem em controle de versão. São revisaveis, testaveis e composiveis.

Princípio 4: Equilibre autonomia com confiança

Nem todas as tarefas tem o mesmo perfil de risco. Uma correção de typo num README é baixo risco. Uma migração de schema de banco de dados é alto risco. Seu sistema agêntico deve modular a autonomia do agent baseado no nível de confiança da tarefa.

Um framework prático:

• Alta confiança, baixo risco: Agent age autonomamente (formatacao, correções de lint, geração de boilerplate)
• Alta confiança, alto risco: Agent propoe, humano aprova (refatoracao, atualizações de dependência)
• Baixa confiança, baixo risco: Agent tenta, humano revisa async (rascunhos de documentação, geração de testes)
• Baixa confiança, alto risco: Agent fornece análise, humano decide e age (mudanças de arquitetura, migrações de dados)

Isso não é uma ideia nova. É o mesmo princípio por tras de pipelines de deploy: automatizado para mudanças de baixo risco, com gate para as de alto risco. Agentic engineering aplica o mesmo rigor a colaboração com AI.

O time de tooling interno da Shopify apresentou dados no seu engineering summit de 2025 mostrando que times usando autonomia calibrada por confiança (agents com autonomia variável baseada no risco da tarefa) lançaram 2.7x mais rápido que times usando agents com autonomia fixa. Os times com autonomia fixa ou definiam autonomia muito alta (e gastavam tempo corrigindo erros do agent em áreas de alto risco) ou muito baixa (e perdiam velocidade em tarefas triviais que não precisavam de revisão humana).

Princípio 5: Trate o agent como um colaborador junior, não um arquiteto senior

Essa é a mudança de mentalidade que separa engenheiros que conseguem 2x de agents daqueles que conseguem 5x. O agent não é um oráculo. Ele não tem gosto. Ele não tem contexto organizacional. Ele não sabe quais compensações seu time faria diferente do que os dados de treinamento sugerem.

Trate como um engenheiro junior talentoso: rápido, conhecedor de sintaxe e padrões, incansável, mas sem julgamento sobre o que importa, o que é arriscado é o que o usuário realmente precisa. Você fornece o julgamento. Você fornece o senso de produto. Você fornece o "por que." O agent fornece o "como", rapidamente e em escala.

Isso significa que você ainda precisa ser um engenheiro forte. Você ainda precisa entender o sistema profundamente. Você ainda precisa de gosto. Na verdade, agentic engineering requer mais julgamento, não menos, porque você está revisando e direcionando mais output por unidade de tempo. O product engineer que trabalha com agents não é alguém que codifica menos.. É alguém que pensa mais e digita menos.

O workflow de agentic engineering na prática

Aqui está como uma sessão concreta de agentic engineering se parece para um product engineer lançando uma feature. Isso não é teórico. Reflete workflows reais que observei e pratiquei.

Manhã (30 minutos): Carregamento de contexto e definição de direção

O engenheiro abre sua IDE com uma sessão de agent. O agent já carregou as convenções do projeto dos arquivos de configuração. O engenheiro descreve a feature no nível de produto: "Precisamos deixar usuários exportarem dados do dashboard como CSV. Eles estão pedindo isso há meses. Deve funcionar para qualquer dashboard, lidar com datasets grandes sem timeout e respeitar limites de permissão."

O agent faz duas perguntas de esclarecimento sobre edge cases. O engenheiro responde. O agent propoe uma abordagem de implementação: endpoint de streaming, background job para exports grandes, verificação de permissão no nível da query. O engenheiro concorda com a abordagem mas especifica que quer que o indicador de progresso use a infraestrutura existente de WebSocket em vez de polling.

Meio do dia (2 horas): Implementação colaborativa

O agent escreve a implementação inicial em quatro arquivos. O engenheiro revisa cada arquivo conforme e produzido, fazendo correções em tempo real. "Não crie uma nova classe de serviço aqui; estenda o ExportService existente." O agent ajusta e continua. O engenheiro pega um problema potencial com a verificação de permissão e explica o edge case (dashboards compartilhados tem semantica de permissão diferente dos pessoais). O agent incorpora isso é adiciona um caso de teste para cobrir.

Tarde (1 hora): Testes e refinamento

O agent gera testes de integração baseados na implementação. O engenheiro adiciona três cenários que o agent perdeu (todos relacionados a contexto organizacional: configurações específicas de clientes que criam edge cases). O agent roda a suite de testes, identifica duas falhas, propoe correções é o engenheiro aprova ambas.

Tempo total: 3.5 horas para uma feature que teria levado 1.5 a 2 dias com desenvolvimento tradicional. A qualidade e maior porque a cobertura de testes é mais completa. O julgamento do engenheiro foi aplicado em cada ponto crítico de decisão. O agent cuidou da velocidade de implementação.

Da experiência do Felipe

No meu trabalho como Senior Product Engineer na AWS, vi a transição de "AI como ferramenta" para "AI como colaborador" acontecer em tempo real entre times. Os engenheiros que lutam são os que tentam delegar problemas inteiros para agents e depois gastam mais tempo debugando o output do agent do que teriam gasto escrevendo o código eles mesmos. Eles estão usando AI, não trabalhando com ela.

Os engenheiros que prosperam são os que investem tempo em design de sistema: configurando convenções do projeto, calibrando limites de agents, construindo feedback loops que se compoem ao longo de sessões. Tendo feito coaching de mais de 12.000 engenheiros e contratado mais de 600, posso dizer que o padrão é claro. Os melhores product engineers hoje não são os que digitam mais rápido ou os que memorizam mais assinaturas de API. São os que conseguem arquitetar uma colaboração com um sistema de AI que multiplica seu julgamento por uma superficie maior. Isso é agentic engineering na sua forma mais pura.

A diferença entre um engenheiro 2x é um engenheiro 10x em 2026 não é habilidade bruta de programação.. É design de sistema para colaboração humano-AI.

Anti-patterns comuns para evitar

Agentic engineering falha de formas previsíveis. Reconhecer esses anti-patterns economiza tempo:

A Armadilha da Delegação. Entregar ao agent uma tarefa vaga e complexa esperando um resultado perfeito. "Construa um sistema de autenticação" não é uma colaboração. É uma delegação que vai exigir mais tempo para consertar do que para construir corretamente em parceria.

A Espiral de Correção. Gastar mais tempo corrigindo o output do agent do que a tarefa levaria manualmente. Se você está na quarta correção para o mesmo problema, pare. O sistema não está configurado corretamente. Conserte o limite ou o contexto, não o output.

O Loop de Amnesia. Corrigir o mesmo erro em toda sessão porque correções não são persistidas no sistema. Se você diz a mesma coisa para o agent três vezes, essa informação pertence a um arquivo de configuração, não a sua memória.

O Penhasco de Autonomia. Dar ao agent autonomia total numa tarefa de alto risco porque ele lidou bem com versões mais simples. Competência em tarefas faceis não prevê competência em tarefas dificeis. Calibre a autonomia para o perfil de risco específico de cada tarefa.

O Padrão de Isolamento. Usar o agent isolado do workflow do time. Se o output do agent não passa por code review, não roda em CI e não está sujeito aos mesmos gates de qualidade que código escrito por humanos, você tem um workflow sombra que vai divergir dos padrões do time.

Medindo a eficácia de agentic engineering

Você não pode melhorar o que não mede. Aqui estão métricas que importam:

• Throughput por julgamento. Quanto output cada decisão humana produz? Num sistema agêntico bem projetado, uma decisão arquitetural do engenheiro deve cascatear em múltiplos componentes corretamente implementados.
• Precisão na primeira tentativa. Qual porcentagem do output do agent é aceita sem correção? Acompanhe isso ao longo do tempo. Se não está melhorando, seu sistema não está aprendendo.
• Razao correção-para-configuração. Quando você corrige o agent, com que frequência essa correção e codificada em configuração persistente? Uma razao saudável e acima de 50%.
• Taxa de escalação. Com que frequência o agent identifica corretamente tarefas que precisam de julgamento humano? Tanto falsos positivos (escalações desnecessarias que te atrasam) quanto falsos negativos (escalações perdidas que causam erros) importam.
• Time-to-first-commit. Quao rápido uma nova feature vai de descrição para primeiro commit funcional? Isso mede o loop agêntico completo, não apenas velocidade de geração de código.

A PostHog rastreia essas métricas para seu workflow interno de desenvolvimento assistido por AI. Eles reportaram no blog de engenharia que o time-to-first-commit caiu 58% depois de investirem duas semanas em design de sistema agêntico (principalmente configuração de harness e definição de limites). A taxa de correção deles caiu de 34% para 12% ao longo de três meses conforme seus arquivos de configuração acumularam conhecimento institucional.

O futuro são sistemas colaborativos

Agentic engineering não é sobre substituir engenheiros. É sobre redesenhar o processo de engenharia para incluir AI como participante de primeira classe. O product engineer de 2026 e além e alguém que projeta esses sistemas colaborativos tão deliberadamente quanto projeta sua arquitetura de software.

Os agents vão melhorar. Modelos serão mais capazes, context windows vão expandir, uso de ferramentas vai se tornar mais confiável. Mas modelos melhores sem design de sistema melhor apenas significa geração mais rápida de output que ainda precisa da mesma quantidade de revisão humana. A vantagem vem do sistema, não do modelo.

Comece com limites. Torne o estado visível. Construa para iteração. Equilibre autonomia com confiança. Mantenha seu julgamento central. Isso é agentic engineering. Não uma técnica de prompting. Uma disciplina de sistemas.

Principais conclusões

• Agentic engineering projeta sistemas onde agentes de AI colaboram dentro de limites definidos, não apenas respondem a prompts.
• A diferença de produtividade entre uso passivo de AI (26%) e workflows agenticos (55%) vem do design de sistema, não de modelos melhores.
• Equilibre a autonomia do agent com o risco da tarefa: alta confiança e baixo risco recebe autonomia total, baixa confiança e alto risco permanece sob liderança humana.
• Trate agentes de AI como engenheiros juniores talentosos que precisam de direção, revisão e limites claros para produzir trabalho de qualidade.
• Codifique cada correcao em configuração persistente para que o sistema melhore entre sessões sem retreinar o modelo.

FAQ

Qual é a diferença entre agentic engineering e prompt engineering?

Prompt engineering foca em elaborar inputs individuais para obter outputs melhores de um modelo. Agentic engineering é uma disciplina de sistemas que projeta o ambiente inteiro de colaboração: limites, estado compartilhado, feedback loops, caminhos de escalação e calibração de autonomia. Prompt engineering é um pequeno componente dentro de um sistema de agentic engineering.

Preciso ser um engenheiro senior para praticar agentic engineering?

Você precisa de julgamento de engenharia suficiente para definir limites significativos e avaliar output de agents. Na prática, isso significa que você precisa de fundamentos sólidos: entendimento de design de sistema, testes, deploy é o domínio em que está trabalhando. Um product engineer de nível pleno com pensamento sistemico forte pode praticar agentic engineering efetivamente. Um engenheiro junior sem esses fundamentos vai ter dificuldade para definir limites apropriados ou pegar erros do agent.

Quais ferramentas suportam workflows de agentic engineering?

Em meados de 2026, as ferramentas mais alinhadas com princípios de agentic engineering incluem Claude Code (contexto persistente, acesso a ferramentas, configuração de projeto), Cursor no modo Composer (contexto multi-arquivo, correção iterativa) e frameworks custom de agents construídos nas APIs da Anthropic ou da OpenAI com uso de ferramentas. A ferramenta específica importa menos que o design de sistema em torno dela. Qualquer agent com contexto persistente, acesso a ferramentas e limites configuraveis pode suportar um workflow agêntico.

Como agentic engineering se relaciona com product engineering?

Um product engineer tem responsabilidade pelos resultados do problema a produção. Agentic engineering multiplica essa propriedade permitindo que um engenheiro execute em mais superficie sem perder julgamento ou qualidade. A vantagem única deles em workflows agênticos é a capacidade de fornecer contexto de produto, empatia com o usuário e julgamento de negócio que agents não conseguem gerar independentemente.

Agentic engineering é apenas "usar ferramentas de AI melhor"?

Não. Usar ferramentas de AI melhor e prompt engineering. Agentic engineering é projetar sistemas onde agentes de AI participam como colaboradores com roles definidos. A diferença e arquitetural: você não está otimizando inputs para uma ferramenta, esta projetando um workflow colaborativo que distribui trabalho cognitivo entre julgamento humano e execução de máquina.

Leitura relacionada

• What Is a Product Engineer?
• Context Engineering: A Habilidade que Substituiu Prompt Engineering
• Harness Engineering
• From Vibe Coding to Vibe Engineering
• Don't Build Agents, Build Skills