2 poin oleh GN⁺ 2025-04-04 | 1 komentar | Bagikan ke WhatsApp
  • Pandangan yang menyalahkan simbol formal atas sulitnya pemrograman melahirkan harapan keliru bahwa beban manusia akan berkurang jika mesin memahami bahasa alami
  • Risiko bahasa mesin awal sebagian telah dikurangi oleh bahasa pemrograman tingkat tinggi, tetapi esensinya tetap sama: jawaban yang salah hanya berubah menjadi pesan kesalahan, sementara instruksi yang presisi tetap diperlukan
  • Antarmuka bahasa alami bukanlah solusi pembagian kerja, melainkan dapat memperbesar biaya kerja sama dan komunikasi antara manusia dan mesin sehingga menambah beban di kedua sisi
  • Perkembangan matematika menunjukkan bahwa sistem simbol formal yang dibangun oleh tokoh seperti Vieta, Descartes, Leibniz, dan Boole merupakan alat kunci untuk menangani pemikiran yang kompleks
  • Jika pemrograman bahasa alami dijadikan input/output dasar, ilmu komputer kemungkinan besar pada akhirnya hanya akan menjadi jalan memutar yang panjang untuk kembali ke sistem formal yang dapat digunakan

Harapan dan Salah Kaprah terhadap Pemrograman Bahasa Alami

  • Sejak awal komputasi otomatis, sebagian orang menganggap sebagai cacat bahwa pemrograman menuntut perhatian dan ketepatan yang dibutuhkan oleh simbol formal
    • Mereka mempersoalkan fakta bahwa mesin menjalankan perintah yang salah dengan kaku, dan berharap pada mesin yang lebih “bijaksana” yang menolak kesalahan administratif sepele
  • Bahasa mesin hampir tidak memiliki redundansi, sehingga menjadi antarmuka yang berbahaya antara manusia dan mesin
    • Untuk menanggapi hal ini, bahasa pemrograman tingkat tinggi dikembangkan
    • Seiring waktu, banyak kesalahan kecil diperbaiki sehingga menghasilkan pesan kesalahan alih-alih jawaban yang salah
    • Namun, mesin abstrak yang sesuai dengan bahasa pemrograman tetaplah automaton yang setia menjalankan perintah yang diberikan, dan masih dapat mengeksekusi perintah yang tidak bermakna
  • Usulan untuk memberi instruksi kepada mesin dengan bahasa alami bertumpu pada logika bahwa beban manusia bisa dikurangi meskipun mesin dibuat lebih kompleks
    • Logika ini hanya tampak masuk akal bila “kewajiban menggunakan simbol formal” dianggap sebagai penyebab kesulitan
    • Mengubah antarmuka bukan sekadar membagi kerja, tetapi juga menambahkan biaya kerja sama dan komunikasi yang melintasi antarmuka itu
    • Secara empiris, perubahan antarmuka dapat sangat meningkatkan jumlah pekerjaan di kedua sisi, sehingga muncul preferensi terhadap “antarmuka yang sempit”

Cara Simbol Formal Memperluas Pemikiran

  • Dalam sejarah matematika, pendekatan yang berpusat pada bahasa alami dan gambar berulang kali menunjukkan keterbatasannya
    • Matematika Yunani tetap terhenti karena bertahan pada aktivitas yang bersifat verbal dan visual
    • “algebra” Moslem sempat mencoba penggunaan simbol, lalu kembali ke cara retoris dan menghilang
    • Eropa Barat keluar dari upaya presisi linguistik ala skolastik abad pertengahan berkat simbol formal yang dirancang secara sadar oleh tokoh seperti Vieta, Descartes, Leibniz, dan kemudian Boole
  • Keunggulan teks formal terletak pada kenyataan bahwa manipulasi yang sah hanya perlu memenuhi beberapa aturan sederhana
    • Keteraturan ini menjadi alat untuk menyingkirkan berbagai jenis ketakbermaknaan yang sulit dihindari dalam bahasa alami
  • Penggunaan simbol formal bukan beban, melainkan nyaris sebuah keistimewaan
    • Berkat simbol formal, hal-hal yang dahulu hanya bisa dilakukan oleh para jenius kini dapat dipelajari oleh para siswa
    • Kalimat dalam kata pengantar sebuah laporan teknis tahun 1977, “demi kejelasan kami bahkan menghindari simbol standar untuk penghubung logis”, menunjukkan bahwa kesalahpahaman ini tidak terbatas pada satu orang saja
  • “Kealamian” bahasa alami justru membuat orang mudah menyusun kalimat yang ketakbermaknaannya tidak tampak jelas

