Vibe coding, çalışan görünümlü bir uygulama üretebilen kişilerin kimler olduğunu değiştirdi. Bir istem, geleneksel bir mühendislik ekibi ilk tasarım incelemesini tamamlamadan önce ekranlar oluşturabilir, bir API’ye bağlanabilir ve makul görünen bir iş akışı kurabilir.

Bu hız, işe alım ve teslimat açısından yeni bir sorun yaratıyor: Bir demo artık yazılımın iyi olduğuna dair güçlü bir kanıt değil. İşverenler giderek daha zor bir soru soracak: Bu yapay zekâ tarafından oluşturulmuş sistem, girdiler karmaşık olduğunda, bağımlılıklar başarısız olduğunda, kullanıcılar işlemleri tekrarladığında ve temel model değiştiğinde doğru davranabilir mi?

Yanıt, görsel ciladan çok disiplinli yazılım doğrulamasına benzeyen bir kalite çıtasından gelecek. Öne çıkan kişiler yalnızca bir yapay zekâ kodlama aracının ürettiğini göstermeyecek. Nasıl test ettiklerini, neleri güvenli biçimde yapamayacağını ve bir değişikliğin başka bir şeyi bozmadığını nasıl bildiklerini gösterecekler.

Bir kıyaslama, liderlik tablosu puanı değil kanıttır

Açık kaynak kodlama aracısı kıyaslamaları yararlı başlangıç noktaları sunar, ancak farklı yetenekleri ölçer. SWE-bench, gerçek GitHub sorunlarını ve depo anlık görüntülerini kullanarak bakım çalışmalarıyla ilgili sonuçlar verir. Terminal-Bench, komut satırı etkileşimini test eder. Listelenen diğer kıyaslamalar, SlopCodeBench ve ProgramBench dâhil olmak üzere, oluşturulan kodun ve aracı davranışının farklı yönlerini hedefler.

Bu kıyaslamalar araçları karşılaştırmaya veya bir başlangıç ölçütü oluşturmaya yardımcı olabilir, ancak işverenler tek bir puanı üretime hazır olmanın kanıtı olarak değerlendirme konusunda temkinli olmalıdır. Depo sorunlarını çözen bir model yine de güvenli olmayan yetkilendirme mantığı üretebilir. Terminal görevlerini tamamlayan bir aracı, uzun bir iş akışı boyunca durumu koruyamayabilir. Özenle hazırlanmış bir web uygulaması, mutlu yol demosunu geçerken yeniden denemeleri veya yinelenen ödemeleri hatalı ele alabilir.

Bu nedenle güvenilir bir portföy veya kurum içi inceleme, göreve özgü bir değerlendirme kümesi içermelidir. Bu küme; temsili hata raporlarını, normal kullanıcı yolculuklarını, hatalı girdileri, izin sınırlarını, bağımlılık hatalarını ve daha önce düzeltilmiş regresyonları içerebilir. Her vakanın yalnızca doğru görünen bir ekran görüntüsüne değil, açıkça belirtilmiş beklenen bir sonuca sahip olması gerekir.

Yapay zekâ tarafından oluşturulmuş yazılım için asgari test paketi

Küçük bir uygulama için yararlı bir kalite paketi, ayrıntılı bir araştırma laboratuvarı olmadan da oluşturulabilir:

  • Kabul testleri: başarılı ve başarısız sonuçlar dâhil olmak üzere, en önemli iş akışlarında kullanıcıya görünen davranışı doğrular.
  • Birim ve entegrasyon testleri: iş kurallarını yalıtılmış hâlde kontrol eder ve veritabanlarının, API’lerin, kuyrukların ve kimlik doğrulamanın amaçlandığı şekilde birlikte çalıştığını doğrular.
  • Negatif testler: eksik, hatalı biçimlendirilmiş, aşırı büyük, yinelenen ve yetkisiz girdiler gönderir. Yapay zekâ tarafından oluşturulan kod, genellikle istemde gösterilen yolda en güçlü görünür; bu nedenle istenmeyen yollar önem taşır.
  • Regresyon testleri: keşfedilen her hatayı kalıcı bir teste dönüştürür. Bir düzeltmeden sonra demonun başarılı olması, aynı hata bir sonraki oluşturulan değişiklikte geri dönebiliyorsa yeterli değildir.
  • Güvenlik kontrolleri: erişim denetimini, gizli bilgilerin işlenmesini, enjeksiyon savunmalarını, bağımlılık güvenlik açıklarını ve güvenilmeyen içeriğin araç çağrılarını veya ayrıcalıklı eylemleri etkileyip etkileyemeyeceğini test eder.
  • Operasyonel kontroller: zaman aşımını, yeniden denemeleri, idempotansı, günlük kaydını, uyarıları ve bir bağımlılık kullanılamadığında güvenli davranışı doğrular.

