Compound Engineering: filosofia de engenharia nativa de IA

• Uma metodologia de desenvolvimento de software com efeito composto, na qual cada unidade de trabalho de engenharia torna o trabalho seguinte mais fácil, estruturada em torno de um loop de 4 etapas (Planejar → Executar → Revisar → Compor) para sistematizar a colaboração com agentes de IA
• No loop iterativo, 80% do tempo do engenheiro deve ser dedicado a planejamento e revisão, e 20% à execução e composição
• Distribuído em formato de plugin, com 26 agentes especializados, 23 comandos de workflow e 13 skills, podendo ser instalado no Claude Code, OpenCode e Codex
• Apresenta 8 noções convencionais do desenvolvimento de software existente (como “código deve ser escrito à mão” e “cada linha precisa ser revisada manualmente”) como crenças que precisam ser abandonadas, e defende a adoção de novos princípios para codificar preferências no sistema
• Classifica o nível de adoção de IA por desenvolvedores em do estágio 0 (desenvolvimento manual) ao estágio 5 (execução paralela em nuvem), oferecendo um framework abrangente que cobre formas de avançar em cada estágio e se expande para colaboração em equipe, design, pesquisa e marketing

---

Filosofia central

• O princípio central é que cada unidade de trabalho de engenharia deve tornar o trabalho seguinte mais fácil
• Em codebases tradicionais, a complexidade aumenta a cada nova funcionalidade, e depois de 10 anos passa-se mais tempo lutando contra o sistema
• No Compound Engineering, as funcionalidades ensinam novas capacidades ao sistema, correções de bugs eliminam categorias inteiras de bugs futuros, e padrões são convertidos em ferramentas, fazendo com que a codebase fique mais fácil de entender, modificar e confiar com o passar do tempo

Loop principal: Plan → Work → Review → Compound

• Cada time da Every opera 5 produtos (Cora, Monologue, Sparkle, Spiral, Every.to) principalmente como equipes de engenharia de uma pessoa só, e o que torna isso possível é o loop de 4 etapas
• As três primeiras etapas (planejamento, execução, revisão) são comuns, mas o grande diferencial é a 4ª etapa, Compound, onde os ganhos compostos se acumulam
• Seja uma correção de bug de 5 minutos ou o desenvolvimento de uma funcionalidade de vários dias, usa-se o mesmo loop, ajustando apenas o tempo investido em cada etapa

• Etapa 1: Plan (planejamento)

  • Entender os requisitos: identificar o que será feito, por que será feito e quais são as restrições
  • Investigar a codebase: analisar como funcionalidades semelhantes funcionam e quais padrões já existem
  • Pesquisa externa: consultar documentação de frameworks e boas práticas do setor
  • Projetar a solução: definir a abordagem e os arquivos que serão alterados
  • Validar o plano: verificar a completude e a consistência do plano como um todo

• Etapa 2: Work (execução)

  • Configurar um ambiente isolado: separar o trabalho com Git worktree (cópia isolada do repositório) ou branch
  • Executar o plano: o agente implementa passo a passo
  • Executar validações: após cada alteração, rodar testes, linting (verificação automática de código) e checagem de tipos
  • Acompanhar o progresso e ajustar o plano se surgirem problemas
  • Se você confia no plano, não há necessidade de vigiar o código linha por linha

• Etapa 3: Review (revisão)

  • Vários agentes fazem revisão de código em paralelo
  • Os achados são classificados por prioridade em P1 (correção obrigatória), P2 (correção recomendada), P3 (melhoria)
  • O agente corrige os problemas com base no feedback da revisão e valida os resultados
  • Registrar padrões: documentar o que deu errado para evitar recorrência

• Etapa 4: Compound (composição) — a etapa mais importante

  • O desenvolvimento tradicional termina na 3ª etapa, mas é na etapa Compound que as melhorias do sistema se acumulam
  • Se as três primeiras etapas produzem funcionalidades, a 4ª produz um sistema que cria funcionalidades melhor
  • Tarefas executadas:
    • Capturar o que funcionou, o que não funcionou e quais insights podem ser reutilizados
    • Adicionar metadados, tags e categorias com YAML frontmatter para permitir busca
    • Adicionar novos padrões ao CLAUDE.md e, se necessário, criar novos agentes
    • Validar: “na próxima vez, o sistema consegue detectar esse problema automaticamente?”

