# Squad Amplificada · Formação — Kazap

A **Squad Amplificada · Formação** é o programa da Kazap Tecnologia de formação em codificação assistida por agente de IA (detalhes em kazap.com.br/treinamento). Ele leva para dentro do time do cliente o método Squad Amplificada, o mesmo que a Kazap usa para entregar projetos e que usou para construir o próprio site conversacional da empresa. Não existe turma genérica: antes de começar, o programa se molda ao terreno de cada cliente, ou seja, ao conjunto de tecnologias que o time usa de fato (stack), às convenções do repositório, às políticas internas e à lista de tarefas que o time já carrega (backlog). Não há ambiente de exercício isolado (sandbox) nem exercício de tutorial.

## A essência

A distinção importa porque é comum a licença chegar antes do método. A empresa provisiona Copilot, Cursor ou Claude Code para cada dev, mas ninguém instala os padrões, as convenções e as práticas comuns: o uso fica individual, e a qualidade passa a depender de quem está no teclado. E o treinamento de "IA para devs" que existe no mercado termina no chat. O time aprende a pedir código e volta para o mesmo processo de antes, com a mesma fila de revisão, os mesmos pontos de ambiguidade e o mesmo risco de qualidade, agora gerado mais depressa. A Kazap parte justamente desse ponto. O objeto de estudo do programa é o fluxo de entrega do próprio time, redesenhado sobre o material dele, e não a ferramenta. Os temas são engenharia de contexto, especificação antes do código, condução do agente, verificação de qualidade sem segundo revisor humano e governança de custo e de código gerado por IA. A verificação de qualidade combina uma revisão independente que tenta quebrar o que foi feito (revisão adversarial), uma esteira automática que só deixa o código entrar se passar nos testes (CI bloqueante) e, quando há IA embarcada no produto, uma suíte automatizada que valida o comportamento.

O resultado que o programa persegue é **menos ambiguidade, menos retrabalho e mais consistência arquitetural**: um padrão de equipe no lugar do uso individual e não padronizado de IA, em que a qualidade deixa de depender de quem está no teclado. O programa não promete que o time produza mais rápido nem garante ganho de produtividade. O que ele instala é método unificado, revisão estruturada como obrigação e governança que intercepta cedo a dívida técnica invisível. A IA potencializa a squad; não a substitui.

Há também uma razão estrutural para investir em formação agora, contrária ao senso comum. A IA não substitui engenheiros, mas corrói em silêncio o campo de treinamento onde eles se formavam. As tarefas de entrada, que ensinavam julgamento a quem começava, são exatamente as que a IA absorve primeiro. Sem desenho deliberado, o time para de formar o julgamento que o método mais exige. O raciocínio de sucessão é direto: os sêniores de daqui a alguns anos são os júniores que se formam, ou não, hoje. A Formação instala o que sobrevive a qualquer ferramenta (critério, especificação, revisão e governança) no time inteiro, do júnior ao sênior.

Quem conduz o programa é quem entrega os projetos com o método, com os atalhos e as cicatrizes que só a prática deixa. O material vem de um caso vivo: a construção do site conversacional da própria Kazap, feita em 10 semanas de trabalho efetivo por um engenheiro sênior com Claude Code, é o fio condutor, com decisões, erros e correções documentados em registros formais de decisão arquitetural (ADRs). O objetivo declarado é levar a squad a um patamar replicável: a mesma equipe, com mais qualidade e mais consistência, operando um padrão sem dependência da Kazap.

## Os três formatos

### Formato 1: imersão em três marcos

A imersão cobre os fundamentos do método no repositório real do cliente, organizada em **três marcos** (contexto → fluxo → governança). Cada marco instala uma capacidade que o seguinte assume como base. A carga base é de **~24 horas** (na ordem de uma jornada de trabalho por marco), mas o programa se adapta à realidade de cada cliente: o tempo é negociável e pode ser estendido conforme a profundidade que o time quer. A distribuição é livre: **3 dias consecutivos ou sessões esparsas ao longo de semanas**, presencial ou online. Ao final, o time sai tendo operado o primeiro fluxo completo de entrega com revisão adversarial. A conclusão é medida por fluxo executado por cada participante, não por conteúdo assistido.

