Yapay Zekâ Geliştiricilerin İşinde Neyi Değiştirir (Neyi Değiştirmez)

Değiştir, Destekle, Dokunma: Basit Bir Çerçeve

“AI geliştiricilere ne yapacak” konusundaki konuşmalar hızla kafa karıştırıcı olabilir çünkü sık sık araçları ve sorumlulukları karıştırırız. Bir araç kod üretebilir, bir ticket’ı özetleyebilir veya testler önerebilir. Bir sorumluluk ise öneri yanlış olduğunda ekipten kimin hesap vereceğidir.

Bu makale, gerçek ekiplerdeki —son teslim tarihleri, legacy kod, üretim olayları ve güvenilir sonuç bekleyen paydaşları olan— günlük işleri tanımlamak için replace, augment, untouched adlı basit bir çerçeve kullanır.

“Replace” ne demek (ve ne demiyor)

Replace demek, AI'nın görevi uçtan uca çoğu zaman net koruyucularla tamamlayabilmesi ve insan rolünün denetim ve spot-check'lere kayması demektir.

Örnekler genelde sınırlı işlerle ilgilidir: boilerplate üretmek, diller arasında kod çevirmek, tekrarlayan test vakalarını hazırlamak veya ilk taslak dokümantasyon üretmek.

Replace, insan sorumluluğunun olmadığı anlamına gelmez. Çıktı üretimde bozulma, veri sızıntısı veya standart ihlali yaparsa sorumluluk hâlâ ekipte olur.

“Augment” ne demek

Augment demek, AI geliştiriciyi daha hızlı veya daha titiz yapar, ama insan yargısı olmadan işi güvenilir şekilde bitiremez.

Bu, profesyonel mühendislikte yaygın durumdur: faydalı taslaklar, alternatif yaklaşımlar, hızlı açıklamalar veya muhtemel hataların kısa listelerini alırsınız—ancak neyin doğru, güvenli ve ürün için uygun olduğuna geliştirici yine karar verir.

Ne “untouched” (dokunulmamış) kalır

Untouched demek, çekirdek sorumluluğun insan liderliğinde kalmasıdır; çünkü bağlam, ödünleşimler ve hesap verebilirlik promptlara sığmaz.

Düşünün: gereksinimleri müzakere etmek, sistem seviyesinde kısıtları seçmek, olayları yönetmek, kalite çıtalarını belirlemek ve tek bir “doğru” cevabın olmadığı durumlarda karar almak.

Neden sorumluluklar analiz birimi olmalı

Araçlar hızlı değişir. Sorumluluklar yavaş değişir.

Bu yüzden “Bu kodu AI yazabilir mi?” demek yerine “Sonucun sahibi kim?” diye sorun. Bu çerçeve beklentileri doğruluk, güvenilirlik ve hesap verebilirlik temelinde dengede tutar—etkileyici demoların ötesinde daha önemli olan şeyler.

“Geliştirici Sorumlulukları”ndan Ne Anlıyoruz

İnsanlar AI’nın geliştirmede neyi “değiştirdiğini” sorduğunda genellikle görevleri kastediyorlar: bir fonksiyon yazmak, test üretmek, doküman taslağı hazırlamak. Ancak ekipler görevleri göndermez—sonuçları gönderir. İşte bu yüzden geliştirici sorumlulukları önemlidir.

Tipik sorumluluk paketi

Bir geliştiricinin işi genellikle sadece kod yazmaktan daha fazlasını kapsar:

• Teslimat: belirsiz bir fikri zamanında çalışan yazılıma dönüştürmek.
• Kalite: doğruluk, sürdürülebilirlik ve regresyonların önlenmesi.
• Güvenlik ve gizlilik: güvenli varsayılanlar, veri işleme ve tehdit farkındalığı.
• Operasyon: servislerin çalışır kalması, hata modlarını anlama ve olaylara müdahale.
• İletişim: ürün, tasarım, destek ve diğer mühendislerle hizalama.

Bu sorumluluklar, “ne inşa etmeliyiz?” den “bu güvenli mi?”ye ve “sabah 3’te kırıldığında ne olur?”a kadar tüm yaşam döngüsüne yayılır.

