AI ile çalışan bir uygulama geliştirmek, onu canlı ortama açmakla aynı şey değildir. Kod hazır olsa bile yayınlama yetkisini, güvenlik koşullarını ve onay sorumluluğunu netleştirmeniz gerekir.
Özellikle yayınlama görevini bir AI ajanına verdiğinizde mesele yalnızca dağıtım otomasyonu değildir: Ajanın neyi, kimin onayıyla ve ne kadar süreyle yapabileceğini belirlemelisiniz.
Bu rehber, VibeHub'ı değerlendirirken bu sınırları nasıl sınayacağınızı ve mevcut sürecinizle nasıl karşılaştıracağınızı gösterir.
Kod üretiminden yayınlama standardına
Platform mühendisliği ve kurum içi geliştirici platformu (Internal Developer Platform — IDP) yaklaşımı, geliştiricilere ortak bir çalışma yolu sunmayı hedefler. Ancak bu alandaki araçlar aynı işi yapmaz.
Örneğin ekibiniz geliştirici portalından servis sahibini buluyor, CI/CD aracında derleme ve dağıtımı çalıştırıyor, ayrı bir sistemde yayın onayı topluyor olabilir. Bu düzen zaten ihtiyaçlarınızı karşılıyorsa yeni bir platform eklemek zorunda değilsiniz.
VibeHub demosunda aynı uygulamanın akışını baştan sona göstermelerini isteyin: Koddan yayına geçerken hangi adımları platform yürütüyor, hangileri başka araçlarda veya insanlarda kalıyor? Mevcut akışınızdaki manuel aktarımlarla karşılaştırın. Böylece özellik sayısını değil, gerçekten değişen işi görürsünüz.
Kod hazır, ajan için yayınlama onayı yok
Bu senaryo kurgudur; müşteri deneyimi veya performans verisi değildir.
Bir geliştirici, AI desteğiyle web servisi ve PostgreSQL veritabanından oluşan şirket içi destek uygulaması hazırlıyor.
Pazartesi kod hazır. Hedef Kubernetes ortamı, uygulama adresi ve bağlantılar da hazır. Ekip, salı günkü tanıtımdan önce yayınlama görevini AI ajanına vermek istiyor.
Ancak ajan için yayınlama yetkisini kimin onaylayacağı belli değil. Geliştirici pazartesi öğleden sonra onay istiyor; talep platform ve güvenlik ekipleri arasında dolaşıyor. Salı sabahı hâlâ bir onay sahibi yok. Ekip, ajana erişim açmıyor ve geliştirici tanıtımı yerel bilgisayarından yapıyor.
Yayını durduran tek neden, ajanın erişimini onaylayacak sorumlunun belirlenmemesi. Daha hızlı kod üretmek bu beklemeyi çözmüyor. Önce sorumluyu belirlemek, ardından onay kararını teknik erişimle ilişkilendirmek gerekiyor.
AI ajanının yetkisini işlem yaparak sınayın
Bir erişim token'ının bulunması, yetkinin doğru sınırlandığını göstermez. İnsan onayının bulunması da her işlem için yeniden onay gerektiği anlamına gelmez.
VibeHub görüşmesinde AAT (Agent Access Token) ve HITL (insan onayı) başlıklarını açıklamayla sınırlamayın. Test ortamında şu işlemleri göstermelerini isteyin:
- Ajan, onaylanan uygulamayı yayınlasın.
- Aynı erişimle kapsam dışındaki bir projeye işlem yapmayı denesin.
- Süresi dolmuş veya iptal edilmiş erişimle yeniden denesin.
Ardından onayın hangi aşamada gerektiğini netleştirin: Erişimi ilk kez açarken mi, her yayında mı, kapsam değiştiğinde mi?
Kabul kriteriniz, onay ekranını görmek değil; izin verilen işlemin gerçekleşmesi ve kapsam dışındaki işlemin engellenmesi olmalı. Platformun bu sınırları nasıl uyguladığını demoda doğrulayın.
Güvenlik bulgusunu yayınlama kararına bağlayın
Tarama sonucunu görmek ile o sonuca göre yayını durdurmak farklı yeteneklerdir.
Pilot öncesinde ekibinizin gerçek bir kabul kriterini seçin. Örneğin kurum politikanız kritik bağımlılık açığı içeren bir sürümün yayınlanmasını yasaklıyorsa, kontrollü test ortamında bu koşulu oluşturun.
Ürün ekibinden şunları göstermesini isteyin:
- Kuralı nerede tanımlıyorsunuz?
- Bulgu ortaya çıktığında yayın hangi adımda duruyor?
- İstisna gerekiyorsa kim, nasıl onaylıyor?
Bu örnek, VibeHub'a belirli bir politika motoru veya kural arayüzü atfetmez. Satın alma öncesinde göstermeniz gereken bir ihtiyacı, doğrulanabilir bir teste dönüştürür.
Kimler değerlendirmeli?
Bu değerlendirme özellikle üç ekip profili için anlamlıdır:
- Platform ve DevOps ekipleri: Birden fazla uygulamanın Kubernetes yayınlarını üstlenenler.
- AI ajanlarıyla çalışan geliştirme ekipleri: Ajanları kod üretiminin ötesinde operasyonel görevlerde kullanmayı planlayanlar.
- Çok ekipli veya çok müşterili organizasyonlar: Proje sınırlarını ve onay sorumluluklarını ayrı tutması gerekenler.
Yalnızca statik site yayınlamak, servis kataloğu kurmak veya kod üreten bir AI aracı edinmek istiyorsanız farklı araç kategorileri daha doğrudan bir başlangıç olabilir. Kubernetes kullanmayı planlamıyorsanız bu rehberdeki değerlendirme çerçevesi de öncelikli ihtiyacınız değildir.
Pilotun başarısını nasıl ölçersiniz?
İhtiyaç uyumu, pilotu başlatma gerekçesidir. Kazanım ise mevcut süreçle karşılaştırarak ölçülür. Aynı uygulama ve benzer yayın kapsamı için şu göstergeleri kaydedin:
| Ölçüt | Ölçüm yöntemi |
|---|---|
| Koddan canlıya geçen süre | Kodun hazır olması ile uygulamanın erişime açılması arasındaki süreyi ölçün. |
| Manuel müdahale | Yayın boyunca başka araçlarda veya elle yaptığınız işlemleri sayın. |
| Kontrol testleri | Yetki ve güvenlik testlerinde beklenen sonuç ile gerçekleşen sonucu karşılaştırın. |
| İnceleme süresi | Bir yayının kod, tarama ve onay kayıtlarına ulaşmak için geçen süreyi ölçün. |
Sonucu yalnızca "yayın daha hızlı tamamlandı" diye özetlemeyin. Hangi beklemenin azaldığını, hangi işin hâlâ ekipte kaldığını ve hangi kontrolün çalıştığını ayrı ayrı kaydedin.
Kendi uygulamanızla değerlendirin
Bütün uygulamalarınızı taşımak yerine, gerçek ihtiyaçlarınızı temsil eden tek bir uygulamayla başlayın.
Git sağlayıcınızı, uygulama bileşenlerinizi ve hedef Kubernetes ortamınızı hazırlayın; ATP ekibiyle iletişime geçerek VibeHub hakkında görüşme talep edin. Görüşmede yayınlama akışını, ajan yetkisinin sınırlarını ve pilotun kabul kriterlerini birlikte incelemeyi isteyin.