Neden Dış Kutudan Çıkan AI Kodları Geliştiricileri Kızdırır ve Buna Ne Yapabilirsiniz

Birçok teknoloji gibi, bir teknolojiyi ne kadar çok kullanırsanız, ona o kadar çok güvenmeye başlarsınız. Ancak AI araçlarında bunun tersi doğruymuş: Stack Overflow, 49.000’den fazla geliştiricinin katıldığı yıllık anketinde, AI araçlarının kullanımının %84’e çıkmasına rağmen, bu araçların doğruluğuna olan güven %40’dan %29’a düştü.

Bu etki bana tanıdık geliyor. Kendi ilk AI araçları deneyimimiz, teknoloji basınının yazdığı daha hızlı çalışma ve menos drudgery’nin tersiydi. Geliştiricilerimiz hayal kırıklığına uğradı: AI, uzun süre incelememiz gereken ortalama kodu üretti ve sonunda yeniden yazmamız gerekti. Takım, AI’dan zaman kazanmayı bekliyordu, ancak ekstra iş aldı. Bu nedenle, AI araçlarını günlük iş akışımıza katma girişimlerinin kısa bir süre sonra, takım eski yöntemine geri döndü.

Bugün aynı araçlar, geliştiricilerimiz için hem kod yazmayı hem de incelemeyi hızlandırıyor – daha iyi bir model bulduğumuz için değil, çünkü araçla çalışma şeklimizi değiştirdik. Oraya nasıl geldiğimizi anlatayım.

Neden AI Yazılı Kodları Geliştiricileri Kızdırır

AI, internet genelinde büyük bir kamu koduna dayanır ve bu kod genellikle mükemmel değildir: kalitesi ortalamadır ve model bu ortalamayı yeniden üretir.

Ancak “ortalama” mümkün olanın tavanı değil, modelin projenizi tanıyana kadar ürettiği şeydir: kuralları, kod yapısı, mimari kararları. 600’den fazla geliştiricinin katıldığı bir ankete göre, AI kodu kalitesinden memnun olmayanların %44’ü bunu precisely bir bağlam eksikliğine bağlar. Bu, çıktının ortalama seviyede kalmasını sağlar.

İyi haber, AI’nin aldığı bağlamın, takımın tamamen kontrol ettiği tek değişken olmasıdır. Araç, projenize ne kadar iyi uyum sağladığını belirler, model değil, ona ne verdiğiniz.

İkinci neden zihinsel – işin doğası değişir. AI, çoğu kodu yazdığında, geliştiricinin ana eylemi artık yazmak değil, üretileni incelemektir: birinin çözümünü okumak, alternatifleri değerlendirmek, neyin gönderilmeye hazır olduğunu karar vermek. Bu, kendi kodunu yazmaktan farklı bir beceridir ve yazma kısmını sevenler için kolay değildir.

GitHub, 2025 Octoverse raporunda, AI ile ilerleyen geliştiricilerin artık kendilerini “kod yazarı” olarak adlandırmadıklarını, daha çok “yaratıcı direktör” olduklarını açıklar: ana beceri, yönlendirmek ve doğrulamaktır. Ancak bu role giden yol, hatalar ve hayal kırıklıklarıyla doludur, пока bir kişi kendi işinde getirileri görmez.

Neden AI, Bir Kızdırma Kaynağından Çalışan Bir Araç Olur

Takımımız AI’i ilk kullanmaya başladığında, bazı geliştiriciler Claude Code, diğerleri OpenAI Codex, GitHub Copilot veya Gemini CLI denedi ve her araç farklı bir sonuç verdi. Bu nedenle, AI ile çalışmanın yolunu düzene koymaya çalışırken, ilk yaptığımız şey, tek bir araç üzerinde anlaşmak oldu.

Bu sadece bizim uygulamamız değil. Linear ekibinin hikayesine bakın: 2026’nın başlarına kadar, herkesin kendi yöntemini kullanmasına izin veren bir prensibe sahiptiler, ancak liderlik bu yaklaşımı bıraktı ve herkesi tek bir çalışma yöntemine geçirdi: AI araçlarını ikiye indirdi ve geliştiricilere, el ile değil, bu araçlarla kod yazmalarını istedi. Şirketin belirttiğine göre, ortalama verimlilik, bir sonraki ayda birleştirilen PR’lerde %30, mühendis başına kapatılan görevlerde %33 arttı.

