Preseden Bukan Kebenaran — Bagaimana AI Menyalin Tambal Sulam dan Menciptakan Otoritas

Jika AI mengusulkan patch yang tampak masuk akal berdasarkan kode yang ada namun ada sesuatu yang terasa mengganjal, jika kalimat “codebase memang sudah begini dari dulu” semakin terasa mencurigakan, jika model yang lebih besar pun mengulang kesalahan yang sama — masalahnya bukan seberapa pintar modelnya, melainkan struktur yang keliru menafsirkan preseden sebagai kebenaran.

Ini terjadi pada saya sendiri. Lebih tepatnya, hal yang dilakukan AI yang bekerja bersama saya di depan kode saya. Saya hanya melakukan satu kalimat intervensi, dan apa yang diputus oleh satu kalimat itu — itulah seluruh isi tulisan ini.

Titik Macet

Saya sedang membangun code generator. Sebuah alat yang menghasilkan backend dan frontend dari satu spesifikasi deklaratif (schema). Janji inti alat ini hanya satu — “jika validasi lolos, build pasti berhasil.” Jika validator menyala hijau tapi compiler menyala merah, itu berarti alat tersebut berbohong.

Suatu hari, satu tipe tertentu (pengenal unik, UUID) tersangkut di validator. Ia berhenti dengan pesan “mengharapkan string tapi mendapat tipe lain.” Saya meminta AI untuk membuka kebuntuan ini. AI menelusuri kode dan segera menemukan sesuatu yang disambut gembira.

“Tipe serupa (nilai waktu) sudah ditangani dengan baik dalam situasi yang sama. Ada percabangan yang memasukkan penanda khusus agar validator meloloskannya. UUID tidak memiliki percabangan itu. Ini murni kelalaian. Cukup pulihkan simetri. Saya akan menyalin cara yang diterapkan pada nilai waktu ke UUID. Ini solusi akar masalah.”

Diagnosisnya rapi. “Asimetri”, “pemulihan simetri”, “solusi akar masalah”. Kata-katanya kuat. Rencana pun sudah disusun. Kalau dibiarkan begitu, patch itu akan di-merge.

Satu Kalimat

Saya berhenti membaca rencana itu, lalu bertanya:

“Preseden? Apakah cara penanganan nilai waktu itu benar-benar metode yang tepat? Periksa.”

Hanya itu. Saya tidak tahu jawabannya. Saya juga tidak tahu bagaimana seharusnya UUID ditangani. Yang saya miliki bukan jawaban, melainkan keraguan — “titik acuan yang hendak kamu salin itu, sudahkah diverifikasi kebenarannya?”

Satu kalimat ini memaksa AI beralih dari mode referensi-kode ke mode verifikasi-perilaku.

Asumsi yang Runtuh

Ketika AI memeriksa output aktual — bukan struktur kode, melainkan hasil yang sebenarnya dihasilkan oleh alat itu — seluruh asumsi runtuh seketika.

  • Nilai yang selama ini diyakini validator sebagai “mengharapkan string” ternyata berlawanan dengan output aktual. Generator sebenarnya menghasilkan UUID sebagai tipe khusus, dan nilai waktu sebagai tipe waktu. Keduanya bukan string.
  • Penanganan nilai waktu yang disebut “sudah ditangani dengan baik” juga memiliki lubang yang sama. Itu bukan desain yang benar, melainkan tambal sulam cacat yang bisa meloloskan validasi namun merusak build.
  • Kalau tambal sulam itu disalin ke UUID? Validator menyala hijau dan compiler menyala merah — sebuah kondisi yang melanggar langsung janji inti alat itu akan bertambah satu lagi.

Solusi yang AI sebut “solusi akar masalah” ternyata salah. Dan bukan sekadar salah — melainkan arah yang lebih buruk, mereplikasi cacat yang sudah ada sekaligus membuat validator memejamkan mata terhadap cacat baru.

Apa Nama Fenomena Ini — Error Amplification

Mari kita beri nama pada apa yang terjadi di sini. Ini adalah error amplification (amplifikasi kesalahan) AI.

