Utang kognitif: ketika kecepatan melampaui pemahaman

• Pengembangan berbantuan AI membuat kecepatan produksi kode melampaui kecepatan pemahaman manusia, sehingga memunculkan "utang kognitif (cognitive debt)"
• Meski kode berjalan normal dan lolos pengujian, tetap terjadi akumulasi kondisi ketika pengembang sendiri tidak memahami struktur dan alasan di balik kode tersebut
• Keterbatasan peninjau dalam melakukan review, hilangnya pengetahuan implisit di organisasi, dan kekurangan pembelajaran bagi pengembang junior makin mempercepat utang ini
• Organisasi hanya mengukur metrik yang berpusat pada kecepatan (DORA, story point, dll.), sehingga gagal menangkap kekurangan pemahaman
• Semakin besar kesenjangan antara produktivitas dan pemahaman, semakin besar pula risiko jangka panjang berupa kegagalan pemeliharaan, terputusnya pengetahuan, dan stagnasi pertumbuhan engineer

---

Keterlambatan pemahaman (The Comprehension Lag)

• Coding manual menjalankan dua proses sekaligus: produksi dan penyerapan, dan gesekan saat mengetik membantu mendorong proses berpikir
  • Saat menulis kode, model mental dan intuisi terbentuk secara alami
• Pengembangan berbantuan AI memisahkan proses ini, sehingga kecepatan output melonjak tajam sementara kecepatan memahami tetap terikat pada batas manusia
• Kesenjangan antara output dan pemahaman inilah yang disebut utang kognitif, dan tidak seperti utang teknis, utang ini tidak terlihat dalam metrik kecepatan
• Masalahnya baru tampak kemudian dalam metrik keandalan seperti kenaikan MTTR dan naiknya tingkat kegagalan perubahan

Apa yang benar-benar diukur organisasi (What Organizations Actually Measure)

• Organisasi hanya mengukur hasil yang terlihat seperti jumlah fitur, commit, atau kecepatan review
• Di masa lalu, hasil dan pemahaman saling terhubung, sehingga ketika fitur dirilis, diasumsikan ada pemahaman di baliknya
• Namun di era AI, fitur dapat dirilis hanya dengan pemahaman permukaan, sehingga asumsi ini tidak lagi berlaku
• Karena metrik organisasi tidak mampu menangkap kekurangan pemahaman, sistem evaluasi kinerja dan kompensasi pun menjadi terdistorsi

Dilema reviewer (The Reviewer’s Dilemma)

• Dengan AI, developer junior bisa menghasilkan kode lebih cepat daripada senior
• Reviewer senior tidak punya cukup waktu untuk menelaah volume kode yang sangat besar secara mendalam, sehingga kedalaman review terpaksa dikorbankan
• Akibatnya, anggapan bahwa "kode yang sudah direview = kode yang dipahami" pun runtuh
• Karena tekanan organisasi memprioritaskan kecepatan, budaya yang menekankan throughput dibanding kualitas review makin menguat

Pola burnout (The Burnout Pattern)

• Engineer yang menggunakan alat AI mengalami kelelahan karena output tinggi berjalan berdampingan dengan rasa tidak yakin yang rendah
• Kode memang berjalan, tetapi kecemasan karena tidak sepenuhnya memahami sistem yang mereka buat sendiri terus bertahan
• Sistem penilaian yang berpusat pada kecepatan membuat investasi waktu untuk membangun pemahaman yang mendalam terasa seperti kerugian, sehingga utang kognitif makin cepat bertambah

Keruntuhan ingatan organisasi (When Organizational Memory Fails)

• Pengetahuan organisasi terdiri dari pengetahuan eksplisit yang terdokumentasi dan pengetahuan implisit yang ada di kepala developer
• Pengembangan dengan AI mempersingkat proses pembentukan pengetahuan implisit (pengalaman implementasi langsung), sehingga akumulasi pengetahuan tidak terjadi
• Akibatnya, sistem tetap berjalan, tetapi orang yang benar-benar memahaminya makin lama makin hilang
• Saat masalah muncul, organisasi bisa sampai pada kondisi tidak ada seorang pun yang dapat menjelaskan konteks sistem tersebut

