Yapay Zeka Tarafından Üretilen Kod Tabanlarında Güvenlik, Performans ve Güvenilirlik

AI Tarafından Üretilen Koddan Ne Beklemelisiniz

“AI tarafından üretilen kod” takımınıza ve kullandığınız araçlara bağlı olarak çok farklı anlamlara gelebilir. Bazıları için var olan bir modülde birkaç satırl otomatik tamamlama demektir. Diğerleri için uç noktalar, veri modelleri, migration’lar, test iskeletleri veya bir prompt’tan üretilmiş büyük bir refaktör olabilir. Kaliteyi değerlendirmeden önce, repoda AI tarafından üretilen şeyin ne sayılacağını yazın: snippet’ler, tam fonksiyonlar, yeni servisler, altyapı kodu veya “AI destekli” yeniden yazımlar.

Ana beklenti: AI çıktısı bir taslaktır, garanti değil. Oldukça okunabilir olabilir ama hâlâ kenar durumları kaçırabilir, bir kütüphaneyi yanlış kullanabilir, kimlik doğrulama kontrollerini atlayabilir veya ince performans darboğazları getirebilir. Hızlı bir genç ekip arkadaşından gelen kod gibi ele alın: hız kazandırır ama inceleme, testler ve net kabul kriterleri gerekir.

Eğer bir “vibe-coding” iş akışı kullanıyorsanız (ör. Koder.ai gibi bir platformda bir sohbet promptundan tam özellik üretmek—frontend React, backend Go ve PostgreSQL ile veya bir Flutter mobil uygulaması), bu zihniyet daha da önem kazanır. Üretilen yüzey alanı ne kadar büyükse, “tamamlandı”nın derlenmesinin ötesinde ne anlama geldiğini tanımlamak o kadar önemli olur.

Neden açık kriterlere ihtiyaç var

Güvenlik, performans ve güvenilirlik, onları istemezseniz ve doğrulamazsanız üretilen kodda kendiliğinden ortaya çıkmaz. AI, inandırıcılık ve yaygın desenleri optimize etme eğilimindedir; sizin tehdit modelinizi, trafik şeklinizi, hata modlarınızı veya uyumluluk yükümlülüklerinizi değil. Açık kriterler yoksa, ekipler sık sık demo ortamında çalışan ama gerçek yük veya saldırgan girişim altında başarısız olan kodu merge eder.

Üç temel sütun (ve nasıl örtüştükleri)

• Güvenlik: kötüye kullanımı önlemekle ilgilidir: giriş doğrulama, doğru auth/authz, güvenli varsayılanlar ve gizli/veri yönetiminde dikkat.
• Performans: beklenen ölçeğinizde verimlilikle ilgilidir: öngörülebilir gecikme, gereksiz I/O’dan kaçınma ve kaynak kullanımını kontrol altında tutma.
• Güvenilirlik: zaman içinde doğrulukla ilgilidir: kısmi hataları ele alma, tekrar denemeler, idempotentlik ve bağımlılıklar yavaş veya kapalı olduğunda makul davranış.

Uygulamada bu alanlar örtüşür. Örneğin, hız sınırlama hem güvenliği hem de güvenilirliği iyileştirir; önbellekleme performansı artırabilir ama kullanıcılar arasında veri sızdırırsa güvenliğe zarar verebilir; katı zaman aşımı ayarları güvenilirliği artırır ama yeni hata yollarını ortaya çıkarıp bunların da güvenli hale getirilmesi gerekir.

Bu bölüm temel zihniyeti belirler: AI kod yazmayı hızlandırır, ama “üretime hazır” kalite barını siz tanımlarsınız ve sürekli doğrulamanız gerekir.

Üretilen Koddaki Yaygın Risk Desenleri

AI tarafından üretilen kod genellikle düzenli ve kendinden emin görünür, ama en sık görülen problemler stil meselesi değildir—yargı boşluklarıdır. Modeller derleyen ve temel testleri geçen makul uygulamalar üretebilirken sisteminizin bağlamını sessizce kaçırabilir.

İzlenecek tipik risk alanları

İncelemelerde tekrarlayan kategoriler:

• Girdi işleme: doğrulama eksikliği, güvensiz ayrıştırma, istemci tarafından sağlanan ID’lara güvenme veya SQL/JSON/HTML stringlerini doğrudan oluşturma.
• Kimlik doğrulama ve yetkilendirme: “oturum açıldı” ile “izin verildi” karıştırma, rol kontrollerinin atlanması veya kontrollerin bazı uç noktalarda uygulanıp bazılarında uygulanmaması.
• Hata yönetimi: hata mesajlarında dahili detay sızdırma, istisnaları yutma, kısmi başarılarda başarı dönme veya gerçek sorunları gizleyen geniş catch blokları kullanma.
• Eşzamanlılık ve durum: yarış koşulları, iş parçacığı güvenli olmayan önbellekler, naif kilitlemeden kaynaklanan deadlock’lar ve tek istekte yürütme varsayımlarının yanlış olması.

Atlardan kaçan “bilinmeyen bilinmeyenler”

Üretilen kod gizli varsayımlar taşıyabilir: saat dilimlerinin hep UTC olduğu, ID’lerin her zaman sayısal olduğu, isteklerin hep düzgün biçimlendirilmiş olduğu, ağ çağrılarının hep hızlı olduğu veya tekrar denemelerin hep güvenli olduğu gibi. Ayrıca kısmi uygulamalar içerebilir—güvenlik kontrolü yerleştirilmemiş, TODO yolu veya kapalı kalmak yerine varsayılan veri döndüren bir fallback.

Bağlam olmadan desen kopyalama

Yaygın başarısızlık modu, başka bir yerde doğru olan bir deseni burada bağlamı olmadığı halde ödünç almaktır: doğru parametrelerle kullanılmayan bir hashing yardımcı fonksiyonunu yeniden kullanmak, çıktınıza uymayan genel bir sanitize ediciyi uygulamak veya isteği istemeden artıran bir retry döngüsü benimsemek.

Sahiplik devredilmez

Kod üretilse bile, sorumluluk insanlardadır; üretim davranışından insanlar sorumludur. AI çıktısını bir taslak olarak ele alın: tehdit modelini, kenar durumları ve sonuçları siz üstlenirsiniz.

Basit Bir Tehdit Modeliyle Başlayın

AI tarafından üretilen kod kendinden emin ve eksiksiz görünme eğilimindedir—bu da kolayca şu temel soruyu atlamanızı sağlar: “Ne koruyoruz ve kimden koruyoruz?” Basit bir tehdit modeli, güvenlik kararlarını kod sabitlenmeden önce açık tutan kısa, sade bir alışkanlıktır.

Varlıkları, aktörleri ve güven sınırlarını tanımlayın

İlk olarak, ele geçirilmesi zarar verici olan varlıkları adlandırın:

• Veri: müşteri PII’si, auth tokenları, API anahtarları, faturalar
• Para hareketi: ödemeler, iade, kredi, ödeme çıkışları
• Yönetici işlemleri: kullanıcı rol değişiklikleri, feature flag’ler, veri dışa aktarımları
• Çalışma süresi: istekleri servis etme yeteneğinin kesintiye uğramaması

Sonra aktörleri listeleyin: normal kullanıcılar, yöneticiler, destek personeli, harici servisler ve saldırganlar (credential stuffing, dolandırıcılar, botlar).

Son olarak güven sınırlarını çizin veya tanımlayın: browser ↔ backend, backend ↔ veritabanı, backend ↔ üçüncü taraf API’ler, dahili servisler ↔ halka açık internet. Eğer AI, bu sınırlar arasında “hızlı” kısayollar öneriyorsa (ör. halka açık bir uç noktadan doğrudan veritabanı erişimi), bunu hemen işaretleyin.

Koda başlamadan önce çalıştırılacak hafif bir kontrol listesi

Kısa tutun ki gerçekten kullanılsın:

1. Kötü niyetli bir kullanıcı bu özellik ile en kötü ne yapabilir?
2. Hangi girdiler bir güven sınırını geçiyor (formlar, webhooks, header’lar, dosyalar)?
3. Özellikle yönetici ve para işlemleri için ne yetkilendirme gerektiriyor?
4. Hangi olayların log’lanması ve uyarılması gerekir (başarısız auth, yüksek değerli işlemler)?
5. Güvenli hata modu nedir (varsayılan olarak reddet, hız sınırı, rollback)?

İnceleyenlerin göreceği yere kararları belgeleyin

Yanıtları PR açıklamasına yazın veya karar uzun ömürlü ise kısa bir ADR (Architecture Decision Record) oluşturun (örn. token formatı, webhook doğrulama yaklaşımı). Gelecekteki inceleyenler böylece AI tarafından yapılan değişikliklerin orijinal niyetle hâlâ örtüşüp örtüşmediğini ve hangi risklerin bilerek kabul edildiğini görebilir.

Kod İncelemeleri için Güvenlik Kontrol Listesi

AI tarafından üretilen kod temiz ve tutarlı görünebilir ama yine de varsayılanlar, hata yönetimi ve erişim kontrolleri etrafında güvenlik tuzakları saklayabilir. İnceleme sırasında stilden çok “bir saldırgan bununla ne yapabilir?” sorusuna odaklanın.

Çoğu sorunu yakalayan hızlı kontroller

• Güvenli varsayılanları kontrol edin: deny-by-default, en az ayrıcalık, minimal maruziyet.
• Girdi doğrulama ve çıktı kodlamasını doğrulayın (ilgili olduğunda).
• Gizli bilgilerin kaynakta gömülmediğinden emin olun; çevre/depo gizli yöneticisinden yüklenmeli.
• Güvenli hata mesajlarını onaylayın (yanıtlar içinde yığın izi veya hassas veri yok).
• Yetkilendirme (authz) sunucu tarafında uygulanıyor mu? UI’daki kontroller yeterli değildir.

İncelemede diff’te bakılması gerekenler

Güven sınırları. Verinin sisteme nereden girdiğini (HTTP istekleri, webhooklar, kuyruklar, dosyalar) belirleyin. Doğrulamanın sınırda yapıldığından emin olun, “sonradan bir yerde” değil. Çıktı için, bağlama uygun kodlamanın (HTML, SQL, shell, loglar) yapıldığını kontrol edin.

Kimlik doğrulama vs yetkilendirme. AI kodu sıklıkla isLoggedIn kontrolleri içerir ama kaynak seviyesi yetkiyi kaçırır. Her hassas eylemin hangi kişinin hangi nesne üzerinde işlem yapabileceğini kontrol ettiğini doğrulayın (ör. URL’deki userId sadece var mı diye kontrol edilmemeli; izin kontrolü yapılmalı).

Gizli bilgiler ve konfigürasyon. API anahtarları, tokenlar ve bağlantı dizileri kaynakta, örnek konfigürasyonda, loglarda veya testlerde olmamalı. Ayrıca “debug modu”nun varsayılan olarak etkin olmadığını kontrol edin.

Hata yönetimi ve loglama. Hataların ham istisnalar, yığın izleri, SQL hataları veya dahili ID’ler döndürmediğinden emin olun. Loglar faydalı olmalı ama kimlik bilgileri, erişim tokenları veya kişisel veriler sızdırmamalı.

İnceleyici için küçük ama faydalı bir alışkanlık

Riskli yol başına bir negatif test isteyin (yetkisiz erişim, geçersiz girdi, süresi dolmuş token). Kod böyle test edilemiyorsa, genellikle güvenlik sınırının net olmadığı işaretidir.

Bağımlılık ve Tedarik Zinciri Güvenliği

AI tarafından üretilen kod genellikle paketler ekleyerek “çözüm” getirir. Bu, saldırı yüzeyini ve bakım yükünü sessizce genişletebilir: daha fazla bakımcı, daha fazla güncelleme trafiği ve istemeden çekilen dolaylı bağımlılıklar.

Göndereceğiniz şeyi kilitleyin

Bağımlılık seçimini kasıtlı yaparak başlayın.

• Versiyonları sabitleyin (lockfile’ları repoya ekleyin) ki CI ve geliştiricide tekrarlanabilir derlemeler olsun.
• Güvenilir kayıtları tercih edin (mümkünse dahili ayna).
• Her yeni paketi bir değişiklik isteği gibi değerlendirin: neden gerekli, kim bakım yapıyor, lisans durumu ve güvenlik geçmişi.

Basit bir kural iyi işler: her yeni bağımlılık için PR açıklamasına kısa bir gerekçe yazılmadan ekleme yok. AI bir kütüphane önerdiyse, standart kütüphane veya zaten onaylı bir paketle halledilip halledilemeyeceğini sorun.