Estrutura do plugin

• 26 agentes especializados: revisão (14), pesquisa, design, workflow, documentação etc., cada um focado em uma tarefa específica
• 23 comandos de workflow: loop principal + utilitários
• 13 skills: oferecem especialização de domínio, como arquitetura agent-native e guias de estilo
• Pode ser instalado com configuração zero no Claude Code, OpenCode (experimental) e Codex (experimental)

• Estrutura de arquivos

  • CLAUDE.md: o arquivo mais importante, lido pelo agente no início de cada sessão, onde ficam preferências, padrões e contexto do projeto
  • docs/solutions/: problemas resolvidos se acumulam como documentação pesquisável, formando conhecimento institucional (institutional knowledge)
  • docs/brainstorms/: armazena a saída do comando brainstorm
  • docs/plans/: armazena a saída do comando plan
  • todos/: rastreia itens de trabalho por prioridade e status

Comandos principais

• /workflows:brainstorm

  • Comando usado quando ainda não está claro o que deve ser criado
  • Após uma pesquisa leve no repositório, esclarece o objetivo, usuário, restrições e edge cases fazendo perguntas uma a uma
  • A IA sugere uma abordagem, e o resultado é salvo em docs/brainstorms/ para handoff ao /workflows:plan

• /workflows:plan

  • Ao descrever o que deseja, retorna um plano de implementação
  • Executa 3 agentes de pesquisa em paralelo: repo-research-analyst (padrões da codebase), framework-docs-researcher (documentação), best-practices-researcher (padrões do setor)
  • O agente spec-flow-analyzer analisa o fluxo do usuário e os edge cases
  • Ao ativar o modo ultrathink, /deepen-plan é executado automaticamente, acionando mais de 40 agentes de pesquisa em paralelo

• /workflows:work

  • Etapa em que o agente escreve o código de fato
  • 4 fases: quick start (criação de Git worktree e configuração de branch) → execute (implementação por tarefa com rastreamento de progresso) → quality check (aciona opcionalmente mais de 5 agentes revisores) → ship it (executa linting e cria PR)

• /workflows:review

  • Um PR é revisado simultaneamente em paralelo por mais de 14 agentes especializados
  • Inclui segurança (security-sentinel), desempenho (performance-oracle), arquitetura (architecture-strategist), integridade de dados (data-integrity-guardian), qualidade de código (code-simplicity-reviewer), revisores por framework (DHH-rails, Kieran-rails/python/typescript), validação de deploy, race conditions de frontend e revisor agent-native, entre outros
  • A saída é uma lista única priorizada, classificada em P1 (crítico), P2 (importante), P3 (menor)
  • O comando /resolve_pr_parallel corrige automaticamente os achados (P1 primeiro, cada correção executada de forma isolada)
  • Com o comando /triage, é possível filtrar os achados aprovando, pulando ou personalizando um por um

• /workflows:compound

  • Documenta problemas resolvidos para referência futura
  • Aciona 6 subagentes paralelos: context analyzer, solution extractor, related docs finder, prevention strategist, category classifier, documentation writer
  • Gera Markdown pesquisável com YAML frontmatter

• /lfg

  • Ao descrever uma funcionalidade, o agente executa planejamento, implementação e revisão, entregando um PR pronto para merge
  • Encadeia todo o pipeline de plan → deepen-plan → work → review → resolve findings → browser tests → feature video → compound
  • Após a aprovação do plano, executa de forma autônoma com pausa, acionando mais de 50 agentes ao longo de todas as etapas

8 crenças que precisam ser abandonadas

• "Código deve ser escrito à mão"

  • O requisito real é escrever um bom código, de fácil manutenção e que resolva o problema certo; quem faz a digitação não importa

• "Toda linha precisa ser revisada manualmente"

  • A revisão manual linha por linha é apenas uma forma de garantir qualidade, e sistemas automatizados que capturam os mesmos problemas também são válidos
  • Se você não consegue confiar no resultado, não compense fazendo tudo manualmente; é preciso corrigir o sistema

