CodeSpeak - bahasa baru dari pencipta Kotlin: berbicara dengan LLM lewat spesifikasi, bukan bahasa Inggris

• Bahasa pemrograman generasi berikutnya berbasis LLM yang dapat mengurangi codebase 5–10x
• Developer menulis spesifikasi (spec) yang ringkas alih-alih kode, lalu kode dibuat otomatis dengan perintah codespeak build
• Saat spesifikasi berubah, sistem mengubah perbedaan spesifikasi (diff) menjadi perbedaan kode dan menerapkannya
• Juga mendukung proyek campuran yang berisi kode tulis manual dan kode hasil generasi, dan pada contoh open source nyata terlihat peningkatan tingkat kelulusan tes
• Berfokus pada engineering tingkat tim untuk menangani software kompleks, dengan tujuan menghadirkan lingkungan pengembangan yang ramah bagi manusia lewat pemeliharaan berbasis spesifikasi

---

Gambaran umum CodeSpeak

• CodeSpeak adalah bahasa pemrograman generasi berikutnya yang digerakkan LLM, dengan tujuan mengurangi codebase hingga 5–10x
  • Menurut penjelasan di situsnya, efisiensi ditekankan lewat frasa “Shrink your codebase 5–10x”
• Bahasa ini merupakan alat untuk membangun sistem kelas produksi, dirancang untuk proyek jangka panjang, bukan sekadar prototipe sederhana
• Pengguna utamanya dibayangkan sebagai tim engineer yang mengembangkan software kompleks, dan arahnya adalah pengembangan kolaboratif, bukan coding eksperimental yang berpusat pada developer individu

Metode pengembangan berbasis spesifikasi

• Inti CodeSpeak adalah filosofi “Maintain Specs, Not Code”
  • Developer menulis spesifikasi (spec) yang ringkas, lalu kode dibuat otomatis dengan perintah codespeak build
  • Ketika spesifikasi diubah, sistem otomatis mengubah perubahan spesifikasi (diff) menjadi perubahan kode (diff)
• Pendekatan ini menekankan bahwa memelihara dan mengelola spesifikasi lebih mudah bagi manusia dibanding kode

Dukungan proyek campuran

• CodeSpeak mendukung proyek di mana kode manual yang sudah ada dan kode hasil generasi hidup berdampingan
  • Sebagai contoh, diperkenalkan kasus fork dari repositori MarkItDown milik Microsoft
  • Tersedia panduan tutorial untuk menangani proyek campuran secara bertahap

Fitur konversi kode → spesifikasi (direncanakan)

• CodeSpeak sedang menyiapkan fitur yang menganalisis kode yang sudah ada lalu mengubahnya menjadi spesifikasi
  • Dengan ini, sebagian kode yang ada bisa diganti dengan spesifikasi yang 5–10x lebih kecil
  • Ditekankan bahwa pemeliharaan spesifikasi lebih ramah bagi manusia daripada pemeliharaan kode

Studi kasus nyata (Case Studies)

• CodeSpeak menguji beberapa kode proyek open source dengan mengubahnya menjadi spesifikasi
  • Dukungan subtitle WebVTT di yt-dlp: 255 LOC → 38 LOC, menyusut 6.7x, 37 tes ditambahkan
  • Generator SSN Italia di Faker: 165 LOC → 21 LOC, menyusut 7.9x, 13 tes ditambahkan
  • Deteksi otomatis encoding di beautifulsoup4: 826 LOC → 141 LOC, menyusut 5.9x, 25 tes ditambahkan
  • Konverter EML→Markdown di markitdown: 139 LOC → 14 LOC, menyusut 9.9x, 27 tes ditambahkan
• Di tiap kasus, tingkat kelulusan tes dipertahankan atau meningkat, menunjukkan efektivitas pendekatan berbasis spesifikasi

Ringkasan

• CodeSpeak adalah bahasa pemrograman AI yang berpusat pada spesifikasi, menggabungkan pembuatan kode otomatis dan efisiensi pemeliharaan
• Fitur utamanya meliputi generasi kode berbasis LLM, sinkronisasi spesifikasi-kode, dan dukungan proyek campuran
• Pada kasus nyata, pengurangan kode dan peningkatan tes telah terbukti, sehingga menunjukkan potensi peningkatan produktivitas software engineering tingkat tim

[roxie]