CI taramaları ekleyin—ve sonrasında ne yapılacağını tanımlayın

Otomatik taramalar sadece bulgular aksiyon üretiyorsa kullanışlıdır. Ekleyin:

• Bilinen zafiyetleri işaretleyen SCA (Software Composition Analysis)
• Üretilen kod ve konfigürasyonda sızan gizli anahtarları yakalayacak secret scanning

Sonra iş kurallarını belirleyin: hangi şiddet seviyesinin merge’i engellediği, hangilerinin bir issue ile zaman kutusuna alınabileceği ve kimlerin istisnayı onaylayacağı. Bu kuralları katkı rehberinizde belgeleyin.

Dolaylı risk ve bağımlılık şişkinliğine dikkat edin

Çoğu olay dolaylı bağımlılıklardan gelir. PR’lerde lockfile farklarını inceleyin ve kullanılmayan paketleri düzenli olarak temizleyin—AI kodu “ihtimal” için yardımcı import’lar ekleyebilir ve asla kullanmayabilir.

Güncelleme sürecini belgeleyin

Güncellemelerin nasıl yapılacağını yazın (zamanlanmış bump PR’leri, otomatik araçlar veya manuel) ve kim onaylıyorsa bunu belirtin. Net sahiplik, zayıf ve savunmasız paketlerin üretimde kalmasını önler.

Performans: “İyi” Ne Demek

Performans “uygulama hızlı hissetmesi” değildir. İnsanların ürünü gerçekte nasıl kullandığına ve çalıştırma maliyetine bağlı ölçülebilir hedefler setidir. AI tarafından üretilen kod çoğunlukla testleri geçer ve temiz görünür ama yine de CPU yakar, veritabanına çok sık gider veya gereksiz bellek ayırır.

Net performans hedefleri belirleyin

Herhangi bir şeyi optimize etmeden önce “iyi”yi sayısal olarak tanımlayın. Tipik hedefler:

• Yanıt süresi: ana uç noktalar veya kullanıcı eylemleri için p95 ve p99 gecikme
• Verim: beklenen zirvede saniye başına istek veya dakika başına iş
• Kaynak kullanımı: yük altında CPU, bellek, disk I/O, ağ I/O
• Maliyet: 1.000 istek/iş başına bulut harcaması

Bu hedefler gerçekçi iş yüküne (mutlu yol + yaygın sıçramalar) bağlı olmalı, sentetik tek bir benchmark’a değil.

Darboğazların genellikle nerede saklandığını bilin

AI tarafından üretilen kod tabanlarında verimsizlik genellikle öngörülebilir yerlerde ortaya çıkar:

• Veritabanı çağrıları: çok konuşkan erişim modelleri, eksik indeksler, tekrarlanan sorgular
• N+1 sorguları: ilişkili veriyi döngü içinde satır satır alan sorgular
• Dosya veya JSON ayrıştırma: büyük payload’ları tekrar tekrar veya ağır kütüphanelerle ayrıştırma
• Sıkı döngüler: iterasyon başına gereksiz işler, yanlış veri yapıları, ekstra tahsisatlar

Üretilen kod genellikle “yapı itibariyle doğru” ama “varsayılan olarak verimli” değil. Modeller okunabilir, genel yaklaşımları seçme eğilimindedir (fazla soyutlama, tekrar dönüşümler, sınırsız sayfalama)—kısıtları belirtmezseniz.

Optimize etmeden önce profil çıkarın

Tahmin yürütmekten kaçının. Üretime benzeyen bir ortamda profil ve ölçümle başlayın:

• Uygulama profilleyicisi (CPU/bellek) ve veritabanı zamanlaması için sorgu izleme kullanın.
• Gecikme yüzdeliklerini ve en yavaş uç noktaları toplayın; ilk 2–3 dar boğazı belirleyin.
• Bir kerede tek değişiklik yapın ve etkinliği yeniden ölçün.

Hedeflerinize karşı bir öncesi/sonrası iyileşmesi gösteremiyorsanız, yaptığınız değişiklik optimizasyon değil, gereksiz uğraştır.

Pratik Performans Korumaları

