Desain untuk Agen: Alasan Zero Ada dan Apa Kompromisnya

Pertanyaan yang Diajukan Zero

Premis di balik Zero sederhana: saat agen AI, bukan hanya manusia, membaca, menulis, dan memperbaiki kode, seperti apa bentuk yang ideal untuk bahasanya sendiri?

Bahasa yang sudah ada dirancang jauh sebelum agen bisa menulis kode. Prioritasnya, seperti sintaks yang ringkas, idiom yang ekspresif, dan library yang cerdik, masuk akal bagi manusia yang mengetik di editor. Bahasa-bahasa itu menoleransi ambiguitas dan konversi implisit karena manusia pandai mengisi celah. Agen tidak. Agen menghasilkan teks persis dari distribusi probabilitas, dan setiap sisi bahasa yang kabur dibayar dengan token yang salah di suatu tempat di hilirnya.

Zero memulai dari awal dengan batasan yang dibalik: rancang untuk agen lebih dulu, terima kenyataan bahwa manusia tetap akan membaca kodenya, lalu lihat hasilnya.

Prinsip 1: Permukaan yang Kecil dan Teratur

Sebagian besar bahasa pemrograman terus bertambah besar. Setiap rilis baru menambahkan kemudahan kecil: operator baru, bentuk sintaks baru, cara baru untuk mengungkapkan sesuatu yang sebenarnya sudah bisa dilakukan. Setiap tambahan sepadan untuk kenyamanan manusia, tetapi setiap tambahan juga membebani agen: satu varian lagi yang harus dipelajari, satu cara lagi untuk salah.

Zero sengaja menjaga permukaannya tetap sangat kecil:

• Satu bentuk binding (let).
• Satu bentuk fungsi (fun, dengan pub sebagai pilihan).
• Satu perulangan saat ini (while).
• Satu cara untuk memodelkan product type (shape).
• Satu cara untuk memodelkan sum type dengan payload (choice).
• Satu cara untuk memodelkan sum type berlabel (enum).
• Satu konstruksi pattern matching (match).

Tidak ada operator overloading, decorator, macro, konversi implisit, konversi truthy, atau operator ternary. Setiap ketiadaan itu adalah fitur: satu tempat lagi di mana agen bisa memilih varian yang salah jadi hilang.

Biayanya jelas: fitur kemudahan jadi lebih sedikit. Manfaatnya, agen yang mempelajari Zero dalam satu sesi bisa langsung menemukan sintaks yang benar tanpa harus menimbang tujuh pilihan yang hampir setara.

Prinsip 2: Efek yang Eksplisit

Sebagian besar bahasa membolehkan fungsi apa pun, di mana pun, melakukan I/O. console.log di JavaScript, printf di C, print di Python. Signature fungsinya tidak memberi petunjuk apakah fungsi itu mungkin menulis ke file atau mengakses jaringan. Satu-satunya cara untuk tahu adalah membaca isinya, dan isi fungsi yang dipanggilnya, dan seterusnya.

Zero mengambil posisi sebaliknya: setiap efek yang dimiliki sebuah fungsi terlihat di signature-nya.

• I/O dijaga oleh capability World. Fungsi yang tidak menerima World tidak bisa melakukan I/O. Sistem tipe memastikan hal ini.
• Kegagalan dijaga oleh raises dan check. Fungsi yang bisa gagal menyatakannya di signature. Setiap pemanggil mengakuinya dengan check atau konstruksi eksplisit lainnya.

Hanya dari signature sebuah fungsi, kamu bisa menjawab dua pertanyaan yang sangat penting bagi agen (atau static analyzer, atau reviewer manusia):

• "Mungkinkah fungsi ini menyentuh dunia luar?" Ya, jika dan hanya jika World muncul.
• "Mungkinkah fungsi ini gagal?" Ya, jika dan hanya jika raises muncul.

Sifat seperti ini tidak ada di bahasa-bahasa populer, dan sifat ini bukan hal kecil.

Biayanya adalah banyaknya parameter yang harus diteruskan. Nilai World dikirim ke mana pun I/O dibutuhkan, dan klausa raises diulang di mana pun error mengalir. Zero menerima itu sebagai harga untuk sifat tersebut.

Prinsip 3: Tooling yang Deterministik

Prinsip ketiga paling langsung ditujukan untuk agen: setiap output yang dihasilkan compiler berupa data terstruktur.

Diagnostik JSON adalah contoh utamanya:

{
    "code": "NAM003",
    "message": "unknown identifier",
    "line": 3,
    "repair": { "id": "declare-missing-symbol" }
}

Ada tiga sifat yang membuatnya berbeda dari error compiler biasa:

1. Kode yang stabil. NAM003 berarti hal yang sama hari ini dan besok, apa pun kata-kata di pesan yang ditujukan untuk manusia.
2. Rencana perbaikan yang terstruktur. Saat compiler merasa tahu cara memperbaiki sebuah diagnostik, compiler menghasilkan rencana berupa data, yaitu daftar edit, bukan saran dalam bahasa Inggris.
3. Beberapa saluran terstruktur. Diagnostik, dependency graph, laporan ukuran, dan penjelasan semuanya tersedia lewat mode --json.

Intinya, sebuah tool, agen atau bukan, tidak pernah perlu mengurai bahasa Inggris untuk bertindak berdasarkan output compiler. Mencari kode yang stabil itu pasti, sedangkan mengurai kalimat itu kabur. Zero memperlakukan yang pertama sebagai kontrak dan yang kedua sebagai kemudahan untuk manusia.