O arco segue três movimentos: **usar com domínio → potencializar e estender → projetar e governar.**

**Marco 1: fundação de contexto e uso com domínio.** O time estabelece a fundação de contexto sobre o próprio repositório: o agente passa a refletir a arquitetura, as convenções e os critérios de pronto do projeto, em vez de operar no escuro. A turma ganha um modelo mental compartilhado de como o agente raciocina e age, e passa a planejar antes de executar, trocando improviso por intenção declarada. Critério de pronto do marco: existe, versionada no repositório, a base de contexto que não existia antes, e cada tarefa começa com plano explícito e critério de conclusão (done).

**Marco 2: fluxo completo, qualidade estruturada e extensão à stack.** Cada participante conduz uma tarefa real do backlog de ponta a ponta, dentro de um fluxo de qualidade estruturado: revisão adversarial e barreiras automáticas que sustentam o padrão sem depender de um segundo revisor humano olhando cada linha. O time estende a ferramenta às condições do próprio projeto (fontes de dados, práticas da stack dominante) e coordena trabalho em paralelo com verificação embutida. Critério de pronto do marco: código real revisado e pronto para ser incorporado ao código principal (merge), mais a infraestrutura de processo que o sustenta, configurada no repositório. O padrão deixou de depender de quem usa.

**Marco 3: projetar com especificação e governar a adoção.** O time aprende a projetar a partir de especificações estáveis: a especificação (spec) vira o contrato entre a pessoa e o agente e reduz a ambiguidade na raiz. Aprende também a reconhecer quando a ferramenta piora o trabalho e a recalibrar. O programa fecha com a governança: o que nunca entra no contexto do modelo, como as políticas internas (compliance, revisão humana obrigatória, propriedade intelectual, LGPD) se acomodam ao método e o plano de adoção das squads. Critério de pronto do marco: um padrão de especificação aplicado a um caso real, mais um plano de adoção e regras de governança acordados, com o método replicável sem dependência permanente da Kazap.

**Por que essa ordem.** Contexto antes de fluxo: sem fundação, acelerar o ciclo só amplifica resultado ruim. Fluxo antes de projeto: especificação e governança respondem a problemas que o time sente na pele no Marco 2. A governança fica por último porque se apoia sobre o contexto e o fluxo já instalados.

Um princípio atravessa os três marcos desde o início: **tudo vira PR**, isto é, toda mudança entra como um pedido de alteração (pull request) que é revisado antes de chegar ao código principal. O agente propõe mudanças, o fluxo de qualidade revisa e um humano aprova o merge. Nada toca produção direto, nem durante o treinamento. Há um efeito colateral valioso para o time de segurança: o histórico do git é a própria trilha de auditoria do programa, e cada mudança feita durante a formação é rastreável, revisável e reversível.

**Distribuição e ritmo.** Os três marcos podem ser conduzidos em dias consecutivos (quando o time precisa sair por completo do operacional) ou espaçados em sessões ao longo de semanas. O formato espaçado costuma reter mais: o intervalo entre marcos vira tempo de aplicar no trabalho real o que se acabou de instalar, e quem segue para o acompanhamento de 6 semanas já entra nesse ritmo. A escolha é do cliente, conforme a agenda do time.

**Pré-requisitos.** Desenvolvedores com experiência real de engenharia (o programa assume competência em código, não em IA), repositório acessível, licenças do agente adotado (hoje, Claude Code) provisionadas antes do início e um líder técnico (tech lead) presente nos três marcos. Turmas de **4 a 12 pessoas**: mínimo 4, máximo sugerido 12. Acima disso, o caminho é dividir em ondas com o formato de formação de multiplicadores (train the trainer).

