Em fevereiro de 2025, Andrej Karpathy descreveu "vibe coding" como a prática de descrever a intenção em linguagem natural, aceitando as alterações de um LLM com o mínimo de revisão e deixando 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 haviam avançado e propôs "engenharia agêntica" como seu nome preferido para a prática evoluída de orquestrar agentes, mantendo uma forte supervisão humana sobre a arquitetura e o 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ívida oculta, lacunas de segurança e problemas de mantenibilidade assim que outras pessoas dependem do resultado. A engenharia agêntica mantém a velocidade e o poder dos agentes modernos, mas ancora tudo em uma estrutura clara, artefatos rastreáveis e responsabilidade humana.
O Fluxo de Trabalho da Engenharia Agêntica
Comece com uma intenção inicial 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 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. É aqui também que os diagramas de design residem, como UML (linguagem de modelagem universal), fluxos de código ou interação do usuário, juntamente com links para registros de decisão de arquitetura (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 o comportamento preciso, assinaturas de funções, casos extremos, expectativas de teste e pontos de integração. Usando toda a estrutura como um prompt de contexto de design, instrua a IA a construir uma hierarquia no estilo de tickets com rastreabilidade direta de volta 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 as verificações de validação, implante, observe e atualize os artefatos vivos à medida que os requisitos evoluem.
Exemplo Real: Verificador de Backup Diário
Considere uma ferramenta de CLI de pequena escala e pronta para produção que verifica backups diários do S3 e envia alertas do Slack em caso de falha.
Comece com o objetivo inicial: "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 extremos:
- 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 de 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 tem versão e pode ser vinculada.
O wiki fornece aos leitores futuros o contexto circundante que um documento plano não pode oferecer. 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 de acordo com 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 prossegue então 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 incompleto 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 traz 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 engenharia reversa da base de código.
- A clara separação 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 agêntica é como você canaliza esse mesmo poder conversacional para sistemas nos quais outras pessoas possam 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 um conhecimento amplo em todo o espaço da aplicação, com a capacidade de se aprofundar quando necessário.
Porque você não precisa ter um modelo mental completo e atualizado de como toda a aplicação funciona a qualquer 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 habilidade de saber o que procurar e onde procurar, além da disciplina de continuar fazendo perguntas precisas até entender o item específico em questão. A parte ampla do T te dá o mapa do sistema; o agente de IA suporta as habilidades necessárias para mergulhar no módulo, caso extremo ou ponto de integração exato que importa agora. O agente fornece o detalhamento exaustivo sempre que você perguntar.
Isso muda o papel humano de "Preciso entender tudo o tempo todo" para "Sei navegar, questionar e validar na altitude certa." Essa é a verdadeira habilidade da engenharia agêntica.