Neden bir kontrol listesinden daha fazlası

Her sorumluluk aslında birçok küçük karar içerir: hangi kenar durumlar önemli, hangi metrikler sağlığı gösterir, ne zaman kapsamı kısaltmalı, bir düzeltmenin gönderilmesi güvenli mi, bir ödünleşimi paydaşlara nasıl açıklamalı. AI bu işin parçalarını yürütmeye yardım edebilir (kod taslağı, test önerisi, log özeti), ama sorumluluk sonuç üzerinde sahiplenmektir.

Handoff’lar nerede başarısız oluyor

Çoğu çökme handoff sınırlarında olur:

• “QA yakalar” (ama kim kaliteyi tanımladı?).
• “Güvenlik inceler” (ama tasarım zaten riskli seçimleri kilitledi).
• “Ops halleder” (ama servis işletilebilir olacak şekilde inşa edilmedi).

Sahiplik belirsiz olduğunda işler boşluğa düşer.

Karar hakları: kim karar verir vs kim uygular

Sorumluluklardan bahsetmenin faydalı bir yolu karar hakları:

• Gereksinimleri, ödünleşmeleri ve kabul edilebilir riski kim karar veriyor?
• Uygulama ve doğrulamayı kim uyguluyor?

AI yürütmeyi hızlandırabilir. Karar hakları—ve sonuçlar için hesap verebilirlik—halen yanında bir insan ismi gerektirir.

AI’nın Genellikle Değiştirebildiği İşler (koruyucularla)

AI kod asistanları, işin öngörülebilir, düşük riskli ve doğrulanması kolay olduğu yerlerde gerçekten faydalıdır. Onları hızlı bir genç ekip arkadaşı gibi düşünün: ilk geçişi iyi üretir, ama net talimatlar ve dikkatli bir kontrol gerekir.

Pratikte bazı ekipler bu değiştirilebilir parçaları hızlandırmak için “vibe-coding” platformlarını (ör. Koder.ai) kullanıyor: scaffold üretimi, CRUD akışlarının kurulması ve sohbetten UI ile backend için ilk taslakların çıkarılması. Ana unsur yine aynı: guardrail’ler, inceleme ve net sahiplik.

Düşük riskli boilerplate

Geliştiricilerin zamanının büyük kısmı proje iskeleti ve katmanlar arası bağlantı için gider. AI genellikle üretebilir:

• başlangıç dosyaları ve klasör yapıları (controller, route, DTO gibi)
• katmanlar arasındaki tekrarlayan “bağlayıcı” kod
• yerleşik bir deseni takip eden basit CRUD endpoint’leri

Buradaki guardrail tutarlılıktır: mevcut konvansiyonlarınıza uyduğundan ve yeni desenler ya da bağımlılıklar icat etmediğinden emin olun.

Mekanik refaktörler ve migration’lar

Değişiklik büyük ölçüde mekanik ise—kod tabanında sembol yeniden adlandırma, yeniden formatlama veya basit bir API kullanım güncellemesi—AI yoğun işi hızlandırabilir.

Yine de bunu bir toplu düzenleme gibi ele alın: tüm test süitini çalıştırın, farkları inceleyip istenmeyen davranış değişikliklerine bakın ve AI’nın istenenden fazlasını “iyileştirmesine” izin vermeyin.

Dokümantasyon taslakları (inceleme gerekli)

AI READMElar, inline comment’ler ve commit notlarından changelog girdileri taslağı oluşturabilir. Bu açıklığı hızlandırır, ama aynı zamanda kendinden emin görünen yanlışlıklar da üretebilir.

En iyi uygulama: AI’yı yapı ve ifade için kullanın, sonra her iddiayı doğrulayın—özellikle kurulum adımları, konfigürasyon varsayılanları ve kenar durumlarda.

Temel test üretimi başlangıç noktası olarak

İyi tanımlanmış, saf fonksiyonlar için AI tarafından üretilen birim testleri başlangıç kapsaması sağlayabilir ve kenar durumları hatırlatabilir. Guardrail sahiplenmedir: hangi sonuçların önemli olduğunu siz seçersiniz, gerçek gereksinimleri yansıtan assertion’lar eklersiniz ve testlerin doğru sebeplerle başarısız olduğundan emin olursunuz.

