Artık kod yazmıyoruz — review yapıyoruz

Yazılım geliştirme, son birkaç yılda görünür biçimde değişti. Ama bu değişim ne yazılımın ortadan kalkması, ne de mühendisliğin gereksiz hale gelmesi anlamına geliyor. Değişen şey pratiğin kendisi.

Yapay zeka destekli kod üretimi, artık küçük bir araç eklentisi değil — geliştirme sürecinin merkezinde. Claude Code gibi komut satırı arayüzleri, Cursor ve Copilot gibi editör entegrasyonları, Gemini Gems ve Claude Projects gibi bağlam yönetimi araçları; bunlar çoğu ekibin günlük iş akışının parçası haline geldi.

Bu araçların var olduğunu bilmek ile onları doğru kullanmak arasındaki fark, projenin çıktısını doğrudan etkiliyor. Ve bu fark, teknik bilgisi olan için de olmayan için de geçerli.

Mesele artık "AI kod yazar mı?" değil. Yazar. Asıl soru şu: Siz ne yapıyorsunuz?

"AI halleder" — bu tam olarak nerede kırılıyor?

Yeni bir araç çıktığında ortaya çıkan ilk tepki hep aynı: abartma ya da reddetme. Yapay zekalı kod üretimi de bu iki kutuptan birinde karşılandı.

Abartma tarafı şunu söylüyor: "Artık geliştirici gerekmez, AI her şeyi yazar." Reddetme tarafı ise: "Gerçek mühendis AI kullanmaz, güvenemezsin." İkisi de meselenin yanında duruyor.

Gerçekte olan şu: Yapay zekâ, iyi tanımlanmış bir görevi hızlı biçimde koda döküyor. Ama ne istediğinizi net söyleyemiyorsanız, aldığınız kod da net olmayacak. Çıktı yüzeysel bakıldığında çalışıyor gibi görünebilir. Testlerde geçebilir. Ama altında yatan mimari kararlar, güvenlik açısından riskler, ya da ölçeklendiğinde çakışacak noktalar fark edilmeyebilir.

Bu yanılgı neden bu kadar yaygın? Çünkü araç gerçekten etkileyici. İlk birkaç deneme çoğu kişiyi şaşırtıyor. "Bu kadar hızlı çıktı!" diye düşünülen noktada süreç doğrulanmış sayılıyor. Oysa hız, doğruluğun kanıtı değil.

Bir başka yanılgı daha var: "Sorunu yazdım, cevabı kopyaladım, bitti." Kalıpsal görevler için bu yeterli olabilir. Ama gerçek bir ürün geliştirirken — birden fazla bileşenin birbiriyle konuştuğu, verinin farklı katmanlarda işlendiği, kullanıcı davranışının öngörülemediği bir yapıda — kopyala-yapıştır yaklaşımı kısa sürede karmaşa üretiyor.

Şu an ekipler ne yapıyor?

Pratikte ne değişti? Birkaç yıl önce bir geliştirici kod yazarken aynı anda kendi kendini denetliyordu. Her satırı düşünerek yazıyordu. Bu süreçte hem üretim hem kontrol paralel yürüyordu.

Şu an bu iki süreç ayrıştı.

Üretim hızlandı, kontrol yoğunlaştı

AI araçları kod üretimini onlarca kat hızlandırdı. Ama bu hız boşluğu, kontrol yükünü artırdı. Üretilen her kod bloğu, daha önce kişisel olarak yazılan koda göre çok daha dikkatli incelenmeyi gerektiriyor. Çünkü kodu yazan zihin ile denetleyen zihin artık ayrı.

Kod review, eskiden iyi pratik olarak önerilen bir adımdı. Şimdi zorunlu bir güvenlik katmanı haline geldi.

Bağlamı yönetmek yeni bir beceri oldu

Claude Projects, Gemini Gems gibi araçların getirdiği temel yenilik bağlam yönetimidir. Bu araçlara projenizle ilgili bağlam — mimari kararlar, kodlama standartları, iş kuralları, dil kuralları — beslendiğinde, üretilen çıktı çok daha tutarlı hale geliyor.

Bu demek oluyor ki ne ürettiğiniz kadar araca ne söylediğiniz de belirleyici. Prompt yazmak, sistematik düşünmeyi gerektiren ayrı bir beceriye dönüştü.

CLI araçlar süreci farklı bir boyuta taşıdı

