Yapay zeka ile geliştirdiğin uygulamayı nasıl yedeklersin — ve neden gerçekten yedeklemen gerekiyor

Konuştuğum bir kurucu, bütün rezervasyon işini — üç lokasyon, haftada yaklaşık 200 müşteri — bir yapay zeka uygulama oluşturucu ile kendi geliştirdiği bir uygulama üzerinde yürütüyor. Onu bana bir salı günü gösterdi ve çok gururluydu. Çarşamba günü, biraz gergin bir şekilde sordu: “Bu şey bozulursa, ben sadece… her şeyi mi kaybederim?”

Dürüst cevap şuydu: belki. “Bozulmak” derken ne kastettiğine bağlı. Ne tür bir yedeği olduğuna bağlı (hiç yedeği yoktu). Onu zamanında yeniden oluşturup oluşturamayacağına bağlı.

O konuşma, yapay zeka ile uygulama geliştirmiş insanlarla yaptığım en yaygın konuşmadır. Geliştirmenin kendisi küçük bir mucize gibi hissettiriyor. “Yok olursa ne olur” sorusu, uygulama zaten gerçek bir iş yapana kadar neredeyse hiç gündeme gelmez — ve o zamana kadar onu kaybetmenin sonuçları ciddileşmiş olur.

Bu yazı, kod yazmadan gerçek, çalışan bir uygulama geliştirmiş ve şimdi önemli bir şey için ona güvenen herkes için. Gerçekte neyin risk altında olduğunu, neyi yedekleyeceğini, ne sıklıkla ve bir şey ters gittiğinde ne yapacağını ele alacağız. Teknik değil. Çalıştırılacak bir betik yok. Amaç, ne geliştirdiysen, kimse sana yedeklemenin bir şey olduğunu söylemedi diye onu kaybetmemeni sağlamak.

Yapay zeka ile geliştirdiğin uygulamanın içinde gerçekte ne var (ve ne yok olabilir)

Yapay zeka ile geliştirilen bir uygulama çok farklı iki şeyden oluşur ve her birini farklı şekilde yedeklemen gerekir.

Birincisi uygulamanın kendisi — ekranlar, mantık, tasarım, entegrasyonlar. Bu, yapay zeka oluşturucunun senin için ürettiği şey. Yapay zeka oluşturucunun hesabında, genellikle bir projenin içinde yaşar. O hesaba erişimini kaybedersen, oluşturucu bir kesinti yaşarsa ya da proje bozulursa, bunu kaybedersin.

İkincisi verin — kullanıcılar, siparişler, mesajlar, rezervasyonlar, insanların yüklediği dosyalar. Bu genellikle bir yerde bir veritabanında yaşar. Bazen yapay zeka oluşturucunun içindedir. Bazen Supabase, Firebase ya da Airtable gibi bir serviste. Bazen birden çok yere dağılmıştır.

Bu iki şeyin tamamen farklı risk profilleri var. Uygulama yapısı, yapay zekadan değiştirmesini istediğinde değişir. Verin, bir kullanıcı her bir şey yaptığında değişir. Yani farklı yedekleme stratejileri gerektirirler.

Bunu düşünmenin yararlı bir yolu: bir bina yansa, uygulama plan, veri ise yandığında binanın içinde olan şeydir. Plandan yeniden inşa edebilirsin. İçeride olanı geri alamazsın.

Neyin risk altında olduğu: gerçekten olan dört senaryo

Yapay zeka uygulama oluşturucularıyla geliştiren insanların başına bunların her birinin geldiğini gördüm. Hiçbiri teorik değil.

1. Yanlışlıkla yapay zekaya uygulamayı bozmasını söylersin. Yorgunsun, gece yarısı çalışıyorsun ve “kullanıcı kayıt sayfasını kaldır” diyorsun çünkü onu yeniden tasarlamak istiyorsun. Yapay zeka kaldırıyor. Aynı zamanda mevcut kullanıcıların giriş yapmasını sağlayan kısmı da kaldırıyor. Şimdi kimse uygulamayı kullanamıyor ve sürüm geçmişini açmadıysan (çoğu oluşturucu varsayılan olarak açmaz) yapay zekanın son çalışan sürümü gitti.

2. Yapay zeka oluşturucu bir kesinti ya da veri sorunu yaşar. Nadir ama gerçek. 2024’te popüler bir kodsuz platform, müşteri verisine erişilemeyen 6 saatlik bir kesinti yaşadı. Kimse verisini kalıcı olarak kaybetmedi ama pek çok işletme bir gününü kaybetti. Rezervasyon uygulaman, müşterilerin cumartesi öğleden sonrası için randevu almaya çalıştığı bir cumartesi sabahı çökmüşse, bu “veri kaybı yok” değil — bu, geri alamayacağın kayıp gelir.

