AI Destekli Yazılım Geliştirmede Hermetik Build ve Ajan İzolasyonu

AI destekli yazılım geliştirmede tehdit modelini yetki grafiğiyle kurmak

Kod üreten bir ajanı yalnızca “geliştirici yardımcısı” olarak değerlendirmek yetersizdir: ajan, komut çalıştırma, paket indirme, dosya yazma ve Git push gibi ayrı ayrı yeteneklere sahip bir yürütücüdür. İlk adımda bunları bir capability matrisi olarak çıkarın. Örneğin CI içindeki ajan için network: false, çalışma alanı dışına yazma için filesystem.write: workspace ve yayınlama için git.push: false varsayılanı tanımlayın. Bu yaklaşım, prompt içine yazılan “prod'a dokunma” talimatından daha güvenilirdir; çünkü politika, modelin doğal dil yorumundan sonra değil araç çağrısından önce uygulanır.

{
  "agent": "refactor-bot",
  "capabilities": {
    "filesystem": { "read": ["src/**", "tests/**"], "write": ["src/**"] },
    "process": { "allow": ["npm test", "npm run lint", "npx tsc --noEmit"] },
    "network": false,
    "git": { "commit": false, "push": false }
  },
  "limits": { "maxToolCalls": 40, "maxRuntimeSeconds": 600 }
}

Bu manifesti CI job'ının yanında sürümleyin ve her araç çağrısını bir policy enforcement point üzerinden geçirin. Open Policy Agent (OPA) ile örneğin curl, kabuk yönlendirmesi ve çalışma alanı dışına dosya yazma taleplerini reddedebilirsiniz. İncelik şudur: yalnızca çalıştırılabilir dosya adını allowlist'e almak yeterli değildir; npm lifecycle script'leri üzerinden preinstall sırasında keyfi süreç başlatılabilir. Bu nedenle npm ci --ignore-scripts gibi bir kurulum modu ve ayrı, açıkça izinli build adımı kullanın.

package agent

default allow := false

allow if {
  input.tool == "shell"
  input.argv == ["npm", "ci", "--ignore-scripts"]
}

allow if {
  input.tool == "shell"
  input.argv == ["npm", "test"]
}

# Ağ erişimi isteyen her araç çağrısı açıkça reddedilir.
deny_reason := "networked command is not permitted" if {
  input.network == true
}

Bu tür bir yetki grafiği, yazılım eğitimi içinde “ajan prompt'u yazma” modülünden önce gelmelidir. Teknoloji eğitimi veya yapay zeka eğitimi programlarında katılımcılardan, her ajan görevi için izin verilen komutların ve erişilen dizinlerin kısa bir threat model belgesini üretmelerini istemek, soyut güvenlik önerisini denetlenebilir bir teslimata dönüştürür.

Generative AI çıktısını hermetik build içinde yeniden üretmek

Generative AI tarafından önerilen bir değişikliğin güvenilirliği, yalnızca testin bir kez yeşil olmasına bağlı değildir; aynı commit'in aynı bağımlılık grafiğiyle tekrar build edilebilmesi gerekir. Hermetik build için bağımlılık çözümlemesini lockfile'a sabitleyin, derleme konteynerinde ağ erişimini kapatın ve temel imajı değişmez digest ile bağlayın. Etiketle referans vermek (node:22 gibi) zaman içinde farklı katmanlar çekebileceğinden, başarısızlığı yeniden üretmeyi zorlaştırır.

# syntax=docker/dockerfile:1
FROM node@sha256:REPLACE_WITH_APPROVED_DIGEST AS build
WORKDIR /workspace
COPY package.json package-lock.json ./
RUN --network=none npm ci --ignore-scripts
COPY . .
RUN --network=none npm run build
RUN --network=none npm test

BuildKit ile bu Dockerfile'ı ağsız çalıştırmak için CI tarafında docker buildx build --network=none --load -t app:agent-pr-42 . komutunu kullanın. İlk bağımlılık indirme aşamasını, kurumsal artifact proxy'den doğrulanmış paketleri alan ayrı bir “dependency refresh” pipeline'ına taşıyın; ajan PR doğrulaması bu proxy'ye bile doğrudan çıkmamalıdır. Mekanizma basittir: DNS, CDN veya registry'deki anlık bir değişiklik build girdilerinden çıkarıldığı için aynı kaynak ağaca farklı üçüncü taraf byte'ların girmesi engellenir.

