Menara Terus Menjulang

• Perangkat lunak yang di-vibe coding yang berubah secara acak dan tak terduga mirip dengan Menara Babel, yang pembangunannya terhenti karena kehilangan bahasa bersama, tetapi di era AI perbedaannya adalah pembangunan terus berlanjut bahkan setelah pemahaman runtuh
• Batas kemampuan perangkat lunak berskala besar tidak hanya bergantung pada kecepatan seseorang menghasilkan kode, tetapi juga pada seberapa baik pemahaman bersama tentang konsep, batas, invariant, kepemilikan, dan alasan desain dapat diselaraskan
• Gesekan yang muncul dalam penelusuran kode, bertanya, review, dan koordinasi antartim memang merupakan pemborosan, tetapi sekaligus menjadi proses untuk menyinkronkan pemahaman satu sama lain dan memastikan kesepakatan tentang sistem
• Agen menjalankan pekerjaan seperti menambahkan OAuth, caching, atau membangun ulang database secara paralel tanpa percakapan; meski tiap perubahan masuk akal dan lolos pengujian, model bersama manusia dapat melemah
• Dalam rekayasa berbantuan AI, agen menafsirkan dan memodifikasi tiap area sehingga pembangunan berlanjut tanpa kegagalan langsung, membuat hilangnya bahasa arsitektur yang dulu dipakai manusia untuk menalar sistem bersama-sama sulit disadari

---

Kekuatan Menara Babel Ada pada Koordinasi, Bukan Teknologi

• Cara sebagian perangkat lunak hasil vibe coding berubah dengan agak acak dan tak terduga mengingatkan pada The Tower of Babel karya Bruegel
• Kisah Menara Babel sering ditafsirkan sebagai cerita tentang keangkuhan dan ambisi, serta alasan mengapa orang-orang berbicara dalam bahasa yang berbeda, tetapi sekaligus juga menunjukkan persatuan yang memungkinkan kemajuan teknologi
• Dalam Kejadian 11:3–6 (KJV), orang-orang mencapai peningkatan teknologi dengan menggunakan batu bata bakar sebagai pengganti batu, dan aspal sebagai pengganti mortar, lalu berupaya membangun kota dan menara yang mencapai langit
• Yang dipandang Tuhan sebagai masalah bukanlah batu bata atau pengetahuan manufaktur, melainkan fakta bahwa orang-orang itu satu dan berbagi satu bahasa, sehingga tidak ada apa pun yang akan membatasi mereka
• Dengan bahasa bersama, ketika pekerjaan masing-masing digabungkan, mereka dapat membangun sesuatu yang tidak mungkin dibuat siapa pun sendirian
• Ketika bukan batu bata atau resep pembuatannya yang hilang, melainkan kemampuan untuk saling memahami, koordinasi menjadi mustahil dan pembangunan pun berhenti

Menara yang Terus Naik Bahkan Setelah Agen AI Menghilangkan Gesekan

• Pemrograman berbantuan AI memberi individu alat yang lebih kuat, dan pengembang yang menggunakan agen dapat membuat perubahan jauh lebih besar pada codebase
• Namun batas proyek berskala besar tidak hanya ditentukan oleh seberapa cepat seseorang menghasilkan kode, tetapi juga oleh seberapa baik orang-orang menyelaraskan pemahaman tentang sistem yang diubah
• Bahasa bersama dalam proyek perangkat lunak bukanlah bahasa Inggris atau Python itu sendiri, melainkan pemahaman bersama tentang hal-hal berikut
  • Apa arti tiap konsep
  • Di mana batas sistem berada
  • Invariant apa yang penting
  • Siapa memiliki apa
  • Mengapa sistem memiliki struktur seperti sekarang
• Pemahaman semacam ini tidak pernah tercatat sepenuhnya di satu tempat, dan tidak hanya terakumulasi dalam dokumentasi dan kode, tetapi juga dalam code review, percakapan, perdebatan, serta pengalaman menjelaskan perubahan kepada orang lain
• Sebelum ada agen, jika ingin mengubah lapisan storage milik orang lain, sering kali perlu membaca kode, mengajukan pertanyaan, dan berkoordinasi dengan tim lain yang mengoperasikan layanan dependensi
  • Proses ini memang mengandung pemborosan, tetapi juga berfungsi meneruskan pemahaman satu orang kepada orang lain dan memastikan apakah kedua pihak masih sepakat tentang cara kerja sistem
  • Gesekan seperti ini menyinkronkan pemahaman orang-orang
