Voltar ao blog
X24LABS

Deletando nosso classificador de regex: quando a IA substitui sua própria abstração

Passamos meses construindo uma engine de regex ponderada que classificava erros de CI em nove categorias com scores de confiança. Depois deletamos. Esta é a história de por que ela precisou ir e o que a substituiu.

Boa parte da reescrita do v1 para o v2 foi sobre a forma externa. Local em vez de remoto, TypeScript em vez de Python, CLI em vez de job de CI. A parte que vale um post próprio é interna. O v2 saiu com bem menos código que o v1, e a maior parte do que está faltando foi deliberadamente deletada.

A maior deleção de todas foi o nosso classificador de erros.

O que ele fazia

O classificador do v1 era uma engine de regex ponderada. Lia logs de CI, passava por uns cento e cinquenta padrões e separava erros em nove baldes: lint, formatting, types, build, CI config, test contracts, complex types, logic, e um pega-tudo chamado unknown. Cada classificação vinha com um score de confiança. Cada balde mapeava para uma estratégia de correção.

A landing page do Stitch v1 listava orgulhosamente todas as nove categorias. Achávamos que era uma funcionalidade.

Por que construímos

O classificador respondia a um problema real. Chamadas de modelo de linguagem custam tokens. Logs de CI são enormes. Se você manda o log inteiro, desperdiça contexto e recebe resultados piores porque o modelo tem que achar o sinal sozinho. Se você pré-processa o log, tira o ruído, isola o erro relevante e rotula o tipo, você economiza tokens e dá vantagem ao modelo.

Então construímos um pré-processador. Ele rodava antes do modelo. Produzia um payload compacto que dizia “este é um erro de tipo no arquivo X linha Y, aqui está o traceback, aqui estão as cinco linhas ao redor do call site”. O modelo então produzia a correção. Isso funcionava.

Por que precisou ir

Duas coisas mudaram.

Modelos ficaram melhores em ler logs brutos. Claude e GPT ficaram mais baratos por token e mais afiados em parsear saída não estruturada. A distância entre “enviar ao modelo um erro extraído cirurgicamente” e “enviar ao modelo o log e deixar ele se virar” encolheu. A etapa de extração parou de justificar seu custo.

Nosso classificador ficou pior em comparação. Tínhamos padrões para TypeScript, Python e Go. Não tínhamos padrões para Elixir, Rust ou qualquer framework que um usuário estivesse rodando naquela semana. Quando um log chegava e o regex não batia, mandávamos para o balde unknown e deixávamos o modelo resolver do mesmo jeito. Essa foi a pista. Se o fallback funcionava, o caminho especializado era opcional. Se o caminho especializado era opcional, também era fonte de bugs que estávamos mantendo à toa.

A percepção decisiva veio no contexto local do v2. Na máquina de um desenvolvedor, rodar stitch run claude significava chamar o Claude Code, um agente plugável que já tem ferramentas para ler arquivos, rodar comandos e raciocinar sobre erros. Mandar um payload pré-classificado para ele era como mandar a um engenheiro sênior um relatório de bug pré-preenchido e insistir que ele usasse nosso template. Ele não precisava. O template estava adicionando atrito.

Com o que substituímos

Duas coisas. Uma muito mais simples que antes, outra nem na mesma camada.

O Stitch v2 ainda faz um pouco de pré-processamento, mas é grosso e honesto. Ele olha os nomes dos jobs e decide se roda. Um job chamado deploy-prod é infra, pula localmente. Um job chamado lint é verificação, roda localmente. É uma decisão de uma linha por job. Não finge saber quais erros virão.

O diagnóstico de verdade foi para o agente. Quando um job falha, o Stitch entrega o log ao agente com um prompt curto e propositalmente chato: este é o job, este é o log, este é o repo, por favor corrija. O agente faz o que faria numa sessão interativa. Lê arquivos, roda comandos, tenta coisas. O Stitch valida re-executando o job.

O total de código removido foi de milhares de linhas. A capacidade perdida foi zero. Os diagnósticos ficaram melhores porque o agente passou a ter acesso ao repo inteiro em vez de um trecho de cinco linhas.

A lição

A lição é desconfortável, mas aparece de novo e de novo em ferramentas construídas em torno de agentes de IA: as abstrações que você cria para ajudar o modelo costumam parar de ajudar quando o modelo fica bom o suficiente. Se você é dono do pré-processador e do prompt, vai chegar num ponto em que o pré-processador está piorando o prompt. Você não vai notar, porque você construiu.

A única forma de notarmos foi nos dar permissão para deletar e ver o que aconteceria. Nada aconteceu. Era esse o ponto.

Próximo post da série: Stitch 2.0 está saindo. O que você realmente instala e o que ele faz.

Voltar ao blog