Prinsip 4: Library yang Menyatu dengan Bahasanya

Agen pandai menulis kode yang mengikuti pola yang sudah ada. Agen kurang pandai memilih dependency eksternal yang tepat dari lautan pilihan, mengintegrasikannya dengan benar, dan mengikuti perubahan API-nya. Setiap dependency eksternal adalah hambatan.

Desain Zero mendorong kemampuan-kemampuan itu masuk ke standard library, yang terdokumentasi secara eksplisit, saling konsisten, dan stabil seiring bahasanya makin stabil. Tujuannya, program Zero jarang perlu mencari ke luar distribusi standar untuk pekerjaan rutin. Dengan begitu, permukaan yang harus dinalar agen tetap terbatas.

Untuk saat ini, ini masih cita-cita, belum kondisi yang sudah selesai. Standard library pra-1.0 sudah nyata, tetapi masih terus berkembang. Prinsip ini adalah arah, bukan tujuan akhir.

Kompromi yang Diambil Zero

Setiap pilihan desain ada harganya. Kompromi yang jujur diambil Zero:

• Panjang daripada ringkas. Fungsi murni tidak butuh World. Fungsi yang bisa melakukan I/O butuh. Error terlihat di signature. Hasilnya, anotasi lebih banyak daripada kode setara di JavaScript atau Python.
• Eksplisit daripada ajaib. Tidak ada metaprogramming reflektif, tidak ada decorator yang diam-diam membungkus perilaku, tidak ada variabel global implisit. Hal-hal yang di bahasa dinamis terlihat "langsung jalan" harus dirangkai secara manual.
• Statis daripada dinamis. Tipe wajib ditulis pada parameter, nilai kembalian, dan field shape. Compiler melakukan banyak pekerjaan, dan biayanya adalah setiap signature harus ditulis oleh penulis (atau generator) kode.
• Stabilitas daripada kecepatan perubahan. Bahasanya masih pra-1.0 dan berubah cepat, tetapi maksud desainnya adalah mengunci permukaannya begitu sudah mapan. Biayanya, menambahkan fitur kemudahan yang cerdik di kemudian hari jadi lebih sulit, karena syarat sebuah tambahan adalah "apakah ini lebih membantu agen daripada membebaninya?"

Apakah kompromi itu sepadan tergantung pada apa yang ingin kamu optimalkan. Kalau kamu manusia yang menulis script sekali pakai, hambatannya terasa nyata dan manfaat untuk agen terasa abstrak. Kalau kamu menjalankan agen yang menghasilkan ribuan program kecil per hari, hambatan itu terbayar berkali-kali lipat.

Yang Tidak Ingin Dicapai Zero

Beberapa pernyataan negatif yang perlu dibuat jelas:

• Bukan "masa depan seluruh pemrograman". Zero adalah hipotesis, bukan manifesto. Hipotesisnya adalah batasan yang mengutamakan agen menghasilkan bahasa yang berguna. Apakah bahasa-bahasa populer harus mengikuti batasan itu adalah pembahasan lain yang lebih panjang.
• Bukan fitur platform deployment Vercel. Meskipun berasal dari Vercel Labs, Zero tidak terikat dengan Next.js atau hosting Vercel. Zero adalah bahasa sistem yang berdiri sendiri.
• Bukan pengganti Rust, Go, atau Zig di production. Masih pra-1.0. Masih eksperimental. Pakai untuk belajar dan memberi masukan, tetapi jangan dulu merilis software untuk pelanggan dengannya.
• Belum selesai. Bagian-bagian standard library, sintaks mutabilitas, bentuk penanganan error, dan batasan pada generic semuanya bisa berubah sebelum 1.0.

Yang Tetap Menarik Meskipun Kamu Tidak Memakainya

Meskipun kamu tidak pernah menulis satu baris pun kode Zero, eksperimen ini tetap memberi pelajaran:

• Ini contoh paling jelas dari sistem efek berbasis capability yang nyata dan berjalan di bahasa sistem yang kecil. Model berpikirnya, yaitu kirim izinnya lalu lihat efeknya di signature, bisa dibawa ke bahasa lain.
• Cara Zero menangani diagnostik adalah hal yang seharusnya sudah dilakukan setiap compiler sejak satu dekade lalu. Output terstruktur selalu lebih unggul daripada kalimat, dan komitmen Zero pada kode yang stabil bisa diadopsi tool lain tanpa perubahan bahasa apa pun.
• Prinsip "satu cara untuk setiap hal, permukaan yang sengaja dibuat kecil" berlawanan dengan cara desain bahasa yang biasa dilakukan. Mengamati di mana prinsip itu membantu dan di mana prinsip itu membatasi tetap berguna, apa pun bahasa yang akan kamu tulis besok.

Bacaan Berikutnya

Kalau kamu sudah menyelesaikan seluruh dokumentasi ini, bacaan berikutnya yang paling berguna ada di luar sini:

• Repository Zero di github.com/vercel-labs/zero: contoh, kode sumber, dan AGENTS.md yang berisi pernyataan maksud dari para maintainer-nya sendiri.
• Situs resminya di zerolang.ai: petunjuk memulai dan pengenalan resminya.

Keduanya terus berkembang. Apa yang kamu temukan di sana akan lebih baru daripada tutorial pihak ketiga mana pun. Prinsip di dokumen ini adalah bagian yang lambat berubah, sedangkan sintaks di sekitarnya akan terus bergerak selama bahasanya belum mapan.