Fluxos de desenvolvimento com IA funcionam melhor quando o time troca o improviso por uma esteira mínima: card de produto, cards técnicos pequenos, execução em paralelo e revisão assistida. Foi o que o convidado Sam descreveu na live do canal Augusto Galego, com base no trabalho em uma startup que usa Claude Code diariamente. O ganho de velocidade é real, mas vem acompanhado de débito cognitivo.
Fluxos de desenvolvimento com IA: como ficaram os fluxos de trabalho em 2026
Fluxos de desenvolvimento com IA mudaram de brinquedo de fim de semana para esteira de produção em cerca de dois anos. Foi o retrato dado por Sam, engenheiro convidado da live de setembro de 2026 do canal do Augusto Galego, que trabalha em uma startup com plano enterprise da Anthropic. Segundo ele, cerca de 90% do trabalho diário roda no Claude Code, a ferramenta de codificação agêntica da Anthropic que opera no terminal.
Essa concentração não significa ausência de experimentação. O convidado relatou que já usou o Cursor, editor de código com IA baseado no VS Code, principalmente quando a ferramenta mudou de posicionamento para orquestração de agentes. Ele também testou alternativas para projetos pessoais, como um jogo no estilo Vampire Survivors de Pokémon, e mediu o custo disso na prática.
Um dado concreto do teste: em um único fim de semana de experimentação com modelos diferentes, ele gastou quase R$ 1.000 em créditos de API. Essa experiência é dele, não um benchmark controlado, e ilustra um ponto central da live: comparar modelos com rigor é caro, e a maioria das pessoas acaba escolhendo por impressão.
Freestyle ou processo: quando cada abordagem faz sentido
Freestyle funciona quando você trabalha sozinho e não precisa de padrões. É abrir o Claude Code, conversar com o modelo, mandar gerar código e avaliar o resultado na mão, sem skills, sem MCP, sem ceremony. O jogo de Pokémon citado na live foi feito exatamente assim, sem PR, sem fluxo de desenvolvimento formal.
Em time, a conta muda. Quando várias pessoas entregam código gerado por IA na mesma base, surge a necessidade de padrões mínimos: como criar cards, como revisar, como limitar o escopo. O objetivo declarado do convidado não é uma fórmula universal, e sim reduzir o não determinismo o suficiente para o time trabalhar junto sem atrito.
Ele resumiu o tradeoff em uma frase que funciona sozinha: quanto mais você delega para uma ferramenta não determinística, menos profundidade você tem sobre o que foi entregue. Quem delega card, documentação e review inteiro vira, nas palavras dele, um 'QA premium' da própria tarefa.
Skills e slash commands: prompt repetido vira ferramenta
Skill, no Claude Code, é um prompt reutilizável que o agente carrega quando relevante, podendo ser invocada por slash command ou descoberta pelo próprio modelo. A regra prática do convidado: se você escreve o mesmo prompt toda semana, ele vira skill; se não se repete, não precisa virar.
Ao criar uma skill, você define se o modelo pode descobri-la sozinho ou só executá-la sob comando explícito. Skills sensíveis devem ficar escondidas; uma skill de design de frontend pode ficar visível para o modelo acionar quando estiver desenhando interface. O Material for Claude Code documenta esses parâmetros.
Ele também fez uma ressalva que desmistifica o hype: muitas skills públicas são, na prática, pedaços de prompt que um modelo bom o suficiente dispensa. Em teste A/B informal que ele conduziu, várias não mudaram o resultado. O que decide o comportamento do agente são três peças — o modelo, a harness com tool calls e os prompts de sistema — e nenhuma delas é mágica isolada.
Da card de produto ao card técnico: a esteira em quatro etapas
A esteira resolve o problema de transformar uma dor de negócio em código revisado sem depender de uma única conversa longa com o modelo. São quatro skills encadeadas, e cada uma responde uma pergunta diferente do fluxo de entrega: como configurar o contexto, o que construir, como fatiar o trabalho e como executar.
1. Setup de contexto
Uma skill de configuração prepara MCPs comuns, regras de trabalho e arquivos de memória como o Claude.md. O convidado evita instructions globais longas: em uma base grande, uma regra global sem escopo já fez o modelo se recusar a implementar algo do jeito solicitado. A alternativa são arquivos de regras segmentados por caminho, válidos apenas para frontend ou backend, reduzindo poluição de contexto.
2. Card de produto
Uma skill transforma uma dor de negócio em card, história ou épico. Ela pode ser intervencionista, só formatando o texto, ou questionadora, perguntando qual é a dor e para onde o time quer levar a solução. Ferramentas como Jira ou Linear entram via MCP para criar o card automaticamente.
3. Refinamento técnico e cards técnicos
Outra skill lê o card de produto, a base de código e eventuais RFCs escritas à mão, e produz microcards ordenados. Cada card técnico traz critérios de teste end-to-end, critérios de observabilidade (log, eventos, alerta, dashboard) e, quando aplicável, estratégia de feature flag e rollback. A regra de ouro do time: PR de no máximo 500 linhas, excluindo testes e documentação. Escopo pequeno reduz a chance de o modelo se perder.
4. Execução e revisão
A última skill executa cada microcard, abre pull request e roda em várias máquinas virtuais em paralelo — o Claude Code, por exemplo, consegue abrir VMs isoladas. Depois entram agentes revisores, como detalhado na próxima seção, e só então o código chega aos devs.
| Etapa | Pergunta que responde | Saída |
|---|---|---|
| Setup de contexto | Como o modelo enxerga o projeto? | MCPs, regras segmentadas e memória |
| Card de produto | O que o negócio precisa? | Card, história ou épico no Jira ou Linear |
| Refinamento técnico | Como fatiar o trabalho? | Microcards ordenados com critérios de teste e rollback |
| Execução e revisão | Quem escreve e confere o código? | Pull requests revisados por agentes |
Revisão automatizada: CodeRabbit e agentes avaliadores
A revisão de PR é onde o convidado vê o melhor custo-benefício da IA. Na empresa dele, o CodeRabbit, ferramenta de code review automatizada, é o primeiro olho em cada pull request. Ele resume o risco com franqueza: no pior caso, a ferramenta gera um falso positivo e uma correção prolixa que não muda nada; no melhor, pega uma vulnerabilidade real antes do release.
Para times que não dominam segurança, o ganho é proporcional. Além de segurança, o revisor automatizado aponta problemas de performance, como query sem índice fazendo full table scan. Ele citou que, na empresa anterior, era comum o PR só chegar a um humano depois da aprovação do revisor automatizado.
A visão mais ambiciosa, ainda não implementada por ele, é uma malha de agentes avaliadores: um para performance, um para segurança, um para resiliência, um para observabilidade, cada um comentando no PR por um critério. Ele reconhece a objeção legítima de quem acha que isso suja o PR — e a decisão, mais uma vez, é do time, não do ferramental.
Há um limite conhecido: em bases grandes, com guidelines extensas, o modelo revisor perde regras. Quando um agente começa a perder contexto, a resposta do time tem sido adicionar outro agente, não inflar o primeiro.
O preço da velocidade: débito cognitivo e observabilidade
A velocidade da esteira com IA cobra um preço que não aparece na fatura do modelo: o time entrega em uma hora o que levava um dia, mas para de entender o próprio sistema. O convidado chamou isso de débito cognitivo. Ritmo alto, leitura baixa, regra de negócio escapando na revisão.
A resposta não é voltar atrás. É comprar visibilidade. Ele propôs três frentes de mitigação:
- Incluir critérios de observabilidade dentro de cada card, antes do desenvolvimento começar.
- Instrumentar o sistema com ferramentas como o New Relic.
- Classificar alertas por severidade e por frequência de erro.
A classificação de alertas separa dois regimes bem diferentes:
| Tipo de alerta | Comportamento | Ação exigida |
|---|---|---|
| Slow burn | Degrada o serviço aos poucos | Investigar sem pressa |
| Fast burn | Pode derrubar produção | Agir imediatamente |
Com observabilidade bem feita e um MCP conectado à ferramenta, o próprio agente ajuda a localizar o bug sem reprodução local. Você economiza horas de depuração manual.
Ele estabeleceu uma fronteira clara para deploy sem leitura completa do código: só tarefas fail-safe, sem blast radius, que não interrompem nenhum fluxo do cliente. O exemplo dado foi emissão de eventos fire-and-forget em uma plataforma de eventos. Tudo que tem raio de alcance na base merece revisão humana e ambiente de testes.
Sobre métricas de gestão, ele citou como referência informal um cycle time de mercado de cerca de 24 horas por card técnico. Foi observação dele como líder, não dado publicado.
Escolha de modelos e custo: caro para planejar, rápido para executar
A estratégia aqui é separar quem planeja de quem executa. Modelos caros e reflexivos entram na elaboração de cards e no refinamento técnico; modelos rápidos e baratos ficam na execução, iterando o código. Na experiência dele, ferramentas de execução entregam bem sem precisar do modelo mais inteligente.
Sobre preços, ele consultou o comparador Artificial Analysis durante a live e observou que, via API, o GPT tende a custar menos que os modelos da Anthropic ressalva: subsídios de assinatura mudam a conta, e só testando você descobre qual plano rende mais. Já o Gemini, família de modelos do Google, ele reconheceu como a opção mais barata e rápida, embora tenha percebido um gap de inteligência em relação aos concorrentes nos testes pessoais dele.
| Etapa da esteira | Perfil de modelo indicado | Motivo |
|---|---|---|
| Card de produto e RFC | Caro e reflexivo | Exige julgamento e contexto amplo |
| Revisão técnica | Caro e reflexivo | Detecta falhas antes do código |
| Execução e iteração | Rápido e barato | Entrega bem sem o modelo mais inteligente |
Para reduzir custo sem quebrar a esteira, a receita dele foi direta: faça card de produto, RFC e revisão na mão, e delegue só a execução ao modelo mais rápido. Isso preserva ownership, reduz débito técnico e cabe em orçamentos pequenos.
Sobre planos de assinatura, ele relatou que o de US$ 200 da Anthropic raramente estoura por contribuição individual, enquanto o básico acaba rápido. Ele também se preloadou de alertar: deixar o plano de uso por token (pay as you go) ativo sem perceber saiu caro para ele.
Perguntas frequentes
- Preciso de skills para começar com Claude Code? Não. O ponto de partida recomendado na live é o freestyle: use a ferramenta, perceba quais prompts se repetem e só então transforme-os em skills ou slash commands. Skill sem repetição é prompt morto no repositório.
- É seguro subir código gerado por IA sem ler? Só em tarefas fail-safe, sem blast radius e que não interrompem fluxo de cliente, como emissão de eventos isolada. Em qualquer tarefa com impacto cruzado na base, revisão humana e ambiente de testes continuam obrigatórios.
- Usar IA para revisar PR substitui review humano? Não substitui; encurta o caminho. Um revisor automatizado como o CodeRabbit pega problemas de segurança e performance antes do humano, mas perde regras em bases grandes e gera falsos positivos, então o bypass manual continua necessário.
- Como controlar o custo de modelos em equipe? Separe planejamento de execução: modelos caros só na elaboração de cards, modelos rápidos e baratos na execução. Monitorar cycle time, custo por tarefa e aderência ao processo mostra quando o time está comprando velocidade mais cara do que precisa.
- Onde estudar fundamentos antes de depender de IA? A recomendação da live foi aprender lógica, uma linguagem de mercado, banco de dados, Git e segurança básica de API primeiro, e usar a IA para criticar e ensinar, não para fazer por você. Conteúdos como o Bootcamp do Dev Doido e o Crazystack Typescript do Crazystack seguem essa linha de fundamentos antes de ferramenta.
Da live ao artigo escrito
A tese que atravessou toda a conversa vale para o seu próprio conteúdo: conhecimento aplicado que existe só em uma live de quase duas horas é conhecimento difícil de consultar, citar e reaproveitar. Se você apresenta fluxos, testes ou opiniões em vídeo como o Augusto Galego fez aqui, transformar esse material em texto estruturado multiplica o alcance dele.
O Skala Blog faz exatamente esse caminho: você cola a URL de um vídeo do YouTube, a ferramenta transcreve e gera um artigo organizado, pronto para revisão e publicação. Se a sua melhor aula está presa em um arquivo de live, vale passar dela para a página.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits