Como uso Linear, Codex, Claude Code e GitHub para lançar experimentos de growth

Um experimento de growth costuma morrer no espaço entre uma boa ideia e um handoff limpo.

A ideia começa afiada: mudar a pergunta do onboarding, testar uma nova promessa na landing page, adicionar um empurrãozinho no lifecycle, apertar o fluxo da demo. Aí ela é copiada para um doc, resumida no Slack, traduzida em tarefas, dividida entre design, dados, engenharia e marketing, e vai perdendo o formato aos poucos. Quando o experimento finalmente vai ao ar, ninguém tem certeza absoluta de qual era a hipótese original.

É aqui que uso Linear, Codex, Claude Code e GitHub juntos.

O Linear não é onde os agents fazem o trabalho. O Linear é onde o trabalho fica organizado. Uso ele para gerenciamento de tarefas e projetos: entrada, escopo, responsabilidade, dependências, critérios de aceite e status.

Os agents fazem a execução. Codex e Claude Code ajudam a programar, revisar, testar e preparar mudanças. O GitHub é onde essas mudanças viram algo concreto: branches, pull requests, CI, review e histórico de merge.

O ponto não é "os agents do Linear rodam o experimento". O ponto é que o Linear mantém o experimento legível enquanto os agents movem a implementação pelo GitHub.

O loop

Meu workflow tem seis estágios:

1. Entrada
2. Brief do experimento
3. Grafo de tarefas
4. Instrumentação
5. QA de lançamento
6. Postmortem

O trabalho do Linear não é tomar a decisão. Ele mantém o raciocínio visível, expõe as peças que faltam e mantém cada artefato conectado à mesma hipótese. Os coding agents trabalham a partir dessa estrutura em vez de prompts soltos.

Estágio 1: Entrada

O loop começa com uma única issue no Linear:

Testar se adicionar uma pergunta de "meta de sono" antes do screener aumenta a taxa de conclusão.

Um sistema fraco transforma isso numa tarefa e perde o contexto.

Uma issue útil no Linear transforma isso em perguntas:

• Para qual segmento é isso?
• Qual métrica define o sucesso?
• É um teste de conversão, de qualificação ou de aprendizado?
• Qual é o efeito mínimo detectável?
• Qual métrica lá na frente poderia piorar?
• Quem precisa aprovar o texto, o tracking de eventos e o lançamento?

O primeiro resultado não é uma lista de tarefas. É um enunciado do problema mais afiado.

Hypothesis:
If we ask users to choose their sleep goal before the screener, completion rate will increase because the flow starts with user motivation instead of clinical qualification.

Primary metric:
Screener completion rate

Guardrail:
Qualified lead rate should not decrease by more than 5%

Decision rule:
Ship if completion improves by 10%+ and guardrail holds.

Isso já muda a qualidade do trabalho. O time não está discutindo um botão ou um campo. Está discutindo um mecanismo.

Estágio 2: Brief do experimento

Crio o brief dentro do Linear e o conecto à issue original.

Mantenho o brief sem graça:

• Contexto
• Hipótese
• Público
• Métrica principal
• Métricas de guardrail
• Eventos necessários
• Variantes
• Responsável
• Revisores
• Checklist de lançamento
• Regra de decisão

Sem graça é bom. Sem graça quer dizer reutilizável.

O truque é que o brief continua vivo. Se a variante muda, quero que a issue deixe o trade-off visível: mudou a hipótese ou só a implementação? Se uma métrica é adicionada, ela é principal ou é guardrail? Se o texto muda, a mensagem ainda mapeia o mecanismo?

O brief vira a espinha dorsal do experimento.

Estágio 3: Grafo de tarefas

A maior parte do acompanhamento de experimentos quebra porque o trabalho é representado como um checklist plano.

Experimentos não são planos. São grafos de dependência.

Para este teste, crio issues conectadas como:

• Escrever o texto da variante
• Desenhar o passo de onboarding
• Implementar a variante no frontend
• Adicionar eventos de analytics
• Configurar o experimento no Statsig
• Fazer QA do disparo dos eventos
• Rascunhar a nota de lançamento
• Monitorar as primeiras 24 horas
• Readout depois do limiar de amostra

Cada issue carrega a parte do brief da qual ela depende.

A issue de analytics tem os nomes dos eventos. A issue de design tem o público e a hipótese. A issue de QA tem as métricas de guardrail. A issue de readout tem a regra de decisão.

Essa é a diferença entre gerenciamento de projetos e memória de workflow.

Como Codex, Claude Code e GitHub se encaixam

O Linear é o sistema de projetos. Codex, Claude Code e GitHub são o loop de execução em volta dele.

Uso o Linear para definir o trabalho: a hipótese, os critérios de aceite, as dependências, o plano de eventos, o checklist de QA e a regra de decisão. Isso dá aos coding agents um objeto estável para trabalhar, em vez de um prompt vago.