• "A solução precisa vir do engenheiro"

  • Como a IA pode pesquisar abordagens, analisar trade-offs e recomendar opções, o papel do engenheiro é adicionar gosto (taste) — julgar qual solução faz sentido para esta base de código, esta equipe e este contexto

• "Código é o principal entregável"

  • O sistema que produz código tem mais valor do que o código individual
  • Mais importante do que uma implementação excelente é um processo que produz implementações boas de forma consistente

• "Escrever código é a atividade principal"

  • O trabalho do desenvolvedor é entregar valor (ship value), e código é apenas um dos insumos
  • Planejamento, revisão e treinamento do sistema também fazem parte do trabalho

• "A primeira tentativa precisa ser boa"

  • A taxa de falha da primeira tentativa é de 95%, e a da segunda ainda é de 50%
  • Isso não é fracasso, mas sim processo; o foco deve estar em iterações rápidas para que a terceira tentativa fique pronta mais rápido do que a primeira

• "Código é autoexpressão"

  • O código pertence à equipe, ao produto e ao usuário, e, se você não o enxergar como autoexpressão, fica mais fácil aceitar feedback, refatorar e discutir qualidade

• "Quanto mais eu digitar, mais eu aprendo"

  • Hoje, entendimento importa mais do que memória muscular
  • Um desenvolvedor que revisa 10 implementações feitas por IA entende mais padrões do que alguém que digitou 2 delas por conta própria

Desafios psicológicos da transição

• Quando você digita menos, parece que está trabalhando menos: na prática, orientar agentes exige mais pensamento do que implementar
• Ansiedade com execução autônoma: não se trata de abrir mão do controle, mas de codificar o controle em restrições, regras e processos de revisão
• A dúvida "fui eu que fiz isso?": planejar, revisar e garantir padrões de qualidade já são o trabalho em si; a IA apenas executa a escrita

Crenças que devem ser adotadas

• Extrair o gosto para o sistema

  • O gosto do desenvolvedor, como convenções de nomes, padrões de tratamento de erro e abordagens de teste, normalmente não é documentado e fica na cabeça de engenheiros seniores
  • É preciso registrar essas preferências em CLAUDE.md ou AGENTS.md e construir agentes e skills especializados para revisão, testes e deploy, para que a IA produza diretamente código passível de aprovação

• Regra 50/50

  • 50% do tempo de engenharia deve ser alocado ao desenvolvimento de funcionalidades, e 50% à melhoria do sistema
  • Tradicionalmente, a divisão é 90% funcionalidades / 10% resto, mas criar agentes de revisão, documentar padrões e construir geradores de teste é um investimento que facilita funcionalidades futuras
  • Investir 1 hora em um agente de revisão pode economizar 10 horas de revisão ao longo de 1 ano

• Confiar no processo e construir redes de segurança

  • Para que o suporte por IA escale, não dá para humanos revisarem todas as linhas, então o essencial é construir guardrails como testes, revisão automática e monitoramento
  • Se você não consegue confiar no resultado, não volte para a revisão manual; adicione um sistema que torne aquela etapa confiável

• Estruturar o ambiente de forma agent-native

  • Tudo o que um desenvolvedor pode ver ou fazer, o agente também deve poder: executar testes, verificar logs de produção, depurar com screenshots, criar PRs etc.
  • Toda tarefa que não é permitida ao agente precisa ser feita manualmente por você

• Usar paralelização

  • No passado, o gargalo era a atenção humana (uma tarefa por vez), mas o novo gargalo é o compute (quantos agentes podem rodar ao mesmo tempo)
  • Execute vários agentes e várias funcionalidades ao mesmo tempo, com revisão, testes e documentação em paralelo

• Planejamento é o novo código

  • O documento de planejamento agora é o entregável mais importante
  • Em vez de escrever código primeiro e documentar depois, escrever o plano primeiro cria uma source of truth que os agentes podem usar para gerar, testar e validar o código
  • Corrigir ideias no papel é mais barato do que corrigi-las no código