3. Hesabın kilitlenir. Belki bir faturalandırma sorunu, belki yeni bir konumdan işaretlenen bir giriş, belki yayılmayan bir e-posta değişikliği. Uygulama iyi, verin iyi ama içine giremiyorsun. Dışa aktarılmış bir kopyan yoksa, destek yanıt sürelerinin insafına kalmışsındır.

4. Platformdan ayrılırsın. İnsanların planlamadığı şey bu. Bir yıl sonra farklı bir araca geçmek ya da geliştirdiğin şeyi devralması için bir geliştirici tutmak isteyebilirsin. Uygulamanın ve verinin tek kopyası tek bir oluşturucunun içinde yaşıyorsa, seçeneklerin dar ve pahalıdır.

Bu senaryoların her birinde, “can sıkıcı” ile “felaket” arasındaki fark, bir yedeğinin olup olmamasıdır.

Neyi yedeklemeli ve ne sıklıkla

Süslü bir sisteme ihtiyacın yok. Bir alışkanlığa ihtiyacın var. Kod yazmadan yapay zeka ile geliştiren biri için önerdiğim asgari şu.

Verin — her gün, mümkünse otomatik olarak.

Verin Supabase ya da Airtable gibi bir şeyde yaşıyorsa, ikisi de zamanlanmış dışa aktarımlar ya da yedeklemeler sunuyor. Bunu aç. Çoğu insan bunu atlıyor çünkü üç tıklama ve sonra yaparım diye düşünüyorlar. Yayına aldığın gün yap.

Verin yapay zeka oluşturucunun içinde yaşıyorsa ve otomatik dışa aktarım yoksa, her pazar elle dışa aktarmak için bir takvim hatırlatıcısı kur. Tablo başına bir CSV olarak dışa aktar. Onu oluşturucunun dışında bir yere kaydet — Google Drive, Dropbox, harici bir sabit disk. Aynı servis olmayan herhangi bir yere.

Bu dışa aktarımların en az dört haftalık kısmını sakla. Her seferinde aynı dosyanın üzerine yazma. Verin salı günü bozulur ve cumaya kadar fark etmezsen, tek yedeğinin cumanın zaten bozuk verisi olmasını istemezsin.

Uygulama yapın — önemli bir değişiklik yaptığın her seferinde.

Çoğu yapay zeka uygulama oluşturucusunun bir tür sürüm geçmişi ya da anlık görüntüsü var. Bu özelliği bul. Kullan. Uygulamada büyük bir değişiklik yapmadan önce — ve “büyük”, “bir saatte hafızandan yeniden yapamayacağın bir şey” demek — adlandırılmış bir anlık görüntü al. Ona “ödeme ekranı eklemeden önce” ya da “kullanıcı rollerini değiştirmeden önce” gibi yararlı bir şey de.

Oluşturucunun anlık görüntüsü yoksa, yapay zekadan uygulamanın ne yaptığını uzun bir belgede özetlemesini iste. O belgeyi kaydet. Uygulamanın gerçek bir yedeği değil ama bir tarif — en kötüsü olursa, o belgeyi yeniden inşa etmek için bir istem olarak kullanabilirsin.

Hesapların ve kimlik bilgilerin — bir kez, yayına aldığın gün.

Her şeyin nerede yaşadığını tek bir yere yaz. Hangi oluşturucu hesabında uygulama var. Hangi veritabanı servisinde veri var. Hangi e-posta yönetici girişi. Hangi ödeme işlemcisi bağlı. Hangi entegrasyonlar bağlı.

Bunu bir Google Doc’a değil, bir şifre yöneticisine kaydet. Yarın seni bir otobüs çarparsa, iş ortağının bütün bunları bulabilmesi gerek. Tek kişilik bir kurucuysan, gelecekteki kendin de (altı ay sonra, bitkin, yayına alırken ne yaptığını hatırlamaya çalışırken) bunu bulabilmek zorunda.

Dosyaların — kullanıcıların nereye yüklediyse oraya.

Uygulaman dosya yüklemelerini kabul ediyorsa — görseller, PDF’ler, herhangi bir şey — o dosyalar bir yerde yaşar. Nerede olduğunu bul. Çoğu oluşturucu bir tür depolama kovası kullanır. Yedeklenip yedeklenmediğini kontrol et. Yedeklenmiyorsa, kendi depolamana periyodik bir kopya kur.

Haftada yaklaşık 20 dakika süren basit bir yedekleme rutini

