Yapay Zekâ Prototipi Canlıya Nasıl Alınır

Bir yapay zekâ prototipini canlıya almak, “denediğimde çalışıyor” ile “başkaları kullandığında da çalışmaya devam ediyor” arasındaki farkı kapatmak demektir. Pratikte bu beş şey anlamına gelir: bir şeyi her değiştirdiğinizde ana akışları test etmek, kimin neyi görüp değiştirebileceğini kilitlemek, kullanıcılarınız söylemeden hataları duyduğunuzdan emin olmak, verileri yedeklemek ve geri yükleyebildiğinizi kanıtlamak ve uygulamayı telefonda yeterince hızlı tutmak. Bunların hiçbiri yeniden yazmayı gerektirmez; prototipi kuran yapay zekâyla birlikte üzerinden geçeceğiniz bir kontrol listesidir.

Prototip ile canlı uygulama: gerçekte ne değişir

Bir prototipin dikkatli bir tek kullanıcısı vardır: siz. Hangi düğmelere basılacağını bilirsiniz, mantıklı girdiler yazarsınız ve bir şey bozulursa omuz silkip yapay zekâdan düzeltmesini istersiniz. Canlı bir uygulamanın ise çok sayıda dikkatsiz, bazı meraklı ve ara sıra kötü niyetli kullanıcısı olur. Kodun “kurumsal” hale gelmesi gerekmez; prototipin hiç karşılaşmadığı durumları yönetebilmesi gerekir.

Bu rehberin geri kalanı bu satırların her birini adım adım inceliyor.

Adım 1: Kapsamı dondurun ve ana akışları yazın

Hiçbir şeyi sertleştirmeden önce birinci sürümün ne olduğuna karar verin. En önemli üç ila altı akışı listeleyin; örneğin “kayıt ol, bir proje oluştur, bir ekip arkadaşını davet et, öde”. Bunlar test senaryonuz, izleme hedefleriniz ve her değişiklikten sonra kontrol ettikleriniz olur.

Listede olmayan her şey ya kesilir ya da açıkça beta olarak etiketlenir. Dört akışı güvenilir hale getirmek, on dört akışı güvenilir hale getirmekten çok daha kolaydır.

Adım 2: Bir yabancı gibi test edin, sonra tekrarlanabilir hale getirin

Yapay zekâ oluşturucular, mutlu yolda çalışan kod üretmekte iyidir. Canlıdaki sorunlar ise mutlu olmayan yollarda ortaya çıkar. Her ana akışı şunlarla test edin:

• Kötü girdi: boş zorunlu alanlar, 5.000 karakterlik bir ad, @ işareti olmayan bir e-posta, negatif bir adet, geçmiş bir tarih.
• Yenilemeler ve geri tuşu: ödeme sırasında sayfayı yenileyin; bir formu gönderdikten sonra geri tuşuna basın. Bir şey iki kez oluşuyor mu?
• İki sekme, iki kullanıcı: iki farklı hesapla giriş yapın ve URL'deki kimliği değiştirerek birbirinizin sayfalarını açmaya çalışın.
• Yavaş ve küçük: telefon boyutunda bir ekran ve yavaşlatılmış bir bağlantı (tarayıcı geliştirici araçları bunu simüle edebilir).
• Boş durumlar: hiç verisi olmayan yeni bir hesap. Prototipler çoğu zaman örnek verilerle kurulur ve onlar olmadan bozuk görünür.

Ardından kontrolü tekrarlanabilir hale getirin. En azından yazılı bir kontrol listesi tutun ve her sürümden önce çalıştırın. Daha iyisi, yapay zekâdan en önemli akışlar için otomatik testler yazmasını isteyin:

Bu akışlar için otomatik uçtan uca testler ekle: e-postayla kayıt olma, bir proje oluşturma, ikinci bir kullanıcı davet etme ve Stripe test modunda ödemeyi tamamlama. Ayrıca bir kullanıcının URL'yi değiştirerek başka bir kullanıcının projesini görüntüleyemeyeceğini ya da düzenleyemeyeceğini doğrulayan testler ekle.

Bir kullanıcının bir şeyi yapamadığını kanıtlayan testler, prototiplerde en sık eksik olan testlerdir.

Adım 3: Prototiplerin atladığı güvenlik temelleri

Yapay zekâ ile yapılmış uygulamalardaki güvenlik sorunlarının çoğu egzotik değildir. Eksik kontrollerdir. Bu listeyi gözden geçirin ve daha kapsamlı yapay zekâ ile yapılmış uygulamalar için güvenlik kontrol listesine bakın:

• Sunucuda yetkilendirme. Bir düğmeyi gizlemek güvenlik değildir. Veri okuyan ya da değiştiren her istek, sunucuda giriş yapmış kullanıcının buna izni olup olmadığını kontrol etmelidir. Uygulamanız satır düzeyi kuralları olan bir veritabanı kullanıyorsa, bunların açık ve test edilmiş olduğundan emin olun.
• Gizli bilgiler tarayıcının dışında. Ödeme, e-posta ya da yapay zekâ sağlayıcılarının API anahtarları sunucu tarafı ortam değişkenlerinde olmalıdır, asla ön yüz kodunda değil. Bunun ne anlama geldiğinden emin değilseniz, ortam değişkenleri ve gizli bilgiler nedir rehberini okuyun.
• Sunucuda doğrulama. Tarayıcı atlatılabilir; bu yüzden önemli her kontrolü sunucuda da tekrarlayın.
• Girişin düzgün yapılması. Elle yazılmış parola saklama yerine iyi test edilmiş bir kimlik doğrulama kütüphanesi ya da hizmeti kullanın. Uygulamanıza giriş ekleme rehberi seçenekleri anlatır.
• Giriş, kayıt, parola sıfırlama ve e-posta gönderen ya da ücretli bir API çağıran her şey için hız sınırları.
• Anlaşılır hatalar. Kullanıcılar “bir şeyler ters gitti” mesajını görmeli; ayrıntılar ekrana değil kayıtlara gitmelidir.
• Sızan her şeyi yenileyin. Canlı bir anahtar bir zamanlar bir sohbete, bir commit'e ya da bir ekran görüntüsüne yapıştırıldıysa, sağlayıcıda değiştirin.

Bir seferde çok alanı kapsayan bir istem:

Bu uygulamayı canlı güvenlik açısından incele. Her API rotasının okuduğu ya da değiştirdiği kaydın giriş yapmış kullanıcıya ait olduğunu doğruladığını, hiçbir gizli anahtarın tarayıcıya gönderilmediğini, girdilerin sunucuda doğrulandığını ve girişin ile parola sıfırlamanın hız sınırlı olduğunu kontrol et. Bir şeyi değiştirmeden önce bulduklarını listele.

Önce bir liste istemek, tek bir dev değişiklik almak yerine sorunları görmenizi ve sırayı siz belirlemenizi sağlar.

Adım 4: Bozulduğunu bilmek — kayıt tutma ve izleme

Önizlemede hatalar oluştukça görürsünüz. Canlıda ise uygulamanın size haber vermesi gerekir. En ucuzdan en yararlıya üç katman:

1. Sunucu kayıtları. Hataların, yeniden üretmek için yeterli bağlamla kaydedildiğinden emin olun: hangi rota, hangi kullanıcı kimliği (parola ya da kart bilgisi değil), hangi girdi yapısı. Uygulama yalnızca konsola yazıyorsa yapılandırılmış kayıt tutmasını isteyin.
2. Hata takibi. Sentry ya da benzeri bir hizmet, ön yüz ve arka uç istisnalarını yakalar, gruplar ve size e-posta gönderir. Küçük bir uygulama için bu hizmetlerin ücretsiz katmanları çoğu zaman yeterlidir; güncel limitleri sitelerinden kontrol edin.
3. Çalışma süresi kontrolleri. Birkaç dakikada bir ana sayfanızı ve bir kritik API rotanızı yükleyen, başarısız olursa sizi uyaran harici bir hizmet. Bu, uygulamanın hiç kayıt tutamadığı sorunları yakalar.

