Wir haben einen LLM-basierten Linter für Code-Konventionen entwickelt.
(github.com/DevSymphony)Hallo! Wir sind Symphony, ein studentisches Team, das sym-cli entwickelt.
Nutzt ihr in letzter Zeit häufig Tools wie Cursor oder Claude Code für Vibe Coding? Auch unser Team setzt LLMs aktiv im Entwicklungsprozess ein. Dabei ist uns jedoch ein Punkt aufgefallen, der uns gefehlt hat.
Der von der AI geschriebene Code funktioniert funktional zwar gut, ignoriert aber immer wieder die teaminternen Konventionen wie Variablenbenennung, Kommentarstil oder Regeln zur Nutzung bestimmter Bibliotheken. Die Regeln jedes Mal erneut in den Prompt zu schreiben, ist umständlich, und mit der Zeit vergisst man die Konventionen selbst immer mehr.
Deshalb haben wir begonnen, sym-cli mit der Frage zu entwickeln: „Kann man das LLM nicht dazu bringen, vor dem Schreiben von Code oder schon währenddessen seine eigenen Konventionen zu überprüfen?“
[Was ist sym-cli?]
sym-cli ist ein richtlinienbasierter Linter für Code-Konventionen für AI-Coding-Tools. Der Kern dabei ist, dass er mithilfe von MCP direkt mit dem LLM kommuniziert.
Die Unterschiede zu bestehenden Lintern sind folgende:
- (Konfiguration in natürlicher Sprache) Statt komplexer Konfigurationsdateien definiert man Regeln in natürlicher Sprache, etwa „Schreibe log niemals mit print“, und das LLM versteht und befolgt sie.
- (Kontext-Optimierung) Das LLM liest nicht alle Regeln des Projekts, sondern holt sich über das MCP-Tool gezielt nur die Regeln, die für die aktuelle Aufgabe benötigt werden.
- (Aktive Prüfung) Über das Tool
validate_codekann das LLM direkt nach der Code-Erzeugung selbst prüfen, ob die Regeln eingehalten wurden.
[Wie funktioniert es?]
Wenn man nach dem Download des sym-Befehls den Befehl sym init ausführt, wird die MCP-Server-Konfiguration automatisch eingerichtet. Danach beginnen MCP-fähige IDEs wie Cursor oder andere LLM-Tools sofort, diese Regeln zu referenzieren.
[Wir freuen uns über Feedback!]
Wir sind noch ein studentisches Team, und auch das Projekt befindet sich gerade erst in einer frühen Phase, in der das Grundgerüst steht. Es gibt noch viele Schwächen, und möglicherweise auch Bugs. Umso mehr brauchen wir Unterstützung und Feedback von Entwicklerinnen und Entwicklern aus der Praxis sowie von Menschen mit großem Interesse an LLM-Tools.
Ob „So eine Funktion wäre hilfreich“, „Dieser Teil wirkt strukturell problematisch“ oder „So nutzt man das in der Praxis“ — wir freuen uns über jede Rückmeldung. Da es Open Source ist, sind Beiträge oder ein GitHub Star für unser Team eine enorme Unterstützung!
GitHub Repository: https://github.com/DevSymphony/sym-cli
npm: npm install -g @dev-symphony/sym
Vielen Dank fürs Lesen.
7 Kommentare
Wenn Sie opencode verwenden, können Sie sogar die Lint-Funktion in Ihren Workflow integrieren.
https://de.news.hada.io/topic?id=21883
https://opencode.ai/docs/formatters/
Dem stimme ich zu. Dinge, die sich wie Syntax- oder Typfehler sofort erkennen lassen, sind in der LSP- oder Kompilierungsphase am effizientesten aufzufangen, und auch im Hinblick auf den Token-Verbrauch halte ich das für den richtigen Ansatz. Auch wir sehen LLMs weniger als Ersatz dafür, sondern eher in der Rolle, natürlichsprachlich formulierte Regeln automatisch in bestehende Lint-/Test-Workflows einzubinden.
Ich denke wie t7vonn, dass es richtig ist, Konventionen mit Automatisierungstools durchzusetzen.
Bei der LSP-Funktion merkt man aber einen ziemlich deutlichen Unterschied, weil sich Syntaxfehler, die man sonst erst beim Testen oder Kompilieren findet, sofort erkennen lassen, wodurch der Token-Verbrauch sinkt.
Einem PR-Review-Agenten die Konventionsdokumentation und den Diff zu geben, damit er fehlende Punkte findet, macht man ja schon jetzt ohnehin … darüber hinaus würde ich es wohl nicht verwenden.
Ich füge einen Beitrag von jemandem bei, der eine ähnliche Meinung hat wie ich.
Ich denke, die von Ihnen beschriebene Nutzungsweise ist derzeit der realistischste Ansatz. Das Problem, das wir lösen möchten, besteht darin, den Prozess zu verringern, bei jedem PR das Konventionsdokument mitzugeben, und die in natürlicher Sprache definierten Regeln im Voraus in Linter- und Validierungsregeln umzuwandeln, damit sie in der PR-/CI-Phase automatisch ausgeführt werden.
Hm … das wirkt so, als könnte man das auch mit einer Funktion wie Claude Hooks/Subagents/Skills umsetzen …
Technisch wäre es zwar auch mit Hooks oder Subagents möglich gewesen, aber wir haben uns dafür entschieden, eine schlanke Schicht auf MCP und den bestehenden Linter-Workflow zu setzen, damit wir nicht von einem bestimmten LLM abhängig sind. Deshalb konzentrieren wir uns weniger auf Agentenfunktionen als darauf, Konventionen als wiederverwendbare Infrastruktur zu schaffen.