AI Destekli Yazılım Geliştirmede Hotspot Tabanlı Kod İnceleme

AI destekli yazılım geliştirme için hotspot sinyali kurma

Bir LLM'in ürettiği 15 satırlık değişiklik, son 90 günde 80 kez değiştirilmiş bir ödeme adaptörüne dokunuyorsa, 400 satırlık yeni bir test fixture'ından daha yüksek inceleme riski taşır. Bunun mekanizması nettir: yüksek churn, aynı dosya üzerinde paralel PR olasılığını ve davranışı yalnızca yerel bağlamla anlaşılamayan kod oranını yükseltir. Bu nedenle ai destekli yazılım geliştirme akışında risk puanını en az dosya churn'ü, fonksiyon karmaşıklığı ve CODEOWNERS sahipliğiyle hesaplayın.

#!/usr/bin/env python3
import os
import subprocess
from collections import Counter

BASE = os.getenv("BASE_REF", "origin/main")
TOP_N = int(os.getenv("HOTSPOT_TOP_N", "20"))

def paths(command):
    raw = subprocess.check_output(command)
    return [p.decode("utf-8", "surrogateescape")
            for p in raw.split(b"\0") if p]

recent = paths([
    "git", "log", "--since=90.days", "--format=", "--name-only", "-z"
])
changed = paths([
    "git", "diff", "--name-only", "-z", f"{BASE}...HEAD"
])

churn = Counter(recent)
ranked = [name for name, _ in churn.most_common()]
hot = set(ranked[:TOP_N])
risky = sorted(set(changed) & hot, key=lambda name: churn[name], reverse=True)

for name in risky:
    print(f"HOTSPOT churn={churn[name]:3d} file={name}")

if risky:
    print("AI_REVIEW_LEVEL=senior-owner-required")
    raise SystemExit(2)

Betikte `-z` ve Python tarafında `surrogateescape` kullanımı kasıtlıdır. Sadece satır sonuna göre ayrıştırılan `git log --name-only` çıktısı, adında newline bulunan geçerli bir Git dosya yolunu iki ayrı dosya gibi sayabilir. Bu edge case nadir görünür ancak saldırganın PR denetimini atlatmak için kullanabileceği veri ayrıştırma tutarsızlığıdır. İlk eşik için son 90 gün içindeki ilk 20 dosyayı seçin; ardından her depo için false positive oranını kaydedip eşiği sabitleyin.

CI CD pipeline içinde otomatik hotspot kapısı

Hotspot raporunu geliştiricinin makinesinde bırakmayın. PR açıldıktan sonra aynı Git tabanından çalışan bir ci cd pipeline adımı, modelin ürettiği değişiklik ile insanın yazdığı değişikliği aynı kurala tabi tutar. Aşağıdaki GitHub Actions örneğinde tam geçmiş için `fetch-depth: 0` gereklidir; varsayılan sığ checkout kullanılırsa 90 günlük churn verisi eksik kalır ve skor sistematik biçimde düşük çıkar.

name: ai-change-risk
on:
  pull_request:
    branches: [main]

permissions:
  contents: read

jobs:
  hotspot:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: Check repository history depth
        run: git merge-base --is-ancestor origin/main HEAD
      - name: Score changed files
        env:
          BASE_REF: origin/main
          HOTSPOT_TOP_N: "20"
        run: python3 tools/hotspot_gate.py
      - name: Static checks for elevated-risk changes
        if: failure()
        run: |
          pip install --require-hashes -r tools/requirements.txt
          semgrep scan --config p/default --error
          git diff --check origin/main...HEAD

`if: failure()` altındaki Semgrep çağrısı, ana test süitinin yerine geçmez. Amaç sadece yüksek riskli değişiklikte ek görünürlük sağlamaktır. `git diff --check` özellikle üretken modellerin bazen bıraktığı trailing whitespace ve conflict-marker benzeri hataları erken yakalar. Bağımlılıkları `pip install semgrep` şeklinde anlık çözmek yerine hash'li requirements dosyasından kurun; aksi halde iki PR aynı kural adını çalıştırsa bile farklı analizör sürümleri farklı sonuç verebilir.