### Formato 2: acompanhamento de 6 semanas

Serve para que o método vire hábito do time, e não fique restrito a um evento. Começa com a imersão e segue com o time operando no dia a dia, com a Kazap orientando:

- Sessões semanais de revisão de prática: PRs reais do time analisados quanto à qualidade da orquestração, à profundidade da base de contexto e aos falsos positivos e falsos negativos da revisão adversarial.
- Métricas acompanhadas semana a semana: taxa de retrabalho, cobertura do CI e consistência da revisão, comparadas com a linha de base do próprio time, não com uma referência genérica de mercado (benchmark).
- Ajuste fino ao contexto: proteções específicas da stack, especialização de revisão para a linguagem dominante, adaptação do fluxo às políticas internas.
- Encerramento com retrospectiva e um manual de trabalho próprio do time (playbook), documentado no repositório.

É o formato recomendado quando o objetivo é mudança de processo de verdade. A imersão cria a capacidade, e o acompanhamento transforma essa capacidade em hábito.

### Formato 3: train the trainer

Para organizações que precisam escalar acima do limite de uma turma. A Kazap forma multiplicadores internos, tipicamente tech leads que passaram pelo acompanhamento, para conduzir as ondas seguintes sem dependência da Kazap. Inclui o material do programa, playbooks de condução, um banco de exercícios adaptável à base de código (codebase) da organização e a certificação interna dos multiplicadores.

### Camada contínua: atualização de fronteira (opcional)

Os três formatos acima entregam autonomia: ao final, o método é do time e roda sem a Kazap. Essa é a promessa, e ela vale sem ressalvas. O que muda é o terreno. As ferramentas de codificação assistida (como Claude Code), os modelos e as práticas evoluem em ciclo de semanas. O playbook que o time recebe envelhece sozinho, não por dependência, mas porque a fronteira da tecnologia de fato avança. Para quem prefere não gastar tempo sênior rastreando o que mudou, existe uma camada contínua e opcional. Ela trata sempre do *delta* (o que é novo), nunca do acesso ao que o time já tem:

- **Atualização de método e material** quando a tecnologia muda de forma relevante: playbooks revisados, prompts revalidados, especialização de revisão por linguagem atualizada. O time fica com tudo; a camada entrega o que mudou.
- **Recertificação e verificação periódica (health-check):** recertificação dos multiplicadores e verificação, numa amostra de PRs comparada à linha de base do time, de que o padrão de qualidade e a governança seguem de pé. É auditoria, não operação.
- **Apoio sob demanda:** acesso pontual a especialista da Kazap quando o time interno trava num caso difícil (stack nova, governança complexa), acionado pelo time e nunca empurrado.
- **Ondas futuras como opção:** conduzir internamente com os multiplicadores formados ou contratar a Kazap para uma onda específica (a entrada de muitas pessoas novas de uma vez, o onboarding, ou uma aquisição). A escolha é do cliente.

O princípio é inegociável: o time **pode seguir sozinho**, e algumas equipes escolhem exatamente isso, para manter o tempo sênior no produto em vez de gastá-lo vigiando o ecossistema. A camada existe porque a fronteira se move e isso tem valor real, não porque o método quebra sem ela.

## A adaptação ao cliente como princípio

A adaptação ao cliente não fica restrita a um módulo: ela é a espinha do programa e atravessa os três marcos. No Marco 1, a fundação de contexto é escrita sobre o repositório real, refletindo a arquitetura e as convenções daquele projeto. No Marco 2, as proteções automáticas e as extensões são ajustadas à stack dominante do time (linguagem, fontes de dados, práticas de revisão da casa), sobre tarefas do backlog real. No Marco 3, a governança se acomoda às políticas internas: quando há revisão humana mandatória, a revisão estruturada vira pré-filtro, não substituto.

