Bir özellik yayına alındıktan altı ay sonra bir depoyu açtığınızda pek çok şeyi yeniden kurabilirsiniz. Mimarinin izini sürebilir, şemayı inceleyebilir, testleri okuyabilir ve tam olarak hangi satırların değiştiğini görebilirsiniz.
Ama genellikle yeniden kuramayacağınız şey, o satırları gerekli kılan konuşmadır.
Kod size bir doğrulama kuralının, bir müşterinin hatalı dışa aktarımlar göndermesi nedeniyle var olduğunu söylemez. Garip görünen bir yeniden deneme politikasının, aşağı akıştaki bir sistemde yinelenen işlemleri önlediğini açıklamaz. Daha temiz arayüzün bir erişilebilirlik testinden sonra reddedildiğini ya da bir servis sınırının mühendislik tercihinden değil sözleşmesel bir kısıttan kaynaklandığını göstermez.
Git, kod geçmişini korumakta mükemmeldir. Niyeti ise ancak bir ekip bunu bilinçli olarak yazıya döküp uygulamayla bağlantılı tuttuğunda korur.
Bu boşluk her zaman yazılım mühendisliğinin bir parçası oldu. Yapay zekâ kodlama araçları bunu daha görünür hâle getiriyor. Bir sistem depodaki her dosyayı okuyabilir, her sembolü takip edebilir ve teknik olarak ikna edici bir yama üretebilir; ama yine de yanlış problemi çözüyor olabilir.
Sorun kodun yanıltıcı olması değil. Kod daha dar bir soruya yanıt veriyor.
Mühendislik gerçeğinin beş katmanı
Anlamlı yazılım değişikliklerinin çoğu, beş farklı kanıt katmanına dayanır.
- Niyet — Kullanıcı, müşteri veya işletme hangi sonucu istiyor? Bu, bir spesifikasyonda, kayıtta, destek görüşmesinde veya toplantı notunda yer alabilir.
- Kısıtlar — Ne bozulmamalı? Uyumluluk taahhütleri, güvenlik sınırları, düzenlemeler, sözleşmeler, bütçeler ve son tarihler çoğu zaman deponun dışında bulunur.
- Uygulama — Sistem bugün nasıl çalışıyor? Kod, testler, şemalar, bağımlılıklar ve dağıtım yapılandırması bu katmanı sağlar.
- Çalışma zamanı kanıtı — Gerçek sistemde neler oluyor? Günlükler, izler, metrikler, üretim verileri ve olay raporları, kodda makul görünen varsayımlarla çelişebilir.
- Karar geçmişi — Mevcut yaklaşım neden seçildi? Pull request'ler, tasarım tartışmaları, reddedilen alternatifler ve önceki olaylar bunun yanıtını taşır.
Depo en güçlü olduğu alanı üçüncü katmanda bulur. Diğerlerinin bazı parçalarını içerir, ama onları bütünüyle temsil etmeye nadiren yeter.
Bu önemlidir çünkü yazılım hataları çoğu zaman katmanlar arasındaki sınırlarda ortaya çıkar. Uygulama, güncelliğini yitirmiş bir spesifikasyonla eşleşir. Düzeltme kaydı karşılar ama operasyonel bir kısıtı ihlal eder. Testler geçer çünkü dünkü varsayımları kodlarlar. Kod kendi içinde tutarlıdır ama üretim verileri kimsenin belgelemediği bir örüntüyü izler.
Yerel olarak doğru bir yama yine de yanlış değişiklik olabilir.
Deponun tek başına yanıtlayamayacağı sorular
Bir kullanıcının bir belgeyi düzenlediğini, ardından güncellenmiş cümleyi aradığını ama sonuçlarda eski sürümü gördüğünü düşünün. “Aramayı hemen güncelleyin” kulağa net bir istek gibi gelir. Depo, nereden başlanabileceğine dair birkaç olası noktayı gösterir, ancak doğru çözümü kendi başına tanımlayamaz.
| Soru | Muhtemel kaynak |
|---|---|
| Belgenin hangi sürümü esas alınmalı? | Kaynak belge ve revizyon geçmişi |
| Eski metin nerede kalıyor? | Senkronizasyon günlükleri, çıkarım çıktısı, arama indeksi veya önbellek |
| Bu ürün için “hemen” ne anlama geliyor? | Ürün vaadi veya hizmet hedefi |
| Belgenin izinleri, içeriğiyle birlikte değişti mi? | Kaynak izinleri ve denetim geçmişi |
| Bayat sonuç tek bir kullanıcı, kaynak veya bölgeyle mi sınırlı? | İstek izleri ve üretim metrikleri |
Arama kodu, sonuçların nasıl döndürüldüğünü açıklayabilir. Ancak asıl sorunun senkronizasyon gecikmesi, bayat çıkarım, önbellek geçersizleştirme, izin yayılımı ya da ürünün hiç tanımlamadığı bir beklenti olup olmadığını söyleyemez.
Bu ayrım, olgun sistemlerde daha da önemli hale gelir. Eskimiş görünen bir alan hâlâ eski bir istemciyi destekliyor olabilir. Yineleniyor gibi görünen bir servis, farklı izin gereksinimlerine sahip verileri ayırıyor olabilir. Gereğinden fazla gibi görünen bir kontrol, mevcut ekibin hiç görmediği bir üretim olayının kod düzeyindeki tek izi olabilir.
Karmaşıklığı silmek değerlidir. Ama karmaşıklık gibi görünen geçmişi silmek pahalıya mal olur.
Daha fazla bağlam yine de yanlış cevabı üretebilir
Bariz çözüm, yapay zekâya daha fazla malzeme vermektir: tüm depo, her bilet, her belge, her mesaj ve her günlük.
Bu, anlayış değil erişim sağlar.
Kaynaklar eski, çelişkili, spekülatif olabilir ya da farklı kitleler için yazılmış olabilir. Bir beyin fırtınası, onaylanmış bir spesifikasyonun önüne geçmemelidir. Altı aylık bir gereksinim, dünkü ürün kararını sessizce geçersiz kılmamalıdır. Bir üretim günlüğü, onu üreten sürüm, ortam ve kod yoluyla ilişkilendirilmelidir. Bir müşteri talebi, kapsam kontrol edilmeden evrensel bir gereksinim gibi ele alınmamalıdır.
Bu nedenle ciddi bir bağlam sistemi, erişip getirmeden daha fazlasına ihtiyaç duyar. Şunlar hakkında akıl yürütebilmenin bir yoluna ihtiyaç duyar:
- Yetki: Gereksinimi hangi kaynağın tanımlamasına izin verilir?
- Güncellik: Hangi bilgi güncel, hangisinin yerini yenisi aldı?
- Köken: Her iddia, kısıt veya sonuç nereden geldi?
- İlişkiler: Hangi sorun, sürüm, müşteri, veri kümesi ve kod yolu birbiriyle bağlantılı?
- İzinler: Bu görev için hangi kaynaklar kullanılabilir ve bu kişiye hangileri gösterilebilir?
Bağlam bir token yığını değildir. Zamanı, yetkisi ve sınırları olan bir grafiktir.
Daha fazla bağlam, kanıt olmadan daha fazla güven değil, daha fazla kanıt üretmelidir.
Asıl iş birimi değişikliktir
Editörler ve kodlama araçları dosyalar etrafında düzenlenir, çünkü değiştirdiğimiz şey dosyalardır. Mühendislik ekipleri ise değişiklikler etrafında düzenlenir.
Bir değişiklik bir nedenle başlar. Bir gereksinime dönüşür, koda ve veriye dokunur, incelemeden geçer, üretime ulaşır ve yeni kanıtlar üretir. Bu aşamalar birbirinden kopuk kalırsa, gelecekteki her görev yeni bir arkeoloji turuyla başlar.
Gerçek yazılım üzerinde çalışan bir yapay zekâ sistemi bu yaşam döngüsünü izlemelidir.
Uygulamadan önce, talebi, ilgili kısıtları ve çelişen kaynakları belirlemelidir. Bir kusuru düzelttiğini, beklenen davranışı değiştirdiğini ya da yeni bir sözleşme getirdiğini bilmelidir.
Uygulama sırasında, anlamlı her seçimi kanıtla ilişkilendirmelidir. Neden bu modül? Neden bu geçiş stratejisi? Neden bu dal korunsun? Açıklama, kodu üreten sohbetin ötesinde de varlığını sürdürmelidir.
Uygulamanın ardından, doğrulama sonuçlarını, gözden geçirme kararlarını ve yeni keşfedilen kısıtları değişikliğe eklemelidir. Aksi takdirde bir sonraki kişi—ya da bir sonraki AI oturumu—bunları yeniden keşfetmek zorunda kalacaktır.
İşte bu, bir depoyu düzenleyebilen bir araç ile mühendislik çalışmalarına katılabilen bir sistem arasındaki farktır.
AI muhakemeyi ortadan kaldırmamalı, yeniden kurma ihtiyacını azaltmalı
Daha iyi bağlam bazen otonom yazılım geliştirmeye giden bir yol olarak sunulur. Asıl yakın vadeli değeri ise daha az çarpıcı ama daha kullanışlıdır: bir değişiklik yapmadan önce gerçekliği yeniden kurmanın maliyetini azaltmak.
AI, özgün gereksinimi ilgili kodun yanına getirebilir. Alışılmadık bir güvenlik önlemini açıklayan olayı ortaya çıkarabilir. Başarısız olan bir metriği onu değiştiren sürümle ilişkilendirebilir. Uygulama başlamadan önce iki yetkili kaynağın birbiriyle çeliştiğini gösterebilir.
Bu yetenekler mühendislik muhakemesini ortadan kaldırmaz. Muhakemenin daha sağlam bilgiye dayanmasını sağlar.
Hangi ödünün kabul edilebilir olduğuna, bir gereksinimin eksiksiz olup olmadığına ve bir sürümün ne kadar risk taşıyabileceğine yine bir insan karar vermelidir. Sistem, kanıtları görünür, muhakemeyi ise incelenebilir kılmalıdır. Belirsizliği cilalı bir yamanın arkasına saklamamalıdır.
Ölçüt “kod üretebiliyor mu?” değildir.
Ölçüt şudur: “Bunun neden şu anda doğru değişiklik olduğunu açıklayabiliyor mu?”
Depo farkındalığından iş farkındalığına
Kodlama asistanları, önce geliştiricinin önündeki dosyayı anlayabildiklerinde faydalı hâle geldi. Depo farkındalığı bir sonraki büyük adımdı: ilgili kodu bulmak, sembolleri takip etmek ve bir proje genelinde değişiklik uygulamak.
Bir sonraki adım, deponun etrafındaki işe dair farkındalıktır.
Bu, kodu onu talep eden spesifikasyona, onu netleştiren konuşmaya, ona meydan okuyan üretim kanıtına ve sonrasında hatırlanması gereken karara bağlamak anlamına gelir. Aynı zamanda ilgisiz, güncelliğini yitirmiş veya kullanıcının izinlerinin dışında kalan bağlamı dışarıda bırakmak anlamına da gelir.
Dvina'yı geliştirirken, sürekli geri döndüğümüz fikirlerden biri bu. İş, tek bir dosyanın, uygulamanın ya da konuşmanın içinde gerçekleşmez. Anlam, bunlar arasındaki bağlantılarda ve bu bağlantıların zaman içinde nasıl değiştiğinde yaşar.
Depo hâlâ vazgeçilmezdir. Sistem davranışının çalıştırılabilir doğruluk kaynağı odur. Sadece ürün niyetinin, operasyonel gerçekliğin veya kurumsal hafızanın eksiksiz doğruluk kaynağı değildir.
Hikâyenin bütünü neyin inşa edildiğini değiştirir
Yalnızca kod varken doğal soru şudur:
Bu sisteme hangi değişiklik uyar?
Daha geniş bağlamla birlikte soru şuna dönüşür:
Bu sisteme, bu gereksinime, bu geçmişe ve bu ana hangi değişiklik uyar?
İkinci soru, kısıtları gerilemeye dönüşmeden önce yakalar. İnceleme yapanlara uygulamanın arkasındaki gerekçeyi verir. Yeni ekip üyelerinin sistemin neden bu şekilde göründüğünü anlamasına yardımcı olur. Yapay zekâya da sağlam bir rol kazandırır: editörün içindeki bir kâhin değil, işin tamamına yayılmış kanıtları bir araya getirebilen bir katılımcı.
Repo'nuz hiçbir zaman hikâyenin tamamı olmadı.
Asıl fırsat, bunun geri kalanını okuyabilen ve nasıl sonuca vardığını gösterebilen sistemler inşa etmekte.
