Harness engineering mülakat soruları: yapay zeka mühendisi için 22 soru ve cevap

Nasıl hazırlanmalı

Harness engineering mülakatları genellikle genelden özele ilerler: harness nedir, hangi bileşenlerden oluşur, bir sorunu nasıl teşhis edersiniz, etkiyi nasıl ölçersiniz. Mülakatçı mühendislik düşüncesini arar: modelin sorunu ile ortamın sorununu ayırt edebilme ve doğrulanabilir bir çözüm önerebilme. Aşağıda konulara göre gruplanmış 22 soru ve cevabı bulursunuz.

Temeller

1. Bir ajanın harness'i nedir?

Harness, AI ajanının çalıştığı, modelin dışındaki tüm ortamdır: talimatlar, araçlar, çalıştırma ortamı, durum saklama ve geri bildirim döngüleri. Modeli kararları verir, harness ise neyi bildiğini, neyi yapabileceğini ve sonucunu nasıl öğreneceğini belirler. Aynı model farklı harness'lerde çok farklı kalitede sonuç verir.

2. Harness engineering, prompt ve context engineering'den nasıl ayrılır?

Prompt engineering tek bir isteğin ifadesiyle, context engineering ise her adımda modelin penceresine ne gireceğiyle ilgilenir. Harness engineering ikisini de kapsar ve metinle çözülmeyen şeyleri ekler: araçlara erişim, tekrarlanabilir ortam, oturumlar arası durum ve makineyle sonuç doğrulama.

3. Harness'in beş bileşenini sayın.