Bagaimana utang ini terakumulasi (How the Debt Compounds)

• Pertama, semakin lama usia kode, semakin besar risikonya — kode yang sejak awal hanya dipahami secara tidak sempurna menjadi benar-benar opak
• Kedua, waktu pemulihan saat insiden melonjak — muncul situasi harus men-debug "black box yang dibuat oleh black box"
• Ketiga, ketiadaan senior engineer di masa depan — ketergantungan pada AI menghapus kurva belajar dan menimbulkan kekosongan kepemimpinan jangka panjang

Sudut pandang director (The Director’s View)

• Eksekutif hanya melihat sinyal positif seperti peningkatan produktivitas, pemendekan jadwal, dan efisiensi tenaga kerja
• Karena tidak ada metrik untuk mengukur "kedalaman pemahaman" atau "kemampuan menjelaskan", utang kognitif tidak pernah dilaporkan
• Akibatnya, pengambilan keputusan berbasis data memang rasional, tetapi tetap tidak lengkap, dan risiko yang sebenarnya tersembunyi

Batas model ini (Where This Model Breaks)

• Konsep utang kognitif tidak berlaku dengan cara yang sama untuk semua jenis pekerjaan
  • Untuk pekerjaan repetitif sederhana atau eksperimen cepat, pendekatan ini bisa saja cocok
• Di masa lalu pun tingkat pemahaman berbeda-beda pada tiap individu, sehingga ini mungkin lebih merupakan pergeseran distribusi daripada fenomena baru sepenuhnya
• Ke depan, ada kemungkinan perbaikan alat dan dokumentasi dapat mengurangi kesenjangan pemahaman

Masalah pengukuran (The Measurement Problem)

• Organisasi hanya mengoptimalkan hal yang bisa diukur
  • Kecepatan bisa diukur, tetapi pemahaman tidak bisa
• Selama pemahaman tidak tercermin dalam sistem evaluasi, insentif yang berpusat pada kecepatan akan tetap bertahan
• Ini bukan kegagalan individu atau manajer, melainkan akibat sistem pengukuran dari era sebelumnya yang tidak lagi selaras dengan realitas saat ini
• Pada akhirnya, kesenjangan ini kemungkinan akan terlihat dalam bentuk kenaikan biaya pemeliharaan, keterlambatan respons insiden, dan terbukanya kerentanan sistem
• Penutupnya menyimpulkan: "Sistem dioptimalkan sesuai apa yang diukurnya. Namun apa yang sekarang diukur tidak lagi menangkap hal yang paling penting."

[laeyoung]

Saya juga akhir-akhir ini memikirkan hal yang serupa, jadi kemarin saya menulis sebuah postingan blog tentang cognitive debt. Sepertinya semua orang punya kegelisahan yang mirip.

[bini59]

Bagaimana seharusnya kita memahami kode? Haruskah kita mengukurnya dengan memberikan kuis berdasarkan basis kode internal?

[GN⁺]

Komentar Hacker News

• Pengalaman beberapa bulan terakhir sangat relate dengan isi artikel
  Proyek tempat saya bekerja terus berkembang, tetapi jumlah engineer justru berkurang
  Kami makin bergantung pada pengujian dan beralih ke pengembangan berbasis simulator. Verifikasi di sistem nyata jadi jarang, dan setiap kali melakukannya, kami justru menangani bagian yang paling kompleks
  Sejak sekitar tahun lalu, saya merasa bahkan detail fitur yang saya kerjakan berbulan-bulan pun cepat terlupakan. Itu terjadi bahkan sebelum coding agent benar-benar diadopsi secara luas
  Setelah agent masuk, review PR jadi jauh lebih implisit, sehingga konteks tidak benar-benar tertinggal di kepala dan saya harus sengaja memusatkan perhatian. Rekan satu tim juga melaporkan pengalaman yang sama
  Sekarang kami sedang mencoba berbagai hal, seperti meng-commit rencana agent bersama kode. Hasilnya, proses kami berubah menjadi lebih sistematis dan eksplisit
  Namun, engineering manager tampaknya hampir tidak menyadari peningkatan beban kognitif ini

  • Dalam pengalaman saya, manajer sering melihat hutan tetapi melewatkan pohonnya. Peran manajer yang baik adalah mengurangi beban kognitif tim
  • Yang saya pelajari pada akhirnya adalah kebiasaan mencatat. Hanya membaca tidak membuatnya melekat di kepala
  • Saat ini kita belum punya abstraksi yang benar-benar mendukung AI-driven development. Kita sudah menggantikan diri sendiri, tetapi alat satu tingkat di atasnya belum ada
  • Ke depan, menyimpan rekam percakapan dengan agent (prompt, rencana, laporan hasil) kemungkinan akan makin penting