AI tarafından üretilen kod genellikle “çalışıyor” ama gizlice zaman ve para yakar: ekstra veritabanı turları, istemeden N+1 sorguları, büyük veri kümeleri üzerinde sınırsız döngüler veya bitmeyen tekrar denemeler. Korumalar performansı kahramanca bir sonradan uğraş değil, varsayılan haline getirir.

Önbellekleme, çıkış planıyla kullanılsın

Önbellekleme yavaş yolları gizleyebilir ama veriyi sonsuza dek bayat da bırakabilir. TTL, event tabanlı invalidasyon veya versiyonlanmış anahtar gibi net bir invalidasyon stratejisi olması gerekir. Bir önbelleğe alınan değerin nasıl yenileneceğini açıklayamıyorsanız, önbellekleme yapmayın.

Beklemeyi bilinçli kılın

Zaman aşımı, tekrar denemeler ve backoff ayarlarının kasıtlı yapıldığından emin olun (sonsuz beklemeler olmasın). Her dış çağrı—HTTP, veritabanı, kuyruk veya üçüncü taraf API—için:

• Makul bir timeout
• Sınırlı tekrar denemeler
• Jitter ile exponential backoff
• Net bir hata modu (fallback, kısmi yanıt veya hızlı hata)

Bu, yük altındayken kaynakları meşgul eden “yavaş başarısızlıkların” önüne geçer.

Async sınırlarına saygı gösterin

Async yollar içinde bloklayıcı çağrılardan kaçının; thread kullanımını kontrol edin. Yaygın suçlular: senkron dosya okuma, event loop üzerinde CPU ağırlıklı işler veya async handler içinde bloklayıcı kütüphaneler kullanmak. Ağır hesaplama gerekiyorsa offload edin (işçi havuzu, arka plan işi veya ayrı bir servis).

Büyük veriler için baştan tasarlayın

Toplu işlemler ve sayfalama sağlayın. Bir koleksiyon döndüren herhangi bir uç nokta limit ve cursor desteklemeli; arka plan işler parçalar halinde işlemeli. Bir sorgu kullanıcı verisiyle büyüyebiliyorsa, bununla yaşanacağını varsayın.

Regresyonları göndermeden yakalayın

CI’ya performans testleri ekleyin. Küçük ama anlamlı olsunlar: birkaç sıcak uç nokta, temsilî bir veri seti ve eşikler (gecikme yüzdelikleri, bellek ve sorgu sayıları). Başarısızlıkları test başarısızlığı gibi ele alın—"yeniden çalıştırıp geçene kadar bekleme" değil, inceleyip düzeltme yapın.

Güvenilirlik: Gerçek Koşullar Altında Doğruluk

Güvenilirlik sadece “çökme yok” demek değildir. AI tarafından üretilen kod için, sistemin dağınık girdiler, kesintili servisler ve gerçek kullanıcı davranışı altında doğru sonuç üretmesi; üretemediğinde ise kontrollü şekilde başarısız olması anlamına gelir.

Güvenilirlik sonuçlarını önceden tanımlayın

Uygulama ayrıntılarına bakmadan önce, her kritik yol için “doğru”nun nasıl görüneceği konusunda anlaşın:

• Doğru sonuçlar: doğru verinin yazılması, doğru yanıtın dönmesi, sessiz veri kaybı veya yuvarlama sürprizleri olmaması
• Nazik başarısızlık: net hata mesajları, güvenli varsayılanlar ve bir şey ters gittiğinde bozuk durum olmaması
• Öngörülebilir iyileşme: tekrarlar, replay’ler ve yeniden başlatmalar çiftlere/çoğaltmalara veya sürüklenmeye yol açmamalı

Bu sonuçlar, inceleyenlere AI tarafından yazılan mantığı değerlendirirken standart sağlar—mantıklı görünse bile kenar durumları gizlenmiş olabilir.

Tekrarlanabilir işlemler için idempotentlik

AI tarafından üretilen handlerlar sıklıkla “sadece işi yapıp” 200 döner. Ödemeler, iş işleme ve webhook alımı için bu risklidir çünkü tekrarlar normaldir.

Kodu idempotent kılacak şeyleri kontrol edin:

• Sabit bir idempotency anahtarı (istek ID’si, olay ID’si, ödeme niyeti ID’si)
• “Zaten işlendi” işini saklayan kalıcı kayıt
• Çift teslimde güvenli davranış (çift ücretlendirme, çift e-posta, çift satır yok)