Sık atlanan edge case, test sırasında indirilen Chromium binary'leri, Python build backend'leri veya postinstall script'leridir. Bunları fark etmek için ağ erişimi açık bir keşif job'ında strace -f -e trace=network -o network.trace npm test çalıştırın; ardından grep -E 'connect\(|sendto\(' network.trace ile beklenmeyen bağlantıları listeleyin. Bulduğunuz runtime asset'lerini image katmanına veya kurum içi artifact deposuna alın; “testte bir kez indiriliyor” istisnasını ajan job'ına taşımayın.

Bir yapay zeka kursu ya da llm eğitimi laboratuvarında bu modeli öğretirken hedef, modelden daha iyi kod istemek değil, modelin ürettiği patch'in bağımsız bir ortamda kanıtlanabilir biçimde derlendiğini göstermektir. Katılımcıya kasıtlı olarak ağdan font indiren bir frontend testi verip, --network=none altında başarısızlığı gidertmek pratik bir alıştırmadır.

Vibe coding eğitimi için patch sınırı ve Git tabanlı kabul kapısı

Vibe coding eğitimi veya vibe coding kursu tasarlanırken ajan çıktısını doğrudan çalışma dalına uygulamak yerine patch sınırı koyun: ajan yalnızca unified diff üretir, ayrı bir doğrulayıcı diff'i uygular ve korunan alanlara dokunuşu reddeder. Bu ayrım önemlidir; modelin araç kullanarak dosya sistemini değiştirmesi ile öneri üretmesi aynı denetim yüzeyine sahip değildir. Diff, hem insan incelemesine hem de deterministik kurallara uygun, küçük bir değişim birimidir.

#!/usr/bin/env python3
from pathlib import Path
import subprocess, sys

protected = (".github/workflows/", "infra/prod/", "package-lock.json")
diff = subprocess.check_output(
    ["git", "diff", "--name-only", "origin/main...HEAD"], text=True
).splitlines()

blocked = [p for p in diff if p.startswith(protected) or p == "package-lock.json"]
if blocked:
    print("Protected paths changed:", ", ".join(blocked), file=sys.stderr)
    sys.exit(1)

changed_lines = subprocess.check_output(
    ["git", "diff", "--numstat", "origin/main...HEAD"], text=True
).splitlines()
total = sum(int(row.split()[0]) + int(row.split()[1]) for row in changed_lines)
if total > 500:
    print(f"Patch is too large for unattended merge: {total} lines", file=sys.stderr)
    sys.exit(1)

Bu kapıyı GitHub Actions, GitLab CI veya Jenkins'te testlerden önce çalıştırın. Örneğin GitHub Actions'ta python ci/check_patch.py job'ı başarısız olduğunda merge queue'ya geçişi branch protection ile engelleyin. Ancak salt path kontrolü yeterli değildir: src/config.ts üzerinden üretim URL'sinin değiştirilmesi gibi dolaylı etkiler kalabilir. Bu nedenle kritik konfigürasyon için CODEOWNERS zorunluluğu, IaC için terraform plan -detailed-exitcode ve bağımlılık güncellemesi için lockfile diff incelemesini ayrı kontroller olarak ekleyin.

Ajanın “sadece testi düzelttim” gerekçesiyle snapshot'ları topluca güncellemesi yaygın bir kaçış yoludur. Jest kullanıyorsanız CI'da jest --ci --updateSnapshot=false çalıştırın; snapshot değişimini yalnızca açık bir insan onaylı commit'te kabul edin. Böylece test çıktısını yeni davranışa uyduran büyük bir snapshot değişikliği, fonksiyonel regresyonu gizleyemez.

Ajanlı build sürelerini OpenTelemetry ve hyperfine ile ölçmek

Hermetik build, yanlış cache kurgusuyla gereksiz yavaşlayabilir; bu nedenle optimizasyonu tahminle değil ölçümle yapın. BuildKit plain logları aşama sürelerini verir, uygulama testleri için OpenTelemetry span'ları hangi test grubunun veya dış süreç çağrısının zamanı tükettiğini gösterir. Baz çizgisi için aynı temiz runner üzerinde en az 10 tekrar yapın; hyperfine --warmup 2 --runs 10 'docker buildx build --network=none --no-cache -t app:baseline .' komutunun ortalama, standart sapma ve uç değerlerini kaydedin.

