Ajanlarla böyle çalışıyorum: soy ağaçları, kurallar ve konuşarak üretim
WORKFLOWTekrarlanabilir çalışma akışı.VOICEKonuşma kaynaklı üretim.LINEAGEParent/child/relation soy ağacı gerekiyor.AI-DEVELOPMENTAI ile geliştirme pratiği.
Şu anda kendi çalışma şeklimi göstermek istiyorum. Bu sayfadaki her şey yaklaşık otuz dakikalık canlı bir konuşmadan çıktı: ben ekrana bakarak konuştum, konuşurken gördüklerimi kopyalayıp işaretledim, sonra konuşmayı olduğu gibi taze bir ajana yapıştırdım. Bu içeriğin kendisi o ajan tarafından yazıldı — ama benim konuşmamla.
Bu resim bir günün şantiye özetini gösteriyor; Source Control panelindeki staged ve changes sayaçları konuşma sırasında işaretlendi.
Mantığım genelde şöyle oluyor: ajanın yazdığı şeylere bakıyorum ve stage'e alıyorum. Commit yapmıyorum, sadece stage'liyorum; çok fazla ajanla çalıştığım için commit beni yavaşlatıyor. Commit ajanları çıkartıyorum; stage'lediklerimi onlar commit ediyor — commit kurallarım var, ona göre commit atıyorlar. Stage ve test sayılarını çok önemsemiyorum, çünkü geriye yönelik gitme eylemi neredeyse hiç yapmıyorum; tüm olanlar sadece forward oldu, ileriye odaklı gidiyorum.
Refactor modu. Ghostty kullanıyorum ve şu anda refactor modundayım. Yani sistemler zaten kurulmuş durumda; kurduğum bütün sistemler burada, sekme başına bir ajan.
Bu resim Ghostty terminalindeki ajan sekmelerini gösteriyor; her sekme kendi sorumluluk alanında otonom çalışan bir refactor ajanı.
Enerji döngüsü. Enerjim varken kurabildiğimi kurmaya çalışıyorum. Kırık da olsa, kafamda ne varsa hepsini somut hâle — bir yazılıma, çalışan bir ürüne — çevirmeye çalışıyorum; mümkün olduğunca en hızlı şekilde. Enerjim tükendiği zaman, ki bu burnout genelde çok çalışmaktan oluyor, zihnim biraz daha hafif kalıyor: daha az çalışmak istiyorum, evi toplayasım geliyor. İşte o arada bütün ajanları soy ağaçları dediğim işe veriyorum. Teorik olarak şöyle özetleyebilirim: uyanıkken sürekli büyümeye çalışıyorum, uyurken dayanıklılığa odaklanıyorum. Ben dinlenirken sistem de dinlensin, korunsun.
Soy ağacı nedir? Her projenin bağımlılık zincirini dibine kadar çıkacak şekilde ayarlamaya çalışıyorum. Dosyaları dağıtıyorum, parçalıyorum, bölüyorum; en kötü küçük dosyalar oluşturuyorum. Soy ağacından kastım şu: neyi silersem sistem kırılır? Eğer sildiğinde sistem kırılıyorsa o parça aynı soydan geliyor, bağımlılık olması lazım. Eğer silince sistem kırılmıyorsa bağımlılık olmaması lazım. Bunu çok iyi ve doğru bir şekilde kurarsam — ki bu çok zor — hiçbir ajan birbiriyle çakışmaz, çünkü zaten hiçbiri birbirine değmez. Kodlar, merkezler, proje aynı olsa bile çakışma imkânı olmaz. Teoride bu çok zor; sürekli geliştirme yaptıkça bunları tekrar güncellemek gerekiyor. Ama belli bir oranın üstünde bunu sözlü bir hâle getirebiliyorum — şu anda ajanlarla tam olarak onu yapıyorum.
Ajanlara verdiğim refactor talimatı. Her ajan kendi başına otonom çalışıyor; kuralları ve talimatı onlara ben başta veriyorum. Verdiğim refactor talimatının özü şu maddelerden oluşuyor — kendi projene uyarlayabilirsin.
Soy ağacına göre yeniden tasarla. Sistemi lineage graph'lara uygun yeniden tasarla ve böl; gerekirse package kur. Yanlış soydaki sistemi virüs gibi düzelt; soy üyeliği silinme-hayatta-kalma testiyle ölçülür, build'de değil runtime'da.
Runtime görünürlüğü kur. Hesap verebilirlik için dispatch table ve loglar ekle; arka planda dönen her iş iz bıraksın.
Impossible state'leri temizle. Gerekirse switch case ve discriminated union kullan; ama impossible state yoksa dokunma, sırf olsun diye yazma.
Aynı görevi iki kişiye verme. Authority'leri ve atanan görevleri de soy ağacına uygun tasarla; birbirinden bağımsız çalışan aktörler aynı soy ağacında ve aynı dosyalarda olmasın.
Runtime bağı yoksa build bağı da olmasın. Gerekirse kodu böl, package çıkart.
Uygulamalar arası sınırlara dikkat et. İki uygulamanın kullandığı bir işi ikisi birden çalıştırmasın; gerekirse headless servis kur. Arka plan işleri için kullanıcı yüzeyi açma; tek başına yaşamasının anlamı yoksa app olarak tanımlama, parent'ı yoksa kendiliğinden kapansın, birden fazla da açılmasın.
Her kullanıcı eylemi hesap versin. İzinler, depolama, kısayol gibi sınırlı kullanıcı eylemlerinin de soy ağacını çıkart. Sistem arka planda iş yapıyor olsa bile kullanıcıyla konuşmak zorundadır — bu da animasyon, motion, placeholder, ses gibi önceden tanımlı kurallara göre belirlenir.
Magic string bırakma. Bilgisayar veya dil değişince etkilenen sabit değerleri kodda yönetilebilir ve belirgin kıl.
Native'i önceliklendir. Ama custom çözüm bakım gerektirmiyorsa ve çok daha hafifse custom seçebilirsin; kritik unsur deterministik olması ve sıfır false-positive vermesidir. Custom sağlayamazsa native'e delege et, bakım yükünden kurtul.
Şantiyede çalıştığını unutma. Diğer ajanların scope'una karışma. Ve legacy destek koyma: cut over et, iz dahi bırakma; eski yol ancak davranış yeni soyda runtime'da yeniden ölçüldükten sonra silinir.
Kurallarım felsefi, implementasyonel değil. Bu zaten benim agent dosyalarım var — AGENTS.md dosyası. Bir de kendi rules dosyalarım var. Bunlar sistemleri kurarken keşfettiğim tekil kurallar: denediğim ve çalışanların kayıtlı olduğu kurallar — çalışmayanların değil. Ve bunlar implementasyonel kurallar değil; çünkü onlar codebase'de zaten var, onları yazmadım. Kural yazmadan önce filtrem şu: bu kural olmadan sistem kesinlikle ama kesinlikle bozuk kurulur mu? Cevap evetse kural olabilir — ve kodda yazmaması lazım. Kodda varsa zaten bozuk kurulamaz, compiler uyarır ve düzeltiriz. Bu yüzden kalanlar felsefi ya da principle tarzında kurallar. Mesela: sistem arka planda bir iş yapıyorsa kullanıcıya bunu kesinlikle bir şekilde göstermesi lazım — ve gösterme şekli yazı olmamalı, çünkü yazı insanı düşünmeye zorlar; animasyon, motion ya da resim kullanmamız gerekiyor. Bu bir prensip kuralı. Böyle bir kuralı beş yerde deniyorum; çalışınca doğru yere koyuyorum. Kural oluşturma kuralım da prompt'ta var — bunu özellikle söylüyorum, kural okuma kuralı da öyle. Bu şekilde sistem içinde kurallar birikmiş oluyor.
Kural örneklerinden birkaçı — denenmiş ve gerekli etiketiyle sistemde yaşayanlardan: [#agent:visibility-lifecycle-ancestor] görünürlük, yüzey-altı her işin lifecycle atasıdır; panel gizlendiğinde altındaki her iş — render, disk IO, playback, timer — görünürlükle birlikte ölür. [#agent:authority-read-order] kırpılabilir önizleme truth sayılmaz; okuma sırası önce kalıcı authority, ancak yokluğunda projection'a düşülür. [#agent:emit-refresh-edge] state'i güncelleyen sinyal varsa tüketiciye o sinyale abonelik de kurulur; "event loglanıyor ama UI güncellenmiyor" sınıfının kökü eksik kenardır. [#agent:diff-field-completeness] değişim-algılama karşılaştırması karar değiştiren her alanı taşır; eksik alan o alandaki değişimi sessizce yutar. [#agent:parallel-writer-discipline] aynı çalışma ağacında eşzamanlı yazarlar edit'leri küçük ve bölgesel tutar; çakışan bölge görülünce diğer yazara tek sınır mesajı verilir, başkasının yarım işi sessizce düzeltilmez. Başlıklardaki bu işaretler de birazdan anlatacağım çapalar. Kural dili böyle: etiketleme ve denendiğini ifade eden işaretler var. Bu denendi kısmı aslında kendim içindi; ama fark ettim ki ajan da bunları okuduğu zaman direkt tepki alabiliyor — "bunu denemişsin ve gerekli bir kural, yapmalıyız" diyor. O yüzden ajana da vermeye başladım.
Altyapı bir yılda oluştu. Altyapı çok geniş olduğu için aslında bunları yapabilir durumdayım. Yapay zekâlarla bir yıllık çalışma altyapım var — en azından Claude Code'la saydım; Claude Code'la yoğun bir yıllık çalışma diyebiliriz. Bunun son yedi-sekiz ayı da sürekli refactor ettiğim bir Mac uygulaması. Kuralı anlayabilmek için sürekli baştan yazdım.
Sorumluluk alanları ve şantiye. Ajanların her birine bir sorumluluk alanı veriyorum: dictation, clipboard gibi belirli bir alana sahipler. Bunlar çalışırken aklıma problemler geliyor. Gerçek örnek: bir clipboard problemi aldım diyelim. Bunu kestirdiğim iki ajana da atıyorum — hem dictation'a hem clipboard'a, çünkü ortak kod. "Bu senin scope'unda ise çözeriz, yoksa başkasına devredeceğim; senin değilse işine devam et, bildir" diyorum. Cevaplar geliyor: clipboard "bu benim scope'umda, benim çözmem lazım" diyor; dictation "bu benim scope'um değil, clipboard'a ver" diyor. Kendi aralarındaki konuşmayı ben yönetiyorum; çünkü ajanlar birbirleriyle konuşurken çok fazla bağlam siliniyor ve uzun işlerde hedeften sapıyorlar. Ben bağlama sahip olduğum için koordinasyonu yapabiliyorum. Bir de şantiye diye bir tabir denk geldi bana — Claude Fable ile çalışırken fark ettim. Bu ifadeyi ajanlara verdiğim zaman diğer ajanların da çalıştığını kestirebiliyorlar. Ama tek bir kelime her şeyi değiştiren bir olay değil; arka planda bir sürü kural mekanizması ve ajanların birbirleriyle nasıl çalışması gerektiğine dair kural dokümanlarım var.
166 kural dosyası. Kural dokümanlarım oldukça fazla ve genelde evrensel kurallar bandında vermeye çalışıyorum. İsim mantığını anlayabilmen için başlıklardan bir kesit vereyim — içerikleri değil, miktarı ve adlandırmayı göstermek istiyorum: action.policy.effect-preview.rules.md · adr.rules.md · agent.contract.attention-index.rules.md · agent.skill.closure.rules.md · carrier-generalization.rules.md · clipboard-app.rules.md · compose.contract.timeline-authority.rules.md · dictation.policy.hud-surface.rules.md · file.contract.filename-axis-grammar.rules.md · graph.contract.lineage-closed-universe.rules.md · hooks.contract.visible-output.rules.md · hotkey.rules.md · information.rules.md · markdown.contract.claim-status-grammar.rules.md · package.rules.md · preflight.rules.md · problem-solving.algorithm.structural-analogy.rules.md · runtime-proof.rules.md · security.macos.rules.md · service.contract.headless-lifecycle.rules.md · swift.contract.main-thread-dispatch.rules.md · term.registry.user-alias.rules.md · ui.contract.animation-motion.rules.md · whisper.policy.decoder-term-prompt.rules.md — ve devamı; toplam 166 dosya. Bunların her biri birbirine indekslenmiş dosyalar şeklinde geçiyor.
Çapalar. İndeks mekanizması Markdown başlıklarına koyduğum çapalarla çalışıyor: [#signal-carrier:local-preflight-name] ya da [#lineage-universe:edge-rule] gibi işaretler — ilki mesela preflight dosyamdan geliyor; göstermeye çalıştığım şey bu parçaların birbirlerine olan ilişkisi. Gerçi hızlı komutlar için # işareti koymuyorum, hızlı olmayan kurallar için koyuyorum. Her kural başka bir kurala bağlı ve bir kural içinde öteki kuralı çağırıyorsun; ajanlar da bir kuralı okuduklarında onunla alakalı kuralı okuyorlar. Bunu önce dosya sistemiyle yapmıştım ama her zaman okumadıklarını fark ettim; bir de dosya sisteminde çok fazla alakasız kural sisteme sızıyordu. Özellikle Claude okumuyor — kendi harness ortam promptları daha fazla olduğu için benim promptlarıma daha az uyuyor; Codex daha hafif bir terminal aracı olduğu için kurallara uyuyor. Bu bir gözlemim. O yüzden kural dosyası okutmak yerine kendi kural mekanizmamı veriyorum:
Bu resim cos anchor komutunun gerçek bir çağrısını gösteriyor; consumer, session ve çapa argümanları konuşma sırasında tek tek işaretlendi.
Buradaki mantık soy ağaçlarıyla aynı: her bir kural başka bir kurala bağlı ve birbirine bağlı kuralları sürekli ajanlarla tekrar indeksliyorum — hangi kural öbürüne bağlı, aralarında nasıl bir ilişki var. Böylece bir kural ağacı oluşuyor. Bu komut, bir kural çağrıldığında onun bütün aşağı soyunu veriyor; yukarıyı değil, çocukları ve torunları. Bu sayede ajanların kuralları doğru aldığına emin olabiliyorum. Bu cos komutu benim en kilit komutlarımdan bir tanesi — olmazsa olmaz sistem komutum.
Ajan telemetrisi. Aynı insan sistemlerini düşün: kullanıcı neye tıklamış diye telemetri toplarız. Aynısını ajanlar için yapıyorum. Hangi ajan hangi kuralı kullanmış, kurallar arasındaki ilişki düzgün kurulmuş mu — başka bir ajanla bunun denetimini yapıp soy ağacını güncelliyoruz; sürekli çağrılan ama ilişkisi olmayanları bulup temizliyoruz.
Uçuş öncesi: session start hook. Ajanlara bir session start hook'um var: konuşma başladığı anda çalışıyor ve "ilk görevlerini al" tarzı bir talimat veriyor. Buna pre-flight diyorum, uçuş öncesi. Ajan oradan zincirleme bir şekilde, benim niyetime göre diğer kuralları toplayarak ilerliyor.
Bu resim session start hook'unun gerçek çıktısını gösteriyor; CONTEXT_GATE ajanı kural toplamadan ilerletmiyor.
Büyük bir işse konuşmanın ilk yüzde 20-30'luk context'i kurallara gidiyor. Token kullanımı artıyor ama işin kalitesi dehşet yükseliyor. O yüzden ben token'ı fazla kullan ama kaliteli olsun diyorum; sonrasında test etmek ve bağlam bulmak için token harcamayalım. Kısa vadede daha çok ödüyorsun, uzun vadede daha çok kazanıyorsun — çünkü kalite problemi yok. Ayrıca ajan istediği şeyi bulana kadar projedeki her yeri gezmiyor; ajanın yanlış yönde gitmesi en yüksek token maliyetini oluşturan şey. O yüzden başta hedefin net olması lazım.
Kuralları yolda vermeyi denedim, olmadı. Kuralları yolda vermeye çalışınca şunu fark ettim: ajanın kafası karışıyor — hepsini yapamıyor, yönden çıkıyor, asıl hedefi unutuyor. Benim de kafamı karıştırıyor; sürekli bir şey spawn'lanıyor, yönetimi zor, yakalaması ayrı zor. O yüzden bunu ajana devrettim: sadece başlangıçta bütün hepsini toplamaya çalışıyor. Sonra yapılacak işi donduruyoruz — plan dediğimiz mod gibi; ben plan modunu kullanmıyorum, kendi yapımı kullanıyorum ama teoride yine plan yapıyor. Ajan kuralları topluyor, niyetimi topluyor ve hedefi bana tek seferlik gösteriyor: "Bunu yapayım, okay mi?" Okay deyip gönderiyorum. Burada kilit nokta: okay dediğimde yeni ajan açılmıyor, aynı ajandan devam ediyor. Çünkü en çok değer verdiğim şey bağlam; token kullanımı ne kadar yüksek olursa olsun, bağlam konumuzla alakalıysa kesinlikle sıfırlamıyorum.
12 saat çalışan ajan. Ajanlardan mümkün olduğunca goal oluşturmaya çalışıyorum: bütün görevleri ve hedefi başta veriyorum, sonrasında kendi başlarına hedefe doğru ilerlesinler istiyorum. Mesela bir dictation ajanım şu anda 12 saattir çalışıyor. Bu çok uzun bir iş — refactor yapıyor — ve 12 saattir çalışan bir ajanın hedeften sapmaması gerekiyor.
Bu resim 12 saattir çalışan dictation ajanının terminalini gösteriyor; sağ alttaki sayaç konuşma sırasında işaretlendi.
Merak edenler için, şu an aktif çalışan ajanların süreleri: bir tanesi on saat, bir tanesi on bir saat, teki üç saat, teki yine üç saat, teki on iki saattir çalışıyor — hepsi refactor, fark ettiysen. Bazıları block kısmına düşüyor; onları topluyorum.
Bu resim forge refactor ajanının terminalini gösteriyor; sağ altta Pursuing goal 10h 25m yazıyor.
Bu resim clipboard refactor ajanının terminalini gösteriyor; sağ altta Pursuing goal 11h 59m yazıyor.
Bu resim cockpit ve terminal refactor ajanını 3 saat 5 dakikada gösteriyor; compact sonrası cos anchor ile gate'lerini yeniden açmış.
Bu resim cos refactor ajanını 3 saat 17 dakikada gösteriyor; kendi runtime judge'larını koşuyor.
Bu resim dictation ajanının 12 saat 53 dakikadaki hâlini gösteriyor; Swift kodunda gerçek bir diff üzerinde çalışıyor.
Üretim bende, belirsizlik ajanlarda. Kritik konsept şu: eğer başlarında ben varsam ajanları üretim için, yeni bir şey üretmek için kullanıyorum — üretim kısmını ben söylüyorum, kontrol ediyorum; bütün niyet ve yaratım kısmını kendim üstleniyorum. Ama başlarında durmayacaksam, otonomiyle gidecekse ya da ben uyurken çalışacaklarsa üretim kısmını kapatıyorum ve ajanlar sadece belirsizlikleri çözmeye çalışıyor. Yani sistemin runtime'da nasıl davrandığına dair kısımların build time'da, kodun yazıldığı yerde belirgin hâle gelmesini sağlıyoruz.
Runtime belirsizliği alma. Ajanlar genellikle her şeye nil koyuyor. Elli tane nil'li obje olunca runtime'da nasıl çalıştığını anlayamıyoruz; ulaşılamaz durumlar kod tarafında bug'ları görmemizi engelliyor, çünkü hepsi runtime'da gözüküyor. Bunun ilacı discriminated union ve impossible state konseptleri. TypeScript'te şöyle görünüyor: type PasteResult = { kind: "delivered"; at: Date } | { kind: "fault"; reason: string } — artık "teslim edildi ama fault sebebi dolu" gibi imkânsız bir durum yazılamıyor. Tüketen taraf da switch (result.kind) ile default'suz kapanıyor; yeni bir durum eklendiğinde compiler seni uyarıyor. Swift'te aynı şey: enum PasteResult { case delivered(Date); case fault(reason: String) } ve default'suz switch result — case dışı bir değer derlenmiyor bile. Switch case koyunca başka problemler de ortaya çıkıyor: mesela o case içinde olmayan bir değer kullanılmış, ajan tahmini bir değer atmış — sallamış yani. Bunlar kod tarafında yakalanabiliyor. Ajan bunu yeni bir şey üretmeden, sadece kodu anlayarak yapabiliyor; runtime'da loglar var, loglara bakıp teyit edebiliyor ya da değiştirip çalıştırıp bakabiliyor. Loglar çok kritik.
Kodda soy ağacı işi. Ajanlar bağımlılıklara bakıyor: hangi kaynak kod hangisini kullanıyor, gerçekten runtime'da kullanılıyor mu, bunu kaldırınca kod kırılıyor mu — kendi testlerini yapıyorlar. Bir dosya düşün: yüzde ellisini bir package kullanıyor, yüzde kırkını başkası, hiç kimse yüzde yüzünü kullanmıyor. O dosyayı ikiye parçalıyor. Amaç yine soy ağacı: herkes kendi kullandığı kodu import ediyor ve soy ağacının bir kısmı oluşunca birkaç ajanın topluca çalışabileceği altyapı da oluşmuş oluyor. Parçaladıkça ajanlar bazı içeriklerin iki kere kullanıldığını ya da aynısının tekrar tekrar tanımlandığını fark ediyor — bunlar drift; aynı görevi iki farklı kişiye vermek gibi. Sorumluluk dağılımının yanlış olduğu kendiliğinden ortaya çıkıyor ve ajan bunları tek bir sorumluluk ağına bağlıyor. Runtime'da "bu niye hareket ediyor da bu etmiyor?" diye yakalayacağımız soruların cevabı build time'da çözülmüş oluyor. Bu iş hem uzun sürüyor hem genelde sıkıcı — sonuca doğrudan etkisi olmadığı için insan itip bırakıyor; ama kaliteyi, stabiliteyi, dayanıklılığı artırıyor. Bunları ben uyurken yapıyorlar.
Denetlemeyi görsel katmanda yapıyorum. Gece işlerinde runtime değişikliği yapılmadığı için denetlemeyi kod okuyarak yapmıyorum; denetlemede kodlama hiç yapmamaya çalışıyorum, çünkü kod beni düşündürüyor ve yavaşlatıyor. Görsel katmanda yapıyorum: ajanlar görsel testleri benim ikinci bilgisayarımda yapıyor.
Bu fotoğraf çalışma masasını gösteriyor; sağdaki laptop, ajanların görsel testleri koştuğu ikinci bilgisayar.
Zaten uygulamanın kendisini kullandığım için normal kullanım akışına devam ediyorum — beni sürekli test hâlinde düşünebilirsin. Karşılaştığım problemi anında çözüyorum; bir şey kırıldıysa git geçmişinden alınabiliyor, ne olduğunu biliyorum, hemen topluyorum. Derdim "mükemmel sistem kurulsun diye kaynak kodların hepsini okuyayım" değil; her şey görsel olsun, UI katmanına aktarılsın, bir şekilde loglar olsun, insana gözüksün. Akıp giden bir iş varsa da log olsun, hesap versin tarzında kurallarım var. Ajanlar zaten kendileri bakıyorlar; kaçarlarsa ben kullanım tarafında görüyorum ve diyorum ki: "Bak bir şeyler bozulmuş, loglara bak. Kim bozmuş bunu?" Buluyorlar, çözüyorlar ya da Git'ten bakıyorlar.
Bağlamı dinamik tutan sistem. Özellikle goal uzun olunca ajan kesinlikle hedeften sapıyor; hele şimdi anlatacağım şeyi kullanmazsak verdiğimiz başlangıç işini bile unutabiliyor. Çünkü goal kendi başına çok dümdüz bir şey: ajan durduğu için aynı promptu defalarca veriyor — çok anlamlı bir şey değil, sadece tekrar ettirmeye çalışıyor gibi. 12 saat çalışan ajanın hedeften sapmamasının arkasındaki asıl şey transcript sistemim. cos içinde kendi transcription metodum var: chat'in session ID'sini veriyorsun; bu chat içinde benim söylediğim mesajları, ajanın bana söylediği mesajları ve ajanın düzenlediği dosyaların yollarını alan kırpılmış bir transcript çıkarıyor. Mantığı şu: konuşma içinde değişiklik oluşturan şeyi almaya çalışıyoruz — insanın konuşması, ajanın cevabı (çünkü ben ona tepki veriyorum, düşünce sürecini değiştiriyor) ve değiştirilen dosyalar. Bunlar 260 binlik bir context penceresinde yaklaşık 40 binlik bir alan alıyor. Geri kalanlar — dosya okumaları, kural okumaları — disposable, atılabilir; davranışı değiştirmek için kullanılan ara katmanlar önemsiz, sonuç önemli. 240'lık pencereden 40 binlik bir öz çıkıyor ve bunu ajana her compact'tan, yani sıkıştırılma anından sonra tekrar veriyorum. Sıkıştırma algoritması zaten konuşmanın başlıklar gibi bir özetini çıkarıyor; benim verdiğim orijinal konuşma ona dayanak veriyor ve ajan kaldığı yerden devam ediyor — odaklanması gereken yerde çift odak alıyor gibi. Konuşma ilerledikçe birikim riski var; sistemim bunu da ele alıyor: belirli bir limitin üstünde eski konuşmaları iptal ediyor. Her sıkıştırmayı yeni bir katman gibi düşün; iki üç eski sıkıştırmayı yavaş yavaş atıyor. Otonom ajanda zaten büyük birikim olmuyor: kaynak kod değişikliklerini dahil etmiyoruz, sadece dosya yolunu dahil ediyoruz; ajan otonom gidiyor, dosya düzenliyor, kendi kendine konuşuyor, onların çoğu çöpe atılıyor. Bu sayede bağlam statik duran bir doküman değil, konuşma içinde sürekli güncellenen dinamik bir forma giriyor.
Uyanınca kural hasadı. İş bittiği zaman ajana soruyorum: "Burada keşfedilen ve kurallarımızda olmayan bir kural var mı?" Bu da aslında soy ağacı mantığı: bu kural olmazsa sistem bozulur mu? Bana veriyor, ben denetliyorum — bunları bilhassa kendim denetliyorum, çünkü kaynak koddan daha önemli olduğunu düşünüyorum. Sonra o kuralları sistemime tekrar dağıtıyorum; sürekli birikerek artıyor. İki kural farklı şey söylüyorsa bunu matematik formülü gibi ele alıyorum: formülün çalışmadığı bir senaryo gelirse önceki formülü koşullandırırsın. Aynı mantık — "bu kural sadece şu alandayken geçerli, yoksa şunu kullan" diye link koyuyorum. Ajanlarla çalışırken kurallara bilhassa denenmiş ve gerekli etiketi olanları alıyorum, çünkü ajan çok fazla sallıyor; kendim için denenebilir, faydalı tarzında kural yapılarım da var — kendi fikirlerim, onları bizzat kontrol ediyorum.
Bu içerik nasıl üretildi. Bu benim agentics çalışma şeklim; bütün altyapıyı ve sistemi buna göre kurdum ve ajanlarla konuşarak konuşuyorum — çünkü çok fazla bağlam gereksinimi var. Şu an bu içeriği bile ajanıma sesli olarak anlatıyorum. Anlattığım her sistemi kullanıp fotoğraflarını ve çıktılarını alıyorum; konuşmayı yaparken ajanlarım çalışıyor — on tane ajan çalışıyor, bir tanesine bunu anlatıyorum. İçeriğin kendisi ajan tarafından çıkmış olacak ama benim konuşmamla; ve konuşmam şu anda tahmini yirmi beş, otuz dakika. Bir sunum gibi anlatıyorum.
Bu resim konuşarak içerik üretirken kullandığım düzeni gösteriyor; konuşma, transkript, yakalananlar ve kısayollar aynı anda görünür.
Konuşurken etiketleme de yapıyorum demiştim; etiket yapma panelim de burası. Genelde rectangle kullanıyorum — konuşmamla etiketlediğim şeyleri sıralıyor.
Bu resim konuşma sırasında kullanılan etiketleme panelini ve rectangle aracını gösteriyor.
Ve sonrasında ne yapıyorum? Hazırda bekleyen bir ajanım var — yeni açtım, öteki on bir ajanla birlikte yanda çalışacak. Konuşmayı direkt olduğu gibi ona yapıştıracağım ve kendisi tam otonom bir şekilde hedef belirleyerek bu içeriği oluşturacak. Bunun için Codex ya da Claude, ikisini de deneyeceğim; hangisi alacak bilmiyorum. Çünkü otuz dakikalık bir konuşma ziyan edilmez.
Bu resim konuşmayı devralacak taze ajan terminalini gösteriyor; sekme, boş bağlamlı terminal ve prompt satırı işaretli.
Bir de fark ettiysen hangi uygulamadan ve hangi ajandan kopyaladığımı gösterebilen bir mekanizmaya sahip. Son olarak konuşma geçmişlerimi gösterdiğim paneli göstereyim. Konuşma geçmişine dikkat edersen çizimlerimi gösterdiği kısımlar var — rectangle diye geçmiş. Anchor dediğim an çizim yapmışım, o da yapay zekâma gidiyor. Zaten şu an kayıttaydı; canlı konuşmayı görüyorsun. Konuşma sürekli kaydedildiği için bozulma riski yok: bilgisayar kapandı, internet koptu — otuz dakikalık konuşma çöpe gitmiyor, sürekli yedekleniyor. Çünkü çok değerli; insan üretimi inanılmaz değerli. O yüzden çok sorunsuz ve hızlı şekilde toplanması lazım.
Bu resim konuşma geçmişi panelini gösteriyor; kayıt listesi, çizim izleri ve toplam süre konuşma sırasında işaretlendi.
optionOS bunun tamamlayıcısı. Bütün araçları kendi sistemlerim içinde geliştirerek kuruyorum ve hepsini adım adım paylaşmaya başlıyorum — çalıştıklarına emin olduklarımı, stabil hâle gelenleri. İlk ürün de zaten optionOS, ilk konuşma ürünü. Çünkü bağlam en kritik unsur ve en önemli bağlam da insanın bağlamı — kişinin zihnindeki o fikir dediğimiz kısım. Fikri çıkarmak için yazmak çok yavaş; bu yüzden yazmak yerine konuşmak lazım, bir. İkincisi, konuşmak yeterli değil: insanın bir şey görmesi lazım ki hatırlayabiliyor olsun — bakarak konuşması gerekiyor. O yüzden konuşurken kopyaladığımız şeyleri sıralayan bir uygulama geliştirdim. Ben şu anda bilgisayarımdaki görsel olaylara, ajanların çıktılarına, kendi sistemlerimin çıktılarına bakarak bu konuşmayı yapıyorum. Yazmıyorum; yazı da okumuyorum, çünkü insan yazıya baktığı zaman düşünüyor ve düşünce yavaşlatıyor. Yazıdan mümkün olduğunca kaçmamız gerekiyor; daha çok bedensel, daha çok sezgisel çalışmamız lazım. O yüzden sistemlerin hepsi resim ve animasyon odaklı kurulmalı. optionOS de vizyon olarak bunu takip ediyor: insana mümkün olduğunca az yazı, mümkün olduğunca resim ve animasyon — insan sadece görsel öğelere baksın, kaynak koda hiç bulaşmasın. Görsel öğelerdeki soy ağacı konseptini hatırla: kaynak kodla görsel objenin ilişkisini ajana fotoğraf çekerek verebiliyor olsun. Buna inspector diyorum — Chrome'daki DOM inspector'lar gibi; kaynak koda görselden bakabiliyorsun. Bunu Mac için hem Chrome'da çalışan hem kendi Mac uygulamamda çalışan, fotoğrafla ajana verebildiğim yapılar üzerine çalışıyorum. Ajana "şu kodu değiştir" değil, "şu objeyi değiştir, şu kırık, bu kırık" diyorum — ve bu, konuşma içinde oluyor. Sadece tuşlara basıyorum; inanılmaz hızlı context çıkıyor.
Öncelikle bu vizyonun, bu çalışma stilinin verimli olduğunu deneyip içselleştirmen lazım; ondan sonra bu gereksinimin ne kadar önemli olduğunun farkına varıyorsun. Ondan sonra optionOS zaten elin ayağın oluyor — benim şu an elim ayağım, her sistemi bunda kullanıyorum. Ekosistemin diğer oyuncuları da var: ajanların yönettiği Cockpit tarzı görsel panellerim ve Clipboard dediğim kısımlar; onları başka bir konuşmada adım adım anlatacağım. Eğer sistemi ya da — daha önemlisi — anlattığım çalışma mantığını denemek istiyorsan hiç bekleme, hemen denemeye başla. optionOS sistemlerini kullanmak için bana ulaşabilir ya da optionos.app sitesinden davet listesine girebilirsin. Bu içerikten geldiğini yazarsan bekleme sırasında seni önceliklendirmeye çalışacağım.