Você Construiu Metade de uma Rede de Segurança e Chamou de Pronto

Vamos ser honestos sobre como a maioria das pipelines de código com IA realmente se parece agora.

Você gera código com Cursor ou Claude Code. Você roda tsc --noEmit porque o strict mode do TypeScript pega incompatibilidades de tipo. Você roda o ESLint porque ninguém quer discutir sobre ponto e vírgula em um pull request. Talvez você rode o dependency-cruiser porque importações circulares são embaraçosas. Seus testes passam. Você entrega.

E você acha que isso é uma pilha determinística.

Não é. É uma pilha de tipos e estilo. Você impediu estados inválidos e assegurou boundaries de importação, o que é genuinamente útil. Mas você não fez absolutamente nada sobre o fato de que a LLM acabou de gerar uma função de 180 linhas com uma complexidade ciclomática que faria um teórico dos grafos chorar. Você não pegou que três módulos diferentes copiaram o mesmo helper com nomes de variáveis ligeiramente diferentes. Você não notou que o tratamento de erros é um único catch (e) { console.log(e) } sentado no fim de uma cadeia de promises como um segurança preguiçoso.

O código compila. A arquitetura está limpa. O código ainda é objetivamente terrível.

Essa é a lacuna. E isso importa porque código gerado por IA tem um talento particular para produzir exatamente esse tipo de lixo: estruturalmente válido, em conformidade com a arquitetura, e apodrecendo silenciosamente por dentro.

O Que a Camada Ausente Realmente É

Pense na diferença entre um prédio passar na vistoria de um engenheiro estrutural e um prédio ser agradável de morar. A vistoria estrutural verifica se o prédio desaba. Ela não verifica se o chuveiro escoa na pia da cozinha. Ambos importam. São trabalhos diferentes.

Sua pilha determinística existente é o engenheiro estrutural. Ela verifica:

  • Types: Esse valor pode mesmo existir nesse formato?
  • Linting: A sintaxe segue higiene básica?
  • Regras de arquitetura: As importações respeitam os boundaries?
  • Testes: O caminho feliz executa sem travar?

O que ela não verifica:

  • Complexidade: Essa função tem tantos ramos que nenhum humano vai conseguir raciocinar sobre ela corretamente?
  • Duplicação: A LLM gerou a mesma lógica em quatro lugares com variações menores?
  • Nomenclatura: data é um nome de variável significativo, ou é o equivalente em programação de um encolher de ombros?
  • Tratamento de erros: Os erros são realmente tratados, ou apenas capturados e ignorados?
  • Estrutura: A organização dos arquivos faz sentido, ou é um depósito de lixo?
  • Comentários: As partes complicadas estão explicadas, ou o próximo desenvolvedor vai precisar de uma sessão de espiritismo?
  • Tamanho: Esse arquivo tem 400 linhas porque precisa ter, ou porque ninguém disse ao modelo para parar?

Essas não são preferências estéticas. Complexidade correlaciona com densidade de defeitos. Duplicação garante que mudanças futuras serão inconsistentes. Nomenclatura ruim aumenta a carga cognitiva de cada modificação subsequente. Tratamento de erros ruim significa falhas em produção sem trilha de diagnóstico.

A pesquisa é inequívoca aqui. Nossa própria análise multidimensional encontrou que arquiteturas de confiabilidade em camadas só funcionam quando cada camada pega defeitos que as camadas anteriores perderam. Se sua Camada 1 é type checking e sua Camada 2 é testes, mas ninguém está verificando se o código é um desastre de manutenibilidade, você tem um buraco na sua pilha. E código gerado por IA adora cair nesse buraco porque os modelos são muito bons em gerar implementações de aparência plausível que por acaso são pesadelos para se conviver.

Entra a Ferramenta Com o Nome Grosseiro

Existe uma ferramenta chamada fuck-u-code — sim, sério, esse é o comando — e ela faz exatamente uma coisa que nada mais na sua pipeline está fazendo. Ela roda análise determinística de qualidade de código baseada em AST em catorze linguagens e te diz precisamente quão ruim está seu código, usando métricas que realmente correlacionam com problemas reais.