• Agen sangat mengurangi gesekan ini, sehingga beberapa orang dapat meminta perubahan berbeda tanpa saling berbicara
  • Satu orang menambahkan OAuth, orang lain memasukkan caching, sementara yang lain lagi membangun ulang database dari awal dan membuat UI berwarna merah muda
  • Tiap perubahan bisa saja masuk akal secara independen, kode dapat dikompilasi dan lolos pengujian, bahkan penjelasan dapat dibuat saat diperlukan
  • Tidak seorang pun perlu berbicara dengan orang lain, atau mempelajari bagian dari model bersama yang dulu akan mereka pelajari selama proses perubahan
• Agen tidak merasakan rasa sakit; hanya manusia yang merasakannya, dan agen memungkinkan perubahan pada area sistem serta codebase yang sebelumnya membutuhkan bantuan orang lain
• Proyek vibe coding yang membesar menjadi codebase seperti Menara Babel bukan karena tidak bisa berkomunikasi, melainkan karena komunikasi menjadi tidak diperlukan
  • Setiap pengembang memiliki penerjemah tak kenal lelah yang menjelaskan area tertentu dari menara dan melakukan perubahan lokal yang diinginkan
  • Perubahan terus diterapkan, tetapi bahasa arsitektur yang dulu membuat manusia menalar sistem bersama-sama dapat menghilang
• Dalam Menara Babel di Alkitab, hilangnya bahasa bersama menghentikan pembangunan, tetapi dalam rekayasa berbantuan AI, pembangunan dapat terus berlanjut bahkan setelah pemahaman bersama runtuh
• Karena menara tidak runtuh dan tidak terjadi kegagalan langsung, sulit menyadari apa yang telah hilang, dan menara terus menjulang

[GN⁺]

Komentar Hacker News

• Sudah lama saya berpikir bahwa komposabilitas perangkat lunak seharusnya seperti Tetris, di mana baris-baris perlu dihapus. Penggunaan agen yang belum matang atau engineer yang kurang berpengalaman cenderung melewatkan perapian seperti ini dan hanya terus meninggikan menara
  Memang mungkin membuat agen berulang kali mengintegrasikan elemen yang ada ke dalam abstraksi yang lebih baik, tetapi bahkan Fable atau Sol 5.6 pun masih jauh tertinggal dari manusia dalam naluri arsitektur tingkat tinggi untuk memprediksi evolusi halus perangkat lunak. Sistem saat ini tampaknya belum mampu mempertahankan model dunia berkualitas tinggi yang langka dan bisa diperbesar-diperkecil sebagaimana dilakukan manusia, tetapi fakta bahwa kesenjangannya kini telah menyempit hingga ke tingkat yang begitu halus itu sendiri memberi harapan

  • Saya tidak bisa membuktikannya, tetapi saya sangat yakin bahwa logika dan intuisi yang dibutuhkan untuk abstraksi dengan mempertimbangkan perubahan di masa depan tidak bisa diwujudkan hanya dengan rangkaian token prediktif. Ada sesuatu yang tak terukur yang masih hilang
  • Dulu batas atas kompleksitas program adalah kapasitas mental manusia, tetapi vibe coding bisa menembus batas itu. Bukan karena masalahnya benar-benar sekompleks itu, melainkan karena proses pengembangannya tidak mengerucut menuju abstraksi yang ringkas
    Ini adalah versi AI dari masalah penskalaan yang dibahas Brooks dalam 《The Mythical Man-Month》, di mana ledakan kombinatorial makin parah seiring skala membesar dan kode yang pada dasarnya mengimplementasikan fungsi yang sama muncul berulang di berbagai bagian proyek. Diperlukan cara untuk membuat coding berbasis AI mengejar keringkasan
  • Context window manusia mungkin jauh lebih kecil daripada LLM masa kini. Batasan ini justru punya kelebihan karena memaksa pekerjaan dimodularisasi dan diabstraksikan agar bisa ditampung dalam pikiran, sedangkan LLM yang dapat memuat jauh lebih banyak hal sekaligus tidak memiliki insentif yang sama, sehingga agen cenderung menghasilkan spaghetti code yang tidak rapi
  • Pada akhirnya ini hanya soal waktu. gpt2 atau llama2, jika dibandingkan dengan model masa kini, terasa mengejutkan buruknya dan pada masa itu pun sebenarnya nyaris tak berguna, tetapi kita tetap terkesan
    GPT3.5 dan gpt4 yang dulu begitu dielu-elukan pun kini tertinggal jauh dari qwen27b atau gemma31b. Dengan waktu yang cukup dan reinforcement learning (RL) yang tepat, model juga akan mampu membangun model mental yang unggul tentang sistem perangkat lunak
  • Mungkinkah ini hasil dari LLM yang dilatih dengan reinforcement learning untuk menyelesaikan tugas dengan rentang waktu pendek? Tidak seperti tugas lulus tes, upaya bertahun-tahun, arsitektur yang rapi, dan sense yang baik tidak mudah dimaksimalkan lewat benchmark