• Resumo dos princípios centrais

  • Cada unidade de trabalho deve tornar o trabalho seguinte mais fácil
  • O gosto deve ser embutido no sistema, não na revisão
  • Em vez de fazer diretamente, ensine o sistema
  • Em vez do processo de revisão, construa redes de segurança
  • Estruture o ambiente de forma agent-native
  • Aplique pensamento de juros compostos em tudo
  • Aceite o desconforto da delegação e escolha resultados imperfeitos, mas escaláveis, em vez de perfeitos, porém impossíveis de escalar
  • Escreva menos código e entregue mais valor
  • Esses princípios podem ir além da engenharia e se expandir para design, pesquisa, escrita e qualquer área em que codificar gosto e contexto ajude

Etapas de crescimento do desenvolvedor (escada de 5 níveis)

• Stage 0: desenvolvimento manual

  • Escrever código linha por linha sem IA, pesquisar em documentação e no Stack Overflow, depurar com print
  • Isso produziu bom software por décadas, mas em 2025 já não é rápido o suficiente

• Stage 1: assistência baseada em chat

  • Fazer perguntas ao ChatGPT, Claude, Cursor etc. para receber snippets de código e copiar e colar o que for útil
  • A IA acelera pesquisa e geração de boilerplate, mas você ainda revisa cada linha diretamente e mantém controle total

• Stage 2: ferramentas agentic + revisão linha por linha

  • Ferramentas agentic como Claude Code, Cursor Composer e Copilot Chat leem arquivos e fazem mudanças diretamente na base de código
  • O papel do desenvolvedor é ser um gatekeeper que aprova ou rejeita tudo o que o agente propõe
  • A maioria dos desenvolvedores fica estagnada neste estágio e não aproveita os benefícios da delegação para IA

• Stage 3: planejamento primeiro, revisão em nível de PR

  • É a etapa em que tudo muda: você coescreve com a IA um plano detalhado com requisitos, abordagem e edge cases
  • Depois do planejamento, a IA implementa sem supervisão, e a saída é revisada como PR
  • É aqui que começa a Compound Engineering — o planejamento, a implementação e a revisão de cada ciclo alimentam o aprendizado do sistema, tornando o próximo ciclo mais rápido e fácil

• Stage 4: ideia → PR (máquina única)

  • Você fornece a ideia, e o agente faz tudo: pesquisa na base de código, planejamento, implementação, testes, auto-revisão, correção de problemas e criação do PR
  • Sua participação se reduz a 3 etapas: dar a ideia, revisar o PR e fazer o merge
  • Ainda assim, tudo roda em um único computador, um de cada vez

• Stage 5: execução paralela na nuvem (múltiplos dispositivos)

  • A execução vai para a nuvem, permitindo execução paralela
  • É possível colocar 3 agentes trabalhando em 3 funcionalidades ao mesmo tempo e revisar quando os PRs ficarem prontos
  • Os agentes podem monitorar feedback e até propor correções por conta própria
  • O papel deixa de ser o de contribuidor individual e passa a ser o de comandar uma frota de agentes

Guia para subir de nível

• 0 → 1: começar a colaborar

  • Escolha uma ferramenta (Cursor with Opus 4.5 ou Claude Code etc.) e use-a todos os dias
  • Antes de escrever código, peça à IA para explicar o código existente e verifique seu nível de entendimento
  • Comece delegando o boilerplate, como testes, arquivos de configuração e funções repetitivas
  • Revise todas as linhas para aprender
  • Trabalho de capitalização composta: registre continuamente os prompts que funcionaram bem

• 1 → 2: permitir acesso ao agente

  • Mude para o modo agentic e dê ao agente permissão de acesso ao sistema de arquivos
  • Comece com mudanças pequenas, em um único arquivo e com um único objetivo, como “adicione testes a esta função”
  • Construa sua intuição de confiança aprovando ou rejeitando cada ação
  • Revise o diff para focar nas partes alteradas
  • Trabalho de capitalização composta: crie um arquivo CLAUDE.md e adicione notas quando o agente errar

• 2 → 3: confiar no plano (mudança central)

  • Escreva requisitos, abordagem e casos de borda em um plano explícito
  • Permita que a IA leia a base de código, encontre padrões e proponha uma abordagem
  • Depois de escrever o plano, deixe a implementação com o agente e saia da frente até ele terminar
  • Faça revisão no nível de PR, não em etapas individuais ou linhas de código
  • Trabalho de capitalização composta: após cada implementação, documente o que o plano deixou passar