Claude Code gibi komut satırı araçları, editör entegrasyonlarından bir adım öteye geçiyor. Projenizin tamamını görerek çalışabiliyor, dosyalar arası ilişkileri değerlendiriyor, değişiklik öneriyor. Bu araçlar doğru kurulduğunda bir junior geliştirici gibi çalışıyor — ama denetlenmesi gerekiyor.

Bu durum herkes için aynı mı?

Yapay zekalı geliştirme araçlarının getirdiği değişim, farklı bağlamlarda çok farklı biçimler alıyor.

Tek başına çalışan geliştirici için

AI araçları, tek kişilik ekiplerin kapasitesini gerçek anlamda büyüttü. Eskiden bir kişinin haftalar içinde tamamlayabileceği şeyler artık günler içinde çıkabiliyor. Ama bu hız, karar kalitesini düşürmemeli. Tek başına çalışırken üretim ve denetim yükü hâlâ aynı kişide. Kod hızlı geliyor, ama inceleyen de yine siz oluyorsunuz — daha dikkatli olmanız gerekiyor, daha az değil.

Ekip ortamında

Ekiplerde AI araçları ortak bir çıktı üretiyor ama her geliştirici farklı araçlar, farklı promptlar, farklı bağlam dosyaları kullanıyor olabilir. Bu tutarsızlık, kod stilinde ve mimari kararlarda gizli uyumsuzluklara yol açıyor. AI ile çalışma alışkanlıklarını ekip içinde standartlaştırmak, teknik borcu önlemenin yeni yolu haline geliyor.

Teknik bilgisi olmayan ürün sahipleri için

AI araçları, teknik olmayan kişilerin prototip seviyesinde bir şeyler üretmesini mümkün kıldı. Bu gerçek. Ama prototipten ürüne geçiş hâlâ mühendislik gerektiriyor. Kodu çalıştırmak ayrı bir şey, ölçeklenebilir, bakımı yapılabilir, güvenli çalışan bir sistem kurmak ayrı bir şey. Bu ayrımı görmeden alınan kararlar, ilerleyen süreçte yüksek maliyetli yeniden yazımlara neden oluyor.

Yazılım projesi fikri olan ama ekibi olmayan için

AI araçları bu profil için önemli bir kapı araladı. Fikrin ne olduğunu net tanımlayabiliyorsanız, bir geliştirici olmadan da süreci çok daha somut hale getirebilirsiniz. Mockup, prototip, kullanıcı akışı — bunlar artık daha az teknik kaynak gerektiriyor. Ama bu araçların ürettiği çıktıları gerçek bir ürüne dönüştürmek için yine de teknik karar alma süreçleri devreye giriyor.

"Yazılım mühendisliği bitti" — bu söylemin neyi kaçırdığı

Her teknolojik geçişte aynı söylem çıkıyor: Eski beceri artık gerekmiyor.

Assembly yerini C'ye bıraktığında, "Artık assembly bilmek gereksiz" denildi. Kısmen doğruydu — ama sistemin en derinindeki kararları almak için alt katmanı anlamak hâlâ gerekiyordu. IDE'lere otomatik tamamlama geldiğinde, "Geliştirici ne iş yapacak?" sorusu soruldu. Ama otomatik tamamlama, ne yazılacağını değil, yazılanın nasıl tamamlanacağını söylüyordu. Karar hâlâ insandaydı.

Şimdi de aynı süreç yaşanıyor. AI araçları kod üretimini devraldı. Ama ne üretileceğine karar vermek, üretilen kodun gerçekten doğru olup olmadığını değerlendirmek, sistemin bütününü görmek — bunlar hâlâ insan yargısı gerektiriyor.

Yazılım mühendisliği yok olmadı. Pratiği değişti.

Eskiden zamanın büyük bölümü koda dökmeye harcandı. Şimdi daha büyük bölümü tanımlamaya, yönlendirmeye ve denetlemeye harcanıyor. Bu fark küçük görünüyor ama gerektirdiği zihinsel model bambaşka.

Bu değişimde neye dikkat etmeli?

Yapay zekalı geliştirme araçlarını kullanıyorsanız ya da kullanmayı düşünüyorsanız, birkaç konu her profil için geçerli.

Maliyet

API tabanlı AI araçları token başına ücretlendiriliyor. Küçük projelerde bu fark edilmiyor. Ama büyük bağlam dosyaları, uzun kod tabanları, sık yapılan sorgular bir noktada kayda değer bir maliyet kalemine dönüşüyor. Bu maliyeti baştan görmek, araç seçimini ve kullanım biçimini doğrudan etkiliyor.