Ilmu Komputer di Dunia yang Hanya Mengizinkan Bahasa Alami

  • Jika sejak awal input/output peralatan pemrosesan informasi hanya dilakukan dalam bahasa ibu, maka ilmu komputer kemungkinan akan lebih menyerupai “black art” untuk berpindah menuju sistem formal yang cukup terdefinisi
    • Untuk mempersempit antarmuka ke tingkat yang dapat dipakai, kecerdasan seluruh dunia mungkin akan dibutuhkan
    • Jika melihat sejarah umat manusia, bisa saja itu memakan waktu ribuan tahun lagi
  • Ada pula kekhawatiran bahwa arus pendidikan di Barat menjauh dari pelatihan intelektual, sehingga kemampuan orang dalam menangani bahasanya sendiri merosot tajam
    • Sebagai contoh, disebutkan bahwa dalam makalah ilmiah, laporan teknis, publikasi pemerintah, dan sejenisnya pun terdapat banyak ujaran yang tak bermakna bila dibaca dengan cermat
    • Fenomena ini disebut “The New Illiteracy”, dan juga menjadi peringatan bagi para pendukung yang tidak memiliki wawasan teknis untuk memperkirakan kegagalan pemrograman bahasa alami
  • Penutupnya menyatakan kecurigaan bahwa mesin yang diprogram dengan bahasa alami akan sama sulitnya untuk digunakan seperti halnya untuk dibuat, entah itu memakai Dutch, English, American, French, German, atau Swahili

