# Utang Teknis AI: Dua Masalah Berbeda dengan Solusi Berbeda

URL: https://codebasechat.com/id/journal/utang-teknis-ai-dua-masalah-berbeda
Type: blog
Locale: id
Published: 2026-07-14
Updated: 2026-07-14

---

> Utang teknis AI terbagi dua: utang kode (duplikasi yang ditangkap tools) dan utang kognitif (jarak antara generasi dan pemahaman tim). Survei Sonar 2026 menunjukkan 88% developer terdampak.

## Utang Teknis AI Itu Dua Masalah Berbeda, Bukan Satu

Utang teknis AI bukan kekacauan yang Anda pikir. Bukan hanya tentang fungsi yang duplikat dan penamaan yang berantakan yang bisa ditangkap linter. Setengahnya terlihat baik-baik saja saat review, lolos approval, dan baru ketahuan enam minggu kemudian saat tidak ada yang bisa jelaskan kenapa satu perubahan kecil malah rusak tiga hal yang tidak terduga. Itulah bagian yang sebagian besar tim sama sekali tidak ukur. Masalah ini menjadi semakin penting karena semakin banyak tim yang menggunakan AI untuk development, terutama dalam organisasi dengan tim distributed dan pengetahuan siloed di beberapa individu kunci.

## Utang Teknis AI: Dua Masalah Berbeda, Butuh Solusi Berbeda

Tanya lima manajer teknik tentang utang teknis AI dan Anda akan dengar lima definisi berbeda. Tapi umumnya mereka jatuh ke dua kategori yang sangat beda.

Pertama adalah utang kode: duplikasi, pola inkonsisten, kode yang teknis benar tapi bikin surface area tambahan yang tidak diminta. Ini yang sebenarnya dibuat untuk tools analisis statis.

