Ajan tabanlı kodlama (agentic coding), teknoloji dünyasının standartlarına göre bile benzeri görülmemiş bir hızla değişiyor. Çevrim içi olarak mevcut olan öğreticiler ve kaynaklar çoğunlukla basit sıfırdan başlanan (greenfield) senaryolardaki münferit özellikleri ele alıyor.

Bob'ı geliştirirken ve çok çeşitli sektörlerden sahadaki sayısız uygulayıcıyla etkileşim halindeyken, Bob'ı kullanma deneyimini ve etkinliğini artırmaya yardımcı olan bir dizi kavram ortaya çıktı.

Bu kavramlar, ana akım olmayan teknolojileri kullanan karmaşık projeler için de geçerlidir.

Kavram 1: Döngü — keşfet, planla, uygula, doğrula (explore, plan, implement, verify)

Rehberlerin ve sensörlerin sürekli iyileştirilmesi için bir dış döngüye sahip keşfet, planla, uygula, doğrula döngüsü

Ajan tabanlı Yazılım Mühendisliğinde en yaygın başarısızlık biçimi yapı eksikliğidir. Konuşma tutarlılığı yapı izlenimi verir ve bir uygulamanın tüm adımlarını tek bir sohbet oturumuna sığdırma eğiliminde oluruz. Oturumlar üretken hissettirir, ancak bunun maliyeti ancak inceleme sırasında görünür hale gelir.

Kodu elle yazmak kendi yapısını dayatıyordu. Uygulama maliyetliydi, bu yüzden uygulamadan önce plan yapmak sezgisel olarak mantıklı geliyordu. Yazdıkça kavrayış birikiyor ve hatalı varsayımlar bu süreçte büyük olasılıkla yüzeye çıkıyordu. Yapay zeka ajanları bu sürtünmeyi ortadan kaldırıyor. Artık kod üretmek ucuz ve bu durum yapıya yönelik sezgimizi de ortadan kaldırdı. Bir zamanlar yavaşlığın bir yan ürünü olan yapı, artık bilinçli olarak oluşturulmalıdır.

Bu döngüyü bilinçli olarak kullanmak gerekli yapıyı sağlayabilir:

Keşfet (Explore) anlamayı sağlar
Planla (Plan) kararlar üretir
Uygula (Implement) kod üretir
Doğrula (Verify) kanıt üretir.

Bu döngüyü takip etmek odaklanmış ve yapılandırılmış kalmana, hedeflerine daha hızlı ve daha tutarlı bir şekilde ulaşmana yardımcı olur.

Döngüden tek bir geçiş yirmi dakika veya üç gün sürebilir. Bir geçiş alt döngüler içerebilir ve zamanın aşamalar arasında nasıl bölüneceği göreve göre büyük ölçüde değişir.

Döngünün ayrıntılı bir incelemesini aşağıda Derinlemesine İnceleme: Döngüyü Çalıştırma bölümünde bulabilirsin.

Kavram 2: Bağlam penceresi (context window) kıt kaynaktır

Bağlam penceresi konusunda bilinçli olmak en yüksek getirili alışkanlıktır.

Bağlam penceresi nedir?

Modeller durumsuzdur (stateless). Bir sohbet, belleği olan çalışan bir oturum değildir: her tur önceki her mesajı yeniden gönderir ve yeni yanıtı sona ekler. Bağlam penceresi, bir modelin bu turlardan birinde kabul edebileceği maksimum girdi miktarıdır. Bob V2'de bu 270k tokendir (bağlam penceresi yönetimi).

Pencere ilk mesajdan önce dolmaya başlar:

En başta yüklenenler: Bob'ın sistem istemi (system prompt), aktif modun açıklaması, deponun agents.md dosyası ve bağlı her Model Context Protocol (MCP) aracının açıklaması (Bob'ta MCP).
Oturum sırasında görünmez bir şekilde eklenenler: dosya okumaları, araç sonuçları, Bob'ın çektiği beceri (skill) dosyaları, alt ajan çıktıları.

Bağlam penceresi dolar ve bir özet halinde sıkıştırılır

Pencere dolduğunda Bob konuşmayı sıkıştırır (compact). Bob şimdiye kadarki konuşmayı bir özetle değiştirir ve çalışma devam eder. Bu, oturumu canlı tutar ve tasarımı gereği kayıplıdır. Bob hangi ayrıntıların kalacağına otomatik olarak karar verir ve kaybolanları hiçbir şey işaretlemez. İki kez sıkıştırılmış bir oturum, bir özetin özeti üzerinde çalışır.