Vibe coding eğitimi ile sahiplik tabanlı inceleme sözleşmesi

Vibe coding eğitimi veya bir vibe coding kursu kapsamında en sık görülen hata, başarılı derleme sonucunu yeterli kabul etmektir. Derleyici tip ve sözdizimi tutarlılığını görür, fakat ödeme sağlayıcısının idempotency anahtarı sözleşmesini ya da müşteri verisinin hangi bölgeden çıkamayacağını bilemez. Bu bilgiyi depo içinde makinece kontrol edilebilir hale getirmek için CODEOWNERS ve risk sözleşmesini birlikte kullanın.

# .github/CODEOWNERS
/services/payments/     @billing-platform @security-reviewers
/infra/terraform/       @platform-infra
/apps/web/auth/         @identity-team

# .ai-review.yml
rules:
  - path: "services/payments/**"
    require:
      approvals: 2
      owners: true
      evidence:
        - "idempotency-test"
        - "provider-sandbox-log"
  - path: "infra/terraform/**"
    require:
      approvals: 1
      owners: true
      evidence:
        - "terraform-plan-json"

Bu sözleşmeyi PR açıklamasında serbest metin olarak istemek yerine CI'da doğrulanabilir artifact'e bağlayın. Örneğin ödeme değişikliğinde sandbox çağrı kimliğini ve test adını `review-evidence.json` dosyasına yazdırın, ardından şemayı `ajv` ile doğrulayın. İnce ayrıntı şudur: CODEOWNERS kuralı yalnızca dosya eşleşmesine dayanır. Bir model ödeme mantığını `shared/utils` altına taşıyorsa kritik sahiplik kuralı devre dışı kalabilir. Bu yüzden hotspot listesine ek olarak import grafiğini `dependency-cruiser` veya `pydeps` ile çıkarıp ödeme modülüne yeni gelen ters bağımlılıkları PR kontrolünde raporlayın.

Generative AI değişikliklerinde önce-sonra ölçümü

Generative ai kullanımının inceleme kalitesine etkisini 'daha hızlı hissediyoruz' diye değil, aynı repository metrikleriyle ölçün. Başlangıçta dört haftalık bir baz dönem alın: PR başına ilk yanıt süresi, merge sonrası 14 gün içinde aynı dosyaya gelen düzeltici commit sayısı, hot dosyalardaki revert oranı ve owner onayı olmadan merge edilen PR sayısı. Hotspot kapısını sonraki dört hafta açın ve dağılımları medyan ile p90 olarak karşılaştırın. Ortalama, birkaç çok uzun bekleyen PR nedeniyle yanıltıcı olur.

# Son 28 günde merge edilmiş PR'ları CSV olarak dışa aktarır.
gh pr list --state merged --base main --limit 1000   --json number,createdAt,mergedAt,files   --jq '.[] | [
    .number,
    .createdAt,
    .mergedAt,
    ([.files[].path] | join(";"))
  ] | @csv' > merged-prs.csv

# Aynı dosyada merge sonrasındaki 14 günlük commit'leri incelemek için:
git log --since="2026-08-01" --name-only --format='%H %ad' --date=short

Düzeltici commit'i yalnızca commit mesajında `fix` geçmesine göre sınıflandırmayın. PR merge SHA'sından sonraki 14 günlük pencerede, PR'ın dokunduğu dosyaya tekrar gelen commitleri aday olarak çıkarın; sonra `git show --word-diff=porcelain` ile manuel örneklem yapın. Bu yaklaşım refactor commitlerini kusur diye sayma riskini tamamen kaldırmaz, ancak mesaj tabanlı filtreye göre çok daha az kaçırır. Her dönem için en az 30 PR yoksa sonucu istatistiksel iddia olarak sunmayın; yalnızca operasyonel gözlem olarak raporlayın.

Yazılım eğitimi rotasında DevOps, LLM ve cloud native uygulama

Bu pratik, yazılım eğitimi ve teknoloji eğitimi programlarında tek başına prompt yazma modülü olmamalıdır. Yapay zeka eğitimi, yapay zeka kursu ve llm eğitimi katılımcılarının aynı PR üzerinde Git geçmişi, test kanıtı ve sahiplik kontrolü üretmesi gerekir. Devops eğitimi içinde bunu bir ci cd pipeline laboratuvarına dönüştürün: PR webhook'u risk betiğini çalıştırsın, başarısız sonucu merge koruma kuralına yazsın ve artifact olarak değişen dosya listesini saklasın.

Docker eğitimi ve kubernetes eğitimi için yerel bir tekrar ortamı kurmak, denetimin uygulama kodu ile sınırlı kalmadığını gösterir. Aşağıdaki komutlar minikube üzerinde örnek bir servisi ayağa kaldırır; container orchestration katmanında üretilen manifest değişikliğinin gerçekten uygulanabilir olup olmadığını `kubectl rollout status` ile kontrol edersiniz.

minikube start --driver=docker
docker build -t checkout:review ./services/checkout
minikube image load checkout:review
kubectl apply -f deploy/checkout.yaml
kubectl rollout status deployment/checkout --timeout=90s

Cloud native mimari kullanan ekiplerde risk kapısı uygulama deposundan infrastructure as code deposuna da taşınmalıdır. Terraform değişikliklerinde `terraform plan -out=tfplan` ve `terraform show -json tfplan` çıktısını artifact olarak saklayın, ardından plan JSON'unda silinecek kaynak sayısını eşikleyin. Aws eğitimi ve google cloud eğitimi laboratuvarlarında aynı kuralı sırasıyla IAM politika değişiklikleri ve servis hesabı yetkileri için uygulayın. Böylece ai destekli yazılım geliştirme tarafından önerilen bir rol genişletmesi, metin diff'i yerine sağlayıcının hesapladığı plan üzerinden incelenir.

Sık Sorulan Sorular

AI destekli yazılım geliştirme için hotspot eşiği nasıl belirlenir?

İlk olarak son 90 gündeki dosya değişim sayısını çıkarın ve en üst yüzde 5'i hotspot kabul edin. Dört hafta boyunca bu etiketlerin kaçının gerçekten owner incelemesi gerektirdiğini ölçün. False positive oranı yüzde 30'un üzerindeyse salt churn yerine churn x dosya karmaşıklığı puanına geçin.

Vibe coding kursu projelerinde LLM kodu için hangi CI CD pipeline kontrolleri kullanılmalı?

En az `git diff --check`, tam geçmişle çalışan hotspot betiği, değişen dile uygun test komutu ve Semgrep taraması ekleyin. Ödeme, kimlik veya Terraform yollarında ayrıca CODEOWNERS onayı ve doğrulanabilir kanıt artifact'i zorunlu tutun.

Docker eğitimi ve kubernetes eğitimi sırasında minikube ile AI üretilen manifest nasıl doğrulanır?

Manifesti önce `kubectl apply --dry-run=server -f deploy/` ile API sunucusuna doğrulatın. Ardından minikube'a image yükleyip `kubectl apply` ve `kubectl rollout status` çalıştırın. Dry-run şema ve admission kontrollerini, rollout ise image pull, readiness probe ve deployment ilerlemesini yakalar.

Terraform infrastructure as code değişiklikleri için generative ai incelemesinde ne saklanmalı?

`terraform plan -out=tfplan` ile ikili planı, `terraform show -json tfplan` ile okunabilir planı ve kullanılan provider lock dosyasını CI artifact'i olarak saklayın. İnceleyici özellikle `delete` ve `replace` action'larını, IAM policy diff'lerini ve planın hangi workspace veya backend ile üretildiğini kontrol etmelidir.