• Gagasan utama tulisan ini mengingatkan pada Lisp Curse dan Bipolar Lisp Programmer. Argumennya adalah bahwa Lisp membuat individu terlalu mudah membuat apa yang mereka inginkan, sehingga motivasi programmer untuk berkolaborasi membangun hasil yang umum dan kompleks menjadi lemah, dan ekosistem perangkat lunak terbukanya pun menjadi miskin dibanding bahasa yang menuntut usaha besar
  Armin tampaknya mengajukan argumen yang sangat mirip tentang AI coding: Lisp Curse, Bipolar Lisp Programmer

  • Programmer assembly juga pernah mengajukan argumen yang sama. Ini adalah anggapan yang terus berulang setiap kali rekayasa perangkat lunak mengalami pergeseran paradigma, dan selalu ada orang yang lebih sulit beradaptasi terhadap pergeseran itu daripada yang lain
  • Saya ragu ini benar-benar argumen yang sama. Sekarang cukup banyak orang yang berpikir bahwa tanpa perlu berkumpul dan berkolaborasi pun, kita bisa membuat perangkat lunak serumit apa pun yang dibayangkan hanya dengan mengerahkan kawanan agen
  • Justru, jika TypeScript dan Rust tidak sampai menyapu pasar, sekarang mungkin akan menjadi masa yang bagus untuk menjadi pawang LLM untuk Lisp. Agen masa kini dapat menjelaskan hampir semuanya nyaris tanpa halusinasi, jadi jika ada kemauan untuk memahami, hambatan pemahaman pada dasarnya sudah hilang, dan itulah inti tulisan ini
  • Premis bahwa bahasa lain memerlukan “usaha yang jauh lebih besar” untuk mencapai hasil yang sama tidaklah jelas. Banyak pengembang non-Lisp sangat mementingkan sintaks, sedangkan pengembang Lisp tidak, dan bahkan setelah mengalami perluasan cara berpikir lewat Lisp, banyak orang tetap tidak menyukai Lisp
    Mungkin ada cara pemrosesan kognitif yang berbeda di antara kedua kelompok itu. Agar Lisp bisa seproduktif bahasa lain, homoiconicity harus dimanfaatkan secara aktif, tetapi akibatnya program Lisp yang serius mudah berubah menjadi kumpulan domain-specific language (DSL) yang hanya dipahami oleh satu atau dua orang