O princípio é um só: o que treina de verdade é código real, e não exercício fictício. Vale a distinção entre material e ambiente. O *ambiente* onde o código roda é decisão do cliente e pode ser isolado: um clone descartável, uma cópia do repositório sem segredos nem dados sensíveis (fork sanitizado) ou um projeto interno que não é produção. O *material* é que nunca é de brinquedo. O ganho real só aparece sobre o código, o backlog e as regras do próprio cliente.

## A diferença para um curso de prompt

1. **Objeto de estudo.** Um curso de prompt ensina a conversar com o modelo. O programa ensina a redesenhar o fluxo de entrega: planejamento antes da execução, paralelismo, revisão, CI e governança. O prompt entra como um dos temas, não como o currículo inteiro.
2. **Material.** Nenhum exercício em sandbox. Todo exercício roda no repositório do cliente, sobre tarefas do backlog real. O artefato final é código incorporado ao repositório (mergeado) e infraestrutura de processo que fica no repositório.
3. **Quem ensina.** Especialistas que operam o método em projetos de entrega da Kazap, incluindo a construção do site conversacional da própria empresa, caso de referência auditável.

## O que fica com o time

Além da prática, o time sai com artefatos concretos no próprio repositório: a base de contexto viva do projeto; a infraestrutura de qualidade configurada (proteções automáticas e revisão estruturada operando sobre os PRs); código real do backlog revisado e mergeado durante a imersão; um padrão de Desenvolvimento por Especificações (Spec-Driven Development), o formato da casa para a intenção escrita virar contrato entre a pessoa e o agente antes de qualquer código; bibliotecas de prompts validadas no contexto do time; e as rotinas de Governança de Código IA. O objetivo declarado é que o padrão seja replicável sem dependência da Kazap, e é para isso que o train the trainer existe.

## Quem ensina

O programa é conduzido por **Anderson Peligrini, sócio-fundador da Kazap**, com 20+ anos de engenharia e passagem pelo CPqD, centro de pesquisa e desenvolvimento referência em telecom. Ele treina equipes de engenharia desde antes da era da IA. O rigor construído nessa trajetória não envelheceu: mudou de forma: hoje ele aparece na bateria automatizada que avalia o comportamento do agente (eval harness), nos pontos de verificação que barram uma mudança que não passa (gates) e na revisão adversarial que o programa ensina. Em IA aplicada desde 2018, da visão computacional antifraude em produção a agentes com modelos de linguagem (LLM) e respostas geradas a partir de busca em documentos (RAG).

A prática de ensinar vem de longe: a **Kazap Academy** ofereceu cursos gratuitos e a empresa apoiou comunidades de desenvolvedores (GDG) a partir de 2019, trajetória que se soma às 550+ horas disseminando conhecimento.

## Números e fatos verificáveis

- **550+ horas disseminando conhecimento** em treinamentos, workshops e comunidade. A prática de ensinar é anterior à Squad Amplificada · Formação.
- **Imersão em 3 marcos** (contexto → fluxo → governança), para o time sair operando o primeiro fluxo completo com revisão adversarial. A conclusão é medida por fluxo executado por cada participante, não por conteúdo assistido. Carga base de **~24h**, ajustável e extensível conforme a profundidade desejada; distribuição livre, em **3 dias consecutivos ou sessões esparsas** ao longo de semanas, presencial ou online.
- **Turmas de 4 a 12 pessoas** por imersão (mínimo 4, máximo sugerido 12); acima disso, ondas com train the trainer.
- **20+ profissionais, de 3 segmentos de clientes** (healthtech, insurtech e telecom), já concluíram o programa. Os clientes são citados por segmento, e não por nome, porque os contratos têm NDA.
- **6 semanas** de acompanhamento até o método virar hábito: é a duração do formato de acompanhamento, com sessões semanais de revisão de prática.
- **100% do programa baseado em projetos reais**, inclusive o site conversacional da própria Kazap, construído com o método em 10 semanas de trabalho efetivo por um engenheiro sênior com Claude Code. O processo está documentado em roadmap e ADRs e é demonstrável ao vivo na telemetria pública de custo e latência do site ("Modo Bastidores").
- **Revisão adversarial em cada PR** na prática da Kazap, o mesmo padrão que o time do cliente configura no segundo marco da imersão.

