DEV Community

Cover image for Do "Ok" ao "Termonuclear": Elevando a Barra do Code Review com IA
Fazedor de Codigo profile image Emerson Delatorre
Emerson Delatorre for Fazedor de Codigo

Posted on

Do "Ok" ao "Termonuclear": Elevando a Barra do Code Review com IA

#ai #codereview #mattpocock #cursor

Se você programa profissionalmente, provavelmente já usa IA para gerar trechos de código, preencher boilerplates ou acelerar refatorações pequenas. Mas se a sua rotina de revisão automatizada ainda se resume a caçar vírgulas perdidas, discutir nomenclatura ou repetir checklist cosmético, você está deixando muito dinheiro — e muita sanidade mental — na mesa.

A revisão automatizada com IA só fica realmente poderosa quando deixa de perguntar “o código compila?” e passa a perguntar “esse design merece existir?”. É aqui que entra a mentalidade de Code Review Termonuclear: uma revisão agressiva, estrutural e ambiciosa, voltada para cortar complexidade antes que ela se espalhe pelo projeto.

Essa abordagem ganhou força no ecossistema do Cursor por meio da skill Thermo-Nuclear Code Quality Review, divulgada em discussões recentes sobre agentes de programação. A ideia central é simples: em vez de usar o agente como um linter mais educado, você o instrui a agir como um revisor sênior que questiona arquitetura, fronteiras de tipos, modularidade, testabilidade e acúmulo de complexidade.

Neste artigo, vou reconstruir essa abordagem de forma prática e atualizada para o Cursor, usando os mecanismos corretos da ferramenta hoje: Project Rules, User Rules, Agent Skills e Bugbot.

Por que a maioria dos agentes de IA falha no code review?

Quando você entrega um diff — as linhas alteradas em uma branch — para um LLM convencional, ele tende a se comportar de forma tímida. O agente olha apenas para o trecho alterado, verifica se a sintaxe parece plausível e, no máximo, aponta um detalhe local.

Esse comportamento é insuficiente.

Um bom revisor não avalia apenas a linha adicionada. Ele pergunta:

  • Essa mudança reforça ou enfraquece a arquitetura?
  • O código novo espalha exceções e condicionais pelo sistema?
  • O tipo usado representa a realidade do domínio ou só silencia o compilador?
  • A implementação ficou mais testável ou mais acoplada?
  • Existe uma refatoração menor que eliminaria uma categoria inteira de problemas?

A revisão termonuclear começa justamente nesse ponto. Ela usa o diff como ponto de partida, mas não se limita a ele. O objetivo é fazer o agente olhar para o entorno do código e identificar sintomas de deterioração estrutural.

Princípio central: não aprove código apenas porque ele funciona. Código que funciona, mas piora o design, está comprando dívida técnica com juros compostos.

O que torna uma revisão “termonuclear”?

Uma revisão termonuclear não é uma revisão grosseira. Ela é rigorosa, explícita e estrutural. O agente recebe critérios claros para rejeitar soluções frágeis, mesmo quando elas parecem funcionar no curto prazo.

Abaixo estão os padrões mais importantes.

1. A regra das mil linhas

Arquivos muito grandes são ruins para humanos e para agentes de IA.

Quando um arquivo passa de 1.000 linhas, ele normalmente deixa de representar um conceito claro e começa a acumular responsabilidades. Isso torna a navegação mais lenta, a revisão mais cara e o contexto mais difícil de carregar em uma conversa com IA.

A regra não deve ser interpretada de forma infantil. Não significa quebrar arquivos mecanicamente só para reduzir o número de linhas. Significa questionar por que aquele arquivo ficou tão grande.

Boas perguntas para o agente fazer:

  • Esse arquivo mistura orquestração, regra de negócio, validação e acesso a dados?
  • Existe uma fronteira natural que permitiria separar responsabilidades?
  • O nome do arquivo ainda descreve bem tudo o que ele contém?
  • A divisão proposta melhora a leitura ou apenas espalha a complexidade?

A divisão de arquivos deve criar contexto, não esconder bagunça.

