Utang teknis, utang kognitif, utang intensi
(martinfowler.com)- Dalam lingkungan tempat LLM memproduksi kode dalam jumlah besar, yang melemah bukan hanya masalah pada kode itu sendiri, tetapi juga pemahaman bersama tim dan catatan tujuan sistem, sehingga makin penting untuk menanganinya dalam tiga lapisan: utang teknis, utang kognitif, dan utang intensi
- Technical debt membatasi kemungkinan perubahan di masa depan, Cognitive debt melemahkan kemampuan tim untuk menalar perubahan pada sistem, dan Intent debt membuat catatan tujuan serta kendala menjadi kabur sehingga menghambat evolusi berkelanjutan oleh manusia maupun agen AI
- Teori Tri-System yang menempatkan AI sebagai System 3 membedakan cognitive surrender, yaitu ketika penalaran buatan dari luar dipercaya tanpa kritik sehingga proses berpikir mendalam dilewati, dari cognitive offloading yang merupakan pendelegasian kognisi secara strategis
- Semakin murah biaya coding, semakin mahal verification, dan tolok ukur akurasi serta keberhasilan berbeda menurut konteks, seperti ETA lalu lintas, penugasan pengemudi, atau operasi ratusan microservice, sehingga penilaian manusia dan perancangan sistem verifikasi menjadi makin penting
- Poros utama engineering bergeser dari volume implementasi ke verifikasi, dan ke depan manusia akan tetap memegang peran dalam 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 sebenarnya dilakukan sistem, dan sudut pandang yang melihat ini sebagai Cognitive Debt makin menguat
- Tiga lapisan kesehatan sistem membagi utang ke dimensi kode, manusia, dan artefak
- Technical debt berada pada kode; ia menumpuk ketika keputusan implementasi merusak kemungkinan perubahan di masa depan dan membatasi bagaimana sistem dapat berkembang
- Cognitive debt berada pada manusia; ia menumpuk ketika pemahaman bersama tentang sistem melemah lebih cepat daripada upaya untuk melengkapinya, sehingga membatasi kemampuan tim untuk menalar perubahan
- Intent debt berada pada artefak; ia menumpuk ketika tujuan dan kendala yang seharusnya mengarahkan sistem tidak terdokumentasi atau tidak dipelihara dengan baik, sehingga membatasi apakah sistem masih mencerminkan apa yang semula ingin dibuat, dan apakah manusia maupun agen AI dapat terus mengembangkannya secara efektif
- Sudut pandang ini juga mencakup bagian untuk mendiagnosis dan memitigasi tiap utang, sekaligus membahas bahwa ketiganya saling berinteraksi
- Tim perlu menjalankan aktivitas umum untuk mengendalikan ketiga jenis utang ini secara bersamaan
Teori Tri-System dan penyerahan kognitif
- Makalah yang menambahkan LLM ke model berpikir dua sistem ala Kahneman memperluas kerangka berpikir dengan menempatkan AI sebagai System 3
- System 1 membuat keputusan cepat lewat intuisi, sedangkan System 2 adalah tahap berpikir yang disengaja untuk memecahkan masalah
- Demi menghemat energi, manusia secara default cenderung mengandalkan intuisi, sehingga bisa melewatkan hal-hal yang seharusnya ditemukan jika dipikirkan lebih matang
- Sebagai konsekuensi dari System 3, muncul cognitive surrender, yang didefinisikan sebagai keadaan ketika penalaran buatan yang dihasilkan dari luar dipercaya tanpa kritik sehingga System 2 dilewati
- 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 melalui sejumlah eksperimen juga memverifikasi seberapa valid teori ini dalam memprediksi perilaku, setidaknya di lingkungan laboratorium
Notasi <> sebagai ikon kode
- Belakangan ini beberapa ilustrasi memakai simbol “<>” sebagai ikon kode, tetapi notasi ini terasa tidak lazim sebagai penanda yang membungkus elemen bahasa pemrograman
- Alasan “<>” dipakai alih-alih simbol lain seperti “{ }” tampaknya karena ia mengingatkan pada HTML atau XML
- Jika sampai memakai bentuk “</>”, asosiasi dengan HTML menjadi lebih langsung, tetapi HTML sendiri tidak diperlakukan sebagai bahasa untuk menulis program oleh programmer
Saat coding menjadi murah, yang menjadi mahal adalah verifikasi
- if coding agents make coding free, what becomes the expensive thing berpendapat bahwa semakin coding agent menurunkan biaya coding, elemen yang menjadi mahal adalah verification
- Standar akurasi terus berubah tergantung konteks
- Algoritme ETA untuk lalu lintas Jakarta dan algoritme ETA untuk lalu lintas Ho Chi Minh City bisa memiliki makna “correct” yang berbeda
- Dalam penugasan pengemudi, “successful” tidak punya satu definisi tunggal karena harus sekaligus menyeimbangkan keadilan pendapatan, waktu tunggu pelanggan, dan tingkat pemanfaatan kendaraan
- Dalam lingkungan tempat ratusan engineer terus melakukan deployment ke sekitar 900 microservice, “correct” tidak lagi punya 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 oleh agen
- Agen bekerja sangat baik terutama dalam alur yang memiliki verifikasi yang baik dan kalau bisa terotomatisasi terhadap hasil kerja
- Alur seperti ini mendorong Test Driven Development
- Karena jumlah verifikasi yang tetap harus dilakukan masih besar, dibutuhkan lebih banyak upaya untuk membantu manusia memahami cakupan pengujian yang lebih luas dengan mudah
- Untuk modernisasi legacy, ada juga beberapa pandangan berbeda
- Harapan bahwa agentic coding pada akhirnya akan menyelesaikan modernisasi legacy sepenuhnya dinilai berlebihan
- Namun, ada bukti kuat bahwa LLM sangat membantu dari sisi understanding what legacy code is doing
Reorganisasi menuju organisasi yang berpusat pada verifikasi
- Ketika agen mengambil alih eksekusi, pekerjaan manusia bergeser ke perancangan verification system, pendefinisian quality, dan penanganan kasus ambigu yang tidak dapat diselesaikan agen
- Struktur organisasi juga perlu berubah agar sesuai dengan perubahan ini
- Pertanyaan dalam stand-up Senin pagi akan lebih berpusat pada “apa yang telah diverifikasi” daripada “apa yang telah dideploy”
- Fokus akan bergeser dari melacak output ke melacak apakah hasilnya benar
- Tim yang sebelumnya terdiri dari 10 engineer pembuat fitur dapat disusun ulang menjadi 3 engineer, ditambah 7 orang yang menangani pendefinisian acceptance criteria, perancangan test harness, dan pemantauan outcome
- Reorganisasi seperti ini bisa terasa tidak nyaman karena menurunkan status kegiatan membuat dan menaikkan status kegiatan menilai
- Budaya engineering yang tidak menolak perubahan ini kemungkinan akan lebih berhasil
Masa depan source code dan bahasa yang ramah LLM
- Di tengah arus yang memperlakukan LLM seperti programmer, masa depan source code sendiri ikut menjadi pertanyaan
- several views of the future of code mengumpulkan berbagai sudut pandang tentang masa depan kode
- Sebagian sedang bereksperimen dengan bahasa yang benar-benar baru yang dirancang dengan mempertimbangkan LLM
- Pihak lain melihat bahwa bahasa yang ada sekarang, khususnya bahasa bertipe ketat seperti TypeScript dan Rust, mungkin lebih cocok untuk LLM
- Tulisan ini penuh kutipan dan tidak banyak analisis sendiri, tetapi tetap layak dibaca sebagai materi tinjauan umum atas keseluruhan diskusi
Abstraksi dan penamaan yang tetap menjadi peran manusia
- Bahkan dalam proses membuat software bersama LLM, manusia akan tetap memegang peran untuk membuat abstraksi yang berguna agar kita bisa 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 bisa memahami dan mengeksekusinya, tetapi juga membentuk solusi
- Ini mencakup memecah masalah menjadi bagian-bagian yang terfokus, mengelompokkan data dan perilaku yang saling terkait, 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 lebih jelas
3 komentar
Istilah utang niat adalah istilah yang dulu pernah saya definisikan sendiri dengan cara saya sendiri, jadi menyenangkan melihatnya lagi seperti ini. Sepertinya cara berpikir orang memang mirip-mirip.
Tulisan blog: https://brunch.co.kr/@limjk/2
Melakukan restrukturisasi organisasi dengan cepat agar selaras dengan perubahan juga terasa agak konservatif, jadi menimbulkan sedikit antipati.
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