• Premis tulisan ini, yaitu “developer mengingat kode yang ia tulis 6 bulan lalu”, itu keliru
  Sejak dulu, memahami kode saat menulis memang lebih mudah daripada saat membacanya. Joel Spolsky juga pernah mengatakan bahwa “membaca kode lebih sulit daripada menulisnya”

  • Walau detail logika terlupakan, alur keseluruhan tetap diingat sehingga lebih mudah dipahami kembali
  • Saya pernah melihat lagi codebase dari 4 tahun lalu dan masih bisa mengingat struktur serta niat desainnya dengan baik
  • Saya bekerja bolak-balik di beberapa codebase, tetapi saat kembali setelah 6 bulan rasanya mirip dengan kembali setelah seminggu. Gaya coding yang familiar dan intuisi struktural cepat hidup lagi
  • Saat pertama belajar, penting untuk menulis kode sendiri dengan tangan agar berpikir kritis terinternalisasi. Karena itu saya sering bereksperimen langkah demi langkah di Jupyter notebook
  • Membaca itu sulit bukan berarti lambat. Walau AI menulis kode sebagai gantinya, proses pemahaman tetap dibutuhkan. Hanya saja manusia secara naluriah cenderung menghindari pekerjaan yang sulit

• Masalah “kode yang tidak dipahami” sudah ada bahkan sebelum AI
  Misalnya, seperti kasus penghapusan kode Pinball oleh Microsoft, ada kasus ketika kode outsource lama terlalu rumit sehingga tak seorang pun memahaminya dan fitur itu akhirnya ditinggalkan
  Kasus codebase Oracle RDBMS juga serupa

  • Namun seperti kata OP, pada kode AI situasi seperti ini bisa terjadi lebih sering dan lebih cepat
  • Karena itu saya pikir prompt juga harus disimpan bersama version control. Itu menjadi konteks bagi manusia maupun mesin
  • Ini mengingatkan saya pada lelucon, “Saat saya menulis kode, hanya saya dan Tuhan yang memahaminya; sekarang hanya Tuhan yang paham”

• Ungkapan “sistem yang bekerja normal tetapi terasa asing” sangat membekas
  Ini mirip dengan perasaan saat developer beralih menjadi manajer. Semakin jauh dari kode, pemahaman terasa lebih abstrak dan terputus

  • Saya juga manajer sekaligus developer, dan belakangan ini “vibe-coding” mencakup sebagian besar pekerjaan saya. Intinya adalah memikirkan gambaran besar dan memverifikasi apakah kodenya selaras dengan gambaran itu
  • Pada akhirnya, seperti manajemen yang baik, kita butuh batas domain yang jelas, standar kualitas, dan proses perbaikan berulang

• Bagian paling menyakitkan adalah bahwa “engineer yang berusaha memahami secara mendalam tertinggal dalam metrik kecepatan”
  Pasar lebih mementingkan kecepatan daripada kualitas, dan akhirnya tercipta struktur di mana engineer yang hati-hati justru di-PHK

  • Tentu saja, keterbatasan kadang melahirkan kreativitas. Jika waktu dan uang tak terbatas, kita akan mengejar kesempurnaan, tetapi di dunia nyata dengan persaingan dan keterbatasan sumber daya, ada banyak contoh bahwa batasan justru membentuk kualitas

