GitHub, Copilot düzeltme eylemlerini Microsoft Teams'teki issue bildirimleriyle eşleştirdi

GitHub ne yayımladı

Keith Azodeh'nin dev.to'daki yazısına göre GitHub'ın 23 Ekim güncellemesi, issue bildirimlerini Microsoft Teams uygulamasındaki Copilot eylemleriyle birleştiriyor. Eskiden bir kanal mesajı yalnızca bir issue'nun varlığını bildirirken, anlatılan entegrasyon sayesinde biri sohbette GitHub'dan bahsediyor ve ardından Copilot issue'yu inceliyor, bir düzeltme üretiyor ve bir pull request açıyor. İnsan adımları ortadan kalkmıyor: iş akışı ekip incelemesini, testi ve merge işlemini koruyor.

Yazının kendisi dikkat çekmeye değer bir açıklama içeriyor: Azodeh'nin belgelenmiş çalışmasından otonom bir yapay zeka sistemi tarafından üretildi ve içinde anlatılan hata örneği gerçek bir olay değil, açıklama amaçlı bir senaryo.

Daha hızlı kayıt, belirsizliği daha maliyetli yapıyor

Yazının ana iddiası, sohbet mesajından pull request'e giden yolu sıkıştırmanın bir hata raporunun içermesi gerekenleri değiştirdiği. Küçük bir ekip için fayda, bir sorunu fark etmek ile incelemeye başlamak arasındaki kesintilerin azalması. Risk ise, Azodeh'ye göre, kısa bir bildirimi tamamlanmış bir mühendislik görevi sanmak. "Katılımcılar etkinliğe giremiyor" gibi bir mesaj kasıtlı bir erişim kısıtlamasını, bayat bir ekranı ya da başarısız bir check-in isteğini tarif ediyor olabilir — üç farklı değişiklik gerektiren üç ayrı sorun. Eline yalnızca şikayet geçirilen bir agent, bu boşlukları varsayımlarla kapatmak zorunda.

Kullanılabilir bir rapor ne içerir

Yazı, hatanın iki tarafında da kesinlik istiyor: bilinen bir uygulama sürümüne ve kararlı test tanımlayıcılarına kaydedilmiş başlangıç durumu, gerçekleştirilen eylem, gözlenen sonuç ve beklenen sonuç. Açıklayıcı senaryo — check-in yapılmış bir katılımcının manuel yenileme yapılana kadar kısıtlı bir ekranda kalması — aynı derecede kesin bir beklentiye kavuşuyor: erişim yenileme olmadan güncellenmeli ve etkinliğin katılım koşulunu yerine getirmemiş katılımcı kısıtlı kalmalı. İkinci madde asıl nokta, çünkü kapıyı tamamen kaldıran bir yama şikayeti ortadan kaldırırken ürünün tasarımını bozardı.

Yazıda iki uyarı daha yer alıyor: kayıtlı durumun gerçekten değiştiğini doğrulayın — başarı mesajının kendisi de hatanın parçası olabilir — ve paylaşılan her şeyden telefon numaralarını, session token'larını ve katılımcı bilgilerini çıkarıp yerine sentetik kayıtlar kullanın.

Onarmadan önce inceleyin

Yazıya göre bir kodlama agent'ına yapılan ilk istek, davranışı yeniden üretip üretemediğini ve kanıtların desteklediği en dar açıklamayı rapor edip edemeyeceğini sormalı. O ana kadar birden çok hipotez açık kalır — arayüz erişim durumunu yenilemeyebilir, bir yanıt gezinmeden sonra ulaşabilir, test yanlış etkinliği hedefliyor olabilir. Hata anlaşıldıktan sonra bile agent'tan istenen, sign-in, izinler ve check-in'in aynı anda yeniden tasarımı değil, dar kapsamlı bir değişiklik olmalı. Küçük düzeltmelerin gözlenen hataya bağlanması ve tanı yanlış çıkarsa geri alınması daha kolaydır; ayrıca başarısız olan bir agent denemesi bile açıklamayı daralttığında bir şey öğretir.

Hatayı kanıt olarak saklayın

Regresyon kapsamı için yazı, amaçlanan geçişi ifade eden bir assertion öneriyor — özgün davranışa karşı başarısız olan ve düzeltmeden sonra geçen bir test, çünkü önceden zaten geçen bir test bu özel hata hakkında hiçbir şey kanıtlamaz. Komşu davranışların da denetlenmesi gerekir: koşulu karşılamayan katılımcı kapıyı hâlâ görürken, onaylanan katılımcı etkinlik alanına ulaşmalı. Pull request; raporu, yeniden üretilebilir kurulumu, açıklamayı, değişikliği ve doğrulamayı bir araya getirmeli ve bir denetimin agent'ın ortamında çalıştırılamadığını açıkça belirtmelidir — makul görünen bir yama ile doğrulanmış bir yama aynı teslimat değildir.

Neden önemli

GitHub, bir düzeltmenin başlangıç noktasını issue takip sisteminden ekiplerin zaten konuştuğu yere taşıdı ve bu da oraya yazılanların değerini yükseltti. İnceleme, test ve merge insan adımları olarak kaldığından, entegrasyonun yararı neredeyse tamamen agent'a geçirilen kanıtın kalitesine bağlı. Yeniden üretilebilir bir rapor, inceleyiciye somut bir soru sorma imkânı verir — bu düzeltme, amaçlanan kullanıcı akışını korurken gösterilen hatayı ele alıyor mu — ve ürün kararlarını ekipte tutarak agent'ın bunları uydurmasına izin vermez.