Menyebut ini sebagai bahasa cuma demi cari perhatian, atau memang zamannya sudah seperti itu.

[brainer]

> Seperti yang dikatakan Joel Spolsky dalam kuliahnya di Yale, upaya untuk ‘menghasilkan program dari spesifikasi (spec)’ selalu gagal.
> Jika spesifikasi cukup rinci hingga sepenuhnya mendefinisikan program, itu berarti menulis spesifikasi tersebut sama sulitnya dengan menulis programnya sendiri.

Saya setuju secara prinsip, tetapi pada saat yang sama rasanya ini agak terlalu jelas. Seperti pembuktian Gödel bahwa sejak awal memang tidak ada yang benar-benar lengkap, kritik ini terasa seperti mengkritik upaya tersebut dengan asumsi bahwa produk yang sepenuhnya lengkap itu memang bisa ada.

[halfenif]

Ini mengingatkan pada MDD(Model Driven Dev.).

[GN⁺]

Komentar Hacker News

• Seperti yang dikatakan Joel Spolsky dalam kuliah di Yale, upaya untuk "menghasilkan program dari spesifikasi (spec)" selalu gagal
  Jika sebuah spesifikasi cukup rinci untuk mendefinisikan program sepenuhnya, maka menulis spesifikasi itu sendiri sama sulitnya dengan menulis programnya
  Tautan kuliah asli

  • "Generasi kode berbasis spesifikasi" pada 2007 dan maknanya sekarang benar-benar berbeda
    Sekarang program bisa dibuat bahkan dari prompt yang tidak lengkap, dan riset tentang cara menangani prompt secara sistematis layak dilakukan
  • Kini kode makin menjadi sesuatu yang amorf (amorphous)
    Skalabilitas bergerak dari penambahan fitur menuju pendefinisian batasan perilaku dan invariansi struktural
  • Di perusahaan saya sering melihat orang menulis secara prosedural
    Seperti, "1. minta pengguna memasukkan informasi, 2. kirim permintaan HTTP, 3. laporkan jika terjadi error",
    padahal menurut saya menulis skrip langsung jauh lebih cepat dan deterministik
  • Sebuah candaan tentang solusi yang tidak terpikirkan Joel di era pra-AI: cukup buat "kristal pikiran (crystal)" untuk menafsirkan spesifikasi

• Ini bukan bahasa baru, melainkan workflow dan tool untuk pengembangan berbasis LLM
  Alih-alih kode, yang dipelihara adalah file spesifikasi Markdown, lalu codespeak memodifikasi kode berdasarkan diff spesifikasi
  Kelebihannya, prompt ikut dikelola versinya bersama kode; kekurangannya, spesifikasi tidak bisa mencerminkan semua detail kode

  • Ditambahkan analogi bahwa bahasa C pada akhirnya juga merupakan workflow pengganti untuk pengembangan assembly
  • Pada akhirnya kita memang akan menuju dunia di mana manusia tidak perlu lagi menyentuh kode secara langsung, tapi belum sekarang
    Sedang diuji alat bernama codespeak takeover untuk mengubah kode menjadi spesifikasi, dan agar prompt dari sesi agen ikut tercermin
    Ini dijelaskan sebagai peralihan dari mode "sprint" jangka pendek ke mode "maraton" jangka panjang
    Tautan blog terkait
  • Saya rasa sulit menjadikan ini bisnis
    Idenya sederhana sehingga siapa pun bisa dengan cepat mengimplementasikan ulang, dan versi open source kemungkinan segera menggantikannya
  • Jika untuk perbaikan kode sepele saja (misalnya bug off-by-one) kita harus mengubah spesifikasi, itu tidak efisien
    Diusulkan perlunya kebijakan yang mengizinkan "perubahan kecil"
    Secara keseluruhan, konsep kompiler pseudocode bertahap terasa menarik
  • Terasa terlalu formal
    Lima tahun lagi, rasanya kita tidak akan menulis kode seperti ini, dan spesifikasi teknis setingkat bahasa Inggris saja sudah cukup

