# Yapay Zeka ile Kodlama Verimliliği: Ölçüm Sorunu ve Güvenlik URL: https://upstreamapi.com/tr/journal/yapay-zeka-kodlama-verimliligi-olcum-sorunu Type: blog Locale: tr Published: 2026-08-08 Updated: 2026-08-13 --- > Yapay zeka ile kodlama verimliliği gerçektir. Ölçüm sorunu da gerçektir. Bunu başarılı şekilde yönetenlerin farkı: araçları devreye almadan önce neyi ölçeceğine karar vermek. Yapay zeka ile kodlama verimliliği metrikleriniz slayttı harika görünüyor. Geliştiriciler görevleri yüzde 21-33 daha hızlı tamamlıyor. Mühendis başına merge edilen pull request yüzde 98 artmış. Mühendislik örgütü hızlandırma hedeflerine ulaştığını kutluyor. Sonra saat 2'de PagerDuty uyarısı geliyor. Hiçbir şey seçilmemiş. PR başına incident yüzde 242 artmış. Kod inceleme süresi yüzde 441 arttı. Hata bütçeniz, yapay zeka ile kodlama yardımcılarını devreye almadan öncekinden daha hızlı yanıyor. Slack'teki on-call kanalında, saat 3'te telemetri okuyor ve bütçenin neden bu kadar hızlı tükündüğünü soruyor. Cevaplar net değil. Kurumsal yöneticiler bunu yan çizgi grafiğinde görseller. Teknik ekipler biliyorlar. Verimliliğin paradoksu efsane değildir. Bu bir ölçüm problemidir. Bunu başarıyla yönetenlerin farkı şudur: araçlar devreye girmeden önce neyi ölçeceğine karar veren ekipler. ![Yapay zeka destekli geliştirmeden kaynaklanan aşırı yükü gösteren çok sayıda kod inceleme isteği](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-08/d88c83-inline1.webp) ## Hiç Kimsenin CTO Seviyesinde Ölçmedği 3x Sorunu Yapay zeka ile kodlama, mühendislerin kod yazma hızını yaklaşık 3 kata çıkarıyor. Bu rakam, tüm kurumsal toplantılarda ve mühendislik blog yazılarında adı geçen sayı. Velocity kazancı gerçek ve ölçülebilir. Fakat söylenmeyenler daha çıkardı: 3 kat daha fazla kod, 3 kat daha fazla uygulama yapısı, 3 kat daha fazla üretim ortamı yayını ve platform ekibinin yönetmesi için 3 kat daha fazla operasyonel yüzey demektir. Platform ekibinin kadrosu üçe katlanmamıştır. SRE mühendisleri aynı ekip boyutu ile 3 kat daha fazla release olayını yönetmek zorunda kalıyor. Bu teorik bir sorgulama değildir. 2026 yılında platform ekiplerinin yüzde 73'ü yapay zeka kodlama yardımcılarını en az bir geliştirici iş akışına entegre etmiştir. Veri çıktısı artışı gerçektur, Faros telemetrisi tarafından doğrulanmıştır. Altyapı katmanı tarafından emilmek zorunda kalınan operasyonel yük de gerçektur ve nadiren kapasiye modelinde yer alır. Bu, kurumsal yöneticilerin konuşmadığı bir hesap. Kötü bir dağıtımın etki alanı mühendisin yapay zeka araçlarını kullanması nedeniyle küçülmez. Dağıtım hızıyla ölçeklendirilir. Dağıtım hızınız az önce arttı. SRE ekibi haftada 3 kat daha fazla değişim olayını yönetiyorsa, olay başına bilişsel maliyet zorunlu olarak düşer. Triyaj kalitesi bozulur. Uyarı yorgunluğu birleşir ve müdahale süresi uzar. Platform ekibi, operasyonel maliyet tanımlamada hiçbir rolü olmayan verimlilik kazancının sistemic maliyetini emilir. ## Dağıtım Frekansı Artık Eskisi Gibi Ölçmüyor Dağıtım frekansı, DORA'nın dört metriğinden biridir. Kodun üretim ortamına ne sıklıkla dağıtıldığını ölçer. Yapay zeka ile kodlama yardımcıları bunu artırır, çünkü geliştiriciler aynı takvim haftasında daha fazla kod üretir. Fakat dağıtım frekansı asla kaliteyi ölçmemiştir. Hızı ölçmüştür. Yapay zeka kodunun yüzde 41'ini üretiyorsa, hız artarken üretim ortamı trafiğinizdeki sinyal-gürültü oranı değişir. Kurumsal müdürlerin görmek istediği basit metrik "haftada kaç dağıtım" olmasına rağmen, sistem sağlığı bu numaraya bağlı değildir. [Faros tarafından analiz edilen DORA 2025 bulguları](https://www.faros.ai/blog/key-takeaways-from-the-dora-report-2025) bunu kesin olarak ölçer: bireysel seviye metrikler hepsi iyileşir (mühendis başına görev yüzde 66 artış, merge edilen PR yüzde 98 artış), fakat örgütsel dağıtım kararlılığı yüzde 7.2 azalır. Limanı terk eden daha fazla gemi, zeminle daha az gemi çatışması anlamına gelmez. Tersine, hızlanan tersane daha fazla gemi gönderiyor ama karaya oturan gemi sayısı aynı kalıyor veya artıyor. Yapay zeka ile kodlama verimlilik dağıtımı için başlık metriği olarak dağıtım frekansını kullanıyorsanız, sisteminizin yanlış katmanını ölçüyorsunuz. Doğru soru şudur: hız kazancının karşılığı nedir? Değişim hatası sabit mi? Yoksa yanmış mı? Dağıtım frekansının yanında izlemeye değer metrik: değişim hatası oranıdır. Her iki metrik ters yöne hareket ediyorsa, bu hızın istikrarı aşıyor olduğu sinyalidir. DORA çerçevesinde, bu uyumsuzluk, iyileşmekte olan sistemi değil, stres altındaki sistemi gösterir. DORA 2025 raporunun sorunlu bulgularından biri de budur. ![Hata oranı SLO eşiğini aşan hata oranı artışını gösteren SRE izleme panosu](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-08/69d95b-inline2.webp) ## PR Başına Incident Yüzde 242 Artmış: Retro'da Gömülü Kalan Sayı Bu sayı verimlilik anlatısına uymayan istatistiktir: yüksek yapay zeka ile kodlama araçları benimsemesi olan ekiplerde PR başına incident yüzde 242 artmıştır. Bu yuvarlanış hatası değildir. Bu kodun commit'ten üretim ortamına gidiş şeklindeki yapısal değişikliktir ve hiçbir şeyin hatası değil. Mekanizmik şaşırtıcı değildir. Yapay zeka ile kodlama yardımcıları, daha yüksek hızda testleri ve incelemeyi geçen kod üretir. Testler ve inceleyiciler, yapay zeka mandatı öncesi mevcut olanla aynıdır ve ölçeklememiştir. PR başına göz sayısı azalmıştır, algoritma hızda kaybetti. PR'ler insan incelemesi olmadan merge olmaktadır (yüzde 31 artış). Bu post-mortem'de yazılı, hiçbir zaman soruşturmada gün yüzüne çıkmayan sayı. Daha fazla kod. Aynı güvenlik tedbirleri. Değişiklik başına daha az ilgi. İşte platform ekibinizin dağıtım planlamasının muhtemelen atladığı etki hesabı ve hatta kaydıyla uyarı vermedi. Yapay zeka ile kodlama araçlarının kendileri kök nedeni değildir. Cursor'ın Şubat 2026'da 2 milyar dolar yıllık yinelenen gelire ulaşması ve GitHub Copilot'un yüzde 42 kurumsal pazar payını tutması, bu araçların platform ekibinin kararından bağımsız olarak örgütünüzün içinde olduğu anlamına gelir. Soru "izin verilip verilmeyeceği" değildir, zaten veriyor. Soru "dağıtım hattının etrafında uyarlanıp uyarlanmadığından" geçerdir. Bunun cevabı genellikle hayırdır. Bu soruları post-mortem'de soran bir platform ekibi zaten penceresini kaybetmiştir. Cevabın işlem yapılabilir olduğu yer: hata bütçe yanmadan öncesi. Saat 1'de olay kanalında yanma oranını okuduğunuz sırada değil, araçlar devreye girmeden 2 hafta önce. ## Yapay Zeka ile Kodlama Araçlarını Çalıştırıyorken İzlemeye Değer Dört Metrik Standart DORA dağıtım frekansı, müşteri adına geçen süre, değişim hatası oranı ve MTTR'i kapsar. Önemli yapay zeka ile kodlama araçları benimsemesi olan ekipler için, baştan enstrümante edilmeye değer dört ek sinyal vardır, hangisi standart dashboard'da görünmez: **Yapay Zeka Commit Oranı.** Commit'lerin yüzde kaçı yapay zeka desteklidir? Bunu zamanla değişim hatası oranınıza karşı izleyin. Yapay Zeka commit oranı yüzde 30 tırmanırsa ve değişim hatası oranı iki hafta içinde takip ederse, müdahale edilmeden önce yanıt verilebilir bir sinyaliniz vardır. Beklemeyin. Hemen veri başlayın. **PR İnceleme Kapsam Alanı.** PR'lerin yüzde kaçı merge olmadan önce en az bir sağlam insan inceleme yorumu alır? Yapay zeka ile kodlama destekli kod daha hızlı merge olur. Bu daha az inceleme ile merge olması gerektiği anlamına gelmez. Ortalama PR başına inceleme zamanı yüzde 441 tırmanışı olduğunda temel değişir. Hiçbir mühendis daha hızlı inceleyemez. **Kod Aşınma Oranı.** Son 30 günde yazılı kodun yüzde kaçı sonraki 30 gün içinde yeniden yazılır veya silinir? Yapay zeka ile kodlama araçları mevcut test paketini denetleyen ve geçen kod için eniyiye ayarlanmıştır. Ürün gereksinimlerinin ikinci veya üçüncü yinelemesinde kalan kod için eniyiye ayarlanmamıştır. Yüksek aşınma, üretim ortamında problem olacaktır. **Hata Bütçe Yanma Oranı Dağıtım Hızına Karşı.** Hata bütçeniz dağıtım frekansı yüzde 50 arttığında 2 kat daha hızlı yanıyorsa, daha fazla gönderiyorsunuz ve aynı zamanda daha az güvenilir hale geliyorsunuz. Bu dağıtım panoyu kutlaması değil, kapı gerektiren bir dağıtım. Dağıtımı duraklatın ve sorunun nerede olduğunu bulun. ## Dağıtım Deneyini Değiştiren Desen Standart yapay zeka ile kodlama verimlilik dağıtımı tanıdık bir deseni takip eder: araç lisansını satın alın, IDE eklentisini yapılandırın, mühendislik örgütüne duyuru yapın, haftada PR'leri ölçün, başarı durumunu liderlik bildirin. Operasyonel etkileri düşünün mi? Hiçbir zaman. Operasyonel tarafı hesaba katan dağıtım deseni farklı görünür. Üstler canlı olmadan önce dört metriği enstrümante edin. Temel çizgiyi oluşturun. Daha sonra değişim hatası oranında regresyonu araçtan çıkarmak için dağıtım hattınıza SLO kapısı ekleyin. Bu, dağıtımın otomatik olarak durdurulacağı bir kontrol noktasıdır. Bu yeni bir fikir değildir. Bu kanari dağıtımları standart uygulama yapan mantıktır. Trafiğin yüzde 100'ünü bir kerede değiştirmezsiniz. Kademeli olarak dağıtırsınız ve hata bütçe size neler söyler. Aynı mantık, 150 mühendis örgütüne yapay zeka ile kodlama mandatı kapsamında uygulanır. Bir ekibe dağıtın. Enstrümante edin. Kod aşınması iki katına çıkarsa ve PR başına incident ilk haftada tırmanışla başlarsa, bu hızlandırmak değil duraklatmak ve ayarlamak sinyalidir. Devam etmeyin. Durun ve sorun nedir bulun. Kod kalitesi araçları bu katmanda özellikle yararlıdır. Yapay zeka ile kodlama dağıtımından önceki ve sonraki teknik borç ve hotspot analizi çalıştırılması, hız metriklerinden bağımsız olarak, operasyonel tutarlılığa ne maliyeti olduğunun niceliklendirilmiş bir resmini verir. Bu sayı dağıtım incelemesinde olmalı, sadece hız tablosunda değil. Kod mimarisi nasıl değişti? Borcunuz arttı mı? ## Sonraki Yapay Zeka ile Kodlama Dağıtımından Önce Enstrümante Etmek Platform ekibinizden yeni bir takım veya örgüt birimi için yapay zeka ile kodlama araçlarını etkinleştirmesi isteniyorsa, dağıtım öncesi enstrümantasyonun kontrol listesi kısadır ve NET: - Hedef ekip için dağıtım frekansı, değişim hatası oranı ve MTTR'i temel çizgisi oluşturun (30 günlük yuvarlama penceresi), yazın, kaydedin - PR inceleme kapsam alanı: sadece onay tıklaması değil, en az bir sağlam inceleme yorum yüzdesi - Kod aşınma oranı: sürüm kontrol geçmişinden çıkarın, aynı ekibi altı ay öncekisi ile karşılaştırın - Hata bütçe yanma oranı: dağıtım hızıyla çizin böylece mutlak sayıları değil oranı görürsünüz Bunlardan hiçbiri zaten gözlemlenebilirlik ve sürüm kontrolü varsa yeni araçlar gerektirmez. Biri dağıtım başlamadan önceki sayıları çekmek için atanması gerekir. Post-mortem'de doksan gün sonra değil, ÖNCE. Platform ekibinin asıl görevi yapay zeka ile kodlama verimliliğini engel koymak, hiçbir zaman değildir. Etki alanı genişlemeden önce güvenlik tedbirleri var olduğundan emin olmaktır. Bütçenizi koruyun. ## SLO Bütçe'nin Son Söyü Vardır Saat 3'te düşünmek istemiyor. Hesaplamak istemiyor. Düğmeye basmak istemiyor. Ama yapması lazım. SLO bütçe, doğru enstrümante edildiyse bu soruya cevap verir. Dağıtım frekansında yüzde 50 artış boyunca hata bütçe sabit kalırsa, bu dağıtım işe yaradığını söyler ve ilerle. Hata bütçe hız arttığında 2 kat daha hızlı yanıyorsa, verimlilik kazancı güvenilirliğinde ödeniyorsunuz ve güvenlik tedbirleri nerede başarısız olduğunu bulmanız lazımdır. Durdur ve araştır. Yapay zeka ile kodlama verimliliği gerçektir ve kaçınılmazdır. Ölçüm sorunu eşit derecede gerçektir ve çoğu zaman göz ardı edilir. İkisi de doğrudur, ama ikisine birden cevap veren kuruluşlar az sayıda. Ölçüm sorunu eşit derecede gerçektir. SLO bütçe, ikisini ayıran araçtır. Biri olmadan, diğeri yanılsama. Yapay zeka ile kodlama dağıtımından sonraki post-mortem şunu soracak: hata bütçe dağıtımdan önce size ne söyledi? Bu tek cevap önemli olandır. Cevap "hiçbir şey, enstrümante etmedik" ise, o zaman hatayı bulun ve zaman harcadığınız doğru yerdir. Sonra bunu yapın. ## FAQ ### Yapay zeka ile kodlama araçları gerçekten verimliliği 3 kata çıkarıyor mu? Kısmen evet. Bireysel mühendis çıktısı yüzde 21-98 arasında artıyor (görev başına dakika / PR merge oranı). Ancak 3 kat daha fazla kod, 3 kat daha fazla operasyonel yük demek. Platform ekibi bu yükü sorun yaşamadan arttırmak zorunda kalıyor ve bu çoğu dağıtım planında hesaplanmıyor. ### Neden PR başına incident oranı çoğalıyor? Yapay zeka ile kodlama araçları hızlı kod üretir, ama inceleme süresi azalıyor. PR başına insan inceleme sayısı düşüyor ve yüzde 31 oranında kişi olmayan merge gerçekleşiyor. Kodun kalite kapısı hızla ölçeklemediğinden, incident oranı arttığı tespit ediliyor. ### DORA metriklerini neden tekrar düşünmeliyiz? Dağıtım frekansı hız ölçer ama kaliteyi ölçmez. Yapay zeka ile kodlama araçları endüstrilenmişse, frekans arttığında değişim hatası oranı da arttığını görebilirsiniz. Metrik uyumsuzluğu, işin bozulduğunun erken sinyalidir. ### SLO kapısı nedir ve neden gerekli? Dağıtım hattınıza hata bütçe yanma oranını izleyen kontrol ekleyin. Dağıtım frekansı yüzde 50 artsa fakat hata bütçe yanma 2 kat daha hızlıysa, bu dağıtımı duraklatıp ayarlamanız gerektiğini söyler. Canari dağıtımları gibi: şeyi 100 kişiye vermeden 10'a versek ne öğreniriz? ### Kod aşınma oranını neden izlemeliyim? Yapay zeka ile kodlama araçları, güncel test paketini geçmeye eniyiye ayarlanmıştır. Fakat ürün gereksinimi değiştiğinde, bu kod silinir veya yeniden yazılır. Yüksek aşınma, hızlı olarak yazılsa da kalıcı olmayan kod anlamına gelir ve bu teknik borçtan farklıdır. ### Platform ekibim ne zaman dağıtım öncesi enstrümantasyona başlamalı? Araç lisansı almadan hemen ONCE. 30 günlük temel çizgi oluşturun: dağıtım frekansı, değişim hatası oranı, MTTR, PR inceleme yüzdesi, kod aşınması. Bunu sonra yapılırsa, değişimi ölçemeyen bir dağıtım yaratırsınız. ### İlişkisiz infrastructure sorunu ile yapay zeka ile kodlama sorununu nasıl ayırt ederim? SLO bütçe araçtır. Dağıtım frekansını hata bütçe yanma oranıyla karşılaştırın. Yüzde 50 hız artışının yüzde 100 bütçe yanması ile karşı karşıya kalırsa, verimliliğiniz güvenilirlik maliyeti var demek. Tersine, yanma sabit kalırsa, dağıtım başında var olan sorunlar devam ediyor demek.