# Engenharia de Produto — Kazap

Engenharia de produto para sistemas onde o erro custa caro: desenvolvimento de software sob medida, com plataformas B2B ponta a ponta, sistemas críticos em Rust e modernização de legado, para médias empresas e operações enterprise. Esta página descreve o que a frente cobre, como os projetos rodam e quais fatos são verificáveis.

## Essência

A Kazap constrói software sob medida desde 2008 para operações onde indisponibilidade custa dinheiro e erro custa reputação, com experiência acumulada em 12 segmentos, de fintech a healthtech. As histórias completas, identificadas por segmento e anônimas por acordo de confidencialidade, estão na página de Cases. É esse histórico que define a frente de engenharia. Quatro práticas são o padrão mínimo de qualquer entrega, e não extras de proposta: uma esteira automática que só deixa o código entrar se passar nos testes (CI bloqueante), uma revisão independente que tenta quebrar o que foi feito (revisão adversarial), visibilidade do que acontece em produção, com logs, métricas e rastreamento (observabilidade), e roteiros de operação para quando algo quebrar (runbooks). Como formato de engajamento, Engenharia de Produto é projeto de escopo fechado: o cliente contrata o resultado. Quando a necessidade é um time dedicado entrando na operação, o formato é a Squad Amplificada (time alocado).

Alguns princípios atravessam tudo o que essa frente entrega. Não fazemos virada de tudo de uma vez (big bang): as migrações acontecem por estrangulamento progressivo, com o sistema antigo validando o novo em produção. Também não vendemos reescrita total como modernização, nem adotamos a tecnologia da moda sem que o volume e a exigência reais do sistema a justifiquem. Escolhemos a tecnologia pelo perfil do problema: Rust onde latência e correção mandam, TypeScript/Next.js onde velocidade de entrega manda. E cada decisão relevante vira um registro de decisão de arquitetura (ADR) no repositório, porque a trilha de decisão é parte da entrega.

O que mudou nos últimos anos foi onde o tempo sênior é gasto, e não o rigor. Todo projeto de engenharia da Kazap roda no método Squad Amplificada: uma squad capacitada e estruturada (sênior, pleno e júnior) com codificação assistida por agente de IA (hoje majoritariamente Claude Code; também Codex e ferramentas afins), planejamento dedicado, execução em paralelo e revisão adversarial em cada proposta de mudança no código (PR, pull request). A senioridade comanda arquitetura, julgamento e a assinatura da entrega; a estrutura amplifica cada nível. O cliente paga por julgamento e arquitetura, porque a digitação deixou de ser o gargalo. O próprio site da Kazap é o exemplo mais recente e auditável do método em ação. Ele foi construído com esse mesmo processo e pode ser verificado ao vivo, do agente conversacional à telemetria pública de custo e latência ("Modo Bastidores"). A trilha de decisões do projeto é apresentada em reunião.

## Plataformas B2B ponta a ponta

Produtos digitais completos, do design system à infraestrutura. O padrão de qualidade é objetivo e medível: performance entra como requisito de aceite, não como aspiração. Cada projeto tem um orçamento para o tempo de exibição do maior elemento visível da página (LCP, Largest Contentful Paint), acordado por projeto e medido no percentil 75 de campo (p75), ou seja, sobre dados de usuários reais e não apenas em laboratório. Tudo o que vai para a web tem, como piso, nota acima de 90 no Lighthouse mobile, a auditoria automatizada de qualidade de páginas do Google.

O SEO técnico (otimização para mecanismos de busca) entra no desenho desde o início, e não como ajuste posterior (retrofit): renderização estática ou no servidor (SSR) onde importa, dados estruturados e conteúdo legível por robôs de busca (crawlers) fazem parte do código. A stack típica do front é TypeScript com Next.js, escolhidos pela velocidade de entrega combinada com um ecossistema maduro.

## Sistemas críticos em Rust: quando vale e quando não

Rust é a escolha da Kazap para backends onde latência e correção mandam: motores de decisão, processamento de eventos de alto volume, APIs de missão crítica. As razões são de engenharia, não de moda:

- **Previsibilidade de latência.** Rust não usa coletor de lixo (garbage collector, GC) e, portanto, não tem as pausas que ele provoca. O tempo de resposta no percentil 99 (P99) fica previsível, o que importa quando o SLA é medido em milissegundos.
- **Correção em tempo de compilação.** O sistema de tipos e o verificador de empréstimos de memória (borrow checker) eliminam classes inteiras de bugs (memória, concorrência) antes do deploy. Em sistema crítico, isso significa que esses erros são barrados na compilação, antes de virarem incidente em produção.
- **Custo de infraestrutura.** Sem pausas de GC, o consumo de memória (footprint) e o P99 ficam previsíveis. Em algumas cargas de trabalho de alto volume, isso reduz a contagem de instâncias frente a equivalentes com garbage collector. A previsibilidade de latência é o motivo recorrente da escolha em caminhos críticos.

**Quando Rust não vale.** Dizemos isso na primeira conversa: sistemas de cadastro e consulta de volume moderado (CRUD), back-offices, primeiras versões de produto (MVPs) que precisam validar hipótese rápido e contextos em que o time do cliente vai manter o código sem experiência (nem interesse) em Rust. Nesses casos, TypeScript/Node resolve com melhor velocidade de entrega e um pool de contratação maior.

Essa escolha tem um case medido, publicado na página de Cases da Kazap: o pipeline de visão computacional de uma plataforma de busca por características visuais de imagens (features) foi reconstruído em Rust, a partir de Python, e caiu de horas para segundos no mesmo conjunto de dados (dataset). Os números e a metodologia completa estão na página Cases. É a medição de um engajamento específico, nunca uma fórmula de multiplicador.

## Modernização de legado por estrangulamento progressivo

A regra inegociável: nunca virar tudo de uma vez (big bang). Na experiência da Kazap, reescrita total com data de virada é uma das formas mais arriscadas de modernizar um sistema, porque o novo estreia sem o conhecimento acumulado de anos de produção do antigo. O método da Kazap segue o padrão que a literatura chama de estrangulamento progressivo (strangler fig) e tem seis etapas:

1. **Auditoria curta de arquitetura e débito técnico.** Mapa do sistema, ordem de ataque por risco × valor, plano com fatias pequenas.
2. **Registro do comportamento atual (golden master) antes de tocar fluxo crítico.** Onde o legado tem pouca cobertura de testes e o comportamento atual é a fonte da verdade, esse comportamento é capturado **antes** de qualquer mudança, com testes de caracterização, na técnica que Michael Feathers descreveu para código legado. O princípio é caracterizar o comportamento, não entendê-lo: não é preciso compreender anos de código para protegê-lo, basta capturar fielmente o que ele faz hoje (entrada → saída). O desenho evita uma armadilha: deixar o agente de IA escrever os testes a partir do código que ele mesmo gerou. A captura vem do comportamento observado. A partir daí, qualquer mudança de comportamento acende um alarme. Se foi acidente, é corrigida; se foi deliberada, é aprovada conscientemente. O maior risco da modernização assistida por IA é a mudança silenciosa de comportamento, e esta etapa existe para que ela não aconteça.
3. **Estrangulamento por fatias.** Cada capacidade do legado é extraída individualmente para o sistema novo, atrás de uma camada de roteamento. O monolito encolhe módulo a módulo.
4. **Tráfego espelhado (shadow traffic).** Antes de assumir tráfego real, o componente novo recebe uma cópia espelhada do tráfego de produção, e suas respostas são comparadas às do legado. Cada divergência é um bug encontrado antes de afetar usuário. A técnica se aplica diretamente a caminhos de leitura e de comparação determinística. Em fatias que escrevem dados ou disparam efeitos colaterais (banco, cobrança, e-mail, API de terceiros), o desenho isola as escritas (banco sombra, efeitos colaterais neutralizados) ou usa reprodução (replay) ou escrita dupla (dual-write) de forma controlada. As duas técnicas se completam: o golden master protege a unidade; o shadow traffic protege a borda.
5. **Reversão automática (rollback).** Cada etapa de migração tem critério de saúde objetivo e reversão automática. Avançar exige uma decisão; voltar acontece automaticamente.
6. **O antigo só desliga quando o novo já provou que aguenta** em produção, com métricas, e não em homologação.