• Pendekatan ini lebih merupakan tooling untuk memetakan spesifikasi ke kode ketimbang bahasa
  Namun model bersifat nondeterministik, jadi spesifikasi yang sama pun bisa menghasilkan hasil berbeda setiap kali
  Spesifikasi pada dasarnya adalah ringkasan dengan kehilangan informasi besar, sehingga sulit menjaga konsistensi dalam codebase skala besar
  Yang ingin saya lihat adalah pipeline yang dapat diverifikasi: spesifikasi teks → spesifikasi formal (formal spec) → kode

  • Ada argumen balasan bahwa jika hasilnya selalu benar secara logis, maka tidak masalah meskipun kodenya berbeda
    Yang penting bukan kodenya sendiri, melainkan konsistensi hasil perilaku
  • Namun spesifikasi formal pun bisa berbeda setiap kali
    Semakin abstrak spesifikasi dibanding kode, semakin banyak implementasi yang mungkin, jadi determinisme tetap tidak terjamin
  • Saya membuat AGENTS.md, DESIGN.md, TECHNICAL-SPEC.md dan melakukan pengembangan berbasis spesifikasi informal
    Saya pikir pengujian otomatis seharusnya berperan sebagai spesifikasi yang sesungguhnya
  • Ada yang meragukan klaim bahwa model itu nondeterministik
    Menurutnya, jika seed dikunci, input yang sama bisa menghasilkan output yang sama
  • Saya menggunakan Kiro IDE sebagai pembuat spesifikasi
    Cursor atau Antigravity dioptimalkan untuk 'vibe coding' yang berpusat pada manusia, tetapi Kiro dikhususkan untuk pengembangan berbasis spesifikasi yang berpusat pada agen
    Kiro memakai format terstruktur seperti EARS dan INCOSE, serta menghasilkan pemeriksaan konsistensi otomatis dan property-based testing (PBT)
    Jika spesifikasinya kokoh, implementasi hampir mengikuti secara otomatis
    Saya juga menjalankan beberapa agen CLI secara paralel untuk mendapatkan hasil dengan tingkat kematangan tinggi

• Masalah pada bahasa prompt formal bukanlah ambiguitas, melainkan kurangnya kemampuan model memahami konteks
  Prompt yang sama bisa menghasilkan hasil berbeda tergantung konteks
  Seformal apa pun prompt-nya, tidak ada gunanya jika model salah memahami codebase

  • Ada dua saran yang sering terdengar
    1. reset konteks secara berkala
    2. beri agen tool bergaya Unix agar ia bisa berinteraksi dengan perintah pseudo-English yang sederhana
       Karena model dioptimalkan untuk bahasa percakapan, lebih baik tidak langsung menulis bahasa formal dan hanya memakainya saat perlu

• Ada harapan sederhana: andaikan niat bisa disampaikan ke komputer dengan cara yang deterministik dan formal

• Konsep ini berangkat dari asumsi yang salah dalam memahami struktur internal LLM
  Menurut riset terbaru, LLM memiliki tahap pemrosesan terpisah antara encoding dan decoding,
  dan setelah pelatihan, bahasa itu sendiri mungkin tidak lagi terlalu penting
  Tautan riset terkait

  • CodeSpeak bukan untuk LLM, melainkan alat terstruktur untuk manusia
    Tujuannya membantu manusia mengekspresikan apa yang mereka inginkan dengan lebih jelas

• Saya tidak yakin tool seperti ini benar-benar diperlukan
  Cukup tulis spesifikasi Markdown langsung, lalu minta agen menghasilkan kodenya

• Di bagian "Prerequisites" pada tutorial tertulis bahwa kunci API Anthropic diperlukan
  Mungkin itu hanya langkah sementara karena masih versi alpha, tetapi saya penasaran kenapa harus memakai API
  Rasanya prompt bisa saja langsung disuntikkan ke sesi seperti Claude Code
  Tautan referensi

• Menarik karena proyek ini sangat mirip dengan spesifikasi bahasa eksekutor LLM yang sedang saya kerjakan
  Proyek saya, AIL, mendefinisikan dan menjalankan rantai prompt berbasis YAML
  Intinya adalah menempatkan "mesin pemurnian prompt" yang mengubah bahasa alami pengguna menjadi perintah terstruktur
  Misalnya, menganalisis maksud pengguna, memecahnya menjadi beberapa langkah, lalu mengoptimalkannya sesuai standar prompt engineering modern
  Jika ada interceptor seperti ini, alur seperti "ubah apa yang baru saja saya katakan ke format CodeSpeak" akan dimungkinkan
  Ini ide yang sangat keren, dan saya pasti ingin mendalaminya lebih jauh