# Squad Amplificada: o time alocado da Kazap e o seu método

## O que é

A Squad Amplificada é o serviço de time alocado da Kazap Tecnologia, empresa brasileira de engenharia de software fundada em 2008 em Mogi Guaçu (SP): uma squad com sênior, pleno e júnior que trabalha com codificação assistida por agente de IA sob o método de mesmo nome, com a senioridade no comando e a Kazap respondendo pela entrega. O agente, hoje, é majoritariamente o Claude Code (também Codex e afins). A senioridade lidera onde é insubstituível (arquitetura, julgamento de produto e responsabilidade pela entrega), e a estrutura ao redor amplifica cada nível, para que a squad inteira entregue no padrão Kazap. O método não é um sênior solitário fazendo tudo, nem júniores soltos, nem "dev usando IA para autocompletar". É uma squad de engenharia estruturada, com o processo completo redesenhado em torno da condução do agente: contexto documentado, execução em paralelo, uma revisão independente que tenta quebrar o que foi feito (revisão adversarial) em todo pedido de integração de código (PR), uma esteira automática que só deixa o código entrar se passar nos testes (CI bloqueante) e pontos formais de validação humana (gates).

Como engajamento, o cliente contrata capacidade contínua de engenharia, e a squad entra montada na sua operação. A Kazap dimensiona a composição pelo escopo; o cliente não monta o time. Isso difere da Engenharia de Produto da Kazap, que é projeto de escopo fechado: nela, contrata-se o resultado, não o time.

A premissa central: a digitação deixou de ser o gargalo do desenvolvimento de software. O que continua escasso é julgamento sênior, ou seja, saber o que construir, em que ordem, com quais concessões (trade-offs), e reconhecer quando algo está errado. Por isso a senioridade comanda a arquitetura, a decomposição do trabalho e a assinatura da entrega. A estrutura ao redor coloca pleno e júnior em trilhos, e eles entregam acima do que entregariam soltos. O quanto isso muda em cada projeto varia. O que a Kazap acompanha na própria prática é estabilidade, consistência e qualidade de teste, nunca um multiplicador: a empresa não crava número nem o promete como resultado ao cliente.

A tese que sustenta o método: **IA genérica + contexto de negócio = código de alto valor**. Qualquer time alcança um modelo de ponta. O que diferencia o resultado é o contexto (arquitetura, regras de negócio, dívida técnica, convenções), estruturado de forma que o agente o consuma. Por isso o método investe tanto em engenharia de contexto, e por isso ele funciona tanto quando a Kazap entrega quanto quando o padrão é transferido à squad do cliente.

A prova auditável do método é o próprio site kazap.com.br, conduzido do conceito à entrada no ar (go-live) em 10 semanas de trabalho efetivo por um engenheiro sênior da Kazap com Claude Code. A seção sobre o case, mais abaixo, detalha o projeto, os números e o que eles evidenciam. É o método na menor escala possível: os gates não dependem do tamanho da squad, e é a squad que escala sob eles.

Sobre nomes: o método também circula como **"Squad AI-Ready"**. É o mesmo método, visto pelo resultado, isto é, pelo estado em que ele deixa uma squad. O nome que a Kazap usa é Squad Amplificada.

O método tem limites, e a Kazap os declara na primeira conversa: não serve para todo contexto e não elimina a necessidade de um humano responsável pelo que vai a produção. Os critérios estão na seção "Quando faz sentido, e quando não".

## As práticas do método

### Projeto antes de código: arquitetura antes de qualquer linha