Bu, Stack Overflow’un aracılı bir yazılım geliştirme yaşam döngüsüne ilişkin anlatımında açıklanan QA mühendisliği yaklaşımına oldukça yakındır. Önemli değişim kültüreldir: kalite güvencesi, bir yapay zekâ kodu yazdıktan sonra gerçekleştirilen son bir inceleme değildir. Hızlı üretimi kullanılabilecek kadar güvenli hâle getiren yapı budur.

Yalnızca çıktıyı değil, orkestrasyonu da test edin

Yazılım bir yapay zekâ aracısı içerdiğinde, sıradan uygulama testleri gerekli olmakla birlikte yetersizdir. Sistem, modelin bir isteği yanlış anlaması nedeniyle başarısız olabilir; ancak çevresindeki orkestrasyon bağlamı kaybettiği, bir aracı iki kez çağırdığı, hatalı biçimlendirilmiş yapılandırılmış çıktıyı kabul ettiği veya hiç sonlanmadığı için de başarısız olabilir.

Özetin dağıtımdan önce önerdiği regresyon alanları pratik bir kontrol listesi oluşturur: bağlam kaybı, araç idempotansı, istem enjeksiyonu, yapılandırılmış çıktı, sonlanmama, erişim temellendirmesi ve durumun yeniden oluşturulması. Bunlar test edilebilir mühendislik özellikleridir.

Örneğin bir test aynı isteği iki kez çalıştırabilir ve ikinci denemenin yinelenen bir sipariş oluşturmadığını doğrulayabilir. Başka bir test, bir aracının iş akışının ortasında çalışmasını kesebilir, onu yeniden başlatabilir ve geri döndürülemez bir eylemi tekrarlamak yerine geçerli bir durumdan devam ettiğini doğrulayabilir. Bir erişim testi, sistemin yalnızca onaylanmış bir kaynak kümesindeki bilgileri belirtmesini veya döndürmesini zorunlu kılabilir. Yapılandırılmış çıktı testi, geçersiz bir yanıt sağlayabilir ve uygulamanın bunu geçerli veriymiş gibi sessizce ele almak yerine güvenli biçimde reddettiğini doğrulayabilir.

Uzun süre çalışan ve çok aracılı sistemler, özellikle açık hata kayıtlarına ihtiyaç duyar. Uzun bir etkileşim zincirinde hangi aracının hataya neden olduğunu ve bunun hangi noktada gerçekleştiğini belirlemek zor olabildiğinden, araştırmacılar otomatik hata atıflandırma üzerinde çalışıyor. Uygulamada ekipler; araç çağrılarını, girdileri, çıktıları, model sürümlerini, zaman damgalarını, durum geçişlerini ve nihai kararları gizliliğe duyarlı bir denetim kaydında saklamalıdır. Bu kanıt olmadan kırmızı bir test size bir şeylerin başarısız olduğunu söyler, ancak düzeltmeye nereden başlayacağınızı söylemez.

Tekrar üretilebilirlik bir kariyer avantajına dönüşecek

Yapay zekâ tarafından oluşturulan kod değişkendir. Yeniden çalıştırma farklı bir uygulama üretebilir; model güncellemesi davranışı değiştirebilir; sağlayıcı kesintisi yönlendirmeyi veya gecikmeyi değiştirebilir. Bu nedenle işverenler, değerlendirmeleri tekrarlanabilir hâle getirebilen adaylara değer verecektir.

Bu, mümkün olduğunda model anlık görüntülerini sabitlemek, istemleri ve yapılandırmayı kaydetmek, platform izin verdiğinde rastgeleliği kontrol etmek ve sonuçları değişken olan görevler için birden fazla deneme çalıştırmak anlamına gelir. Özet, sabitlenmiş anlık görüntüleri, kullanılabildiğinde düşük veya sıfır sıcaklığı ve güven aralığıyla sınırlandırılmış CI/CD geçitlerini yararlı güvenlik önlemleri olarak özellikle belirtir.

Uygulamalı bir rapor en az üç sonucu birbirinden ayırmalıdır:

  1. Geçme oranı: kaç vakanın başarılı olduğu.
  2. Tutarlılık: aynı vakanın tekrarlanan çalıştırmalarda ne sıklıkla başarılı olduğu.
  3. Önem derecesi: hataların yalnızca kozmetik mi, rahatsızlık verici mi, verilere zarar verici mi, güvenlikle ilgili mi yoksa güvenli olmayan bir dış eyleme yol açabilecek nitelikte mi olduğu.