O padrão de referência: a operação nunca para durante a reescrita. A paridade é provada por shadow traffic antes de qualquer troca definitiva (cutover), com rollback automático armado em cada etapa.

### O primeiro artefato: o mapa do sistema

Toda modernização começa por um mapeamento semântico do código (codebase): grafo de dependências, modelo de dados, trechos que mais mudam e concentram risco (hot spots) e zonas de risco. Esse mapa é produzido com o Kazap CodeSense, o motor de contexto do método (o mesmo descrito na página da Squad Amplificada). O CodeSense indexa o repositório e expõe a agentes de codificação como Claude Code, Codex, Copilot e Cursor um mapa vivo da arquitetura, incluindo a análise do impacto de cada mudança antes que ela seja feita ("blast radius").

Ele roda em modo auto-hospedado (self-hosted), com proteção de dados sensíveis (prevenção de vazamento de dados, ou DLP) para CPF, CNPJ e segredos. Isso importa quando o código é um ativo crítico: o índice fica na infraestrutura que o cliente controla. Como em qualquer ferramenta de IA, trechos de código são processados nas APIs do provedor de modelo, sob os termos que o cliente mantém com o provedor; a Kazap não retém nem armazena o código do cliente. É o que transforma "ninguém entende mais esse sistema" em um plano de estrangulamento com ordem de ataque defensável. Hoje o CodeSense é tecnologia que equipa o método, e não um produto à venda.

## Padrão de entrega: o mínimo de qualquer projeto

Independente do projeto, toda entrega da Kazap inclui:

- **CI bloqueante.** Nenhum código entra na base principal (merge) sem a esteira automática (pipeline) verde: testes, verificação automática de estilo e erros comuns (lint), clippy (em Rust) e auditoria de dependências. O que falha volta para correção.
- **Revisão adversarial em todo PR.** Uma revisão crítica, feita em sessão separada da autoria, examina cada PR antes do merge. Assim, o erro é pego enquanto ainda é barato de corrigir.
- **Observabilidade desde o dia um.** Logs estruturados, métricas e rastreamento (tracing) são parte do escopo, não do pós-venda, porque sem telemetria não há como operar o sistema com segurança.
- **Runbooks.** O que fazer quando algo quebrar, escrito por quem construiu. A entrega inclui a capacidade de operar o sistema, não só o binário.
- **ADRs.** Decisões de arquitetura registradas no repositório, para que quem chegar depois entenda não só o quê, mas o porquê.
- **Testes que pegariam um bug, não cobertura de vaidade.** O modo de falha da era da IA é a "tautologia verde": o agente escreve o teste a partir do código que ele mesmo gerou, o teste valida que o código faz o que o código faz, a cobertura sobe e nenhum bug é pego. O método tem três respostas. Os testes derivam da especificação (da intenção), não do código gerado. A cobertura é tratada nos caminhos críticos, não como número global. E, nos fluxos em que o custo de um bug justifica, o método pede **testes de mutação (mutation testing)**: estragar o código de propósito (trocar um maior-que por maior-ou-igual) e verificar se algum teste percebe. O contrato de cobertura não é o número, e sim a pergunta "um bug aqui seria pego antes de produção?". Há um custo: mutation testing é caro, por isso roda de forma incremental, depois da integração, nos caminhos críticos.

Depois da entrega, há dois caminhos: operação contínua pela Kazap ou transferência total para o time do cliente, com treinamento incluído. Não existe entrega que cria dependência por desenho.

## Como todo projeto roda: o método Squad Amplificada

Todo projeto de engenharia da Kazap usa o método Squad Amplificada: uma squad capacitada e estruturada (sênior, pleno e júnior) com codificação assistida por agente de IA (hoje majoritariamente Claude Code), planejamento dedicado para arquitetura antes de qualquer código, execução em paralelo real entre backend, frontend e infraestrutura, revisão adversarial em cada PR e etapas de validação humana (gates). Arquitetura, julgamento e responsabilidade pela entrega ficam com a senioridade; a estrutura amplifica cada nível.

Na prática, o efeito é senioridade no comando, padrão sustentado pela estrutura e trilha de decisão completa, com ênfase em qualidade e consistência, não em velocidade. Quem assina a entrega é sempre um humano sênior. Os detalhes do método estão na página Squad Amplificada.

