Creamos un linter de convenciones de código basado en LLM
(github.com/DevSymphony)¡Hola! Somos Symphony, un equipo universitario que está desarrollando sym-cli.
¿Últimamente usan mucho herramientas como Cursor o Claude Code para hacer vibe coding? Nuestro equipo también está aprovechando activamente los LLM durante el proceso de desarrollo. Pero mientras los usábamos, había algo que nos dejaba inconformes.
El código que genera la IA funciona bien a nivel funcional, pero seguía ignorando las convenciones propias de nuestro equipo (nomenclatura de variables, estilo de comentarios, reglas de uso de ciertas librerías, etc.). Escribir las reglas en el prompt cada vez era molesto, y además, con el tiempo también surgía el problema de que poco a poco se nos iban olvidando esas convenciones.
Por eso empezamos a crear sym-cli a partir de una pregunta: “¿No sería posible hacer que el LLM revise por sí mismo las convenciones antes de escribir código, o incluso mientras lo está escribiendo?”.
[sym-cli, ¿qué es?]
sym-cli es un linter de convenciones de código basado en políticas para herramientas de codificación con IA. Su punto clave es que usa MCP para comunicarse directamente con el LLM.
Se diferencia de los linters existentes en lo siguiente.
- (Configuración basada en lenguaje natural) En lugar de archivos de configuración complejos, puedes definir reglas en lenguaje natural, como “nunca escribas logs con print”, y el LLM las entiende y las sigue.
- (Optimización de contexto) El LLM no lee todas las reglas del proyecto; mediante herramientas MCP, obtiene de forma inteligente solo las reglas necesarias para la tarea actual.
- (Validación activa) A través de la herramienta
validate_code, el LLM puede verificar por sí mismo si cumple las reglas justo después de generar el código.
[¿Cómo funciona?]
Después de descargar el comando sym, al ejecutar sym init se configura automáticamente el servidor MCP, y así los IDE compatibles con MCP (como Cursor) o las herramientas LLM empiezan a consultar estas reglas de inmediato.
[¡Les pedimos su feedback!]
Todavía somos un equipo universitario, y el proyecto también está apenas en una etapa inicial en la que recién tiene su estructura base. Nos faltan muchas cosas y puede que haya bugs. Aun así, necesitamos muchísimo el apoyo y el feedback de desarrolladores profesionales y de personas interesadas en herramientas LLM.
Nos encantaría escuchar cualquier opinión, ya sea “estaría bien tener una función así”, “esta parte parece tener un problema estructural” o “en un entorno profesional esto se usa de esta manera”. Como es open source, cualquier contribución o GitHub Star de verdad le da muchísima fuerza a nuestro equipo.
GitHub Repository: https://github.com/DevSymphony/sym-cli
npm: npm install -g @dev-symphony/sym
Gracias por leer.
7 comentarios
Si usas opencode, también puedes incluir la función de lint en tu flujo de trabajo.
https://es.news.hada.io/topic?id=21883
https://opencode.ai/docs/formatters/
Coincido. Para cosas que se pueden detectar de inmediato, como errores de sintaxis o de tipos, la etapa de LSP o de compilación es la más eficiente, y creo que también es el enfoque correcto en términos de consumo de tokens. Nosotros tampoco vemos al LLM como un reemplazo de eso, sino más bien como algo más cercano a un rol que conecta automáticamente reglas escritas en lenguaje natural con los flujos de trabajo existentes de lint/test.
Yo también, como t7vonn, creo que lo correcto es ajustar las convenciones con herramientas de automatización.
Pero la funcionalidad de LSP sí se siente bastante distinta, porque permite detectar de inmediato errores de sintaxis que solo se atraparían al correr tests o compilar, así que el uso de tokens se reduce.
Incluso ahora ya se usa algo como pasarle al agente de revisión de PR el documento de convenciones junto con el diff para que encuentre lo que falta... y no creo que lo use para algo más que eso.
Adjunto un texto de alguien con una opinión parecida a la mía.
Creo que la forma de uso que mencionaste es, por ahora, el enfoque más realista. El problema que queremos resolver va por reducir el proceso de entregar el documento de convenciones en cada PR, y por convertir de antemano las reglas definidas en lenguaje natural en reglas de linting y validación para que se ejecuten automáticamente en la etapa de PR/CI.
Mmm... parece que también se podría hacer con algo como hooks/subagents/skills de Claude...
Técnicamente, parece que también sería posible con hooks o subagentes, pero nosotros elegimos poner una capa delgada sobre MCP y el flujo de trabajo existente del linter para no depender de un LLM específico. Por eso, más que en funciones de agente, nos estamos enfocando en convertir las convenciones en una infraestructura reutilizable.