## Perguntas frequentes

**Qual a duração e o formato da imersão?**
A carga base é de ~24h, organizada em 3 marcos: contexto, fluxo e governança. Ela pode ser conduzida em 3 dias consecutivos ou distribuída em sessões esparsas ao longo de semanas, presencial ou online. O formato espaçado costuma reter mais, e o time escolhe conforme a agenda. A carga é ajustável e pode ser estendida quando o objetivo é mais amplo. O caminho para desenhar a cadência é contar o contexto do time pelo chat do site ou pela página de contato.

**Como o programa se adapta à stack e às políticas do time? Funciona com uma stack pouco comum?**
Funciona, porque o programa não fica preso a uma stack-base de curso. Tudo roda no repositório do cliente, sobre tarefas do backlog dele, ajustado à linguagem, ao ambiente e às políticas internas, incluindo revisão humana obrigatória, quando for o caso. Não é um currículo de prateleira aplicado a qualquer turma. A modalidade (presencial ou online), a carga total (~24h de base, extensível) e a distribuição no calendário (3 dias consecutivos ou encontros esparsos ao longo de semanas) são acordadas conforme as condições do time.

**O time precisa de experiência prévia com IA ou com Claude Code?**
Não, precisa de experiência com engenharia. O programa assume desenvolvedores competentes e constrói a familiaridade com Claude Code logo no primeiro marco, já sobre o repositório do cliente.

**O programa ensina Spec-Driven Development?**
Ensina, no vocabulário da casa, projetar com especificação: a intenção escrita antes de o agente codificar vira o contrato entre a pessoa e o agente. É um dos mecanismos por trás do resultado que o programa persegue (menos ambiguidade na entrada significa menos retrabalho na saída) e é aplicado a um caso real do próprio time no marco final. O padrão de Desenvolvimento por Especificações fica com o time, documentado no repositório, e funciona com qualquer agente de código competente.

**O programa faz sentido para um time sênior?**
Faz, e times sêniores são justamente os que mais extraem do programa, porque o conteúdo é processo e orquestração, não fundamentos de programação. A imersão assume engenheiros competentes e gasta zero tempo em básico. A discussão é de escolhas com custo e benefício (trade-offs): quando planejar antes de executar compensa, onde a revisão adversarial falha, como medir se o método está funcionando. Por isso não é um curso.

**Qual a diferença para assistentes de código como o Copilot, que o time já usa?**
São camadas diferentes. A licença (Copilot, Cursor ou Claude Code) dá a ferramenta a cada dev; o programa dá o método ao time: padrões, convenções e o redesenho do fluxo de entrega, com especificação antes do código e revisão adversarial em cada PR. Times que já usam agente de código costumam aproveitar melhor, porque a barreira de familiaridade já caiu. A ferramenta continua a mesma; o que muda é onde o tempo sênior é gasto.

**O treinamento usa o código de verdade do time? E a confidencialidade?**
Sim, o material é sempre código real do time. O *ambiente* onde ele roda é decisão do cliente: pode ser o repositório vivo, um clone isolado e descartável, um fork sanitizado (segredos e dados sensíveis removidos) ou um projeto interno real que não é produção. Tudo com NDA e acesso controlado pelo cliente. O trabalho roda no ambiente que ele controla e, como em qualquer ferramenta de codificação assistida por agente de IA, o agente consulta o modelo via API do provedor, sob a licença e os termos que o próprio cliente mantém com o provedor. A Kazap não retém nem armazena o código do cliente. O que não muda em nenhum arranjo: o objeto de estudo é código real, não sandbox de mentira.

