LLM Wiki — Synaptic Lattice

ciclo-issue-branch-pr-merge

Properties1
tagsvibe-coding, delivery-cycle, founder, pm

Leitura de 5 min

Ciclo Issue → Branch → PR → Merge

Definition

O ciclo issue → branch → PR → merge é o loop mínimo de qualidade que leva uma issue aprovada até código em produção, com pontos de verificação em cada etapa. A fonte resume a regra em uma máxima: “se não está no GitHub Issues, não é tarefa; se não tem branch, não é mudança; se não tem PR, não foi entregue; se não tem merge, não existe.” Cada etapa filtra um tipo diferente de erro — a issue pega erro de especificação, o diff pequeno pega erro de escopo, os checks automáticos pegam erro técnico, a revisão pega erro de alinhamento, o merge consolida.

Key Points

  • Seis passos, nenhum opcional: issue clara → branch isolada → mudança pequena (um PR não deveria ter dezenas de arquivos) → checks automáticos (lint, teste, build) → revisão do diff → merge.
  • Regra Zero: nenhum agente de IA codifica sem uma issue linkada no GitHub. É descrita na fonte como a regra mais óbvia e, ao mesmo tempo, a mais violada na prática — o padrão de risco é o agente começar a codar direto no chat antes de qualquer issue existir.
  • PRs de agente começam como draft. Três degraus antes do merge: lint estático passa, testes de fronteira passam, revisão humana aprova — subir todos de uma vez é arriscado, subir um de cada vez é seguro.
  • A regra dos 30 segundos: gastar 30 segundos olhando o diff especificamente atrás do que o modelo omitiu ou assumiu errado (casos de erro não tratados, try sem catch, valores hardcoded) — não ler linha por linha.
  • Revisão em duas camadas: o PM/founder valida comportamento e alinhamento com a issue (não lê código); um dev valida implementação, segurança e dívida técnica escondida. Cada revisor foca no que sabe.
  • Checklist de revisão não-técnica em 6 itens, sem exigir leitura de código: fluxo principal funciona, casos positivos/negativos, mensagens de erro claras, visual/design ok, performance básica aceitável, sem regressão.
  • Código de IA não é confiável por padrão — tratado como código de um “estagiário entusiasmado mas inexperiente”. A fonte cita que menos de 25% do código sugerido por agentes é integrado sem modificação, e que uma auditoria da Veracode (2025) encontrou 45% de falhas em testes de segurança básicos em código gerado por IA — ambas as cifras citadas sem link rastreável (confidence: medium).
  • Erros silenciosos são o risco mais caro: modelos preferem que o código “pareça funcionar” a falhar abertamente — supressão de erro (try/catch vazio, validação que ignora o caso de erro) produz resultado incorreto sem alarme. “Business logic mismatch” é a variante mais traiçoeira: o código roda sem erro, mas aplica a regra de negócio errada por ela não ter sido explicitada na issue.
  • Fechamento automático: Closes #N na descrição do PR fecha a issue automaticamente no merge; o board se atualiza sozinho.
  • Dois rituais fecham o ciclo: diário (5 min — escolher uma única issue “Ready” como foco do dia) e semanal (15 min — revisar Blocked, In Review, Done; triagem de backlog; limpeza do AGENTS.md).
  • “Comfortable work” vs. “uncomfortable work”: construir mais automação/template/processo é confortável mas não move o produto; falar com usuário e decidir o que cortar é desconfortável e é o que importa. Gastar mais tempo ajustando o workflow do que entregando valor é sinal de alerta.
  • Automação do ciclo pelo próprio agente (Anthropic, 2026-09): o playbook AI-native SDLC da equipe do Claude Code leva este loop mais adiante — revisão de PR conduzida por IA seguindo um review.md (SOP do tech lead, achados tagueados por path/severidade), hooks que bloqueiam ações perigosas (tocar banco de produção, escrever credenciais, editar arquivos proibidos), deploy headless (o agente lê o build log, corrige e abre PR) e rollback pós-deploy com análise de causa raiz. Ver ai-native-sdlc em Related Concepts.

Implications

Este ciclo depende de um pré-requisito estrutural que já existe como página própria neste vault — branch-isolation-for-agents, que cobre o isolamento por branch/worktree em si. Este conceito descreve a camada seguinte: o que acontece dentro desse isolamento, do momento em que a issue existe até o merge. Junto com especificacao-de-issues-para-agentes (o contrato) e plan-first-com-agentes-de-ia (o checkpoint antes de codar), formam a espinha dorsal do funil completo descrito na fonte.

Para o founder/PM não-técnico, o ponto central é que “revisar” não significa “ler código” — significa validar comportamento contra a issue, usando o checklist de 6 itens. A confiança no código de IA vem da verificação em camadas, não da origem do código.

Open Questions

  • As métricas citadas (Veracode 45%, <25% de código integrado direto, “33 mil PRs” de outro estudo mencionado na fonte) merecem uma checagem de fonte primária antes de serem citadas com confidence: high em qualquer página futura.
  • Não fica claro se o ritual diário/semanal descrito assume um único founder operando sozinho ou também cobre um time pequeno com mais de uma pessoa revisando.

Sources

Visão de gráfico

Backlinks