Em fevereiro de 2025, Andrej Karpathy descreveu "vibe coding" como a prática de descrever a intenção em linguagem natural, aceitar as alterações de um LLM com revisão mínima e deixar o código crescer além da sua compreensão habitual. Isso proporcionou uma velocidade impressionante para projetos pessoais e protótipos.
Um ano depois, ele observou que as capacidades dos agentes avançaram e propôs "engenharia agentiva" como seu nome preferido para a prática evoluída de orquestrar agentes, mantendo uma forte supervisão humana sobre arquitetura e processo. O objetivo, como ele definiu, é aproveitar o poder dos agentes sem comprometer a qualidade do software.
A distinção é importante. O "vibe coding" funciona bem para um único usuário em trabalhos pessoais de baixo risco, mas rapidamente acumula dívidas ocultas, falhas de segurança e problemas de manutenibilidade quando outras pessoas dependem do resultado. A engenharia agentiva mantém a velocidade e o poder dos agentes modernos, mas ancora tudo em estrutura clara, artefatos rastreáveis e responsabilidade humana.
O Fluxo de Trabalho da Engenharia Agentiva
Comece com uma intenção vaga e conduza conversas de design com a IA, documentando a funcionalidade em notas de reunião de design que descrevem a funcionalidade em suas partes componentes. Quando o design parecer sólido, capture a visão de alto nível e o mapa de componentes em uma hierarquia de design (isso é o que as pessoas mostram quando exibem um "cérebro" no Obsidian), uma estrutura navegável que dá a você e ao agente acesso imediato ao contexto circundante, decisões relacionadas e dependências. É também onde os diagramas de design residem, como UML (Linguagem de Modelagem Unificada), fluxos de código ou interação do usuário, juntamente com links para registros de decisão arquitetural (ADRs) onde eles esclarecem como os componentes se relacionam.
Para cada módulo ou bloco de funcionalidade menor, crie um spec.md focado dentro do LLD que defina comportamento preciso, assinaturas de função, casos de borda, expectativas de teste e pontos de integração. Usando toda a estrutura como um contexto de design, instrua a IA a construir uma hierarquia no estilo de ticket com rastreabilidade direta para as páginas wiki e as especificações. Implemente ticket por ticket com o agente seguindo o spec.md relevante como seu contrato. Em seguida, execute portões de verificação, implante, observe e atualize os artefatos vivos à medida que os requisitos evoluem.
Exemplo Real: Verificador Diário de Backup
Considere uma ferramenta CLI pequena e de nível de produção que verifica backups diários do S3 e envia alertas do Slack em caso de falha.
Comece com o objetivo vago: "Preciso de algo confiável que verifique se meus backups estão saudáveis todos os dias." Em seguida, conduza conversas arquiteturais com a IA para levantar requisitos e casos de borda:
- Quais são os modos de falha realistas para backups do S3 na prática?
- O que exatamente devemos verificar (idade, contagem de arquivos, tamanho, taxa de sucesso) e quais limites fazem sentido?
- Como a configuração e os segredos devem ser tratados entre o desenvolvimento local e as funções IAM de produção?
- Quais comandos CLI e formatos de saída seriam úteis no dia a dia?
- Quais requisitos não funcionais são mais importantes para uma ferramenta diária agendada?
Essas conversas esclarecem o escopo e ajudam a decompor a ferramenta em seus componentes principais: busca de metadados do S3 com lógica de repetição, um mecanismo de regras de verificação, um sistema de notificação, um carregador de configuração, uma interface CLI, registro estruturado e tratamento de erros.
Com o design claro, você documenta a visão de alto nível e o mapa de componentes no wiki da hierarquia de design, onde cada página é versionada e pode ser vinculada.
O wiki fornece aos leitores futuros o contexto circundante que um documento plano não pode fornecer. Como parte do mesmo trabalho de design, você cria um spec.md focado no nível sub-LLD para cada módulo. Aqui está o contrato para o buscador de metadados do S3.
Este spec.md é o contrato que você entrega ao agente, por exemplo: "Implemente exatamente conforme o spec.md no diretório s3_client/, siga os padrões do projeto e inclua testes abrangentes." Com o wiki e as especificações dos módulos em vigor, você então instrui a IA a gerar a hierarquia de tickets diretamente a partir deles. Cada item remonta a um requisito funcional e à especificação que define seu contrato.
A implementação então prossegue ticket por ticket, cada um entregue ao agente com seu spec.md correspondente como contrato. Aqui está o que isso produz na prática: uma execução agendada detectando um conjunto de backup curto e disparando o alerta.
A execução termina com código diferente de zero para que o cron job perceba e dispare o alerta que chega no Slack.
O alerta carrega o contexto da regra que um engenheiro de plantão precisa para agir: qual verificação falhou, o que foi encontrado, o que era esperado e qual conjunto de backup.
Benefícios Desta Abordagem em Camadas
- Os agentes lidam com o volume de implementação enquanto os humanos são responsáveis pela arquitetura e qualidade em todas as camadas.
- O wiki fornece descoberta e decisões em nível de projeto, enquanto os arquivos spec.md fornecem contratos precisos em nível de módulo sem inflar o design de alto nível.
- Requisitos e decisões fluem diretamente das páginas wiki e especificações para os tickets e código.
- As mudanças começam a partir de artefatos de design vivos, em vez de fazer engenharia reversa do código base.
- A separação clara de preocupações suporta trabalho paralelo, integração de novos membros e auditorias.
- Profissionais em formato T navegam com amplitude e questionam com precisão, e o agente fornece profundidade sob demanda sem forçar ninguém a manter todo o sistema na cabeça.
O "vibe coding" continua sendo um modo excelente para exploração e prototipagem pessoal rápida. A engenharia agentiva é como você canaliza esse mesmo poder conversacional para sistemas que outras pessoas podem confiar e manter.
O Papel do Profissional em Formato T
Este fluxo de trabalho é especialmente poderoso para profissionais em formato T: engenheiros que mantêm conhecimento amplo em todo o espaço da aplicação com a capacidade de se aprofundar quando necessário.
Porque você não precisa manter um modelo mental completo e atualizado de como toda a aplicação funciona a cada momento. O agente pode carregar essa profundidade e reexplicar qualquer parte sob demanda, desde que tenha o contexto certo do wiki, dos arquivos spec.md e do histórico da conversa.
O que você precisa é da capacidade de saber o que procurar e onde procurar, além da disciplina para continuar fazendo perguntas precisas até entender o item específico em trabalho. A parte ampla do T lhe dá o mapa do sistema; o agente de IA suporta as habilidades necessárias para mergulhar no módulo, caso de borda ou ponto de integração exato que importa agora. O agente fornece o detalhe exaustivo sempre que você pergunta.
Isso desloca o papel humano de "Devo entender tudo o tempo todo" para "Sei como navegar, questionar e validar na altitude certa." Essa é a verdadeira habilidade da engenharia agentiva.