Bununla birlikte, paylaşılan bir araç, kendi başına kodu iyileştirmez – yapılandırılması gerekir: kurallar, bir rules.md gibi, kod nasıl yazılacağını belirten bir şey. Ardından, projenize özgü görevler için özel beceriler gelir, böylece aynı şeyi tekrar tekrar açıklamaya gerek kalmaz. Son olarak, aracın mevcut kod tabanınıza yönlendirilmesi yararlıdır: projenin nasıl yazıldığını analiz eder ve yeni kodu aynı tarzda üretir, genel bir tarzda değil. Araca verilen bağlam ne kadar çok olursa, el ile yeniden yazmanız gereken şey o kadar az olur.

Ancak en zor parte teknik değil – kodun yazarından, değerlendirmesine geçiş, kendi başına gerçekleşmez – bu geçişe yardım gerekir. En doğrudan yol, eğitim ve sertifikadır. Örneğin, bizim durumumuzda, on geliştirici, aracın sağlayıcısı ile bir ortaklık programına katılırken, bir kişi, aracın neden belirli bir sonucu ürettiğini ve nasıl düzeltilmesi gerektiğini açıklamak için adoption için çalışır.

Takım koordine bir şekilde çalışmaya başladığında, bir engel kalır – inceleme – ve bu, AI ile güçlendirilebilir. Aracın her pull requesti önce incelemesi ve açık olanları ele alması yararlıdır: rutin hatalar, stil, tekrarlar, güvenlik açıkları. İnsan inceleyicisi artık her şeyi rastgele incelemez, sadece mimariyi ve kritik kararları inceler. Etki, bu araçları üreten şirketlerde bile görülür: Anthropic’te, böyle bir aracın tanıtılmasının ardından, kapsamlı inceleme alan pull requestlerin oranı %16’dan %54’e çıktı ve mühendisler, aracın yorumlarının %1’inden azınıyla anlaşmazlık yaşadı.

Bizim için, bu, iki veya üç gün süren ve birkaç turda gerçekleşen inceleme döngüsünü kısalttı ve senior mühendislerimizin rutin işini kaldırdı, onlara gerçekten zor noktaları bıraktı. Aracın nihayet yeniden çalışmaya başladığından, güven de ortaya çıktı.

Neden AI Araçlarına Güvenmek Öder

Öncelikle ve en önemlisi – kod yazmada: aracın projenizi bildiği ve aracın ilk incelemeyi yaptığı zaman, takım aynı sürede daha çok ve daha iyi kod yazar. Bizim durumumuzda, AI araçları, işi %30-40 hızlandırdı.

Ötesinde, AI, yeni bir kişinin projeye katılması daha kolay hale getirdi. Bir yeni kişinin katıldığında, genellikle deneyimli biri, projenin kod yapısı hakkında birçok soruyu cevaplamak zorundadır. Şimdi, aracın bu rolü üstlendiğini görüyoruz: eğer proje iyi belgelenmişse, yeni gelen, %95’e varan soru ve sorunlarını aracın kendisine, değil de kolega sormaktadır.

Belgelerin durumu da benzer: bir mimari taslağı, aracın kendisi yazmaktadır – bizim tahminimize göre, đủ bağlam verilirse, %80’e varan bir taslak. İnsan için kalan, depoda olmayan şeylerdir: kararlar, tercihler, uzmanlık.

Şununla da dürüst olmak önemlidir: AI’nin ne yapabileceğinin sınırlarını bilmek, çünkü abartılmış beklentiler, ilk etapta hayal kırıklığına neden olur. AI, uyumluluk işini üstlenmez – bir insan, tıbbi veya finansal verilerin sorumluluğunu üstlenir ve şirket, model değil, sızıntıdan sorumludur. AI, entegrasyonları hızlandırmaz – ortaklarla yapılan görüşmeler ve koordinasyon için saatlerce zaman harcanır.

Dış kutudan çıkan AI gerçekten can sıkıcıdır – ancak sadece bitmiş bir çözüm olarak kullanıldığında. Fark, neye göre kullanılırsa, İşte burada yatar: paylaşılan bir standart, projenizin bağlamı ve geliştiricinin yeni rolü.