2. Combate a código espaguete e condicionais ad hoc

Um dos sinais mais claros de deterioração arquitetural é o crescimento de condicionais específicas:

if (user.type === 'admin') {
  // regra especial
} else if (user.type === 'partner') {
  // outra regra especial
} else if (featureFlag && user.region === 'BR') {
  // exceção dentro da exceção
}
Enter fullscreen mode Exit fullscreen mode

Esse tipo de código costuma surgir como solução rápida. O problema é que cada nova exceção torna a próxima mudança mais arriscada.

Uma revisão termonuclear deve questionar se a lógica deveria estar em outro formato, como:

  • uma state machine;
  • um objeto de política;
  • uma tabela de decisão;
  • uma estratégia por tipo de usuário;
  • uma camada explícita de domínio;
  • uma configuração declarativa em vez de condicionais imperativas espalhadas.

O objetivo não é trocar if por abstração desnecessária. O objetivo é impedir que exceções locais virem arquitetura acidental.

3. Fronteiras de tipos rígidas

Em TypeScript, um agente de IA tende a usar atalhos para fazer o código “passar”. Os atalhos mais comuns são:

any
unknown
as SomeType
Partial<T>
Record<string, any>
Enter fullscreen mode Exit fullscreen mode

Esses recursos não são proibidos em absoluto, mas devem ser tratados como sinais de alerta.

A revisão deve perguntar:

  • O tipo representa o contrato real ou apenas evita erro do compilador?
  • Esse any está escondendo uma integração mal modelada?
  • Esse as é inevitável ou está mascarando uma inconsistência?
  • A propriedade é realmente opcional ou virou opcional para evitar corrigir o fluxo?

Um erro muito comum é transformar dados obrigatórios em opcionais:

interface User {
  id?: string;
  email?: string;
}
Enter fullscreen mode Exit fullscreen mode

Se id e email são obrigatórios para o sistema funcionar, o tipo deve expressar isso:

interface User {
  id: string;
  email: string;
}
Enter fullscreen mode Exit fullscreen mode

Opcionalidade artificial espalha incerteza. E incerteza espalhada gera código defensivo, condicionais redundantes e testes mais frágeis.

4. Orquestração paralela vs. sequencial

Outro ponto que uma revisão comum costuma ignorar é a execução sequencial desnecessária.

Exemplo ruim:

const profile = await loadProfile(userId);
const permissions = await loadPermissions(userId);
const preferences = await loadPreferences(userId);
Enter fullscreen mode Exit fullscreen mode

Se essas operações são independentes, elas podem rodar em paralelo:

const [profile, permissions, preferences] = await Promise.all([
  loadProfile(userId),
  loadPermissions(userId),
  loadPreferences(userId),
]);
Enter fullscreen mode Exit fullscreen mode

Uma revisão termonuclear deve procurar esse tipo de desperdício. Nem toda sequência é errada, mas toda sequência independente merece ser questionada.

5. Testabilidade como critério de aprovação

Este é um ponto que muitas skills de revisão deixam fraco: testes.

Não basta perguntar se o código está “limpo”. O agente precisa perguntar se o código é testável.

Critérios úteis:

  • A regra de negócio pode ser testada sem subir infraestrutura?
  • Existem pontos de costura para substituir dependências externas?
  • A mudança adiciona comportamento sem adicionar teste?
  • O teste cobre o caso feliz e os casos de borda relevantes?
  • A refatoração preserva cobertura de comportamento?

Um bom code review automatizado não deve aprovar uma mudança crítica em backend, autorização, pagamentos, dados, integrações ou regra de negócio sem questionar testes.

O conceito de “code judo”

Uma das ideias mais fortes da revisão termonuclear é o code judo.

No judô, você usa a força do adversário para derrubá-lo com o mínimo de esforço. No código, um movimento de judô é uma refatoração pequena que elimina uma classe inteira de problemas.

