Yapay Zeka Teknik Borcu: Kod Borcu vs Bilişsel Borç

Yapay Zeka Teknik Borç İki Farklı Sorundur, Biri Değil

Yapay zeka teknik borcu, düşündüğünüz kadar basit değildir. Bu sadece bir linterin işaretleyebileceği yinelenen fonksiyonlar ve tutarsız adlandırma değildir. Bunun yarısı pull request'te tamamen iyi görünür, review'dan geçer, deploy edilir ve altı hafta sonra takımda kimsenin neden bir yerde yapılan bir değişikliğin beklenmeyen üç şeyi bozduğunu açıklayamadığı zaman ortaya çıkar. Bu ikinci yarısı, çoğu takımın hiç ölçmediği kısımdır.

Yapay Zeka Teknik Borcu İki Farklı Sorun Kategorisine Ayrılır

Beş mühendislik müdürünü sıra ile sorsanız, yapay zeka teknik borcunu tanımlamak için beş farklı cevap alırsınız. Ama bu cevaplar iki oldukça farklı kategoriye toplanma eğilimindedir.

Birincisi kod borcu: tekrarlı fonksiyonlar, tutarsız kalıplar, teknik olarak doğru ama kimsenin istemediği yüzey alanı ekleyen kod. Bu kategori static analysis araçlarının inşa edildiği yerdir.

İkincisi ise bilişsel borç: kod ne kadar hızlı generate edilirse edilsin, takımın bunu ne kadar hızlı anlayan paylaşılan bir zihin modeli oluşturma arasındaki fark. Sonar'ın 2026 geliştirici anketine göre, geliştiricilerin yüzde 88'i yapay zekanın teknik borca en az bir olumsuz etkisini bildirmekte; yüzde 53'ü yapay zekanın doğru görünen ama gizli kusurlar içeren kod ürettiğini söylemektedir. Bu kod borcudur. Anketin tam olarak açmadığı şey ikinci kategoridir ve LeadDev'in bu kavram üzerine yaptığı haber reportajı, okuduğumuz en net açıklamadır.

Beş takımdan üçü bu ikisini karıştırır. Diğer ikisinin yaptığı şey farklıdır: kod borcunu araçlarla takip ederler, bilişsel borcu ise konuşmalarla takip ederler.

Kod Borcu Kısmı: Doğru Görünen Ama Olmayan Kod

Kod borcu, tanıdık kategoridir. Yapay zeka generate kodu, bu mantık zaten üç dosya ötede var olduğunu bilmediği için mantığı tekrar eder. Sonar'ın anketinde buna rakam konmuş: geliştiricilerin yüzde 40'ı yapay zekanın gereksiz veya yinelenen kod üretmek suretiyle borcu artırdığını söylemektedir.

Tehlikeli varyant, yanlış görünen kod değildir. Doğru görünen koddur. Bir fonksiyon testlerini geçer, happy path'i temiz şekilde işler ve kıdemli bir mühendist tarafından yazılmış gibi okuna dursa bile, sessiz sedasız orijinal implementasyonun işlettiği bir uç durumu bırakır. Review yazım hatalarını yakalar. Review, inandırıcı görünen fakat hafifçe eksik olan bir fonksiyonu yakalamada çok daha kötüdür.

// Yapay zeka generate: testleri geçer, temiz görünür
function getActiveUsers(users) {
  return users.filter(u => u.status === "active");
}

// Orijinal, üç dosya ötede, işlediği şey:
function getActiveUsers(users) {
  return users.filter(u => u.status === "active" && !u.deletedAt);
}

Burada hiçbir hata fırlatılmaz. CI başarısız olmaz. Boşluk ancak yumuşak silinmiş bir kullanıcı üç hafta sonra bir raporda yeniden göründüğü zaman ortaya çıkar ve sayfa görevlisi olan kim varsa hangisi doğru ve neden diye bulmak için grep, blame ve etrafı sormak zorunda kalır. Bu grep-ve-sor döngüsü gerçek maliyettir ve belirsiz bir şekilde "bir şey yanlış hisset" de değil, saat cinsinden ölçülebilir.

Repo'nun yanında ayrı bir wikide yaşamak yerine kod-olarak-dökümanlar araçları, bu döngünün ne kadar sık olduğunu azaltır, çünkü bir fonksiyonun arkasındaki mantık, birinin hafızasında yaşayan yerde yerine, fonksiyonun kendisinden bir tık uzakta yaşar.

Bilişsel Borç Kısmı: Takım İçin Konu Kaybı

Dr. Margaret-Anne Storey, Victoria Üniversitesi bilgisayar bilimleri profesörü, Ekim 2025'te öğrencilerinin yapay zeka ile hızlı şekilde deploy ettiğini fakat kendi kullanıcı geri bildirimlerine göre hareket etmekte zorluk çektiğini izledikten sonra "bilişsel borç" terimini ortaya attı. Onun tanısı: öğrenciler kodu kaybetmemişlerdi, inşa ettikleri şeyi ve neden inşa ettiklerini kaybetmişlerdi ve takımda kimin neyi bildiğini kaybetmişlerdi.