Bir alışkanlık daha ekleyin: her sürümden sonra, canlı uygulamayı açın ve ana akış kontrol listenizi yalnızca önizlemede değil, gerçek URL'de çalıştırın.

Adım 5: Yedeklemeler ve geri dönüş yolu

Korunması gereken iki farklı şey vardır ve bunlar kolayca karıştırılır.

• Kod. Projeyi her değişikliğin geri alınabilmesi için sürüm kontrolünde tutun. Birçok yapay zekâ oluşturucu dosyalarınızın kontrol noktalarını tutar; bir Git deposuyla senkronize etmek, oluşturucunun dışında da bir kopya sağlar.
• Veri. Kodu geri almak veritabanını geri almaz. Hatalı bir geçiş ya da hatalı bir silme düğmesi, hiçbir kod kontrol noktasının geri getiremeyeceği kayıtları yok edebilir.

Veri için, uygulamanın kendi barındırma alanı dışında düzenli yedeklemeler kurun — bir Postgres veritabanı için yaygın yaklaşım, ayrı bir depolama alanına planlanmış bir pg_dump çalıştırmaktır; birçok yönetilen veritabanı sağlayıcısı ise otomatik yedekleme ya da belirli bir ana geri dönme sunar. Sonra çoğu kişinin atladığı adımı atın: bir yedeği geçici bir veritabanına geri yükleyin ve verilerin orada olduğunu kontrol edin.

Ayrıca yıkıcı işlemleri daha güvenli hale getirmesi için yapay zekâdan isteyin: silmeler için bir onay adımı ve kullanıcıların geri isteyebileceği her şey için “yumuşak silme” (kayıtları kaldırmak yerine silinmiş olarak işaretlemek).

Adım 6: Telefonda da dayanan performans

Prototipler hızlı hissettirir, çünkü tek kullanıcı sizsiniz ve veri kümesi çok küçüktür. Yayından önce:

• Gerçek boyutta veri yükleyin. Yapay zekâdan birkaç bin kayıt eklemesini isteyin ve hangi sayfaların yavaşladığına bakın. Listeler genellikle sayfalama gerektirir; veritabanı da genellikle filtrelediğiniz ve sıraladığınız sütunlarda indeks ister.
• Görselleri küçültün. Aşırı büyük görseller bir sayfanın yavaş yüklenmesinin en yaygın nedenidir. Boyutlandırılmış, sıkıştırılmış görseller ve ekranın alt kısmındaki görseller için tembel yükleme isteyin.
• Ölçün. Canlı URL'de, mobil modda Chrome geliştirici araçlarındaki Lighthouse'u çalıştırın. Google'ın Core Web Vitals ölçütleri makul bir hedeftir: En Büyük İçerikli Boyama 2,5 saniye içinde, Sonraki Etkileşime Kadar Geçen Süre 200 ms veya daha az ve Kümülatif Düzen Kayması 0,1 veya daha az.
• “Uyanma” gecikmelerine dikkat edin. Boşta kaldığında uyuyan barındırma para tasarrufu sağlar, ancak sessiz bir dönemden sonraki ilk ziyareti yavaşlatır. Yeni bir uygulama için bu çoğu zaman kabul edilebilir bir takastır; bunun olduğunu bilin.

Projeler sayfası 5.000 kayıtla yavaş. Sunucu tarafı sayfalama ekle (sayfa başına 25), filtrelediğimiz ve sıraladığımız sütunlar için veritabanı indeksleri ekle ve bir sonraki sayfa yüklenirken bir yükleniyor durumu göster.

Adım 7: Operasyonel temeller

Hobi amaçlı bir uygulamayı insanların güvendiği bir uygulamadan ayıran birkaç küçük şey vardır:

• HTTPS'li özel bir alan adı. Özel alan adı nasıl bağlanır rehberine bakın.
• Kayıt onayları ve parola sıfırlamalar için doğrulanmış bir alan adından işlemsel e-posta. Uygulamanızdan e-posta nasıl gönderilir rehberinde anlatılır.
• Gerçekte neyi topladığınızı anlatan gizlilik politikası ve koşullar. Kazanmadığınız uyumluluk iddialarını kopyalamayın.
• Bir destek kanalı — izlenen bir e-posta adresi bile olsa.
• Ödemeler ve e-posta için ayrı test ve canlı anahtarlar, ayrıca hangi ortamın hangi anahtarı kullandığına dair net bir not.

Adım 8: Temiz bir devir

Önce ya da sonra uygulamada başka biri çalışacaktır: bir serbest çalışan, yeni bir ortak kurucu ya da altı ay sonra siz. Bunu kolaylaştırın:

• Uygulamanın nasıl çalıştırılacağını, hangi ortam değişkenlerine ihtiyaç duyduğunu (yalnızca adları, asla değerleri) ve nasıl yayınlanacağını anlatan bir README.
• Ana akış kontrol listesi ve otomatik testler.
• Kısa bir mimari not: ön yüz, arka uç, veritabanı, üçüncü taraf hizmetler ve her birinin nerede barındırıldığı.
• Erişim listesi: alan adı, barındırma, veritabanı, ödeme ve e-posta hesaplarında kimin yönetici erişimi olduğu. Bu hesapları kişisel değil, bir iş e-postası altında tutun.
• Kod Git'te, ideal olarak size ait bir depoyla senkronize. Barındırmayı daha sonra taşımayı düşünüyorsanız, yapay zekâ ile yapılmış bir uygulamayı nasıl dışa aktarıp kendi sunucunuzda barındırırsınız rehberini okuyun.

Yapay zekâ bunun çoğunu sizin için taslak olarak hazırlayabilir:

Bu projeyi hiç görmemiş bir geliştirici için bir README yaz: uygulamanın ne yaptığı, teknoloji yığını, yerelde nasıl çalıştırılacağı, okuduğu her ortam değişkeni (yalnızca adları ve amacı), veritabanı şemasının nasıl düzenlendiği ve nasıl yayınlanacağı.

Canlıya hazır olma kontrol listesi

• Ana akışlar yazılı ve test edilmiş, “başkasının verisine erişilemez” dahil
• Her veri rotasında sunucu tarafı yetkilendirme ve doğrulama
• Ön yüz kodunda gizli anahtar yok; sızan anahtarlar değiştirildi
• Kimlik doğrulama ve para harcayan her şeyde hız sınırları
• Hata takibi ve çalışma süresi uyarıları, okuduğunuz bir gelen kutusuna yönlendirilmiş
• Veritabanı yedekleri uygulamanın barındırma alanı dışında, bir başarılı geri yükleme testiyle
• Gerçekçi verilerle kontrol edilmiş sayfalama ve indeksler
• Özel alan adı, doğrulanmış gönderim alan adı, gizlilik politikası
• Sıradaki kişi için README ve erişim listesi

Mythex ile bunu yapmak

Protipi Mythex'te oluşturduysanız, bu adımların çoğu aynı projedeki istemlerdir. /test yazın; Mythex canlı önizlemede bir kullanıcı gibi gezinir ve bozuk akışları bildirir — bkz. Uygulama testi. Anahtarlar sohbete değil proje gizli bilgilerine girer; başarılı her agent turu dosyalarınızın bir kontrol noktasını kaydeder ve buna geri dönebilirsiniz. Yayınlamak size canlı bir URL verir; barındırma ve veritabanı aynı kredi bakiyesinden faturalandırılır (barındırma limitleri uygulamaların ve veritabanlarının nasıl uyuyup uyandığını açıklar). Kontrol noktaları dosyaları kapsar, veritabanı satırlarını değil; bu yüzden yine de veri yedeklerinizi planlayın. Pro planda özel bir alan adı bağlayabilir, kodu dışa aktarabilir ya da devir için kendi GitHub deponuzla senkronize edebilirsiniz.

Sorular