Tek bir MCP çağrısı on binlerce token döndürebilir ve bir dizi dosya okuması, oturumun daha önceki kısımlarında tartışılanları seyreltebilir. Mod açıklamaları, kural dosyaları ve MCP sunucuları bunu daha yavaş ve daha az görünür şekilde yapar. Bob pencereyi kaynağına göre ayrıştırır ve kurulum büyüdükçe bu döküme tekrar bakmaya değer.

Mevcut oturumu kaynağına göre ayrılmış olarak göstermek için genişletilmiş Bob'ın bağlam penceresi göstergesi

Bobcoins temel olarak token başına hesaplanır. Dolayısıyla bir konuşmanın maliyeti uzunluğuna bağlı olarak karesel olarak artar. Uzun konuşmalar, kısa konuşmalara göre çok daha fazla Bobcoins harcar! (Bobcoins dokümantasyonu)

Bağlam penceresine karşı değil, onunla birlikte çalışın

İşi ayrı konuşmalara bölün. Bir görev, bir oturum. Bu, koddaki tek sorumluluk (single responsibility) prensibiyle aynı mantıktır. Bir konuşmanın var olmak için tek bir nedeni olmalıdır; örneğin "X bileşeninin mimari diyagramını çiz" veya "Y özelliği için bir uygulama planı oluştur." Bağlam penceresindeki her şey, işe yaramayan yaklaşımlar da dahil olmak üzere bundan sonra ne geleceğini etkiler. Tıkanmış bir oturum tıkanık kalma eğilimindedir çünkü başarısız denemeler hâlâ oradadır ve model bunları bu görevin neye benzediğine dair kanıt olarak okur (bağlam zehirlenmesi / context poisoning).
Bob ile tartışmak yerine geri alın (rollback). Bir konuşma istenmeyen bir davranışa saptığında, son iyi mesaja geri dönün, mesajı değiştirin ve oradan devam edin. Bu aynı zamanda Bob'ın yerel olarak yaptığı tüm değişiklikleri de geri alır; bu da bağlam penceresini küçük ve temiz tutar (geri alma / rollback).
Saklamaya değer her şeyi sohbette değil, bir dosyada tutun. Planlar, bulgular ve kararlar bir dosyaya aittir. Bir iş arkadaşı markdown belgesini inceleyebilir ve onu yeni bir oturuma aktarabilir; sohbet günlüğü ise bunların hiçbirini yapamaz.
Alt ajanlar (subagents) toplu işleri bağlam penceresinin dışında tutar. Bob ne zaman bir alt ajan çalıştıracağına karar verir ve yalnızca bulgular geri gelir. Bir görev kimsenin okumasına gerek olmayan bir çıktı üreteceğinde doğrudan bir alt ajan istemek de işe yarar (alt ajanlar).
Bağlam penceresine neyin girdiğine ve değer katıp katmadığına dikkat edin. Aşağıdaki konuda ele alındığı gibi kılavuzlarınızı ve sensörlerinizi düzenli olarak kontrol edin ve bunları geliştirmeye zaman ayırın.

Kavram 3: İki tür yapı taşı — kılavuzlar (guides) ve sensörler (sensors)

Uzun bir proje boyunca kod tabanının daha iyiye mi yoksa daha kötüye mi gittiği, Bob'tan ziyade onun çalışmasını neyin şekillendirdiği ve çıktısını neyin denetlediğiyle ilgilidir. Kullanılabilir birçok yapı taşı vardır: kurallar, beceriler (skills), modlar, kancalar (hooks), alt ajanlar, harici linter'lar ve inceleme ajanları. Neredeyse hepsi iki işten birini yapar.

Kılavuzlar (Guides), Bob çalışmadan önce veya çalışırken onu yönlendirir (İleri besleme / Feedforward). Kurallar, beceriler ve modların tümü kılavuzdur.
Sensörler (Sensors), Bob işlem yaptıktan sonra geri bildirim sağlar (Geri bildirim / Feedback). Testler, linter'lar, tip denetleyicileri, etkileşimli tarayıcı oturumu ve inceleme ajanlarının hepsi sensördür.