• Batas proyek perangkat lunak berskala besar bukan pada seberapa cepat individu dapat menghasilkan kode, melainkan pada seberapa baik orang-orang yang mengubah sistem itu menyelaraskan pemahaman bersama tentang sistem tersebut. Pernyataan bahwa segalanya menjadi lebih rumit sejak 30 November 2022 memang tepat

  • Perangkat lunak menjadi terlalu rumit dengan menumpuk lapisan di atas lapisan, dan untuk menanganinya kita memakai alat yang menciptakan jauh lebih banyak kerumitan lagi. Pada 1990-an dan awal 2000-an, bahkan tanpa pendidikan formal orang bisa membuat aplikasi yang kuat dengan Visual Basic atau PHP, tetapi sekarang pengembangan web maupun desktop sudah sangat rumit, dan bahkan untuk memakai React dengan benar pun ada terlalu banyak hal yang harus diketahui
    Menambahkan AI ke dalamnya nyaris merupakan kesalahan dengan menumpuk kerumitan lain di atas kerumitan yang sudah ada. Dalam sudut pandang terbaik, ini pemborosan perangkat keras yang sangat besar; dalam sudut pandang terburuk, agen memperbaiki bug sebanyak mereka menciptakan bug baru, perangkat lunak rapuh yang buruk makin bertambah, dan pada saat yang sama orang tidak belajar keterampilan sehingga kapasitas umat manusia secara keseluruhan bisa melemah. Perangkat lunak pada dasarnya tidak perlu serumit ini, dan untuk mengatasinya kita harus menghargai keahlian craftsmanship
  • Fakta bahwa sistem harus dipahami sebelum diubah bukanlah hal baru. Programming as Theory Building karya Peter Naur sudah terbit pada 1980-an, dan bahkan tanpa membacanya pun, di antara pengembang berpengalaman sudah menjadi pengetahuan umum bahwa pemahaman sistem itu esensial
  • Tidak semuanya menjadi lebih rumit. Basis data utama kini menyertakan alat high availability yang praktis, microservices sedang surut, dan basis data terstruktur kembali hadir menggantikan NoSQL
    HTML dan prerendering juga kembali bersama HTMx dan LiveView, dan CSS pun keluar dari berbagai solusi akal-akalan aneh di masa lalu. Jika Anda menjelaskan kepada rekan muda cara men-debug halaman web di IE6, terasa benar-benar beda zaman. Sebagian hal memang makin rumit, tetapi sebagian lain sudah cukup matang sehingga menjadi lebih sederhana
  • Bukan “sejak 30 November 2022”, melainkan harus dibilang bahwa segalanya menjadi lebih rumit sejak 2022 SM. Peningkatan kompleksitas pada dasarnya adalah sejarah peradaban manusia
    Manusia pada 20.000 SM mencari makanan dan menghindari dingin serta predator, tetapi manusia pada 5.000 SM bertani, mengkhawatirkan hujan dan penyakit, serta menciptakan sistem untuk mengelola komunitas dan tanah. Kebanyakan orang hari ini tidak menanam makanannya sendiri, melainkan mengelola kompleksitas masyarakat raksasa. Bagi pengembang tahun 1970-an dan 1980-an, bahkan perangkat lunak sebelum LLM pun sudah tampak sangat rumit, dan kini hampir tak ada lagi yang menulis kode langsung ke perangkat keras tanpa lapisan abstraksi. Dalam kriptografi juga, library menyembunyikan kompleksitas dan mengajarkan “jangan mengimplementasikannya sendiri”. Jadi pertanyaan intinya sekarang adalah seberapa cepat LLM dapat menyelaraskan pemahaman tentang sistem yang akan diubah

• Bahasa bersama dalam proyek perangkat lunak bukanlah bahasa Inggris ataupun Python, melainkan pemahaman bersama tentang makna konsep, batas-batas, invariant, kepemilikan, dan alasan mengapa sistem memiliki bentuknya yang sekarang. Pattern Language karya Christopher Alexander membahas tepat persoalan ini, dan anjurannya untuk membuat pattern language yang sesuai dengan tiap domain kemudian mengarah pada GoF Design Patterns yang terkenal
  Sedang diuji fitur yang membuat AI memelihara tiga pattern language per proyek untuk domain bisnis, produk, dan teknis, dan hasilnya bekerja sangat baik. Dengan merujuknya saat perencanaan serta merapikannya selama implementasi dan review, bahkan proyek yang dikodekan 100% oleh AI menjadi sistematis, selaras dengan baik antar-domain, dan lebih mudah ditangani

  • Saya penasaran dengan contoh nyata. Saya sudah beberapa kali mendengar bahwa proses pematangan kode mirip pertumbuhan alami kota, tetapi belum pernah melihat hasil yang konkret
  • Saya ingin tahu apakah ada contoh GitHub yang dipublikasikan

• Dalam Menara Babel, pembangunan berhenti ketika bahasa bersama hilang, tetapi dalam pengembangan berbantuan AI, pembangunan tetap berlanjut bahkan setelah pemahaman bersama runtuh. Penulis tidak secara eksplisit menyebut ini baik atau buruk, tetapi jelas memandangnya sebagai hal yang buruk
  Jika mengetahui bahwa tomat adalah buah itu kecerdasan, dan tidak memasukkannya ke salad buah itu kebijaksanaan, maka AI adalah bentuk pamungkas dari kecerdasan tanpa kebijaksanaan sama sekali, dan pada dasarnya mendekati ilusi kecerdasan. Jika tidak ada seorang pun yang memahami apa yang dilakukan AI, kita harus berhenti dan mengakui bahwa kita kekurangan kebijaksanaan untuk mengendalikan apa yang kita buat

  • Saya suka bahwa alih-alih berkhotbah, penulis membiarkan gambar itu sendiri menyampaikan makna. Sejarah tidak pernah berulang dengan persis sama, tetapi ritmenya selalu mirip
  • Klise kekanak-kanakan seperti “mengetahui bahwa tomat adalah buah itu kecerdasan” sebaiknya dihindari kecuali memang bertujuan menyesatkan. Hanya memahami klasifikasi dan hubungan ketergantungan saja sudah merupakan masalah yang cukup sulit, dan dalam konteks supermarket atau standar perpajakan Nix v. Hedden, tomat adalah sayuran