• 3 → 4: apresente o resultado, não as instruções

  • Forneça o resultado (outcome), como “adicionar notificação por e-mail para novos comentários”, e deixe o agente decidir como implementar
  • Como o agente conhece a base de código e faz pesquisa, o planejamento também passa a ser responsabilidade dele
  • Revise a abordagem antes da implementação para bloquear cedo direções erradas
  • Trabalho de capitalização composta: construa uma biblioteca de instruções orientadas a resultado que funcionaram bem

• 4 → 5: paralelizar tudo

  • Mova a execução para a nuvem para eliminar gargalos da máquina local
  • Atribua 3 funcionalidades a 3 agentes ao mesmo tempo
  • Organize ideias, bugs e melhorias em uma fila para que os agentes processem em ordem
  • Habilite os agentes a monitorar feedback dos usuários e propor funcionalidades de forma proativa
  • Trabalho de capitalização composta: documente separadamente o que pode ser executado em paralelo e o que é inerentemente serial

3 perguntas antes de aprovar a saída da IA

• “Qual foi a decisão mais difícil aqui?” — induz a IA a revelar as partes difíceis e os pontos de julgamento
• “Quais alternativas você descartou, e por quê?” — verifica as opções consideradas para detectar escolhas erradas
• “Em que parte você está menos confiante?” — faz o LLM admitir suas próprias fraquezas, mas ele só responde se você perguntar diretamente

Arquitetura nativa para agentes

• O ponto central é dar ao agente as mesmas capacidades que um desenvolvedor
• Se o agente não puder executar testes, você terá que executá-los; se não puder ver logs, você terá que depurar diretamente, então toda capacidade não concedida vira trabalho manual

• Checklist nativo para agentes

  • Ambiente de desenvolvimento: executar a aplicação localmente, rodar a suíte de testes, executar linter e verificador de tipos, migrações de banco de dados, seed de dados de desenvolvimento
  • Operações de Git: criar branch, fazer commit, push para o remoto, criar PR, ler comentários do PR
  • Depuração: visualizar logs locais/de produção (somente leitura), capturar screenshots da UI, inspecionar requisições de rede, acessar rastreamento de erros (como Sentry)

• Adoção gradual do modelo nativo para agentes

  • Level 1 (desenvolvimento básico): acesso a arquivos, execução de testes, commits no Git — viabiliza o Compound Engineering básico
  • Level 2 (local completo): acesso ao navegador, logs locais e criação de PR — viabiliza os estágios 3~4
  • Level 3 (visibilidade de produção): logs de produção (somente leitura), rastreamento de erros, dashboards de monitoramento — permite depuração proativa pelo agente
  • Level 4 (integração completa): sistema de tickets, capacidade de deploy, integração com serviços externos — viabiliza o estágio 5

• Mindset nativo para agentes

  • Ao criar uma funcionalidade: “Como o agente vai interagir com isso?”
  • Ao depurar: “O que o agente precisa conseguir ver?”
  • Ao documentar: “O agente consegue entender isso?”

Skip Permissions

• A flag --dangerously-skip-permissions do Claude Code desativa as solicitações de permissão que perguntam a cada ação
• O nome é intencionalmente assustador para levar você a pensar com cuidado antes de usar

• Quando usar

  • Recomendado: quando há um bom sistema de planejamento e revisão, ao trabalhar em ambiente sandbox, quando velocidade é necessária
  • Evitar: durante o aprendizado (as solicitações de permissão ajudam na compreensão), ao trabalhar em código de produção, quando não há mecanismo de rollback

• Mecanismos de segurança ao pular permissões

  • O Git é a rede de segurança: o trabalho do agente fica registrado no Git e pode ser restaurado com git reset --hard HEAD~1
  • Os testes capturam erros: execute testes antes do merge
  • Revisão antes do merge: as permissões podem ser puladas durante a implementação, mas a revisão final é obrigatória
  • Isolamento de risco com Worktree: experimente tarefas arriscadas em diretórios isolados

