Pengantar — ilusi spesifikasi bahasa Inggris
- Tulisan ini dimulai dari inspirasi artikel, "spesifikasi yang cukup rinci adalah kode". Spesifikasi berbahasa Inggris tampak intuitif dan presisi, tetapi saat benar-benar hendak diimplementasikan, ambiguitasnya mulai terlihat
- "Segala sesuatu itu ambigu sampai Anda mencoba membuatnya presisi" — Bertrand Russell
- Pemrograman, seperti menulis, adalah aktivitas iteratif yang makin lama makin diasah menjadi tajam sambil dikerjakan (esai ini pun melewati banyak draf)
Vibe coding — mengapa bekerja, dan mengapa berbahaya
- Karena AI makin cepat dan makin baik dalam mengubah bahasa Inggris menjadi kode yang bisa dijalankan, kini kita bisa membuat kode dengan "nuansa (vibe)" setingkat bahasa Inggris
- Sambil bereaksi terhadap hasil buatan AI — "pindahkan tombol itu ke sana, bikin lebih biru" — prosesnya perlahan menjadi makin presisi
- Istilah "vibe coding" terasa tepat sekali: mempertahankan vibe setingkat bahasa Inggris sambil menajamkan pemikiran lewat keluaran AI
- Masalah intinya: vibe memberi ilusi bahwa itu adalah abstraksi yang presisi. Saat fitur bertambah atau skala membesar, abstraksi itu mulai bocor (
leaky abstraction) dan bug tak terduga bisa menghabiskan satu hari penuh
Kasus nyata — aplikasi vibe coding Dan Shipper
- Aplikasi editor teks yang dibuat Dan Shipper lewat vibe coding menjadi viral → server tumbang
- Penyebabnya: "kolaborasi real-time (live collaboration)" tampak intuitif dan sederhana, padahal kenyataannya punya kompleksitas setingkat mimpi buruk
- Kita semua pernah memakai Google Docs dan Notion, jadi "kolaborasi real-time" terasa seolah sudah terspesifikasi dengan presisi. Padahal, sangat sulit mengetahui sebelumnya mengapa itu tidak sesederhana kelihatannya
- Penulis sendiri 10 tahun lalu pernah membuat editor kolaboratif dan mengalami mimpi buruk kompleksitas yang tak terduga. Apa yang sulit? Bahkan dia sudah tidak ingat! Itu bagian dari masalahnya — kompleksitas itu membosankan, tidak ingin dipikirkan, dan detail maupun edge case sulit diingat
- Contoh: flowchart klasik Slack untuk menentukan apakah notifikasi harus dikirim — kompleksitas sebesar ini bersembunyi di balik ungkapan sederhana seperti "kirim notifikasi"
Abstraksi — satu-satunya alat untuk menangani kompleksitas
- Keterbatasan mendasar otak manusia: hanya bisa menangani 7±2 hal sekaligus
- Satu-satunya cara menangani lebih dari 7 hal: mengompres beberapa hal menjadi satu. Ini bisa diulang secara rekursif tanpa batas, sehingga manusia dapat menangani kompleksitas tak terbatas. Tahap kompresi inilah yang disebut abstraksi (abstraction)
- "Tujuan abstraksi bukanlah menjadi kabur, melainkan menciptakan tingkat makna baru yang dapat benar-benar presisi" — Dijkstra
- Contoh Sophie Alpert yang merapikan flowchart notifikasi Slack yang terkenal ruwet menjadi jauh lebih sederhana lewat abstraksi yang cerdas
- Bagian terbaik dari pemrograman: menaklukkan kompleksitas dengan menciptakan abstraksi yang makin baik, seperti yang dilakukan ReactJS atau TailwindCSS di ranahnya masing-masing
- Fakta bahwa editor teks kolaboratif pada dasarnya kompleks hanya berarti kita harus terus mencari abstraksi yang lebih baik
AGI — kode yang baik tetap tidak akan hilang
- Jika membayangkan 1 tahun, 2 tahun, 5 tahun, 10 tahun, hingga 100 tahun ke depan: AI akan terus menjadi lebih baik/lebih cepat/lebih murah, dan pada akhirnya datang titik ketika kecerdasan mesin tak dapat dibedakan dari manusia (AGI)
- Dunia AGI bisa terlihat seperti dunia vibe. Jika Anda bisa mempekerjakan 100 jenius setingkat Karpathy dengan $1000/bulan, mengapa repot memikirkan detail yang melelahkan?
- "Ini benar-benar omong kosong yang lucu." Pikiran seperti ini hanya terdengar mungkin secara abstrak sebelum teknologinya benar-benar tiba
- Jika kita punya akses ke tingkat kecerdasan seperti itu, persentase orang yang memakainya untuk menghasilkan lebih banyak slop adalah 0%. Tentu saja bukan itu yang akan terjadi
- Alasan kita bingung: kita keliru menganggap kode hanya untuk memproduksi software. Padahal kode itu sendiri adalah hasil utama. Jika dibuat dengan baik, ia bisa seperti puisi
- "Tidak ada yang bicara soal 'vibe writing', kan?" — dalam menulis, tak ada yang sungguh percaya ChatGPT akan menggantikan novelis atau jurnalis hebat. Kode pun sama, hanya saja ada ilusi karena "keajaiban" bahwa kode bisa dieksekusi
- AI menghasilkan kode yang (semakin tidak) buruk. Kita semua tahu ini. Kita memakai AI meskipun kodenya buruk, bukan karena kodenya buruk
- Kutipan Simon Willison: "AI seharusnya membantu kita membuat kode yang lebih baik"
- Hal pertama yang akan dilakukan saat AGI datang: memecahkan masalah abstraksi yang paling sulit. Menciptakan abstraksi yang lebih baik agar kompleksitas bisa dipahami dan ditaklukkan dengan lebih baik
- Gagasan bahwa kebutuhan akan kode yang baik hilang ketika AI makin pintar? Itu sama saja dengan berkata kita akan memakai ChatGPT untuk menghasilkan lebih banyak slop
- Contoh nyata: Opus 4.6 menyelesaikan masalah yang belum terpecahkan dalam sekali jalan saat membangun framework React full-stack milik Val Town (
vtrr). Demo aplikasi full-stack satu file sepanjang 50 baris adalah hasilnya
Kesimpulan — kode baru saja dimulai
- Sepertinya 99% masyarakat setuju dengan gagasan "kode sudah mati". Bahkan kemarin penulis mendengar podcaster Sam Harris dengan yakin berkata, "semua orang setuju coding sudah mati, tidak ada lagi yang perlu belajar coding"
- "Ini menyedihkan. Ini seperti mengatakan 'storytelling sudah mati' setelah mesin cetak ditemukan. Kalian bodoh, kode baru saja dimulai. AI akan menjadi berkah luar biasa bagi coding."
- Kutipan penutup:
- "Alih-alih menganggap kewajiban memakai simbol formal sebagai beban, kita seharusnya melihatnya sebagai hak istimewa. Berkat itu, para pelajar kini bisa melakukan hal-hal yang dulu hanya bisa dilakukan para jenius" — Dijkstra
- "Mampu menggunakan bahasa ibu secara 'alami' tak lebih dari kemampuan dengan mudah membuat kalimat yang omong kosongnya tidak tampak jelas" — Dijkstra, "On the foolishness of natural language programming"
- "Ada dua cara merancang software: membuatnya begitu sederhana sehingga cacatnya jelas tidak ada, atau membuatnya begitu rumit sehingga tidak ada cacat yang tampak jelas" — Tony Hoare
- "Jumlah makna yang dipadatkan ke dalam ruang kecil lewat simbol aljabar memudahkan penalaran yang kita lakukan melaluinya" — Charles Babbage
7 komentar
Bahkan sebelum masuk ke pembahasan penyuntingan kolaboratif, hanya untuk mengimplementasikan dengan benar satu editor yang dipakai sendiri saja sudah penuh dengan kompleksitas tak terduga seperti penanganan kursor, stack undo/redo, dan input IME. Seperti yang ditunjukkan dalam tulisan itu, hampir tidak ada perangkat lunak yang menampilkan jebakan dari "spesifikasi yang terasa intuitif sekaligus presisi" sejelas editor. Pada akhirnya, sesuatu yang terlihat mudah bukan benar-benar mudah, melainkan kompleksitasnya telah diabstraksikan dan disembunyikan dengan baik.
Sebenarnya, alasan Anthropic membuat compiler C sebagai demo kemungkinan juga karena compiler memiliki spesifikasi yang jelas dan test case yang sudah dipersiapkan dengan baik. Sekaligus juga terlihat sangat sulit.
Saya pernah membuat beberapa compiler dan sekarang juga sedang mengerjakan satu; ketika dilihat dari sudut pandang vibe coding, saya juga sempat mencoba editor, tetapi compiler terasa lebih mudah. Seperti yang Anda tulis, spesifikasinya terasa kurang presisi dan ada jauh lebih banyak variabel yang berasal dari pengguna. Pengujiannya juga lebih sulit.
Spesifikasi memang menjadi semakin penting, tetapi sejak dulu saya merasa mustahil untuk menuliskan spesifikasi secara sangat rinci dan mencakup semua situasi. Saya masih berpikir pendekatan yang lebih baik untuk saat ini adalah menyempurnakan spesifikasi sambil bekerja, seperti halnya kode; meski begitu, saya juga merasa mungkin saja itu bisa dibiarkan dilakukan antarsesama oleh berbagai agen. Namun pada akhirnya, tanpa campur tangan manusia, rasanya sulit untuk keluar dari situasi dan pengetahuan yang sudah dipelajari, sehingga menghadapi situasi dan fungsi yang benar-benar baru akan tetap sulit.
Rasanya seperti ketika robot vacuum pertama kali muncul dan saya mendengar bahwa kita harus melakukan "pembersihan sederhana" dengan membereskan barang-barang di lantai demi si robot. Menulis spesifikasi yang rinci demi AI juga merupakan pekerjaan yang cukup besar, jadi terasa seperti kita bekerja untuk AI.
IDE dan PR sudah mati semua, tapi kode malah hidup lagi?
Kode adalah spesifikasi yang secara logis paling akurat dalam sistem sederhana.
Namun jebakannya, dunia nyata adalah sistem kompleks.. pada akhirnya hanya data yang setidaknya menjadi spesifikasi paling akurat
Sepertinya kita perlu melihat apakah itu bisa digantikan dengan metode verifikasi lain. Semakin dekat ke front-end, kemungkinan cukup dengan E2E melalui perilaku browser untuk memverifikasi bahwa semuanya bekerja dengan baik. Namun, semakin dekat ke back-end dan infrastruktur, code review tampaknya akan menjadi hal yang esensial. Jika tidak, akan sulit memverifikasi side effect seperti transaction yang terbuka dan tertutup tanpa terlihat, atau panggilan API yang terkirim.
Di browser ada banyak sekali isu yang bahkan tidak bisa ditangkap dengan E2E.