Kwame Boateng tarafından
Yapay zekâ destekli kodlama, genellikle eşli programlamanın daha hızlı bir versiyonu olarak tanımlanır. Bu karşılaştırma artık yetersiz kalıyor. Bir ajan bir depoyu inceleyebildiğinde, birden fazla dosyayı değiştirebildiğinde, araçları çalıştırabildiğinde, bir önizleme oluşturabildiğinde ve bir pull request açabildiğinde, temel iş birliği sorunu artık yalnızca “Kod yazabilir mi?” değildir. Asıl soru şudur: “İnsanlar ne olduğunu görebilir, inceleyebilir, onaylayabilir ve daha sonra yeniden oluşturabilir mi?”
Bu nedenle, ajan destekli yazılım ekiplerindeki en önemli tasarım değişikliği, özel istemlerden görünür çalışma alanlarına geçiş olabilir. Örneğin Slack Code; proje kanallarını kodlama ajanları, kod farkı denetimi, canlı HTML önizlemeleri, geri bildirim ve onay iş akışları, otomatik arşivleme ve denetim günlükleriyle birleştiren bir yapı olarak tanımlanıyor. GitHub’ın Copilot uygulaması da projeler genelindeki issue’ları ve pull request’leri düzenlemek için “Çalışmalarım” bölmesini ekledi. Bu özellikler pratik bir ilkeye işaret ediyor: Bir ajanın çalışması, opak bir yanıttan çok, kontrollü bir üretim sürecinden geçen bir değişiklik kümesine benzemeli.
Sohbet, çalışma kaydı değildir
Bir ajanla yapılan konuşma bir fikri keşfetmek için yararlı olabilir, ancak kayıt sistemi olarak zayıftır. Önemli ayrıntılar uzun bir ileti dizisinin içinde gömülü kalabilir: hangi dosyaların değiştiği, hangi komutların çalıştırıldığı, ajanın hangi varsayımlarda bulunduğu, bir inceleyicinin neyi reddettiği ve nihai sonucun ilk öneriden farklı olup olmadığı.
Kalıcı bir çalışma alanı bu ayrıntıları incelenebilir kılar. İsteği belirli bir depoya veya projeye bağlamalı, ajanın planını korumalı, araç işlemlerini ve dosya değişikliklerini göstermeli, testlere ve önizlemelere bağlantı vermeli ve sonucu kimin onayladığını kaydetmelidir. Arayüzün kendisi değişebilir—bir issue takip sistemi, pull request, iş birliği kanalı veya ajan konsolu olabilir—ancak bilgiler oturum sona erdikten sonra da varlığını sürdürmelidir.
Bu, yalnızca uyumluluk açısından değil, sıradan mühendislik nedenleriyle de önemlidir. İki hafta sonra bir hata ortaya çıkarsa ekibin yalnızca nihai farktan fazlasını bilmesi gerekir. İlk gereksinimi, oluşturulan planı, test kanıtlarını, inceleyicinin yorumlarını ve bir insanın riskli bir ödünleşimi açıkça kabul edip etmediğini bilmesi gerekebilir. Kalıcı bir kayıt bu araştırmayı kısaltır.
Görünür çalışmanın beş katmanı
Kodlama ajanlarını benimseyen ekipler, her değişikliği küçük ve incelenebilir bir vaka dosyası olarak ele alabilir. Özellikle beş katman yararlıdır:
- Niyet: issue, kabul kriterleri, kısıtlamalar ve talep edilen kapsam.
- Plan: ajanın dosyaları düzenlemeden önce önerdiği yaklaşım. Önemsiz olmayan bir görev için bu, süs değil, bir onay kontrol noktasıdır.
- Fark: tam eklemeler, silmeler, bağımlılık değişiklikleri, yapılandırma düzenlemeleri ve oluşturulan varlıklar.
- Kanıt: test sonuçları, lint çıktısı, güvenlik kontrolleri, ekran görüntüleri ve uygun olduğunda canlı veya dağıtılabilir bir önizleme.
- Karar kaydı: inceleyici yorumları, talep edilen değişiklikler, onay, ret, geri alma veya takip çalışması.
Amaç, her değişikliği ağır işleyen bir komiteden geçirmek değildir. Bir yazım hatası ile ödeme akışındaki bir değişiklik aynı kontrollere tabi olmamalıdır. Amaç, inceleme düzeyini olası etkiyle orantılı hâle getirmektir.
Onaylar eylemlere bağlanmalıdır
“Döngüde insan” ifadesi, yararlı bir kontrol olacak kadar açık değildir. Bir kişi ortaya çıkan farkı görmeden bir planı onaylayabilir veya ajanın bir dağıtım dosyasını da değiştirdiğini fark etmeden bir kod değişikliğini onaylayabilir. Daha iyi iş akışları, onayın neye izin verdiğini açıkça belirtir.
Örneğin bir ekip, ajanın bir depoyu okumasına ve yerel testleri otomatik olarak çalıştırmasına izin verebilir; belirlenmiş bir dalın dışına yazmadan önce onay isteyebilir ve birleştirme veya dağıtımdan önce ayrı bir onay gerektirebilir. Bir ajan veritabanı geçişi önerebilir, ancak bunu üretim ortamında yürütmesi yasaklanabilir. BAE’nin ajanların hangi görevleri tamamlayabileceğini, hangilerini ise yalnızca önerebileceğini sınıflandırmaya yönelik önerilen yaklaşımı da bu daha geniş modele yansıyor: özerklik küresel olarak varsayılmamalı, göreve göre atanmalıdır.
Onayların kapsamı ve süresi de olmalıdır. “Açılış sayfası metnini güncelle” onayı, sessizce yeni bir analiz paketine izin vermemelidir. Dün onaylanan bir plan, bugün maddi ölçüde değişmiş bir farkı otomatik olarak kapsamamalıdır. Arayüz bu sınırları görünür kılmalıdır.
Önizlemeler incelemeyi gözden geçirmeye dönüştürür
İnsanlar sonucu kaynak dosyalardan çıkarsamak yerine inceleyebildiğinde kod incelemesi genellikle daha kolaydır. Canlı bir HTML önizlemesi; bozuk aralıkları, eksik durumları, erişilemeyen kontrolleri veya bir inceleyicinin metinsel farkta gözden kaçırabileceği, gezinmedeki istenmeyen bir değişikliği ortaya çıkarabilir.
Önizlemeler doğruluğun kanıtı değildir. Testlerin ve kaynak kodu incelemesinin yerine geçmemeli, onların yanında yer almalıdır. Ancak tartışma için ortak bir nesne oluştururlar: Bir inceleyici belirli bir ekrana, duruma veya etkileşime işaret edebilir ve geri bildirimini önerilen değişikliğe bağlı olarak bırakabilir.
Bu, uzman olmayan kişilerin incelemeye dâhil olduğu durumlarda özellikle değerlidir. Bir ürün yöneticisi bir çerçeve değişikliğini değerlendiremeyebilir, ancak iş akışının gereksinimle örtüştüğünü doğrulamak için doğru kişi olabilir. Bir tasarımcı görsel bir gerilemeyi doğrulayabilir. Bir güvenlik uzmanı izinlere ve veri işleme süreçlerine odaklanabilir. Ajan destekli çalışma alanı her soruyu, yanıtlamaya en uygun kişiye yönlendirebilir.
Farkların yalnızca renge değil, bağlama da ihtiyacı vardır
Alışılmış kırmızı-yeşil fark görünümü hâlâ vazgeçilmezdir, ancak ajanlar tarafından oluşturulan değişiklikler bir inceleyiciyi bunaltacak kadar kapsamlı olabilir. Ekipler ajanlardan commit’leri veya değişiklik gruplarını dar tutmalarını, kayda değer her dosyanın neden değiştiğini açıklamalarını ve oluşturulan veya tedarikçi dosyalarını ayrı olarak belirtmelerini istemelidir.
Yararlı inceleme soruları şunlardır:
- Kullanıcının gördüğü davranış nasıl değişti?
- Yalnızca uygulamayı desteklemek amacıyla hangi dosyalar değiştirildi?
- Ajan, mevcut davranışla ilgili hangi varsayımlarda bulundu?
- Hangi testler eklendi, değiştirildi veya çalıştırılmadı?
- Bu değişiklik izinleri, veri saklamayı, faturalandırmayı veya harici API'leri etkileyebilir mi?
Bu sorular, incelemeyi belirsiz bir “şuna bir göz at” isteğinden tekrarlanabilir bir değerlendirmeye dönüştürür. Ayrıca yaygın bir hata biçiminin ortaya çıkarılmasına yardımcı olurlar: makul görünen bir özelliğe eksik bir test güncellemesinin veya yanlışlıkla yapılmış bir yapılandırma değişikliğinin eşlik etmesi.
Önem taşıyan akıl yürütmeyi arşivleyin
Her model görüşmesinin her bir parçasını saklamak otomatik olarak yararlı değildir. Uzun geçmişleri depolamak pahalı, aramak ise zor olabilir; bağlam sıkıştırma araştırmaları da özetlerin önemli bilgileri kaybedebileceği konusunda uyarır. Bu nedenle pratik bir denetim izi, her şeyi ayrım gözetmeksizin kaydetmek yerine karar açısından önemli çıktıları korumalıdır.
En azından isteği, onaylanan planı, son diff'i, araç ve test sonuçlarını, önizleme veya dağıtım referansını, inceleyenlerin kararlarını ve verilen istisnaları saklayın. Bir ajan harici kaynaklar kullandıysa veya dahili belgeleri aldıysa, ilgili kaynak referanslarını ve değişikliği etkiledikleri noktayı kaydedin. Yüksek riskli işler için etkileşimin ve yürütme günlüğünün tamamını saklamak gerekçelendirilebilir.
Riskin yüksek olduğu durumlarda kayıtları kurcalanmaya karşı belirgin hâle getirin ve bir kriz yaşanmadan önce saklama kurallarını tanımlayın. Bir kanal arşivlendiğinde ortadan kaybolan ya da değiştirilmiş bir sonucu orijinalinden ayırt edemeyen bir denetim izi, ciddi bir soruşturmayı destekleyemez.
Yazılım kariyerleri açısından bunun değiştiği noktalar
Ortaya çıkan beceri yalnızca daha iyi istemler yazmak değildir. Başka bir kişinin inceleyip güvenebileceği işler tasarlamaktır. Geliştiricilerin kabul kriterlerini belirleme, görevleri parçalara ayırma, diff'leri geniş ölçekte inceleme, anlamlı testler oluşturma ve bir ajanın ne zaman durup soru sorması gerektiğine karar verme konularında rahat olmaları gerekecek.
Ürün ve tasarım profesyonellerinin önizlemeleri incelemede ve amacı netleştirmede daha büyük bir rolü olacak. QA mühendisleri onay aşamalarını ve hata durumlarını tanımlamaya yardımcı olabilir. Mühendislik yöneticilerinin görünmez riskler almayı ödüllendirmeden iş hacmini ölçmesi gerekecek. Teknik yazarlar ve operasyon uzmanları, kararları, istisnaları ve çalışma kılavuzlarını kalıcı hâle getirerek katkıda bulunabilir.
Yararlı bir egzersiz, sıradan bir özelliği ele alıp kanıt zincirini haritalamaktır: istek, plan, dal, diff, testler, önizleme, onay, yayın ve geri alma. Ardından gelecekteki bir ekip arkadaşının nerede tahminde bulunmak zorunda kalacağını sorun. Her tahmin, daha iyi bir çalışma alanı, daha net bir izin veya daha kalıcı bir kayıt için adaydır.
Basit bir çalışma kuralı
Ajanların görünür ve geri alınabilir bir alan içinde hızla ilerlemesine izin verin. Onlara tanımlı bir çalışma alanı sağlayın, hassas eylemleri kısıtlayın, önemli sınır noktalarında onay isteyin, kanıtları değişikliğe ekleyin ve nihai kararı koruyun. Amaç, otomasyonu manuel kodlamaya benzeyene kadar yavaşlatmak değildir. Amaç, hızı hesap verebilirlikle uyumlu hâle getirmektir.
Ajan destekli geliştirmede en iyi işbirlikçi, tek başına en çok kodu üreten sistem değildir. Çalışmaları anlaşılabilen, sorgulanabilen, onaylanabilen, geri alınabilen ve bunlardan öğrenilebilen sistemdir.
