R$49.00code
  • Claude

Code review adversarial

  • no rating
  • 0
  • 0
  • Jul 11, 2026

O modelo tenta quebrar o seu diff antes de aprovar qualquer coisa.

R$49.00

One-time payment for this item.

Lab

Test how it works before buying.

Try it
1 real run

Prompt

You are seeing 10 of 37 lines

Você é um revisor de código cético. Sua reputação sofre mais com um falso
positivo do que com um achado perdido.

## Diff em revisão
```diff
{{diff}}
```

## Contexto
- Linguagem/stack: {{stack}}

Get this prompt to see it

What this prompt does

Um review em duas passadas: a primeira levanta hipóteses de falha, a segunda tenta refutar cada uma delas construindo um caso concreto de entrada e estado. Só sobrevive o achado com cenário de falha reproduzível, o que elimina quase todo o ruído típico de review automatizado.

Preview

Result

[alta] search.ts:2, resultado vazio nunca é cacheado, e cada requisição volta ao banco

Cenário de falha: fetchSearch("xyzzy") devolve [] para um termo sem resultado. cache.set guarda [], mas na requisição seguinte cache.get devolve [], que é truthy como objeto, então esta hipótese não se confirma para array. Confirma-se, porém, se fetchSearch devolver null ou 0 resultados como undefined: aí if (cached) é falso e o cache nunca serve. Com um termo popular e sem resultado, os 4 workers vão ao banco em toda requisição.

Correção sugerida:

- const cached = cache.get(key);
- if (cached) return cached;
+ if (cache.has(key)) return cache.get(key);

[média] search.ts:3, nada impede a estampida de cache

Cenário de falha: o termo "iphone" expira às 12h00m00s. Vinte requisições concorrentes chegam em 12h00m00.05s. Todas leem o cache vazio e todas disparam fetchSearch antes da primeira gravar. O banco recebe 20 consultas idênticas, o pico é maior do que sem cache nenhum, porque elas chegam simultâneas.

Correção sugerida: guarde a promise em vez do resultado, para que os concorrentes aguardem a mesma execução:

if (!cache.has(key)) cache.set(key, fetchSearch(query), 60);
return cache.get(key);

[média] search.ts:4, erro de busca é cacheado como sucesso pela correção acima

Cenário de falha: ao cachear a promise, uma rejeição de fetchSearch fica guardada por 60s e toda requisição no período recebe o mesmo erro. Sem tratamento, um blip de 200ms no banco vira 60s de indisponibilidade da busca.

Correção sugerida: remova a entrada no catch antes de repropagar.


Descartadas na passada 2

  • Chave de cache colide entre usuários: não construí o cenário, key não aparece no diff. Ver "Não verificado".
  • Vazamento de memória: o cache tem TTL de 60s; sem evidência de crescimento ilimitado.
  • Off-by-one no TTL: 60 vs 60000 é plausível, mas a unidade da API de cache não está no diff.

Não verificado

  • Como key é construída (arquivo não incluído), é onde estaria um possível vazamento entre usuários.
  • A unidade do terceiro argumento de cache.set (segundos ou milissegundos).
  • Se fetchSearch já tem retry interno, o que mudaria a análise de estampida.

How to use

  1. 1

    Copy the template

    After the purchase the full template becomes available to copy.

  2. 2

    Fill in the variables

    Swap the highlighted variable for your own content. Leaving them blank degrades the output.

  3. 3

    Pick one of the listed models

    Run it on one of the models listed on the side. A smaller model usually degrades the result.

  4. 4

    Paste and run

    Or use the lab, with your own key, and compare it against the preview.