Bağımlılık katmanının kaynak koddan önce kopyalanması, yalnızca package.json veya lockfile değiştiğinde npm ci katmanını geçersiz kılar. Aşağıdaki cache mount, CI runner'ları cache export/import ile yapılandırıldıysa paket arşivlerini yeniden kullanır; yine de lockfile doğrulamasını atlamaz. Önce-sonra karşılaştırmasında aynı commit, aynı runner sınıfı ve aynı --network=none seçeneği kullanılmalıdır; aksi halde ölçtüğünüz fark Dockerfile değil ağ gecikmesi olur.

# syntax=docker/dockerfile:1
FROM node@sha256:REPLACE_WITH_APPROVED_DIGEST AS build
WORKDIR /workspace
COPY package.json package-lock.json ./
RUN --mount=type=cache,target=/root/.npm     --network=none npm ci --ignore-scripts
COPY . .
RUN npm run build

CI'da sonuçları karşılaştırılabilir hale getirmek için BuildKit cache'ini açıkça taşıyın: docker buildx build --cache-from type=gha --cache-to type=gha,mode=max --network=none -t app:test .. Ayrıca ajan araç çağrılarını OpenTelemetry'de agent.tool.name, agent.tool.exit_code ve agent.patch_lines alanlarıyla span olarak kaydedin. Örneğin p95 build süresi düşerken agent.patch_lines başına test başarısızlığı artıyorsa cache kazanımı kalite maliyetini gizliyor olabilir; bu yüzden süre metriğini tek başına merge kriteri yapmayın.

Yapay zeka eğitimi müfredatında bu ölçüm pratiği, ai destekli yazılım geliştirme için kritik bir ayrımdır: öğrencinin “ajan hızlı” iddiası yerine, cache kapalı/açık koşullarında medyan süreyi, p95'i ve başarısız build oranını raporlaması beklenmelidir. Bu yaklaşım, araç demosunu üretim benzeri mühendislik kararına çevirir.

Sık Sorulan Sorular

AI destekli yazılım geliştirmede kod ajanına neden doğrudan Git push yetkisi verilmemeli?

Ajanın ürettiği patch önce korunan path kontrolü, test, secret taraması ve insan incelemesinden geçmelidir. Varsayılan olarak yalnızca branch oluşturma veya diff üretme izni verin; merge/push token'ını CI'nın onay sonrası çalışan ayrı job'ına koyun. Böylece prompt injection ile gelen bir araç çağrısı doğrudan ana dalı değiştiremez.

Vibe coding kursu projelerinde Docker build nasıl ağsız çalıştırılır?

Dockerfile'daki bağımlılık ve test komutlarını RUN --network=none ile çalıştırın; build'i de docker buildx build --network=none ile başlatın. Önceden indirilmesi gereken paketleri lockfile üzerinden kontrollü bir artifact proxy pipeline'ında hazırlayın. Ağsız modda kırılan testler, gizli indirme veya dış servise bağımlılık içerdiğini gösterir.

LLM eğitimi sırasında ajan tarafından değiştirilen dosyaları nasıl sınırlarım?

Ajanın çalışma alanına mount edilen dizinleri daraltın ve CI'da git diff --name-only origin/main...HEAD çıktısını allowlist ile kontrol edin. Workflow, production IaC, secret yönetimi ve lockfile gibi yolları varsayılan olarak reddedin; bu dosyalar için CODEOWNERS onayı veya ayrı bir değişiklik süreci kullanın.

Yapay zeka kursu için hermetik build performansı nasıl ölçülür?

Aynı commit ve aynı runner üzerinde hyperfine --warmup 2 --runs 10 'docker buildx build ...' ile cache kapalı ve cache açık deneylerini ayrı ayrı çalıştırın. Medyan, p95 ve standart sapmayı kaydedin; BuildKit aşama loglarıyla farkın gerçekten bağımlılık katmanından geldiğini doğrulayın. Ağ erişimi veya farklı runner kullanmak karşılaştırmayı geçersiz kılar.