İşlemler ve tutarlılığı açıkça belirtin

Akış veritabanına, kuyruğa ve önbelleğe dokunuyorsa, tutarlılık kurallarının kodda açıkça yazılı olduğundan emin olun—varsayılmasın.

Arananlar:

• Birden çok yazmanın birlikte başarılı olması gereken yerlerde DB transaction’ları
• “Durumu yazma” ile “olay yayınlama” arasında net sıra (veya outbox pattern)
• Kaçırılan güncellemeleri tolere edebilen cache invalidation

Servisler arasındaki kısmi hataları ele alın

Dağıtık sistemler parça parça çöker. Kodun “DB yazıldı, olay yayınlanamadı” veya “HTTP çağrısı timeout oldu ama uzak taraf başarılı oldu” gibi senaryoları ele aldığını doğrulayın.

Sonsuz tekrarlar veya sessiz yutmalar yerine zaman aşımı, sınırlı tekrarlar ve dengeleme eylemlerini tercih edin. Bu durumları testlerde doğrulayın (daha sonra /blog/testing-strategy-that-catches-ai-mistakes adresinde ele alındığı gibi).

AI Hatalarını Yakayan Test Stratejisi

AI tarafından üretilen kod genellikle “tamamlanmış” görünür ama boşluklar gizleyebilir: eksik kenar durumları, girdiler hakkında iyimser varsayımlar ve asla çalıştırılmamış hata yolları. İyi bir test stratejisi her şeyi test etmekten çok, sürpriz yaratabilecek şeyleri test etmektir.

Katmanlı bir test seti oluşturun

Önce mantık için unit testleri, sonra gerçek sistemlerin mock’lardan farklı davranabildiği yerler için integration testleri ekleyin.

• Mantık için unit testleri; veritabanı/kuyruk/harici API’ler için integration testleri
• Gerçekçi fixture’lar kullanın ve hataları gizleyen kırılgan mock’lardan kaçının

En çok hata glue kodunda çıkar: yanlış SQL varsayımları, hatalı retry davranışı veya hatalı API modellemesi.

Kasıtlı olarak “mutlu olmayan yolları” test edin

AI kodu genellikle hata yönetimini az belirtir. Sistemin güvenli ve öngörülebilir tepki verdiğini kanıtlayan negatif testler ekleyin.

• Negatif testler: geçersiz girdiler, auth hataları, zaman aşımı, boş durumlar

Bu testler önemli çıktılara (doğru HTTP durum kodu, hata mesajlarında veri sızıntısı olmaması, idempotent tekrarlar, kibar fallback’ler) assert koymalı.

Girdi ağırlıklı kodu generatif testlerle zorlayın

Bir bileşen girdileri ayrıştırıyorsa, sorgu kuruyorsa veya kullanıcı verisini dönüştürüyorsa, geleneksel örnekler garip kombinasyonları kaçırır.

• Girdi ağırlıklı bileşenler için uygun olduğunda property-based veya fuzz testleri ekleyin

Property-based testler sınır hatalarını (uzunluk limitleri, kodlama sorunları, beklenmeyen null’lar) yakalamada özellikle etkilidir.

Kapsam: bir taban belirleyin, sonra riske odaklanın

Kapsam sayıları asgari bir bar olarak yararlıdır, hedef değil.

• Minimum kapsam hedefleri belirleyin, ama yüksek riskli yolları önceliklendirin

Önceliklendirme: kimlik doğrulama/yetkilendirme kararları, veri doğrulama, para/credit işlemleri, silme akışları ve retry/zaman aşımı mantığı. Emin değilseniz hangi yolun “yüksek risk” olduğunu görmek için isteği halka açık uç noktadan veritabanı yazısına kadar izleyin ve yol üzerindeki dalları test edin.

Gözlemlenebilirlik ve Olay Hazırlığı

AI tarafından üretilen kod “bitti” görünürken işletilmesi zor olabilir. Ekiplerin üretimde en çok yandığı durum genellikle eksik görünürlüktür. Gözlemlenebilirlik sürpriz bir olayı rutin bir düzeltmeye çevirir.

Gerçekten işe yarayan loglar

Yapılandırılmış loglamayı zorunlu kılın. Düz metin loglar yerelde yeterli olabilir ama çoklu servis ve dağıtım olduğunda ölçeklenmez.

