Understanding Is the New Bottleneck: Memahami Kode di Era AI

Bayangkan ini: Anda baru saja meminta AI agent membangun fitur pencarian full-text untuk aplikasi yang sedang dikembangkan. Tiga puluh detik kemudian, agent mengembalikan 400 baris kode yang tersebar di tujuh file. Semua tes hijau. Semua linter puas. Fitur berjalan. Tapi ketika klien bertanya, "Bagaimana logika relevansinya bekerja?" Anda menyadari bahwa Anda tidak punya jawaban yang meyakinkan. Bukan karena kode-nya salah, tapi karena Anda belum memahaminya.

Di era di mana AI agent menulis kode lebih cepat daripada kita bisa membaca, understanding is the new bottleneck. Ini bukan klaim dari filsuf teknologi, tapi dari Geoffrey Litt, Design Engineer di Notion, yang baru-baru ini menyampaikan talk dengan judul persis itu. Pesan intinya: bottleneck dalam software engineering telah bergeser. Dulu kita kesulitan menulis kode. Sekarang, kita kesulitan memahami apa yang sudah ditulis. Dan pergeseran ini mengubah segalanya tentang bagaimana kita bekerja.

Mengapa Harus Memahami?

Pertanyaan pertama yang muncul: bukankah tujuan AI agent precisely untuk mengeluarkan manusia dari loop? Jika agent semakin pintar memverifikasi dirinya sendiri, mengapa manusia masih perlu repot memahami detail implementasi?

Jawaban yang paling umum: kita perlu memahami untuk memverifikasi. Kita membaca diff untuk memastikan agent tidak salah. Tapi Litt menantang asumsi ini. Menurutnya, agent memang semakin baik dalam memverifikasi pekerjaannya sendiri. Thumbs-up atau thumbs-down semakin bisa didelegasikan ke mesin. Jika verifikasi adalah satu-satunya alasan kita memahami, maka manusia akan semakin tidak relevan.

Alasan yang lebih dalam adalah partisipasi. Software engineering tidak pernah sekali jadi. Sebuah proyek adalah ribuan iterasi. Dan pemahaman Anda terhadap sistem adalah modal kreatif untuk iterasi berikutnya. Tanpa vocabulary mental yang kaya, Anda tidak bisa berpikir kreatif tentang evolusi fitur. Anda hanya menjadi operator yang mengucapkan prompt berikutnya tanpa visi arsitektural.

Cognitive Debt: Tech Debt Versi Otak

Litt mengutip konsep cognitive debt yang dipopulerkan Margaret Storey dan Simon Willison. Mirip tech debt, cognitive debt adalah biaya tersembunyi dari keputusan untuk tidak memahami sistem. Jangka pendek, Anda bisa lolos. Jangka panjang, bunga mentalnya menghancurkan: bug yang sulit di-debug, refactoring yang menakutkan, dan tim yang "simply lost the plot".

Paradoksnya, AI yang seharusnya mengurangi beban kognitif justru bisa mempercepat akumulasi cognitive debt. Semakin cepat agent menghasilkan kode, semakin cepat pula kita kehilangan pemahaman terhadap codebase. Loop AI berjalan lebih cepat daripada kecepatan otak manusia mengasimilasi. Kita terjebak dalam spiral produktivitas palsu: lebih banyak kode, lebih sedikit pemahaman, lebih banyak masalah di kemudian hari.

Tiga Teknik Membangun Pemahaman di Era AI

Dalam talk-nya, Litt menawarkan tiga teknik yang terinspirasi dari pedagogi untuk memperlambat loop dan memperdalam pemahaman:

1. Code Explainer Docs

Jangan baca raw diff. Diff adalah artefak mesin, bukan artefak manusia. Sebaliknya, minta agent memproduksi literate diff: penjelasan terstruktur yang memadukan konteks, intuisi, dan cuplikan kode dalam urutan yang masuk akal secara naratif. Litt membangun skill /explain-diff yang menghasilkan dokumen eksplanasi HTML atau Notion untuk setiap perubahan besar.