Etik ve sorumluluk

AI araçlarının ürettiği kod, sizin imzanızı taşıyor. Lisans uyumu, üçüncü taraf kütüphane kullanımı, kullanıcı verisinin nasıl işlendiği — bunların sorumluluğu araca değil, kodu yayına alan kişiye ya da ekibe ait. Bu sorumluluk, hız kazanıldığında geri planda kalmaya başlıyor. Dikkatli olmak gerekiyor.

Bağlam kalitesi belirleyici

AI aracına ne kadar iyi bağlam verirseniz, o kadar iyi çıktı alırsınız. Bu bağlam şunları içeriyor:

  • Projenin ne yaptığına dair net, kısaca yazılmış açıklama
  • Kullanılan teknoloji yığını ve mimari tercihler
  • Kodlama standartları ve stil kuralları
  • Sınır koşulları — neyin yapılmaması gerektiği

Bu bağlamı hazırlamak bir defaya mahsus değil, süreç boyunca güncellenmesi gereken canlı bir belgedir.

Review vazgeçilmez

Kod review'ı atlamak, AI çağında daha tehlikeli hale geldi. Üretilen kod miktarı arttı, dolayısıyla gözden kaçan hata olasılığı da arttı. Review'ı hızlandırmak için de AI araçları kullanılabilir — ama son kararı yine bir insan veriyor.

Kod review artık iyi bir pratik değil. Zorunlu bir adım.

Teknik mühendisler için: bu geçişte kazanılması gereken yetkinlikler

AI araçlarından en iyi çıktıyı alan mühendisler, teknik bilgilerini kaybetmiyor — farklı bir katmana taşıyor. Hangi seviyede olursanız olun, bu değişim farklı yetkinlikler gerektiriyor.

Junior mühendisler için

En kritik risk şu: AI araçları öğrenme sürecini kısaltıyor gibi görünse de temeli atlayan birinin ilerleyen dönemde süresi çok daha dar oluyor. Bir junior'ın AI çıktısını değerlendirmesi için önce sistemin nasıl çalıştığını bilmesi gerekiyor. Aksi hâlde üretilen hatayı göremez.

Bu aşamada kazanılması gereken yetkinlikler:

  • Okuyarak anlamak: AI'nın ürettiği kodu satır satır takip etmek. Kopyala-yapıştır değil, anlayarak devam etmek.
  • Hata ayıklama: Çıktı çalışmıyor olduğunda neye bakacağını bilmek. AI hata mesajını çözebilir ama neyin neden hata verdiğini anlamak sizi farklılaştırır.
  • Uç durumları test etmek: AI'nın ürettiği kodu sınır koşullarıyla test etme alışkanlığı. Happy path'te çalışan her şey gerçek kullanımda çalışmayabilir.
  • Çıktıyı sorgulamak: "Bu çalıştı" ile "Bu doğru" aynı şey değil. Bu farkı erken görmek, ileride büyük kazanım sağlıyor.

Mid-level mühendisler için

Bu seviyedeki geliştiriciler için AI araçları ciddi bir verimlilik katmanı açıyor. Ama aynı zamanda gizli bir tuzak var: AI'ın ürettiği kalıplar çok ikna edici göründüğünde daha az sorgulamaya başlıyoruz.

Bu aşamada odaklanılması gereken yetkinlikler:

  • Mimari görüş: AI tek bir bileşeni iyi üretiyor. Bileşenlerin nasıl bir araya geleceğini, sistemin bütününde nerede durduğunu görmek hâlâ insan işi.
  • Bağlam mühendisliği: Claude Projects, Gemini Gems ya da benzer araçlara ne beslediğiniz, ne aldığınızı doğrudan belirliyor. Bağlam dosyalarını iyi yazmak ayrı bir beceri.
  • Review liderliği: Ekipte AI kullanımı yaygınlaştıkça review sürecini standartlaştırmak ve yönetmek orta seviye mühendislerin sorumluluğuna giriyor.
  • Seçici kullanım: Her görevi AI'a vermek değil, hangi görevi AI'a vermenin mantıklı olduğunu bilmek. Bazı kararlar, AI'ın hız kazanımından daha değerli.

Senior mühendisler için