Exemplos:

  • remover uma camada de helper em vez de criar mais um helper;
  • substituir múltiplos booleanos por um estado explícito;
  • trocar condicionais espalhadas por uma tabela de decisão;
  • mover uma regra para o tipo correto em vez de duplicá-la nos consumidores;
  • deletar uma abstração genérica que só é usada em um lugar;
  • transformar um fluxo implícito em uma interface clara.

A pergunta que o agente deve fazer é:

Existe uma mudança menor e mais profunda que elimina complexidade em vez de apenas reorganizá-la?

Essa pergunta é a diferença entre uma revisão cosmética e uma revisão arquitetural.

Como aplicar isso no Cursor hoje

Aqui é importante atualizar o vocabulário.

O Cursor já teve exemplos populares baseados em .cursorrules, mas o caminho recomendado atualmente para regras de projeto é usar Project Rules dentro de .cursor/rules. Para instruções globais, use User Rules. Para workflows especializados e reutilizáveis, use Agent Skills. Para revisão automática de Pull Requests, use Bugbot.

Abaixo está o fluxo atualizado.

Opção 1: Project Rules em .cursor/rules

Use Project Rules quando quiser regras específicas de um projeto e versionadas junto com o repositório.

Crie a pasta:

mkdir -p .cursor/rules
Enter fullscreen mode Exit fullscreen mode

Depois crie um arquivo de regra:

touch .cursor/rules/code-review-termonuclear.mdc
Enter fullscreen mode Exit fullscreen mode

Exemplo de conteúdo:

---
description: "Revisão rigorosa de qualidade de código para mudanças antes de PR"
alwaysApply: false
---

#### Revisão Termonuclear de Código

Use esta regra quando eu pedir revisão de código, auditoria de branch, preparação para Pull Request ou refatoração arquitetural.

#### Objetivo

Atue como um revisor sênior extremamente rigoroso. Não limite a análise ao diff. Use o diff como ponto de partida para avaliar arquitetura, modularidade, fronteiras de tipos, testabilidade e complexidade acidental.

#### Critérios obrigatórios

1. Modularidade e coesão
   - Funções, classes, componentes e módulos devem ter responsabilidade clara.
   - Aponte arquivos que misturam UI, regra de negócio, validação, persistência e orquestração.
   - Questione arquivos acima de 1.000 linhas quando não houver justificativa arquitetural forte.

2. Fronteiras de tipos
   - Aponte `any`, casts desnecessários e `unknown` usado como fuga de modelagem.
   - Questione propriedades opcionais que deveriam ser obrigatórias.
   - Prefira contratos explícitos para entradas, saídas e integrações.

3. Complexidade estrutural
   - Procure condicionais ad hoc, flags espalhadas e branches especiais.
   - Sugira state machines, policy objects, tabelas de decisão ou estratégias quando isso reduzir complexidade real.
   - Evite abstrações genéricas sem uso concreto.

4. Testabilidade
   - Aponte ausência de testes quando houver mudança em regra de negócio, backend, permissões, dados ou integrações.
   - Verifique se dependências externas podem ser isoladas.
   - Prefira testes de comportamento a testes que apenas congelam implementação.

5. Code judo
   - Procure uma refatoração pequena que elimine uma categoria inteira de problemas.
   - Priorize deletar complexidade antes de adicionar camadas.

## Formato da resposta

Organize a revisão nesta ordem:

1. Resumo executivo
2. Achados críticos
3. Riscos arquiteturais
4. Problemas de tipagem
5. Lacunas de teste
6. Sugestões de refatoração
7. Movimento de code judo recomendado

Para cada achado, explique:

- o problema;
- o risco;
- onde aparece;
- como corrigir.

Evite comentários cosméticos se houver problemas estruturais mais importantes.
Enter fullscreen mode Exit fullscreen mode

Agora você pode chamar essa regra no Agent do Cursor quando quiser uma revisão mais pesada.

Exemplo:

Revise as alterações da branch atual usando a regra code-review-termonuclear. Procure problemas de arquitetura, tipagem, testabilidade e complexidade acidental.
Enter fullscreen mode Exit fullscreen mode

Ou referenciando arquivos específicos:

Revise @UserService.ts e @UserController.ts usando nossa regra termonuclear. Quero foco em modularidade, fronteiras de tipos e testes.
Enter fullscreen mode Exit fullscreen mode

Opção 2: User Rules globais

Use User Rules para preferências gerais que devem valer em todos os projetos.

No Cursor:

  1. Abra Cursor Settings.
  2. Vá em Rules.
  3. Adicione suas instruções em User Rules.

Exemplo:

Responda de forma direta, técnica e objetiva.
Ao revisar código, priorize arquitetura, tipagem, testes e manutenibilidade.
Evite comentários cosméticos quando houver problemas estruturais mais importantes.
Sempre que possível, proponha uma simplificação que delete complexidade em vez de apenas reorganizá-la.
Enter fullscreen mode Exit fullscreen mode

Atenção: User Rules são úteis para orientar o Agent/Chat, mas não devem ser tratadas como substitutas de Project Rules. Também não é seguro prometer que elas serão aplicadas automaticamente em todo fluxo de edição inline. Para regras críticas de projeto, prefira .cursor/rules.

Opção 3: Agent Skills

Rules são boas para diretrizes persistentes. Skills são melhores para workflows especializados.

Uma Skill do Cursor é um pacote reutilizável de instruções, conhecimento e, quando necessário, scripts auxiliares. Ela normalmente é definida por um arquivo SKILL.md e pode ser acionada pelo Agent quando aplicável ou invocada manualmente pelo usuário.

No caso da revisão termonuclear, você pode usar a skill oficial como inspiração ou criar uma versão própria.

Estrutura possível:

.cursor/skills/thermo-code-review/
  SKILL.md
Enter fullscreen mode Exit fullscreen mode

Exemplo simplificado de SKILL.md:

---
name: thermo-code-review
description: Revisão termonuclear de qualidade de código com foco em arquitetura, tipagem, testes e simplificação estrutural.
---

#### Thermo Code Review

Use esta skill quando o usuário pedir uma revisão rigorosa de código, auditoria antes de PR ou análise estrutural de uma branch.

#### Procedimento

1. Identifique os arquivos alterados.
2. Leia o diff como ponto de partida, não como limite da análise.
3. Avalie modularidade, fronteiras de tipos, testes e complexidade.
4. Procure arquivos grandes demais e responsabilidades misturadas.
5. Sugira pelo menos um movimento de code judo quando houver oportunidade real.
6. Separe achados críticos de sugestões opcionais.

#### Barra de aprovação

Não aprove código que:

- adiciona `any` sem justificativa;
- transforma campos obrigatórios em opcionais por conveniência;
- mistura regra de negócio com UI ou infraestrutura;
- adiciona comportamento relevante sem teste;
- aumenta complexidade estrutural sem necessidade;
- cria arquivos gigantescos sem fronteira clara.
Enter fullscreen mode Exit fullscreen mode

Uso no Agent:

/thermo-code-review
Revise a branch atual antes do PR. Quero uma auditoria dura, com foco em arquitetura, tipos, testes e oportunidades de simplificação.
Enter fullscreen mode Exit fullscreen mode

Essa abordagem é melhor do que entupir uma única regra global com dezenas de instruções. Skills funcionam bem quando você quer um modo de operação específico e reutilizável.

Opção 4: Bugbot para revisão automática de Pull Requests

Se o objetivo é revisar Pull Requests automaticamente, use o Bugbot.

Rules e Skills ajudam dentro do Agent do Cursor. Bugbot é mais adequado para revisão de PR, porque analisa diffs, deixa comentários e pode ser configurado com regras específicas do repositório.

Crie um arquivo:

mkdir -p .cursor
touch .cursor/BUGBOT.md
Enter fullscreen mode Exit fullscreen mode

Exemplo:

# Regras de revisão do Bugbot

Priorize problemas que possam gerar bug, regressão, risco de segurança, inconsistência de dados ou aumento relevante de dívida técnica.

#### O que procurar