• Cálculo de produtividade

  • Sem pular permissões, surge um prompt a cada ~30 segundos, e digitar “y” toda vez faz você perder o foco
  • Ao pular permissões, é possível manter o estado de flow, alcançando iterações 5 a 10 vezes mais rápidas e economizando muito mais tempo do que o risco eventual de ter que fazer rollback

Fluxo de trabalho de design

• Abordagem Baby App

  • Crie um projeto descartável (baby app) em que você possa iterar livremente, sem se preocupar com testes, arquitetura ou mudanças incompatíveis
  • Quando o design estiver satisfatório, extraia cores, espaçamento, tipografia e padrões de componentes e transfira para o projeto principal

• Loop de exploração de UX

  • Gere várias versões, compartilhe protótipos funcionais com usuários para coletar feedback por meio de clickthrough
  • Diferente de um mockup no Figma, ele pode realmente ser clicado
  • O protótipo serve para aprendizado e, depois, é reconstruído do zero com um plano adequado

• Colaboração com designers: fluxo Compound

  • Fluxo tradicional: mockup do designer → interpretação do desenvolvedor → iteração de correções
  • Fluxo Compound: mockup no Figma pelo designer → enviar o link do Figma para /plan → implementação pela IA → o agente figma-design-sync verifica se a implementação corresponde ao mockup → o designer revisa a versão ao vivo, não screenshots

• Codificar o gosto de design

  • Trabalhe junto com o designer em algumas funcionalidades e registre em arquivos de skill os padrões descobertos (cores preferidas, layout de formulários etc.)
  • A IA pode produzir designs alinhados ao gosto do designer mesmo sem a presença dele

• Agentes de design

  • design-iterator: analisa screenshots do design atual, itera melhorias e faz refinamento gradual
  • figma-design-sync: traz o design do Figma, compara com a implementação e corrige automaticamente as diferenças
  • design-implementation-reviewer: verifica se a implementação corresponde às especificações do Figma e captura bugs visuais antes de chegarem ao usuário

Vibe Coding

• Uma abordagem para quem só quer o resultado, e não o código em si: gerentes de produto, designers, projetos pessoais etc.
• Pule a escada e vá direto para o estágio 4: descreva o que deseja → o agente cuida de planejamento, código, testes, revisão e PR
• Adequado para: projetos pessoais, protótipos, experimentos, investigar “isso é possível?”, ferramentas internas, exploração de UX
• Não adequado para: sistemas de produção com usuários, código que outras pessoas terão que manter, apps sensíveis à segurança, sistemas críticos de desempenho

• Paradoxo do Vibe Coding

  • O Vibe Coding pode, na verdade, melhorar a capacidade de planejamento
  • Quando você não sabe o que construir, crie um protótipo, colete feedback dos usuários e depois apague tudo e recomece com um plano adequado
  • Distribuição ideal: descobrir com Vibe Coding, construir com especificação — na implementação final, a especificação sempre vence

Colaboração em equipe

• Novas dinâmicas de equipe

  • Tradicional: pessoa A escreve o código → pessoa B faz a revisão → discussão nos comentários do PR → merge após aprovação
  • Compound: pessoa A cria o plano → IA implementa → agente de IA faz a revisão → pessoa B revisa a revisão da IA → merge após aprovação humana

• Padrões da equipe

  • Aprovação do plano: silêncio não é aprovação, então é necessário sign-off explícito antes da implementação
  • Propriedade do PR: independentemente de quem escreveu o código, quem iniciou o trabalho é dono do PR, responsável pela qualidade do plano, revisão, correções e impacto após o merge
  • Foco da revisão humana: em PRs já analisados pelo agente de revisão de IA, humanos revisam com foco na intenção (intent), não em erros de sintaxe, segurança, desempenho ou estilo — “está de acordo com o que foi combinado?”, “a abordagem faz sentido?”, “há problemas na lógica de negócio?”

• Padrões de comunicação

  • Assíncrono por padrão: não há necessidade de reuniões para criar, revisar e aprovar planos, “criei o documento do plano, por favor comentem ainda hoje”
  • Handoff explícito: incluir status, o que foi concluído, trabalho restante, contexto e como continuar