Talimatlar (AGENTS.md, CLAUDE.md, skills, belgeler), araçlar (shell, testler, linter, tarayıcı, MCP), ortam (bağımlılıklar, runtime, Docker, worktree), durum (PROGRESS.md, özellik listesi, kararlar) ve geri bildirim (make check, E2E, hook'lar, değerlendirici). Bileşenlerden birinin eksik olması "biraz daha kötü" sonuç vermez, hataların sistematik bir sınıfını doğurur.

4. Modeli daha güçlüsüyle değiştirmek neden çoğu zaman yardımcı olmaz?

Çünkü birçok arızanın kaynağı modelin zekası değildir. Güçlü bir model, verilmemiş bir komuta erişemez, durum dosyası olmadan dünkü oturumu hatırlayamaz ve kimse çalıştırmadıysa bozuk bir migration'ı fark edemez. Bir ekibin geleneklerini de model kendiliğinden bilmez.

Teşhis

5. Ajan CLAUDE.md içindeki bir kuralı çiğniyor. Ne yaparsınız?

Önce ajanın kuralı görüp görmediğine bakarım: onlarca maddelik uzun bir dosya önemli şeyi bulanıklaştırır. Dosyayı bir içindekiye indirir, ayrıntıları koşullu yüklenen belgelere taşırım. Kural kritikse, onu çalışan bir kontrole dönüştürürüm: linter, test, grep-guard veya hook. Böylece ihlal modelin dikkatine bağlı kalmaz, makine tarafından görülür.

6. Bir belirtiye bakarak hangi bileşenin bozuk olduğunu nasıl anlarsınız?

Bilinen gelenekler çiğneniyorsa talimatlar. Ajan "yapmak istiyor ama yapamıyor" diyorsa araçlar. Her oturum ortamı onarmakla başlıyorsa ortam. Yeni oturum nerede kaldığını bilmiyorsa durum. "Hazır" ile gerçeklik uyuşmuyorsa geri bildirim.

7. Harness'e hangi bileşenle başlarsınız ve neden?

Geri bildirimle. "Çalışıyor mu, çalışmıyor mu" sorusunu makineye yanıtlatan bir komut olmadan başka herhangi bir değişikliğin etkisini ölçemezsiniz. Sonra genellikle talimatlar, durum, ortam ve araçlar gelir, ama sıra deneyime göre belirlenir ve en çok hangi bileşenin bozulduğuna bağlıdır.

8. Harness'in tek bir bileşeninin katkısını nasıl ölçersiniz?

Ablation ile: model ve görev kümesini sabit tutup bileşenleri teker teker kapatır, düşüşe bakarım. Ama önce, darboğazı hızlıca gösteren, katmanlara göre işaretlenmiş bir hata günlüğüyle başlarım. Sıfır düşüş bileşenin işe yaramadığı anlamına gelmez: seçilen görevler onu hiç kullanmamış olabilir ya da başka bir bileşenin açığını kapatıyor olabilir.

Talimatlar ve context

9. İyi bir AGENTS.md nasıl yazılır?

Ders kitabı gibi değil, yönlendirici gibi: proje nedir, nasıl çalıştırılır, nasıl kontrol edilir, Definition of Done ve zorunlu sınırların kısa listesi. Ayrıntılar, "ödemeyle ilgili iş varsa oku" gibi koşullu bağlantılarla ayrı belgelerde durur. Dosya değişmezleri anlatır ("veri sınırda doğrulanır"), satır satır uygulamayı ya da kütüphaneleri dikte etmez.

10. Subagent'lar neden kullanılır?

Context'i izole etmek için. Kodbazında arama, inceleme veya kontrol gibi bir yan iş, kendi context'inde yapılır ve yalnızca sonucu döndürür. Ana akış kirlenmez ve kontrol eden subagent, uygulayıcının gerekçelerini devralmaz; bu da dürüst bir değerlendirme için önemlidir.

11. "Harness borcu" nedir?

Harness ile gerçeklik arasında birikmiş sapma: eskimiş kurallar, artık çalışmayan komutlar, var olmayan modüllerin belgeleri. Teknik borç gibi sessizce birikir ve ajanın arızaları olarak ödenir. Harness'in düzenli gözden geçirilmesi gerekir; bir kez kurup bırakılmaz.

Durum ve oturumlar

12. Ajanın oturumlar arası unutkanlığıyla nasıl başa çıkarsınız?

Durumu depoda tutarım: PROGRESS.md (durum, yapılanlar, engeller, sonraki adımlar), DECISIONS.md (karar, gerekçe, reddedilen seçenekler), durumlu bir özellik listesi ve sık commit'ler. Talimatlarda başlangıç sırasını tanımlarım: ilerlemeyi oku, ortam kontrol betiğini çalıştır, aktif özelliği al.

13. WIP=1 kuralı neden var?

Ajan aynı anda birçok özelliğe başlarsa durum dağılır: hiçbiri bitmez, değişiklikler birbirine karışır, geri almak zorlaşır. Tek bir aktif özellik net bir kontrol noktası, temiz commit'ler ve arızadan sonra basit bir dönüş sağlar.

14. "Soğuk başlangıç testi" nedir?

Yeni bir oturumun, insan ipucu olmadan temel soruları yanıtlayıp yanıtlayamadığını kontrol etmektir: proje hangisi, nerede kalınmıştı, hangi özellik aktif, her şeyin yolunda olduğu nasıl kontrol edilir? Ajan dosyalardan tahmin yürütmeden yanıt veriyorsa durum bileşeni çalışıyor demektir.

Doğrulama

15. Yeşil unit testler neden özelliğin çalıştığını kanıtlamaz?

Unit test bir modülü izole eder ve bağımlılıkları mock'lar; bu yüzden bağlantıları görmez: arayüz uyumsuzluğu, durumun yayılması (şema değişti, önbellek eski), kaynak sızıntıları, yapılandırma ve ortam sorunları. Unit testlerin yakaladığı hatalar, integration testlerin yakaladığı hataların alt kümesidir ve bunlar da E2E'nin yakaladığı hataların alt kümesidir.

16. Verification gap nedir ve nasıl hesaplanır?

Ajanın "hazır" dediği ama bağımsız doğrulamanın onaylamadığı görevlerin oranıdır. Son 10 görevi alır ve her biri için iki gerçeği kaydedersiniz. Bu ölçü bir başlangıç çizgisi verir: harness değişikliklerinden sonra benzer görevler üzerinde yeniden hesaplanır.

17. Ajan için Definition of Done nasıl yazılır?

AGENTS.md içinde doğrulanabilir maddeler halinde: kontrol komutları kod 0 ile tamamlandı, özellik için E2E var, migration'lar uygulanıyor, ilerleme güncel. Hazır sayılmayacakları da açıkça yazmak faydalıdır: "doğru görünüyor", "unit testler geçiyor", "bende yerelde çalışıyor".

18. Ajan neden kendisi "hazır" işaretini koymamalı?

Model kendi işini olduğundan iyi değerlendirme eğilimindedir ve bu öz değerlendirme, kararın verildiği context'in içinde yapılır. Passing işaretini doğrulama betiği koymalı, çalıştırma sonuçlarına göre ve commit hash'ini kanıt olarak kaydederek.

19. Bağımsız bir değerlendirici nasıl kurulur?

Yalnızca gereksinimi, diff'i ve çalıştırma sonuçlarını gören ayrı bir ajan veya oturum; uygulayıcının gerekçelerini değil. Bir rubrikle değerlendirir (doğruluk, mimari, testler, hata yönetimi) ve her değerlendirme bir dosyaya, satıra veya loga atıf yapar. Kör noktalar örtüşmesin diye mümkünse başka bir model kullanılır.

20. Bir mimari kuralı çalıştırılabilir hale nasıl getirirsiniz?

Üç seviye: grep-guard (hızlı, pattern ile), import grafiğini anlayan linter kuralı (import-linter, dependency-cruiser) ve CI'da mimari testi. Üçü de make check'e eklenir, sıfır olmayan kodla başarısız olur ve ajanın ihlali kendisinin düzeltebilmesi için WHY ve FIX yazdırır. Yeni bir kontrol eklemek için tetikleyici: aynı yorumun incelemede ikinci kez gelmesi.

Özerk çalışma

21. Ajanı saatlerce çalışmaya bırakmak için neye ihtiyaç vardır?

Net bir hedef, tek yönlü ilerleme ölçütü (örneğin passing özelliklerin sayısı), özellik başına süre ve deneme bütçesi, gerileme durumunda otomatik geri alma ve insanın yapması gerekenler listesi: migration'lar, altyapı, para. Bir de izolasyon: sandbox veya ayrı bir git worktree, hatanın çalışma ortamına ulaşmaması için.

22. Tek bir ajan döngüsü ne zaman yetmez ve rol grafiği nasıl kurulur?

Uygulayıcı kendini kontrol etmeye başlayıp takıldığında. O zaman iş rollere bölünür: uygulama, inceleme, test, merge. İnceleme temiz bir context ve rubrik alır, merge ise yalnızca review == pass olduğunda yapılır. İnceleme başarısız olursa özellik uygulamaya geri döner; birkaç başarısızlıktan sonra temiz bir context ile baştan başlatılır, çünkü o noktada sorun kodda değil, görevin anlaşılmasındadır.

Sonuç

Harness engineering mülakatlarında en güçlü cevap, doğrulanabilir olandır: hangi dosyalar, hangi komutlar, hangi metrik. Beş bileşeni, verification gap'i ve "hazır işaretini betik koyar" kuralını aklınızda tutun. Bu konuların hepsi, gerçek bir proje üzerinde, tek bir harness içinde birleştirilerek uygulamalı bir kursta öğretilmektedir.