O Codex é onde rodo as frentes de implementação. Para um experimento maior, divido o grafo de tarefas em issues estreitas no Linear e deixo cada frente trabalhar na sua própria branch ou worktree. Uma frente pode ligar a variante do frontend. Outra pode adicionar o tracking de eventos. Outra pode apertar o texto, os testes ou a documentação. O importante é que cada frente reporta de volta à mesma estrutura de issues do Linear: o que mudou, o que foi validado, o que está bloqueado e que evidência existe.

O Claude Code é útil quando quero uma segunda superfície de código no terminal: revisar o formato de uma implementação, explorar um repo, rascunhar um plano de migração ou pressionar o código para ver se ele ainda bate com o brief do experimento. Não trato ele como uma fonte de verdade separada. É outra superfície de execução apontada de volta para a mesma issue do Linear.

O GitHub é onde o trabalho se torna revisável e pronto para entrega. Os pull requests anexam o diff do código, o status do CI, screenshots e a discussão da implementação. O Linear guarda o porquê. O GitHub guarda a mudança exata. O loop funciona quando o PR aponta de volta para a issue do Linear e a evidência de validação volta para o Linear.

O workflow fica assim:

Linear issue -> Codex / Claude Code implementation -> GitHub PR -> review + CI -> Linear readout

Essa é a parte que torna o sistema durável. O Linear não substitui o GitHub. O GitHub não substitui o Linear. Codex e Claude Code não substituem o julgamento. Cada ferramenta é dona de uma parte diferente do loop.

Estágio 4: Instrumentação

A instrumentação é onde bons experimentos falham em silêncio.

A issue do Linear carrega o plano de eventos antes da implementação:

Events:
- sleep_goal_step_viewed
- sleep_goal_selected
- screener_started
- screener_completed
- lead_qualified

Properties:
- variant_id
- sleep_goal
- traffic_source
- device_type
- market

Aí cada tarefa de implementação pode ser checada contra o plano:

• O evento foi adicionado?
• A nomenclatura está consistente?
• As propriedades estão disponíveis no momento do disparo?
• O analista consegue segmentar por variante, mercado e device?
• O dashboard bate com a regra de decisão?

Isso não é glamouroso. É exatamente o tipo de detalhe que determina se o experimento gera conhecimento ou só atividade.

Estágio 5: QA de lançamento

Antes do lançamento, mantenho um checklist de QA específico para o experimento, não genérico para o produto.

Para este teste:

• A variante renderiza no mobile e no desktop
• A seleção da meta persiste ao longo do screener
• O caminho existente do screener ainda funciona
• Os eventos disparam na ordem certa
• O bucketing no Statsig está estável
• O dashboard tem as métricas principal e de guardrail
• O responsável pelo rollback está definido
• A nota para o suporte está pronta caso os usuários perguntem sobre o novo passo

A decisão de lançar acontece no mesmo lugar que o trabalho. Não numa ata de reunião. Não numa thread do Slack que será impossível de achar depois.

O Linear vira a fonte de verdade para o estado do experimento.

Estágio 6: Postmortem

O postmortem é onde o loop completo fica mais útil.

A maioria dos times escreve readouts como resumos avulsos:

A variante B melhorou a conclusão em 8%, sem significância estatística. Sem lançamento.

Isso não basta.

Um postmortem útil responde:

• No que a gente acreditava?
• O que aconteceu?
• O que mudou no nosso entendimento do usuário?
• O que devemos testar em seguida?
• Quais issues, docs, eventos, screenshots e dashboards sustentam essa conclusão?

O resultado vira memória reutilizável:

Learning:
Motivation-first onboarding increased early engagement but did not improve qualified completions. Users selected goals, but the added step created drop-off before clinical questions.

Next test:
Move goal selection after screener completion and use it to personalize follow-up copy.

Esse aprendizado não desaparece dentro de um deck. Ele é conectado ao próximo item do backlog.

No que essa stack é boa

O melhor uso dessa stack não é "faça o meu trabalho".

É:

• Manter o contexto anexado às tarefas
• Transformar ideias vagas em briefs estruturados
• Identificar a instrumentação que está faltando
• Criar o grafo de dependência certo
• Preservar as regras de decisão
• Tornar os postmortems reutilizáveis
• Manter o próximo experimento conectado ao último aprendizado
• Deixar os agents programarem, revisarem e validarem contra uma issue clara
• Deixar o GitHub carregar o diff exato, o review, o CI e o histórico de merge

É por isso que o Linear é interessante num workflow de desenvolvimento de produto AI-native. Ele já fica onde o trabalho é negociado. A issue é onde produto, engenharia, design, suporte, vendas e marketing tocam o mesmo objeto.

Se Codex e Claude Code trabalham a partir desse objeto, eles conseguem fazer mais do que gerar código. Eles ajudam a manter a implementação alinhada com a razão pela qual o trabalho existe.

O ponto maior

Times de growth não precisam de mais ideias de experimento. Eles precisam de uma memória melhor de experimentos.

Eles precisam que a hipótese, as tarefas, os eventos, o QA, a decisão e o aprendizado sobrevivam à jornada da ideia até o trabalho entregue.

É esse o loop que eu rodo com Linear, coding agents e GitHub.

Não um checklist mais rápido.

Uma memória melhor de como o time aprende.