Zorunluluklar:

• İstek ID’leri (servisler arasında taşınsın ve her log satırında yer alsın)
• Ana bağlam alanları: kullanıcı/hesap ID’si (uygun olduğunda), uç nokta, yöntem, durum kodu, gecikme, hata tipi
• Tutarlı anlamlı seviye düzeyleri (debug/info/warn/error)

Hedef: tek bir istek ID’si ile “ne oldu, nerede ve neden” sorularına tahmin etmeye gerek kalmadan cevap alınabilmesi.

Gerçek hatalarla eşleşen metrikler

Loglar neden olduğunu anlatır; metrikler ne zaman bozulma başladığını söyler.

Ekleyin:

• Uç nokta veya iş tipi bazında gecikme (p50/p95/p99)
• Hata oranları (5xx, tekrar denemeler, zaman aşımı, başarısız işler)
• Doygunluk: CPU, bellek, thread/worker havuzu kullanımı
• Kuyruk derinliği / backlog (asinron işlem için)

AI kodu genellikle gizli verimsizlikler getirir (fazladan sorgular, sınırsız döngüler, chatty ağ çağrıları). Doygunluk ve kuyruk derinliği bunları erken yakalar.

Eyleme götüren uyarılar

Bir uyarı grafik yerine bir karara işaret etmelidir. Gürültülü eşiklerden kaçının (“CPU > %70”)—bunlar kullanıcı etkisine bağlı olmadıkça anlamsız olabilir.

İyi uyarı tasarımı:

• SLO-vari sinyaller: “p95 gecikme X’i 10 dakika aştı” veya “hata oranı Y%’nin üstünde”
• Açık sahiplik: kim çağrılır kim bildirilir
• Oyun kitabı bağlantıları: kısa “ilk kontroller” bölümü ve runbook linki

Uyarıları kasıtlı test edin (staging’de veya planlı tatbikat sırasında). Uyarının gerçekten tetiklenip eyleme dönüştüğünü doğrulayamıyorsanız, o uyarı umut olmaktan öte değildir.

Runbook’lar: gelecekteki kendiniz minnettar kalır

Kritik yollar için hafif runbook’lar yazın:

• İlk önce ne kontrol edilmeli (panolar, son deploylar, bağımlılık durumu)
• Nasıl hafifletilir (feature flag kapat, ölçek yükselt, arka plan işini devre dışı bırak)
• Nasıl geri alınır (kesin komut/süreç, artifact’ların nerede olduğu)
• Kimi bilgilendireceksiniz (on-call, ürün sahibi, olay kanalı)

Runbook’ları kod ve süreçlere yakın tutun (ör. repoda veya dahili dokümanda), böylece sistem değiştiğinde güncellenirler.

Güvenli, Tekrarlanabilir Sürümler için CI/CD Kontrolleri

AI tarafından üretilen kod akışı hızı artırabilir ama varyansı da artırır: küçük değişiklikler güvenlik sorunları, yavaş yollar veya gizli doğruluk hataları getirebilir. Disiplinli bir CI/CD hattı bu varyansı yönetilebilir kılar.

Bu aynı zamanda uçtan uca üretim iş akışlarının ekstra disipline ihtiyaç duyduğu yerdir: bir araç hızlıca üretebilir ve deploy edebilir (Koder.ai gibi yerleşik dağıtım/barındırma, özel domainler ve snapshot/geri alma ile), pipeline kapıları ve geri alma prosedürleriniz de benzer hız ve standarda sahip olmalı—böylece hız güvenliğe mal olmaz.

Her değişiklikte “kalite kapıları” uygulayın

Pipeline’ı merge ve release için asgari bar olarak değerlendirin—“acil düzeltme” için istisna yok. Tipik kapılar:

• Formatlama + lint: diff’leri okunur tutmak ve yaygın hatalardan kaçınmak
• Unit + integration testleri: net geçme/kırılma kriterleri (flaky testlere izin yok)
• Güvenlik kontrolleri: SAST, gizli anahtar taraması, bağımlılık zafiyet taramaları
• Derleme tekrarlanabilirliği: sabit araç versiyonları, kilitlenmiş bağımlılıklar, deterministik build çıktıları