- Mudanças em regra de negócio sem teste.
- Uso de `any`, casts desnecessários ou tipos que escondem contratos reais.
- Campos opcionais que deveriam ser obrigatórios.
- Condicionais ad hoc para casos especiais.
- Código sequencial quando operações independentes poderiam rodar em paralelo.
- Arquivos acima de 1.000 linhas sem justificativa clara.
- Captura genérica de erro que engole exceções.
- Mudanças em autenticação, autorização, pagamentos, dados ou integrações sem cobertura adequada.

#### Como comentar

Para cada achado, explique:

1. qual é o problema;
2. por que isso importa;
3. qual correção concreta você recomenda.

Evite comentários de estilo se não houver risco real.
Enter fullscreen mode Exit fullscreen mode

Esse arquivo não substitui revisão humana. Ele funciona como uma primeira barreira automatizada, especialmente útil para capturar problemas antes que o PR chegue ao revisor principal.

Como usar no dia a dia

Antes de abrir um Pull Request

No Agent do Cursor:

Revise a branch atual usando nossa regra termonuclear. Foque em arquitetura, tipagem, testes, arquivos grandes e code judo. Não quero comentários cosméticos.
Enter fullscreen mode Exit fullscreen mode

Ao revisar arquivos específicos 

Revise @UserService.ts, @UserController.ts e @UserRepository.ts. Procure responsabilidades misturadas, tipos fracos, lacunas de teste e oportunidades de simplificação.
Enter fullscreen mode Exit fullscreen mode

Ao pedir uma refatoração 

Refatore este fluxo para reduzir condicionais ad hoc. Antes de alterar, proponha duas alternativas: uma conservadora e uma com code judo.
Enter fullscreen mode Exit fullscreen mode

Ao endurecer a barra de qualidade 

Não aprove a solução se ela depender de any, cast desnecessário, campo opcional artificial ou ausência de teste em regra de negócio.
Enter fullscreen mode Exit fullscreen mode

Onde essa abordagem falha

A revisão termonuclear é poderosa, mas precisa de calibragem.

1. Pode gerar falsos positivos

Um agente ambicioso vai sugerir mudanças que nem sempre compensam. Isso é aceitável desde que os achados sejam fáceis de descartar.

É melhor ter um revisor automatizado que encontra problemas reais e às vezes exagera do que um agente tímido que só comenta formatação.

2. Pode incentivar abstração demais

Nem todo if precisa virar strategy. Nem toda função precisa virar classe. Nem todo arquivo grande precisa ser dividido imediatamente.

A regra correta não é “abstraia tudo”. A regra correta é “remova complexidade acidental”.

3. Pode ignorar contexto de produto

Às vezes, uma decisão técnica aparentemente estranha existe por causa de uma restrição de negócio, legado, prazo ou compatibilidade.

Por isso, a revisão automatizada deve ser tratada como input técnico, não como sentença final.

4. Pode ficar verbosa demais

Prompts longos e repetitivos desperdiçam contexto. Uma boa regra deve ser específica, mas não redundante. O ideal é dividir responsabilidades:

  • User Rules para preferências globais;
  • Project Rules para padrões do repositório;
  • Skills para workflows especializados;
  • Bugbot para revisão automática de PR.

Conclusão: suba a régua dos seus agentes

Automatizar code review com IA não é transformar o agente em fiscal de estilo. É transformar o agente em uma camada extra de julgamento técnico.

A revisão termonuclear é valiosa porque muda a pergunta central. Em vez de perguntar “isso funciona?”, ela pergunta:

“Essa mudança melhora ou piora a capacidade do sistema de evoluir?”

Esse é o tipo de pergunta que separa um assistente de código comum de um revisor de engenharia realmente útil.

Se você usa Cursor, o caminho mais sólido hoje é combinar quatro mecanismos:

  • Project Rules em .cursor/rules para padrões versionados do projeto;
  • User Rules para preferências globais de interação;
  • Agent Skills para workflows especializados, como revisão termonuclear;
  • Bugbot para revisão automatizada de Pull Requests.

Com essa combinação, você deixa de depender de prompts soltos e passa a construir um sistema de revisão consistente, repetível e cada vez mais alinhado ao padrão técnico do seu time.

Referências

Top comments (0)