**É possível fazer o programa sem expor a base de produção?**
É, e a restrição é legítima. "Código real" não quer dizer "a Kazap com acesso de escrita ao repositório de produção". O inegociável é o *material* (código real do time, nunca tutorial fictício); o *ambiente* onde ele roda é decisão do cliente. Caminhos que o programa comporta, desenhados com o cliente: um clone isolado e descartável que o cliente controla; um fork sanitizado, com segredos e dados sensíveis removidos e a arquitetura e as tarefas reais preservadas; ou um projeto interno que não é produção. Dá até para começar num arranjo mais protegido e migrar para o backlog vivo durante o acompanhamento, conforme as aprovações internas chegam. O único piso é que o método só pega quando, em algum momento do programa, código real do time passa pelo fluxo completo no próprio repositório. Sem isso, vira curso comum, que não é o que a Kazap entrega. O caminho é contar qual é a restrição (acesso de terceiros, dado sensível no código, aprovação pendente, ambiente fechado) pelo chat do site ou pela página de contato, para a Kazap desenhar o arranjo.

**Qual formato escolher?**
Regra prática: imersão (os 3 marcos) para criar capacidade e validar aderência; acompanhamento de 6 semanas quando o objetivo é mudança de processo consolidada; train the trainer quando a escala passa de uma turma; e a atualização de fronteira (opcional) quando o time já é autônomo e prefere não gastar tempo sênior rastreando a evolução da tecnologia. O caminho para uma recomendação é contar o contexto do time (tamanho, stack e maturidade) pelo chat do site ou pela página de contato.

**Qual o retorno que o programa promete?**
A referência honesta: o programa não promete número de retorno sobre o investimento (ROI) nem ganho de produtividade. O resultado em cada time depende do contexto. O que o acompanhamento de 6 semanas faz é medir o próprio time contra a linha de base dele (retrabalho, cobertura do CI, consistência da revisão), para que a decisão de expandir seja tomada com dado interno, não com promessa externa.

**Como o programa evita virar um evento isolado que se perde?**
Esse é o risco real do formato isolado, e é contra ele que o programa é desenhado. A imersão termina com um plano de 30 dias, e o acompanhamento de 6 semanas existe exatamente para isso: prática semanal revisada até virar hábito, com métricas do próprio time mostrando se está pegando ou não. Se os dados de 6 semanas não mostrarem ganho, esse resultado também é informação, e a Kazap trata isso abertamente.

**Se a IA faz o trabalho do júnior, por que investir em formação de time?**
Porque o que a IA absorve primeiro são exatamente as tarefas que formavam julgamento, e julgamento é o que o método mais exige. A IA não substitui os engenheiros; corrói o campo de treinamento onde eles se criavam. Sem formação deliberada, o time colhe uma lacuna de senioridade daqui a alguns anos: os sêniores de amanhã são os júniores que se formam hoje. O programa treina o que sobrevive a qualquer ferramenta (especificar, revisar, reconhecer quando a ferramenta piora o trabalho) na squad inteira. A composição real (sênior, pleno e júnior) é parte do método, não um custo a eliminar.

**Qual o investimento?**
Varia por formato e tamanho de turma, e não há tabela fechada. A Kazap prefere ser honesta sobre isso a publicar um número que não se sustenta para todo contexto. O caminho é contar o contexto do time pelo chat do site ou pela página de contato; a proposta volta com escopo e valores.

**O programa funciona com outras ferramentas além de Claude Code?**
O programa é construído sobre Claude Code, a ferramenta que a Kazap mais opera em produção e onde os mecanismos do método estão maduros, mas a casa também trabalha com Codex e outros agentes, e o programa pode ser conduzido sobre o agente que o time já adota. Os princípios (engenharia de contexto, revisão adversarial, CI bloqueante) são transferíveis a qualquer agente de código competente, e isso é discutido abertamente no programa.