GDD - Era "pengembangan yang digerakkan gaslighting"

• Belakangan ini, pengguna komputer berulang kali melakukan banyak tugas tak bermakna terlepas dari keinginan mereka sendiri, dan mengikuti apa yang diperintahkan komputer
• LLM memengaruhi cara pengembang merancang API, dan bahkan muncul prediksi bahwa pengembang menerima fitur yang diusulkan AI dan tak lama lagi sebagian besar kode akan ditulis oleh AI
• Sebagai contoh, Soundslice benar-benar menambahkan fitur yang salah dijelaskan oleh ChatGPT
• Ini karena LLM menganalisis banyak API dan mengusulkan desain intuitif yang kemungkinan paling dulu terpikirkan oleh pengembang
• Saat mengembangkan ide baru atau pendekatan yang unik, LLM tidak cocok, tetapi dalam kebanyakan kasus, mengikuti desain yang paling wajar bisa jadi efektif
• Kini kita memasuki era ketika AI memimpin bukan hanya penggunaan alat, tetapi juga cara alat itu dirancang

---

Gaslight-driven development

Tugas tak bermakna yang menjadi keseharian

• Siapa pun yang menggunakan komputer selama 10 tahun terakhir telah berulang kali melakukan tugas yang pada dasarnya tidak perlu seperti mendaftar akun, verifikasi email, menyetujui cookie, dan mengisi CAPTCHA
• Pengguna harus mengikuti apa yang diperintahkan komputer, meskipun itu bukan yang mereka inginkan
• Melalui tugas-tugas berulang ini, kita sudah sampai pada titik tertentu terbiasa menjalani hidup dengan mengikuti perintah mesin

Realitas pengembangan yang diubah oleh LLM

• Belakangan ini, LLM mulai menyampaikan pendapat tentang seperti apa API atau antarmuka seharusnya dibuat
  • Bahkan muncul prediksi bahwa pada September 2025, 90% dari seluruh kode akan ditulis oleh AI
• Seperti pada kasus Soundslice, ChatGPT keliru mengira ada fitur yang sebenarnya tidak ada sehingga permintaan pelanggan terus berdatangan, dan akhirnya fitur tersebut benar-benar ditambahkan
• Kasus serupa juga terjadi di Instant; sebelumnya tx.update digunakan untuk menangani insert dan update sekaligus, tetapi karena LLM terus menghasilkan kode yang memakai tx.create, mereka akhirnya menambahkan metode tx.create

Makna dari fenomena ini

• Sulit menilai apakah perubahan ini positif atau negatif
• Di sisi lain, karena LLM telah mempelajari sangat banyak API, ia efektif mengusulkan cara yang 'paling intuitif' dari sudut pandang pengembang
• Ini juga merupakan cara baru untuk menguji API dari sudut pandang pemula (newbie’s POV)
  • Dulu, jika pengembang melakukan kesalahan, mereka akan mencari dokumentasi sendiri lalu memperbaikinya; sekarang, karena LLM terus memberikan contoh penggunaan yang salah, pengembang juga bisa lebih cepat menyadari masalahnya

Keterbatasan dan renungan

• Pendekatan ini tidak cocok untuk pekerjaan yang inovatif
  • LLM tidak dapat memahami pola yang belum familier atau konsep yang sepenuhnya baru
• Pada akhirnya, di area seperti API, 'biasa-biasa saja' mungkin justru yang terbaik
  • Dalam kebanyakan situasi, alih-alih merancang sesuatu yang rumit, bentuk yang dapat dipahami secara intuitif baik oleh AI maupun pengembang lebih menguntungkan

Kesimpulan: awal dari era baru

• AI kini tidak lagi sekadar menggunakan alat yang diberikan, tetapi mulai memiliki pendapat tentang bagaimana alat itu sendiri seharusnya dirancang
• Dan pendapat itu sering kali menjadi cara untuk meng-gaslight pengembang dan organisasi seolah-olah "memang sejak awal begitu adanya"
• Ke depan, pengembangan yang disesuaikan dengan ekspektasi dan akal sehat AI kemungkinan besar akan menjadi standar yang terasa alami

[ffdd270]