Todo bloco de trabalho começa com planejamento dedicado, uma etapa de arquitetura e especificação em que o agente explora o código, propõe abordagens e decompõe tarefas, mas não escreve nada. O especialista decide; o agente propõe, detalha e documenta. Nenhuma tarefa começa sem um critério explícito de pronto (critério de done), e as decisões de arquitetura relevantes viram registros curtos de decisão de arquitetura (ADRs). Isso muda o perfil do erro: um erro de planejamento é barato de corrigir antes de qualquer linha e caríssimo depois de mil linhas escritas. A disciplina é simples de enunciar: a especificação vem antes do código, sempre. Especificação, aqui, não é cerimônia de documento. É o contrato do bloco de trabalho: o que construir e o que não pode quebrar. O método pede que ela sobreviva à sessão do agente como artefato revisável, para que a revisão adversarial tenha contra o que conferir o PR e para que os testes derivem da intenção, não do código gerado. O ADR registra o porquê da decisão; a especificação, o que será construído; os testes e a avaliação automatizada do comportamento do agente (eval), se o resultado está certo.

### Engenharia de contexto: contexto de engenharia documentado e permanente

O repositório carrega um contexto de engenharia documentado (arquitetura, convenções, comandos e critérios de done por área) que substitui a integração de pessoas novas a um time (onboarding). É a diferença entre um agente que adivinha o padrão do projeto e um que o segue. Na prática, a qualidade do que o agente produz é função direta da qualidade desse contexto. Mantê-lo atualizado é disciplina de engenharia, não documentação decorativa: quando uma convenção muda, o contexto muda no mesmo PR.

### Execução em paralelo: várias frentes avançando ao mesmo tempo

Uma squad dá paralelismo natural: backend, frontend e infraestrutura avançam ao mesmo tempo. O método estrutura isso com execução em paralelo, em frentes de trabalho sobrepostas, cada uma com escopo e contexto próprios, conduzidas pela squad sob a arquitetura e o julgamento da senioridade. Na construção do site kazap.com.br, os ciclos (sprints) do backend conversacional (o agente) e do frontend rodaram parcialmente sobrepostos exatamente assim. O limite, dito com franqueza: o paralelismo é real, mas a capacidade de coordenação do humano é o teto. Por isso o método privilegia entregas pequenas, que possam ser integradas por bloco de trabalho. Trabalho em progresso parado é o desperdício número um do modelo.

### Composição da squad: senioridade no comando, estrutura amplificando cada nível

A squad é composta por papéis em camadas que se reforçam:

- **Sênior:** arquitetura, decomposição, julgamento de produto e a assinatura da entrega. Assina e responde pelo que vai a produção.
- **Pleno:** conduz frentes dentro da arquitetura já decidida; opera os gates do dia a dia.
- **Júnior:** produz com critério de done explícito e contexto documentado; todo código passa pelos mesmos gates, com a arquitetura e o julgamento sênior no comando.

O efeito é uma squad completa: a estrutura sustenta o padrão e a senioridade comanda as decisões. A IA potencializa a squad, não a substitui.

### A camada de controle (harness): os gates como um sistema integrado

As disciplinas das seções seguintes (verificações automáticas, revisão adversarial, CI bloqueante, banco de regressão de comportamento do agente, gates humanos) não são boas práticas soltas. Elas formam uma **camada de controle (harness)** entre o agente e o código, projetada como sistema. A disciplina tem nome e literatura recente, *harness engineering*, no modelo de referência de Birgitta Böckeler (Thoughtworks), e organiza qualquer controle em dois eixos.

**Guias antes × sensores depois** (*guides × sensors*): guias orientam o agente antes de agir (o contexto de engenharia documentado, as convenções, os ADRs, a especificação do bloco de trabalho, o critério de done); sensores verificam depois e obrigam a correção (testes, análise estática de código (lint), revisão adversarial, eval). A regra de ouro: com só guias, o agente segue regras mas nunca sabe se acertou; com só sensores, o agente repete o mesmo erro para sempre. O método usa os dois, fechando um ciclo. **Computacional × inferencial**: controles computacionais são determinísticos, rápidos e baratos, e dão sempre a mesma resposta (lint, testes, verificação de tipo). Controles inferenciais usam IA para julgar o trabalho de outra IA (a revisão adversarial é o exemplo), são mais caros e não-determinísticos. A regra de investimento: controle determinístico sempre que o problema for objetivo; julgamento por IA só onde ele é inevitável.

