6 puan yazan hon2yb22 2026-04-08 | Henüz yorum yok. | WhatsApp'ta paylaş

Aynı yapay zeka modeli, aynı insan; peki neden sonuçlar farklı oluyor?
Her seferinde tabanı baştan kurup yeniden yapmak, her ekibin Agent’ı farklı şekilde kullanması yüzünden kod çakışmaları yaşanması ve işletilemeyen prototiplerin birikmesi…

Burada her zaman AI araçlarını kullanan kişiler arası iş birliği sırasında ortaya çıkan kronik bir anomali yaşanır.

Teknolojiye hâkim bir geliştirici Claude Code’a bir workflow uygulatırsa mükemmel bir kod ortaya çıkar. Ama ilk kez kullanan bir geliştirici aynı Claude Code’a aynı isteği verdiğinde ortaya sıradan, tutarsız ve hafifçe hatalı bir kod çıkar. Model aynı. Peki neden?

Sorun model değil, bağlam uçurumu (Context Gap) idi — ve bu hem insanlar hem de yapay zeka agent’ları için aynı şekilde geçerlidir.
Onboarding olmadan ekibe katılan yeni bir ekip üyesinin aynı kod tabanında kaybolmasının nedeni de aynıdır: konvansiyonlar örtüktür, mimari birinin kafasındadır ve rehberlik edecek yapılandırılmış bir ortam yoktur. Yapay zeka agent’ları için de durum farklı değildir.

Deneyimli kişiler de bu duvara çarpar. Oturum değişince agent geçmiş tasarımı unutur. Dün belirlenen mimariyi bugünkü agent bilmez. Çünkü bilgi yalnızca insanların kafasındadır; kod tabanının içinde değildir. İnsan konvansiyonları bulamıyorsa agent da bulamaz.

Bunu çözmek için prompt iyileştirmesi ya da daha iyi bir modele ihtiyaç yok. İnsanların ve agent’ların birlikte çalıştığı ortamın kendisini tasarlamak gerekiyor.

[ Harness en başından beri vardı. ]

Harness kelimesi Eski Fransızca 'harnois' sözcüğünden gelir. İlk anlamı "askeri teçhizat, kontrol aracı"dır.
1690’lardan itibaren mecazi anlamı yerleşir: "kontrolsüz gücü doğru yöne yönlendirip kullanmak (to control for use as power)".
Rüzgarı enerjiye dönüştüren bir rüzgar santralinin "rüzgarı harness etmesi" denmesi de aynı bağlamdadır.

Mühendislikte bu ilke biçim değiştirerek tekrar tekrar karşımıza çıktı.

  • Elektrik kablo harness’i (Wiring Harness): Karmaşık biçimde dolaşmış kabloları tek bir demet halinde toplayıp kontrol edilebilir bir birime dönüştüren düzenek. Otomotiv sektöründe onlarca yıldır standarttır.
  • Test harness’i (Test Harness): Tüm altyapı olmadan belirli bir bileşeni izole şekilde çalıştırabilmek için stub ve driver’lardan oluşan yürütme ortamı. Yazılım testinin temel kavramlarından biridir.
  • CI/CD pipeline’ı: Kodun doğrudan prodüksiyona gitmeyip build·test·doğrulama katmanlarından geçmesini sağlayan yapılandırılmış kontrol ortamı. Bu da bir harness’tir.

Ortak nokta tek bir şeydir.

Kontrolsüz hedefleri (kablolar, kod bileşenleri, dağıtım akışı) doğru yönde yönlendirmek için dış ortam tasarlamak.

Bu yüzden 2026 başında OpenAI, Codex agent ile 5 ay boyunca tek satır manuel kod yazmadan 1 milyon satırlık bir sistem kurduğunda, bu eski ilkenin yapay zeka agent’larına uygulanmasına Harness Engineering adını vermesi doğal bir sonuçtu. Martin Fowler’ın da, Anthropic mühendislik ekibinin de aynı dönemde aynı kelimeyi kullanması tesadüf değildi.

LangChain de sadece harness’i iyileştirerek Terminal Bench 2.0 sıralamasını 30.’luktan 5.’liğe çıkardı.

Bu nedenle act-operator, gerçek ürünlerde kullanılabilecek LangGraph 1.0+ yapı kontrol harness’i olarak geliştirildi.

[ Ultra-Quick Start ]

uv kurulu bir ortamda aşağıdaki tek satırla gerçek prodüksiyon için LangGraph 1.0+ proje harness kurulumu tamamlanır.

uvx --from act-operator act new

[ Act Operator’ın 3 katmanlı yapısı ]

Yapay zeka tabanlı geliştirmede harness, işi kimin yaptığına bakmaksızın hem insanların hem de yapay zeka agent’larının doğru çıktıyı istikrarlı biçimde üretebilmesini sağlayan scaffolding, çalıştırılabilir bilgi ve geri bildirim döngüsü sistemidir.

Act Operator bunu üç katmanla uygular:

  1. Scaffolding: İlk agent prompt’undan önce kurulan; minimum düşük coupling ve minimum yüksek cohesion garantili modül konvansiyonları ile base class’lar içeren tam proje iskeleti
  2. Çalıştırılabilir SSOT: Agent’ların ve insanların runtime’da okuduğu, çalışabilir dosyalara kodlanmış bilgi
  3. Geri bildirim döngüsü: Oturumlar arasında agent’ı hizalı durumda tutan spesifikasyon

[ Çalıştırılabilir SSOT ]

Tipik ekipler geliştirme ve tasarım bilgisini wiki’lerde, mimari dokümanlarda, sözlü aktarım yoluyla paylaşır; hatta bazen hiç paylaşmaz. Sorun şu ki dokümanlar eskir, wiki’ler bayatlar ve sözlü bilgi ekip değişimlerine dayanamaz.

Harness bu bilgileri çalışan dosyalar olarak kodlar — statik dokümanlar değil, agent’ların ve insanların doğrudan okuduğu çalıştırılabilir referanslar. Act Operator bunu coupling ve cohesion’ı dikkate alarak üç tamamlayıcı SSOT bileşen katmanı ile yönetir:

  1. Act Template (scaffold): Proje iskeletinin kendisi — temel CI workflow’ları, base class’lar, test yapısı, monorepo ayarları, environment variable yönetimi, kullanım kılavuzu
  2. Agent Skills: Toplam 5 skill, 50’den fazla referans pattern, karar ağaçları, mimari şablonlar
  3. Drawkit: draw.io için Act mimarisi ön tanımlı shape’leri — insanlar arası iletişim için ortak görsel sözlük

Her bileşen farklı bir hedefe yönelirken aynı temel konvansiyonlara referans verir. Act Template, hem agent’ların hem de geliştiricilerin çalıştığı yapısal temeli kurar. Skill’ler, agent’a bu yapı içinde nasıl doğru geliştirme yapacağını öğretir; Drawkit ise ekibe mimariyi nasıl görselleştireceğini gösterir.

[ Açık kaynak hakkında diğer bilgiler ]

  • Claude Code dışında OpenCode, Cursor, Gemini CLI gibi skill dizinini destekleyen tüm araçlarla çalışır.
  • Hem Korece hem İngilizce dokümantasyon desteklenir
  • Apache 2.0 License – PIPY’de %200 ücretsiz dağıtılıyor

Herkesin geri bildirimini ve katkısını memnuniyetle karşılıyoruz (ve GitHub yıldızı★ da...!). Teşekkürler :)

Github: https://github.com/Proact0/act-operator

Henüz yorum yok.

Henüz yorum yok.