• Saya juga teringat Babel dan lukisan Bruegel, tetapi saya melihatnya jauh lebih pesimistis. Agen-agen kecil yang picik masing-masing mengembangkan wilayahnya dalam suatu keseluruhan yang begitu besar hingga mustahil dipahami, dengan 50 benteng dinding di satu sisi, menara batu menonjol yang ganjil di sisi lain, lalu di atas halaman dibangun atap adobe tanpa alasan yang jelas, dan di bordes sebelahnya berdiri menara beratap jerami
  Pada tingkat desain individual semuanya mungkin masuk akal, tetapi tanpa kebijakan dan pertimbangan di berbagai lapisan yang menyatukan keseluruhan usaha, jadilah monster desain raksasa. Fakta bahwa dibutuhkan disiplin untuk membangun dan memelihara bahasa bersama dalam organisasi yang cukup besar juga tampak dari istilah khas di perusahaan sukses maupun militer. “Gastown Mayors”, lalu “polecats” di bawahnya, dan bahkan golem di bawah itu semuanya mengira mereka memakai bahasa yang sama, tetapi setelah semuanya selesai barulah akan disadari bahwa pemahaman yang diyakini telah tersampaikan sempurna dari singgasana ternyata sebenarnya tidak dibagikan

• Anakin: “Pengembang yang memakai agen akan sangat meningkat kemampuannya untuk mengubah codebase”
  Padmé: “Ke arah yang lebih baik, kan?”
  Anakin: hening
  Padmé: “Ke arah yang lebih baik, kan?”

• Mungkin alasan vibe coding menyuruh orang agar tidak membaca kode yang dihasilkan adalah karena sekali melihat kengerian yang mengintai di dalam file Python, itu tak akan bisa dilupakan. Dalam arti luas, kode itu memang bekerja sesuai yang diminta, tetapi setiap kali harus memilih cara mencapai tujuan, ia mengambil keputusan yang tidak konsisten
  Ia hanya menerapkan validasi aneh pada sebagian input pengguna, berulang kali menyortir data atau mengubahnya menjadi huruf kecil dalam tiga tahap tanpa alasan, dan bahkan men-hardcode semua nama kolom dari baris pertama CSV input sebagai string. Separuhnya membuat fungsi global yang menerima data class, separuh lainnya diimplementasikan sebagai class. Ketika membayangkan bahwa suatu hari Anda sendiri harus memperbarui dan merawatnya, sulit untuk tidak memperbaikinya, tetapi saat mulai mengubahnya, sebagian besar waktu yang dihemat pun menguap

• Pemrograman berbasis agen jauh lebih mirip pekerjaan manajerial daripada pemrograman yang sesungguhnya. Manajer hanya memahami pekerjaan para kontributor individual pada level tinggi, dan sering kali tidak punya waktu, kapasitas kognitif, atau kemampuan untuk memahami semua detailnya
  Semakin banyak perangkat lunak ditulis oleh agen, peran software engineer akan makin mendekati jabatan manajerial daripada jabatan teknis

  • Hal yang sama berlaku untuk programmer. Sebagian besar kontributor individual tidak tahu apa yang terjadi di bawah lapisan tempat mereka bekerja, dan tidak memahami implementasi internal library, framework, API jarak jauh, maupun system call
    Karena tidak punya waktu dan kapasitas untuk memahami semuanya, mereka hanya melakukan pekerjaan yang diperlukan di lapisan abstraksi mereka sendiri
  • Rasanya seperti meninjau kode developer junior sepanjang hari, jadi hampir tidak pernah kupakai, dan terutama hanya kugunakan untuk mencari hal-hal yang mungkin kulewatkan

• Dulu, refactoring skala besar membutuhkan upaya besar sehingga perlu alasan yang cukup kuat. Sekarang, jika prompt sedikit saja ambigu dan hasilnya tidak ditinjau dengan benar, agen bisa menulis ulang setengah dari kode, sehingga jiwa program bisa berubah drastis setiap hari. Ini hal yang luar biasa, sekaligus sama sekali tidak luar biasa

  • Hambatan terbesar dalam refactoring skala besar bukanlah beban kerja aslinya, melainkan meminimalkan risiko bug, menjaga fungsionalitas, dan memastikan kompatibilitas dengan ekosistem yang ada. Alasan ini menjadi lebih mudah di era AI adalah karena kita tidak lagi terlalu peduli pada hal-hal tersebut