Eis o que ela verifica:

  • Complexidade: Pontuações de complexidade ciclomática e cognitiva. Se uma função tem dezessete ramos, ela sinaliza.
  • Tamanho: Contagens de linhas de arquivo e função. A LLM que gerou uma função de 250 linhas não ganha um passe porque os tipos estão corretos.
  • Comentários: Densidade e qualidade de comentários. Não porque comentários sejam virtuosos, mas porque lógica complexa sem explicação é uma armadilha de manutenção.
  • Tratamento de erros: Se erros são capturados, relançados, logados ou engolidos silenciosamente.
  • Nomenclatura: Qualidade de nomes de variáveis e funções. data, temp, handler e process não passam.
  • Duplicação: Blocos de código repetidos entre arquivos. O truque favorito da LLM: copiar e colar com um find-and-replace.
  • Estrutura: Organização de arquivos e coesão de módulo.

Ela produz uma pontuação geral de 0 a 100. Quanto maior, melhor. Ela também produz um “shit-gas index” por arquivo — quanto maior, pior — então você sabe exatamente quais arquivos precisam de atenção primeiro. A análise roda inteiramente offline via parsing de AST com tree-sitter. Seu código nunca sai da sua máquina. Leva menos de um segundo na maioria dos projetos.

E aqui está a parte que deveria te deixar com raiva de não estar usando isso já: ela custa zero dólares.

A Ferramenta Encarna a Filosofia

O que torna o fuck-u-code interessante não é só o que ele verifica. É como ele é arquitetado internamente, porque a ferramenta em si é um microcosmo perfeito da pipeline a que ela pertence.

A ferramenta tem dois comandos:

fuck-u-code analyze .          # Deterministic AST analysis. Offline. Fast. Free.
fuck-u-code ai-review . -m gpt-4o   # AI review of the worst-scoring files. API call. Costs tokens.

Note a ordem. Note o padrão. A análise determinística roda primeiro, sempre, porque não requer uma chave de API, não custa dinheiro e não varia entre execuções. A revisão de IA é um segundo passo opcional que só olha para os N piores arquivos.

Essa é exatamente a arquitetura que sua pipeline deveria ter.

Você não envia cada pull request para o Greptile ou Claude Code para uma revisão semântica completa. Isso custa dinheiro, leva tempo e — como estabelecemos em posts anteriores — produz saída probabilística que pode ou não sinalizar os mesmos problemas em execuções consecutivas. Você roda o gate determinístico primeiro. Você filtra os desastres estruturais de graça, em milissegundos, com reprodutibilidade perfeita. Então, e só então, você envia os sobreviventes para revisão de IA cara para a análise semântica, arquitetônica e comportamental que ferramentas determinísticas não conseguem fazer.

O fuck-u-code literalmente implementa isso internamente. O comando analyze é seu filtro de qualidade da Camada 1. O comando ai-review é seu mergulho semântico da Camada 2. A ferramenta é uma demonstração do princípio que ela habilita.

O Argumento Econômico É Quase Ofensivo

Vamos falar de dinheiro por um momento, porque é aqui que o estado atual da indústria se torna genuinamente irritante.

Plataformas de revisão de código com IA cobram por pull request ou por linha de código revisada. O custo não é enorme — talvez um dólar ou dois por PR — mas é não-zero, e escala com a velocidade da sua equipe. Se você está gerando código com IA, sua velocidade é maior do que costumava ser, o que significa que seus custos de revisão também são maiores do que costumavam ser.

Enquanto isso, o fuck-u-code vai analisar seu codebase inteiro, em catorze linguagens, em menos de um segundo, e te cobrar exatamente nada. Ele vai sinalizar os 20% de arquivos que são genuinamente problemáticos. Ele vai produzir um relatório em JSON ou Markdown que seu CI pode consumir. Ele vai falhar o build se a pontuação média cair abaixo de um limiar que você configurou.

Se você roda revisão de IA em cada PR sem um gate de qualidade determinístico primeiro, você está pagando tokens de API para descobrir que uma função é complexa demais. Isso é como contratar um engenheiro estrutural para te dizer que sua casa está suja. O engenheiro é qualificado para o trabalho, mas você está desperdiçando o tempo dele e seu dinheiro.

A pipeline economicamente racional é:

  1. IA gera código
  2. Type check, lint e regras de arquitetura (sua pilha existente)
  3. fuck-u-code analyze (o gate de qualidade ausente — $0, <1s)
  4. Revisão de IA (Greptile, etc. — mas apenas em arquivos que sobreviveram ao passo 3, ou apenas quando o passo 3 sinaliza padrões interessantes)

Isso não é teoria. Isso é aritmética. O gate determinístico pega a classe de problemas para a qual ferramentas determinísticas foram projetadas. A revisão de IA pega a classe de problemas que exigem entendimento semântico. Cada ferramenta faz o que é boa em fazer. Ninguém está desperdiçando tokens em higiene estrutural.