Thread ve log özetleri

Uzun Slack konuşmaları, ticket’lar veya olay logları olduğunda AI bunları kısa notlara ve aksiyon maddelerine dönüştürebilir. Tam bağlamı vererek sonuçları somutlaştırın ve önemli tarihleri, kararları ve gerçekleri paylaşmadan önce doğrulayın.

AI’nın Çoğunlukla Desteklediği İşler: Daha Hızlı, Ama Bitmiyor

AI kod asistanları, ne istediğinizi zaten bildiğinizde en iyi performansı gösterir; “yazma işi”ni azaltır ve faydalı bağlamları ortaya çıkarır, fakat sahiplenme, doğrulama ve yargı ihtiyacını ortadan kaldırmaz.

Uygulamayı hızlandırma (iyi bir ilk taslak)

Açık bir spes verildiğinde—girdiler, çıktılar, kenar durumlar ve kısıtlar—AI makul bir başlangıç uygulaması taslağı çıkarabilir: boilerplate, veri eşlemesi, API handler’ları, migration’lar veya basit bir refaktör. Kazanç ivme kazanmaktır: çabuk çalışır hale gelen bir şey elde edersiniz.

Yakalanması gereken nokta: ilk geçiş genelde ince gereksinimleri kaçırır (hata semantiği, performans kısıtları, geriye uyumluluk). Bunu bir stajyer taslağı gibi ele alın: kullanışlı ama kesin otorite değil.

Seçenek önerme—kontrol etmeniz gereken ödünleşmelerle

Kullanım örneğin caching vs batching, optimistic vs pessimistic locking gibi seçenekler arasında karar verirken AI alternatifler ve ödünleşmeleri listeleyebilir. Bu beyin fırtınası için değerlidir, ama ödünleşmelerin ekibin gerçekliğiyle (trafik şekli, veri tutarlılığı, operasyonel kısıtlar, ekip konvansiyonları) kontrol edilmesi gerekir.

Kod anlama ve kod tabanında gezinme

AI, alışık olmadığınız kodu açıklamakta, kalıpları işaret etmekte ve “bu ne yapıyor?” sorusunu düz dille anlatmakta güçlüdür. Arama araçlarıyla birleştirildiğinde “X nerede kullanılıyor?” sorusuna yanıt bulmaya ve gözden geçirilmesi gereken çağrı yerleri, konfigürasyonlar ve testlerin kısa listesini üretmeye yardımcı olabilir.

Geliştirici ergonomisi: daha iyi geri bildirim döngüleri

Daha net hata mesajları, küçük örnekler ve hazır yapıştırılabilir snippet’ler gibi pratik kalite-yaşam iyileştirmeleri bekleyin. Bunlar sürtünmeyi azaltır, ama kullanıcıları veya üretim sistemlerini etkileyen değişiklikler için dikkatli incelemeyi, yerel çalıştırmayı ve hedefe yönelik testleri değiştirmez.

Ürün Anlayışı ve Gereksinimler: Hâlâ İnsanın Liderliğinde

AI gereksinimleri yazıp düzeltmenize yardım edebilir ama ne inşa etmeliyiz veya neden önemli sorusuna güvenilir şekilde yanıt veremez. Ürün anlayışı bağlamda köklenir: iş hedefleri, kullanıcı ağrıları, organizasyonel kısıtlar, kenar durumlar ve yanlış yapmanın maliyeti. Bu girdiler konuşmalarda, geçmişte ve hesap verebilirlikte yaşar—model özetleyebilir ama gerçekten sahiplenemez.

Belirsiz hedefleri inşa edilebilir hale getirmek

Erken istekler genelde “Onboarding’i daha kolay yap” veya “Destek biletlerini azalt” gibi genel ifadeler taşır. Geliştiricinin işi bunu net gereksinimlere ve kabul kriterlerine çevirmektir.

Bu çeviri çoğunlukla insan işi çünkü sorgulayıcı sorular ve yargı gerekir:

• Hangi kullanıcı segmentini optimize ediyoruz ve hangi davranış değişmeli?
• “Tamam” ne demek ve bunu nasıl ölçeceğiz?
• Hangi kısıtlar vazgeçilmez (gizlilik, performans, teslim tarihleri)?

AI olası metrikler veya kabul kriterleri önerebilir, ama hangi kısıtların gerçek olduğunu bilmez—ve çelişkili bir isteğe geri itme yapmaz.

Ödünleşmeler ve beklenti yönetimi

Gereksinimler işi rahatsız edici ödünleşmelerin su yüzüne çıktığı yerdir: zaman vs kalite, hız vs sürdürülebilirlik, yeni özellik vs stabilite. Ekiplerin riskleri açıkça ifade edecek, seçenekler önerecek ve paydaşları sonuçlar konusunda hizalayacak bir kişiye ihtiyacı vardır.

İyi bir spes sadece metin değil; bir karar kaydıdır. Test edilebilir ve uygulanabilir olmalı, net tanımlarla (girdiler, çıktılar, kenar durumlar ve hata modları). AI belgeyi yapılandırmaya yardım edebilir, ama doğruluk ve “bu belirsiz, karar gerek” demek insanlarda kalır.

Sistem Tasarımı ve Mimari Kararlar

Sistem tasarımı “ne inşa etmeliyiz?” sorusunu “ne üzerine inşa etmeli ve işler bozulduğunda nasıl davranmalı?” sorusuna çevirir. AI size seçenekleri keşfetmede yardımcı olabilir, ama sonuçları sahiplenemez.

Gerçeğe uyan bir mimari seçmek

Monolith, modular monolith, microservices, serverless veya yönetilen platformlar arasında seçim tek doğru cevabı olan bir sınav değildir. Uygunluk problemi: beklenen ölçek, bütçe, pazara çıkış süresi ve ekibin becerileri.

Bir asistan kalıpları özetleyebilir ve referans mimariler önerebilir, ama ekibinizin haftalık on-call döngüsüne, işe alım sürecinin yavaşlığına veya veri tabanı sağlayıcınızın sözleşme yenilemesine dair bilgiyi bilmez. Bu ayrıntılar genelde bir mimarinin başarılı olup olmayacağını belirler.

Ödünleşmeleri açık hale getirmek

İyi mimari çoğunlukla ödünleşmelerdir: basitlik vs esneklik, performans vs maliyet, bugünkü hız vs ileride sürdürülebilirlik. AI hızlıca artı/eksi listeleri üretebilir; bu faydalıdır—özellikle kararları belgelemek için.

Yapamayacağı şeyse, ödünleşmeler acı verdiğinde öncelikleri belirlemektir. Örneğin “Sistemi daha basit ve işletmesi kolay tutmak için cevap süresinde biraz yavaşlamayı kabul ediyoruz” iş kararıdır, saf teknik bir karar değildir.

Sınırlar, veri sahipliği ve hata modları

Servis sınırlarını tanımlamak, hangi verinin kime ait olduğunu belirlemek ve kısmi kesintilerde ne olacağını kararlaştırmak derin ürün ve operasyonel bağlam ister. AI hata modlarını beyin fırtınası için önerebilir (“ödeme sağlayıcısı kapandığında ne olur?”), ama beklenen davranışı, müşteri iletişimini ve geri alma planını insanların kararlaştırması gerekir.

Kullanışlı kalan API’ler

API tasarlamak bir sözleşme tasarlamaktır. AI örnekler üretebilir ve tutarsızlıkları bulabilir, ama versiyonlama, geriye uyumluluk ve uzun vadede neyi destekleyeceğinize karar vermeniz gerekir.

İnşa etmeme veya silmeye karar vermek

Belki en mimari karar “hayır” demek veya bir özelliği silmektir. AI fırsat maliyetini veya politik riski ölçemez. Ekipler bunu yapmalı ve yapmalıdır.

Hata Ayıklama ve Kök Neden Analizi (Pratikte)

