GitHub Trending listesine bakınca bazı projeler var ki insanın kaşı kalkıyor. Archon da onlardan biri. Bir gün oturup “tamam, bunu bir inceleyeyim” dedim; editör masasında kahvemi koydum, repo’yu açtım. İlk hissim şuydu: bu iş rastgele yapılmamış (buna dikkat edin). Temiz, disiplinli ve oldukça iyi paketlenmiş bir sistemle karşı karşıyayım.
Ama işin asıl ilginç tarafı başka. Archon sadece popüler bir açık kaynak proje değil — aynı zamanda sektörde sessizce büyüyen bir tartışmanın da canlı örneği, hani şu “yapay zekâ ajanı” kelimesiyle herkesin farklı şeyi kastettiği o tartışmanın. Bir tarafta sıkı sıkıya kontrol edilen iş akışları var, diğer tarafta daha serbest, daha “düşünen” sistemler. Herkes aynı şeyi konuştuğunu sanıyor ama konuşmuyor.
Ben bu yazıda Archon’u övmek için değil, nerede çok iyi çalıştığını. Nerede duvara tosladığını anlatmak için masaya yatırıyorum. Çünkü bazen bir araç gerçekten iyidir. Yanlış problemi çözerse hayal kırıklığı kaçınılmaz oluyor — hani o meşhur mesele: kağıt üstünde süper, pratikte göreceğiz artık.
Şimdi gelelim işin can alıcı noktasına.
Archon tam olarak ne yapıyor?
Doğrusu, En sade haliyle şöyle okumak lazım: yapay zekâ için kurulmuş bir iş akışı iskeleti. Yani kendi başına “beyin” olmaktan çok, modele ne zaman ne yapacağını söyleyen akıllı bir koordinatör gibi davranıyor. GitHub’da “AI için GitHub Actions” benzetmesi yapılması boşuna değil; çünkü yapı oldukça deterministik ve bu kasıtlı bir tercih.
Bir şey dikkatimi çekti: Geçen ay İstanbul’da bir startup ekibiyle sohbet ederken benzer mantıkta çalışan otomasyonlarını dinledim. Onların derdi yaratıcılık değildi; tekrar edilebilirlikti (bizzat test ettim). Her seferinde aynı kalitede PR üretmek istiyorlardı, nokta. Archon’un parladığı yer de tam orası zaten — bir LLM’i serbest bırakıp ortalığı dağıtmasına izin vermek yerine, onu adım adım yürütüyor: planla, uygula, test et, PR aç… tertemiz.
Şimdi gelelim işin can alıcı noktasına.
Bu yaklaşımın büyük avantajı var tabii. Ekipler saçma sürprizlerle uğraşmıyor, model konu dışına çıkamıyor ya da yarıda başka fikre kayamıyor — bence çok yerinde bir karar —. Ama gel gelelim bu düzenin bedeli de var. Sistem sağlamlaşıyor, evet — ama aynı anda esniyor mu? İşte orası biraz tartışmalı.
Bir harness, yani kuşatma çerçevesi, modeli hizaya sokar; fakat ona yeni bir dünya kurmaz.
Neden bu kadar iyi çalışıyor?
Ne yalan söyleyeyim, Cevap aslında basit. Kontrol seviyesi yüksek olduğu için iyi çalışıyor — kurumsal ekiplerde en sevilen şeylerden biri budur zaten, sürpriz az olsun, sonuçlar benzesin, loglar düzgün aksın. Archon da tam bu zihniyeti yansıtıyor ve bence bunu yaparken abartıya kaçmıyor.
Evet, doğru duydunuz.
Bence, Repo’ya baktığınızda TypeScript ağırlıklı bir yapı görüyorsunuz; Bun gibi modern araçlarla hızlı çalışan, web geliştirme tarafında gayet doğal bir yüzey sunuyor. React bileşeni üretmekten test koşturmaya kadar uzanan süreçlerde tek tip bir boru hattı kurmak istiyorsanız, hmm, fena çözüm değil açıkçası. Bu konuyla ilgili Fransa Windows’tan Uzaklaşıyor: Linux Hamlesi Ne Anlatıyor? yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza bakabilirsiniz. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Ben 2023 sonlarında kendi yan projemde benzer şekilde LLM destekli kod üretimi denemiştim (eh, fena değil). Açık konuşayım: ilk başta model özgür bırakılınca güzel fikirler veriyordu ama üç tür sonra dağılıyordu, insan eli değmeden yapılan işler bazen fazla özgüvenli oluyor çünkü, siz de bilirsiniz bunu muhtemelen. Archon’un yaptığı şey tam da o özgüveni törpülemek.
| Kriter | Workflow Harness | Cognitive OS |
|---|---|---|
| Ana amaç | Tutarlı çıktı üretmek | Sürekli karar verebilmek |
| Kuvvetli yani | Daha az sapma | Daha fazla uyum kabiliyeti |
| Zayıf yani | Esneklik sınırlı | Karmaşıklık yüksek |
| İdeal kullanım | Kod PR otomasyonu | Ajanik operasyonlar |
Peki sorun nerede başlıyor?
Şuradan başlıyor: harness dediğiniz şey dışarıdan yönetir, düşünmez (en azından benim deneyimim böyle). Sadece yürütür. Plan belli ise sistem mutlu çalışır — ama plan bozulursa ya da ortam değişirse? Orada iş karışır.
Bunu geçen hafta Ankara’daki bir güvenlik toplantısında yine konuştuk; özellikle altyapı tarafında çalışan ekipler bunu hemen anlıyor, anlaması da kolay zaten. Bir agent’ın sadece komut takip etmesi yetmiyor artık. Çevreyi okuyup karar değiştirmesi de gerekiyor, mesela saldırı yüzeyi değiştiyse ya da sistem aniden yük altındaysa tek çizgili YAML akışı orada yetersiz kalabiliyor — ve bu küçük bir sorun değil.
YAML tabanlı DAG yapıları çoğu zaman reaktif kalıyor; yani olay olduktan sonra tepki veriyorlar. Oysa gerçek otomasyon biraz proaktif (belki yanılıyorum ama) olmak zorunda değil mi? Sistemin beklemeden hissetmesi gerekiyor… dur, biraz iddialı oldu ama ana fikir bu işte.
Dil bariyeri meselesi hiç küçümsenecek iş değil
Archon’un TS ağırlıklı olması bazı senaryolarda gayet mantıklı. Ama ağır hesaplama işi başladığında tablo değişiyor. Python ekosistemi hâlâ AI dünyasının ana sahnesi gibi çalışıyor; PyTorch’tan CUDA araçlarına kadar her şey orada daha doğal akıyor, bunu inkâr etmenin anlamı yok. Base64, URL ve HTML: Üçü de Aynı Şey Değil yazımızda bu konuya da değinmiştik.
E tabi Node/Bun katmanı üzerinden her şeyi geçirmek mümkün ama bazı işler şerit değiştiren kamyon gibidir — olur ama rahat olmaz! Yerel model çağrıları, düşük seviye script’ler veya donanım erişimi söz konusuysa Python tarafının nefes aldığı alan çok daha geniş oluyor. Bu fark pratikte hissediliyor.
Tedarikçi bağımlılığı can sıkabilir mi?
Bence evet. Hem de bayağı sıkabilir. Belirli bir SDK’ye yaslanınca karar alanınız daralıyor; bugün Claude ile harika görünen kurgu yarın farklı maliyet politikasıyla tatsızlaşabiliyor.
Editör arkadaşım Burak’la geçen ay bunun üzerine uzun uzun konuştuk; kendisi küçük ölçekli SaaS ürünü yönetiyor. “tek modele bağlanınca içim rahat etmiyor” dediğinde hak verdim doğrusu. Gerçekten de akıllı orkestrasyonun — kendi adıma konuşayım — güzel tarafı doğru işi doğru modele gönderebilmesi olmalıydı. E peki, sonuç ne oldu? — tek modele kilitlenen sistem bunu yapamıyor. Daha fazla bilgi için MCP’nin Kör Noktası: 10 API, 300 Tehlikeli Tuş yazımıza bakabilirsiniz.
Cognitive OS fikri neden kulağa daha sert geliyor?
Bilim kurgu gibi geliyor ilk duyuşta (en azından benim deneyimim böyle). Ama özünde basit bir iddia taşıyor: ajan yalnızca verilen görevi yapan robot olmasın; bağlam toplayabilsin, hafızasını kullanabilsin ve gerektiğinde yön değiştirebilsin. Bu yüzden sadece workflow motoru değil de işletim sistemi benzeri düşünülüyor — mantıklı bir metafor aslında.
Böyle bakınca fark netleşiyor. Workflow harness size fabrika verirken Cognitive OS size sinir sistemi vadediyor diyebiliriz… çok mekanik oldu belki ama özetlemek için iş görüyor!
- Harness = kontrollü üretim hattı
- Cognitive OS = sürekli uyarlanan zihin katmanı — ciddi fark yaratıyor
- Biri görev odaklıdır (bence en önemlisi)
- Diğeri durum odaklıdır
Nerede hangisi mantıklı?
Küçük bir startup iseniz ve hedefiniz hızlı PR çıkarmaksa Archon tipi yaklaşım sizi bayağı rahatlatır. Çünkü ekipte herkesin elini taşın altına koymasına gerek kalmadan standart işleri otomatikleştirirsiniz; özellikle frontend ağır projelerde bu iş görüyor. Fakat aynı startup ileride müşteri destek botu, ödeme sistemi ve altyapı izleme üçlüsüne geçerse iş değişir…
İşin garibi, Kurum tarafında ise beklenti başka olur. Orada modelin yalnızca kod yazması yetmez; politika okuması, yetki sınırı tanıması, geri çekilmesi, gerekirse insan onayı istemesi gerekiyor — aksi halde otomasyon güzel görünür. Güven vermeyebilir. Ben buna iki kere şahit oldum: biri fintech demo’sunda, diğeri de Almanya merkezli lojistik firmasının pilotunda. İkisi de aynı cümleyi söyledi: “Göstermelik başarı istemiyoruz.” Haklılar tabii.
# Basit düşünce modeli
if task.type == "code_generation":
route_to("workflow_harness")
elif task.type in ["monitoring", "security", "operations"]:
route_to("cognitive_orchestrator")
else:
ask_for_human_review()
Ben olsam nasıl konumlandırırım?
Küçük bir detay: Açık konuşayım: Archon’u çöpe atacak halimiz yok. Tam tersine, doğru yerde kullanılırsa çok değerli. Onu genel amaçlı zeka platformu gibi satmaya kalkarsanız beklenti şişer — ama PR fabrikası, kodlama hattı veya test otomasyonu olarak görürseniz oldukça kuvvetli duruyor. Yani ürünün vaadi ile gerçek kapasitesini karıştırmamak lazım, bu kadar.
Bir dakika, şunu da ekleyeyim. Bugünün AI dünyasında en büyük hata çoğu zaman aracı yanlış metaforla açıklamak oluyor. Her şeyi “ajan” diye pazarlayınca insanlar bunun kendi kendine yaşayan organizma olduğunu sanıyor. Hayır. Bazısı sadece iyi yapılmış makine parçasıdır — ve dürüst olmak gerekirse bu da yeterince kıymetlidir!
Kusursuz mu? Değil.
Araya gireyim: Beni en çok düşündüren nokta şu oldu: bu tarz sistemler hız kazandırırken bağımlılığı da artırabiliyor. Ekibiniz büyük çoğunluk mantığı YAML zincirlerine gömerse yarın mimariyi değiştirmek sancılı olur, garantisiz. Aynısını geçtiğimiz yıl Rotterdam’daki küçük danışmanlık ofisinde duymuştum; bir noktadan sonra workflow sayısı arttıkça bakım yükü patlamıştı (ki bu çoğu kişinin gözünden kaçıyor)
Dürüst olmak gerekirse, Mesele teknoloji seçmekten ziyade sınırı doğru çizmekte yatıyor aslında. Kod üretimi mi istiyorsunuz? Harness yaklaşımı çok uygun olabilir. Ama altyapıyı izleyen, karar veren, kendini toparlayan sistemler istiyorsanız farklı kas grupları devreye giriyor — ve orada Python merkezli daha esnek tasarımlar öne çıkabiliyor. Neyse, bunu da not olarak bırakayım buraya:
Agent Hafızası Vektörden Zaman Çizgisine Geçiş
Sıkça Sorulan Sorular
Archon ne işe yarar?
Ha şimdi sorunun özü şu:
Archon yapay zekâ destekli kod üretimini belirli adımlara bölüp yönetmeye yarar.
Genelde planlama,
test etme ve PR oluşturma süreçlerinde kullanılır.
Kısacası kaotik modeli raya sokuyor.
Neden bazı kişiler Archon’u “workflow harness” diye tanımlıyor?
Çünkü sistem modeli serbest bırakmıyor;
ona önceden tanımlanmış adımlar içinde hareket ettiriyor.
Bu yüzden bağımsız zeka yerine orkestrasyon katmanı gibi davranıyor.
Cognitive OS ile farkı nedir?
Cognitive OS yaklaşımı daha esnek ve bağlam duyarlı.
Sadece işi yapmakla kalmaz;
hafızayı kullanır,
duruma göre yön değiştirir ve gerektiğinde farklı modellere rota açar.
Büyük şirketler hangisini tercih etmeli?
Tek cevap yok.
Kod üretimi ve tekrarlı görevlerde harness yaklaşımı yeterlidir;
ama operasyonel karar verme gereken senaryolarda daha esnek mimari gerekir.
Kurumsalda genelde ikisinin karışımı daha mantıklı olur.
- Neden?
- Ekip büyüdükçe bakım ihtiyacı artar
- Sabit akışlar tek başına yetmeyebilir
>💡 Bilgi:
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
