Sat Aug 29 2026
Hazırsan başlayalım 🚀
Artık AI kod yazıyor, testleri koşturuyor hatta PR’ları özetliyor. Biz geliştiriciler ise reviewer rolüne itildik. Bu durum sadece “kod okumak” değil, stratejik kararlar almak demek.
Hadi birlikte bu yeni rolü keşfedelim ve reviewer olmanın keyfini çıkarayalım! ✨
🤖 Otomasyon saplantısı ve bilişsel yük artışı, geliştiricilerin kod gözden geçirme (code review) sürecini nasıl ihmal ettiklerini görelim.
# AI tarafından üretilen bir doğrulama fonksiyonu
def validate_user_input(data: dict) -> bool:
# Basit bir kontrol, ama eksik
return "email" in data and "@" in data["email"]
Ne yanlış gitti?
@ varlığına bakıyor, format ve domain kontrolü yok.None veya injection payload'ları geçiyor.| Etki | Açıklama |
|---|---|
| Gizli bug'lar | Basit kontroller atlandığında production'da patlıyor. |
| Teknik borç | Hızlı onay → refactor yok → gelecekte büyük maliyet. |
| Güven kırılması | Takım arkadaşları AI çıktısına kör güvenmeye başlıyor. |
Kısa özet: AI harika bir yardımcı, ama insan incelemesini tamamen değiştiremez. Her PR’da en az bir gerçek göz geçirmeli, test yazmalı ve edge‑case’leri sorgulamalıyız. ✅
Neden her şeyi otomatikleştirmek istiyoruz?
Ne oluyor aslında?
Sonuç ne?
Kısa bir mola verelim:
Otomasyon bir yardımcı olmalı, patron değil.
Ne yapabiliriz?
Özetle: Otomasyon saplantısı, hız kazandırıyor gibi görünse de aslında insansal dikkati parçalayıp bilişsel yükü zirveye taşıyor. Dengeyi kurmak, araçları bizim için çalıştırmak – onlara boyun eğmemek demek. 🚀
Hadi dürüst olalım: code review artık eskisi gibi değil 😅
Benim takımımda yaptığımız son anketin sonuçları beni şaşırttı (ve biraz da korkuttu):
1. "LGTM" kültürü yaygınlaştı
Önceki sprint'te bir junior geliştiricimiz console.log bırakmıştı production'a. Reviewer: "LGTM 👍". Deploy edildi. Müşteri şikayeti geldi. Basit bir grep yapabilirdi ama yapılmadı.
2. Context switching katliam yapıyor
Bir senior arkadaşım: "Günde 8-10 PR review ediyorum, arada meetingler var. 15 dakikada bitirmek zorundayım." → Ortalama review süresi: 12 dakika. Bu sürede ne anlarsınız?
3. "Benim değil, CI/CD yakalar" psikolojisi
Senaryo: E-tcheckout servisinde
nullcheck eksikliği → %15 conversion drop 2 saat sürdü.
// PR'daki kod (review onaylanmıştı 😱)
const processPayment = (user: User) => {
const amount = user.cart.total; // user.cart null olabilir!
paymentGateway.charge(amount);
};
Reviewer yorumu: "İyi görünüyor, testler geçiyor ✅"
Gerçeklik: user.cart optional idi, test mock'ında dolu geliyordu. Edge case atlandı.
| Metrik | 6 Ay Önce | Şimdi |
|---|---|---|
| Ortalama review derinliği (dosya başına yorum) | 3.2 | 1.1 |
| "Nitpick" dışı yorum oranı | %41 | %18 |
| Production'a sızan bug sayısı / sprint | 2.1 | 4.7 |
| Reviewer burnout şikayeti | %12 | %38 |
Özetle: Araçlar gelişti, otomasyon arttı... ama insan faktörü geriledi. Bunu kabul etmezsek, production'da yine biz öderiz 💸
Sizinde takımdan benzer veriler var mı? Yorumlarda paylaşalım 👇
Merhaba arkadaşlar! Bugün karşıtlıklı incelemeyi (adversarial review) tanıtıyorum. Kısaca: AI tarafından üretilen kodu ve önceki gözden geçirme yorumlarını bilerek, ikinci bir gözden geçirme görevlisi bu kodu eleştirir. Böylece güvenlik ve kalite artar 🚀
Özetle: Karşıtlıklı inceleme, AI ile yazılan kodu ikinci bir kritikal bakış altına alarak güvenliği ve kaliteyi bir üst seviyeye taşır. Küçük bir süre ekler ama uzun vadede büyük kazanımlar sağlar 🌟
Hazırsan bu yeni piramidi bir kenara çekip hız ile kapsama arasındaki dengeyi nasıl kurduğunu inceleyelim 🚀
İpucu: Test sayısını artırırken mock kullanımını minimumda tut. Gerçek mantığı test et, altyapıyı değil.
Hız: Saniyeler sürer.
Kapsama: Birden fazla modül / servis arasındaki sözleşme.
Amaç: Veri akışını ve API kontratlarını doğrulamak.
Strateji:
Hız: Dakikalar.
Kapsama: Kullanıcı yolculuğu tamamiyle (UI → API → DB).
Amaç: Kritik iş akışlarının canlı ortamda bozulmadığını kanıtlamak.
Pratik Tavsiyeler:
| Özellik | Ne Sağlar? |
|---|---|
| Otomatik veri üretimi | Sınır değerleri, hatalı formatlar, injecting attack vektörleri. |
| Model‑based fuzzing | Önceden öğrenilen davranış modelleriyle beklenmedik yolları keşfeder. |
| Continuous learning | Her başarısız test, modeli günceller → gelecekte daha akıllı testler. |
Neden bu katman?
| Katman | Çalışma Süresi | Test Sayısı (Örnek) | Kapsama % |
|---|---|---|---|
| Unit | < 1 s | 2 000+ | %70 |
| Integration | 5–30 s | 300 | %20 |
| E2E | 1–5 dk | 50 | %8 |
| AI Adversarial | 30 s–2 dk | 100 (otomatik) | %2 (risk odaklı) |
Böylece hızlı iterasyon yaparken de gizli hataları ve güvenlik açıklarını erken yakalıyorsun. 🎉
Sonuç: Yeni piramit, geliştirici deneyimini bozmadan kaliteyi ve güvenliği bir üst seviyeye taşır. Hazır mısın? Hadi bir pilot proje üzerinde deneyelim! 🚀
AI geliştirme sürecini güvenli hale getirmek istiyorsan, uyarı sistemlerine odaklan. AI‑Guard, CodeArena gibi araçlar, CI/CD kullanıcılarının alışkın olduğu sadece birkaç satır konfigürasyonla otonom bir “güvenlik müfettişi” görevi görür.
Neden AI‑Audit araçlarını kullanmalısın?
# .github/workflows/ai-guard.yml
name: AI Guard Scan
on: [push, pull_request]
jobs:
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: AI‑Guard kontrolu çalıştır
run: |
pip install ai-guard
ai-guard scan \
--source ./src \
--model-config model.yml \
--report-dir reports
Yukarıdaki örnekte GitHub Actions eylemi, kaynak kodunu kontrol ettikten sonra AI‑Guard'ı çalıştırır. Aracı kendi model.yml dosyan ile konfigüre edebilir, raporları özel bir depoya yönlendirebilir veya arama üzerinden hizmete entegre edebilirsin.
Bu sayede ne oluyor?
push veya PR, kaynak kodunun güvenlik açısından güvenli olup olmadığını hemen gösteren bir rapor ile birlikte döndürülür.CodeArena, yapay zekâ tabanlı kodu otomatik olarak yorumlar, güvenlik risklerini belirler ve Jenkins Pipeline ile kolayca entegre edilebilir.
pipeline {
agent any
stages {
stage('Checkout') {
steps {
checkout scm
}
}
stage('AI Audit') {
steps {
script {
// CodeArena tarama aracını çalıştır
def report = sh(
script: 'codearena scan --path src --output reports/codearena.json',
returnStdout: true
).trim()
echo "CodeArena taraması tamamlandı: ${report}"
// SonarQube'a (veya başka bir araca) raporu yükleyin
sh 'sonar-scanner -Dsonar.report.path=reports/codearena.json'
}
}
}
}
}
Yukarıdaki pipeline, CodeArena'ı çalıştırır, JSON formatında bir rapor alır ve raporu SonarQube'a aktarır. Bu sayede, her commit jenkins tarafından otomatik olarak analiz edilir ve denetim raporları kaydedilir.
Nasıl çalışıyor?
training-data/).Özetle, AI‑Guard ve CodeArena gibi araçlar sayesinde güvenlik sürecine akıllı otomasyon ekleyebilir, kodunuz her commit'te güvenli bir yerde kalmasını sağlayabilirsin. Çalıştır, kontrol et ve güvenlik açıklarının büyümekten önce ortaya çıkar! 🚀
Hazırsan hemen kod tarafına geçelim 🎯
Ama önce ne yapmak istediğimizi kısaca özetleyeyim:
Böylece “normal akış” ile “saldırı/yanlış kullanım akışı” ayrı ayrı gözlemlenir 🔎
| Aşama | Ne Yapıyor? | Neden Önemli? |
|---|---|---|
| 1️⃣ Kod yükleme | generated_code string’i olarak alınır |
Gerçek hayatta AI çıktısı bu şekildedir |
| 2️⃣ Birincil inceleme | ast modülü ile sözdizimi + tip kontrolleri |
Hızlıca syntax error ve basit type mismatch yakalar |
| 3️⃣ Karşıtlıklı testler | pytest style küçük test fonksiyonları (negatif senaryolar) |
Sınır değerler, None, çok büyük sayılar, exception fırlatma durumları |
| 4️⃣ Raporlama | Konsola renkli özet + JSON dosyası | CI/CD pipeline’ına kolayca entegre edilebilir |
import ast
import sys
import json
from typing import Any, Dict, List
# -------------------------------------------------
# 1️⃣ AI tarafından üretilen örnek kod (simülasyon)
# -------------------------------------------------
generated_code = """
def calculate_discount(price: float, discount_pct: float) -> float:
\"\"\"Fiyat üzerinden yüzde indirim uygular.\"\"\"
if discount_pct < 0 or discount_pct > 100:
raise ValueError("discount_pct 0-100 aralığında olmalı")
return round(price * (1 - discount_pct / 100), 2)
"""
# -------------------------------------------------
# 2️⃣ Birincil inceleme: sözdizimi + basit tip kontrolü
# -------------------------------------------------
def primary_review(code: str) -> Dict[str, Any]:
result = {"syntax_ok": True, "type_hints": True, "issues": []}
try:
tree = ast.parse(code)
except SyntaxError as e:
result["syntax_ok"] = False
result["issues"].append(f"SyntaxError: {e.msg} (satır {e.lineno})")
return result
# Basit tip ipucu kontrolü: fonksiyon tanımlarında return annotation var mı?
for node in ast.walk(tree):
if isinstance(node, ast.FunctionDef) and node.returns is None:
result["type_hints"] = False
result["issues"].append(f"Fonksiyon '{node.name}' dönüş tipi eksik")
return result
# -------------------------------------------------
# 3️⃣ Karşıtlıklı inceleme: negatif / kötü niyetli testler
# -------------------------------------------------
def adversarial_tests() -> List[Dict[str, Any]]:
tests = []
# Test 1: Negatif fiyat
tests.append({
"name": "negatif_fiyat",
"call": "calculate_discount(-10, 10)",
"expect_exception": False,
"description": "Negatif fiyat iş mantığı hatası olabilir"
})
# Test 2: discount_pct sınır dışı (101)
tests.append({
"name": "discount_ust_sinir",
"call": "calculate_discount(100, 101)",
"expect_exception": True,
"exception_type": "ValueError",
"description": "100'in üzeri indirim geçersiz"
})
# Test 3: None gönderimi (tip hatası)
tests.append({
"name": "none_parametre",
"call": "calculate_discount(None, 10)",
"expect_exception": True,
"exception_type": "TypeError",
"description": "None yerine sayısal değer beklenir"
})
# Test 4: Çok büyük sayı (overflow riski)
tests.append({
"name": "buyuk_sayi",
"call": "calculate_discount(1e308, 50)",
"expect_exception": False,
"description": "Float overflow kontrolü"
})
return tests
# -------------------------------------------------
# 4️⃣ Testleri çalıştır ve raporla
# -------------------------------------------------
def run_adversarial(code: str, tests: List[Dict[str, Any]]) -> List[Dict[str, Any]]:
# Kodu geçici bir modül olarak çalıştır
exec_globals = {}
exec(code, exec_globals)
func = exec_globals["calculate_discount"]
results = []
for t in tests:
try:
# eval ile çağrıyı yap (güvenli ortamda sadece demo için)
retval = eval(t["call"], {"calculate_discount": func})
passed = not t.get("expect_exception", False)
results.append({
"test": t["name"],
"passed": passed,
"returned": retval,
"expected_exception": t.get("expect_exception", False)
})
except Exception as e:
passed = t.get("expect_exception", False) and isinstance(e, eval(t.get("exception_type", "Exception")))
results.append({
"test": t["name"],
"passed": passed,
"exception": f"{type(e).__name__}: {e}",
"expected_exception": t.get("expect_exception", False)
})
return results
# -------------------------------------------------
# 5️⃣ Ana akış + rapor çıktısı
# -------------------------------------------------
if __name__ == "__main__":
print("🔎 **Birincil inceleme başlıyor...**")
primary = primary_review(generated_code)
print(json.dumps(primary, indent=2, ensure_ascii=False))
print("\n⚔️ **Karşıtlıklı testler çalıştırılıyor...**")
adv_tests = adversarial_tests()
adv_results = run_adversarial(generated_code, adv_tests)
# Konsol özeti
for r in adv_results:
status = "✅" if r["passed"] else "❌"
print(f"{status} {r['test']}: {'GEÇTİ' if r['passed'] else 'BAŞARISIZ'}")
# JSON raporu (CI/CD için)
report = {
"primary_review": primary,
"adversarial_results": adv_results
}
with open("review_report.json", "w", encoding="utf-8") as f:
json.dump(report, f, indent=2, ensure_ascii=False)
print("\n📄 Rapor 'review_report.json' dosyasına yazıldı.")
primary_review → ast.parse ile kodun derlenebilirliğini ve tip ipuçlarını kontrol eder.adversarial_tests → Senaryoları liste halinde tanımlar; her test bir dict içerir (beklenen exception, açıklama vb.).run_adversarial → Üretilen kodu exec ile bir namespace’e yükler, sonra eval ile test çağrılarını çalıştırır.review_report.json dosyasına JSON olarak kaydedilir → CI/CD pipeline’ına doğrudan beslenebilir 🚀mypy / pylint entegrasyonu ekleyebilirsiniz.hypothesis) ile zenginleştirin.Özetle: Bu betik, “AI kodu yazdı → biz önce normal bakıyoruz → sonra kötü niyetli bakıyoruz” akışını tek dosyada gösterir. Kendi projenize uyarlarken fonksiyon isimlerini, test senaryolarını ve rapor formatını ihtiyacınıza göre şekillendirebilirsiniz 🎉
Hazırsan başlayalım 🎯 — güvenilir bir reviewer olmak, sadece kod okumak değil; süreci de yönetmek demek. Aşağıdaki kontrol listesini günlük rutininize ekleyip, küçük adımlarla alışkanlık haline getirebilirsiniz.
| ✅ Aksiyon | 🛠 Araç / Yöntem | ⏱ Süre |
|---|---|---|
| PR şablonuna “Reviewer rolü” alanı ekle | GitHub PR template | 5 dk |
| CI’ye SonarQube + CodeRabbit ekle | GitHub Actions / GitLab CI | 30 dk |
| Sprint planlamasında test piramidi kontrolü | Jira/Linear epic | 10 dk |
PR boyut uyarısı (GitHub Actions size-limit) |
actions/size-limit |
10 dk |
| Takımda “Review Mola” takvimi oluştur | Google Calendar / Outlook | 5 dk |
Son söz: Bu alışkanlıkları birer birer ekleyin, hemen hepsini yapmaya çalışmayın. Küçük kazanımlar birikince, güvenilir reviewer kimliğiniz doğal bir şekilde oluşur. Hadi, bugün listeden bir maddeyi seçip başlayalım! 🚀
Hazırsan bu yazıyı bir kadeh kahve eşliğinde bitirelim ☕️.
Özetle, AI araçları harika bir yardımcı ama son karar sizde. İşte hatırlamamız gereken ana noktalar:
// Bu fonksiyon X'i Y yapar yerine // X'i Y yapar çünkü Z senaryosunda performans kritiktir.Bu hafta Cuma günü 15:00‑15:45 arası bir “karşıtlıklı inceleme” oturumu koyun takviminize.
- İlk 15 dk: AI’siz kod inceleme.
- Sonraki 15 dk: Aynı dosyayı AI ile analiz ettirin.
- Son 15 dk: Farkları not edin, hangi yaklaşımdan ne kazandığınızı tartışın.
Bu küçük ritüel, hem AI’nin gücünden yararlanmanızı hem de insan unsurunuzu kesinlikle kaybetmemizi sağlar.
Unutmayın: Kod yazmak bir mühendislik sanatıdır; AI fırçanız, siz ise ressamsınız 🎨.
Hadi, takvime o oturumu ekleyin ve haftaya daha güçlü bir kod tabanıyla buluşalım! 💪
Bu içerik tamamen yapay zeka destekli otomasyon sistemi ile üretilmiştir.
All rights reserved