AI membaca kode yang ada dan memahami strukturnya dengan tepat. Namun apakah itu desain yang benar, atau tambal sulam yang dipasang terburu-buru — dengan kata lain apakah itu keputusan atau utang — tidak bisa dibedakan hanya dengan melihat kode. Maka inilah yang terjadi:

  1. Implementasi yang ada dianggap sebagai jawaban implisit,
  2. Pola itu direplikasi ke situasi baru dengan dalih “konsistensi” dan “simetri”,
  3. Semakin banyak direplikasi, pola itu mendapat otoritas palsu berupa “codebase sudah melakukannya di banyak tempat”.

Cacat bukan dihapus. Jumlah kasusnya bertambah dan legitimasinya terakumulasi. Inilah amplifikasi. Satu tambal sulam menjadi dua, dan di depan replikasi ketiga, tidak ada yang meragukan — “codebase memang sudah begini.”

Ini bukan cerita yang berakhir pada anekdot pribadi. Pada 2025, sebuah tim peneliti bahkan mengukur fenomena ini dan memberinya judul “LLM adalah Replikator Bug (LLMs are Bug Replicators)”. (Pan et al., 2025, arXiv:2503.11082) Ketika kode di sekitarnya mengandung cacat, sebagian besar bug yang dihasilkan model identik secara harfiah dengan bug yang sudah ada — GPT-4o mencapai rasio 82,6%, dan rata-rata lintas model pun 44,4% yang benar-benar cocok dengan versi sebelum perbaikan. Yang lebih menggiriskan, dalam konteks cacat, probabilitas menghasilkan kode benar dan kode salah hampir 1:1. Model tidak membuat kesalahan secara acak. Ia memilih dan mereproduksi pola cacat yang tertanam dalam konteks.

Hukum pun memiliki jebakan yang sama. Satu preseden yang keliru semakin mendapat otoritas seiring dikutip. Frekuensi kutipan bukan bukti legitimasi, namun kita terus mencampuradukkan keduanya. Dan ini adalah penyakit yang sudah diketahui rekayasa perangkat lunak jauh sebelum era AI — klon kode yang dibuat dengan copy-paste secara diam-diam membawa bug dari aslinya. Satu studi empiris melaporkan bahwa sekitar 18% klon yang pernah mengalami bugfix mengandung bug yang disebarkan dengan cara itu, dan semakin klon berada dalam file yang sama, semakin tinggi probabilitas penyebaran. (Mondal et al., ICSME 2017) Dalam kode maupun hukum, berlaku sama. Frekuensi preseden bukan legitimasi preseden.

Mengapa Ini Bisa Terjadi

Bukan karena AI bodoh. Justru sebaliknya — karena berhati-hati, ia berusaha menjaga konsistensi, dan dalam upaya menjaga konsistensi, ia menyelaraskan diri pada titik acuan yang salah. Jika dirinci mekanismenya, ada empat faktor:

  1. Menempatkan sumber otoritas pada kode. “Kode sudah seperti ini, jadi ini yang benar.” Namun kode bisa saja hanya proyeksi sekali pakai dari sebuah keputusan, atau bahkan sekadar utang. AI tidak membuat pembedaan itu. Ilmu kognitif menyebutnya anchoring bias. Penelitian yang menguji bias ini pada LLM menunjukkan bahwa model tidak hanya tertarik kuat pada nilai yang diberikan pertama, tetapi semakin tertarik jika nilai itu diberi label ‘pakar’, dan bahwa prompt yang menyuruh “abaikan petunjuk itu” atau menelaah langkah demi langkah tidak banyak membantu koreksi. (Nguyen et al., 2024, arXiv:2412.06593) Implementasi yang sudah ada adalah jangkar paling otoritatif yang ditawarkan codebase.
  2. Mengacaukan konsistensi dengan koherensi. “Mari selaraskan simetri dengan yang sudah ada” adalah logika internal semata, tanpa memeriksa apakah titik acuan itu sesuai dengan realitas eksternal (output aktual). Self-consistency adalah properti yang terpisah dari akurasi — model bisa membangun keyakinan tanpa dasar melalui penjelasan diri yang masuk akal namun salah. (Chen et al., 2023, arXiv:2305.14279)
  3. Salah mengartikan komentar sebagai bukti. Komentar “tipe ini sengaja dikonversi ke string” diterima sebagai “bukti desain yang benar.” Komentar hanyalah niat penulisnya, bukan bukti legitimasi.
  4. Membungkus utang dengan kosakata yang meyakinkan. Kata-kata seperti “solusi akar masalah” dan “sesuai manual” memberikan kepercayaan pada usulan yang belum diverifikasi, sehingga mempermahal biaya penyaringan bagi saya. Model yang dilatih dengan preferensi manusia cenderung mendahulukan penyesuaian dan kesopanan daripada akurasi — kecenderungan yang disebut sycophancy ini membuat model mengemas usulannya dengan halus dan tegas. (Sharma et al., ICLR 2024, arXiv:2310.13548)