Kadang saya merasa konsep besar path dependency sedang dipaku kuat oleh ketergantungan pada LLM. Perasaan bahwa kita bergeser dari "karena sudah dipakai sejak dulu" menjadi "karena disukai LLM"—pada akhirnya akan seperti apa, ya...

[kandk]

Yang sudah kami pakai sejak dulu memang dipelajari oleh LLM..

[jujumilk3]

"Sekarang Anda boleh mematikan daya komputer."

[rosen]

Analogi yang sempurna!!

[GN⁺]

Komentar Hacker News

• Dalam situasi ketika LLM merekomendasikan endpoint API yang sebenarnya tidak ada, saya sempat membayangkan bagaimana kalau endpoint itu sekalian diimplementasikan lalu sengaja mengembalikan kode status "421: Misdirected Request", atau memakai '501: Not Implemented' yang memang nyata, dan jika nuansa '501' terasa kurang pas, saya mengusulkan kode status baru, '513: Your Coding Assistant Is Wrong'
  Lihat wiki kode status HTTP
  • Ide "513: Your Coding Assistant Is Wrong" benar-benar lucu, terhibur sekali karenanya, dan di sisi lain saya juga ingin merekomendasikan 'HTTP 407 Hallucination', dengan makna bahwa server memahami permintaannya tetapi menilai itu tidak sesuai dengan kenyataan
  • Cerita ini juga mengingatkan saya pada contoh rambu peringatan lucu yang memberi tahu bahwa GPS salah
    Contoh GPS is wrong
  • Saya memilih mendukung adopsi status 513, sudah ada kode 418 juga, jadi saya rasa tidak ada alasan 513 tidak bisa ada
  • Kalau memang ingin membuat lelucon seperti ini, saya harap pakailah respons 418, saya ingin itu dipakai lebih luas
• Melihat banyak pengguna sedang berada di halaman yang sama secara real-time memang menyenangkan, tetapi penanda pengguna yang terus keluar-masuk membuat saya sangat sulit membaca tulisan
  • Saya punya bookmarklet di bilah bookmark yang menghapus elemen fixed atau sticky seperti ini sekaligus, jadi semua elemen tetap/lengket di halaman hilang dan scroll juga dipulihkan, karena itu saya sering memakainya
    (kode JavaScript disediakan)
  • Saya juga merasa terganggu dengan hal serupa, jadi saya klik kanan, buka developer tools lewat Inspect, lalu tempelkan kode berikut di console agar area penanda pengguna itu hilang

    document.getElementById("presence")?.remove();
    

    Jika penasaran kenapa otak begitu sensitif bereaksi terhadap gerakan ini, itu berkaitan dengan naluri mendeteksi predator
    Tautan paper ilmiah, Lihat wiki neurosains
  • Saya jadi teringat game Chess Royale, saya pernah mendapat pengalaman serupa dengan avatar dan bendera, dan meskipun itu game yang benar-benar bagus, Ubisoft seperti sering terjadi justru menutup layanannya, sayang sekali karya hebat seperti itu hilang
    Screenshot Chess Royale
  • Bukankah ini halaman yang dulu latar belakangnya penuh kursor? Pada titik ini saya merasa konsep desainnya memang semacam lelucon yang sengaja dibuat mengganggu
  • Saya pernah mencoba menghapus elemen halaman dengan alat seperti uBlock, tetapi situasinya jadi seperti permainan whack-a-mole yang berulang cepat
• Di Instant, fungsi tx.update dibuat menangani insert dan update entitas sekaligus, tetapi LLM terus menulis kode tx.create, jadi akhirnya saya juga membuat fungsi tx.create; saya jadi berpikir mungkin bukan hanya LLM, pengembang sungguhan pun banyak membuang waktu secara sia-sia pada bagian yang membingungkan seperti ini
  • Kalau sejak awal tx.create memang tidak ada, bukankah tidak akan ada orang yang membuang waktu karenanya?
• Jika sebuah fungsi mendukung insert dan update sekaligus, saya rasa nama yang tepat adalah "put", bukan "update", karena "update" bisa menimbulkan salah paham
  • Dalam kasus begitu, sepertinya "upsert" yang tepat
  • Nama "put" menyiratkan menimpa isi yang sudah ada, sedangkan "upsert" berarti mendukung insert/update keduanya
• Hanya karena LLM mengeluarkan teks yang salah, rasanya semesta akan mengalami kematian panas sebelum saya sempat mengubah satu baris kode; gagasan bahwa saya harus mengubah kode karena alasan sekonyol ini terasa lucu sekaligus tidak bisa saya terima
• Saya tidak setuju dengan argumen post ini, dari pendekatannya saja saya sudah mempertanyakan apakah kita benar-benar harus mengikuti keinginan komputer
  Saya juga berpikir pengguna melakukan verifikasi email atau pendaftaran akun bukan karena komputer yang memerintah, melainkan karena itu pilihan desain manusia
  • Menyebut isi seperti itu sebagai sebuah "thesis" terasa sebagai tafsiran yang terlalu murah hati; saya membaca bagian itu lalu langsung menutup halamannya
• Baru-baru ini saya sempat berbincang seru dengan tim tentang prinsip coding di masa depan
  Ke depannya, alih-alih berfokus pada keterbacaan kode, prinsip SOLID, atau kompleksitas, kemungkinan yang lebih penting adalah seberapa baik agentic IDE yang saya pakai dapat mengindeks konteks kode dan seberapa baik model menghasilkan keluaran dari kode tersebut
  Karena kecepatan perubahan kode akan meningkat drastis, maintainability kode justru akan menjadi metrik inti, dan saya memperkirakan akan datang masa ketika keselarasan antara prompt dan kode, serta kegunaan kode yang kebetulan sangat cocok, akan lebih banyak diperhatikan
• Jika ada seseorang yang terus-menerus dengan percaya diri menyebarkan nasihat pengembangan baru—yang sebenarnya palsu—tentang produk yang saya buat, saya jadi bertanya-tanya apakah dari sudut pandang perusahaan mereka akan begitu saja menambahkan fitur khayalan itu lalu menulis blog post yang kebingungan
  • Saya penasaran, kalau saya sekalian bertindak seperti LLM, membuat kesalahan aneh tetapi tetap ngotot dengan percaya diri, apakah orang-orang juga akan memakluminya
  • Sebenarnya, bukankah penulis “Clean Code”, Mr Martin, juga bergaya seperti ini?
  • Jika orang itu memengaruhi 90% pelanggan saya, mungkin saya benar-benar akan mengadopsi fitur khayalan tersebut
  • Kebanyakan perusahaan tampaknya justru akan dengan yakin menyatakan bahwa fitur tak perlu itu memang mutlak dibutuhkan
• Ini juga terasa seperti titik awal persahabatan yang indah dengan LLM; sebagai fractional CTO, hal yang paling membuat frustrasi bagi saya adalah tiap klien punya naming convention kecil seperti nama environment yang semuanya berbeda-beda
  Misalnya di ranah AWS ada “dev” dan “prod”, sementara di Expo ada “test” dan “production”, sehingga ketika berpindah-pindah proyek, ternyata butuh cukup banyak beban pikir
  Saya rasa LLM juga mengalami masalah seperti ini dalam skala yang jauh lebih besar
  Menurut saya, yang terbaik adalah jika sinapsis otak yang selama ini terpakai untuk kebingungan penamaan/perilaku API yang tidak perlu seperti ini bisa dialihkan ke hal yang benar-benar bermakna
  • Ada lelucon bahwa dalam ilmu komputer ada tiga masalah sulit—cache invalidation, penamaan, dan error off-by-one
    Sebagus apa pun LLM memberi nama, karena ia berbasis pada incoherent stochastic process, masalahnya akan tetap ada
    Dan saya ingin bertanya apakah Anda pernah sungguh-sungguh mempertanyakan kenapa penamaan environment tidak diseragamkan
    Sebagai mantan CTO, saya menganggap hal seperti ini adalah sinyal bahwa komunikasi dalam organisasi, standar, dan hal-hal serupa perlu diperbaiki
    Karena bagian seperti ini cukup mudah diperbaiki dan bahkan bisa meningkatkan budaya nyata serta kesadaran anggota tim, saya ingin mengatakan bahwa ini bukan sesuatu yang sebaiknya diserahkan ke LLM, melainkan ditangani lebih langsung
• Sebagai tautan terkait
  Lihat diskusi Hacker News sebelumnya

[dkmin]

Kesuksesan viral Soundslice