- Dalam lingkungan tempat LLM memproduksi kode dalam jumlah besar, yang melemah bukan hanya masalah pada kode itu sendiri, tetapi juga pemahaman bersama tim dan pencatatan tujuan sistem, sehingga semakin penting untuk menanganinya sebagai tiga lapisan: utang teknis, utang kognitif, dan utang niat
- Technical debt membatasi kemungkinan perubahan di masa depan, Cognitive debt melemahkan kemampuan tim untuk menalar perubahan sistem, dan Intent debt mengaburkan catatan tujuan serta batasan sehingga menghambat evolusi berkelanjutan oleh manusia maupun agen AI
- Teori Tri-System yang menempatkan AI sebagai System 3 membedakan cognitive surrender—ketika penalaran artifisial dari luar dipercaya tanpa kritik sehingga proses berpikir mendalam dilewati—dari cognitive offloading, yaitu pendelegasian kognisi secara strategis
- Semakin murah biaya coding, semakin mahal verification, dan standar akurasi maupun keberhasilan berbeda-beda menurut konteks, seperti ETA lalu lintas, dispatch pengemudi, atau operasi ratusan microservice, sehingga penilaian manusia dan perancangan sistem verifikasi menjadi makin penting
- Poros utama engineering bergeser dari jumlah implementasi ke verifikasi, dan manusia akan terus memegang peran menjaga makna sistem, seperti membuat abstraksi yang berguna, memberi nama, serta merancang acceptance criteria dan test harness
Tiga jenis utang dan kesehatan sistem
- Dalam lingkungan tempat LLM menghasilkan kode dalam jumlah besar, tim mudah kehilangan pemahaman tentang apa yang dilakukan sistem, dan sudut pandang yang melihat ini sebagai Cognitive Debt semakin menguat
- Tiga lapisan kesehatan sistem membagi utang ke dalam dimensi kode, manusia, dan artefak
- Technical debt berada pada kode, menumpuk ketika keputusan implementasi merusak kemungkinan perubahan di masa depan, dan membatasi bagaimana sistem dapat diubah
- Cognitive debt berada pada manusia, menumpuk ketika pemahaman bersama tentang sistem melemah lebih cepat daripada upaya untuk mengisinya kembali, dan membatasi kemampuan tim untuk menalar perubahan
- Intent debt berada pada artefak, menumpuk ketika tujuan dan batasan yang seharusnya mengarahkan sistem tidak dicatat atau dipelihara dengan baik, dan membatasi apakah sistem terus mencerminkan apa yang semula ingin dibuat serta apakah manusia dan agen AI dapat terus mengembangkannya secara efektif
- Sudut pandang ini juga mencakup bagian untuk mendiagnosis dan memitigasi tiap jenis utang, sekaligus membahas bahwa ketiganya saling berinteraksi
- Tim perlu menjalankan aktivitas umum untuk mengendalikan ketiga jenis utang ini
Teori Tri-System dan penyerahan kognitif
- Makalah yang menambahkan LLM ke model berpikir dua sistem Kahneman memperluas kerangka berpikir dengan menempatkan AI sebagai System 3
- System 1 membuat keputusan cepat lewat intuisi, sedangkan System 2 adalah tahap berpikir disengaja untuk memecahkan masalah
- Demi menghemat energi, manusia pada dasarnya cenderung bergantung pada intuisi, dan akibatnya bisa melewatkan hal-hal yang seharusnya akan ditemukan jika dipikirkan lebih dalam
- Sebagai akibat dari System 3, muncul cognitive surrender, yang didefinisikan sebagai keadaan ketika penalaran artifisial yang dihasilkan dari luar dipercaya tanpa kritik sehingga melewati System 2
- Makalah ini membedakannya dari cognitive offloading
- cognitive offloading dipandang sebagai tindakan mendelegasikan kognisi secara strategis dalam proses berpikir
- Makalah ini mengembangkan Tri-System theory of cognition secara rinci dan, setidaknya dalam lingkungan laboratorium, menguji lewat berbagai eksperimen seberapa efektif teori ini dalam memprediksi perilaku
Notasi <> sebagai ikon kode
- Beberapa ilustrasi belakangan ini menggunakan simbol “<>” sebagai ikon kode, tetapi notasi ini terasa asing sebagai penanda yang membungkus elemen bahasa pemrograman
- Alasan “<>” dipakai alih-alih simbol lain seperti “{ }” tampaknya karena ia mengingatkan pada HTML atau XML
- Jika dipakai sampai dalam bentuk “</>”, asosiasinya dengan HTML menjadi lebih langsung, tetapi HTML sendiri tidak diperlakukan sebagai bahasa yang dipakai programmer untuk menulis program
Saat coding menjadi murah, yang mahal adalah verifikasi
- if coding agents make coding free, what becomes the expensive thing berargumen bahwa semakin agen coding menurunkan biaya coding, elemen yang menjadi mahal adalah verification
- Standar akurasi terus berubah menurut konteks
- Algoritme ETA untuk lalu lintas di Jakarta dan algoritme ETA untuk lalu lintas di Ho Chi Minh City bisa memiliki makna “correct” yang berbeda
- Dalam dispatch pengemudi, “successful” tidak memiliki satu definisi tunggal karena harus sekaligus memenuhi keadilan pendapatan, waktu tunggu pelanggan, dan tingkat pemanfaatan kendaraan
- Dalam lingkungan tempat ratusan engineer terus melakukan deployment ke sekitar 900 microservice, “correct” tidak lagi satu definisi melainkan terpecah menjadi ribuan definisi yang semuanya terus berubah dan bergantung pada konteks
- Penilaian seperti ini ditempatkan sebagai pekerjaan yang tidak bisa digantikan agen
- Agen makin efektif terutama dalam alur kerja yang memiliki verifikasi yang baik dan, jika memungkinkan, terotomatisasi untuk hasil pekerjaannya
- Alur seperti ini mendorong Test Driven Development
- Karena volume verifikasi yang tetap harus dilakukan masih besar, dibutuhkan lebih banyak upaya untuk membantu manusia memahami cakupan pengujian yang lebih luas dengan lebih mudah
- Terkait modernisasi legacy, ada juga beberapa pandangan berbeda
- Harapan bahwa agentic coding pada akhirnya akan menyelesaikan modernisasi legacy dinilai terlalu dibesar-besarkan
- Namun, pada aspek memahami apa yang dilakukan kode legacy, ada bukti kuat bahwa LLM sangat membantu
Reorganisasi menuju organisasi yang berpusat pada verifikasi
- Ketika agen menangani eksekusi, pekerjaan manusia bergeser ke perancangan verification system, pendefinisian quality, dan penanganan kasus ambigu yang tidak bisa diselesaikan agen
- Struktur organisasi juga perlu berubah mengikuti pergeseran ini
- Pertanyaan utama dalam stand-up Senin pagi bergeser dari “apa yang telah dideploy” menjadi “apa yang telah diverifikasi”
- Alih-alih melacak volume output, organisasi akan melacak apakah hasilnya benar
- Tim berisi 10 engineer yang sebelumnya membuat fitur bisa direstrukturisasi menjadi 3 engineer dan 7 orang yang menangani pendefinisian acceptance criteria, perancangan test harness, dan pemantauan outcome
- Reorganisasi seperti ini bisa terasa tidak nyaman karena menurunkan status aktivitas membuat dan menaikkan status aktivitas menilai
- Budaya engineering yang tidak menolak perubahan ini kemungkinan akan lebih berhasil
Masa depan source code dan bahasa yang ramah LLM
- Dalam arus yang memperlakukan LLM seperti programmer, masa depan source code sendiri muncul sebagai pertanyaan
- several views of the future of code mengumpulkan berbagai sudut pandang tentang masa depan kode
- Sebagian pihak sedang bereksperimen dengan bahasa yang sepenuhnya baru dan dirancang dengan mempertimbangkan LLM
- Pihak lain melihat bahwa bahasa yang ada saat ini, terutama bahasa bertipe ketat seperti TypeScript dan Rust, mungkin lebih cocok untuk LLM
- Tulisan ini penuh kutipan dan tidak banyak analisis orisinal, tetapi layak dibaca sebagai bahan tinjauan umum atas keseluruhan diskusi
Abstraksi dan penamaan yang tetap menjadi tugas manusia
- Bahkan dalam proses membuat perangkat lunak bersama LLM, manusia akan tetap memegang peran membuat abstraksi yang berguna untuk menjelaskan apa yang dilakukan kode
- Ini terhubung dengan Ubiquitous Language dalam DDD
- growing a language membahas cara menumbuhkan bahasa bersama LLM
- Pemrograman bukan sekadar memasukkan sintaks coding agar komputer dapat memahami dan mengeksekusinya, tetapi juga membentuk solusi
- Kita membagi masalah menjadi bagian-bagian yang terfokus, menggabungkan data dan perilaku yang relevan, serta memilih nama yang mengungkapkan niat
- Nama yang baik membelah kompleksitas dan mengubah kode menjadi skema yang bisa diikuti semua orang, sekaligus menghubungkan struktur masalah dan struktur solusi dengan jelas
1 komentar
Opini Hacker News
Kalau kamu tipe orang yang baru tenang kalau memahami secara mendalam semua yang kamu deploy, perubahan seperti ini terasa cukup menggelisahkan
Sekarang, bahkan proyek modernisasi yang dulu butuh 2 bulan bisa selesai sekitar seminggu kalau fokusnya bukan menggali seluruh logika bisnis lalu menyalinnya apa adanya, melainkan merancang batas dan antarmuka dengan baik
Lalu seperti yang dikatakan di tulisan, cukup buat test harness yang bagus dan verifikasi kesetaraannya semaksimal mungkin
Aku juga awalnya cukup galau, tapi setelah kupikir-pikir, sistem lain yang ku-maintain setiap hari pun sebenarnya tidak terlalu kupahami implementasi internal atau logika bisnisnya sedalam itu
Itu kode yang kutulis beberapa tahun lalu dan hampir tidak kusentuh lagi, jadi saat harus mengubah sesuatu, pada akhirnya aku tetap mengandalkan test suite atau menelusuri struktur kode untuk memahami perilaku tertentu
Bahkan saat ada PHK atau fase penghematan biaya, aku berkali-kali melihat orang yang punya banyak pengetahuan seperti itu bertahan lebih lama dibanding yang tidak
Aku penasaran apa yang kulewatkan
Bukan berarti LLM tidak punya keutamaan kemalasan
Kalau diberi base prompt yang sesuai dengan niat kita, agen berbasis Claude bisa diarahkan cukup baik untuk meminimalkan perubahan kode, menjalankan pass deduplikasi, dan menunjukkan perilaku yang tampak seperti naluri developer yang sangat senior
Menurutku bukan karena modelnya sama sekali tidak pernah mempelajari pengetahuan itu, hanya saja dalam setelan default hal itu tidak tampil di depan
Sepertinya semua orang pernah melihat model dengan gaya over-editing yang mengutak-atik seluruh codebase tanpa peduli pada perubahan orang lain atau risiko hilangnya pengetahuan
Pembahasan soal pembuatan dan verifikasi dokumentasi pada akhirnya juga mirip dengan masalah locking tradisional, dan ada solusi tradisional untuk itu
Agen seharusnya cukup mampu membaca git, memahami mana yang lebih dulu terjadi, dan apakah secara konvensi ia sedang menunggu perubahan lain
Aku juga sudah cukup senior, bahkan pernah benar-benar satu tim dengan beberapa orang yang disebut dalam tulisan ini
Kurasa mereka tidak akan meragukan standar engineering-ku
Namun dalam workflow LLM-ku, hampir tidak terlihat utang semacam itu, malah menurut standar lama pun kualitas proyek terasa lebih baik dibanding 5 atau 10 tahun lalu
Ini bukan sihir, cukup jalankan agen dengan baik yang berbagi prioritas kualitas semacam itu
Dan aku lebih banyak menyelesaikan pekerjaan nyata daripada mencari perhatian di konferensi
Hanya saja bagian bahwa ini lebih baik dibanding 5 atau 10 tahun lalu bahkan menurut metrik kualitas software tradisional terdengar terlalu samar
Aku ingin tahu lebih konkret metrik apa yang dipakai, dan bagaimana perbandingan kode 10 tahun lalu, 5 tahun lalu, dan sekarang
Tanpa penjelasan itu, pesannya malah terasa kabur dan melenceng dari inti
Kalau ada yang bisa dibagikan lebih lanjut, aku cukup penasaran
Rasanya kamu bisa menulis buku berjudul Practical LLM Coding
Menurutku hal yang paling diremehkan di sini adalah framing intent debt
Cognitive debt atau technical debt setidaknya masih meninggalkan jejak di kode, sedangkan intent debt tidak terlihat
Jadi ia baru muncul ketika perubahan yang tampak masuk akal secara lokal ternyata salah secara global
Sebab kendala aslinya tidak tertinggal di artefak mana pun
Kasus tersulit adalah ketika di sistem enterprise kendala itu berupa persyaratan regulasi, lalu diam-diam berubah 3 tahun lalu dan tidak ada seorang pun yang memperbarui kodenya
Test tetap lolos, jadi makin mudah terlewat
Test suite saja tidak bisa memulihkan intent
Aku tidak merasa Martin sepenuhnya salah, tapi logika ini tampaknya adalah argumen yang selalu bisa dibuat setiap kali lapisan abstraksi naik
Menurut definisinya, berpindah dari Assembly ke Python juga akan menciptakan intent debt dan cognitive debt dalam jumlah besar
Karena kita tidak lagi memikirkan sendiri cara memanipulasi bit dan menyerahkannya ke interpreter
Sanggahanku adalah bahwa intent teknis yang dia maksud pada akhirnya muncul karena manusia harus menerjemahkan niatnya ke machine code
Berpikir mendalam tentang masalah itu sendiri tidak harus selalu dilakukan dengan membangun abstraksi domain-driven di dalam kode
Kita bisa berpikir mendalam lewat mind map, jurnal, atau menempelkan Post-it di dinding
Abstraksi object-oriented itu sendiri bukan sihir
Dalam proses itu, ambiguitas, detail yang belum terpikirkan, bahkan fakta bahwa pendekatannya sendiri perlu dipikir ulang sering kali jadi terlihat
Menulis dalam bahasa alami juga bisa menjadi alat berpikir, tetapi ada unsur yang secara esensial berbeda dalam memaksa pikiran kita menyesuaikan diri pada bahasa formal yang tidak mentolerir ambiguitas
Mirip seperti melakukan matematika hanya dengan bahasa alami tanpa notasi matematika: merepotkan dan lebih rentan salah
Hanya saja dilakukan dalam bahasa yang lebih mudah dipahami manusia
Ada pemetaan langsung antara intent dan implementasi
Karena pemetaannya terdefinisi dengan baik dan deterministik
Tujuan abstraksi adalah agar kita bisa percaya bahwa yang kita lakukan sekarang tetap benar tanpa harus melihat lagi ke bawahnya
Itu dimungkinkan karena aku atau seseorang yang kupercaya sudah pernah membayar biaya itu sekali
Sementara LLM mengharuskan output diverifikasi setiap kali menghasilkan sesuatu, jadi utang itu harus dibayar lagi setiap saat
Karena itu, ini sulit disebut abstraksi
Tulisannya sangat bagus
Kemarin aku juga menulis di catatan pribadiku bahwa kalau kode tidak terus berevolusi secara organik, sulit mengatakan kita benar-benar memilikinya
Rasanya seperti mobil otonom; dulu setidaknya kita masih mengingat pemandangan sepanjang jalan, sekarang kita cuma dipindahkan seketika ke tempat lain lalu ditunjukkan rekamannya
Review seperti ini jadi kurang efektif
Untuk alat kecil, ghosted code seperti ini mungkin masih oke, tapi untuk sistem seperti database ini benar-benar mengkhawatirkan
Karena itu sekarang aku hampir tidak pernah memberi agen hak tulis, dan kembali ke QA manual seperti 2 tahun lalu
Dari sisi penggunaan token maupun hasilnya, justru itu terasa lebih efisien
Tentu saja ini hanya pengalamanku
Sayangnya, sebagian besar paper Wharton yang dia tautkan tampak seperti dibuat oleh AI, dan juga belum melalui peer review
Aku tahu belakangan banyak peneliti memakai bantuan AI untuk menulis, tapi kalau topik papernya justru cognitive surrender, jadi sulit menanggapinya dengan serius
not merelysampai 7 kaliAku juga ragu LLM akan mengulang frasa yang sama sebanyak itu, jadi mungkin saja justru penulisnya yang sudah membentuk kebiasaan menulis seperti LLM
Martin tidak sepenuhnya salah, tapi aku pernah melihat AI membuat kode malas, dan pada saat itu jawaban yang benar justru menambah jumlah kode
Tepatnya, ada model Python yang mendefinisikan skema database untuk sekumpulan konsep logika tertentu
Lalu kami menambahkan konsep baru yang sangat mirip dengan himpunan logika yang sudah ada, dan Claude memutuskan bahwa set model yang ada bisa langsung dipakai ulang
Secara teori itu bisa jalan, tetapi di sisi konsumen nyata kami jadi harus melakukan berbagai workaround karena inferensi tipe saat runtime
Itu memang berfungsi, tapi merupakan contoh lapisan abstraksi yang dipilih sepenuhnya keliru
Dari sudut pandang manusia kita menginginkan abstraksi, tapi kadang pengulangan justru lebih tepat
Kalau mesin yang menulis dan memelihara kode, lapisan abstraksi tambahan yang dulu dibutuhkan mungkin sekarang tidak selalu perlu
Dulu kita memakai Duff's device dan melakukan unroll loop secara manual, menciptakan kode duplikat sendiri
Sekarang compiler memahami intent dan menghasilkan assembly yang redundan untuk kita, dan kita tidak peduli pada redundansi itu
Belakangan aku butuh beberapa potong kode computational geometry yang cukup tidak sepele dari LLM, dan kalau dulu aku akan mencari library, mengurus persetujuan compliance, dan menanggung biaya mengubah struktur data domain-ku ke format library itu
Itu mungkin lebih murah daripada mengimplementasikannya sendiri, tapi tetap sama sekali bukan biaya kecil
Sekarang LLM bisa menuliskan hanya bagian yang kubutuhkan, dan tetap memakai format data yang kusimpan
Tidak perlu memasukkan library besar atau mengubah struktur data
Secara ortodoks memang lebih benar memakai geometry library untuk mencegah duplikasi, tetapi di sini satu fungsi yang self-contained sudah bekerja dengan baik
Ini benar-benar salah satu hal terbaik yang kubaca di Hacker News setelah waktu yang lama
Sangat relate
Karena cognitive debt yang dibahas Simon Willison, dan sudut pandang bahwa “tugasmu adalah hanya mendeploy kode yang sudah kamu buktikan bekerja,” aku jadi mengerjakan proyek ke arah Intent-Driven Development
Intent sebelumnya tampak selalu memudar seiring akumulasi perubahan
Aku mungkin akan merapikan ini menjadi protokol nyata dan mempostingnya ke Hacker News nanti
Kalau kamu belum melihat tulisanku, aku sarankan mencarinya
Ringkasnya seperti ini
Visualisasi masalahku saat ini lebih dekat ke gambar ini: https://excalidraw.com/#json=y1fSSx2z8-0nFs7CDnqhp,d9Di8JdGU...
Menurutku bottleneck kognitif dalam software engineering bukan berada di dalam kode, melainkan di antara artefak-artefak itu
Kode hanyalah salah satunya
outcome → requirements → spec → acceptance criteria → executable proof → review
Aku sedang membuat tooling eksperimental untuk mengotomatisasi bagian-bagian membosankan di antara transisi ini, dan membiarkan manusia fokus memverifikasi apakah intent tetap bertahan di setiap tahap
Satu lapisan lain yang ingin kutambahkan di sini adalah proxies/metrics
Dalam sistem yang banyak unsur analisisnya, kerugian sebenarnya sering kali bukan terjadi di spec → code, melainkan di question → proxy
Begitu proxy tertanam di acceptance criteria, dashboard, atau eval, orang-orang akan mengoptimalkannya, dan fakta bahwa itu hanyalah metrik perwakilan perlahan terlupakan
Di ponsel, saat mencoba pan, zoom, dan scroll, aku malah terus menggeser elemen-elemen kanvas