Codex ve çoklu aracılı iş akışı: kontrolü kaybetmeden aracılarla çalışın
· 6 min read · Filippo Spinella · AI, Developer Tools, Productivity, Software Engineering
Bir kodlama temsilcisi sizin için ilk kez bir hatayı düzelttiğinde, tepki neredeyse her zaman aynıdır: coşku ve şüphe karışımı. Elbette güzel. Ama sonra farka bakıp kendinize şunu soruyorsunuz: "Tamam ama tam olarak neye dokundu? Ona güvenebilir miyim? Yarın da aynı şekilde yapacak mı?".
İlginç kısmın burada başladığını düşünüyorum. Aracı bir işlev yazdığında değil, işin tamamını üstlenebilecek kapasiteye ulaştığında: veri deposunu okuyun, bir yama oluşturun, testler çalıştırın, bir PR açın, bir inceleme yorumundan sonra geri gelin. Codex tam olarak bu yönde ilerliyor: arka plan çalışması, ayrı çalışma ağaçları, entegre tarayıcı, otomasyonlar, eklentiler, bellek ve daha açık izin kontrolleri.
Önemli olan artık kimsenin kod okumadığı bir gelecek hayal etmek değil. Korkunç bir gelecek olurdu, aynı zamanda oldukça naif. Önemli olan, her şeyi yapmalarına izin vermeden çok şey yapabilen temsilcilerle nasıl çalışılacağını bulmaktır.
Alışkanlık değişikliği
Geleneksel otomatik tamamlama ile her zaman direksiyon başındaydınız. Yapay zeka bir çizgi önerdi, siz karar verdiniz. Ancak bir temsilciyle ilişki değişir: Ona bir hedef verirsiniz ve o da kendi başına birçok adım atar.
Bu güçlüdür ancak sorunu değiştirir. Soru artık sadece "model programlayabilir mi?" değil. Soru şöyle oluyor:
- Ona yeterince küçük bir dürbün verdim mi?
- sonucu nasıl kontrol edeceğinizi biliyor musunuz?
- İzole bir ortamda mı çalışıyorum?
- Son inceleme hâlâ insani ve dikkatli mi?
Sağlıklı bir iş akışı, sihirli bir değnekten çok şuna benzer:
"Acente her şeyi yapar" ifadesinden daha az romantik geliyor ama çok daha iyi çalışıyor. İnsanlarla arası iyi olan ekipler de bu şekilde çalışır: net görevler, hızlı geri bildirim, açık sorumluluk.
İyi istem neredeyse iyi bir bilettir
En tehlikeli istem belirsiz ama kendinden emin olanıdır: "fatura sayfasını düzeltin", "mimariyi geliştirin", "kimlik doğrulama modülünü temizleyin". Bunlar kulağa üretken gelen ve büyük farklar yaratan isteklerdir. Ama sonra kendinizi arkeoloji yaparken buluyorsunuz.
Yararlı bir bilgi istemi daha sıkıcıdır. Örneğin: tablonun app/(dashboard)/invoices/page.tsx'da olduğunu, sorguların src/server/invoices.ts'de olduğunu ve app/(dashboard)/reports'de zaten benzer bir model olduğunu bilerek faturalar sayfası için CSV dışa aktarımını uygulayın.
Ardından net kısıtlamalar ekleyin: veritabanı şemasını değiştirmeyin, küçük bir yardımcı program yeterliyse bağımlılıklar eklemeyin, mevcut kullanıcı arayüzü stilini koruyun. Ve doğrulamayı şu şekilde sonlandırın: npm test -- invoices ve npm run build.
Bu tür brifinglerin amacı "Yapay zekaya daha iyi açıklama yapmak" değildir. Her şeyden önce neyi devrettiğinizi size daha açık hale getirmeye hizmet eder. Eğer bunu somut olarak yazamıyorsanız, belki de görev henüz bir temsilci için hazır değildir.
İsteyerek devrettiğim üç iş
Birincisi tekrarlanan ancak doğrulanabilir bir çalışmadır: testler eklemek, çağrıları yeni bir dahili API'ye taşımak, içe aktarmaları güncellemek, kullanım dışı bileşenleri değiştirmek, TypeScript hatalarını düzeltmek. Burada acente saatlerce tasarruf edebilir ve risk kontrol edilebilir.
İkincisi keşif çalışmasıdır: "bu toplamın nerede hesaplandığını bulun", "bu testin neden hassas olduğunu bana açıklayın", "hatayı yeniden üretin ve bana hangi dosyaların etkilenmiş göründüğünü söyleyin". Hemen bir yama üretmese bile yararlı keşifler yapabilir.
Üçüncüsü ise yinelenen bakım çalışmalarıdır: küçük bağımlılık güncellemeleri, eski özellik işaretlerinin temizlenmesi, engellenen PR'lerin özeti, unutulan TODO'ların kontrol edilmesi. Gösterişli değil ama tam da birikme eğiliminde olan türden bir iş.
İnsan olarak tuttuğum üç iş
Ürün kararları insani kalır. Bir değişiklik kullanıcının ödeme yapma, verileri silme, fiyatları görme veya bir izni anlama şeklini değiştirirse sorumlu bir kişi istiyorum.
Güvenlik sınırları aynı zamanda insanların ilgisini de hak ediyor: kimlik doğrulama, roller, belirteçler, hassas veri kaydı, veritabanı geçişleri. Bir temsilci uygulamaya yardımcı olabilir ancak tek karar verici olması gerekmez.
Son olarak mimari zevk gerektiren her şeyi insani tutuyorum. Bir etmen bir yeniden düzenleme önerebilir, ancak bir soyutlamanın gerçekten gerekli olup olmadığını veya sadece var olmayan bir sorunu düzeltip düzeltmediğimizi anlamak bir iş olarak kalır.
İnceleme isteğe bağlı değildir
Bir temsilci iyi olduğunda, cazibesi CI'nın yeşiline güvenmektir. Bu anlaşılabilir bir durum. Aynı zamanda sorunların da başladığı zamandır.
Her zaman en az beş şeye bakarım:
- Yama yalnızca istenen görevi çözüyor mu?
- Hiçbir ilgisi olmayan dosyalara dokundu mu?
- Testler yeni davranışları mı yoksa sadece mutlu şansı mı kapsıyor?
- Kod yerel kalıpları takip ediyor mu?
- Hatalar projenin geri kalanında olduğu gibi ele alınıyor mu?
Bir şeyler yanlış olduğunda geri bildirimin spesifik olması gerekir. "Düzelt" tembelliktir. Daha iyisi: bu yardımcı program parseMoney dosyasını src/lib/money.ts dosyasına kopyalar; bu işlevi yeniden kullanın, EUR durumu için bir test ekleyin ve faturalandırma modülünün genel API'sini değiştirmeyin.
Temsilciler küçük, doğrulanabilir yorumlara çok daha iyi yanıt verir. İlginç bir şekilde insanlar da öyle.
Çabaya değer korkuluklar
Bir aracı dosyaları okuyabiliyor, kod yazabiliyor ve komutları yürütebiliyorsa, bunun güçlü bir süreç olarak ele alınması gerekir. Paranoyaya gerek yok, hijyene ihtiyacınız var.
Ayrı çalışma ağaçları veya dalları kullanın. Böylece farkı karşılaştırabilir, başarısız deneyleri bir kenara atabilir ve aracının işini sizin yaptığınız işle karıştırmazsınız.
İzinleri sınırlayın. rg, git diff, npm test ve npm run build gibi komutlar oldukça ücretsiz olabilir. Dağıtımlar, veritabanı geçişleri, sırlara erişim ve yıkıcı komutlar açık kalmalıdır.
İhtiyacınız olmadığında ağ erişimini azaltın. Birçok görev için resmi belgeler, paket kaydı ve belirli dahili hizmetler yeterlidir. Daha az yüzey alanı, daha az sürpriz.
Eylemleri izleyin. Bir yama incelemeye alındığında, istemleri, yürütülen komutları, geçilen testleri ve değiştirilen dosyaları yeniden oluşturabilmelisiniz. Bürokrasi yaratmak değil, bir şeyler ters giderse ne olduğunu anlayabilmek.
Ekip olarak başlamanın kolay bir yolu
Eğer ajanları küçük bir ekibe katacak olsaydım, büyük devrimler olmadan başlardım.
Kapsamı net olan sorunlar için bir agent-ready etiketi oluştururdum. Bağlam, kısıtlamalar ve doğrulama komutlarını içeren bir şablon eklerdim. İdeal olarak birkaç yüz satırın altında küçük bir PR isterim. Görünür değişiklikler için testlere veya ekran görüntülerine ihtiyacım var. Ve her şeyden önce birleşmeden bir kişiyi sorumlu tutardım.
İki hafta sonra verilere bakardım: Hangi görevler gerçekten hızlandırıldı, hangi incelemeler ağırdı, hangi istemler kafa karıştırıcıydı, kod tabanının hangi bölümleri devredilemeyecek kadar kırılgandı.
"Bugünden itibaren her şeyi menajerlerle yapacağız" yaklaşımından daha az gösterişli bir yaklaşım ama pişmanlık duymadan üçüncü haftaya geçmenizi sağlayan yaklaşım.
En insani kısmı
İşin komik yanı, temsilciler ne kadar özerk olursa, klasik beceriler de o kadar önemli hale geliyor: iyi bir bilet yazmak, küçük kesintiler yapmak, testler oluşturmak, farkları okumak, takasları iletmek. Temsilci, nasıl iyi çalışacağını zaten bilenleri hızlandırır. Aynı zamanda kötü yetki verenlerin kaosunu da artırıyor.
Yani hayır, çok aracılı iş akışlarını mühendislik yapmayı bırakmanın kısayolu olarak görmüyorum. Bunları, önemli parçalara daha fazla enerji aktarmanın bir yolu olarak görüyorum: Ne inşa edileceğine karar vermek, çalıştığından emin olmak, sistemi anlaşılır tutmak.
Temsilciler harika asenkron iş arkadaşları yaratabilirler. Ancak asenkron bir meslektaşın faydalı olabilmesi için bağlama, sınırlara ve incelemeye ihtiyacı vardır. Tıpkı diğer herkes gibi.