Dizüstü bilgisayardaki bir insan Bob'a bir ok doğrultur ve Bob da koda bir ok doğrultur. Kurallar, beceriler ve modlarla açıklamalandırılmış "guides" etiketli bir ok Bob'a yukarıdan gelir. Testler, linter'lar ve inceleme ajanlarıyla açıklamalandırılmış "sensors" etiketli bir ok koddan Bob'a geri döner.

1. Kılavuzlar (Guides)

Bob'a çalışmayı yönlendirmesi için sağlanan her şey bir kılavuzdur. Bu konuda sana yardımcı olacak üç ana yapı taşı vardır ve bunlar yazdığın istemin yanı sıra bağlam penceresine metin ekleyerek çalışırlar. Bu metnin ne zaman geldiği ve onu neyin tetiklediği konusunda farklılık gösterirler.

Kurallar her zaman aktiftir, modlar kullanıcı tarafından etkinleştirilir, beceriler Bob tarafından etkinleştirilir

Kurallar (Rules) her zaman aktiftir. Depo kökündeki agents.md ana kuraldır ve bununla ilgili temel tavsiye onu kısa tutmaktır. Her satır her bir turda dikkat çekmek için yarışır, bu nedenle uzun bir kural dosyası Bob'ın içindeki herhangi bir kuralı takip etmesini zorlaştırır (kurallar).
Modlar (Modes) kullanıcı tarafından etkinleştirilir. Entegre modlar şunlardır: Ask salt okunurdur. Plan, bir planlama süreci boyunca çalışır ve sonucu eyleme geçen Agent moduna iletir. Özel modlar kolayca eklenebilir (modlar, özel mod ekleme).
Beceriler (Skills), Bob ilgili olduklarına karar verdiğinde etkinleştirilir. Yalnızca küçük bir beceri açıklaması her zaman aktiftir. Becerinin ana gövdesi yalnızca talep üzerine bağlama yüklenir. Bu, becerileri token açısından oldukça verimli hale getirir (beceriler).

Kural dosyasındaki her şey, bu turun buna ihtiyacı olup olmadığına bakılmaksızın her turda token kullanır; bu nedenle onu asgari düzeyde tutun ve geri kalanının geçerli olana kadar beklemesine izin verin.

2. Sensörler (Sensors)

Bob'a üretilen çalışma hakkında geri bildirim veren her şey bir sensördür. Hangi sinyallerin yararlı olduğu kod tabanına ve teknoloji yığınına bağlıdır, bu nedenle sahip olunmaya değer set projeden projeye farklılık gösterir ve bir araya getirilmesi gerçek bir çaba gerektirir. En değerli sensörler, makine tarafından çalıştırılabilen ve uygulama aşamasında Bob tarafından yürütülen sensörlerdir. Sensörler iki farklı kategoriye ayrılabilir.

Hesaplamalı sensörler (Computational sensors) deterministiktir: testler, linter'lar, tip denetleyicileri, derleyiciler. Kararlar kesin ve tekrarlanabilirdir, Bob'ın sık sık çalıştırması için yeterince ucuzdur. Kapsam, bir ekibin oluşturduğu ve bakımını yaptığı sistemlerle sınırlıdır.
Yapay zeka tabanlı sensörler (AI-based sensors) esnektir ve deterministik değildir. Bir inceleme ajanı niyet ve linter'ın kuralı olmayan şeyler için okur. Çıktı bir ölçüm değil, bir değerlendirmedir. Çalıştırmalar arasında farklılık gösterir; maliyetler ve süre ne sıklıkla kullanılabileceğini sınırlar (kod incelemeleri).

Bunları bağlamak için, kabaca sürtünme sırasına göre birkaç seçenek vardır:

Kancalar (Hooks) en az sürtünmeli deterministik seçenektir. Bir denetim, Bob'ın ilgili olduğuna karar verip vermediğine bakılmaksızın her seferinde sabit bir noktada çalışır. Kancalar dokümantasyonuna bakın.
Beceriler (Skills) genellikle kılavuz olarak kullanılır, ancak bir inceleme çalıştıran bir beceri sensördür ve deterministik olmayan bir denetim eklemenin en düşük sürtünmeli yoludur. Beceriler dokümantasyonuna bakın.
Sürekli Entegrasyon (CI), tek bir geliştirici yerine tüm ekip için her çekme isteğine (pull request) bir inceleme ajanı yerleştirir. PR inceleme ajanını iş başında görün.

