Çoğu kod işi hâlâ bir grup sohbetinde tek bir cümleyle başlıyor. "CSV dışa aktarımı son satırı düşürüyor." "Demo öncesi SSO ekleyebilir miyiz?" "Prod, ödeme sırasında yine 500 veriyor." Biri baş parmak yukarı emojisiyle tepki veriyor, belki bir kodlama ajanı işaret ediliyor ve üç gün sonra kimse bunun yayına girip girmediğini, kimin incelediğini ya da hangi commit'in bunu düzelttiğini söyleyemiyor. Mesaj akıp gidiyor. İş, kulaktan kulağa anlatılan bir efsaneye dönüşüyor.
Buradaki boşluk bir disiplin sorunu değil, yapı sorunu. Bir sohbet mesajının sahibi, durumu, kabul testi ve onu çözen diff'e bir bağlantısı yok. Bir kodlama ajanını o mesaja yönlendirdiğinizde, izlenemeyen bir iş yaratmış olursunuz. Birden fazla ajan çalıştırmaya başladığınızda iş daha da kötüleşir, çünkü bu sefer hangi ajanın ona dokunduğunu da söyleyemezsiniz.
Bu makale, bir sohbet mesajını izlenebilir bir kod görevine dönüştürmeyi ele alıyor: kendi başına kurulan bir yapının size ne kazandırdığını, nerede ölçeklenmeyi bıraktığını ve paylaşılan bir görev katmanının ne eklediğini. Sharkly, izlenebilir versiyon için çalışma alanıdır; çünkü kodlama ajanlarınızın üzerinde konumlanır ve hedefi, çalıştırmayı, engelleri, diff'i ve insan incelemesini tek bir kayıtta tutar. Kodlama ajanlarınız zaten var. İş, onların çalışmalarını bir ekibin takip edebileceği bir şeye dönüştürmek.
Sohbet neden kod görevlerinin öldüğü yer
Bir grup sohbeti, konuşma hızı için optimize edilmiştir; bu da bir kod görevinin ihtiyacının tam tersidir. Gerçek bir görev belirtilmiş bir hedef, bir sahip, kabul kriterleri, sorgulanabilir bir durum ve onu kapatan değişikliğe bir geri bağlantı taşır. Bir sohbet mesajı bunların hiçbirini taşımaz. Bir zaman damgası ve bir tepki taşır.
Başarısızlık modu nettir. Bir talep gelir, başlık altında gayriresmî olarak kabul edilir ve başlık akmaya devam eder. İki gün sonra biri "dışa aktarma hatasını hiç düzelttik mi?" diye sorar ve cevap Slack araması, tahmin yürütme ve aynı ifadenin dokuz kez geçtiği bir kanalda aşağı kaydırma gerektirir. Mesajı bulsanız bile, düzeltmenin birleştirilip birleştirilmediğini söylemez. Konuşma ve kod, birbirlerinin adını hiç öğrenmemiş ayrı sistemlerde yaşar.
O mesaja özerk bir kodlama ajanı yönlendirin, iz daha da kısalır. Ajan bir Slack satırını okur, birinin dizüstü bilgisayarındaki bir terminalde çalışır, dosyaları düzenler ve talebi yutan aynı hızlı akan başlığa rapor verir. Şimdi kimsenin kaydetmediği bir yürütme günlüğünüz, kimsenin bağlamadığı bir değişikliğiniz ve kimsenin kaydetmediği bir kararınız var.
Kendi başına kurulan akış ve nerede ölçeklenmeyi bıraktığı
Başlamak için bir ürüne ihtiyacınız yok. İşe yarayan bir kendin-yap akışı: sohbet mesajını kopyalayın, kodlama ajanınıza istem olarak yapıştırın, ana çalışma kopyanızla çakışmaması için izole bir Git worktree'de çalışmasına izin verin ve Closes #123 satırıyla bir takip sorununa geri bağlanan bir pull request açın. Bu gerçek bir izlenebilirliktir ve aynı anda tek bir talebi ele alan tek bir geliştirici için genellikle yeterlidir.
İşte dürüst karar ikilisi. Tek bir kişiyseniz, tek bir ajan çalıştırıyorsanız, bir sonrakine geçmeden önce bir görevi kapatıyorsanız, kopyala-yapıştır-worktree döngüsü işe yarar ve ona araç eklememelisiniz. Paylaşılan bir sistemin yükü, getirisinden daha fazlasına mal olur.
Bu yapı, iki şey aynı anda doğru olduğu anda ölçeklenmeyi bırakır: iki ajan çalışıyor ya da iki kişi iş yönlendiriyor ya da iki depo devrede. O zaman manuel akışta delikler oluşmaya başlar:
| Ne bozuluyor | Kendin-yap döngüsü neden bunu karşılayamıyor |
|---|---|
| "Dışa aktarma hatası hangi ajanda?" | Atama kafanızda yaşıyordu, bir kayıtta değil |
| "Bu tamamlandı mı yoksa hâlâ çalışıyor mu?" | Durum, kapattığınız bir terminal, sorgulanabilir bir alan değil |
| "Kimlik doğrulama değişikliğini kim onayladı?" | Onay bir baş parmak yukarı emojisiydi, şimdi akıp gitti |
| "O Slack talebinin diff'i nerede?" | PR bir soruna bağlanıyor, ama sorun hiçbir zaman talebe bağlanmıyor |
| "Ajan gerçekte neyi değiştirdi?" | Çalıştırma günlüğü sona eren bir oturumda yaşıyordu |
Her delik, görevin yeniden izlenemez hâle geldiği bir yerdir. Bunları daha fazla sorun, adlandırma kuralı ve disiplinle elle yamayabilirsiniz. Bu, işe yaramadığı ana kadar işe yarar ve sessizce başarısız olur; ki bu bir sürecin başarısız olmasının en kötü yoludur.
Görev paylaşıldığında "izlenebilir" ne anlama gelir
İzlenebilirlik bir his değildir. Bir iş parçasıyla ilgili her sorunun, tek bir yerde yaşayan ve iş başladığında çevrimiçi olan kişilerden daha uzun ömürlü olan bir cevabı vardır. İzlenebilir bir görev, bağlamı, atamayı, ilerlemeyi, engelleri, sonuçları ve insan incelemesini talepten yayına kadar görünür tutar.
Sharkly bunu, sistemdeki ana iş birimi olan bir Task (Görev) olarak modeller. Bir Task ne bir sohbet mesajıdır ne de bir terminal oturumu. Üzerinde işlem yapmaya karar verdiğinizde bir sohbet mesajının dönüştüğü paylaşılan kayıttır. Hedef, açıklamaya girer. Bir Ajan ya da bir kişi Atanan olur. Ajanın yürütmesi, engelleri, sonuçları ve devamındaki tartışma, özel bir terminalde kaybolmak yerine Task zaman çizelgesine geri döner. Değişiklik yayına girdiğinde, pull request ID ile bağlanır, böylece talep ve diff nihayet birbirlerinin adını öğrenir.
Bir sınır önemlidir, çünkü bir okuyucu yanlış bir şey varsayabilir. Sharkly, Claude Code, Codex ya da diğer kodlama ajanlarınızın yerine geçmez. O araçlar yürütmeyi gerçekleştirir. Sharkly onların etrafına paylaşılan görev, bağlam ve inceleme katmanını ekler. Kodu yine Ajan yazar. Sharkly, işi atanabilir ve izlenebilir kılar.
Sharkly ile bir sohbet mesajını izlenebilir bir göreve dönüştürmek
İş akışı kafanızda tutabileceğiniz kadar kısadır. Gerçek bir mesajla başlayın, diyelim CSV dışa aktarma hatası, ve onu kanaldan dışarı taşıyın:
- Mesajı bir Task olarak yakalayın. Talebi hedefi olarak alan bir Task oluşturun. Sohbetiniz Slack'te yaşıyorsa, kodlama ajanları için bir Slack botu, başlıktan çıkmadan bahsi bir Task'a dönüştürür.
- Bir Ajanın yürütebileceği şekle sokun. Tek satırlık bir hata raporu, yürütülebilir bir şartname değildir. Yeniden üretimi, beklenen davranışı ve bir kabul testini ekleyin. AI ajan görev yönetimi ile aynı disiplin: bir Ajanın kapatabileceği bir Task, bir Ajanın üzerinde işlem yapabileceği bir açıklama gerektirir.
- Atayın ve Ajanın çalışmasına izin verin. Ajan Task'ı üstlenir, paralel çalışmanın çakışmaması için izole bir worktree'de çalışır ve ilerlemesini Task'a akıtır. İzlediğiniz şey bir kayıttır, bir terminal değil.
- İnceleyin ve kabul edin. Ajan değişiklik özetini, test sonuçlarını ve bilinen sınırlamaları ekler. Bir kişi kabul eder, değişiklik talep eder ya da birleştirme kararını verir.
Bu son adım, açıkça belirtilmeye değer sözleşmedir: Ajanlar araştırır, yürütür, test eder ve raporlar. İnsanlar yönü belirler, yetki verir ve sonucu kabul eder. Otomasyon, ekip muhakemesinin gerektiği yerde durur. İzlenebilir bir görev bu devri mümkün kılar, çünkü değişikliği inceleyen insan talepten diff'e kadar tüm yolu görür. İş bittiğinde, ajanın neyi tamamladığını hafızadan yeniden kurgulamadan takip edebilirsiniz. Bu, resmî bir bilet yerine bir sohbet kalıntısından başlayan tam bir gereksinimden koda iş akışıyla aynı omurgadır.
Bunun bir versiyonunu sorunlar ve worktree'lerle elle kurabilirsiniz ya da hacim tırmandığında izin korunması için iş akışını yönetmek üzere Sharkly'yi kullanabilirsiniz.
Bugün uygulayabileceğiniz kontrol listesi
Bunu mevcut kurulumunuza karşı çalıştırın. İşaretlenmemiş her kutu, sohbetten doğan bir görevin izlenemez hâle gelebileceği bir yerdir:
- [ ] İşleme alınan her sohbet talebi, bir tepki emojisi değil, bir sahibi olan bir Task'a dönüşür.
- [ ] Her Task, bir Ajanın yürütebileceği bir açıklamaya sahiptir: yeniden üretim, beklenen davranış, kabul testi.
- [ ] Çalışan her Ajan izole bir worktree'de çalışır, böylece iki görev asla aynı dosyalara dokunmaz.
- [ ] Ajanın çalıştırma günlüğü, engelleri ve sonuçları, kapanan bir terminale değil, Task'a döner.
- [ ] Pull request, ID ile Task'a bağlanır, böylece talep ve diff bir tık uzaklıktadır.
- [ ] Bir insan sonucu kabul ya da reddeder ve bu karar Task'a kaydedilir.
- [ ] "Bu bitti mi, kim yaptı ve diff nerede?" sorusunu sohbeti aramadan cevaplayabilirsiniz.
Aynı anda tek bir talebi ele alırken, manuel döngü bunların çoğunu kendi başına geçer. Bir ekipte birkaç ajan çalıştırırken Sharkly, görevlerini ve sonuçlarını yöneteceğiniz tek bir yer sunar. Sharkly'yi indirin ve tüm kanalı ona emanet etmeden önce gerçek bir sohbet talebini bir Task'a taşıyın.
SSS
Sohbetten doğan görevleri izlenebilir kılmak için Sharkly'ye ihtiyacım var mı? Hayır. Tek bir ajan çalıştıran tek bir geliştirici, bir worktree ve bir soruna bağlanan bir pull request ile gerçek izlenebilirlik elde eder. AI ajan gelen kutusu deseni, birden fazla ajanınız veya kişiniz olduğunda ve manuel bağlantılar aksamaya başladığında kendini amorti eder.
Bir sohbet mesajını bir kodlama ajanı için yürütmeyi zorlaştıran nedir? Genellikle bir yeniden üretim, beklenen bir sonuç ve bir kabul testinden yoksundur. "Dışa aktarma bozuk" ifadesini "CSV dışa aktarımı son satırı düşürüyor; beklenen N satır, elde edilen N-1; sayı eşleştiğinde düzeliyor" hâline getirin. Artık Ajanın karşısında kapatacağı bir şey var.
Bu normal bir bilet sisteminden nasıl farklı? Bir bilet, bir insanın yapacağı işi takip eder. İzlenebilir bir kod görevi ayrıca Ajanın yürütme günlüğünü, izole çalıştırmasını ve bağlantılı diff'i taşır, böylece kayıt hem kararı hem de değişikliği kapsar. Kişinin döngüde nerede kaldığı için human-in-the-loop kodlama ajanları yazısına bakın.
Sharkly Slack kanalımı doğrudan okuyabilir mi? Bir bahsin bir Task'a dönüşmesi için bir Sharkly Ajanını Slack'e bağlarsınız. Konuşma Slack'te kalır; izlenebilir iş kaydı Sharkly'de yaşar.
