skip → content

AZARIAS_TECH // V2.6

OK

auditoria técnica · mvp construído com ia

Seu MVP foi acelerado com IA. A gente verifica se ele aguenta produção de verdade.

Copilot, Cursor e Claude tiram produto do chão em semanas. Também costumam deixar chave no frontend, N+1 no ORM e loop de tokens comendo margem. A Azarias não entra para escrever a próxima feature. Abre o repositório, aponta o que quebra e devolve a ordem de correção.

  • Não vendemos banco de horas
  • Não entregamos PDF genérico
  • Sim — diagnóstico + sessão ao vivo

01 — o problema

O código sai rápido. A falha fica escondida.

IA gera o caminho feliz. Produção é outra história: carga real, webhook forjado, cron que chama o modelo de novo porque ninguém colocou teto. Em repo de seed e série A o padrão se repete. Não é “dívida técnica” genérica — é código acelerado sem revisão de concorrência, superfície e custo.

P0 · secret

Chave no client e no histórico do git

Variável pública no Next, define no Vite, .env.example com valor real. O modelo copia o padrão do tutorial. Qualquer um abre o bundle e vê a key — e o commit antigo ainda está no GitHub.

P1 · lock

ORM ok no notebook, pool morto sob carga

findAll + forEach(find) em /orders. Cinco conexões no pool, fila estourando, lock em 1.4s no p95. O índice (user_id, created_at) nunca foi criado porque ninguém pediu na pressa do lançamento.

P2 · custo

Retry sem teto engole a margem

Timeout alto, três retries, embedding recalculado a cada request, job pesado no meio da requisição. Uma boa parte dos tokens do mês some num loop que a IA escreveu “para ficar resiliente”.

02 — para quem

Quem costuma nos procurar

founder

Quer saber se o produto aguenta o próximo lançamento ou uma rodada — sem montar um time de plataforma só para isso.

cto / tech lead

Herda um repo feito em sprint com IA e quer um segundo olhar, com evidência no código — não opinião solta no Slack.

investidor / counsel

Precisa de um material claro de risco: o que é crítico, o que pode esperar e o que já tem dono e prazo.

03 — método

Automação para achar. Engenharia para decidir.

Ferramenta sozinha gera barulho. Só olho humano demora demais. A gente usa scan de secrets, rotas e queries — e depois decide o que é urgente de verdade.

  1. 01

    Conversa inicial (30 min)

    Entendemos o stack, o que está em jogo (lançamento, campanha, rodada) e o que está fora de escopo. Sem discovery de slide deck.

  2. 02

    Acesso mínimo ao repositório

    Somente leitura. NDA se você quiser. Sem produção, sem dump de cliente e sem instalar nada no seu ambiente.

  3. 03

    Auditoria em camadas

    HTTP, secrets, auth, modelagem, locks, jobs, integrações e custo de nuvem. O scan aponta candidatos; a revisão humana corta o ruído.

  4. 04

    Relatório + sessão ao vivo

    Em cerca de 90 minutos com o time, passamos cada P0: arquivo, linha, impacto e primeira correção. Você sai com uma fila clara, não com um parecer vago.

04 — o relatório

Algo que o time e o board conseguem usar

Não é um zip de prints. É um relatório web com gravidade, evidência, correção sugerida e prazo. Abaixo, um recorte anonimizado de um marketplace B2B feito com assistência de IA (Next.js + Prisma + OpenAI).

live_session // acme-mvp @ 7f3a1c2

03

Vulnerabilidades P0

1.4s

Query Lock Time

38%

Token Drain

01 // azarias.audit github.com/acme/mvp

02 scan.secrets() 3 live keys no bundle do cliente

03 scan.orm() N+1 em GET /orders · lock 1.4s

04 scan.llm() 38% dos tokens em retry cego

05 next: open security_leak.log

Abrir relatório de exemplo →

05 — o que entra na auditoria

Quatro frentes que a gente cobre

Superfície & chaves

CORS aberto demais, webhook sem assinatura, rota de admin fora do matcher, API keys no bundle e no CI. Mapeamos o que um estranho vê em pouco tempo — incluindo aquele TODO “proteger depois” que o Copilot deixou no código.

Concorrência & banco

N+1 no Prisma/Drizzle/Sequelize, transação longa, índice que a migration não criou, pool pequeno demais. Olhamos o caminho quente do produto, não só o fluxo feliz do seed.

FinOps & token drain

Retry sem limite, embeddings recalculados, tools chamando o modelo em loop, jobs no meio da request. O relatório mostra onde o dinheiro some — na linha de código, não só no painel da AWS.

Preparação para due diligence

P0 com dono e prazo, superfície autenticada, evidência reproduzível. Serve para o founder priorizar e para o investidor não tratar o repo como caixa-preta.

06 — engajamento

Três níveis de profundidade

health_check

48–72h

Leitura do repositório, dependências, secrets e superfície de API. Resposta direta: aguenta o próximo passo ou não. Entrega: relatório curto com semáforos e os cinco itens que não podem esperar.

deep_audit *

7–14 dias · recomendado

Arquitetura, concorrência, custos e preparação para due diligence. Relatório completo, roadmap P0–P2 e sessão de cerca de 90 minutos com fundadores ou board técnico.

execution_sprint

2 semanas · opcional

Depois do diagnóstico, pairing nas P0. O time de vocês segue no comando; a gente ajuda a fechar as correções que realmente reduzem risco — sem virar a software house da empresa.

07 — perguntas frequentes

Vocês reescrevem o produto?

No diagnóstico, não. O sprint de execução é opcional e foca só nas P0 do relatório. O restante continua com o time de vocês.

Precisam de acesso à produção?

Não. Só o repositório em leitura. Staging ajuda, mas não é obrigatório. Dados de cliente ficam fora do escopo.

E se já temos CTO?

Melhor ainda. O relatório é apoio para o time, não substituto. O CTO participa da sessão; a gente traz o segundo olhar e a evidência no código.