Derinlemesine İnceleme: Döngüyü Çalıştırma

Aşama sınırları aynı zamanda bağlam sınırlarıdır; bu da onları ayrı tutmanın pratik nedenidir: keşif konuşmalarının kodun yazıldığı sohbette yeri yoktur.

1. Keşfet (Explore)

Keşif, rolünüze ve elinizdeki göreve bağlı olarak büyük ölçüde değişir. Yeni bir kod tabanına alışmak anlamına gelebileceği gibi, büyük bir yeniden düzenlemenin (refactoring) etki alanını tahmin etmek de olabilir. Bazı örnekler:

Herhangi bir şeyi değiştirmeden önce Bob'ın mevcut sistemin bir mimari diyagramını oluşturmasını sağlayın. Mimari diyagramları oluşturma öğreticisine veya aynı konunun videosuna bakın.
Biri ürün içinde gezinen bir kullanıcı, diğeri kod içinde gezinen bir geliştirici olarak iki açıdan özelleştirilmiş bir başlangıç rehberi isteyin. Uzmanlığınız ve göreviniz hakkında bilgi vermek, belgenin uyarlanmasına yardımcı olur (bir kod tabanını inceleme).
IBM Z ve IBM i üzerinde platforma özel seçenekleri kullanın. Bu sistemlerdeki keşif problemi farklıdır ve premium paketlerde sağlanan özel araçlardan büyük ölçüde yararlanır. Z için Premium Paket (dokümantasyon) ve IBM i için Premium Paket (dokümantasyon) sayfalarına bakın.

Keşif, silmeyi planladığınız şeyleri inşa etmeyi de içerebilir. Uygulama artık ucuzdur, bu nedenle dar kapsamlı bir prototip, bir yaklaşımın kod tabanıyla temas ettiğinde hayatta kalıp kalamayacağını öğrenmenin en hızlı yoludur. Kent Beck yirmi beş yıl önce buna "spike" uygulaması adını vermişti ve disiplin aynıdır: bir şeyler öğrenmek için oluşturun, öğrenilenleri saklayın, kodu çöpe atın.

Ucuz uygulama, mimarinin ve kod kalitesinin değerini düşürmek yerine artırır. Artık çalışan ve yanlış olan çok miktarda kod üretmek kolaydır.

2. Planla (Plan)

Planlama aşaması en büyük kaldıracın olduğu yerdir. Planın doğru yaptığı her şey iki kez kazandırır: bir kez uygulamada ve değişiklik yazarın elinden çıkıp bir iş arkadaşının incelemesi gerektiğinde tekrar.

İyi bir planın nelere ihtiyacı vardır:

Hem kısa hem de kesin olmak. Planların okunması gerekir.
Belirsiz kısımlar da dahil olmak üzere hedeflenen sonuç hakkında net olmak. Nelerin bilinmediğini bilmek işin çoğudur, geri kalanı ise bunları öğrenmektir.
Bir dosya içinde olmak. Planlar bir sohbet oturumunda yaşamamalıdır.

Bir plan oluşturmanın birçok yolu vardır, ancak entegre Plan modu başlamak için en kolay yerdir (bu öğreticide olduğu gibi). Plan Modu uyumlu olacak şekilde oluşturulmuştur ve boşlukları doldurma eğilimindedir. Bu birçok durumda hızlı yinelemelere olanak sağlarken, bazen daha fazla titizlik gerekir. Varsayımı sorgulamadan, kötü bir varsayım etrafında yetkin bir plan oluşturabilir. Planla tartışan özel bir beceri — örneğin Matt Pocock'ın grill-me becerisi — varsayım koda dönüşmeden önce inceleme almanın en ucuz yoludur.

Spesifikasyon güdümlü geliştirme (SDD) üzerine. Bu terim çok geniş bir alanı kapsar ve hâlâ değişim halindedir. İnsanlar buna evet ya da hayır kararı gibi yaklaşıyor, ancak bu daha çok bir yelpazedir:

Spec-first (Önce spesifikasyon): plan uygulamadan önce gelir. Bu neredeyse tartışmasızdır.
Spec-anchored (Spesifikasyona bağlı): spesifikasyon, dokümantasyon olarak ve uygulamaların karşılaması gereken standart olarak uygulamadan sonra kalır.
Spec-as-source (Kaynak olarak spesifikasyon): spesifikasyon kaynak dosyadır. İnsan spesifikasyonu düzenler; insan kodu düzenlemez.