Pazar akşamı, zaten çalışmadığın bir sırada:

1. Yapay zeka oluşturucunu aç. Mevcut uygulama durumunun adlandırılmış bir anlık görüntüsünü al. Tarih at.
2. Her veri tablosunu CSV olarak dışa aktar. Onları bulut depolamandaki tarihli bir klasöre bırak. (Çoğu veri 3–10 tabloda yaşar — büyük bir iş değil.)
3. Depolama kovana göz at. Garip bir şey olmadığından emin ol (dosya sayısı patlaması, şüpheli yüklemeler).
4. Bu hafta bir şey değiştiyse “her şeyin nerede yaşadığı” belgeni güncelle.

Hepsi bu. Haftada bir kez, yirmi dakika. Koruduğu şey için son derece orantısız bir sigorta.

Bunu elle yapmak istemiyorsan, verinin yerel yedeklemesi olan bir yerde yaşayıp yaşamadığına bak. Örneğin Supabase senin için otomatik günlük yedeklemeler yapabilir. Ücretsiz katmanlarını kullanıyorsan o yedeklemeler sınırlı; ücretli bir planda daha geriye giderler. Uygulamaya bağımlı bir işletme için, o ücretli plan alacağın en ucuz sigortadır.

Bir şey ters gittiğinde ne yapmalı

Uygulaman bir yapay zeka oluşturucu hatası ya da kötü bir değişiklik yüzünden bozulursa:

• Panikle istem yapma. İçgüdü, yapay zekadan hemen düzeltmesini istemek olacak. Buna on dakika direnci. Yanlış yönde panikle yapılmış bir düzeltme işleri daha kötü hale getirebilir ve çoğu oluşturucu bir istem zincirini kolayca geri almaz.
• Son anlık görüntüne geri dön. Eğer varsa. Onu almanın bütün sebebi bu.
• Anlık görüntün yoksa, yapay zeka oluşturucudan son belirli değişikliği geri almasını iste. Kesin ol. “Kayıt sayfasını kaldırdığımız değişikliği geri al” “tekrar çalışır hale getir”den daha iyidir.

Verin bozulursa:

• Yazmaları hemen durdur. Yapabiliyorsan uygulamayı çevrimdışı al. Verin bozukken yapılan her yeni kullanıcı eylemi, daha sonra uzlaştırman gereken daha fazla veridir.
• En son iyi yedeğinden geri yükle. Hangisinin iyi olduğunu bilmiyorsan, son temiz sürümü bulana kadar onları teker teker ortamının bir kopyasına geri yükle.
• Eksik olanı uzlaştır. Cuma günü pazarın yedeğini geri yüklersen, beş günlük etkinliği kaybetmişsindir. Etkilenen kullanıcılara e-posta gönder, yaptıklarını yeniden yapmalarını iste ve özür dile. İnsanlar, dürüst ve hızlı olduğunda şaşırtıcı derecede anlayışlıdır.

Hesabına erişimini kaybedersen:

• Hemen destekle iletişime geç. “Bekleyip görelim” deme. Oluşturucu destek kuyrukları değişir; bazıları harika, bazıları yavaş.
• Kimliğini hazır tut. Orijinal kayıt e-postası, faturalandırma kartı bilgileri, kaydolduğun tarih, eski faturalar. Bunlar olmadan hesap kurtarma zordur.

Kimsenin o kurucuya söylemediği şey

Bu yazıya birlikte başladığım rezervasyon kurucusu, konuştuktan sonra veri servisi için ücretli bir plan aldı. Otomatik günlük yedeklemeler kurdu. Uygulamasının bir anlık görüntüsünü aldı. Bütün hesaplarını bir şifre yöneticisine yazdı. Tüm bu işi bir pazar günü yaklaşık bir saatte hallettı.

Bir ay sonra, istediği bir yapay zeka değişikliği, tekrarlanan rezervasyon mantığını yanlışlıkla bozdu. Müşteriler bir sonraki randevularını göremiyordu. Yirmi dakika içinde fark etti. Anlık görüntüyü iki tıklamayla geri yükledi. Veriyi korudu, uygulamayı korudu ve müşterileri hiçbir şey görmedi.

Sonradan bana harcadığı en ucuz saat olduğunu söyledi. Haksız değil. Yapay zeka ile geliştirilen bir uygulamanın yedeklemeleri, yaklaşık bir saatlik kurulum ve haftada yirmi dakikalık bir alışkanlık. Koruduğu şey, onu kaybeden hiç kimsenin başına geleceğini düşünmediği şeydir.

Gerçek bir şey geliştirdiysen, bugün bir anlık görüntü al.