Senior seviyesinde değişim en derinden hissedilen yer, karar kalitesi değil — karar hızı. Çok daha fazla seçenek çok daha hızlı üretiliyor. Bunu yönetmek ayrı bir kazanım gerektiriyor.

Bu aşamada değer katan yetkinlikler:

  • Ekip standartlarını şekillendirmek: AI araçlarının ekip içinde nasıl kullanılacağına dair kurallar, araç seçimleri, bağlam dosyası formatları — bunlar artık teknik liderlik kapsamında.
  • Teknik borç yönetimi: AI hızlı üretiyor, ama ürettiklerinin uzun vadeli bakım maliyetini değerlendirmek senior bakışı gerektiriyor. Hız ile sürdürülebilirlik arasındaki dengeyi kurmak.
  • Güvenilirlik sınırını çizmek: Hangi görev tipi için AI güvenilir, hangisinde mutlaka insan kararı şart? Bu sınırı belirlemek ve ekibe aktarmak teknik liderliğin yeni bir boyutu.
  • Sistem düşüncesi: AI araçları bileşen seviyesinde etkili. Sistem tasarımı, veri akışı, güvenlik modeli, ölçeklenme stratejisi — bunlar hâlâ derinlikli deneyim gerektiriyor.

Teknik bilgisi olmayanlar için: akılda tutulması gereken felsefe

Yazılım projesi fikriniz var ya da mevcut bir süreci yazılımla çözmek istiyorsunuz — ama teknik altyapınız yok. AI araçlarının bu noktada kapıyı araladığı doğru. Ama bu kapıdan geçerken birkaç şeyi aklınızda tutmak, ilerleyen süreçte çok fazla gereksiz harcamayı engelleyebilir.

AI bir çeviri aracı, karar mekanizması değil

Yapay zekâya ne söylerseniz onu yapar — iyi ya da kötü. Yanlış bir fikri çok hızlı koda dökebilir. Bu, yanlışın doğrulanması değil; sadece hızlanması anlamına geliyor. AI araçlarından çıkan şeyin doğru olup olmadığını değerlendirmek için hâlâ bir çerçeveye ihtiyaç var. Bu çerçeveyi kuramamak, AI kullanımını kârlı değil maliyetli kılıyor.

Çalışan kod ile doğru sistem aynı şey değil

AI'ın ürettiği kod çalışıyor olabilir. Ama çalışmak, ihtiyacı karşıladığı anlamına gelmiyor. Güvenli mi? Bakımı yapılabilir mi? Büyüdüğünde ne olur? Bu soruların cevapları teknik karar gerektiriyor. Teknik bilgisi olmadan bu soruları sorabilmek bile başlı başına değerli bir farkındalık.

İhtiyacı tanımlamak en kıymetli iş

AI araçlarından iyi çıktı almanın sırrı çoğu zaman teknik bilgide değil, neye ihtiyaç duyulduğunun net biçimde tanımlanmasında. Şunu yapacak, şunu yapmayacak, şu durumda şöyle davranacak — bu tür net ifadeler, AI'a da geliştiriciye de aynı ölçüde rehberlik ediyor. Teknik bilgisi olmayan birinin bu tanımı iyi yapması, projeyi başlatmak için yeterli bir başlangıç noktası.

Hız yanılsamasına dikkat

AI araçlarıyla bir şeyler hızla çıktığında süreç tamamlanmış gibi hissettiriyor. Ama bu çoğu zaman prototip aşamasıdır, ürün aşaması değil. Prototipten işleyen bir sisteme geçiş hâlâ zaman, karar ve teknik yatırım gerektiriyor. Bu ayrımı baştan görmek, beklenti yönetimi açısından kritik.

Çıktının sorumluluğu araca değil, size ait

Bir geliştirici tutup o geliştirici hata yapsa, hesap sorulabilir. AI bir kod üretip o kod hata yaptığında, hesap sorulan yine insandır — o kodu kullanan ve yayına alan kişi ya da ekip. Bu sorumluluk bilinci, araçları kullanırken farklı bir dikkat gerektiriyor. "AI yaptı" bir savunma değil.

Bu araçlarla tanışmak, onları çalışma biçimine entegre etmek zaman alıyor. Ama bu zamanı harcamadan verimli kullanmak mümkün değil. Birçok ekip bu geçişi kendi başına yönetiyor — bazen doğru, bazen yanlış sırayla. Süreci birlikte düşünmek, çoğu zaman bu geçişi hızlandırıyor.