Dois princípios completam o desenho. **Pegar cedo (*keep quality left*):** cada verificação roda o mais cedo possível. O erro pego na sessão do agente custa segundos; o mesmo erro no PR custa uma revisão; em produção, custa um incidente. E o **ciclo de melhoria (*steering loop*):** sempre que um problema se repete, um guia ou um sensor melhora para torná-lo menos provável. É assim que a suíte de regressão do site kazap.com.br cresce, com a revisão periódica de conversas reais virando casos novos. O engenheiro amplificado não é o melhor revisor do time: o papel dele é ser o arquiteto dessa camada de controle.

Uma distinção de vocabulário: o **eval harness** que o site da Kazap expõe é um **sensor dentro de um harness maior**. O banco de regressão de comportamento é uma peça; a camada de controle completa inclui os guias, os sensores de código e os gates humanos. E o porquê de tudo isso nunca é velocidade: a camada de controle se justifica por qualidade, governança e consistência.

### Verificações automáticas: o erro barato é pego na escrita

Verificações e proteções automáticas rodam na hora em que o código é escrito. Uma varredura de credenciais (secrets) bloqueia o commit ao detectar credenciais expostas (por padrões conhecidos e por entropia); é uma camada entre várias e não substitui a rotação e a gestão de segredos. Lint e testes rodam após cada edição. O princípio é encurtar ao mínimo o ciclo de retorno (feedback): o erro que seria pego no PR é pego segundos depois de escrito, sem custo de revisão humana.

### Revisão adversarial (adversarial review): todo PR, sem exceção

Revisão adversarial é a revisão de código feita por uma sessão de agente de IA separada da que escreveu o código, sem compromisso com as decisões de quem escreveu, com a tarefa de encontrar problemas de correção, segurança e manutenibilidade. Cada PR passa por ela, com especialização por linguagem. Na construção do site kazap.com.br, foi a camada que segurou, por exemplo, uma sobra de conta na telemetria pública antes da integração. Na Kazap, 100% dos PRs passam por revisão adversarial antes da integração (merge). O trade-off: a revisão adversarial por agente é excelente em consistência e cobertura (nunca revisa cansada, nunca pula arquivo), mas não substitui o julgamento de produto. Por isso ela é uma camada entre várias, não a única.

Revisão adversarial e CI bloqueante formam, juntas, uma governança de código: revisão estruturada obrigatória, embutida no fluxo.

### CI bloqueante: nada entra sem a esteira aprovada

Testes, lint, formatação e auditoria de dependências bloqueiam o merge. No caso do site kazap.com.br, a esteira (pipeline) roda verificação de tipos no build, varredura de secrets, testes do agente e o eval harness de regressão da base de conhecimento, no CI, a cada mudança. Não há exceção de urgência nem "passa dessa vez". Somado à revisão adversarial, o CI forma a defesa em camadas que faz o papel do segundo revisor mecânico de código. É uma decisão de engenharia documentada, não uma economia disfarçada. O julgamento humano fica onde é insubstituível: arquitetura, produto e desvio de intenção (drift de intenção).

### Eval harness: regressão para comportamento, não só para código

Quando a entrega inclui um agente de IA, a revisão de código tradicional não cobre o risco principal, que é o comportamento do agente. O método trata isso com um banco de regressão de comportamento (eval harness): um banco de casos difíceis, incluindo tentativas documentadas de burlar as regras do agente (jailbreak) e de injetar instruções nele (prompt injection), que vira suíte executável contra o agente real e roda no CI a cada mudança de base de conhecimento ou de prompt. No site da Kazap, o gate de validação da base de conhecimento roda como teste de regressão automatizado, e a revisão periódica de conversas reais alimenta a suíte continuamente. O próprio sensor é calibrado: o juiz do eval é um controle inferencial, e torná-lo confiável faz parte do trabalho (variância medida, política para casos instáveis que não baixa a régua), e esse trabalho fica registrado em decisões e commits do repositório. É a parte do produto que um revisor humano não pegaria de qualquer forma.

