Kami membuat linter konvensi kode berbasis LLM.

Halo! Kami adalah Symphony, tim mahasiswa yang mengembangkan sym-cli.

Akhir-akhir ini, apakah Anda sering melakukan vibe coding dengan alat seperti Cursor atau Claude Code? Tim kami juga активно memanfaatkan LLM dalam proses pengembangan. Namun saat menggunakannya, ada satu hal yang terasa kurang memuaskan.

Kode yang ditulis AI memang berjalan dengan baik secara fungsional, tetapi terus mengabaikan konvensi khas tim kami sendiri (seperti aturan penamaan variabel, gaya komentar, aturan penggunaan library tertentu, dan sebagainya). Menuliskan aturan itu setiap kali di prompt terasa merepotkan, dan seiring waktu kami juga mulai makin sering melupakan konvensi tersebut.

Karena itu, kami mulai membuat sym-cli dari pertanyaan: "Bisakah LLM memeriksa konvensi sendiri sebelum menulis kode, atau saat sedang menulisnya?"

[sym-cli itu apa?]

sym-cli adalah linter konvensi kode berbasis kebijakan untuk alat AI coding. Inti utamanya adalah menggunakan MCP untuk berkomunikasi langsung dengan LLM.

Perbedaannya dengan linter yang sudah ada adalah sebagai berikut.

1. (Konfigurasi berbasis bahasa alami) Alih-alih file konfigurasi yang rumit, Anda cukup mendefinisikan aturan dalam bahasa alami seperti, "jangan pernah menulis log dengan print", lalu LLM akan memahaminya dan mengikutinya.
2. (Optimasi context) LLM tidak perlu membaca semua aturan proyek; melalui alat MCP, ia secara cerdas hanya mengambil aturan yang diperlukan untuk pekerjaan saat ini.
3. (Pemeriksaan aktif) Melalui alat validate_code, LLM dapat memeriksa sendiri apakah kode yang baru saja dihasilkan sudah mematuhi aturan.

[Bagaimana cara kerjanya?]

Setelah mengunduh perintah sym dan menjalankan perintah sym init, konfigurasi server MCP akan disusun secara otomatis, sehingga IDE yang mendukung MCP (seperti Cursor) atau alat LLM dapat langsung mulai merujuk ke aturan-aturan ini.

[Mohon feedback-nya!]

Kami masih tim mahasiswa, dan proyek ini juga masih berada di tahap awal yang baru mulai memiliki kerangka dasar. Masih banyak kekurangan dan mungkin juga ada bug. Namun kami sangat membutuhkan dukungan dan feedback dari para developer profesional maupun orang-orang yang sangat tertarik pada alat LLM.

"Akan bagus kalau ada fitur seperti ini", "bagian ini tampaknya punya masalah secara struktural", "di dunia kerja nyata biasanya digunakan seperti ini" — pendapat apa pun akan kami terima dengan penuh rasa terima kasih. Karena ini open source, kontribusi atau GitHub Star akan menjadi dukungan yang sangat berarti bagi tim kami!

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

Terima kasih sudah membaca.

[click]

Kalau memakai opencode, Anda bisa memasukkan fungsi lint ke dalam workflow juga.
https://id.news.hada.io/topic?id=21883
https://opencode.ai/docs/formatters/

[3ae3ae]

Saya setuju. Hal-hal yang bisa langsung ditangkap seperti error sintaks dan tipe paling efisien ditangani pada tahap LSP atau kompilasi, dan saya juga merasa itu pendekatan yang tepat dari sisi penggunaan token. Kami juga melihat LLM bukan sebagai pengganti hal tersebut, melainkan lebih sebagai penghubung yang secara otomatis mengaitkan aturan yang ditulis dalam bahasa alami ke workflow lint/test yang sudah ada.

[click]

Saya juga berpikir seperti t7vonn bahwa konvensi memang sebaiknya diseragamkan dengan alat otomatisasi
Tetapi, untuk fitur LSP perbedaannya terasa cukup besar karena kesalahan sintaks yang baru ketahuan setelah menjalankan test atau kompilasi bisa langsung ditangkap, jadi penggunaan token pun berkurang.

[t7vonn]

Untuk agen review PR, memberi dokumen konvensi dan diff lalu mencari bagian yang terlewat sebenarnya sudah dilakukan bahkan sekarang juga.. dan sepertinya saya tidak akan memakainya lebih dari itu

Saya lampirkan tulisan dari seseorang yang punya pendapat mirip dengan saya

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

Claude bukan linter

• Tidak efisien memasukkan pedoman gaya kode ke dalam CLAUDE.md
  • LLM mahal, lambat, dan lebih tidak deterministik dibanding linter
• Karena aturan gaya secara alami dipelajari lewat pola kode yang sudah ada, instruksi terpisah tidak diperlukan
• Untuk formatting, gunakan linter yang bisa memperbaiki otomatis (seperti Biome), lalu kirimkan ke Claude hanya hasil perbaikannya
• Jika perlu, gunakan Stop Hook atau Slash Command untuk mengotomatiskan formatting dan verifikasi

[3ae3ae]

Saya rasa cara penggunaan yang Anda sebutkan saat ini adalah pendekatan yang paling realistis. Masalah yang ingin kami selesaikan adalah mengurangi proses membagikan dokumen konvensi pada setiap PR, dan mengubah aturan yang didefinisikan dalam bahasa alami terlebih dahulu menjadi aturan linter/verifikasi agar bisa dijalankan secara otomatis pada tahap PR/CI.

[m00nlygreat]

Hmm.. sepertinya ini juga bisa dibuat dengan fitur seperti hooks/subagents/skill di Claude ..

[3ae3ae]

Secara teknis tampaknya ini juga bisa dilakukan dengan hooks atau subagent, tetapi kami memilih menambahkan lapisan tipis di atas MCP dan alur kerja linter yang sudah ada agar tidak bergantung pada LLM tertentu. Karena itu, alih-alih berfokus pada fitur agen, kami berfokus untuk menjadikan konvensi sebagai infrastruktur yang dapat digunakan kembali.