LLM Cara yang lebih stabil untuk menulis kode adalah dengan menulis DSL terlebih dahulu

Beberapa waktu yang lalu, saya melihat situasi yang sama berulang kali: memberikan persyaratan langsung ke model, kecepatan pembuatannya sangat cepat, dan pengerjaan ulangnya juga cepat; pertama-tama masukkan persyaratan ke dalam lapisan DSL, lalu biarkan model menulis implementasi di sekitar lapisan model semantik ini, dan hasilnya jelas stabil. Perubahannya sangat langsung. Kuncinya bukan apakah modelnya bisa ditulis, tapi apakah ruang opsionalnya sudah ditutup terlebih dahulu.

Bahasa alami cocok untuk memberi tahu arah, namun tidak cocok untuk membawa terlalu banyak keputusan implisit. Persyaratan yang tampaknya sederhana akan dibagi menjadi banyak penilaian kecil ketika diterapkan: bagaimana memberi nama keadaan, apakah kegagalan dianggap selesai, berapa kali mencoba ulang, zona waktu mana yang menjadi dasar jendela waktu, dan di lapisan mana log ditulis. Selama penilaian ini masih tersembunyi dalam proses pembuatannya, model tersebut akan mengisi detail dan mengubah batasan pada saat yang bersamaan. Hal tertulis terakhir dapat dijalankan, tetapi sulit untuk ditinjau.

Bahasa alami hanya cocok untuk membicarakan masalah

LLM sangat baik dalam mengembangkan deskripsi yang samar-samar menjadi teks yang lengkap, dan juga sangat baik dalam menyelesaikan suatu maksud menjadi draf yang dapat dibaca. Yang kurang baik adalah penamaan yang stabil dalam jangka panjang dan batasan pada seperangkat aturan bisnis. Ketika persyaratan melibatkan aliran negara, cabang abnormal, batas waktu, dan batas izin, kata-kata ini tampak jelas dalam pikiran, namun sering kali tidak diselesaikan ketika benar-benar dimasukkan ke dalam kode. Model tersebut menghadapi sekelompok besar masalah terbuka, dan keluarannya secara alami akan berfluktuasi.

Inilah sebabnya mengapa kata-kata cepat yang panjang sering kali menjadi semakin melelahkan jika Anda semakin sering menulisnya. Setelah kata perintah terus memanjang, model masih mendapatkan potongan teks bebas, namun teks bebasnya lebih panjang. Ia mengingat lebih banyak konteks tanpa mendapatkan lebih banyak batasan. Jika batasnya tidak ditutup, model hanya bisa terus menebak-nebak.

DSL mengubah penilaian implisit menjadi masukan eksplisit

Setelah mengubah input ke DSL, situasinya berubah. Model tersebut tidak lagi menebak-nebak bisnis berdasarkan kalimat biasa, namun mengisi kekosongan berdasarkan model semantik yang jelas. Untuk skenario pengujian, proses rilis, dan deskripsi grafis, node dan hubungan pertama-tama ditentukan oleh DSL, lalu teks, kode, dan bagan dilengkapi dengan model. Hasilnya akan lebih seperti sesuatu yang tumbuh dari sistem yang sama.

scenario: payment_timeout
steps:
  - send: order.created
  - wait: 3s
  - if: payment_missing
    then: cancel_order
    audit: required

Nilai terbesar dari definisi jenis ini bukanlah definisi tersebut terlihat bagus ketika ditulis, namun dapat dikontrol versinya, dibeda-bedakan, dan ditinjau. Pembuatan kode, dokumentasi, pengujian, dan diagram semuanya dapat berkembang dari model semantik yang sama. Model di sini lebih mirip aktuator dibandingkan inventor. Ia bertanggung jawab untuk menegakkan batasan yang telah ditetapkan dan tidak bertanggung jawab untuk langsung menulis ulang batasan tersebut.

Begitu batas ini ditetapkan, banyak hal yang tadinya berisik akan menjadi sunyi. Apa yang harus dicakup dalam pengujian ini, apakah kegagalan diperkirakan terjadi, dan siapa yang memiliki keputusan akhir mengenai kondisi rollback? Ini tidak lagi dijelaskan langsung dalam bahasa alami, namun ditulis ke dalam struktur yang dapat dieksekusi. Yang dilihat manusia adalah semantik, yang dijalankan mesin adalah semantik, dan yang kita lihat saat pemecahan masalah adalah semantik yang sama.

LLM cocok untuk berpartisipasi dalam pertumbuhan DSL

LLM tidak hanya harus dijalankan di luar DSL. Penggunaan yang lebih tepat adalah membiarkannya berpartisipasi dalam pertumbuhan DSL terlebih dahulu. Masukkan beberapa skenario nyata ke dalamnya, biarkan ia melengkapi kata-kata pembatas, nilai enumerasi, cabang abnormal, dan contoh tandingan, lalu biarkan orang menghentikannya. Ketika DSL diselesaikan, apa yang selanjutnya diserahkan ke model bukanlah bahasa alami yang tidak terbatas, tetapi masukan yang dibatasi.

Pada tahap ini, LLM cukup bermanfaat. Hal ini dapat membantu menyelaraskan pernyataan yang tersebar ke dalam serangkaian istilah, dan juga dapat mengidentifikasi masalah seperti ketidakkonsistenan penamaan, kesenjangan status, dan hilangnya jalur abnormal selama tahap draf. Setelah model semantik stabil, model akan menghasilkan implementasi, diagram skematik, dan sampel pengujian. Outputnya akan lebih seperti berlari di trek dan tidak akan berpindah ke tempat lain setiap saat.

Saya lebih suka menempatkan LLM di belakang DSL. Perjelas dulu batasannya, lalu biarkan mereka membantu mengisi batasan tersebut nanti, sehingga sistem tidak mudah terganggu oleh improvisasi yang berulang-ulang.

Lapisan semantik juga akan menjadi berat

Lebih banyak DSL tidak selalu lebih baik. Ketika kondisi lapangan masih berubah secara drastis, solidifikasi dini akan menghasilkan asumsi yang salah; jika lapisan semantik dirancang terlalu universal, itu akan menjadi kerangka kerja berat lainnya. Skenario yang benar-benar hemat biaya biasanya terjadi ketika jenis tindakan yang sama terjadi berulang kali, biaya peninjauan tinggi, dan perilaku tersebut harus dapat ditelusuri. Pada titik ini, DSL tidak lagi menjadi beban tambahan, melainkan kumpulan penilaian yang tersebar menjadi pintu masuk yang stabil.

Oleh karena itu, penilaian yang lebih praktis bukanlah “Dapatkah LLM dilengkapi dengan DSL?” tetapi “Apakah semantik masalah ini perlu diperbaiki terlebih dahulu?” Begitu jawabannya adalah ya, kata isyarat tersebut seharusnya tidak lagi memiliki tanggung jawab penuh. Prompt bertanggung jawab untuk menjelaskan maksudnya, DSL bertanggung jawab untuk membawa batasan, dan model bertanggung jawab untuk mengubah batasan menjadi hasil yang dapat dieksekusi. Apa yang ditulis dengan cara ini lebih seperti sebuah sistem rekayasa daripada serangkaian improvisasi.