Prinsipnya sederhana: ajar latar belakang dulu sebelum detail. Berikan intuisi sebelum syntax. Seorang reviewer yang baik bukan mesin CI/CD yang mengecek kebenaran, tapi mentor yang memastikan rekan timnya ikut naik level pemahamannya. Litt bahkan mencetak explainer docs ini dan membacanya di kafe. Ironis: AI yang membuat aktivitas interaktif berubah jadi laporan kertas yang bisa dibaca dengan fokus mendalam.

2. Quiz sebagai Speed Regulator

Salah satu ide paling provokatif dari Litt: setiap explainer doc diakhiri dengan kuis interaktif berisi lima pertanyaan tentang perubahan kode tersebut. Aturannya tegas: jangan kirim kode ke orang lain sebelum bisa lulus kuis. Jangan approve PR sebelum benar-benar paham.

Kuis adalah speed regulator mekanis. Bekerja dengan AI, loop bisa berjalan lebih cepat dari kecepatan pemahaman manusia. Kuis menjadi gaya counterbalancing yang memaksa kita bertanya: apakah saya benar-benar memahami? Atau hanya mengira-ngira? Ini adalah bentuk disiplin mental yang jarang kita temui di toolchain modern.

3. Micro-worlds

Inspirasi dari Seymour Papert, bapak LOGO: untuk belajar matematika, Anda harus tinggal di Mathland. Bukan membaca buku tentang Prancis, tapi hidup di Prancis.

Bagaimana menerapkannya pada kode? Bangun environment interaktif tempat Anda bisa hidup di dalam sistem. Saat Litt membangun Prolog interpreter, ia meminta agent membuat debugger visual yang memungkinkannya scrub through time, melihat stack, dan memahami evaluasi rule secara intuitif. Agent tidak melakukan debugging untuknya. Agent membuat tool yang membantu Litt memahami sehingga ia bisa melakukan debugging sendiri.

Ini pembeda filosofis yang besar: agent menulis kode untuk membantu manusia memahami kode lain. Bukan menggantikan manusia, tapi memperkuat kapasitas kognitif manusia.

4. Shared Spaces

Pemahaman tidak hanya personal, tapi kolektif. Tim yang memegang shared mental model bisa berkomunikasi dengan efisien. Mereka punya vocabulary yang sama, memicu gambaran mental yang seragam, sehingga bisa jam dan riff secara kreatif.

Di Notion, Litt dan timnya membangun collaborative space tempat agent dan manusia bekerja bersama. Technical plan yang dibuat Claude langsung muncul di halaman Notion yang bisa dikomentari rekan tim. Thinking together, not alone. Tanpa shared space, setiap anggota tim terjebak di silo kognitifnya sendiri, menebak-nebak apa yang sebenarnya terjadi di codebase.

Augment, Not Automate

Talk ini mengingatkan kita pada visi asli komputasi. Lima puluh tahun lalu Alan Kay membayangkan komputer bukan sebagai media pasif seperti televisi, tapi sebagai medium dinamis tempat anak-anak belajar fisika dengan bermain dan mengedit simulasi interaktif. Bukan untuk mengotomatisasi pembelajaran, tapi untuk meng-augment kapasitas berpikir manusia.

AI membuat pembuatan simulasi dan tools personalisasi jadi sangat mudah. Tapi tujuannya bukan mengeluarkan manusia dari loop. Tujuannya adalah memungkinkan kita masuk lebih dalam ke loop. Lebih dalam memahami. Lebih dalam berpartisipasi. Lebih dalam berkreasi.

Ini adalah pilihan desain yang harus kita buat setiap hari: apakah kita menggunakan AI untuk mengganti pemikiran, atau untuk memperdalamnya? Verifikasi yang didelegasikan ke mesin memang nyaman. Tapi partisipasi yang didalamkan oleh pemahaman itulah yang membuat software engineering tetap menjadi pekerjaan kreatif, bukan assembly line.

Jadi pertanyaannya: kali terakhir Anda meminta agent menulis kode, apakah Anda kemudian meluangkan waktu untuk benar-benar memahami apa yang ia tulis? Atau Anda hanya melihat hasilnya berjalan, lalu beralih ke tugas berikutnya? Jika jawabannya yang kedua, mungkin bottleneck bukan pada AI-nya yang terlalu lambat, tapi pada kita yang terlalu cepat melupakan.