Integração MCP: Feita para o Fluxo de Trabalho, Não Adaptada Depois

Existe mais um detalhe que importa se você é sério sobre desenvolvimento assistido por IA.

O fuck-u-code vem com um servidor MCP. Se você está usando Claude Code, Cursor ou qualquer outra ferramenta compatível com MCP, você pode invocar fuck-u-code analyze diretamente do seu agente. O agente não precisa saber sobre parsing de AST ou complexidade ciclomática. Ele chama uma ferramenta. A ferramenta retorna um relatório estruturado. O agente age com base nele.

Isso importa porque fecha o ciclo. A mesma IA que gerou o código agora pode receber feedback determinístico sobre a qualidade desse código, em um formato que ela consegue entender e agir. O agente pode ver que o shit-gas index para src/auth/login.ts é 87 de 100 e decidir fazer refactor antes que um humano veja o PR.

Nós já escrevemos antes sobre como o CI é a camada de enforcement que torna o desenvolvimento orientado a especificações real. A integração MCP significa que o fuck-u-code não é apenas um gate de CI. Ele é um oráculo de qualidade acessível a agentes que a pipeline de geração pode consultar em tempo real.

Como Adicionar Ele na Prática

Você não precisa de um plano de migração. Você precisa de cinco minutos.

npm install -g eff-u-code
fuck-u-code analyze .              # See your current scores
fuck-u-code config init            # Generate .fuckucoderc.json

Configure seus limiares. Escolha uma pontuação mínima geral. Escolha um shit-gas index máximo para qualquer arquivo individual. Adicione aos seus pre-commit hooks:

# .husky/pre-commit
fuck-u-code analyze . --format json --output quality-report.json

Ou adicione ao CI:

# .github/workflows/quality.yml
- name: Code Quality Gate
  run: |
    npm install -g eff-u-code
    fuck-u-code analyze . --format markdown -o quality.md
    # Parse the JSON and fail if overall score < threshold

Os pesos são configuráveis. Se sua equipe se importa mais com complexidade do que com comentários, ajuste os pesos das métricas no .fuckucoderc.json. Se você quer excluir arquivos de teste, use --exclude. Se você quer ver os 20 piores arquivos em vez dos 10 padrão, use -t 20.

Então, quando você tiver filtrado os desastres estruturais, envie os arquivos interessantes para revisão de IA:

fuck-u-code ai-review . -m gpt-4o -t 5   # Review only the 5 worst files

Essa é a pipeline. Gere. Type-check. Gate de qualidade. Revise os sobreviventes com IA. Entrega.

A Conclusão Honesta

Eu não vou fingir que o fuck-u-code vai resolver todos os problemas do seu codebase. Ele não vai pegar uma condição de corrida. Ele não vai te dizer que sua lógica de autenticação tem um ataque de timing sutil. Ele não vai substituir property-based testing ou mutation testing ou verificação formal ou qualquer uma das outras camadas sobre as quais falamos em posts anteriores.

O que ele vai fazer é pegar os problemas chatos, previsíveis e caros que ninguém está pegando no momento. Ele vai te dizer que seu handler de API gerado por IA tem 300 linhas e nenhum tratamento de erros. Ele vai te dizer que três serviços diferentes copiaram a mesma lógica de validação. Ele vai te dizer que metade das suas variáveis se chamam data ou result e você deveria se sentir mal por isso.

Esses não são casos extremos. Esses são os resultados padrão de uma pipeline de geração de código rápida que não tem loop de feedback de qualidade. A LLM não fica cansada, mas também não fica envergonhada. Ela vai gerar código ruim com a mesma confiança com que gera código bom, e sua pilha determinística atual vai deixar passar porque sua pilha não foi projetada para verificar qualidade. Ela foi projetada para verificar validade.

Validade e qualidade são coisas diferentes. Você precisa de ambas.

O fuck-u-code não é a resposta completa. Ele é a resposta para a pergunta específica: “Qual é a maneira mais barata, mais rápida e mais determinística de impedir que lixo estrutural gerado por IA chegue à revisão de código?”

A resposta é: faça o parse da AST, pontue as métricas, falhe o build, e faça o modelo tentar de novo.

Não custa nada. Leva menos de um segundo. E fecha um buraco na sua pilha de segurança que você provavelmente não sabia que tinha.