- Geliştiricilerin AI kodlama araçlarını yaygın biçimde kullanmasıyla üretkenlik artmış olsa da, görünmeyen bilişsel ve organizasyonel maliyetler ortaya çıkıyor
- Başlangıçtaki Copilot ve Cursor gibi yardımcı araçlardan, son dönemde otonom ajanlara evrilerek insanın AI'ya yardım ettiği bir yapıya geçildi
- Ancak tam yetki devrine dayalı kullanım, bilişsel borç (cognitive debt) ve debugging becerisinde düşüşe yol açarak geliştiricilerin problem çözme ve kodu anlama yetisini zayıflatıyor
- AI'nın yazdığı kodun yalnızca insanlar tarafından gözden geçirildiği yapı, kıdemli yetiştirme yolunun çökmesine ve yaratıcı akışın (flow) kaybına neden olarak organizasyonun teknik kapasitesini uzun vadede aşındırıyor
- AI kullanımı zorunlu hale geliyor, ancak “uygun kullanım eşiğini” kişinin kendisinin belirlemesi ve bunu insanın anlama ile öğrenmesini koruyacak şekilde ayarlaması gerekiyor
AI kodlama benimsenmesinin evrimi
- 2022~2023'te ortaya çıkan Copilot ve Cursor gibi araçlar, kod tabanını indeksleyerek bağlama dayalı otomatik tamamlama ve sohbet özellikleri sundu
- Google'da arama yapmak veya StackOverflow'da aramak gereksiz hale geldi ve AI yerleşik IDE ortamı yaygınlaştı
- Sonrasında ortaya çıkan ajan tabanlı workflow, insan destekli modelden AI öncülüğündeki geliştirmeye geçişi temsil etti
- Ancak ajanlarda döngü, halüsinasyon ve bağımlılık hataları gibi nedenlerle güvenilirlik sorunları yaşanıyor
- Opus 4.5 sonrasında otomasyon seviyesi yükselirken, bazı şirketlerde geliştiricilerin doğrudan kod yazmadığı örnekler de görülmeye başlandı
- Örnek: Spotify'ın eş CEO'su, mühendislerin Slack'te Claude'a komut vererek özellik değişikliği ve dağıtımı yaptığını söyledi
Bilişsel borç ve beceri körelmesi
- Manfred Spitzer'ın 'Digital Dementia' ve Margaret-Anne Storey'in 'Cognitive Debt' kavramlarına atıf yapılıyor
- Tekrarlayan düşünme süreçleri AI'ya devredildiğinde beyindeki yollar zayıflıyor ve kodu anlama yetisi azalıyor
- Shen ve Tamkin (2026) araştırması: 52 geliştiriciden oluşan grupta, AI destekli grup kavramsal anlama, debugging ve kod okuma becerilerinde %17 daha düşük puan aldı
- Özellikle debugging becerisindeki düşüş belirgindi; yalnızca 1 saatlik pasif AI kullanımıyla bile ölçülebilir beceri aşınması görüldü
- AI zorlu görevleri geliştirici yerine üstlendiğinde, “gerçek akış (flow)” yerine “dark flow” durumu ortaya çıkarak öğrenme olmadan yalnızca bağımlılığı güçlendiriyor
Kod inceleme paradoksu ve kıdemli çöküşü
- AI kodu yazıp insan yalnızca gözden geçirdiğinde, inceleme becerisinin kaynağının ortadan kalktığı bir paradoks oluşuyor
- AI'ya bütünüyle bağımlı geliştiriciler hızlı çalışsa da değerlendirme puanları en alt sırada kalıyor
- Storey, “dağıtımdan önce AI tarafından üretilen değişikliklerin insan tarafından tamamen anlaşılması gerektiğini” öneriyor
- AI, yeni başlayanlara kıdemli seviyesinde çıktılar sunuyor; ancak bu, anlama olmadan yapılan bir kopyalamadan ibaret
- Kıdemliler kodu doğrudan yazmadıkça derinliğini kaybediyor, junior'lar ise deneme-yanılma yaşamadan gelişemiyor
- Sonuç olarak kıdemli yetiştirme hattı çöküyor
Yönetimin yanlış hesapları ve organizasyonel yan etkiler
- Microsoft, Anthropic, Google gibi şirketlerin yöneticileri, AI'nın birkaç ay içinde mühendislerin yerini alacağını öngörüyor
- Google, 2024 sonu itibarıyla yeni kodun %50'sinin AI tarafından üretildiğini bildirdi
- Ancak bu tür sayılar, AI satışı ve hisse fiyatlarını destekleme amacıyla abartılmış olup sıradan organizasyonlara uygulanamaz
- Bazı şirketler AI kullanım miktarını KPI olarak ölçüyor ve bunu geliştiricilere dayatıyor
- Reddit örneği: geliştiriciler anlamsız komutlarla AI kullanım miktarını manipüle etti
- Sonuçta Goodhart yasası devreye giriyor; üretkenlik artışı yerine yalnızca biçimsel uyum kalıyor
İnsani maliyet ve yaratıcılığın kaybı
- Kod yazmak odaklanma ve yaratımın verdiği keyfi sunarken, AI kodunu gözden geçirmek zihinsel yorgunluk yaratıyor
- Yaratımın dopamin ödülü kaybolduğunda tükenmişlik hızlanıyor
- Geliştirme işi kalite güvencesine (QA) indirgeniyor ve yaratıcı tatmin yok oluyor
- Bu durum, AI'nın tüm sanatı üretip insanın yalnızca çamaşır katladığı bir senaryoya benzetiliyor
Uygun AI kullanım eşiği
- AI güçlü bir araç, ancak az ya da çok kullanmak tek başına iyi değildir
- Shen ve Tamkin araştırması, 6 AI etkileşim örüntüsü içinde,
- 'tam yetki devri, kademeli bağımlılık, debugging'i devretme' biçimlerinin öğrenmeyi engellediğini
- 'açıklama isteme, kavramsal soru sorma, bağımsız kodlamadan sonra doğrulama' biçimlerinin ise öğrenmeyi koruduğunu gösteriyor
- Esas mesele bilişsel katılımı sürdürmek; önemli olan sadece kullanıp kullanmamak değil, nasıl kullanıldığı
- AI hiç kullanılmazsa arama, boilerplate ve keşif verimliliği kaybediliyor;
aşırı kullanılırsa anlama yetisi, kıdemli yetiştirme, hata tespiti ve akış hissi zarar görüyor
Sessiz gerileme
- Göstergelerde PR sayısı, özellik sayısı ve cycle time iyileşiyor gibi görünse de,
içsel teknik yetkinlik, odaklanma ve problem çözme becerisi yavaş yavaş zayıflıyor
- Geliştiriciler, AI'nın kurduğu yapıyı anlamadan sadece onay düğmesine basan birer 'butter robot'a dönüşüyor
- Simon Willison da bir projede AI'nın ürettiği özelliği gözden geçirmediği için
“artık iç işleyişi net biçimde anlamadığını” söyledi
- Sonuçta araç değil insan köreliyor ve bu değişim ne ölçülüyor ne de yönetiliyor
- AI bağımlılığı bir tür alışkanlık gibi ilerleyerek, sessiz ama gerçek bir teknik gerilemeye yol açma riski taşıyor
1 yorum
Hacker News görüşleri
Benim için hâlâ kodu bizzat yazma ve yapıyı zihnimde kurma süreci, işimin keyifli yanlarından biri
Tekrarlayan ya da can sıkıcı refaktörler bile benim için anlamlı bir süreç
Bu zorlu anlar, bir dahaki sefere daha iyi bir yol bulmamı sağlayan bir öğrenme malzemesi oluyor
Bir gün bu akışın yeniden geri döneceğine dair bir umut olarak kalıyor
Bir gün kendi başına seçme ve yargıda bulunma becerisini koruyan insanların değerinin yeniden anlaşılacağına inanıyorum
Test etmesi zorsa, soyutlamayı ya da arayüzleri değiştirmen gerekir
Testler kodun ilk yeniden kullanımıdır; testte rahatsız ediciyse gerçek kullanımda da rahatsız edici olacaktır
Kod bana ait olduğunda, sorunun nerede çıkabileceğini zihnimde canlandırmak daha kolay oluyor
LLM ne kadar log fırlatırsa fırlatsın bu sezginin yerini tutamıyor
Ama bunun, frontend ekosistemini iyileştirme motivasyonunu ortadan kaldırmasından endişe ediyorum
İnsanların LLM’ye devretmek istediği işleri bile kendim yapmak bana keyif veriyor
Şirketlerin bu küçük keyifleri yavaş yavaş elimizden almasını görmek üzücü
Son 1 yılda Claude Code’u çok kullandım ve son zamanlarda ekip arkadaşlarım arasında AI kullanımına dair duygusal bir değişim hissettim
AI’ın aşırı kullanımında ortaya çıkan gizli maliyetler hakkında bir yazı yazdım ve çeşitli kaynaklardan veri topladım
Henüz net veriler yok ama birçok geliştirici benzer şeyler hissediyor gibi görünüyor
Ama “yazılım sadece bir araçtır” ifadesi bana her zaman tuhaf gelmiştir
Bir araç düşünmenin yerini alabiliyorsa, ona hâlâ “araç” diyebilir miyiz?
“Prompt bağımlılığı” gibi dürüst bir ifade hoşuma gitti. Ama davranışsal bağımlılık yönü de incelenebilir
Hızlı ve kontrollüymüş gibi geliyor ama yavaş yavaş kontrolü kaybediyorsun
Asıl zor olan, “bunu ne kadar sürdürülebilir bir hızda kullanmalıyım” sorusunun cevabını bulmak
Ben de benzer konuda bir blog yazısı yazdım,
ama meseleyi liderlerin organizasyonun sürdürülebilir bir denge bulmasına nasıl yardımcı olabileceği açısından ele aldım
Çalışma belleği (working memory) ile ödül sisteminin öğrenme ve odaklanma üzerindeki etkisine dair makalelere baktım
Örneğin bu Nature makalesi, çalışma belleğinin dopamin tepkiselliğiyle ilişkili olduğunu söylüyor
Ayrıca bu Scientific American yazısı, elle yazmanın daha fazla beyin bölgesini etkinleştirdiğini anlatıyor
Sonuçta düşük ödüllü, pasif işler söz konusu olduğunda bu bilişsel faydalar neredeyse hiç oluşmuyor
Bu yüzden AI kullanımının ölçütü olarak “ne kadar acı verici ve ne kadar düşük ödüllü bir iş olduğu”nu almak mantıklı geliyor
Ben hâlâ kodu kendim yazıyor ve sonucunu tamamen anlıyorum
Hız artışı falan umurumda değil. Önemli olan bunun benim kodum olduğuna dair sahiplik hissi
Eskiden de dışarıya yaptırabilirdim ama bu, beni kodu sadece okuyan birine dönüştüren yol olurdu
Ben ve çevremdeki çoğu geliştirici bu baskıyı hissediyoruz
Klavye kullanınca el yazısını unutmuyoruz, kahve satın alınca da kahve yapmayı unutmuyoruz
80’lerin başında LSI-11 assembly ile kod yazmayı öğrenirken tüm sekizlik opcode’ları ezberlemiştim
Ama FORTRAN 83 öğrenince üretkenliğim 10 kat arttı ve o dönemin becerileri körelse bile buna hiç üzülmem
Bir gün C++ ya da Java gibi diller de aynı şekilde gereksiz hale gelmiş beceriler olacak
Opcode’larla uğraşırken geliştirdiğin mantıksal düşünme becerisi, sonraki dilleri öğrenmeni kolaylaştırdı
Böyle biçimsel dilleri (formal language) kullanmayı gerektiren düşünme tarzı, LLM prompt yazmaktan bilişsel olarak çok daha derin
ama AI ile işbirliği, niyeti muğlak doğal dille aktarma süreci
İngilizce sözde kod yazmıyorsan doğruluk düşüyor
Üstelik bu kez buna yerinin doldurulabileceği korkusu da eşlik ediyor
AI’ı uygun şekilde kullanmanın üç paterni korunursa hem üretkenlik hem öğrenme kazanılabilir
Ama anti-pattern izlenirse araç bağımlılığına, kaygıya, debugging becerisinde düşüşe ve anlık ödül bağımlılığına yol açar
Sonunda bilişsel körelmenin kısır döngüsü oluşur
Kısa süre önce AI merkezli bir şirkete girdim ve elle kod yazmak neredeyse yasak gibi
Claude’a API dokümantasyonunu okutup bir wrapper oluşturdum; ortaya çıkan sonuç kusursuzdu
Ama ben API’nin hissini ya da yapısını hiç kavrayamadım
Bu şekilde “çok şey yapabiliyor ama hiçbir şey bilmiyor olma” hali rahatsız edici ve boş hissettiriyor
Refleksif hafıza birikmiyor. Bu yüzden yazıdaki söylediklerine derinden katılıyorum
Çeşitli AI tarafından yazılmış yan projeler üzerinde çalışıyorum
Yine de bu, “iyi olduğunu düşünüyorum ama emin değilim” gibi tuhaf bir duygu
Sonuç olarak, AI ile birlikte üretsen bile tatmin duymak için içine kendi izini bırakman gerekiyor
Kodlamaya başlayalı daha 8 ay oldu ve AI sayesinde öğrendim
Ama Claude kod yazdığında bunun sadece %70’ini anlıyorum, geri kalanıysa öylece geçip gidiyor
Bu hız hissi bağımlılık yapıyor ama bütün yapıyı zihinde tutma becerisi zayıflıyor
Yine de AI olmadan şu anki çıktıları üretemezdim; bu trade-off’u kabul ediyorum
Örneğin gereksiz fallback kodunu fazla kullanıyor
Deneyimin yoksa bunun yanlış olduğunu fark etmeyebilirsin
Mevcut LLM seviyesi yaklaşık stajyer~junior geliştirici düzeyinde
Darboğaz model değil, bizim doğrulama becerimiz
Sırf boilerplate otomasyonu için LLM kullanmak gerçekten gerekli mi emin değilim
Bunu mevcut metaprogramming ya da script’lerle de rahatça yapmak mümkün değil mi?
Ayrıca AI’ı ilkesel olarak reddetmek de kendi içinde tatmin edici bir tercih olabilir
Fare ve klavye kullanımı, dosya gezintisi, komut arama gibi temel konularda zayıflık var
Bu yüzden “gidelim LLM’ye soralım” cazibesi büyüyor
Ama gerçek çözüm, araç hâkimiyetini artırmak ve template engine öğrenmek
AI yüzünden beceri körelmesi olabilir,
ama bu benim odaklandığım alan değilse sorun etmiyorum
Örneğin derleyicinin iç optimizasyonlarını bilmek zorunda değilim
Sistemler arası etkileşimi anlamak için bir miktar derleyici çalışma mantığını da bilmek gerekiyor
Kafaya takmak istemediğin kısımları LLM’ye bırakıp,
gerçekten önemli sorunlara zihinsel kaynaklarını odaklamak