Yapay Zeka Kullanarak Kod Yazmanın Yan Etkileri

Table of Contents

İki aydır profesyonel hayatımda kod yazmıyorum. Artık sadece hobi olarak yazıyorum; öğrenmeye devam etmek, kod yazmayı unutmamak için. İletişim becerileri, daha iyi prompt yazmak, context yönetmek — yıllarca biriken hands-on deneyimle birleşince — bunlar birden bu kadar değerli hale geldi.

Geçen ay, normalde bir ay sürecek bir projeyi bitirdik. 2.000’den fazla sayfalık dokümantasyonla harici API entegrasyonları, testler, servisler, uygulamalar, internal entegrasyonlar. Üç günde teslim ettik. Buraya nasıl geldik?

Üşengeç Developer ve Beynin Optimizasyonu #

Bir keresinde biri demişti: “En iyi developer, en üşengeç olandır.” Ne demek istediğini hemen anlamıştım: daha az kod yaz, daha fazla sonuç al. Bunu abstraction yoluyla yapmaya çalışan developerlar tanıdım; hâlâ varlar, ama o ayrı bir konu. Asıl vurgulamak istediğim şu: bu söz, beynimizin nasıl çalıştığıyla birebir örtüşüyor.

Beyin her eylemi ve sonucunu haritalar. Daha önce yaşadığımız hormonal ödülü yeniden üretmek için aynı nöronları ateşler. Bu pattern basit, ama alışkanlıklarla, kazanımlarla ve emekle doğrudan bağlantılı.

Yani “daha az emek, daha fazla sonuç” sadece tembellik değil — beynin doğal optimizasyon stratejisi.

Yeni Bir Pattern: Notepad’den IDE’ye #

Neden buna giriyorum diye sorabilirsiniz. Basit: yeni bir patternle karşı karşıyayız.

Text editor’da kod yazdığın dönemde her şeyi ezberlemek zorundaydın — her fonksiyonu, her paketi, neyin ne işe yaradığını. Sonra IDE’ler bu bilgiyi basit bir hover ile önüne koymaya başladı. Yavaş yavaş ezberlemeyi bıraktın. list. yazıp “bakayım hangi method’lar var” diye düşünür, seçenekleri kaydırır, tıklayarak seçerdin. Belki hiç yazmayı da bıraktın.

Ardından shortcut’lar geldi: “replace all”, “rename in all occurrences.” Bu feature’lar işini kolaylaştırdı, seni tatmin etti. “Vay be, bunu elle yapsaydım ne kadar uzun sürerdi” dedin. Ve o anda ezberden yazma becerisini kaybettin.

Bu seni yetersiz bir developer yapmadı. Kodu sen yazdın — sadece biraz yardım aldın. Text editor’dan IDE’ye geçtin.

Ama bu geçiş sadece araç değişikliği değildi. kas hafızası nın ilk erozyonuydu. Nokta yazıp autocomplete beklemek, ezberden yazmaktan daha hızlıydı; ama trial-and-error sürecini de dış kaynağa devretmiş oldun.

IDE’den Agentic Development’a: Semantic Seviyede Çalışmak #

Bir kısmımız, Copilot’lu IDE’lerden agentic development ’e geçti. Aynı tatmini, aynı shortcut’ları yaşamaya başladık. “Replace all” → “tüm mantığı değiştir” oldu. “Find all” → “bu mantığı bul” oldu. Artık keyword aramıyoruz; anlam arıyoruz.

LLM ’ler tam da burada hayatımızı dönüştürmeye başladı. Bu devrim o kadar derin ki artık tek bir satır kod yazmadan logic’i açıklayabilir, tartışabilir, sonuçları analiz edebilir, üzerinde iterasyon yapabilir ve tam istediğini elde edebilirsin.

Artık keyword seviyesinde çalışmıyoruz. Semantic seviyede çalışıyoruz.

Vibe Coder: Kod Yazmayan Developer #

İşte buyur: “En iyi developer en üşengeç olandır” sözü artık “en iyi developer kod yazmayandır"a evrildi. Eğer ilk başta evet üşengeç developer iyi developer dediysen, vibe coder kavramı sana düşündüğünden daha yakın.