1 komentar

 
GN⁺ 2025-04-04
Komentar Hacker News
  • Membela LLM di sini memang bagus, tetapi bagaimana kalau kita coba sebaliknya? Ambil proyek dengan kompleksitas menengah, lalu gunakan LLM favorit untuk mengubah kodenya kembali menjadi bahasa alami
    Apakah ia bisa menjelaskan perilaku dan kebutuhan yang ada di source code secara masuk akal, tanpa kehilangan detail yang cukup untuk mereproduksi programnya? Apakah penjelasan bahasa alami itu lebih mudah untuk dinalar?
    Menurut saya ada alasan mengapa aplikasi vibe coding yang ditunjukkan orang-orang umumnya sederhana. Ada tingkat kompleksitas dan presisi yang sulit dikelola, dan meski bisa didefinisikan dalam bahasa Inggris biasa, saya ragu apakah penjelasan itu lebih deskriptif daripada bahasa yang skalabel, dapat dipahami, dan presisi
    Saya juga berpikir alasan dokumen hukum tidak ditulis dalam bahasa Inggris biasa lebih dari sekadar menciptakan hambatan masuk

    • Sebagai contoh dari bidang lain, prakiraan dan pemberitahuan cuaca penerbangan didistribusikan dalam format yang sangat disingkat dan dikodekan. Misalnya cuaca Sydney, Australia saat ini ditulis seperti METAR YSSY 031000Z 08005KT CAVOK 22/13 Q1012 RMK RF00.0/000.0
      Hampir tanpa pengecualian, pilot baru bertanya, “kenapa tidak ditulis dengan kata-kata saja?”, dan memang sebagian besar aplikasi perencanaan penerbangan mengubah kode ini menjadi prosa
      Namun pilot profesional atau pengendali lalu lintas udara jauh lebih menyukai format kode. Karena hanya satu baris, formatnya padat, terdefinisi dengan baik sehingga mereka tahu persis di mana mencari item yang dibutuhkan, serta tidak ambigu dan jelas
      Matematika dan coding juga sama: setelah mencapai tingkat kemahiran tertentu, kompleksitas dan redundansi bahasa alami biayanya menjadi lebih besar daripada manfaatnya. Tampaknya ini berlaku di semua bidang profesional
    • Menurut saya ini lebih dekat ke masalah working memory daripada presisi. Alasan manusia sulit memahami versi prosa yang cukup besar mungkin mirip dengan alasan LLM sulit menangani versi prosa yang besar: kapasitas working memory terbatas
      Mengambil kembali informasi dari prosa memakan banyak waktu, dan orang yang membaca teks panjang mulai menggarisbawahi, membuat catatan, serta menciptakan singkatan mereka sendiri
      Format yang dipadatkan dan abstraksi mengurangi beban working memory dan pencarian informasi. Jadi mungkin ini bukan semata-mata masalah presisi bahasa
    • Bahasa dapat memuat konteks dalam jumlah sangat besar. Misalnya kalimat “saya ingin aplikasi navigasi modern untuk mengemudi, dan saya ingin bisa memilih persimpangan yang sama sekali tidak ingin saya lewati” kompleksitasnya rendah, tetapi mengodekan informasi yang sangat banyak
      Anda mungkin berpikir untuk sampai dari kalimat itu ke aplikasi yang benar-benar berfungsi diperlukan banyak sekali detail implementasi, tetapi dengan informasi sebanyak itu saja ada kemungkinan mencapai aplikasi berjalan yang memenuhi kebutuhan saya
      Dan jika itu sudah cukup untuk membuatnya, permintaan seperti “bisakah itu diubah menjadi cornflower blue?” juga menjadi mudah, lalu pengguna bisa melakukan perbaikan iteratif dari sana
    • Tentu saja kita membuat abstraksi yang bocor, dan itu juga terjadi dalam dokumen hukum
      Jika hanya diberi ISA dan driver display lalu LLM diminta membuat aplikasi grafis dalam assembly, kita tidak akan mendapatkan apa-apa
      Namun jika abstraksinya bertumpuk sangat banyak, mungkin itu menjadi mungkin
      Saya bukan sedang membela LLM; maksud saya, jika kita menyediakan abstraksi yang tepat dan komponen yang dapat digunakan ulang, kita bisa jauh lebih mendekati tujuan itu
    • Ada alasan mengapa dokumen hukum tidak memakai bahasa Inggris biasa. Sebagian presisi dalam redaksi hukum berasal dari fakta bahwa makna istilah tertentu sudah didefinisikan lebih tepat oleh preseden pengadilan
  • Saya teringat kutipan lama Hal Abelson
    “Di balik pendekatan kami terhadap subjek ini terdapat keyakinan bahwa ‘ilmu komputer’ bukanlah sains, dan signifikansinya hampir tidak ada hubungannya dengan komputer. Revolusi komputer adalah revolusi dalam cara kita berpikir dan cara kita mengekspresikan pikiran. Esensi perubahan ini adalah munculnya sesuatu yang paling tepat disebut epistemologi prosedural. Ini adalah studi tentang struktur pengetahuan dari sudut pandang imperatif, berbeda dengan sudut pandang yang lebih deklaratif yang diambil oleh bidang matematika klasik. Matematika menyediakan kerangka kerja untuk menangani secara presisi gagasan tentang ‘apa itu’. Komputasi menyediakan kerangka kerja untuk menangani secara presisi gagasan tentang ‘bagaimana melakukannya’.”

    • Intinya adalah komputasi membuat sesuatu terjadi. Coding dengan LLM menambah satu lapisan abstraksi, tetapi tidak menghilangkan kebutuhan akan presisi dan akurasi dari “hal yang terjadi”
      Sebanyak apa pun demo keren dan deklarasi “coding sudah mati karena AI”, sebagian besar pekerjaan nyata bergeser ke preprocessing, postprocessing, dan evaluasi di sekitar AI
      Itu bagus dalam hal meningkatkan aksesibilitas pemrograman, tetapi tidak benar-benar bisa menggantikan pemrograman
    • Apa yang diajarkan dalam program ilmu komputer sekarang jelas sepertinya tidak mengarah ke sana
    • Hal Abelson dengan santai membuat para ilmuwan komputer functional programming di seluruh dunia naik pitam
  • Akhirnya ada yang mengungkapkannya seperti ini. Bahasa alami memiliki batasan bawaan yang berasal dari keterbatasan mental manusia. Pikiran manusia kadang berpikir terlalu abstrak atau terlalu konkret, dan melewatkan detail penting atau generalisasi penting
    Dari pengalaman langsung sebagai programmer, masalah atau bahkan kejanggalan dalam suatu tugas sering kali baru tampak setelah mulai mengimplementasikannya sebagai kode, yaitu dalam sistem simbol yang ketat
    Selain itu, sering kali waktu yang dibutuhkan untuk menjelaskan sesuatu secara akurat dalam bahasa alami lebih lama daripada sekadar menulis algoritmanya dalam kode

    • Benar. Saya cenderung menyukai abstraksi, sehingga memahami sesuatu secara abstrak, tetapi sering kali sangat sulit mengekspresikannya dalam bahasa alami
    • Kita perlu ekspektasi yang realistis tentang batasan LLM saat ini. Secara filosofis pun, bahasa alami tidak sempurna untuk menyampaikan ide antarmanusia, padahal itulah tujuan utamanya
      Seberapa sering kita menulis ulang kalimat, berkata “sebenarnya yang saya maksud...”, atau merumuskan ulang email sebelum mengirimnya? Kita manusia, dan jarang sempurna pada percobaan pertama
      Sekarang kita mengubah bentuk komunikasi yang tidak sempurna ini, yaitu bahasa alami, menjadi kode: bahasa mesin yang terkenal menjalankan apa yang dikatakan, bukan apa yang dimaksud
      Natural language processing sangat berguna untuk memulai pembuatan aplikasi atau skrip ke arah yang benar. Namun pada akhirnya mungkin tetap perlu refactoring di sana-sini
      Anda tidak perlu menjadi jagoan kode untuk mendapatkan nilai dari LLM, tetapi kemampuan coding tetap membantu dan kadang diperlukan
  • /s: Karena kita belum melangkah cukup jauh. Orang-orang membuat program komputer dengan bahasa alami, tetapi seharusnya menjalankan prompt secara langsung
    “Kamu adalah sistem grafis. Kamu adalah entitas yang mengelola apa yang ada di layar. Kamu bisa menerima permintaan dari semua program untuk membuat dan menghapus ‘jendela’, serta permintaan tambahan untuk menggambar teks, garis, lingkaran, dan sebagainya pada jendela yang telah dibuat sebelumnya. Item bisa berwarna apa saja.
    Kamu juga harus mengirimkan lebih banyak informasi klik kepada pihak yang membuat jendela tempat pengguna mengklik mouse.
    Window manager adalah program khusus, dan dapat memberi tahumu jendela mana ditampilkan di mana pada semua monitor yang terhubung ke sistem”
    Lalu “Kamu adalah program tic-tac-toe. Ada sistem grafis yang mengelola apa yang ada di layar. Kamu bisa memerintahkan sistem itu untuk membuat dan menghapus ‘jendela’, dan memintanya menggambar teks, garis, lingkaran, dan sebagainya pada jendela yang telah dibuat sebelumnya. Item bisa berwarna apa saja.
    Grafik yang kamu gambar harus menampilkan permainan tic-tac-toe tempat pengguna mengklik mouse untuk menjalankan giliran. Jika pengguna menang…
    Tambahkan iklan ke game kecuali pengguna berlangganan bayar-per-klik”
    Ini seharusnya sudah cukup agar game berjalan
    Untuk menyimpan, perlu prompt lain. “Kamu adalah sistem berkas. Kamu adalah entitas yang mempersistenkan data ke disk…”
    Dan juga perlu “Kamu adalah sistem operasi multitasking. Kamu memberi beberapa LLM kesan bahwa mereka memiliki kendali penuh atas CPU dan memori sistem. Kamu…”
    Saya menantikan melihat ini pada awal April tahun depan

    • Prompt semacam ini saat ini diimplementasikan secara internal lewat pembuatan dan eksekusi kode Python
  • “Bahasa mesin hampir tidak memiliki redundansi dalam bentuk apa pun, sehingga segera dikenali sebagai antarmuka yang tidak perlu berbahaya antara manusia dan mesin. Sebagai sebagian tanggapan terhadap kesadaran ini, apa yang disebut ‘bahasa pemrograman tingkat tinggi’ dikembangkan, dan seiring waktu kita belajar cara meningkatkan perlindungan terhadap kesalahan bodoh sampai tingkat tertentu. Bahwa kini banyak kesalahan bodoh menghasilkan pesan galat alih-alih jawaban yang salah adalah peningkatan penting.”
    Rasanya kita sebagai kolektif terlalu cepat terjun ke pemrograman dengan LLM. Saya benar-benar menyukai bagaimana Rust berkembang dengan cara yang menunjukkan kesalahan bodoh dan membuat cara memperbaikinya jauh lebih jelas
    Sebagai developer, saya masih memiliki konteks dan pemahaman atas kode yang sedang saya kerjakan, dan compiler memberi tahu galat yang jelas beserta cara memperbaikinya. Sebaliknya, penggunaan LLM terasa seperti permainan tebak-tebakan yang setengah cerdas
    Compiler Rust adalah guru yang mengajar muridnya, sedangkan LLM seperti lulusan yang percaya diri mengoreksi gurunya. Saya jauh lebih menyukai pendekatan Rust dan berharap itu bisa dikembangkan lebih lanjut jika memungkinkan

    • Rust dan sejenisnya punya inferensi tipe, sedangkan LLM punya apa yang disebut “penalaran”. LLM berpura-pura memahami, dan kebohongan itu suatu saat pasti harus dibayar
  • Bahasa alami adalah medium yang buruk untuk menyampaikan aturan dan perintah. Situasi Amerika Serikat saat ini adalah contoh yang baik
    Kita masih memperdebatkan apa arti undang-undang dan pasal-pasal amendemen tertentu. Makna kata berubah seiring waktu, dan konteks historis juga makin berkurang
    Akan menyenangkan jika kita bisa mengoperasikan mesin dengan bahasa alami, tetapi sebagai orang yang sudah memprogram sejak pertengahan 80-an, saya melihat kekakuan bahasa komputer dari BASIC hingga Go menciptakan keseimbangan yang baik. Itu membuat pihak yang memberi perintah memikul tanggung jawab yang cukup untuk mengungkapkan secara tepat apa yang harus dilakukan mesin

  • Saya agak tidak setuju dengan argumen ini. Di perusahaan nyata, ide fitur baru sering kali bermula di kepala seseorang dari sisi bisnis. Orang ini tidak akan berbicara dalam bahasa formal apa pun
    Jadi bagaimanapun juga, untuk mengimplementasikan fitur diperlukan penerjemahan dari bahasa alami ke bahasa mesin
    Biasanya tahap pertama, penerjemahan dari bahasa alami ke bahasa formal, dilakukan oleh analis bisnis dan programmer. Kalau begitu, adakah alasan untuk tidak mencoba mendapat bantuan komputer dalam proses itu?

    • Komputer bisa dan harus membantu dalam proses itu. Namun poin Dijkstra adalah a) sebagian besar kesulitan dalam ide manusia ditemukan dalam tindakan mengubah bahasa alami menjadi bahasa formal, dan b) tindakan itu sendiri melatih diri kita yang berpikir secara logika formal
      Jadi ia tidak hanya membantah gagasan bahwa program harus dispesifikasikan dengan bahasa alami, tetapi juga gagasan bahwa menghilangkan kebutuhan kita untuk memahami bahasa formal akan meningkatkan kemampuan kita membangun sistem yang kompleks
      Banyak “penerjemahan” sebenarnya bukan penerjemahan, melainkan pekerjaan memperbaiki ambiguitas logis, inkonsistensi, dan asumsi yang keliru. Jika menanggapi Dijkstra dengan serius, sebagian besar dari itu bisa dilakukan bahkan di dalam bahasa alami. Karena di tempat itu ada programmer yang sepanjang hidupnya melakukan formalisasi
      Ada juga profesi lain yang membutuhkan banyak pemikiran formal, seperti matematika. Selain itu, saat bukti-bukti lama diubah menjadi bukti komputer, banyak bukti yang diterima luas ternyata ditemukan memiliki lubang dan celah
      Tidak banyak yang sepenuhnya dibalik, tetapi kita bahkan belum memiliki bukti lengkap untuk Teorema Terakhir Fermat https://xenaproject.wordpress.com/2024/12/11/fermats-last-th...
    • Sepertinya Anda belum sepenuhnya memahami poin Dijkstra. Ia tidak mengatakan jangan memakai alat untuk membantu penerjemahan, melainkan bahwa tidak berpikir dengan simbol formal merusak pemikiran
      Jika tidak berpikir dalam sistem formal, ide menjadi lebih buruk. Karena Anda tidak memperlakukan pikiran sendiri sebagai sesuatu yang formal
      Tentang bagaimana menerjemahkan ide “orang bisnis” dalam contoh itu, ia mungkin tidak punya banyak pendapat. Dari sudut pandangnya, ide orang bisnis sudah dangkal dan buruk karena tidak mengikuti formalisme, sehingga tidak layak diterjemahkan
    • Tahap pertama bukan dari bahasa alami ke bahasa formal, melainkan memindahkan ide di kepala ke bahasa alami. Melakukan tahap itu dengan cukup baik agar komputer dapat mengubahnya menjadi sesuatu yang berguna itulah yang sulit
    • Jika begitu, Anda tidak akan tahu apa yang dilakukan komputer. Inti tulisan ini adalah bahwa proses menuliskan ide secara formal itu sendiri memiliki nilai
      Jika “membiarkan komputer membantu di tengah”, Anda akan segera menghadapi masalah bahwa untuk memperoleh hasil yang cukup baik dari mesin, Anda membutuhkan bahasa alami yang semakin formal
    • Bukankah setiap bisnis, setiap aktivitas, memiliki bahasa formalnya sendiri?
      Meski tidak seformal bahasa pemrograman, itu jelas ada
      Ketika mencoba mendefinisikan proses apa pun, sekalipun tidak menyadarinya, pada akhirnya Anda akan condong ke arah formalisasi
  • “Bahwa banyak kesalahan bodoh berujung pada pesan galat, bukan jawaban yang salah, adalah sebuah peningkatan penting. Bahkan peningkatan ini pun tidak disukai semua orang. Sebagian orang menganggap pesan galat yang tidak bisa diabaikan lebih menjengkelkan daripada hasil yang salah, dan ketika menilai keunggulan relatif bahasa pemrograman, mereka tampaknya masih menyamakan ‘kemudahan pemrograman’ dengan mudahnya melakukan kesalahan yang tidak terdeteksi.”
    Kalau tidak tahu siapa yang menulisnya, ini akan terlihat seperti sindiran telak terhadap orang-orang yang membenci Rust

    • Rust? Sejak kapan Rust menjadi puncak keamanan tipe statis?
      Setelah cukup lama memakai Scala, bahasa yang bisa mengekspresikan invariant yang lebih kuat lewat tipe dibanding Rust, saya jadi tidak lagi melihat sifat itu sebagai kemenangan yang jelas dalam situasi apa pun. Saya tidak lagi berpikir “tipe yang lebih kuat == pasti lebih baik”
      “Tidak membiarkan kesalahan” ada harganya. Kalau sistem tipenya benar-benar ketat, pekerjaan eksploratif menjadi cukup sulit. Iterasi cepat bisa saja menjadi mustahil
      Perubahan kecil bisa memaksa kita mendesain ulang separuh program hanya demi kembali memenuhi sistem tipe
      Ini adalah trade-off. Sama seperti hal lain. Bagus untuk produk akhir yang kokoh, tetapi menghambat eksperimen cepat
      Ada yang menjelaskan masalah ini dengan baik dalam konteks Rust dan pengembangan gim: https://loglog.games/blog/leaving-rust-gamedev/
      Namun masalah ini tidak terbatas pada Rust atau pengembangan gim saja
    • Saya rasa ia dengan sungguh-sungguh memikirkan orang-orang yang menyukai PHP era fractal-of-bad-design atau JavaScript ala wat-talk
      Beberapa jenis kebodohan tampaknya tak lekang oleh zaman
    • Sebagai orang yang membenci Rust, masalahnya adalah pesan galat yang muncul padahal tidak ada galat. Sistem tipe Rust tidak memodelkan RAM, CPU, maupun perangkat apa pun secara akurat
      Yang ia bicarakan di sini adalah bahasa interpreter
      Ia juga termasuk salah satu matematikawan yang kini disebut ilmuwan komputer; “algoritmanya” lebih mirip perumusan ulang matematika dan tidak membutuhkan perangkat. Ia adalah orang yang secara temperamen memusuhi aktivitas memalukan berupa memprogram komputer nyata
  • Menspesifikasikan dan membuat aplikasi dengan bahasa alami cukup mirip dengan memiliki dokumen desain gim sebelum mulai membuat prototipe gim
    Namun setelah sebagian besar hal yang diinginkan diimplementasikan, implementasi itulah yang menjadi acuan, dan GDD biasanya dibuang karena sudah tidak selaras dengan gim sebenarnya
    Bersikeras bahwa setiap kali ada perubahan kita harus membaca GDD, mengimplementasikan fitur, lalu menyinkronkan kembali GDD itu merepotkan dan dalam praktiknya tidak berjalan baik. Saya belum pernah melihat hal seperti itu terjadi
    Jika suatu hari AI/LLM bisa menulis kode versi berikutnya dari Linux atau Windows dari nol hanya dengan serangkaian prompt, semua premisnya akan berubah, tetapi saat ini jelas kita belum sampai ke sana dan belum tentu akan sampai

  • Bahasa alami cukup bagus untuk menjelaskan kebutuhan teknis sistem yang kompleks. Artinya, bagus untuk menjelaskan mengapa implementasi saat ini dipilih dibanding kemungkinan implementasi lain, bukan implementasi kode saat ini itu sendiri
    Cocok untuk memuat bukan apa yang dilakukan kode, melainkan apa yang seharusnya dilakukan—dengan kata lain, bagian-bagian yang hilang yang ada di tempat seperti Jira, bukan di repositori
    Selain itu, jika keseluruhan sistem dapat dijelaskan dengan aturan eksternal dan aturan itu dapat ditegakkan di seluruh codebase, hal itu juga bisa memberikan kemampuan refactoring yang lebih baik
    Kita selama ini memakai bahasa pemrograman karena mudah digunakan dalam konteks otomasi dan komputer, dan sejujurnya sebelum LLM itu memang satu-satunya cara
    Bahasa pemrograman memberikan ketidakambiguan pada skala lokal, tetapi begitu seseorang menyalin dan menempel sebagian kode, ia berhenti bekerja pada skala global
    Bisakah kita yakin bagian itu adalah program yang benar sambil tetap mematuhi semua batasan tingkat tinggi yang harus diikutinya? Jika bisa dikompilasi, itu memang program yang berjalan, tetapi definisi “berjalan” cukup longgar. Di C++, program yang merusak seluruh memori pun bisa berjalan