Hata ayıklama AI’nın etkileyici göründüğü yerlerden biridir—ve aynı zamanda en çok zaman kaybettirebileceği yer. Asistan logları tarayabilir, şüpheli kod yollarını işaret edebilir veya “doğru gibi görünen” bir düzeltme önerebilir. Ancak kök neden analizi sadece açıklamalar üretmek değildir; birini kanıtlamaktır.

AI önerir; siz kök nedeni doğrularsınız

AI çıktısını sonuç değil, hipotez olarak değerlendirin. Birçok hata birden fazla makul nedene sahiptir ve AI genelde yapıştırdığınız kod snippet’ine uyan düzenli bir hikâyeyi seçme eğilimindedir, çalışır sistemin gerçeğini değil.

Pratik iş akışı:

• AI’dan olası nedenleri ve onları ayırt edecek kanıt türlerini isteyin.
• Sorunu yeniden üretin ve o kanıtları toplayın.
• Ancak o zaman bir düzeltmeyi kabul edin (ve başarının gerçekten tekrar etmediğini doğrulayın).

Yeniden üretme ve delil toplama hâlâ insan liderliğinde

Güvenilir bir yeniden üretme yeteneği bir gizemi teste dönüştürdüğü için hata ayıklamada üstündür. AI minimal bir repro yazmanıza, bir diagnostic script taslağı hazırlamanıza veya ek log önermeye yardımcı olabilir, ama hangi sinyallerin önemli olduğunu siz belirlersiniz: request ID’leri, zamanlama, ortam farkları, feature flagler, veri şekli veya eşzamanlılık.

Kullanıcılar belirtiler rapor ettiğinde (“uygulama takıldı”), bunu hangi endpoint’in durduğuna, hangi timeout’ların tetiklendiğine, hangi hata bütçesi sinyallerinin değiştiğine çevirmek gerekir. Bu, ürünün nasıl kullanıldığı ve “normal”in ne olduğuna dair bağlam ister.

“Mantıklı ama yanlış” açıklamalardan kaçının

Bir öneri doğrulanamıyorsa, yanlış olduğunu varsayın. Test edilebilir tahminler yapan açıklamaları tercih edin (ör. “bu sadece büyük payload’larda olur” veya “sadece cache ısındıktan sonra olur”).

Patch, revert veya yeniden tasarım?

Kök nedeni bulduktan sonra bile zor karar kalır. AI seçenekleri özetleyebilir, ama insanlar şu yanıtı seçer:

• Kanamayı durdurmak için hızlı bir patch uygula.
• Bilinen iyi duruma dönmek için revert et.
• Eğer hata daha derin bir uyumsuzluğu gösteriyorsa yeniden tasarla (performans, veri modeli veya varsayımlar).

Kök neden analizi nihayetinde hesap verebilirliktir: açıklamayı, düzeltmeyi ve tekrar etmeyeceğine dair güveni sahiplenmek.

Kod İnceleme: Yargı ve Standartlar Otomatikleşmez

Kod inceleme sadece stil kontrolü değildir. Bir ekip neyi sürdüreceğine, hangi kod için hesap vereceğine ve neyi destekleyeceğine o anda karar verir. AI size daha fazlasını görmede yardımcı olabilir, ama neyin önemli olduğuna, ürün niyetine veya ekibin kabul ettiği ödünleşmelere karar veremez.

İncelemede AI’nın iyi olduğu şeyler

AI kod asistanları yorulmaz ikinci göz gibi davranabilir. Hızla şunları yapabilir:

• muhtemel hataları, şüpheli kalıpları, eksik null kontrollerini veya tehlikeli string işlemlerini işaretlemek
• daha net isimlendirme, refaktör veya daha basit kontrol akışı önermek
• tutarsız biçimlendirme veya bariz çoğaltımı göstermek
• “Bu API boş liste döndürürse ne olur?” gibi inceleme soruları üretmek

Bu şekilde kullanıldığında AI PR açıldıktan kapatılana kadar olan süreyi kısaltır—riskin fark edilmesini hızlandırır.

Hâlâ insan yargısı gerektirenler