• Mungkin sekarang saatnya menuju era “LGTM, LLM”
  Industri selalu bergerak berlebihan lalu belakangan menemukan keseimbangan. Masalahnya adalah ekspektasi yang mustahil: minta produktivitas 20x sambil menuntut tanggung jawab 100%
  Pada akhirnya kita harus menyerah pada pemahaman, atau hanya menerima kenaikan produktivitas maksimal sekitar 20%

  • Seperti nasihat desain game dari Sid Meier, “Double it or cut it in half”, penyesuaian ekstrem kadang memang diperlukan (tautan)
  • Peningkatan produktivitas berbeda-beda tergantung struktur codebase. Proyek legacy justru bisa menjadi lebih lambat, sedangkan pada struktur yang ramah LLM peningkatannya bisa besar
  • Saya sendiri masih belajar struktur itu, dan ini masih tahap bleeding edge
  • Di luar penulisan kode, jika LLM dimanfaatkan secara kreatif untuk seluruh proses delivery produk, peningkatan produktivitas bisa lebih besar lagi
  • Namun pada akhirnya, saat masalah meledak, kita tetap akan ditanya, “kenapa ini belum selesai juga?” Budaya yang berfokus pada rilis jangka pendek masih tetap ada
  • Pada akhirnya sesuatu harus rusak dulu agar bisa diperbaiki, solusi tambal sulam hanya memperpanjang penderitaan

• Ini mengingatkan pada filosofi Richard Gabriel, Worse Is Better
  Kode AI sering memilih kesederhanaan daripada ketepatan, tetapi pendekatan realistis “asal berfungsi, berarti menang” bisa saja yang menang
  Begitu ada sistem yang berjalan, kita bisa memperbaikinya secara bertahap

  • Tetapi ada juga sanggahan bahwa tujuan kita seharusnya bukan “menang”, melainkan membuat produk yang bisa dibanggakan
  • Dalam beberapa kasus, AI justru me-refactor kode manusia. Jujur saja, AI menulis kode lebih rapi dan lebih cepat daripada saya
  • Menarik juga mempertanyakan bahwa kesederhanaan bisa berbenturan dengan ketepatan

• Tim kami juga mengalami persis fenomena yang dibahas artikel itu selama 6 bulan terakhir
  Kalimat kuncinya tepat: pengembangan berbantuan AI memutus akumulasi pengetahuan implisit
  Namun, fenomena ini mungkin hanya fase transisi sementara
  Dalam jangka panjang, LLM bisa saja memberikan nilai pada level meta dengan menata struktur kode dengan baik, sehingga manusia hanya perlu memahami secara mendalam saat benar-benar diperlukan

  • Tetapi saat ini LLM menghasilkan terlalu banyak kode yang tidak perlu dan solusi yang belum dimurnikan, sehingga justru muncul situasi di mana LLM menjadi wajib untuk debugging dan maintenance

• Jika dokumentasi kurang, tim dukungan produk juga akan terkena dampak besar
  Saat pelanggan bertanya tentang perilaku produk, akan sulit menjawab jika bahkan engineer tidak benar-benar memahami kode yang mereka tulis
  Jika kecepatan update terlalu tinggi, tim lain sulit mengejarnya

  • Waktu yang dihemat dari penulisan kode harus diimbangi dengan menjadikan dokumentasi sebagai bagian dari workflow. Saya juga merasa sekarang harus mulai melakukannya

• Hal serupa juga pernah terjadi saat bahasa tingkat tinggi muncul, dan hasil akhirnya baik-baik saja
  Jadi, apakah tidak apa-apa jika LLM juga mengabstraksikan pemahaman kode?
  Bedanya, compiler bersifat deterministic sedangkan LLM bersifat probabilistic

  • Menyamakan LLM dengan compiler terasa berlebihan. Compiler adalah proses deduktif, sedangkan LLM adalah proses induktif
  • Di masa depan, jika sudah ada agent deterministik, model supercepat, dan lingkungan eksekusi lokal, mungkin bedanya tidak akan sebesar itu dibanding bahasa tingkat tinggi
  • Namun pendidikan pemrograman akan berubah total. Mengetahui bahasa itu sendiri akan terdorong ke posisi seperti assembly saat ini
  • Tujuan bahasa tingkat tinggi adalah mengekspresikan struktur secara eksplisit agar mudah dibaca manusia, tetapi LLM justru kebalikannya
  • Dalam praktiknya, jika intuisi pada level hardware hilang, risiko kode yang tidak efisien atau celah keamanan bisa meningkat