• Padrões de escala

  • Propriedade clara + atualizações assíncronas: para cada funcionalidade principal, uma pessoa é responsável por planejar, monitorar, revisar, fazer merge e atualizar a equipe
  • Feature flag + PRs pequenos: quanto mais rápido todos fazem deploy, mais conflitos de merge aumentam; faça deploy em unidades menores, faça merge na main com frequência e resolva conflitos imediatamente
  • Documentação Compound = conhecimento tácito insuficiente: em vez de “pergunta para a Sarah, ela entende bem de auth”, Sarah executa /compound para documentar a solução, e então qualquer pessoa pode pesquisar

Pesquisa com usuários

• Lacuna entre pesquisa e desenvolvimento

  • Tradicional: pesquisador faz entrevistas → escreve relatório → deixa no Google Drive → desenvolvedor não vê o relatório → funcionalidade não reflete as necessidades do usuário
  • Compound: a pesquisa gera insights estruturados → os insights são usados como contexto do plano → a IA consulta os insights ao planejar → os dados de uso validam os insights → os insights se acumulam de forma composta

• Estruturação da pesquisa

  • Converter notas brutas de entrevistas em Markdown estruturado para uso da IA: incluir informações do participante, principais insights, citações, implicações e nível de confiança (n/5 participantes)

• Documentos de persona

  • Criar documentos de persona com objetivos, frustrações e citações, para que a IA possa consultá-los

• Planejamento com base em pesquisa

  • Ao executar /workflows:plan, incluir contexto de pesquisa (resultados de entrevistas, padrões de persona, pontos de dor atuais) para que os insights de pesquisa se conectem diretamente às funcionalidades

Extração de padrões de dados

• A forma como os usuários usam o produto é uma pista sobre o que deve ser construído

• Tipos de padrão que merecem atenção

  • Padrões de uso excessivo: funcionalidades usadas muito mais do que o esperado, visitas repetidas à mesma página
  • Padrões de dificuldade: tempo de permanência alto em páginas simples, tentativas repetidas da mesma ação, loop de erro → nova tentativa → erro
  • Padrões de contorno: exportar dados de um lugar para importar de novo em outro, copiar e colar entre telas, manter várias abas abertas ao mesmo tempo para comparar
  • Padrões de abandono: abandono dentro de um fluxo, funcionalidades iniciadas mas não concluídas

• Do padrão à funcionalidade

  • Usuários copiam e colam dados entre tabelas 50 vezes por semana → transformar em funcionalidade com botão “sincronizar com a tabela B”
  • Usuários criam projetos “template” e os duplicam → transformar em funcionalidade com suporte nativo a templates

Copywriting

• Incluir copy no plano

  • A maioria das equipes trata a copy como prioridade secundária, preenchida depois que a funcionalidade é construída, mas a copy faz parte da experiência do usuário
  • Se o plano já incluir copy voltada ao usuário, como assunto de e-mail, mensagem de sucesso e mensagem de erro, a copy já estará pronta quando a IA implementar

• Codificar a voz

  • Escrever em um arquivo de skills os princípios (falar como humano, mensagens de erro devem ajudar, frases curtas, palavras claras) e as palavras a evitar (Invalid → didn't work, Error → explicar o que aconteceu etc.)

• Revisão de copy

  • Adicionar revisão de copy ao processo /workflows:review: agente copy-reviewer que analisa com base em 4 critérios: clareza, utilidade, tom e consistência

Marketing de produto

• Fluxo Compound

  • O engenheiro cria um plano com a proposta de valor do produto → a IA implementa a funcionalidade → a IA gera as release notes a partir do plano → a partir das release notes, gera posts para redes sociais → captura screenshots automaticamente com Playwright → o engenheiro revisa e publica tudo junto
  • Como tudo flui em um só lugar, não há necessidade de handoff e não existem lacunas

• Geração de release notes

  • Como a IA tem o plano, as mudanças no código e os testes, ela consegue identificar com precisão o que foi construído
  • Priorizar benefícios para o usuário, incluir 1 exemplo específico, mencionar breaking changes, em até 200 palavras

• Geração de changelog

  • Com o comando /changelog, verificar os merges recentes na main e ler cada plano/PR para gerar um changelog atraente

• Screenshots automáticos

  • Usar Playwright para capturar screenshots de marketing automaticamente, sem precisar pedir screenshots para a engenharia, eliminando o problema de screenshots desatualizados