Doğruluk kontrolü sadece kodun derlenip derlenmediğiyle ilgili değildir. İnsanlar değişiklikleri gerçek kullanıcı davranışı, üretim kısıtları ve uzun vadeli bakım ile ilişkilendirir.

Bir inceleyicinin hâlâ karar vermesi gerekir:

• Ne gönderilecek: AI sorunları listeleyebilir ama hangilerinin release-blocker olduğu konusunda karar veremez.
• Okunabilirlik ve bakım: “Teknik olarak doğru” kod kafa karıştırıcı, kırılgan veya genişletilmesi zor olabilir.
• Kenar durumlar ve ortam farkları: Birçok hata “makinemde çalışıyor” problemi—konfigürasyon, veri tuhaflıkları, eşzamanlılık veya dağıtım zamanlaması. AI runtime gerçeğinizi güvenilir şekilde çıkaramaz.
• Standartlar ve niyet: Sadece ekip konvansiyonları, risk toleransı ve ürün hedefleri hangi değişikliğin uygun olduğunu bilir.

Pratik iş akışı: AI eş-inceleyici olarak

AI’yı nihai onaylayıcı değil, ikinci bir inceleyici olarak değerlendirin. Belirli bir geçiş isteyin (güvenlik kontrolleri, kenar durumlar, geriye uyumluluk), sonra kapsam, öncelik ve değişikliğin ekip standartları ve ürün niyetiyle uyumu hakkında insan kararı verin.

Test Stratejisi ve Kalite Sahipliği

AI kod asistanları testleri hızlı oluşturabilir, ama kaliteye sahip çıkmazlar. Bir test süiti neyin kırılabileceğine, neyin asla bozulmaması gerektiğine ve hangi kenar durumların kanıtlanmasının gerekli olmadığına dair bahislerin toplamıdır. Bu bahisler ürün ve mühendislik kararlarıdır—halen insanlar tarafından verilir.

AI testleri taslaklar; insanlar hedefleri belirler

Asistanlar birim test iskeleti, bağımlılıkları mock etme ve implementasyondan “mutlu yol” örneklerini üretmede iyidir. Güvenli olmadıkları şeyse hangi kapsamanın önemli olduğu kararını vermektir.

İnsanların tanımlaması gerekenler:

• hangi modüller derin kapsama ihtiyaç duyuyor (güvenlik-kritik veya sık değişenler)
• riskli bir refaktör için “tamam” ne demek vs küçük bir hata düzeltmesi
• regresyon testlerine mi yatırım yapılacak yoksa izleme ve rollback planları mı yeterli

Doğru test türü karışımını seçmek

Çoğu ekip “daha fazla test” yerine katmanlı bir stratejiye ihtiyaç duyar. AI bunların birçoğunu yazabilir, ama seçim ve sınırlar insan odaklıdır:

• Birim testleri iş kuralları ve karmaşık kenar durumları için.
• Entegrasyon testleri veritabanı/kuyruk/servis etkileşimleri için.
• Uçtan uca testler kritik kullanıcı yolculukları için (az, stabil, yüksek değer).
• Kontrat testleri ekipler/arasında API uyumluluğunu korumak için.
• Performans testleri yük altında gecikme ve maliyet koruması için.

Flaky testlerden ve yanlış güven hissinden kaçınma

AI tarafından üretilen testler genellikle koda çok benzer; kırılgan assertion’lar veya aşırı mocklanmış kurulumlar üretebilir ve gerçek davranış başarısızken bile geçebilir. Geliştiriciler bunu önlemek için:

• iç uygulama detayları yerine gözlemlenebilir davranışı test eder
• zamanı, rastgeleliği ve ağ çağrılarını kontrol altında tutar
• başarısızlıkları inceleyip bunun gerçek bir hata mı, test hatası mı yoksa ortam sorunu mu olduğuna karar verir

Stratejiyi risk ve sürüm ritmiyle hizalama

İyi bir strateji nasıl yayınladığınızla eşleşir. Daha hızlı sürümler daha güçlü otomatik kontroller ve net rollback yolları gerektirir; daha yavaş sürümler daha ağır ön-merge doğrulaması kaldırabilir. Kalite sahibi alet değil, ekip olmalıdır.