Önemli bir kontrolse blocklayıcı yapın. Gürültülü ise ince ayar yapın—görmezden gelmeyin.

Atılım değil, aşamalı gönderimler yapın

“Aynı anda herkese” dağıtımları yerine kontrollü açılışları tercih edin:

• Riskli davranış değişiklikleri için feature flag’ler
• Trafiğin küçük bir dilimine canary release
• Platform destekliyorsa blue/green deployment

Otomatik geri alma tetiklerini (hata oranı, gecikme, doyma) tanımlayın ki rollout kullanıcı hissinden önce durdurulsun.

Geri alma işlemini sıradan hale getirin—ve pratik yapın

Geri alma planı hızlı değilse gerçek değildir. Veritabanı migration’larını mümkün olduğunca tersine çevrilebilir tutun; tek yön şema değişikliklerinden kaçının veya test edilmiş bir ileri-düzeltme planınız olsun. Periyodik “geri alma tatbikatları” yapın.

Ne değişti ve kim onayladı takip edin

Niyet, risk ve test notlarını yakalayan PR şablonları zorunlu kılın. Sürümler için hafif bir değişiklik günlüğü tutun ve net onay kuralları uygulayın (ör. rutin değişiklikler için en az bir onay, güvenlik hassasiyeti olan alanlar için iki onay). Daha derin bir inceleme iş akışı için /blog/code-review-checklist adresine bakın.

“Üretime Hazır” İçin Pratik Bir Tanım

AI tarafından üretilen kod için “üretime hazır” demek “makinemde çalışıyor” demek olmamalı. Bunun anlamı: kod bir ekip tarafından güvenle işletilebilir, değiştirilebilir ve güvenilebilir—gerçek trafik, gerçek hatalar ve gerçek teslim tarihlerinde.

Vazgeçilmezler (asgari bar)

Herhangi bir AI-üretimli özellik gönderilmeden önce bu dört madde doğru olmalı:

• Güvenlik incelemesi tamam: tehdit modeli varsayımları kayıtlı, riskli girdiler tanımlı ve auth, veri erişimi, gizli yönetimi insan tarafından incelenmiş.
• Testler geçiyor (anlamlı): çekirdek davranış için unit + integration kapsama ve en olası kötüye kullanım için en az bir negatif test.
• İzleme yerinde: kullanıcı etkisi (hatalar, gecikme) ve iş-kritik akışlar için metrikler, loglar ve uyarılar.
• Geri alma mümkün: release hızlıca geri alınabilir (feature flag veya bilinen iyi build) ve kahramanlık gerektirmeden yapılabilmeli.

Sahiplik: kim pageri taşır?

AI kod yazabilir ama sahiplenemez. Her üretilmiş bileşen için net bir sahibi atayın:

• Servis/ekip sahibi: düzeltmeler, on-call ve takip güçlendirmelerinden sorumlu
• Bağımlılık sahibi: kütüphane güncellemelerinden, advisory incelemesinden ve üçüncü taraf paketlere güvenin yenilenmesinden sorumlu

Sahiplik net değilse, üretime hazır değildir.

Ekiplerin bugün benimseyebileceği hafif bir kontrol listesi

Kullanılacak kadar kısa tutun:

1. Girdiler doğrulandı; authz açık; kodda veya loglarda gizli yok.
2. Hata modları belgelenmiş (timeout, retry, limitler) ve güvenli varsayılanlar ayarlanmış.
3. Testler mutlu yol + kenar durumları kapsıyor; CI yeşil.
4. Panolar/uyarılar hata oranı, gecikme ve doyma için var.
5. Bağımlılıklar sabitlenmiş ve incelenmiş; güncelleme yolu not edilmiş.

İlk 30 gününüz: temel → ölç → sıkılaştır

• 1–7. günler: temel güvenlik tarama sonuçları, performans bütçesi ve güvenilirlik SLO’ları belirleyin.
• 8–21. günler: eksik testleri, kritik uyarıları ve bağımlılık sabitlemeyi ekleyin.
• 22–30. günler: CI/CD kapılarını sıkılaştırın (başarısız testlerde, yüksek şiddetli zafiyetlerde ve eksik gözlemlenebilirlikte merge’i engelle) ve tekrar ölçüp yineleyin.

Bu tanım “üretime hazır”ı somut tutar—daha az tartışma, daha az sürpriz.