Apa yang Memutus Loop

Inilah inti tulisan ini. Yang memutus kesalahan bukan model yang lebih besar, bukan waktu berpikir yang lebih lama. Melainkan satu kalimat pertanyaan dari manusia.

Dan pertanyaan itu bukan intervensi yang “tahu jawabannya”. Saya tidak tahu jawabannya. Itu adalah arahan untuk meragukan asumsi. Hanya dengan satu baris itu, AI berganti mode — dari tangan yang mereferensi kode, ke tangan yang memverifikasi perilaku.

Mengejutkan, satu penelitian menemukan asimetri persis ini. Tim peneliti DeepMind menunjukkan bahwa kemampuan self-correction LLM yang buruk berasal bukan dari ketidakmampuan memperbaiki kesalahan, melainkan ketidakmampuan menemukan kesalahan — jika lokasi kesalahan saja diberitahu dari luar, model ternyata bisa memperbaikinya dengan baik. (Tyen et al., Google DeepMind, 2023, arXiv:2311.08516) Itulah yang saya lakukan. Saya tidak tahu cara memperbaiki UUID, namun saya menunjuk lokasi: “di sini, ragukan preseden ini.” Itu sudah cukup.

Ini mengatakan sesuatu tentang struktur kerja sama manusia dan AI. Nilai manusia bukan terletak pada mengetahui lebih cepat dan lebih banyak. Itu sudah dimenangkan AI. Nilai manusia terletak pada kemampuan berdiri di posisi yang meragukan asumsi tempat AI berpijak. Pertanyaan “benarkah ini?” adalah milik bukan mereka yang punya jawaban, melainkan mereka yang tahu cara meragukan jawaban.

Namun posisi itu tidak datang gratis. Satu studi pengguna dari Stanford melaporkan fakta yang tidak nyaman: peserta yang dibantu AI justru menulis kode yang kurang aman, namun percaya kode mereka lebih aman. Namun dalam studi yang sama, peserta yang kurang mempercayai AI dan lebih banyak mempertanyakannya menghasilkan kode yang lebih aman. (Perry et al., Stanford, 2022, arXiv:2211.03622) Posisi meragukan bukan nilai default. Semakin dalam kepercayaan, semakin kosong posisi itu.

Lalu Bagaimana Mencegahnya

Pelajaran ini harus ditinggalkan sebagai desain, bukan sekadar penghiburan.

  • Preseden ≠ kebenaran. Sebelum memperluas pola yang sudah ada, verifikasi terlebih dahulu bukan apakah pola itu konsisten secara internal, melainkan apakah menghasilkan output yang benar.
  • Jangkar pada ground truth. Letakkan kriteria penilaian bukan pada “struktur kode yang ada” melainkan pada output aktual · perilaku runtime · pengujian. Dalam kasus ini, penentu kemenangan semuanya bukan “seperti apa tampilannya dalam kode” melainkan “apa yang sebenarnya dihasilkan”.
  • Berusaha membedakan keputusan dan tambal sulam, tapi akui ketika gagal. Ada kalanya keduanya tidak bisa dibedakan hanya dari kode dan komentar. Dalam situasi itu, nyatakan ketidakpastiannya secara eksplisit: “ini mengikuti preseden, dan legitimasi preseden itu belum diverifikasi”.
  • Hemat kosakata yang meyakinkan. Jangan melekatkan kata-kata seperti “akar”, “kebenaran”, “sesuai” pada usulan yang belum diverifikasi.
  • Tanamkan checkpoint pada otomatisasi. Keputusan agen yang memperluas implementasi yang ada membutuhkan gerbang yang memaksa pertanyaan “sudahkah legitimasi preseden ini diverifikasi?”