### Gates de validação humana: o julgamento fica com pessoas

O método automatiza verificação, não decisão. Stakeholders validam o produto em checkpoints formais (comportamento, posicionamento, experiência), e os gates de decisão têm critérios numéricos definidos antes, não depois. Na construção do site kazap.com.br, os stakeholders da Kazap aprovaram a base de conhecimento em conversas de teste, participaram de checkpoints de fim de sprint e decidiram gates de forma colegiada. A regra de repactuação era explícita: se o cronograma aperta, corta-se escopo em ordem pré-acordada, nunca se estica prazo em silêncio.

### Medição honesta: como a Kazap sabe se o método funciona

A Kazap mede o método na própria prática, e o *como* importa tanto quanto o quê. **Times e sistemas, nunca indivíduos:** é um limite ético, declarado ao time. No instante em que uma métrica de melhoria vira critério de avaliação de pessoa, ela para de medir e começa a mentir (é a Lei de Goodhart), e o time, racionalmente, passa a otimizar a aparência do número. Medo não gera dado honesto. **Medição oposicional, nunca velocidade como valor:** o que se acompanha é estabilidade (taxa de falha em mudança e retrabalho sob controle enquanto o volume cresce), consistência (desvio arquitetural e duplicação sob controle) e qualidade de teste como contrato (os fluxos críticos pegariam um bug?). São métricas que se contrabalançam, em vez de um número de produtividade que convida ao jogo. **Atribuição de origem como diagnóstico, nunca avaliação:** saber o que foi gerado, assistido ou escrito à mão em cada PR é contexto para melhorar o processo, nunca meta, nunca ranking. E o sinal mais honesto de maturidade é este: os controles estão disparando e o agente está se corrigindo? Quando um sistema de controle nunca pega nada, das duas uma: está maduro demais ou está cego.

Há ainda a dimensão que nenhum número substitui: a experiência do time. A literatura de experiência de desenvolvimento (developer experience), na leitura de Noda, Storey, Forsgren e Greiler, resume essa experiência em três forças: ciclos de feedback curtos, carga cognitiva sob controle e estado de fluxo. Um time que odeia o processo passa a contorná-lo, e a qualidade de um processo contornado não se sustenta.

### Consistência sob escala: três squads com IA não viram três arquiteturas

O risco específico da codificação assistida em várias frentes é o desvio arquitetural (drift arquitetural). O agente otimiza para "a feature funciona" e é indiferente a "a gente já faz assim nesta casa", porque não tem memória organizacional; com o agente solto, cada squad converge para uma arquitetura diferente. Os controles do método são três. **Decisões de arquitetura no repositório, onde o agente lê:** ADRs curtos ao lado do código, com linguagem mandatória ("você DEVE", não "você pode querer"), porque o agente ignora instrução que soa opcional. **Fitness functions:** testes automáticos de propriedades arquiteturais, na formulação de Ford, Parsons e Kua ("nenhum acesso a banco nesta camada", "esta fronteira não se atravessa"), com mensagens de erro que dizem como corrigir, para o agente se autocorrigir no mesmo ciclo. **Revisão humana para o drift de intenção:** a automação pega a violação de regra; o humano pega o código que tecnicamente segue a regra mas perde o espírito dela. A prova viva é o próprio repositório do site da Kazap, que opera assim: cada decisão relevante está em um ADR que o agente lê e respeita.

### Bibliotecas de Prompts: o que fica com o cliente

Engajamentos e treinamentos produzem **Bibliotecas de Prompts**: coleções validadas de prompts, especializações por linguagem e convenções de condução do agente, calibradas no contexto do cliente. São entregáveis: ficam com o time e evoluem com ele. Nasceram do piloto interno do método.

### Kazap CodeSense: o motor de contexto do método

