Gwen Davis, yapay zekâ ajanlarının kullanımının yaygınlaşmasıyla geliştiricilerin değerinin her kod satırını yazmaktan ziyade araçları yönlendirmeye, çıktıları incelemeye ve teknik kararlar almaya daha fazla kayacağını düşünüyor. Makale üç uygulama öneriyor: ajanları yönetmek, ilk yanıtı kabul etmemek ve tasarruf edilen zamanı daha kapsamlı sorunları çözmeye ayırmak.
Yapay zekâ araçlarının kod yazmaya yardımcı olmaktan yazılım görevlerinin daha büyük bölümlerini gerçekleştirmeye geçmesiyle geliştiricilerin çalışma biçimi değişiyor. Gwen Davis’e göre artık yalnızca kod yazmak yeterli değil; sorunu tanımlamak, uygun bağlamı sağlamak, çıktıları değerlendirmek ve çözümü benimsemeden önce teknik ödünleşimleri açıklamak giderek daha önemli hâle geliyor.
1. Yapay zekâyı yalnızca kullanmak yerine yönlendirmek
Makale, yapay zekâya dayalı bir ortamda uygulamanın işi açıkça tanımlamakla, ardından görevleri dağıtıp sonuçları gözden geçirmekle başladığını açıklıyor. Örneğin bir kimlik doğrulama yolu ekleme görevinde bir ajan uygulamayı hazırlarken başka bir ajan belgeleri oluşturabilir ve üçüncü bir ajan test grubunu hazırlayabilir.
Bu durum geliştiricinin nihai sonuç üzerindeki sorumluluğunu ortadan kaldırmıyor. Pratikteki değişiklik, geliştiricinin her bölümü manuel olarak uygulamaya daha az, gereksinimleri belirlemeye, ajanların çıktılarını koordine etmeye ve gözden geçirme ya da yayımlama için neyin uygun olduğuna karar vermeye daha fazla zaman ayırmasıdır. Davis, yapay zekâ ajanlarını yönlendirmeyi öğrenmenin bağımsız bir pratik beceri hâline geldiği sonucuna varıyor.
2. Gözden geçirmeden ilk yanıta güvenmeyin
Araçlar saniyeler içinde ikna edici görünen bir çözüm üretebilir; ancak bu çözüm, hızlı bir okumayla fark edilmeyen kusurlar içerebilir. Makale, her müşteri için en yeni siparişi döndüren bir SQL sorgusu örneğini kullanıyor; çözüm, eşleşen zaman damgalarının ele alınmasını gözden kaçırabilir, uygun bir dizin önermeyebilir veya büyük tablolarla performansı düşebilir.
Davis, ilk modelin çalışmasını eleştirmesi için ikinci bir model kullanılmasını ve ardından iki yanıta mühendislik muhakemesinin uygulanmasını öneriyor. Modellerin güçlü ve kör noktalarının farklı olduğuna dikkat çekiyor ve GitHub Copilot’a entegre Rubber Duck ajanının planları, kodu ve testleri eleştirmek için ikinci bir model kullandığını belirtiyor. Ancak insan incelemesi zorunlu olmaya devam ediyor; amaç insan muhakemesinin yerine geçmek değil, devam etmeden önce eleştirel bir bakış açısı eklemektir.
3. Tasarruf edilen zamanı daha büyük sorunları çözmek için kullanmak
Yapay zekâ uygulamanın daha büyük bir bölümünü üstlendiğinde geliştirici, mevcut zamanını müşterilerin ihtiyaçlarını anlamaya, mimari ödünleşimleri değerlendirmeye, sistemleri tasarlamaya ve aracın onun adına alamayacağı kararları vermeye yönlendirebilir.
Karanlık mod eklemeyle ilgili bir örnekte yapay zekâ değişiklikleri uygulayabilir, testleri oluşturabilir ve belgeleri güncelleyebilir. Buna karşılık geliştiricinin listesinde müşterilerin karşılaştığı sorunu doğrulamak, mimari ödünleşimleri gözden geçirmek, erişilebilirliği kontrol etmek, başarı ölçütlerini belirlemek ve çözümü onaylamak yer alır.
Pratikte ne değişiyor?
Temel mesaj, programlama becerisinin değerini yitirdiği değil, sorumluluk kapsamının genişlediğidir. Geliştirici sonuç kalitesinden sorumlu olmaya devam eder; ancak araçları yönlendirme becerisini, hatalarını keşfetme ve uygulamayı projenin gerçek amacıyla ilişkilendirme becerisiyle birleştirmesi gerekir. Makale genel nitelikte pratik yönergeler sunuyor; ancak bu uygulamaların etkisini ölçmeye yönelik metrikleri veya ajanlara devredilmesi gereken görevlerin sınırlarını belirlemiyor. Bu nedenle uygulama kararları projenin niteliğine ve risk düzeyine bağlı kalıyor.