Kedua adalah utang kognitif: jarak antara seberapa cepat kode dibuat dan seberapa cepat tim benar-benar membangun pemahaman bersama tentang apa yang dilakukan sistem. Survei developer Sonar tahun 2026 menemukan 88% developer melaporkan setidaknya satu dampak negatif AI pada utang teknis, dan 53% bilang AI menghasilkan kode yang terlihat benar tapi sebenarnya ada bug tersembunyi. Itu masalah utang kode. Yang tidak sepenuhnya ditangkap survei adalah jenis kedua, dan [laporan LeadDev tentang ini](https://leaddev.com/ai/ai-coding-creates-two-kinds-of-debt-youre-only-measuring-one) adalah penjelasan paling jelas yang pernah kami baca.

Tiga dari lima tim mencampur dua masalah ini. Inilah yang dua tim lainnya lakukan berbeda: mereka ukur utang kode dengan tools, dan utang kognitif dengan percakapan tim.

## Bagian Pertama: Utang Kode yang Terlihat Sempurna tapi Cacat

Utang kode adalah jenis yang akrab. Kode yang AI buat sering duplikasi logika yang sudah ada di tiga file berbeda, karena model AI tidak tahu logika itu ada kecuali berada dalam context window-nya. Data Sonar menunjukkan ini: 40% developer bilang AI nambah utang dengan generate kode yang tidak perlu atau duplikat.

Yang paling berbahaya bukan kode yang terlihat salah. Tapi kode yang terlihat benar. Fungsi lolos test, handle happy path dengan bersih, terlihat seperti ditulis senior engineer, except itu drop satu edge case yang versi asli tangani. Code review ketangkap typo. Tapi review sangat lemah catch fungsi yang logisnya masuk akal tapi secara diam-diam tidak lengkap.

`// AI-generated: lolos test, terlihat clean
function getActiveUsers(users) {
  return users.filter(u => u.status === "active");
}

// Yang versi asli tangani, tiga file sebelah:
function getActiveUsers(users) {
  return users.filter(u => u.status === "active" && !u.deletedAt);
}`Tidak ada error di sini. CI tidak bakal gagal. Gap baru ketahuan saat soft-deleted user muncul di laporan tiga minggu kemudian, terus orang yang on-call harus grep, blame, dan tanya sana-sini untuk tau versi mana yang benar dan kenapa. Loop grep-and-ask itu adalah biaya sebenarnya, terukur dalam jam kerja, bukan hanya "feeling off".

![Close-up of hands on a keyboard with a red-and-green code diff visible on the blurred screen behind](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-07/eaeaef-inline1.webp)

Tools docs-as-code yang langsung di sebelah repo, bukan di wiki terpisah, mengurangi loop ini terjadi. Alasan di balik setiap fungsi hidup satu klik dari fungsi itu sendiri, bukan di memori satu orang.

## Bagian Kedua: Utang Kognitif saat Tim Kehilangan Pemahaman Sistem

Dr. Margaret-Anne Storey, profesor komputer di Universitas Victoria, menciptakan istilah "utang kognitif" Oktober 2025 setelah lihat mahasiswanya ship cepat pakai AI terus kesulitan act on user feedback mereka sendiri. Diagnosisnya: mereka tidak kehilangan track kode. Mereka kehilangan track apa yang sedang dibangun dan kenapa, dan siapa di tim yang paham apa.

Ini ambil ide lama Peter Naur bahwa software sebenarnya bukan kode, tapi teori bersama di kepala orang-orang yang build. Saat kode dibuat lebih cepat daripada tim bisa build teori itu, teori tidak pernah terbentuk. Anda bisa punya codebase yang bersih, fully tested, tapi tetap punya utang kognitif signifikan jika orang yang ship tidak bisa jelaskan lengkap, atau kalau hanya satu orang yang tahu.

Ini bagian yang metrik utang teknis standar sama sekali lewatkan, karena dashboard track kode, bukan pemahaman. Pertanyaan yang worth tanya di retro Anda: buat architecture diagram, tanya siapa di tim yang bisa jelaskan setiap box. Kalau jawabannya "satu orang, dan dia sedang libur minggu ini", Anda punya utang kognitif apapun yang linter bilang.

Wiki internal yang hidup tidak fix utang kognitif sendiri. Tapi beri tim tempat tulis "kenapa" sebelum hidup di kepala satu orang, dan itu awal yang bagus.

![Three engineers standing at a whiteboard sketching a system architecture diagram together](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-07/e90110-inline2.webp)

## Kenapa Code Review Tidak Bisa Keep Up dengan Kecepatan Generasi

Ini masalah mekanis di bawah kedua utang: AI biarkan satu engineer generate satu minggu code sebelum makan siang, tapi kapasitas review tidak scale sama sekali. Bottleneck bergeser dari writing ke reading, dan reading adalah bagian yang tidak ada yang percepat. Masalah ini terakumulasi saat tim bertumbuh karena jumlah reviewer yang bisa hold mental model lengkap dari sistem semakin sedikit.

Di sini perbandingan tools benar-benar penting, dan worth be specific. Copilot dan Cursor cepat generate kode di file yang sudah Anda buka, yang persis kenapa mereka bagus produce lebih banyak kode daripada tim bisa review. Cody dan Continue.dev lean lebih pada retrieval di seluruh repo sebelum generate, yang bantu hindari duplikasi, tapi tidak satupun replace human step: decide apakah kode baru fit dengan cara sistem harusnya bekerja. Tidak satupun bilang ke Anda apakah orang merge PR benar-benar paham apa yang berubah, ini pertanyaan berbeda dari apakah diff syntactically fine.

Ask-your-codebase tools ada karena gap ini: cara tercepat review AI code dengan baik adalah bisa tanya, plain language, "di mana lagi pattern ini ada" atau "apa yang sudah handle case ini", sebelum approve merge. Dulu pertanyaan itu butuh dua puluh menit senior engineer grep dan blame. Tidak seharusnya begitu.

Ada juga effect size repo yang perlu disebut. Di service 5.000 line, satu reviewer bisa hold sebagian besar sistem di kepala, jadi fungsi masuk akal stand out karena tidak match mental model. Di monorepo 80.000 line yang disentuh enam tim, tidak ada reviewer yang punya mental model lengkap lagi, jadi kode masuk akal lolos begitu saja karena tidak ada di ruangan yang punya context untuk lihat salah. Semakin besar repo, semakin banyak review bottleneck tergantung tooling, bukan memory satu senior engineer.

## Junior Bayar Utang Ini Lebih Dulu dan Lebih Banyak

Anthropic jalanin controlled study Januari 2026, randomized trial dengan 52 junior developer, temuin yang pakai AI assistant score 17% lebih rendah di code comprehension test, roughly dua letter grade jatuh. Study longitudinal internal Infobip, jalanin internship program dari 2022 untuk 225 intern, lihat pola sama di data real: cohort pre-AI grow average 2.50 point dalam self-assessed technical skill, cohort era-AI grow 1.56. Ini perbedaan signifikan yang menunjukkan AI bisa menghambat pembelajaran jika tidak dikalibrasi dengan baik.

Mekanismenya bukan AI use itu sendiri. Dua intern di cohort terbaru Infobip pakai AI same frequency, hasil berlawanan. Satu tanya follow-up question dan bisa fully jelaskan output AI, growth mereka highest di cohort. Yang lain terima output minimal review, treat sebagai black box, growth nol. Tool identik. Relationship dengan tool beda.

![A senior engineer pointing at a laptop screen while a junior engineer leans in to follow along](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-07/ec3aa0-inline3.webp)

Recording pairing session dan architecture walkthrough, buat searchable, beri junior sesuatu untuk return ke daripada re-ask pertanyaan sama ke orang yang happen free. Tidak replace mentor, tapi turun cost tanya dua kali.

## Skip Rekomendasi "Larang AI untuk Junior"

Setiap roundup topik ini akhirnya land pada rekomendasi sama: restrict AI access junior engineer sampai mereka "earn it". Skip itu. Tidak match apa tim yang actually measure problem temuin, dan trade satu failure mode untuk lain, junior yang tidak bisa pakai tools yang team ship with jatuh tertinggal cara lain, equally real.

Yang work untuk Infobip adalah sequencing, bukan banning: coba problem dulu, check AI kedua, jadi independent thinking habit form sebelum AI jadi default move. Mereka add AI-free checkpoint, bukan punishment tapi calibration, jadi intern dan mentor tahu dimana skill actually stand. Mentor juga shift dari review PR ke track process: siapa tanya apa, siapa stuck mana, siapa jelaskan change mereka sendiri tanpa help.

Satisfaction score naik saat skill growth jatuh, itu real warning di data mereka: kalau hanya track cara orang feel tentang tools, tidak bakal lihat ini datang. Dua puluh persen intern di cohort terbaru Infobip tidak tahu apa expected dari junior engineer di level mereka di tempat pertama, buat self-assessment jadi meaningless. Tidak bisa measure gap terhadap reference point yang tidak ada yang write down.

## Apa yang Benar-benar Kita Ubah Sprint Ini

Mulai pertanyaan retro di atas: siapa bisa jelaskan setiap bagian sistem, out loud, sekarang. Satu pertanyaan ini surface lebih banyak cognitive debt dalam sepuluh menit daripada dashboard apapun.

Untuk code debt, keep static analysis di loop. [Survei developer Sonar 2026](https://www.sonarsource.com/blog/how-ai-is-redefining-technical-debt/) show 70% developer already gunakan, tim yang run report meaningfully better outcome pada rework cost daripada skip. Bukan rekomendasi controversial, hanya yang tim skip saat move cepat karena AI output terlihat done.

Toil yang AI ambil dari write code tidak hilang. Sonar sebut ini "great toil shift": reappear downstream, manage debt dan correct AI output. Automate recurring part dari triage itu, flag stale PR, route review request, chase follow-up, free senior time untuk part yang truly butuh human: decide apakah tim understand apa yang baru ship.

Measure trajectory, bukan satisfaction. Tim yang feel good tentang AI tapi tidak bisa jelaskan architecture mereka dalam enam bulan tidak save time. Borrow itu, di rate yang tidak ada orang write down.

## FAQ

### Apa perbedaan utang kode dan utang kognitif?

Utang kode adalah duplikasi dan pola inkonsisten yang bisa ditangkap static analysis tools. Utang kognitif adalah jarak antara kecepatan generasi kode AI dan kemampuan tim untuk memahami dan menjelaskan sistem. Utang kognitif tidak terlihat di linter tapi berdampak besar pada maintainability jangka panjang.

### Mengapa junior developer lebih terdampak oleh utang teknis AI?

Studi Anthropic menunjukkan junior yang pakai AI assistant score 17% lebih rendah pada code comprehension test. Data Infobip dari 225 intern menunjukkan pre-AI cohort grow 2.50 poin skill, era-AI cohort hanya grow 1.56. Ini karena junior cenderung accept output AI tanpa fully memahami atau bisa menjelaskan ulang.

### Apakah kita harus larang junior pakai AI?

Tidak. Data Infobip menunjukkan strategi sequencing lebih efektif: coba problem dulu, gunakan AI kedua. Tambahkan AI-free checkpoint untuk calibrate skill. Yang penting adalah bagaimana junior engage dengan output AI, bukan apakah mereka punya akses atau tidak.

### Bagaimana cara minimize utang teknis AI?

Untuk utang kode: gunakan static analysis tools (70% developer Sonar sudah gunakan). Untuk utang kognitif: tanya di retro siapa bisa jelaskan architecture sistem, gunakan docs-as-code, dan record pairing sessions untuk reference junior. Measure trajectory, bukan hanya satisfaction.

### Kenapa code review tidak efektif terhadap AI-generated code?

Reviewer sering tidak punya full context sistem terutama di monorepo besar. Kode yang AI generate terlihat logical tapi sebenarnya miss edge case. Solusi: gunakan ask-your-codebase tools yang bisa cari pattern di seluruh repo sebelum approve.