## Números e fatos verificáveis

- **Stack-foco oficial (linguagens): Rust, Python, Ruby e TypeScript.** Os frameworks são escolhidos por projeto (Axum, Rails, Next.js, entre outros); o compromisso é com a linguagem.
- **Desenvolvimento mobile faz parte do escopo de Engenharia de Produto**: nativo em Swift (iOS) e Kotlin (Android), ou multiplataforma em React Native e Flutter. A escolha é por projeto, pelo perfil do produto. Não é uma linha de serviço separada: entra no projeto de engenharia com o mesmo padrão de qualidade do restante.
- As demais tecnologias do histórico da Kazap (Java, desktop) são experiência do time, sob consulta.
- **Migrações sem indisponibilidade (downtime) por desenho.** Estrangulamento progressivo com shadow traffic e rollback automático em cada etapa; o legado só desliga quando o novo provou em produção.
- **Lighthouse mobile acima de 90 como piso** em tudo o que a Kazap entrega para a web, verificável em qualquer entrega pública, incluindo o próprio site da Kazap.
- **Toda mudança passa pela esteira de integração e por revisão adversarial antes do merge** (testes, lint, clippy em Rust, auditoria de dependências); o que falha volta para correção.
- **Um caso auditável de escopo:** o site da Kazap foi do conceito à entrada em produção (go-live) em 10 semanas de trabalho efetivo, com um engenheiro sênior em dedicação parcial: o método na menor escala possível. O número descreve esse projeto específico, com o escopo e as condições dele. Não é uma fórmula de produtividade nem um multiplicador que se transfira para qualquer outro projeto.

## Perguntas frequentes

**Por que Rust, e não Go ou Node?**
Depende do problema, e essa é a resposta honesta. Node/TypeScript é ótimo para a maioria das aplicações web e back-offices, e a Kazap usa extensivamente. Go é uma escolha respeitável para serviços de rede e resolve bem essa classe de problema. Rust entra onde importam latência previsível (sem coletor de lixo), correção em tempo de compilação e custo de máquina: motores de decisão, alto volume, missão crítica. A Kazap padronizou em Rust nessa faixa porque profundidade em uma stack gera mais qualidade do que superficialidade em três. E quando o problema não pede Rust, dizemos isso: não faz sentido pagar a curva de aprendizado e o custo de contratação à toa.

**Quem mantém o sistema depois da entrega?**
O contrato de entrega trata exatamente dessa preocupação: todo projeto sai com observabilidade, runbooks, CI completo e ADRs, porque a capacidade de operar é parte do escopo, não do pós-venda. A partir daí, o cliente escolhe entre operação contínua pela Kazap ou transferência total para o time interno, com treinamento incluído, inclusive no método Squad Amplificada, se o cliente quiser internalizá-lo. Dependência por desenho não é um modelo de negócio que a Kazap pratica.

**É possível modernizar um sistema que ninguém entende mais?**
Esse é precisamente o cenário do estrangulamento progressivo: o método existe porque mexer direto em um sistema assim é arriscado demais. O núcleo não é tocado de primeira. Primeiro vem a auditoria; depois, a extração da fatia de menor risco atrás de uma camada de roteamento e a validação com shadow traffic (sem afetar usuário); só então entra o tráfego real, com rollback automático armado. O legado vira a especificação viva do sistema novo. É o desenho certo justamente para o sistema "intocável", que só deixa de ser intocável quando o substituto provou paridade em tráfego real.

**A modernização exige reescrever tudo ou parar o roadmap?**
Não. A Kazap não propõe reescrita nem parada. O estrangulamento é incremental por natureza: fatias pequenas, cada uma entregando valor ou removendo risco antes de a próxima começar, enquanto o time do cliente mantém o roadmap em paralelo. E se a auditoria mostrar que o legado aguenta mais dois anos com intervenções pontuais, é isso que vamos recomendar.