Bu çerçeve, Peter Naur'un eski argümanından alınmıştır: yazılım aslında kod değil, onu inşa eden insanların kafalarındaki paylaşılan teoridir. Kod, takımın bu teoriyi inşa edebileceğinden daha hızlı generate edildiğinde, teori asla oluşmaz. Temiz, tamamen test edilmiş bir kod tabanınız olabilir ve yine de eğer onu deploy edenleri tam olarak açıklayamıyorsanız veya sadece bir kişi açıklayabiliyorsa, önemli bilişsel borcunuz vardır.

Bu, standard yapay zeka teknik borç metrikleri tarafından tamamen kaçırılan kısımdır çünkü panolar kodu takip eder, anlama değil. Sonraki retro'nuzda sorsanız gereken soru açıktır: bir mimari diyagram ortaya koyun ve takımda kaç kişi her bir kutuyu açıklayabiliyor. Eğer cevap "bir kişi, ve o bu hafta tatile gitmiş" ise, linteriniz ne dese de, bilişsel borcunuz vardır.

Canlı bir internal wiki, bilişsel borcu tek başına düzeltmez. Takıma, bunu bir kişinin kafasında sadece yaşadığı olmadan önce "neden" u yazması için bir yer verir ki bu bir başlangıçtır.

Neden Kod Review Üretim Hızıyla Yetişemez

İşte her iki borç türünün altında yatan mekanik problem: yapay zeka tek bir mühendisi öğleden önce bir haftalık kod generate etmesini sağlar, fakat review kapasitesi hiçbir şekilde ölçeklenmemiştir. Darboğaz yazıdan okumaya taşındı ve okuma, hızlandırılan kısım değildir.

Burada araç karşılaştırması gerçekten önemlidir ve belirsiz yerine belirli olunması değer. Copilot ve Cursor, halihazırda açık olduğunuz dosyanın içinde kod generate etmek açısından hızlıdır ki bu tam da yukarıdaki yineleme sorununu daha fazla kod üretmek açısından neden iyi oldukları. Cody ve Continue.dev, generate etmeden önce repo'da retrieval'ye daha fazla yaslanırlar ki bu yineleme sorununu azaltmaya yardım eder, ama hiçbiri PR'ı merge eden kişinin aslında ne değiştiğini anlayıp anlamadığını söylemez, bu sözdizimsel olarak ince mi ince sorusu farklı.

Kod tabanınıza sorgula araçlarının gerçek değeri burada ortaya çıkar. İyi tasarlanmış bu araçlar, reviewer'ın düz İngilizcede sorabilmesini sağlar: "bu pattern başka nerede var", "bu durumu zaten kim işler", "bu değişiklik hangi çağrı alanlarını etkiler". Bu sorular eskiden kıdemli bir mühendiste yirmi dakika grep ve blame'i alırdı, artık saniyeler içinde yanıt alabilirsiniz. Büyük repo'larda bu fark hayati hale gelir.

Kod tabanınıza sorgula araçları bu boşluktan tam olarak dolayı varlar: yapay zeka generate kodu iyi review etmenin en hızlı yolu, düz İngilizcede sormak "bu pattern başka nerede vardır" veya "hangisi zaten bu durumu işler" yapabilmektir, merge'i onaylamadan önce. Bu soru eskiden kıdemli bir mühendiste yirmi dakika grep ve blame'i alırdı. Artık almaması gerekir.

Repo-size etkisi de adlandırılmaya değer. 5.000 satırlık bir serviste, bir reviewer sistemin çoğunu kafasında tutabilir, bu yüzden inandırıcı görünen bir fonksiyon ön plana çıkar çünkü reviewer'ın zihin modeliyle eşleşmez. 80.000 satırlık bir monorepo'da altı takım tarafından dokunulmuş şekilde, hiçbir tek reviewer o zihin modelini artık tutmaz, bu yüzden inandırıcı görünen kod sadece odadaki kimsenin bunun yanlış olduğunu fark etmek için bağlamı olmadığı için geçiverir. Repo ne kadar büyükse, review darboğazı o kadar bir kıdemli mühendist hafızası yerine takım görevli olmasına bağlı olur.

Juniorlar Bu Borcu İlk ve En Hızlı Öderler

Anthropic Ocak 2026'da kontrollü bir çalışma yaptı - 52 junior geliştirici ile bir randomize deneme ve yapay zeka yardımcıları kullananlarda kod kavrayış testlerinde yüzde 17 daha düşük skor buldu, kabaca iki harf notu. Infobip'in iç mühendislik takımı, 2022'den beri 225 intern üzerinden bir staj programı yürütüyor ve gerçek uzun süreli veriler içinde aynı deseni gördü: yapay zeka öncesi yoğunlaştırma, staj üzerinde kendi kendini değerlendiren teknik becerinde ortalama 2,50 puan büyüme; yapay zeka çağı yoğunlaştırması 1,56.

Mekanizm yapay zeka kullanımının kendisi değil. Infobip'in en son yoğunlaştırması içinde iki intern, yapay zekayi aynı sıklıkta kullandı, zıt sonuçlar. Biri takip soruları sordu ve yapay zekanın ürettiğini tam olarak açıklayabildi; onların büyümesi yoğunlaştırma içinde en yüksek oldu. Diğeri minimal review ile çıktıyı kabul etti, bunu bir kara kutu olarak ele aldı ve sıfır büyüdü. Araç aynıydı. Ona olan ilişki değildi. Sadece mühendislik becerisi değil, sorumluluk duygusunun da bu fark oluşturduğunu görmek önemlidir. Bağımsız düşünme alışkanlığı oluştururken yapay zekayi araç olarak kullanmak ve araç olarak yapay zekaya bağlı olmak arasındaki fark sonraki yıllar boyunca birikilir.

Pairing oturumları ve mimari walthrough'ları kaydedip, daha sonra aranabilir hale getirmek, junior'lara aynı soruyu kim serbest kaldığına yeniden sormak yerine geri dönecek bir şey verir. Bir mentorü yerine almayacak, ama ikinci kez sormanın maliyetini azaltır.

"Junior'lar için Yapay Zeka Yasakla" Çözümünü Atla

Bu konudaki her akış yazısı sonunda aynı öneriye varır: "kazandıkları kadar" junior mühendisler için yapay zeka erişimini kısıtlayın. Bunu atla. Sorunun gerçekten ölçen takımlar bulduğu ile eşleşmez ve bir başarısızlık modunu başka bir, eşit derecede gerçek bir için değiştirir; araç seti yaşarken yapay zekayi kullanamayan junior'lar farklı ve eşit şekilde geri kalır.

Infobip için bunun yerine işe yarayan şey yasaklamak değil, sıralamak oldu: sorun ilkini dene, yapay zekayi ikinci olarak kontrol et, bu yüzden bağımsız düşünme alışkanlığı yapay zeka varsayılan hareket olmadan önce oluşur. Ceza değil, kalibrasyon olarak yapay zeka-serbest kontrol noktaları eklediler, bu yüzden hem intern hem de mentor seviyeleri nerede beceri gerçekten duruyor bilirler. Mentorlar da pull request review'dan süreç takibine geçtiler: kim ne sordu, kim nerede takıldı, kim kendi değişikliğini yardım olmadan açıklamadı.

Memnuniyet skoru tüm bu süre beceri büyümesi düşüyorken arttı, bu da gerçek uyarıdır: sadece insanlar araçlar hakkında nasıl hissettiklerini takip ediyorsanız, bunu gelemiyor olmaz. Infobip'in en son yoğunlaştırması içinde yüzde 20 intern, seviyeleri ne bekleneceğini bilmiyorlardı ilk yerde, ki bu kendi kendini değerlendirmeyi hiçbir referans noktası karşı istifa ettiriyor. Kimsenin yazmadığı referans noktaya karşı bir gap ölçemezsiniz.

Bu Sprint'te Gerçekten Ne Değiştireceğimiz

Yukarıdaki retro sorusuyla başla: şu an sistemin her bir kısmını açıklanabilir mi, yüksek sesle. Bu tek soru, herhangi bir panoya göre on dakikada daha fazla bilişsel borç yüzeyine çıkartır.

Kod borcu için, statik analizi döngüde tutun. Sonar'ın 2026 geliştirici araştırması yüzde 70 geliştiriciyi halihazırda kullandığını gösteriyor ve onu çalıştıran takımlar rework maliyeti açısından onu atlayan takımlara göre anlamlı derecede daha iyi sonuçlar bildiriyor. Bu tartışmalı bir tavsiye değil, takımlar hızlı hareket ettikleri zaman onu atlıyor çünkü yapay zeka çıkışı hazır görünüyor.

Yapay zekanın yazı kodundan çıkardığı toil yok olmaz. Sonar bunu "büyük toil kaydırması" deniyor: aşağı akış, borç yönetiminde ve yapay zeka çıkışını düzeltmede yeniden ortaya çıkar. Bu sıralama'nın tekrar eden kısımlarını otomatikleştirmek, eski PR'ları işaretlemek, review isteklerini yönlendirmek, takipleri sürüklememek, kıdemli zamanı gerçekten insan gerektiren kısım için serbest bırakır: takımın az önce deploy ettiğini anlayıp anlamadığını karar vermek.

Memnuniyet değil, yörüngeyi ölçün. Yapay zekayla iyi hisseden ve altı ay içinde kendi mimarisini açıklayamayan bir takım zamanı kazanmamış. Onu ödünç aldı, kimsenin yazmadığı bir oran üzerinden.