AI Destekli Yazılım Geliştirmede Context Engineering ve Eval

AI destekli yazılım geliştirmede bağlamı bir sözleşme gibi tasarlamak

Bir kod asistanının yanlış değişiklik üretmesinin yaygın nedeni modelin "yetersiz zekâsı" değil, çağrı anında aldığı bağlamın eksik veya çelişkili olmasıdır. Depo köküne, araç tarafından otomatik okunabilen AGENTS.md ya da kullandığınız asistana özgü yönerge dosyası koyun; kuralları soyut ilkeler yerine doğrulanabilir komutlarla yazın. Örneğin "test yaz" yerine test komutu, paket yöneticisi, mimari sınır ve yasak API açıkça belirtilmelidir. Bu yaklaşım, vibe coding eğitimi sırasında özellikle kritiktir: modelin serbest biçimli üretimini, CI tarafından denetlenebilen bir değişiklik sözleşmesine dönüştürür.

# AGENTS.md
## Repository contract
- Runtime: Node.js, package manager: pnpm
- Before proposing a patch run: pnpm lint && pnpm test
- HTTP handlers may call use-case services only; no ORM import in src/http/**
- Do not edit generated files under src/generated/
- New endpoint requires: unit test, OpenAPI operationId, and 401 test case
- Prefer Result over throwing expected domain errors

Bağlam seçimini rastgele dosya ekleme olarak yapmayın. Bir görev için değiştirilecek sembolün tanımı + doğrudan çağıranlar + ilgili test + mimari kural çoğu zaman yeterlidir. Örneğin TypeScript deposunda önce sembol referanslarını çıkarıp yalnızca gerekli dosyaları modele verin: rg -n "createInvoice\(" src test. Bu, gereksiz token maliyetini azaltırken daha önemlisi modelin eski bir yardımcı fonksiyonu örnek alıp yanlış katmanda değişiklik yapma ihtimalini düşürür. Generative AI araçlarında uzun bağlam penceresi, tüm depoyu göndermeyi doğru yapmaz; ilgisiz kod, dikkat dağıtıcı alternatif implementasyonlar üretir.

LLM eğitimi için değil, LLM çıktısı için değerlendirme seti kurmak

Bir llm eğitimi programında model eğitmek ile üretim çıktısını değerlendirmek sıkça karıştırılır. Uygulama ekibinin ilk ihtiyacı fine-tuning değil, gerçek hata sınıflarını temsil eden sürümlenmiş bir görev korpusudur. Her görevde başlangıç commit'i, istek, izin verilen dosyalar, beklenen davranış ve çalıştırılabilir oracle bulunmalıdır. Örneğin bir fiyatlandırma hatası için yalnızca "KDV hatasını düzelt" demek yerine, sınır değerleri içeren test ve değiştirilmemesi gereken para birimi yuvarlama davranışını koruyun.

// test/invoice-tax.spec.ts
import { calculateGross } from "../src/billing/calculateGross";

describe("calculateGross", () => {
  it("applies 20% tax using integer minor units", () => {
    expect(calculateGross({ netCents: 1999, taxRateBps: 2000 }))
      .toEqual({ grossCents: 2399 });
  });

  it("does not use floating-point currency arithmetic", () => {
    expect(calculateGross({ netCents: 1, taxRateBps: 5000 }))
      .toEqual({ grossCents: 2 });
  });
});

Değerlendirmeyi iki katmanlı yapın: önce pnpm test, pnpm lint ve tip denetimi gibi deterministik kapılar; sonra açıklama kalitesi veya gereksinim kapsaması için hakem modeli. Hakem modeline yalnızca diff, görev ve test sonucu verin; tüm sohbet geçmişini vermek, gerekçesiz pozitif puanlara yol açar. Sonucu JSON Schema ile zorlayın ve "pass" kararını test geçişinden bağımsız kabul etmeyin. Bu ayrım, yapay zeka kursu projelerinde gösterişli ama çalışmayan demo ile geri alınabilir kod değişikliği arasındaki farkı görünür kılar.

{
  "type": "object",
  "additionalProperties": false,
  "required": ["requirement_coverage", "unjustified_changes", "verdict"],
  "properties": {
    "requirement_coverage": { "type": "integer", "minimum": 0, "maximum": 100 },
    "unjustified_changes": { "type": "array", "items": { "type": "string" } },
    "verdict": { "enum": ["pass", "needs_review", "fail"] }
  }
}

Vibe coding kursu projelerinde araç çağrılarını en az yetkiyle sınırlamak

Kod asistanına kabuk erişimi vermek, yalnızca komut üretme riskini değil veri sınırı ihlalini de doğurur. Asistanın CI logunu okumak için kullandığı token ile üretim sırlarını okuyabilen token aynı kapsamda olmamalıdır. GitHub Actions örneğinde varsayılan izinleri kapatıp yalnızca gerekli işe geçici izin tanımlayın; ayrıca üçüncü taraf action'ları hareketli etiket yerine commit SHA ile sabitleyin. Bu, eylemin sonraki bir yayınında içerik değişse bile pipeline'ın fark etmeden farklı kod çalıştırmasını engeller.

name: ai-eval
on: [pull_request]
permissions: {}

jobs:
  eval:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: read
    steps:
      - uses: actions/checkout@
      - run: corepack enable && pnpm install --frozen-lockfile
      - run: pnpm test

Araç katmanında komut allowlist'i uygulayın. Örneğin bir konteyner içinde sadece rg, git diff --check, pnpm test ve proje dizinindeki dosya yazma işlemlerine izin verin; curl, ssh, ana makine Docker soketi ve ortam değişkeni dökümünü engelleyin. İncelik şudur: npm test içindeki bir script dolaylı olarak ağ erişimi veya postinstall çalıştırabilir. Bu nedenle bağımlılık kurulumunu, modelin yazdığı patch'i test eden aşamadan ayırın ve test konteynerini --network=none ile başlatın: docker run --rm --network=none --read-only -v "$PWD":/work -w /work node:22 pnpm test.

Generative AI gecikmesini ölçmek: token değil uçtan uca iz sürmek

Bir geliştirme akışında gecikme tartışmasını "model yavaş" düzeyinde bırakmayın. OpenTelemetry ile istek süresini en az dört span'a ayırın: bağlam toplama, LLM ilk token süresi, araç çağrıları ve test çalıştırma. İlk token süresi yüksekse sağlayıcı/model kuyruğu veya büyük prompt; toplam süre yüksek ama ilk token normalse uzun üretim ya da seri araç çağrıları olasıdır. Bu ayrım olmadan prompt küçültmek, aslında test süresinin baskın olduğu bir akışta hiçbir şey değiştirmez.

import { trace } from "@opentelemetry/api";

const tracer = trace.getTracer("coding-assistant");

export async function generatePatch(task: string) {
  return tracer.startActiveSpan("assistant.request", async (root) => {
    const context = await tracer.startActiveSpan("context.collect", () =>
      collectRelevantFiles(task)
    );
    const response = await tracer.startActiveSpan("llm.generate", () =>
      client.responses.create({ model: process.env.MODEL!, input: context })
    );
    root.setAttribute("assistant.output_chars", response.output_text.length);
    root.end();
    return response.output_text;
  });
}

Önce-sonra karşılaştırmasını aynı 30 görevlik eval seti ve aynı eşzamanlılıkla yapın. Örneğin bağlamı tüm src/ ağacından sembol odaklı 12 dosyaya indirdikten sonra p50/p95 süreyi, input token sayısını, test-geçme oranını ve insanın kabul ettiği diff oranını kaydedin. Jaeger veya Grafana Tempo'da llm.generate span'ını filtreleyin; SQL benzeri sorgunuzda duration > 5s olan izleri örnekleyin. Yapay zeka eğitimi ve teknoloji eğitimi içeriklerinde bu metriklerin birlikte öğretilmesi önemlidir: yalnız maliyet düşüşü, davranış doğruluğunun gerilediği bir değişikliği başarı gibi gösterebilir.

Yazılım eğitimi müfredatında insan onayı ve değişiklik kapsamı

Yazılım eğitimi kapsamında AI ile üretilen pull request'leri değerlendirmek için "kod güzel mi?" yerine değişiklik kapsamı metriği kullanın. CI adımında git diff --name-only origin/main...HEAD çıktısını izinli dizin listesiyle karşılaştırın ve görev dışı dosya değiştiğinde inceleme isteyin. Özellikle kilit dosyası değişiklikleri bir edge case'tir: model yalnızca bir fonksiyon düzeltirken pnpm-lock.yaml değiştiriyorsa, bağımlılık çözümlemesinin çevresel olarak yeniden üretildiğini veya istenmeyen paket güncellemesi olduğunu anlamak için diff'i ayrı incelemek gerekir.

changed=$(git diff --name-only origin/main...HEAD)
echo "$changed" | grep -Ev '^(src/billing/|test/billing/|docs/openapi/)' && {
  echo "Task scope outside approved paths"; exit 1;
}
git diff --check origin/main...HEAD

İnsan onayını da risk tabanlı yönlendirin: kimlik doğrulama, para, şema migrasyonu ve silme işlemi içeren diff'lerde zorunlu kod sahibi incelemesi; yalnızca test fixture değişimlerinde normal inceleme kuyruğu kullanın. CODEOWNERS ile bu yönlendirme otomatikleştirilebilir. Böylece yapay zeka eğitimi alan bir ekip, model önerisini otorite kabul etmek yerine değişikliğin etki alanı, test oracle'ı ve geri alma maliyeti üzerinden teknik karar vermeyi öğrenir.

Sık Sorulan Sorular

AI destekli yazılım geliştirme için context engineering nasıl ölçülür?

Sabit bir görev setinde iki koşul çalıştırın: mevcut bağlam ve sembol-temelli bağlam. Her koşul için input token, p50/p95 uçtan uca süre, deterministik test geçiş oranı ve insan onaylı diff oranını kaydedin. OpenTelemetry span'larıyla context.collect ve llm.generate sürelerini ayrı izleyin; yalnız token sayısına bakmayın.

Vibe coding eğitimi alan ekipler hangi CI kontrollerini zorunlu tutmalı?

En azından format/lint, tip kontrolü, birim test, git diff whitespace denetimi ve değişiklik kapsamı kontrolü koyun. Örneğin GitHub Actions'ta varsayılan permissions değerini {} yapın, checkout action'ını commit SHA ile sabitleyin ve modelin ürettiği patch'i ağ erişimi kapalı test konteynerinde çalıştırın.

LLM eğitimi olmadan generative AI kod çıktısı nasıl değerlendirilir?

Fine-tuning yerine sürümlenmiş bir eval korpusu oluşturun. Her görev için başlangıç commit'i, kabul testleri, izinli dosyalar ve beklenen davranış tanımlayın. Önce pnpm test gibi deterministik oracle çalıştırın; yalnız gereksinim kapsaması veya açıklama kalitesi için JSON Schema ile sınırlandırılmış bir hakem modeli kullanın.

Yapay zeka kursu projesinde kod asistanına terminal erişimi vermek güvenli mi?

Sınırsız terminal erişimi vermeyin. Allowlist komutları kullanın, sırları modele görünür ortam değişkenlerinden ayırın, çalışma alanını salt okunur bağlayın ve test konteynerini --network=none ile çalıştırın. Ayrıca npm veya pnpm script'lerinin postinstall gibi dolaylı komut çalıştırabildiğini hesaba katın.