Artık kodun içinde değiliz — kodun üstündeyiz. Bu uçurumdan atladığın an sonsuz bir loop’un içinde buluyorsun kendini; özellikle LLM’leri assistant olarak değil, yönetilen araçlar olarak kullanmaya başladığında. Şunu kastediyorum: gereksinimleri ve kuralları tanımlayabilir, tüm işi agent’lara devredebilir, testleri başka bir agent’a gönderebilir, development’ı başkasına, proje yönetimini bir diğerine — ve kendi başına bütün bir ekibe dönüşebilirsin.

Ama artık kodun içinde değilsin. Kodun üstündesin.

Teori Pratiğin Önüne Geçiyor #

“Daha iyi kod” ya da “daha güvenli kod"dan hâlâ bahsetmediğimizi fark ettiniz. Çünkü bu beceriyi kaybediyoruz. Teoriyi öncelik haline getirip pratiği bırakıyoruz.

Bu gidiş bizi conversational analysis’e doğru itecek: “Bu kod yeterince memory-efficient mi?” “Bu kod fazla CPU cycle harcıyor mu?” “Burada gereksiz bir roundtrip var mı?” Artık “bu variable X kez allocate edildi” ya da “bu function Y cycle kullandı” demeyeceğiz. Kodu biz yazmıyoruz, geliştiricisi değiliz ve neden yazıldığını bilmiyoruz. Sadece söyleneni biliyoruz. Sadece sonucu biliyoruz. Process’in içinde bile değiliz.

Oyun değişiyor, biz de değişiyoruz. Ama bu değişimi kontrol etmezsek, sadece sürükleneceğiz.

Pratik Bilgi Yok Oluyor #

Günün sonunda çok şey kaybedeceğiz. Bir aylık işi bir günde bitiren developer’a artık kod yazdıramazsınız. Bugünün dünyasında proje gereksnimleri karşılandığı ve para akışı sürdüğü sürece endüstri detaylara bakmıyor. Asıl sorun tam da burada başlıyor.

Zor kazanılan pratik bilgimiz yok oluyor. Soft skill’lerde, architecture’da, teoride uzmanlaşırken labor’u dışarıya veriyoruz. Dezavantajı? Kod yazamayan expert developer’lar oluyoruz — ya da yetiştiriyoruz. REST API ile GraphQL’in development süreçleri arasındaki farkı bilmeyeceğiz; sadece “hangisi bize ne sonucu veriyor"u bileceğiz.

Ouroboros: Kendi Kuyruğunu Yiyen Yılan #

Bu hikayeyi beş yıl önce anlatsaydım, kendim de inanmakta zorlanırdım. Ne önem taşıyacak? Nasıl tutunacağız? Elimizde ne kalacak?

Elimizde bir Ouroboros kalıyor.

LLM’ler, insan developer’ların yazdığı kod üzerinde eğitildi. Şimdi LLM’ler kod yazıyor. Yeni nesil LLM’ler o kodla eğitilecek. Sonra o yeni model’lerle daha fazla kod üretiyoruz. Loop devam ediyor.

Bu cycle’da shortcut’lar, security vulnerability’ler ve technical debt birikecek. Düşük kaliteli, kötü kontrol edilmiş test’lerle güncellenen package’lar ciddi performance degradation’a, daha fazla data breach’e ve daha büyük hasara yol açacak.

Kısa vadede ciddi kâr üretecek bu. Ama orta vadede collapse’a götürecek. Beş yıl sonra ne diyeceğiz? Bugün inanmakta zorlandığımız ne olacak?

Ne Yapmalıyız? #

Şu an her developer becerilerini korumaya odaklanmalı. Kaybediyoruz onları.

LLM’leri thinking process’ini hızlandırmak için kullan, cevap almak için değil. Direkt sonuç isteme; “bunu nasıl düşünmeliyim?” diye sor.
LLM’leri araştırmanda assistant olarak kullan, manager olarak değil. Prototype ve architecture kararlarını kendin ver. Deneyim kazan — kaybetme.
Kod yazma becerisini kaybetme. Acımasız, hızlı iş döngüsünde kendini yitirme. Codewars, LeetCode gibi platformlarda skill’lerini keskin tut.
Yeni bir şey öğrenirken documentation’ı ve source code’u oku. Model’lere özetlettir, ama proof of concept’i kendin yaz.
Cybersecurity’e öncelik ver. LLM’lerin ürettiği kodda security vulnerability ihtimali yüksek.
Output’u analiz etmeye odaklan. Observability ve performance analysis yapabilmen gerekiyor.

Baltanın en iyi nasıl bilenebileceğini öğreniyoruz ama kas hafızasını kaybetmemeliyiz.