Kod olarak Görevler: Proje Taleplerinin Yapay Zeka Ajanları için Git'te Markdown Olarak Saklanması

typemill.net'te yayınlanan ve Hacker News ana sayfasına çıkan bir makale, "Kod olarak Görevler" (Tasks as Code) adını verdiği bir uygulamayı savunuyor: geliştirme taleplerinin (ticket) Markdown dosyaları olarak, kodun hemen yanında Git sürüm kontrolü altında saklanması. Böylece yapay zeka kodlama ajanları gereksinimleri okuyabiliyor, işi planlayabiliyor ve sonuçları kaydedebiliyor; Jira'dan hiçbir şeyin dışa aktarılmasına gerek kalmıyor.

Docs as Code'dan Tasks as Code'a

Makale, ajanların gerçekte nasıl çalıştığından yola çıkıyor: repository onlar için gerçeğin kaynağı, ancak çoğu ekip gereksinimleri hâlâ Jira veya Redmine gibi harici araçlarda takip ediyor. Dokümantasyon bu uçurumu çoktan aştı. Docs as Code pratiği, dokümanları özel yazılımlardan repository içindeki Markdown klasörlerine taşıdı; burada bir agent dokümanları okuyabiliyor, kodu değiştirebiliyor ve dokümantasyonu tek geçişte güncelleyebiliyor.

Yazar aynı mantığı taleplere uyguluyor. Markdown olarak saklanan bir görev, ajanın doğrudan tükettiği bir şeye dönüşüyor: gereksinimi okuyor, ona göre plan yapıyor ve sonuçlarını aynı dosyaya geri yazıyor; Git de görevin geçmişini yazılımın geçmişiyle birlikte sürümlüyor.

Fikir, Spec-Driven Development ile kesişiyor; bu yaklaşımda amaçlanan davranış, bir ajan uygulamadan önce Markdown özellik dosyalarında tanımlanıyor ve genellikle Spec Kit gibi araçlarla destekleniyor. Yazarın çıkış noktası bilinçli olarak daha yalın: görev dosyasının kendisini özellik tanımı olarak görmek; bu, Git ve bir agent dışında hiçbir şey gerektirmiyor. Bir dosyanın ne kadar ayrıntıya ihtiyacı olduğu işe bağlı — küçük bir bakım düzeltmesi bir iki satır sürebilirken, karmaşık bir özellik kabul kriterleri, teknik kararlar, bağımlılıklar ve test gereksinimleri istiyor.

İnsan kapılı beş adımlı bir iş akışı

Önerilen döngü, bir geliştiriciyi sabit bir noktada sürecin içinde tutuyor:

1. Görevi kısa bir Markdown dosyasında tanımlayın.
2. Agent dosyayı okur ve ilgili kodu ile dokümantasyonu inceler.
3. Agent, yapmayı düşündüğü değişiklikleri de içeren bir uygulama planını dosyaya yazar.
4. Bir geliştirici planı gözden geçirir ve onaylar ya da düzeltir.
5. Agent değişikliği uygular, gerektiğinde dokümantasyonu günceller ve görev dosyasına bir uygulama raporu ekler.

Tanım, plan ve rapor tek dosyada kaldığı için gözden geçiren kişi isteneni, önerileni ve gerçekte yapılanı karşılaştırabiliyor. Onay adımı kontrol mekanizması: agent asla gereksinimden uygulamaya doğrudan geçmiyor.

Üç repository, tek çalışma alanı

Yazarın kendi kurulumu içeriği üç Git repository'si arasında bölüyor — kod, dokümantasyon ve görevler. Bu ayrım bilinçli: dokümantasyon herkese açık olabilirken, görevler bitmemiş güvenlik düzeltmeleri, iç planlama veya duyurulmamış özellikler gibi hassas içerikler barındırabiliyor; ayrı repository'ler ise bağımsız erişim kontrolü sağlıyor.

Yerelde dokümantasyon ve görev repository'leri, kod repository'si içindeki klasörlere klonlanıyor ve .gitignore ile hariç tutuluyor; böylece her biri kendi geçmişini koruyor ve bağımsız olarak push edilebiliyor. Claude Code veya OpenCode gibi yerel bir asistan daha sonra her şeyi tek yerde görüyor. Bir commit'te görev dosyasının adına atıf yapmak, uygulamayı gereksinimine bağlıyor; görevleri sürüm klasörlerinde gruplandırmak ise bir agent'ın tamamlanmış görevlerden ve Git geçmişinden changelog ve sürüm notları hazırlayabilmesini sağlıyor.

Git üzerine bir tarayıcı katmanı

Makaleye göre iş akışını yürütmek için Git ve bir agent yeterli; ancak tarayıcı arayüzü terminalde yaşamayan kişilere hizmet edebiliyor. Yazar, Git repository'leriyle senkronize olan düz dosya tabanlı bir CMS olan Typemill'i kullanıyor; böylece ürün sahipleri ve teknik yazarlar komut satırına dokunmadan görevlere ve dokümantasyona göz atıp düzenleyebiliyor. Aynı dosyalara üç yoldan ulaşılıyor — geliştiriciler ve ajanlar için IDE, repository düzeyinde inceleme için GitHub, içerik çalışması için tarayıcı — while geçmişten ve senkronizasyondan Git sorumlu olmaya devam ediyor. Temel ilke şu: arayüz bir kolaylık katmanıdır; dosyalar taşınabilir kalır ve diğer araçlara açıktır.

Neden önemli

Kodlama ajanları birincil uygulayıcılar haline gelirse, okuyamadıkları bir sistemde gereksinimleri tutmak bir darboğaza dönüşür. Talepleri repository'ye taşımak, ajanlara ve insan gözden geçirenlere tek, sürümlü bir gerçeğin kaynağı verir; açık onay adımı da neyin yayınlandığına dair gözetimi korur. Bu değişim, makalenin açık bıraktığı bir soruyu da gündeme getiriyor: işlerin çoğunu ajanlar yaptığında geleneksel talep sistemlerinin hangi özellikleri — atamalar, yorumlar, kanban panoları, sprintler — hâlâ önemli. Yazarın sıradaki çözümde arayacağı özellikler ise şunlar: Git tabanlı saklama, tek yerde dokümantasyon ve görevler, düz Markdown dosyaları, kendi sunucunuzda barındırma ve tek bir servise kilitlenmek yerine sağlayıcıdan bağımsız yapay zeka entegrasyonu.