O que os participantes relatam
A parte que mais me surpreendeu foi o follow-up na semana dez. A gente tinha medo de que o programa terminasse e as práticas voltassem ao estado anterior. Não voltaram — e agora temos os números para provar isso internamente.
A sessão prática foi diferente de qualquer treinamento que eu já fiz. Não teve slide. Trabalhamos direto no nosso repositório, no nosso problema de semana. Aprendi mais em um dia do que em semanas de leitura sobre o assunto. O único ponto é que um dia é curto para tudo que tem para cobrir.
O que me convenceu a contratar foi exatamente a falta de afiliação com fornecedor. Já tinha passado por situações em que a recomendação de ferramenta era, na prática, um anúncio. A Bitolla fez uma comparação técnica real e foi honesta sobre o que não funcionaria para o nosso contexto.
A Revisão de Práticas identificou três padrões de código que a gente aprovava em revisão e que estavam criando custo de manutenção que ninguém conseguia nomear. Agora estão descritos no checklist que o time usa toda semana.
Antes da oficina, usava o assistente principalmente para gerar boilerplate e pouco mais. Saí com uma perspectiva diferente sobre como usar para testes e refatoração — que é onde eu gasto mais tempo de verdade. Já apliquei na semana seguinte.
A política interna que redigimos com a Bitolla foi a primeira documentação de engenharia que o time leu voluntariamente. Faz diferença quando quem vai usar participou de escrever — e quando o texto não parece ter saído do departamento jurídico.
Três engajamentos em detalhe
Time de 23 desenvolvedores usando três ferramentas de assistência diferentes, sem critério definido. Revisões de PR aumentaram de duração mas a cobertura de testes diminuiu — e ninguém conseguia explicar a correlação.
Programa de Adoção com foco inicial em definição de escopo de uso — onde a assistência era adequada e onde não era. Configuração segura para o ambiente financeiro com dados sensíveis. Três sessões práticas no monorepo da empresa.
Cycle time de revisão estabilizou. A empresa padronizou em uma ferramenta com critério documentado. Cobertura de testes em contribuições assistidas subiu de 41% para 68% — medido pelo mesmo método que o baseline.
Revisão de Práticas contratada depois que um cliente reclamou de bugs em funcionalidades entregues com velocidade acima do esperado. Os tech leads suspeitavam de código assistido aprovado sem revisão adequada, mas não tinham como rastrear.
Amostragem de 47 commits das últimas quatro semanas. Identificação de quatro padrões recorrentes — incluindo funções geradas com tratamento de erro ausente que passavam no linter mas falhavam em edge cases específicos do cliente.
Checklist de revisão com os quatro padrões como itens obrigatórios. Regra de linting customizada para dois dos padrões. Em quatro semanas após a sessão com tech leads, zero ocorrências dos padrões identificados em novos PRs.
Time de oito pessoas que usava assistente há seis meses mas sentia que estava "usando errado" — saídas inconsistentes, muito tempo de edição posterior e dificuldade em usar para testes. Queriam técnica, não teoria.
Oficina Prática de um dia, presencial em Fortaleza. Manhã com técnica de descrição de tarefas e incrementos verificáveis. Tarde com prática livre no codebase real — foco em escrita de testes e identificação de sugestões erradas.
Todos os participantes relataram mudança de prática no dia seguinte. O tech lead reportou redução no tempo de edição posterior por contribuição — observação qualitativa, sem baseline formal, declarado como tal na documentação.
Fale diretamente com a equipe
Fortaleza — CE, 60120-002
Sábado: 09h — 13h
Pronto para estruturar o uso de IA no seu time?
Entre em contato e descreva em uma ou duas frases onde o time está hoje. Partimos daí.
[Entrar em contato]