1. Aracı değil, yapılacak değişikliği tanımlayın
Yapay zekâdan kod istemeden önce, kullanıcı işini tamamladığında neyin farklı olacağını yazın. Hangi kayıt okunacak, hangi durum değişecek, işlemi kim yapabilecek ve hangi koşulda işlem duracak? canias ERP’nin geliştirme platformu TROIA, uygulama geliştirme ve uyarlama için bir çalışma ortamı sunar. Bu ortamda üretilen önerinin doğru olması, işletmenin kuralını doğru anlamasına bağlıdır. Örneğin bir onay kontrolü talebi, yalnızca ekranda yeni bir düğme açmak değildir; reddetme, yeniden gönderme ve yetkisiz kullanım davranışları da kapsamın parçasıdır.
- Beklenen sonucu bir kullanıcı adımı ve gözlemlenebilir sonuç olarak yazın.
- Kapsam dışındaki modül ve davranışları açıkça belirtin.
2. Modele verdiğiniz bağlamı sınırlayın
İyi bir geliştirme sorusu için bütün veritabanını veya tüm kaynak kodu paylaşmak gerekmez. İlgili alanların tanımı, izin verilen bir kod parçası ve anonim bir örnek kayıt çoğu inceleme için daha anlaşılır bir başlangıçtır. Kullanılacak aracın hangi veriyi hangi hizmete göndereceğini ekipçe belirleyin. Erişim anahtarlarını, gerçek kişi bilgilerini ve müşteri sırlarını örneklerden çıkarın. Sürüm veya kurulum farkı bilinmiyorsa bunu boşluk olarak işaretleyin. Modelin eksik bilgiyi tahmin ederek gerçek bir tablo, yöntem veya iş kuralı gibi sunmasına izin vermeyin.
- Her örnekte kaynağı, sürümü ve kullanım iznini kontrol edin.
- Gerekmeyen alanları çıkarın; gerçek verinin yerine örnek değerler kullanın.
3. Öneriyi küçük ve incelenebilir tutun
Hakan, bir üretim şirketindeki canias modül geliştirmelerini kolaylaştırmak için özel bir yapay zekâ aracı geliştirdi. Bu deneyimin gösterdiği çalışma alanı, genel bir sohbet ekranından daha somuttur: belirli bir geliştirme ihtiyacını anlaşılır girdilere ve değerlendirilebilir çıktılara dönüştürmek. Bu, her üretilen kodun doğru olduğunu veya doğrudan canlıya alınabileceğini göstermez. İlk öneride tek bir davranışa odaklanın. Araçtan etkilenen alanları, varsayımları ve değişiklik gerekçesini kodla birlikte açıklamasını isteyin. Gereksiz yeniden yazımları ayırın; inceleyen kişinin neyin değiştiğini görebilmesi gerekir.
- Tek öneride tek iş davranışını ele alın.
- Doğrulanmamış tablo, sınıf ve yöntem adlarını kontrol maddesine dönüştürün.
4. Kodu iş kuralından bağımsız değerlendirmeyin
İnsan incelemesi yalnızca yazım hatası aramak değildir. Değişikliğin yetki kontrolünü, belge durumlarını, bağlantılı modülleri ve kayıt bütünlüğünü nasıl etkilediğine bakın. NIST’in yapay zekâ destekli geliştirme yaklaşımında da çıktılar inceleme, test ve sorumlu onayıyla ele alınır. Bir işlemin neden engellendiği kullanıcıya anlaşılır mı? İşlem yarıda kalırsa kayıt hangi durumda kalır? İki kullanıcı aynı belgeyle çalışırsa beklenen davranış nedir? Bu soruları cevaplamayan bir öneri, düzgün görünen kod üretmiş olsa da geliştirme işini tamamlamamıştır.
- Normal akışın yanında engellenmesi gereken işlemleri inceleyin.
- İnceleme kararını ve açık soruları değişiklik kaydında tutun.
5. Testi üretilen koda göre değil ihtiyaca göre kurun
Yapay zekânın yazdığı kodla aynı varsayımlardan üretilmiş bir test, hatayı tekrar onaylayabilir. Kabul örneklerini önce süreç sahibiyle oluşturun. Eksik alan, yetkisiz kullanıcı, tekrar gönderilen işlem ve önceki bir kaydın düzeltilmesi gibi sınırları dahil edin. Beklenen veritabanı ve ekran sonuçlarını birlikte kontrol edin. Test ortamının canlı kullanımdan hangi noktalarda ayrıldığını da not edin. Sadece test sayısını paylaşmak yerine hangi davranışların doğrulandığını ve hangi belirsizliklerin kaldığını açıklamak, devreye alma kararına daha fazla katkı sağlar.
6. Devreye alma ve bakım sorumluluğunu bırakmayın
Kabul edilen değişiklik için sürüm, devreye alma adımları, geri dönüş yolu ve ilk kullanım kontrolü hazırlayın. Ekip, sorun görüldüğünde kimin karar vereceğini ve hangi kayıtların inceleneceğini bilsin. Yapay zekâ aracı geliştirmede yardımcı olabilir; iş kuralının sahibi, kodu inceleyen kişi ve yayına karar veren sorumlu yine belirli olmalıdır. Hedef, daha çok kod üretmek değil, bakımını yapabileceğiniz doğru değişikliği tamamlamaktır. Jay ise ayrı bir ürün geliştirme çalışmamızdır; burada anlatılan özel geliştirme aracıyla veya tüm müşterilere sunulan hazır bir canias bağlantısıyla eş tutulmamalıdır.