**Uma squad assistida por IA dá conta de projeto de grande porte?**
A primeira resposta está no histórico, e não no tamanho do time: a Kazap entrega software para operações críticas desde 2008, em 12 segmentos, e as histórias completas estão na página de Cases. O tamanho da squad é dimensionado por projeto, e quem assina a entrega é sempre um humano sênior. A qualidade vem da estrutura, e não de esforço heroico: revisão adversarial em todo PR, CI bloqueante e etapas de validação humana. O site da Kazap é o exemplo mais transparente disso: o método pode ser auditado ao vivo, do agente conversacional à suíte de avaliação (evals) que o testa. E onde o formato não serve (regulação extrema, exigência de presença física contínua), dizemos isso na primeira conversa.

**Como a Kazap garante que a IA não quebra o que já funciona?**
Garantia absoluta ninguém dá. O que existe é mitigação por desenho, em camadas. Nos fluxos críticos do legado, o comportamento atual é capturado antes de qualquer mudança (golden master), e qualquer diferença de comportamento acende alarme no mesmo ciclo em que o agente trabalha. No caminho até produção, cada camada cobre um ponto: verificações automáticas na escrita, revisão adversarial no PR, CI bloqueante no merge e shadow traffic na borda. O golden master cobre a unidade, e o shadow traffic cobre a borda. Mudança silenciosa de comportamento é exatamente o risco que esse desenho ataca.

**Como confiar em testes que a própria IA escreveu?**
Não confiamos por padrão: desenhamos contra o risco. Teste escrito a partir do código que o próprio agente gerou é tautologia, porque valida que o código faz o que o código faz e dá verde sem proteger nada. Por isso os testes derivam da especificação, escrita no planejamento dedicado antes de qualquer linha de código, e não do código gerado. A revisão adversarial examina os testes como examina o código. E, nos caminhos críticos, o método pede mutation testing: pequenas mutações feitas de propósito para verificar se a suíte percebe. Na literatura da disciplina há caso documentado de arquivo com 100% de cobertura em que 13 mutações sobreviveram sem nenhum teste falhar (Birgitta Böckeler, Thoughtworks). Cobertura alta com teste fraco é vaidade; o contrato é a pergunta "um bug aqui seria pego antes de produção?".

**A Kazap pega projeto já em andamento?**
Sim. O trabalho começa com uma auditoria curta de arquitetura e débito técnico; a Kazap devolve um plano com ordem de ataque e assume a frente combinada, sem refazer o que funciona.

**O que é shadow traffic, na prática?**
O componente novo recebe uma cópia do tráfego real de produção e responde em paralelo ao legado, sem afetar nenhum usuário. As respostas são comparadas automaticamente, e cada divergência é um bug encontrado antes da troca (switch). O componente novo só assume o tráfego depois que a comparação fica limpa, e com rollback automático armado. Onde a fatia escreve dados ou tem efeito colateral (banco, cobrança, e-mail, integração externa), a escrita não é duplicada em produção: ela é isolada num banco sombra, os efeitos colaterais são neutralizados ou se usa replay ou dual-write de forma controlada. A técnica se adapta à natureza da fatia.

**Qual é a stack da Kazap?**
Rust (Axum) para backends críticos; TypeScript e Next.js para web e serviços de exigência moderada; PostgreSQL como padrão de persistência; Kafka onde há processamento de eventos. Em modernização, a Kazap integra o que o legado já usa (Oracle, SQL Server, MongoDB, Redis), sem exigir troca de banco como pré-requisito. Quando relevância e escala de busca mandam, entram soluções de busca dedicadas (Elasticsearch, Solr, Meilisearch). Cloud e operação fazem parte da entrega, não do pós-venda: AWS e GCP, containers e Kubernetes, com observabilidade desde o dia um. A escolha é sempre pelo perfil do problema, e o porquê fica registrado em ADR.

**A Kazap faz só backend, ou produto completo?**
Produto completo quando faz sentido: design system, frontend, backend e infraestrutura. Também atua em frentes isoladas (um módulo crítico, uma migração), integrada ao time do cliente.

**Quanto tempo leva um projeto típico?**
Depende do escopo. Os engajamentos partem de cerca de 4 semanas; abaixo disso, o custo de montar o contexto (overhead) não compensa. Para chegar a uma estimativa, o caminho é contar o contexto pelo chat do site ou pela página de contato: com um resumo do que precisa ser construído ou modernizado, o time da Kazap devolve um plano com estimativa.