O ponto cego de qualquer agente de IA é o contexto profundo. Uma IA com busca textual sabe ONDE uma palavra está no código, mas não sabe POR QUE está lá, quem a usa, nem o que quebra se ela mudar. O **Kazap CodeSense** ataca exatamente isso: indexa o repositório a cada merge e constrói um mapa semântico vivo (estrutura, dependências, modelo de dados e os trechos que mais mudam e concentram risco, os hot spots), que agentes como Claude Code, Codex, Copilot e Cursor consultam, incluindo a análise de impacto de uma mudança antes de fazê-la ("blast radius"). Roda na infraestrutura do cliente (self-hosted), com proteção de dados sensíveis (prevenção de vazamento de dados, ou DLP, para CPF/CNPJ/segredos), o que importa quando o código é um ativo crítico. O índice fica na infraestrutura que o cliente controla e, como em qualquer ferramenta de IA, trechos de código são processados nas APIs do provedor de modelo (inferência e embeddings), sob os termos que o cliente mantém com o provedor. A Kazap não retém nem armazena o código do cliente. Hoje é tecnologia que equipa o método, não produto à venda.

É a resposta honesta para a dor "adotamos Copilot ou Cursor e a IA quebra coisas no nosso monolito": o problema raramente é o modelo, e sim o contexto que ele não tem.

## Origem: piloto interno, hoje em produção

O método não nasceu de tendência. Ele foi desenvolvido em piloto interno com 5 desenvolvedores da Kazap, em três fases (Fundação, Experimentação e Maturação), antes de chegar a qualquer cliente. Hoje saiu do piloto: é o padrão de entrega da Kazap, e as squads em operação com clientes entregam com ele. A régua que isso preserva: o que vai para o código do cliente é método já validado; uma tendência não comprovada, a Kazap prova internamente primeiro, não no projeto do cliente. "Não testamos tendências no código dos clientes" é uma regra do método, e não um slogan.

Essa regra tem donos. A evolução e a calibração contínua do método são responsabilidade de sêniores da própria Kazap, os mesmos que entregam projetos com ele. Eles mantêm o material-base (manuais de operação, os playbooks; as Bibliotecas de Prompts de origem; o desenho da camada de controle) em dia com o que muda em ferramentas, modelos e práticas. O efeito para quem contrata: a squad alocada opera o método como é praticado hoje, não o playbook de quando o contrato foi assinado. É essa prática que alimenta a camada opcional de Atualização de fronteira, descrita na página de Treinamento do site kazap.com.br.

## De onde vem a obsessão por gates

A disciplina do método não é moda de IA. Anderson Peligrini, o fundador que o conduz, passou pelo CPqD, centro de pesquisa e desenvolvimento onde revisão estruturada, critério de done e auditoria de qualidade (o mundo CMMI) eram a prática, décadas antes dos agentes. Essa disciplina continua valendo com outros nomes: hoje se chama eval harness, gate de validação e revisão adversarial. A Squad Amplificada é a mesma exigência apontada para uma ferramenta nova.

## Quando faz sentido, e quando não

Faz sentido para produto digital com escopo definível e validação frequente: MVPs ambiciosos, módulos novos em sistemas existentes, modernização incremental de sistemas legados, produtos com IA embarcada. São contextos em que o que decide é estrutura e senioridade no comando, em vez de volume de gente genérica.

Não faz sentido (ou exige adaptação) para: ambientes com restrições regulatórias que exigem revisão humana formal de cada linha por política; times que precisam de presença física contínua; projetos abaixo de cerca de 4 semanas, em que o custo de montar o contexto (contexto de engenharia documentado, CI, eval harness) não se paga; e organizações sem nenhum patrocinador técnico interno (sponsor), já que o método precisa de um interlocutor que valide as entregas. A Kazap diz isso na primeira conversa e prefere indicar outro caminho a vender o formato errado.

## Formatos de engajamento

- **Entrega de módulo ou produto:** uma squad Kazap (sênior, pleno e júnior, com a senioridade no comando) conduz uma frente completa (módulo crítico, MVP, modernização) com o método, enquanto o time do cliente mantém o roadmap. Engajamentos a partir de cerca de 4 semanas.
- **Entrega + transferência:** a squad entrega e, em paralelo, prepara o time do cliente para operar o método. O repositório fica com contexto de engenharia documentado, verificações automáticas, CI e playbooks prontos.
- **Adoção do método pelo time do cliente:** quando o objetivo principal é capacitação e não entrega, o caminho é a Squad Amplificada · Formação (descrita na página de Treinamento do site kazap.com.br), que transfere o método com o código e os problemas reais do cliente.

## O case vivo: como o site kazap.com.br foi construído

O site kazap.com.br é o método aplicado à própria Kazap, documentado de ponta a ponta. A estrutura do projeto teve uma fase de fundação (alinhamento de posicionamento e de público, prova técnica da stack conversacional e contrato de métricas e gates entre os stakeholders), seguida de quatro frentes: a base de conhecimento, com rascunho assistido por Claude e curadoria humana; o backend do agente, com a economia do reaproveitamento de prompt em cache (prompt caching) medida pelos cabeçalhos da API; o frontend híbrido, com interface gerada pela conversa (Generative UI) e a telemetria pública de custo e latência ("Modo Bastidores"); e a frente final, com qualificação conversacional de interessados, agendamento e go-live.

Os mecanismos foram os do método de ponta a ponta, do planejamento dedicado de arquitetura ao eval harness rodando a regressão da base de conhecimento, com decisões e cortes registrados em ADRs, decisão a decisão. E os controles dispararam de verdade: na calibração antes do go-live, o primeiro run do eval com os casos novos reprovou, os casos foram corrigidos antes de ir ao ar, e a rodada está no histórico do repositório. A telemetria pública de custo e latência ("Modo Bastidores") expõe os dados reais de cada conversa: camadas de prompt, acerto e falha de cache (cache hit/miss), tokens, latência e custo por conversa.

O resultado: do conceito ao go-live em 10 semanas de trabalho efetivo (descontadas as pausas), conduzido por um engenheiro sênior com Claude Code, em dedicação parcial. É o método na menor escala possível. É o que um projeto real produziu, com processo auditável, e não uma fórmula que se transfere automaticamente para qualquer base de código, time ou domínio.

## Números e fatos verificáveis

- **O método está em produção, não em piloto:** é o padrão de entrega da Kazap; é com ele que as squads em operação com clientes entregam hoje. O que esse dado demonstra é maturidade de adoção. Resultados de clientes específicos ficam sob NDA, e o dado não é promessa de ganho. (A página de Cases do site kazap.com.br traz cases reais anônimos, um deles medido, com metodologia, além da carteira pública nomeada e do case vivo do próprio site; detalhes de projeto, só em conversa direta.)
- **O método capacita e estrutura a squad** (sênior, pleno e júnior): a senioridade lidera arquitetura, julgamento e a assinatura da entrega, e a estrutura ao redor amplifica cada nível, com os gates de qualidade como o que não muda. A ênfase é qualidade e consistência, não velocidade. O quanto isso altera o escopo entregue depende do projeto (base de código, time, domínio), e a Kazap não promete multiplicador fixo de produtividade.
- **Revisão adversarial em cada PR** e esteira de integração antes do merge: revisão numa sessão separada da autoria mais CI. É regra de processo; o que falha volta para correção.
- **Suíte de eval harness** que trava a regressão de comportamento do agente, cobrindo prompt injection, alucinação, qualificação de interessados, casos difíceis e fora de escopo, e roda no CI a cada mudança de prompt ou de base de conhecimento. A contagem de casos é exibida ao vivo no site kazap.com.br, derivada do banco real da suíte, e cresce junto com o agente.
- **10 semanas de trabalho efetivo do conceito ao go-live do site kazap.com.br**, conduzido por 1 engenheiro sênior com Claude Code, com premissa de dedicação parcial e contadas pelo próprio engenheiro, descontadas as pausas do projeto: o método na menor escala possível. É histórico de um projeto específico, com as premissas dele, não fórmula de produtividade nem promessa de resultado.
- **Decisões e cortes registrados em ADRs:** mais de 100 no projeto deste site, contadas no repositório. A trilha de decisão é rastreável e acompanha a entrega ao cliente.
- **Engajamentos típicos a partir de cerca de 4 semanas:** abaixo disso, o custo de montar o contexto (documentação de engenharia, CI, eval harness) não se paga.

## Perguntas frequentes

**O que é exatamente a Squad Amplificada?**
É o serviço de time alocado da Kazap: uma squad com sênior, pleno e júnior que trabalha com codificação assistida por agente de IA sob o método de mesmo nome, do planejamento antes do código à revisão adversarial de todo PR, com CI bloqueante e gates formais de validação humana. Quem assina é um humano sênior, e o tamanho da squad varia com o projeto.

**A Squad Amplificada substitui o time de desenvolvimento do cliente?**
Não, entrega junto. O formato mais comum é uma squad Kazap entregando um módulo crítico enquanto o time do cliente mantém o roadmap, ou o método sendo transferido para o time via treinamento. O que o método muda é o tipo de esforço: menos digitação e revisão mecânica, mais julgamento, arquitetura e decisão. Quem responde pelo produto continua humano e continua do cliente.

**O cliente escolhe quem entra na squad?**
A composição é responsabilidade da Kazap e sai do escopo: a squad entra montada, não é um cardápio de perfis. Os perfis são apresentados antes do início e revistos se o escopo mudar. O que não muda: a senioridade comanda arquitetura e julgamento, quem assina a entrega é um humano sênior e todo código passa pelos mesmos gates. Uma squad só de sêniores não é o formato; o que sustenta o padrão é a estrutura ao redor da squad inteira. Quando o cliente prefere resultado contratado em vez de time alocado, o formato certo é a Engenharia de Produto.

**Quem responde pelo código que a IA escreveu?**
A Kazap, contratualmente e na prática: o especialista que orquestra assina a entrega como assinaria código digitado por ele. O agente é ferramenta de produção, não parte responsável. E a responsabilidade vem instrumentada: revisão adversarial em todo PR, CI bloqueante, trilha de decisão em ADRs e, quando há agente em produção, eval harness com regressão contínua.

**O que acontece quando a IA erra?**
Ela erra; a pergunta certa é em que ponto o erro é pego. O método é desenhado para encurtar o ciclo: verificações automáticas pegam o erro na hora da escrita (segundos), a revisão adversarial pega no PR (minutos), o CI bloqueante pega antes do merge, o eval harness pega regressão de comportamento antes da publicação (deploy) e os gates humanos pegam erro de produto antes do go-live. Um erro que passa por cinco camadas existiria também num fluxo tradicional, com menos instrumentação para detectá-lo.

**Como funciona a revisão adversarial na prática?**
Cada PR passa por uma revisão crítica independente da sessão que escreveu o código, sem compromisso com o que foi escrito e com especialização por linguagem. Ela busca problemas de correção, segurança e manutenibilidade antes do merge. Somada ao CI bloqueante, nenhum código entra sem passar pelas duas.

**A Kazap trabalha com spec-driven development?**
Na substância, sim. Todo bloco de trabalho começa com uma etapa de arquitetura e especificação, fechada antes de qualquer linha. A especificação (spec) é o contrato entre quem decide e o agente que executa, o mesmo padrão de Desenvolvimento por Especificações (Spec-Driven Development) que a Formação transfere ao time. A diferença de ênfase: a especificação não é um documento longo que ninguém revisa; ela se converte em verificação (critério de done, testes derivados da especificação, eval harness quando há agente). O termo é recente, mas a disciplina vem da engenharia clássica.