Pada Akhirnya, Cerita yang Sama

Saya sudah lama mengatakan satu hal. Raw code bukan media yang melestarikan keputusan. Kode tidak bisa menampung “mengapa ini dibuat demikian.” Itulah mengapa git blame bisa menunjukkan siapa dan kapan tapi tidak bisa menunjukkan apa yang diputuskan.

Kejadian ini adalah pembuktian paling tajam dari proposisi itu. Bukan cerita tentang manusia yang kehilangan keputusan. Melainkan bahwa bahkan agen yang dirancang dengan cermat pun salah mengira tambal sulam sebagai desain dan menyebarkannya ke kode baru. Jika keputusan tidak dicatat secara eksplisit, kepintaran bukan solusinya. Justru semakin pintar, semakin konsisten dan semakin meyakinkan dalam menyebarkan utang.

Itulah mengapa saya membuat spesifikasi. Mengukir keputusan pada satu lapisan deklaratif tunggal yang otoritatif di luar kode. Bukan mengharapkan setiap kali manusia melemparkan satu kalimat pertanyaan yang meragukan preseden, melainkan membuat sistem yang melemparkannya sendiri.

Hukum bukan pedang, melainkan rambu jalan. Rambu yang baik sudah berkata lebih dahulu kepada yang tersesat: “di sini, ragukan.” Tulisan ini adalah catatan tentang bagaimana satu rambu itu didirikan — dimulai dari satu kalimat pertanyaan.

Artikel Terkait

Bacaan lanjutan (eksternal)

  • Generative AI and the End of Chesterton’s Fence — Reece. Prinsip “jangan sembarangan mencabut pagar” runtuh di hadapan kode yang dihasilkan secara probabilistik tanpa niat. Tepat menggema dengan tesis tulisan ini bahwa kode tidak bisa melestarikan keputusan di baliknya.
  • Programming as Theory Building — Christian Ekrem. Meminjam klasik Peter Naur untuk berargumen bahwa “program adalah teori dalam kepala manusia, bukan source code.” Akar teoritis mengapa AI yang hanya melihat kode tidak bisa membedakan desain dan utang.
  • Vibe coding is not the same as AI-Assisted engineering — Addy Osmani. Menunjukkan alasan vibe coding yang membutakan diri pada output AI meledak di produksi dengan insiden nyata, dan meresepkan alur kerja berbasis spesifikasi dan verifikasi manusia.
  • Cognitive Debt — Simon Willison (mengutip Storey). Semakin cepat AI mencetak kode, utang sejati bukan “cacat dalam kode” melainkan “manusia yang tidak lagi memahami kode itu” — konsep utang kognitif.
  • Overreliance on AI: Addressing Automation Bias — Lumenova AI. Mekanisme automation bias, anchoring, dan confirmation bias yang menumpulkan penilaian manusia, beserta solusi “perangkat pemaksaan kognitif” — mendukung secara psikologis nilai manusia yang tahu “di mana harus meragukan”.

Bibliografi

  • Pan et al. “LLMs are Bug Replicators: An Empirical Study on LLMs’ Capability in Completing Bug-prone Code” (2025, arXiv:2503.11082)
  • Mondal, Roy, Schneider. “Bug Propagation through Code Cloning: An Empirical Study” (ICSME 2017, link)
  • Nguyen et al. “Anchoring Bias in Large Language Models: An Experimental Study” (2024, arXiv:2412.06593)
  • Chen et al. “Two Failures of Self-Consistency in the Multi-Step Reasoning of LLMs” (2023, arXiv:2305.14279)
  • Sharma et al. “Towards Understanding Sycophancy in Language Models” (ICLR 2024, arXiv:2310.13548)
  • Tyen et al. (Google DeepMind). “LLMs cannot find reasoning errors, but can correct them given the error location” (2023, arXiv:2311.08516)
  • Perry, Srivastava, Kumar, Boneh. “Do Users Write More Insecure Code with AI Assistants?” (Stanford, 2022, arXiv:2211.03622)
  • Gambar utama: dihasilkan AI (Google Gemini)