Önemli sonuçları ölçmek

Kalite bir kapsama yüzdesi değildir. Testlemenin sonuçları iyileştirip iyileştirmediğini izleyin: daha az üretim olayı, daha hızlı kurtarma, daha güvenli değişiklikler (daha az revert, daha hızlı güvenli dağıtım). AI işi hızlandırır; hesap verebilirlik geliştiricilerde kalır.

Güvenlik, Gizlilik ve Uyumluluk Sorumlulukları

Güvenlik işi kod üretmekten çok gerçek kısıtlar altında ödünleşmeler yapmaktır. AI kontrol listeleri ve yaygın hataları ortaya çıkarma konusunda yardımcı olabilir, ama risk kararlarının sorumluluğu ekipte kalır.

Tehdit modelleme bağlam ister

Tehdit modelleme genel bir egzersiz değildir—neyin önemi olduğu işin önceliklerine, kullanıcılara ve hata modlarına bağlıdır. Bir asistan tipik tehditleri (injection, kırık auth, güvensiz varsayılanlar) önerebilir, ama hangi varlığın gerçekten maliyetli olduğunu bilemez: hesap ele geçirilmesi mi, veri sızıntısı mı, servis kesintisi mi veya hangi varlıklar yasal olarak hassas?

Uygulamaya özgü riskler kalıp halinde görünmez

AI bilinen anti-patternleri tanımakta iyi, ama birçok olay uygulamaya özgü detaylardan gelir: izinler kenar durumu, “geçici” bir admin endpoint, veya onayları atlayan bir iş akışı. Bu riskler sistemin niyetini okumayı gerektirir, sadece kodu değil.

Gizli anahtarlar, izinler ve saklama kasıtlı seçimlerdir

Araçlar anahtarları hardcode etmemenizi hatırlatabilir, ama tam politika sahipliği insanlarda kalmalıdır:

• sırların nerede saklandığı (vault, CI, runtime) ve nasıl döndüğü
• en az ayrıcalık rolleri ve erişim incelemeleri
• veri saklama: ne saklanır, ne kadar süre, kim dışa aktarabilir

Bağımlılıklar ve tedarik zinciri riski

AI eski kütüphaneleri işaretleyebilir, ama ekipler hâlâ şu uygulamaları yapmalıdır: versiyonları pinlemek, kaynağı doğrulamak, transitif bağımlılıkları incelemek ve riski kabul etme mı yoksa düzeltmeye yatırım mı yapma kararını vermek.

Uyumluluk ve denetimler kanıt ister

Uyumluluk “şifreleme eklemek”ten ibaret değildir. Kontroller, dokümantasyon ve hesap verebilirlik gerekir: erişim logları, onay izleri, olay prosedürleri ve bunların izlendiğine dair kanıt. AI şablonlar taslaklayabilir, ama insan doğrulaması ve imza gerekir—çünkü denetçiler (ve müşteriler) nihayetinde buna dayanır.

Operasyon, Güvenilirlik ve Olay Müdahalesi

AI operasyon işini hızlandırabilir, ama sahiplenmeyi almaz. Güvenilirlik belirsizlik altında verilen kararların zinciridir ve yanlış bir kararın maliyeti genelde yavaş olmanın maliyetinden yüksektir.

Günlük işlerde AI nerede yardımcı olur

AI operasyon belgeleri—runbook’lar, kontrol listeleri ve “eğer X olursa Y deneyin” oyun kitaplarını taslaklamakta ve sürdürmekte işe yarar. Ayrıca logları özetleyebilir, benzer alarmları kümeleyebilir ve ilk hipotezleri önerebilir.

Güvenilirlik işinde bu şu şekilde daha hızlı yinelemeye dönüşür:

• izleme panoları ve alarm açıklamalarını geliştirme
• kapasite notları ve ölçekleme sezgileri
• hata bütçesi raporlama şablonları

Bunlar hızlandırıcıdır; ama işin kendisi değildir.

İnsanların sahipliğinde kalan parçalar