**Como a qualidade se sustenta sem um segundo desenvolvedor humano revisando cada PR?**
Comparando camadas, não cargos. Um segundo dev dá uma revisão por PR, sujeita a cansaço e contexto parcial. O método dá quatro camadas de verificação: verificações automáticas na hora da escrita, revisão adversarial por sessão dedicada (consistente, cobre cada PR), CI bloqueante e eval harness para comportamento. O que a revisão humana tem de insubstituível, o julgamento de produto, permanece nos gates com stakeholders.

**As métricas de uso de IA viram ranking dos desenvolvedores?**
Não, e essa é regra declarada do método. A Kazap mede times e sistemas, nunca indivíduos. A atribuição de origem (o que veio da IA em cada PR) é diagnóstico de processo, não ranking de pessoa. E a separação entre "dado para o time melhorar" e "avaliação de desempenho" é um limite que o próprio time precisa conhecer, porque medição percebida como vigilância deixa de produzir dado confiável. Avaliação de pessoa continua sendo julgamento humano.

**O método cria dependência de um único fornecedor de IA?**
O método é mais portável que a ferramenta. O que fica no repositório (contexto de engenharia documentado, verificações automáticas, CI, eval harness, ADRs) é infraestrutura de processo que funciona com qualquer agente de código competente. A Kazap usa Claude Code por avaliação técnica de capacidade e segurança. Nas entregas com IA embarcada, a arquitetura isola o provedor: trocar de modelo é decisão de configuração, não reescrita. O trade-off: parte das verificações e da especialização por linguagem tem sintaxe específica da ferramenta, e migrar custaria dias de adaptação, não meses de reconstrução.

**O método se aplica a contextos regulados ou críticos?**
Depende do contexto, e a Kazap diz isso na primeira conversa. Há ambientes em que a política exige revisão humana formal de cada mudança. Nesses casos, o método se adapta (a revisão adversarial vira pré-filtro da revisão humana, não substituta) ou não se aplica. O que não muda em nenhum contexto: CI bloqueante e trilha de decisão documentada são o mínimo exigido, não o teto.

**A codificação assistida por IA não aumenta a dívida técnica?**
Sem governança, esse risco é real, e é exatamente por isso que o método existe. Revisão estruturada obrigatória, CI bloqueante, testes e documentação como parte do fluxo (e não como resíduo) são a proteção ativa contra a dívida silenciosa.

**O método faz sentido para times que já exploram IA internamente?**
Sim, e a exploração prévia é um bom sinal. O método não substitui essa exploração, soma-se a ela: transforma o que cada dev descobriu sozinho num padrão único de equipe, com governança e bibliotecas de prompts compartilhadas. A passagem da exploração individual para o padrão de equipe é justamente onde a maioria dos times trava.

**Qual o tamanho mínimo de projeto?**
Engajamentos a partir de cerca de 4 semanas. Abaixo disso, o custo de montar o contexto não se paga; nesse caso, a Kazap indica o caminho mais curto.

**O método funciona com qualquer stack?**
O método é agnóstico de conjunto de tecnologias (stack); a profundidade da especialização por linguagem varia. A Kazap tem prática forte em Rust, Python, Ruby e TypeScript (com Axum, Rails e Next.js entre os frameworks). Para outras stacks, a avaliação de aderência é feita na primeira conversa, sem compromisso.

**Onde é possível ver o método aplicado de ponta a ponta?**
No próprio site kazap.com.br. O processo de construção está documentado em roadmap e ADRs, e a telemetria pública de custo e latência ("Modo Bastidores") mostra a engenharia do agente funcionando ao vivo: camadas de prompt, cache, tokens, latência e custo por conversa. O agente conversacional do site responde sobre qualquer parte da construção.

**A Kazap treina times para operar o método internamente?**
Sim, com a Squad Amplificada · Formação, em três formatos: imersão em 3 marcos (carga base de aproximadamente 24 horas, com distribuição flexível), acompanhamento de 6 semanas e formação de multiplicadores (train the trainer), sempre sobre o repositório real do cliente. Os detalhes estão na página de Treinamento do site kazap.com.br.