Hangi seviyenin uygun olduğu ekibe, kod tabanının kritikliğine/olgunluğuna ve sektöre bağlıdır. SDD'nin daha yüksek seviyeleriyle gelen ek yük, hızlı yineleme için can sıkıcı olabilir. Spesifikasyon güdümlü geliştirmenin yapay zekadan onlarca yıl öncesine dayandığı otomotiv sektöründe SDD, mevcut uygulamalara çok iyi uyum sağlar.

3. Uygula (Implement)

Uygulama basit aşamadır ve Bob bunun neredeyse tamamını halleder.

Bob'ın çalışmasını izlemek ve netleştirmek için araya girmek isteğe bağlıdır ve genellikle yararlıdır. Sıklığı bir sinyal olarak değerlendirin: sürekli müdahale, sorunun planda olduğu anlamına gelir ve çözüm, düzeltmeye devam etmek yerine geri gitmektir.

Tüm uygulamayı bir kenara atıp Plan moduna dönmekte tereddüt etmeyin. Kod işin ucuz kısmıdır.

4. Doğrula (Verify)

Doğrulama iki ayrı kategoriye ayrılır: otomatik doğrulama ve manuel doğrulama.

Otomatik doğrulama, Bob'ın sahip olduğu veya kancalar aracılığıyla zorunlu kılınan sensörler tarafından yürütülür. Uygulama aşamasında insan müdahalesi olmadan sık sık çalıştırılırlar. Bazı yaygın örneklerle ana kategoriler şunlardır:

Geçerlilik (Validity): Derleniyor mu, tip kontrolünden geçiyor mu, ayrıştırılabiliyor mu?
- Ölçülen: başarılı/başarısız (pass/fail), tip kapsamı
- Araçlar: tsc, mypy, cargo check, javac
Davranış (Behaviour): Doğru şeyi yapıyor mu?
- Ölçülen: geçme oranı, dal kapsamı (branch coverage)
- Birim testleri, Entegrasyon testleri, Uçtan uca testler
- Araçlar: pytest, Jest, Playwright, Stryker
Sürdürülebilirlik (Maintainability): Bu kodu saklamaya değer mi?
- Ölçülen: karmaşıklık, tekrarlama, sınır ihlalleri
- Araçlar: ESLint, Ruff, Lizard, ArchUnit
Güvenlik (Security): Bu kod güvenli mi?
- Ölçülen: önem derecesine göre bulgular, CVE'ler
- Araçlar: Semgrep, CodeQL, gitleaks, npm audit

Bunlar, Bob'ın uygulama aşamasında kendi hatalarını yakalamasını ve kaliteyi artırmasını sağlar. İyi bir test kapsamı, regresyonlara karşı temel bir korumadır: Bob'ın hiçbir şeyi bozmadığından emin olur.

Bu döngüde doğrulama, döngünün sonunda ayrı bir aşama olarak listelenir ve bu temel olarak manuel doğrulamayı ifade eder. Manuel doğrulama, değişikliği çalıştırarak ve gözlemlenen davranışı planın belirttiği davranışla karşılaştırarak başlar. Bir uyumsuzluk çoğunlukla iki nedenden birine indirgenir:

Uygulama plandan sapmıştır. Düzeltme koddadır.
Plan, oluşturmayı düşündüğünüz şeyi yansıtmıyordur. Planın iyileştirilmesi gerekir. Bu çok daha yaygındır.

Dolayısıyla manuel inceleme, planı ve uygulamayı aynı anda test eder.

Ek doğrulama CI/CD hatlarında (pipelines) gerçekleşmelidir. Bu, yazılım mühendisliğinde köklü bir uygulamadır ancak başsız (headless) kodlama ajanları kullanılarak geliştirilebilir. Bir örnek: Bob Shell üzerinden çalışan her çekme isteğindeki otomatik inceleme, insan incelemecilerin yerini almak yerine onları destekler. PR inceleme ajanının iş başındaki videosuna ve Bob Shell'i etkileşimsiz çalıştırma dokümantasyonuna bakın.

Bir ekipte çalışmak

