Criamos um linter de convenções de código baseado em LLM.

Olá! Somos a Symphony, uma equipe universitária que desenvolve o sym-cli.

Vocês têm usado bastante ferramentas como Cursor ou Claude Code para vibe coding ultimamente? Nossa equipe também está usando LLMs ativamente no processo de desenvolvimento. Mas, conforme fomos usando, sentimos falta de uma coisa.

O código gerado pela IA funciona bem do ponto de vista funcional, mas continua ignorando as convenções específicas da nossa equipe (nomenclatura de variáveis, estilo de comentários, regras de uso de determinadas bibliotecas etc.). Ficar escrevendo essas regras no prompt toda vez era trabalhoso, e também havia o problema de, com o tempo, irmos esquecendo cada vez mais as convenções.

Foi por isso que começamos a criar o sym-cli, a partir da pergunta: "Será que não dá para fazer o LLM verificar as convenções por conta própria antes de escrever o código, ou até durante a escrita?"

[o que é o sym-cli?]

sym-cli é um linter de convenções de código baseado em políticas para ferramentas de programação com IA. O ponto principal é que ele usa MCP para se comunicar diretamente com o LLM.

As diferenças em relação aos linters tradicionais são as seguintes.

1. (Configuração em linguagem natural) Em vez de arquivos de configuração complexos, você define regras em linguagem natural, como "nunca escreva log com print", e o LLM entende e segue isso.
2. (Otimização de contexto) Em vez de o LLM ler todas as regras do projeto, ele busca de forma inteligente apenas as regras necessárias para a tarefa atual por meio das ferramentas MCP.
3. (Verificação ativa) Com a ferramenta validate_code, o LLM pode verificar por conta própria, logo após gerar o código, se ele está seguindo as regras.

[como funciona?]

Depois de baixar o comando sym, ao executar sym init, a configuração do servidor MCP é montada automaticamente, e essas regras passam a ser consultadas imediatamente em IDEs com suporte a MCP (como o Cursor) ou em ferramentas com LLM.

[pedimos seu feedback!]

Ainda somos uma equipe universitária, e o projeto também está em uma fase inicial, em que acabou de ganhar sua estrutura básica. Há muitos pontos a melhorar e pode haver bugs. Mesmo assim, precisamos muito do apoio e do feedback de desenvolvedores que atuam no mercado e de pessoas interessadas em ferramentas com LLM.

"Seria bom ter uma funcionalidade assim", "essa parte parece ter um problema estrutural", "na prática, no mercado, usamos assim" — ficaremos muito agradecidos por qualquer opinião. Como é open source, contribuições ou uma estrela no GitHub realmente nos ajudam muito!

GitHub Repository: https://github.com/DevSymphony/sym-cli
npm: npm install -g @dev-symphony/sym

Obrigado por ler.

[click]

Se você usar o opencode, pode incluir até a funcionalidade de lint no fluxo de trabalho.
https://pt.news.hada.io/topic?id=21883
https://opencode.ai/docs/formatters/

[3ae3ae]

Concordo. Para coisas que podem ser detectadas imediatamente, como erros de sintaxe e de tipo, a etapa de LSP ou de compilação é a mais eficiente, e acho que essa também é a abordagem certa do ponto de vista do consumo de tokens. Nós também vemos o LLM menos como um substituto disso e mais como algo próximo de um papel de conectar automaticamente regras escritas em linguagem natural ao workflow existente de lint/test.

[click]

Eu também acho, como o t7vonn, que o certo é alinhar as convenções com ferramentas de automação.
Mas dá para sentir uma boa diferença com os recursos de LSP, porque eles conseguem detectar na hora erros de sintaxe que só apareceriam ao rodar testes ou compilar, então o uso de tokens acaba diminuindo.

[t7vonn]

Atualmente já fazem algo como entregar ao agente de revisão de PR o documento de convenções junto com o diff e pedir para encontrar o que faltou... e acho que eu não usaria além disso.

Compartilho um texto de alguém com uma opinião parecida com a minha

• https://pt.news.hada.io/topic?id=24744

Claude não é um linter

• Incluir diretrizes de estilo de código no CLAUDE.md é ineficiente
  • LLMs têm custo alto, são lentos e menos determinísticos do que um linter
• Regras de estilo são aprendidas naturalmente por meio dos padrões do código existente, então instruções separadas são desnecessárias
• Para formatação, use linters com correção automática (como o Biome) e passe ao Claude apenas o resultado das correções
• Se necessário, use Stop Hook ou Slash Command para automatizar a formatação e a validação

[3ae3ae]

Acho que a forma de uso que você mencionou é, por enquanto, a abordagem mais realista. O problema que queremos resolver é reduzir o processo de entregar o documento de convenções em cada PR e transformar previamente regras definidas em linguagem natural em regras de lint e validação, para que elas rodem automaticamente nas etapas de PR/CI.

[m00nlygreat]

Hum... parece que também daria para fazer isso com alguma funcionalidade tipo claude hooks/subagents/skill...

[3ae3ae]

Tecnicamente, parece que também seria possível com hooks ou subagentes, mas escolhemos colocar uma camada fina sobre o MCP e o fluxo de trabalho dos linters existentes para não ficarmos presos a um LLM específico. Por isso, em vez de focar em funcionalidades de agente, estamos focando em transformar convenções em uma infraestrutura reutilizável.