Düşük riskli 20 biçimlendirme kontrolünün 19'unu geçen bir sistem, 20 vakanın 18'ini geçen ancak hiçbir zaman bir yetkilendirme sınırını aşmayan bir sistemden mutlaka daha iyi değildir. Kalite çıtası, hataları sonuçlarına göre ağırlıklandırmalıdır.

İnsan incelemesi her satırı değil, riski hedeflemeli

Daha iyi otomasyonun amacı, bir kişiyi yapay zekânın ürettiği her belirteci yeniden okumaya zorlamak değildir. Amaç, insanların dikkatini testlerin tam olarak karara bağlayamayacağı konulara yöneltmektir.

İncelemeciler kimlik doğrulama ve yetkilendirmeye, veri saklamaya, finansal veya sözleşmeye dayalı eylemlere, gizliliğe, geçişlere, hata kurtarmaya, üçüncü taraf izinlerine ve sistemin değerlendirme altyapısını doğrudan etkileyen değişikliklere odaklanmalıdır. Bir aracı için ayrıca hangi araçları çağırabileceğini, her aracın hangi verilere erişebileceğini ve geri döndürülemez bir eylemden önce onay gerekip gerekmediğini de incelemelidirler.

Slack Code'un iş birliğine dayalı yapay zekâ kodlamasını açıklarken öne çıkardığı görünür farklar, onay iş akışları, arşivlenmiş konuşmalar ve denetim günlükleri daha geniş bir beklentiye işaret ediyor: Yazılımın nasıl yapıldığının geçmişi önem taşıyacak. Bir incelemeci isteği anlayabilmeli, oluşturulan değişikliği inceleyebilmeli, test kanıtlarını görebilmeli ve dağıtımı kimin onayladığını belirleyebilmelidir.

Bu kayıt, yalnızca bürokrasi olsun diye tutulmaz. Etkileyici bir demoyu, başka bir kişinin sürdürebileceği kontrollü bir değişiklikten ayırt edilebilir kılar.

Portföye veya mülakata ne koymalı

Adaylar için en güçlü gösterim, kalite hikâyesi kasıtlı olarak görünür kılınmış küçük bir sistemdir. Depoyu, kurulum talimatlarını, mimari notlarını, test komutlarını, temsili test vakalarını, bilinen sınırlamaları ve kısa bir hata raporunu ekleyin. Bulunan ve regresyon testlerine dönüştürülen bir veya iki hatayı gösterin. Kullanılan modelin veya kodlama aracısının hangisi olduğunu, aracı mühendislik kararlarının sahibiymiş gibi sunmadan açıklayın.

Uygulama bir aracı kullanıyorsa araç izinlerini, durum modelini, yeniden deneme politikasını, sonlandırma koşulunu ve insan onayı noktalarını belgeleyin. Bilgi erişimi kullanıyorsa kaynakların nasıl seçildiğini ve kanıt bulunmadığında ne olduğunu gösterin. Harici hizmetleri çağırıyorsa zaman aşımı ve yinelenen istek davranışını ortaya koyun.

Tek bir başarılı kayda dayanarak güvenilirlik iddiasında bulunmayın. Denetlenebilir bir iddia daha çok şöyle olur: “Bu 12 senaryonun kaydedilmiş 30 çalıştırmasında sistem 28'inde kabul kriterlerini karşıladı; iki hata belirsiz tarih girdisiyle ilgiliydi ve her ikisi de belgelenmiştir.” Sayının kendisi, yöntemden, sınırlardan ve henüz test edilmemiş noktalar konusunda dürüst olmaktan daha az önemlidir.

Hızın yeni tanımı

Yapay zekâ, ilk sürümü üretmenin maliyetini düşürür. Bu, o sürümün güveni hak edip etmediğini bilmenin maliyetini ortadan kaldırmaz. Hatta daha hızlı üretim, değerlendirmeyi daha önemli kılabilir; çünkü dağıtımlar arasında daha fazla incelenmemiş değişiklik birikebilir.

Vibe coding sonrası profesyonel, şu döngüyle değerlendirilecek: davranışı tanımlamak, kod üretmek veya değiştirmek, gerçekçi ve hasmane vakaları test etmek, yüksek riskli kararları incelemek, hataları kaydetmek ve kanıtları kaybetmeden sistemi iyileştirmek. Karşılaştırmalı testler yeteneği kıyaslamaya yardımcı olabilir. Bu yeteneğin güvenilir yazılıma dönüşüp dönüşmeyeceğini ise kalite güvencesi uygulamaları belirler.

Dolayısıyla kalite çıtası “Yapay zekâyla bir uygulama yapabilir misin?” değildir. “Uygulamanın ne yaptığını kanıtlayabilir, bunu yapmayı bıraktığında tespit edebilir ve bir hatanın olaya dönüşmesini önleyecek sınırları tasarlayabilir misin?” sorusudur.