Önceki bölümlerdeki her şey bir geliştiricinin iç döngüsünü (inner loop) açıklar. Dış döngü (outer loop), değişiklikler inceleme kuyruğuna taşındığında başlar. Artık her fark (diff) daha hızlı ve gerekçesi daha az eklenmiş olarak gelirken, incelemecinin okuyacak daha çok şeyi ve bunu okumak için daha az bağlamı vardır.

Kanıtların yapılan işle birlikte aktarılması gerekir. Nasıl yapıldığına kıyasla neden yapıldığı artık eskisinden daha önemlidir, çünkü nasıl yapıldığı artık üretilmesi pahalı olan kısım değildir.

Pratikte bu, planın değişiklikle birlikte aktarılması anlamına gelir: ekipler bunu çekme isteğine ekler veya incelemenin yanında orijinal soruna (issue) geri ekler. Mekanizma kullanılan araçlara bağlıdır.

Dış döngünün bir ekibin sürecine ne yaptığı kendi başına bir konudur ve sonraki bir yazıda ele alınacaktır.

İstem yazma (prompting) üzerine bazı düşünceler

Geçtiğimiz yıllarda, LLM'leri doğru şekilde yönlendirmeye büyük önem verildi ve bundan "prompt engineer" (istem mühendisi) gibi yepyeni bir iş kategorisi ortaya çıktı. Gelinen noktada, istemlerin büyük bir kısmı sistem çatısı (harness) içinde ele alınıyor. Özel istem tekniklerinin önemi, metodolojik bir yaklaşım lehine azaldı. İşte bazı yönergeler:

Yineleme, istem yazmayı yener. Bob istediğinizden farklı bir şey yaptığında, geri alın (rollback) ve buna neden olan mesajı yeniden yazın. İleriye doğru düzeltme yapmak yanlış cevabı, bu konudaki şikayeti ve yeniden denemeyi bağlam penceresinde bırakır.
Metodoloji, istem yazmayı yener. Bir istem tek bir oturumla sınırlıdır. Bir kural dosyası veya Bob'ın kendi kendine çalıştırabileceği bir denetim, onu üreten oturumdan sonraki her oturumda çalışmaya devam eder; bu da burada biriken tek yatırım türüdür.
Bob'a kıdemli bir mühendisin alacağı özeti verin. Belirsiz bir görev verilen yetkin bir iş arkadaşı, neyin tamamlanmış sayılacağını ve neye dokunmalarına izin verildiğini soracaktır; Bob sormayacaktır, bu yüzden her ikisini de mesaja koyun.
Ne yapılmayacağını değil, ne yapılacağını söyleyin. "Class component kullanma" demek bir seçeneği eler ve alanın geri kalanını açık bırakır, böylece Bob kalanlar arasından seçim yapar; bu da başka bir tahmindir. Bunun yerine hedefi belirtmek — hook'lu function component'lar — tek turda çözüme ulaştırır.
İkiden fazla kez verilen her talimat bir dosyaya aittir. agents.md ve beceriler (skills) bunun içindir.
Daha ayrıntılı istem talimatlarını etkili istemler yazma öğreticisinde bulabilirsiniz.

Önemli çıkarımlar

Yapı eksikliği en büyük sorundur. Keşfet → Planla → Uygula → Doğrula döngüsünü takip etmek, odaklanmış kalmana ve hedeflerine daha hızlı ve daha tutarlı bir şekilde ulaşmana yardımcı olur.
Bağlam kıt kaynaktır ve aşamalar bağlam sınırlarıdır. Keşif konuşmalarını uygulamaya taşımayın.
Plan, inceleme yapıtıdır. Bir planı incelemek, bir diff'i incelemekten hem yazar hem de incelemeci için daha iyidir.
Saklamaya değer her şey sohbetten çıkar. Planlar, kararlar ve bulgular bir dosyaya aittir. Bir dosyayı karşılaştırabilir (diff), inceleyebilir, sürümleyebilir ve başka bir ajana aktarabilirsiniz.
Doğrulama makine tarafından çalıştırılabilir olmalıdır, bu da onu sonradan keşfetmek yerine planlama sırasında tasarlamanız gerektiği anlamına gelir.

Kaynaklar ve ek okumalar

Simon Willison, Agentic engineering patterns
Birgitta Böckeler, Harness engineering

IBM Bob dokümantasyonu ve öğreticileri: