Cada unidade de trabalho
deve tornar a próxima mais fácil.
Compound Engineering é a filosofia que a Every desenvolveu construindo a Cora do zero. Em vez de acumular dívida técnica, cada ciclo de trabalho ensina algo ao sistema, e o desenvolvimento fica progressivamente mais rápido. Este guia cobre tudo: filosofia, loop, estágios de adoção, plugin, skills e o playbook completo.
O que é Compound Engineering
Compound engineering nasceu enquanto a Every construía a Cora, uma "AI chief of staff" para a sua caixa de entrada. Testando padrões, agentes e workflows em muitos pull requests, hacks pessoais de produtividade evoluíram para uma abordagem sistemática de desenvolvimento assistido por IA.
🏗️ O problema que ela resolve
Na engenharia tradicional, cada feature nova injeta complexidade: depois de anos, cada funcionalidade vira uma negociação com as antigas. O código fica mais difícil de entender, modificar e confiar, e times passam mais tempo brigando com o sistema do que construindo sobre ele.
🔄 A virada do compound
No compound engineering, features não somam fragilidade: elas ensinam capacidades novas ao sistema. Bug fixes eliminam categorias inteiras de bugs futuros. Padrões codificados viram ferramentas. Com o tempo, o codebase fica mais fácil de entender, modificar e confiar.
A prova: a Every roda cinco produtos (Cora, Monologue, Sparkle, Spiral e o site Every.to) com times de engenharia essencialmente de uma pessoa. O sistema que torna isso possível é o loop de quatro passos do compound engineering.
A filosofia central
"Cada unidade de trabalho de engenharia deve tornar as unidades subsequentes mais fáceis, e não mais difíceis." Todo o resto deriva dessa única frase.
Retorno composto
Uma hora criando um agente de review economiza dez horas de review ao longo do ano. Melhorias de sistema aceleram o trabalho progressivamente. Trabalho de feature, sozinho, não.
Ensinar > fazer
Tempo gasto dando contexto aos agentes paga dividendos exponenciais. Tempo gasto digitando código resolve apenas a tarefa que está na sua frente.
Ship mais, digite menos
Sua produção deve ser medida pelo número de problemas resolvidos, não pelo número de teclas pressionadas.
Isso vai além de engenharia. Os princípios se aplicam a design, pesquisa e até escrita: qualquer disciplina em que codificar gosto e contexto torna o trabalho futuro mais rápido. Os passos são sempre os mesmos: planejar, executar, revisar, compor.
O loop principal
Plan → Work → Review → Compound → Repeat. Os três primeiros passos são familiares para qualquer dev. É o quarto que separa compound engineering do resto: é nele que os ganhos se acumulam. Pule-o e você fez apenas engenharia tradicional com ajuda de IA.
O loop funciona igual para corrigir um bug em cinco minutos ou construir uma feature ao longo de dias. Você só gasta mais ou menos tempo em cada passo. Clique em cada etapa para explorar:
A regra 80/20 do tempo
Planning e review devem consumir 80% do tempo do engenheiro; work e compound, os outros 20%. Ou seja: a maior parte do pensamento acontece antes e depois de o código ser escrito. E olhando para o escopo total do trabalho, a Every sugere a regra 50/50: metade do tempo construindo features, metade melhorando o sistema.
Plans are the new code. O documento de plano é agora o artefato mais importante que você produz. Em vez de codar primeiro e documentar depois, comece pelo plano: ele vira a fonte de verdade que os agentes usam para gerar, testar e validar código. Consertar ideias no papel é muito mais barato do que consertar código depois.
Os 8 princípios fundamentais
As crenças que sustentam essa nova abordagem de desenvolvimento de software:
Toda unidade de trabalho facilita a próxima
Código, documentação e ferramentas devem se apoiar uns nos outros e tornar o trabalho futuro mais rápido, nunca mais lento.
Gosto pertence ao sistema, não ao review
Embuta seu julgamento em configuração, schemas e checks automatizados. Se não fizer isso, gastará tempo conferindo manualmente, o que não escala.
Ensine o sistema, não faça o trabalho
Tempo dando contexto aos agentes paga dividendos exponenciais; tempo digitando código resolve apenas a tarefa imediata.
Construa redes de segurança, não processos de review
Confiança no trabalho com IA vem de infraestrutura de verificação, não de gatekeeping manual a cada passo.
Torne o ambiente agent-native
Estruture projetos para que agentes de IA possam navegar e modificá-los autonomamente.
Pensamento composto em tudo
Todo artefato (código, docs, testes, prompts) deve fazer a próxima iteração andar mais rápido.
Abrace o desconforto de soltar
Delegar para IA exige aceitar resultados imperfeitos que escalam, em vez de resultados perfeitos que não escalam.
Shipe mais valor, digite menos código
Sua saída é medida por problemas resolvidos, não por teclas pressionadas.
Crenças para abandonar
Fomos treinados para acreditar em certas coisas sobre desenvolvimento de software. Com a evolução das ferramentas de IA, algumas dessas crenças viraram obstáculos. Clique em cada uma para entender por que abandoná-la:
O requisito real do seu trabalho como engenheiro é escrever código bom: código manutenível que resolve o problema certo. Quem digita (humano ou agente) não importa.
Review manual linha a linha é um método para chegar a código de qualidade, mas sistemas automatizados que pegam os mesmos problemas também são. Se você não confia nos resultados, conserte o sistema em vez de compensar fazendo tudo sozinho.
Quando a IA pesquisa abordagens, analisa trade-offs e recomenda opções, o trabalho do engenheiro passa a ser adicionar taste: saber qual solução se encaixa neste codebase, neste time e neste contexto.
Um sistema que produz código vale mais do que qualquer peça individual de código. Uma implementação brilhante isolada importa menos que um processo que produz implementações boas consistentemente.
O trabalho do dev é entregar valor. Código é só um insumo: planejar, revisar e ensinar o sistema também contam. Compound engineers eficientes escrevem menos código do que antes e entregam mais.
Primeiras tentativas têm uma taxa de lixo de ~95%; segundas, ~50%. Isso não é falha, é o processo. Mire na perfeição já na primeira tentativa, mas foque em iterar rápido o suficiente para a terceira tentativa acertar em menos tempo que a primeira levou.
O código nunca foi realmente seu: pertence ao time, ao produto e aos usuários. Desapegar é libertador: você aceita feedback melhor, refatora sem hesitar e pula as discussões sobre se o código "está bom o suficiente".
Entendimento importa mais que memória muscular. Você aprende revisando, pegando erros e sabendo quando a IA está errada. O dev que revisa dez implementações de IA entende mais padrões do que quem digitou duas à mão.
Crença para adotar — extraia seu taste para o sistema: o taste do time costuma viver na cabeça dos engenheiros seniores. Documente preferências em CLAUDE.md ou AGENTS.md para o agente ler a cada sessão, crie agentes especializados e skills que reflitam seu estilo, e aponte o agente para seus guias de estilo e registros de decisão. Quando a IA entende como você gosta de escrever código, ela produz código que você aprova, não código que você precisa consertar.
Os 6 estágios de adoção
Quanto do processo você deixa a IA assumir depende de onde você está na escada de familiaridade. A maioria dos devs que trava com IA não sabe onde está: ouve falar de sistemas multi-agente, sente-se sobrecarregada e tenta pular etapas. Pular estágios não funciona — cada degrau constrói os modelos mentais e hábitos do próximo. Descubra onde você está e evolua a partir daí:
As 3 perguntas de ouro
Mesmo sem um sistema multi-agente sofisticado, você captura grande parte do benefício fazendo estas três perguntas antes de aprovar qualquer output de IA:
Força a IA a revelar onde estão as partes traiçoeiras e onde ela precisou fazer julgamentos.
Mostra as opções consideradas e ajuda a pegar escolhas ruins.
Faz a IA admitir onde pode estar errada. LLMs sabem onde estão suas fraquezas, mas você precisa perguntar.
O plugin oficial
O workflow completo do compound engineering é distribuído como um plugin open source (licença MIT), mantido por @kieranklaassen e @tmchow. São 33 skills cujos workflows principais despacham subagentes especialistas sob demanda para pesquisa, review, planejamento e implementação, o que mantém tudo portátil entre as diferentes ferramentas. O projeto é deliberadamente opinativo: a direção reflete um ponto de vista específico sobre como a engenharia assistida por IA deve funcionar.
skills no inventário completo
agentes especialistas de review em paralelo
ferramentas suportadas oficialmente
Instalação
# Claude Code claude /plugin marketplace add EveryInc/compound-engineering-plugin claude /plugin install compound-engineering
Já instalou antes? O plugin migrou para um layout root-native: atualize o marketplace primeiro (/plugin marketplace update compound-engineering-plugin) e depois rode /plugin update — rodar só o update mantém você na versão antiga.
# No chat do Cursor Agent /add-plugin compound-engineering # ou busque por "compound engineering" no marketplace de plugins
# Codex CLI: registre o marketplace e instale o plugin codex plugin marketplace add EveryInc/compound-engineering-plugin codex plugin add compound-engineering@compound-engineering-plugin
No Codex App: abra Plugins na sidebar → Add marketplace com source EveryInc/compound-engineering-plugin, ref main, depois instale e reinicie. A instalação é auto-contida: reviewers e pesquisa vivem dentro das skills como assets de prompt.
# Copilot CLI /plugin marketplace add EveryInc/compound-engineering-plugin /plugin install compound-engineering@compound-engineering-plugin # ou via shell com o binário copilot copilot plugin marketplace add EveryInc/compound-engineering-plugin copilot plugin install compound-engineering@compound-engineering-plugin
No VS Code: Chat: Install Plugin from Source na paleta de comandos, usando o repositório EveryInc/compound-engineering-plugin.
# opencode.json (global ou do projeto) { "plugin": ["compound-engineering@git+https://github.com/EveryInc/compound-engineering-plugin.git"] } # reinicie o OpenCode depois de alterar a config
# Kimi Code CLI (o repo tem manifest nativo .kimi-plugin) /plugins install https://github.com/EveryInc/compound-engineering-plugin # depois rode /reload ou inicie uma nova sessão
# Antigravity CLI (agy), sucessor do Gemini CLI agy plugin install https://github.com/EveryInc/compound-engineering-plugin agy plugin list
| Ferramenta | Instalação |
|---|---|
| Cline | ./.cline/scripts/install-skills.sh --global + ativar Skills nas configurações |
| Grok Build CLI | grok plugin install EveryInc/compound-engineering-plugin |
| Devin CLI | devin plugins install EveryInc/compound-engineering-plugin |
| Factory Droid | droid plugin marketplace add <repo> + droid plugin install compound-engineering@compound-engineering-plugin |
| Qwen Code | qwen extensions install EveryInc/compound-engineering-plugin:compound-engineering |
| Pi | pi install git:github.com/EveryInc/compound-engineering-plugin (+ pi-subagents para workflows com subagentes) |
| oh-my-pi (omp) | omp plugin marketplace add EveryInc/compound-engineering-plugin + omp plugin install compound-engineering@compound-engineering-plugin |
Não precisa de Bun para instalar: ele é necessário apenas para desenvolvimento do repositório e manutenção do conversor.
Depois de instalar
# em qualquer projeto: /ce-setup # reporta capacidades de ferramentas disponíveis, cria .compound-engineering/config.yaml # quando ausente, atualiza o exemplo commitado e adiciona override local ao .gitignore
Onde as coisas vivem
CLAUDE.md é o arquivo mais importante: quando algo der errado, adicione uma nota ali para o agente aprender. docs/solutions/ constrói seu conhecimento institucional — cada problema resolvido vira documentação pesquisável que sessões futuras encontram automaticamente. E todos/ organiza os achados de review por prioridade e status.
Skills e comandos essenciais
O loop central na versão atual do plugin tem seis passos: brainstorm → plan → work → simplify → review → compound. Cada ciclo compõe: /ce-compound escreve aprendizados que o próximo /ce-brainstorm e /ce-plan leem como grounding. A seta de retorno é o ponto todo.
| Skill | Papel no loop |
|---|---|
| /ce-brainstorm core | Q&A interativo para pensar uma feature ou problema e escrever um doc de requisitos unificado, antes do planejamento |
| /ce-plan core | Enriquece ideias ou docs de requisitos em planos prontos para implementação. Dispara três agentes de pesquisa em paralelo (codebase, docs do framework, melhores práticas) e mescla tudo num plano estruturado |
| /ce-work core | Executa planos prontos, nativamente ou via autor cross-model qualificado, mantendo verificação, commits e shipping no host |
| /ce-simplify-code core | Refina o código recém-escrito para clareza e reuso antes do review |
| /ce-code-review core | Review multi-agente report-only contra o plano, antes do merge; aplicação local é explícita. Há também /ce-doc-review para documentos |
| /ce-compound core | Captura o aprendizado em docs/solutions/ para o próximo loop começar mais inteligente |
| /lfg | Workflow autônomo completo: descreva a feature e o agente planeja, trabalha, simplifica, revisa, aplica fixes, roda testes de browser e abre o PR. Pausa para aprovação do plano e depois roda hands-off |
| /ce-debug | Para bugs em vez de features: reproduz, traça causa raiz, corrige e prepara o fix para PR |
| /ce-ideate | Quando você ainda não sabe o que construir: pesquisa (codebase, aprendizados passados, prior art, issues abertas) e entrega ideias ranqueadas e fundamentadas |
| /ce-strategy | Cria e mantém o STRATEGY.md, lido como grounding por ideate, brainstorm e plan |
| /ce-product-pulse | Relatório com janela de tempo sobre o que usuários realmente experimentaram (uso, performance, erros) |
| /ce-pov | Veredito decisivo e fundamentado sobre adoção, documento ou conjunto de abordagens |
| /ce-explain | Transforma conceito, diff ou "o que fiz essa semana?" em documento visual denso e auto-contido |
| /ce-dogfood | QA hands-off no browser do diff da branch ativa, com correções autônomas |
| /ce-babysit-pr | Monitora um PR aberto e o mantém avançando rumo ao merge, reagindo a comentários de review e CI conforme chegam |
O catálogo completo tem 33 skills, incluindo /ce-commit, /ce-worktree, /ce-prototype, /ce-polish, /ce-test-browser, /ce-handoff, /ce-compound-refresh, /ce-sweep e mais.
Exemplo: o loop padrão na prática
# transforme uma ideia vaga em código revisado e shippado /ce-brainstorm tornar os retries de background job mais seguros /ce-plan /ce-work /ce-simplify-code /ce-code-review /ce-compound
# ou o modo autônomo: descreva a feature, aprove o plano, volte para um PR aberto /ce-brainstorm descreva a feature aqui /lfg
/lfg é o piloto automático: ele roda o loop hands-off — planeja, executa, simplifica, revisa e aplica fixes, roda testes de browser e, se houver remote, abre o PR e acompanha o CI com um loop de reparo limitado (não faz merge sozinho). Rode-o depois do /ce-brainstorm para que planeje contra requisitos reais, não contra um prompt de uma linha.
Review multi-agente
O passo de review dispara mais de 14 agentes especializados em paralelo, cada um focado num domínio específico. Tudo é combinado numa única lista priorizada de achados. Os achados recebem prioridade:
P1 · CRÍTICO precisa corrigir P2 · IMPORTANTE deveria corrigir P3 · MENOR legal corrigir
um PR dispara 14+ agentes especialistas em paralelo
🛡️ Segurança
security-sentinel — varre o top 10 OWASP, ataques de injeção, falhas de autenticação e bypasses de autorização.
⚡ Performance
performance-oracle — detecta queries N+1, índices ausentes, oportunidades de cache e gargalos algorítmicos.
🏛️ Arquitetura
architecture-strategist avalia decisões de design, limites de componentes e direção de dependências. pattern-recognition-specialist identifica padrões, anti-padrões e code smells.
🗄️ Dados
data-integrity-guardian valida migrations, limites de transação e integridade referencial. data-migration-expert checa mapeamento de IDs, segurança de rollback e validação em produção.
✨ Qualidade
code-simplicity-reviewer (YAGNI, complexidade desnecessária) + reviewers específicos: Rails (duas escolas: DHH e Kieran), Python (PEP 8, type hints) e TypeScript (type safety, clean architecture).
🚀 Deploy & Frontend
deployment-verification-agent gera checklists pré/pós-deploy e planos de rollback. julik-frontend-races-reviewer detecta race conditions em JS/Stimulus. agent-native-reviewer garante que features sejam acessíveis a agentes, não só a humanos.
Resolução automatizada: o comando de resolução processa todos os achados automaticamente — P1 primeiro, depois P2, cada fix em isolamento para um não pisar no outro. No final você ainda revisa manualmente os fixes gerados. O /triage apresenta cada achado para decisão humana: aprovar, pular ou customizar.
Ambiente agent-native
Arquitetura agent-native significa dar ao agente as mesmas capacidades que você tem. Se o agente não roda testes, você tem que rodar. Se não vê logs, você tem que debuggar. Toda capacidade que você nega à IA vira uma tarefa sua. A meta: paridade ambiental total entre devs humanos e de IA.
Checklist de capacidades
Marque o que seu agente já consegue fazer hoje (clique para marcar):
- Rodar a aplicação localmente
- Rodar a suíte de testes
- Rodar linters e type checkers
- Rodar migrations e seedar dados de dev
- Criar branches, commits e push para o remote
- Criar pull requests e ler comentários de PR
- Ver logs locais e de produção (read-only)
- Tirar screenshots da UI
- Inspecionar network requests
- Acessar error tracking (Sentry, etc.)
Os 4 níveis de maturidade agent-native
Básico
Acesso a arquivos, testes e git commits. A base que destrava o compound engineering.
Local completo
Browser, logs locais e criação de PRs. Habilita os estágios 3-4 da escada.
Visibilidade de produção
Logs de produção (read-only), error tracking e dashboards. O agente debuga proativamente.
Integração total
Ticket systems, deploy e serviços externos. Habilita o estágio 5 (execução paralela em cloud).
Agent-native também é um mindset. Ao construir features, pergunte: "como o agente vai interagir com isso?". Ao debugar: "o que o agente precisaria ver?". Ao documentar: "o agente vai entender isso?".
Skip permissions
Por padrão o Claude Code pede permissão antes de cada ação. A flag --dangerously-skip-permissions desliga esses prompts — o nome é propositalmente assustador para fazer você pensar antes de usar. Mas no estágio 3+, os pedidos constantes de permissão matam o flow.
✅ Quando usar
- Você confia no processo: tem um bom plano e bons sistemas de review
- Você está num ambiente seguro (sandbox, nada que afete usuários reais)
- Você quer velocidade: os pedidos de permissão quebram o flow
❌ Quando NÃO usar
- Você está aprendendo: os prompts ajudam a entender o que acontece
- Você está em produção: nunca, porque toca usuários reais
- Você não tem bom rollback: se não consegue desfazer fácil, mantenha os prompts
Segurança sem prompts
🔀 Git é a rede de segurança
Tudo que o agente faz está no git. git reset --hard HEAD~1 e você voltou.
🧪 Testes pegam erros
Antes do merge, rode os testes. Se o agente quebrou algo, eles capturam.
👀 Review antes do merge
Skip permissions pula prompts de implementação, não o review final do PR.
🌲 Worktrees isolam risco
Trabalho arriscado acontece num diretório isolado via git worktrees.
O cálculo de produtividade: sem skip permissions, um prompt a cada 30 segundos, cada um exigindo um "y" e perdendo foco — multiplicado centenas de vezes por sessão. Com skip permissions, você mantém o flow state e desbloqueia iteração 5-10x mais rápida, e o tempo economizado pode superar dramaticamente o risco de ocasionalmente reverter algo.
Vibe coding
Vibe coding é para quem não se importa com o código em si — quer resultados. Pode ser um PM prototipando ideias, um designer testando uma interação ou um projeto pessoal que você nunca vai olhar de novo. A filosofia: pular a escada e ir direto ao estágio 4 — descrever o que quer e deixar os agentes construírem.
Perfeito para
- Projetos pessoais
- Protótipos e experimentos
- Investigações "isso funciona?"
- Ferramentas internas
- Exploração de UX
Ruim para
- Sistemas em produção com usuários
- Código que outros vão manter
- Apps sensíveis a segurança
- Sistemas críticos de performance
O paradoxo do vibe coding: ele pode melhorar seu planejamento. Quando você não sabe o que construir, gere protótipos, compartilhe com usuários, colete feedback, clique neles. Depois delete tudo e comece de novo com um plano de verdade. A divisão ótima: vibe code para descobrir o que quer, spec para construir direito. O spec sempre vence na implementação final, mas o vibe coding acelera a descoberta.
# sessão de exemplo: descrever → esperar → testar → corrigir → ship Você: /lfg quero um site onde colo um link do YouTube e ele extrai a transcrição ... agente trabalha por alguns minutos ... Você: funciona, mas o texto está difícil de ler. aumenta a fonte. ... agente corrige ... Você: perfeito. ship it.
Design workflow
Design é mais fácil de iterar em código do que em mockups — dá para clicar e sentir as interações. Mas você não quer experimentar no codebase de produção. O fluxo: prototipar em projetos descartáveis, testar com usuários e capturar o gosto de design para a IA replicar.
A abordagem "baby app"
O workflow
- Crie um repo de protótipo: mkdir baby-myapp
- Vibe-code o design sem medo
- Itere até ficar bom: "mais espaço, toggle mais proeminente"
- Capture o design system: cores, espaçamento, tipografia, padrões
- Transfira para o app principal usando o protótipo como referência
Loop de descoberta UX
Quando não sabe o que construir: peça cinco versões diferentes de uma tela, clique em cada uma, compartilhe com usuários ("esse fluxo te confundiria?"), colete feedback em protótipos funcionais (diferente de um mockup Figma, dá para clicar) e depois delete tudo e recomece com um plano de verdade. O protótipo serve para aprender, não para shipar.
Trabalhando com designers
| Fluxo tradicional | Fluxo compound | |
|---|---|---|
| Processo | Designer cria mockup → dev interpreta e constrói → designer diz "não está bem assim" → idas e vindas até talvez casar | Designer cria mockup no Figma → você roda /plan com o link → a IA constrói → o agente figma-design-sync confere contra o mockup → designer revisa a versão ao vivo, não screenshot → itera até ficar perfeito |
| Gosto | Vive na cabeça do designer | Codificado numa skill (cores, espaçamento, padrões). A IA produz designs que casam com o gosto do designer, mesmo sem ele envolvido |
Agentes de design: design-iterator tira screenshot do design atual, analisa o que não funciona, melhora e repete. figma-design-sync puxa o design do Figma, compara com o que foi construído e corrige diferenças automaticamente. design-implementation-reviewer confere se a implementação casa com as specs do Figma antes de chegar aos usuários.
Colaboração em times
Quando a IA cuida da implementação, a dinâmica do time muda. São necessários novos acordos: quem aprova planos, quem é dono dos PRs e o que humanos revisam quando agentes já fizeram a primeira passada.
Fluxo tradicional
Pessoa A escreve código → Pessoa B revisa → discussão nos comentários do PR → merge após aprovação.
Fluxo compound
Pessoa A cria o plano → IA implementa → agentes de IA revisam → Pessoa B revisa o review da IA → merge com aprovação humana.
✅ Aprovação de plano
Ler um plano e concordar é uma decisão. Silêncio não é aprovação — é ausência de decisão. Exija sign-off explícito antes da implementação: comentário, tag no commit ou outro marcador.
👤 Dono do PR
Quem iniciou o trabalho é dono do PR, independentemente de quem (ou o quê) escreveu o código. Você responde pela qualidade do plano, pelo review, pelos fixes e pelo impacto pós-merge.
🎯 Foco do review humano
Quando agentes já analisaram o PR, humanos focam em intenção, não implementação: casa com o combinado? a abordagem faz sentido? há problemas de lógica de negócio? Erros de sintaxe, segurança e performance já são dos agentes.
Padrões de comunicação e escala
📬 Assíncrono por padrão
Planos podem ser criados, revisados e aprovados sem reunião. Em vez de "vamos marcar para discutir", tente "criei o plano — comentem até o fim do dia". Handoffs explícitos: status, o que foi feito, o que falta, contexto e como continuar.
🚩 Flags + PRs pequenos
Todo mundo shipando mais rápido = mais conflitos de merge. Shipe pedaços pequenos, use feature flags, mergue na main com frequência e resolva conflitos na hora. E cada feature grande tem um dono único, que atualiza o time assincronamente.
Compound docs = conhecimento tribal. Você não deveria precisar perguntar a um colega algo que poderia estar embutido no sistema. Em vez de "pergunta pra Sarah, ela sabe como o auth funciona", a Sarah roda /compound depois de implementar. A solução fica documentada e qualquer um encontra.
Pesquisa de usuários que a IA usa
Estruture a pesquisa para a IA conseguir usá-la. Notas cruas de entrevista são difíceis de aproveitar: insights precisam de citação, implicação e confiança.
O abismo pesquisa ↔ desenvolvimento
Tradicional: pesquisador entrevista → escreve relatório → relatório mofa no Drive → dev constrói sem ler → feature não casa com a necessidade do usuário.
Compound: pesquisa gera insights estruturados → insights viram contexto de planejamento → IA referencia insights ao planejar → features são informadas pela pesquisa → dados de uso validam os insights → insights compõem.
Insight estruturado
# research/interviews/user-123.md ### Insight: ritual matinal de dashboard Quote: "Primeira coisa de manhã, procuro bandeiras vermelhas." Implicação: dashboard precisa surfacar problemas rápido. Confiança: 4/5 participantes
Personas referenciáveis + planejamento informado
Crie documentos de persona (objetivos, frustrações, citações) que a IA pode referenciar e alimente os planos com contexto de pesquisa:
/ce-plan adicionar exportação agendada Contexto de pesquisa: - 3/5 usuários entrevistados mencionaram exportação semanal - a persona marketing-manager exporta toda sexta - dor atual: processo manual de exportação Desenhar para: exports semanais automáticos por e-mail
Extração de padrões de dados
Seus usuários já estão dizendo o que construir pela forma como usam o produto. Cada clique é uma pista. Você só precisa prestar atenção:
🔥 Uso intenso
Features usadas muito mais do que o esperado; usuários voltando à mesma página repetidamente. Sinal de que ali mora valor (ou dependência).
😤 Struggle
Tempo de permanência alto em páginas simples; tentativas repetidas da mesma ação; loops de erro → retry → erro.
🛠️ Workaround
Usuários inventando soluções porque o produto não faz o que precisam: exportar de um lugar e importar em outro, copiar-e-colar entre telas, várias abas abertas para comparar.
🚪 Abandono
Onde usuários desistem nos fluxos: features começadas mas não completadas.
De padrão a feature: você percebe usuários copiando dados de uma tabela e colando em outra 50 vezes por semana → insight: precisam de automação entre tabelas → feature: botão "sincronizar com tabela B". Ou percebe usuários criando projetos "template" e duplicando-os → insight: querem templates → feature: suporte de templates de primeira classe.
Copywriting
A maioria dos times trata copy como pensamento tardio — algo para preencher depois que a feature está pronta. Mas copy é parte da experiência do usuário e merece a mesma atenção que o código.
📋 Copy no plano
Inclua a copy no plano desde o início: assunto de e-mail, mensagem de sucesso, mensagens de erro. Quando a IA implementa, a copy já está lá.
🗣️ Codifique sua voz
Crie uma skill definindo princípios ("fale como humano, não robô"; "erros devem ajudar, não culpar") e palavras a evitar ("inválido" → "não funcionou"; "com sucesso" → diga o que aconteceu).
🔎 Revise copy como código
Adicione um agente copy-reviewer ao processo: clareza (um usuário não-técnico entende?), utilidade, tom (casa com o guia de voz?) e consistência com textos similares.
Marketing de produto
Parabéns, você shippou algo. Agora conte ao mundo: o mesmo sistema que constrói features pode anunciá-las. Release notes geradas do plano, posts sociais, screenshots automáticos — tudo flui de um único lugar, nada precisa de handoff e nada escapa.
| Passo do fluxo compound |
|---|
| 1 · O engenheiro cria um plano que inclui a proposta de valor do produto |
| 2 · A IA implementa a feature |
| 3 · A IA gera release notes a partir do plano (benefício do usuário primeiro, um exemplo concreto, breaking changes, menos de 200 palavras) |
| 4 · A IA gera posts sociais a partir das release notes |
| 5 · A IA gera screenshots com Playwright — sem pedir para engenharia, nunca desatualizadas |
| 6 · O engenheiro revisa e shipa tudo junto. Para várias features, /changelog lê os merges recentes e gera o changelog |
Vibe coding vs. engenharia com IA
O compound engineering é a resposta estruturada ao risco do "vibe coding": código que parece funcionar, mas não é sustentável. Veja o contraste:
| Vibe Coding | AI Engineering / Compound | |
|---|---|---|
| Entrada | Prompt vago → código "parece ok" | Spec clara + critérios de aceite |
| Processo | Sem spec, sem testes, sem review | Agente executa com contexto do repositório |
| Resultado | Funciona na demo, quebra em produção | Review humano + testes |
| Dívida | Débito técnico cresce a cada PR | Aprendizados documentados (compounding) |
A síntese: vibe coding é ótimo para prototipagem rápida; engenharia com IA é o que escala em produção. Times que dominam agentes entregam funcionalidades em horas em vez de semanas, mas velocidade sem processo vira débito técnico rapidamente. A pergunta relevante hoje não é mais "você usa IA?", e sim "você sabe orquestrar IA?".
Spec-driven & o stack de 2026
O compound engineering conversa diretamente com outra tendência: o Spec-Driven Development, em que a especificação vira um contrato executável antes de qualquer linha de código. O fluxo típico: Constitution (AGENTS.md) → SPEC.md → TASKS.md → Código + PR — que é exatamente o espírito do /ce-brainstorm → /ce-plan → /ce-work.
Mapa de ferramentas
| Categoria | Exemplos | Quando usar |
|---|---|---|
| IDE AI-first | Cursor, Windsurf, Kiro | Dia a dia no editor, plan + agent |
| Terminal agent | Claude Code, Codex CLI, Aider | Refactors grandes, multi-arquivo, CI |
| Inline / PR | GitHub Copilot | Autocomplete + review no PR |
| Cloud agent | Devin, Jules, Codex Cloud | Tarefas longas, tickets, PRs remotos |
| Chat / pesquisa | Claude, ChatGPT, Gemini | Design, trade-offs, aprendizado |
Stack recomendado (referência 2026)
| Camada | Sugestão | Por quê |
|---|---|---|
| IDE principal | Cursor | Plan + Agent + rules + MCP |
| Terminal agent | Claude Code | Tarefas longas, plugins de Compound Engineering |
| Chat / design | Claude ou ChatGPT | Trade-offs e especificações |
| PR / CI | Copilot + checks automáticos | Review integrado ao fluxo do GitHub |
| Contexto | AGENTS.md + rules | Base do compounding no repositório |
Checklist do dia a dia
- AGENTS.md / CLAUDE.md atualizado no repositório
- Regras específicas para pontos sensíveis (autenticação, billing, banco de dados)
- Plan mode usado antes de features grandes
- Testes e typecheck rodados pelo agente
- Diff sempre lido antes do commit
- Aprendizados documentados (compounding)
- Nenhum segredo presente no histórico do chat
Quando não usar IA
Melhor manualmente
- Decisões arquiteturais críticas sem critérios definidos
- Hotfixes pequenos que você já entende completamente
- Código sujeito a regulação com accountability humana exigida
- Aprender um fundamento pela primeira vez
Perfeito com IA
- Boilerplate, testes e migrations
- Explorar uma base de código desconhecida
- Refatorações mecânicas cobertas por testes
- Rascunhos de descrição de PR e documentação
Fontes
Este guia foi compilado a partir de:
- Compound Engineering: The AI-native engineering philosophy — guia completo de Kieran Klaassen na Every
- EveryInc/compound-engineering-plugin — plugin oficial no GitHub (MIT, 24k+ stars)
- Documento interno: Técnicas de Programação com IA: Compound Engineering, Spec-Driven Development e o Stack de 2026