Olaylar nadiren planlandığı gibi gider. On-call mühendisleri belirsiz sinyaller, kısmi hatalar ve saat işleyen baskı altında ödünleşmelerle uğraşır. AI muhtemel nedenleri öne sürebilir ama başka bir ekibi çağırmak mı, bir özelliği devre dışı bırakmak mı yoksa kısa vadeli müşteri etkisini kabul edip veri bütünlüğünü korumak mı gerektiğine güvenilir şekilde karar veremez.

Dağıtım güvenliği başka bir insan sorumluluğudur. Araçlar rollback, feature flag veya kademeli dağıtım önerebilir ama ekipler iş bağlamını ve blast radius’u düşünerek en güvenli yolu seçmelidir.

Postmortemler: öğrenmek amaçtır

AI zaman çizelgeleri taslağı oluşturabilir ve chat, ticket ve monitoring verilerinden ana olayları çekebilir. İnsanlar hâlâ kritik kısımları yapar: “iyi”nin ne olduğunu tanımlamak, düzeltmeleri önceliklendirmek ve tekrarları önleyen değişiklikleri yapmak (sadece aynı semptomu düzeltmek değil).

AI’yı ops dokümantasyonu ve örüntü bulmada yardımcı pilot olarak kullanırsanız—olay komutanı olarak değil—hız kazanırsınız ama hesap verebilirliği teslim etmezsiniz.

Ekip İletişimi, Mentorluk ve Sahiplik

AI istenildiğinde kavramları açık ve anlaşılır şekilde açıklayabilir: “CQRS nedir?”, “Bu deadlock neden oluyor?”, “Bu PR’ı özetle.” Bu ekiplerin daha hızlı ilerlemesine yardımcı olur. Ancak iş yerindeki iletişim sadece bilgi aktarımı değil—güven inşa etmek, ortak alışkanlıklar oluşturmak ve insanların güvenebileceği taahhütler vermektir.

Onboarding: dokümantasyondan daha fazlası

Yeni geliştiriciler sadece cevaplara değil; bağlam ve ilişkilere ihtiyaç duyar. AI modülleri özetleyerek, okuma yolları önererek ve jargonları çevirebilir. İnsanlar hâlâ öğretmelidir: “burada ne önemlidir”, ekip hangi ödünleşmeleri tercih eder, kod tabanında iyi olan nedir ve bir şey yanlış hissettirdiğinde kimi aramalısın.

Rollerin hizalanması

Proje sürtüşmesi genelde roller arası ortaya çıkar: ürün, tasarım, QA, güvenlik, destek. AI toplantı notları taslaklayabilir, kabul kriterleri önerebilir veya geri bildirimi daha nötr bir dille yeniden ifade edebilir. İnsanlar hâlâ öncelikleri müzakere etmeli, belirsizliği çözmeli ve bir paydaşın “kabul ettiğini” ama aslında kabul etmediğini fark etmelidir.

Tamamlanmış tanımı ve sahiplik sınırları

Ekipler sorumluluk belirsiz olduğunda başarısız olur. AI kontrol listeleri oluşturabilir ama hesap verebilirliği uygulayamaz. İnsanlar “tamam”ın ne anlama geldiğini (testler? dokümantasyon? rollout planı? izleme?), merge sonrası kimin neyi sahiplenmesi gerektiğini tanımlamalıdır—özellikle AI üretilen kod karmaşıklık gizlediğinde.

Kontrol listesi: ekip iş akışlarında sorumlu AI

• AI kullanımını, kararları, tahminleri veya oluşturulan kodu etkilediğinde açıklayın.
• Bağlantıları, API’leri, güvenlik iddialarını ve “en iyi uygulamalar”ı paylaşmadan önce doğrulayın.
• Promptlarda sırları (anahtarlar, müşteri verileri, olay detayları) kullanmayın.
• AI çıktısını taslak olarak ele alın; her karar için bir insan sahibi atayın.
• Ekip normlarını yazın: AI ne zaman kullanılabilir, ne zaman kullanılamaz ve beklentiler nasıl gözden geçirilir.
• Büyük, toplu AI refaktörlerinden kaçının; küçük, incelenebilir değişiklikleri tercih edin.