Yapay zeka geliştirmede insan inceleme kontrol noktaları: şema doğruluğu, yetki kuralları, veri silme-riskleri ve dağıtım ayarları için 5 dakikalık kontroller; sorun çıkmadan önce yakalayın.
AI destekli geliştirme anlık gelebilir. Bir özelliği tanımlarsınız, çalışan bir ekran elde edersiniz ve uygulama bitmiş gibi görünür. Sorun şu ki küçük detaylar genellikle uç durumlarda başarısız olur: gerçek veriler, gerçek izinler, gerçek üretim ayarları. Bu “ufak” eksikler tam da bir haftalık temizlik gerektiren sorunlara dönüşür.
Bir checkpoint, bir değişikliği kabul etmeden veya yayınlamadan önce yapılan kısa insan duraklamasıdır. Toplantı değil, uzun bir QA döngüsü de değil. Hedefli bir 5 dakikalık taramadır: bunu yanlış yapsak en çok ne kırılır?
Çoğu acı veren temizlik dört yüksek riskli alandan gelir:
Kısa bir duraklama işe yarar çünkü bu problemler kesişkendir. Küçük bir şema hatası API'lere, ekranlara, raporlara ve migration'lara dalga dalga yayılır. Bir izin hatası güvenlik olayına dönüşebilir. Kötü bir dağıtım ayarı kesintiye neden olabilir.
Elle kod yazıyor olun ya da Koder.ai gibi bir vibe-coding aracı kullanıyor olun, kural aynı: hızlı ilerleyin ama zarar büyük olan yerlerde küçük güvenlik halatları ekleyin.
Checkpoint'ler en iyi öngörülebilir olduğunda çalışır. Her şeyi incelemeyin. Geri döndürülmesi pahalı olan birkaç şeyi inceleyin.
Her zaman checkpoint tetikleyecek anları seçin: bir özelliği bitirdikten sonra, dağıtımdan hemen önce ve veriye, yetkiye, faturalamaya veya üretim odaklı herhangi bir refactor’dan hemen sonra.
Bir zamanlayıcıyı 5 dakika için ayarlayın. Süre dolduğunda durun. Gerçek bir risk bulduysanız uzun bir takip planlayın. Bulmadıysanız daha güvenle yayınlayın.
Bir inceleyici rolü atayın, hatta bu “ilerideki siz” olsa bile. Onaylıyor gibi davranın; daha sonra rahatsız edemeyeceğiniz bir ekip arkadaşınız için onaylıyormuş gibi düşünün.
Küçük bir şablon tutarlı kalmanıza yardımcı olur:
Change:
Risky areas touched:
1 quick test to run:
Decision (proceed / adjust prompt / rollback):
Eğer Koder.ai üzerinde çalışıyorsanız, son adımı bilerek kolaylaştırın. Snapshots ve rollback “emin değilim”i güvenli bir karara çevirir.
Günleri kaybetmenin en hızlı yolu, kasıtlı olarak tam eşleşmeyen bir veritabanı şemasını kabul etmektir. Küçük veri hataları her ekrana, API'ye, rapora ve migration'a yayılır.
Önce temel varlıkların gerçek dünya ile uyup uymadığını kontrol edin. Basit bir CRM genellikle Müşteriler, İletişimler, Fırsatlar ve Notlar gerekir. “ClientItem” veya “Record” gibi belirsiz isimler görüyorsanız zaten sapma başladı demektir.
Beş dakikalık bir şema taraması:
Küçük bir örnek: unique invoice_number olmayan bir Invoices tablosu demo için sorun gibi görünmeyebilir. Bir ay sonra kopyalar çıkar, ödemeler yanlış kayıtlara uygulanır ve siz temizlik scriptleri ve özür e-postaları yazarsınız. İncelemede yakalamak 30 saniyelik bir düzeltmedir.
Sadece bir soru soracak olsanız bu olsun: şemayı yeni bir ekip arkadaşına iki dakikada açıklayabilir misiniz? Cevap hayırsa, üzerine inşa etmeden önce sıkılaştırın.
Yetki hataları pahalıdır çünkü mutlu senaryo demoları bunları gizler. İki yaygın başarısızlık “herkes her şeyi yapabilir” ve “hiç kimse bir şey yapamaz”dır.
Rolleri düz metinle yazın: admin, staff, customer. Uygulamanızda ekipler varsa workspace member ve workspace owner ekleyin. Bir rolü bir cümlede açıklayamıyorsanız kurallar sarpa sarar.
Sonra bir kural uygulayın: varsayılan olarak en az erişim. Yeni roller başlangıçta erişimsiz veya salt okunur olmalı ve tam olarak ihtiyaç duydukları şeyleri almalı. AI tarafından üretilen kod genellikle izinleri gevşek başlatır çünkü testleri geçirmesi kolaydır.
Hızlı doğrulama için küçük bir erişim matrisi kullanın ve bunu UI ve API'de gerçekten deneyin:
Sahiplik kontrolleri özel dikkat ister. “Kullanıcı Task okuyabilir” yeterli değil. Olması gereken: “kullanıcı Task okuyabilir where task.ownerId == user.id” (veya kullanıcı workspace'e aittir).
Uç durumlar sızıntıların çıktığı yerdir: davet edilmiş ama kabul etmemiş kullanıcılar, silinmiş hesaplar, eski oturumlu kaldırılmış workspace üyeleri. Bir kaçırılan uç durum bir haftalık temizlik anlamına gelebilir.
Koder.ai kullanıyorsanız, asistanın değişiklikleri kabul etmeden önce roller ve bir erişim tablosu üretmesini isteyin, sonra her rol için iki test hesapla doğrulayın.
Yıkıcı işlemler küçük bir hatayı günler süren bir temizliğe dönüştürmenin en hızlı yoludur.
Önce veriyi silebilecek veya üzerine yazabilecek her şeyi listeleyin. Bunlar sadece silme butonları değildir; reset, sync, import/replace, rebuild index, seed eylemleri ve geniş admin araçları da dahil.
Birkaç net güvenlik sinyaline bakın:
Çoğu kullanıcı verisi için soft delete tercih edin. Basit bir deleted_at alanı artı filtreleme geri alma imkanı sağlar ve bir hata çıktıysa zaman kazandırır.
Şema değişikliklerini de potansiyel olarak yıkıcı sayın. Sütun düşürme, tip değiştirme ve kısıt sıkılaştırma veri kaybedebilir. AI bir migration önerdiyse sorun: mevcut satırlara ne olur ve nasıl geri yüklenir?
Geri alma planını bir cümlede açıklayamıyorsanız, yıkıcı değişikliği hemen göndermeyin.
Çoğu temizlik hikâyesi aynı şekilde başlar: uygulama dev ortamında çalıştı, sonra üretim farklı davrandı.
Geliştirme ve üretimi kasıtlı olarak ayırın: farklı veritabanları, anahtarlar, bucket'lar ve e-posta sağlayıcıları. Eğer her iki ortam aynı veritabanına işaret ediyorsa, bir test scripti gerçek veriyi kirletebilir ve “hızlı sıfırla” gerçek veriyi silebilir.
Sonra gizli anahtarlara bakın. Bir config dosyasında, prompt'ta veya commit mesajında anahtar görürseniz sızacağını varsayın. Gizli anahtarlar deploy sırasında (env var veya secrets manager) enjekte edilmeli. Üretim, gerekli bir gizli eksikse başlamamalı — bu sessiz bir fallback'ten daha ucuzdur.
Tarayıcı tarafı ayarlarını doğrulayın: allowed origins (CORS), yönlendirme URL'leri, OAuth callback'ler. Bunlar neredeyse doğru olmaya çok eğilimlidir ve bu yüzden “bozuk giriş” hatalarını kod düzgünken bile debuglarsınız.
Beş dakikalık bir dağıtım kontrolü:
Koder.ai'den dağıtıyorsanız, doğru ortamı yayınladığınızı ve yanlış görünürse geri alma seçeneğinin olduğunu bu aşamada onaylayın.
AI tarafından üretilen bir değişikliği kabul edip yayınlamadan önce bir dakika durun. Stil değil, uzun temizlemelere dönüşecek hataları arıyorsunuz.
Bir örnek: “admin kullanıcısını sil” özelliğini merge ediyorsunuz. 60 saniyede backend'de rol kontrolü olmadığını görürsünüz, sadece gizli bir UI butonu var. Gerçek bir kullanıcı endpoint'i doğrudan çağırabilir. Bu tek yakalama sizi bir olaydan kurtarır.
Gerçekliği zorlayan bir soru ile bitirin:
Burada gerçek bir kullanıcı kasten veya kazara en kötü ne yapabilir?
Cevap “başkalarının verisini silmek”, “özel kayıtları görmek” veya “prod'u bozmak” içeriyorsa, durun ve değişikliği sıkılaştırın.
Küçük bir CRM inşa ediyorsunuz ve AI aracıdan müşteri sayfasına “Müşteriyi sil” butonu eklemesini istediniz. Birkaç dakika içinde UI, backend endpoint ve ilgili kayıtları kaldıran bir veritabanı değişikliği üretti.
Her şey çalışıyor gibi görünüyor: buton görünüyor, istek 200 dönüyor ve müşteri listeden kayboluyor. Birçok ekip devam eder.
5 dakikalık bir inceleme iki problemi yakalar:
Pratikte hızlı bir inceleme:
Bir prompt düzenlemesi ile gemideyken düzeltilir:
“Delete customer'ı soft delete yap. Faturalar ve loglar saklansın. Sadece adminler silebilsin. Onay adımı olarak DELETE yazılmasını iste. Yetkisiz olduğunda net bir hata mesajı dön.”
Tekrar bozulmasını önlemek için proje notlarına üç şeyi yazın: silme kuralı (soft vs hard), izin gereksinimi (kim silebilir) ve beklenen yan etkiler (hangi ilişkili veriler kalır).
AI çıktısı kendinden emin gelebilir ama varsayımları gizleyebilir. Amaç bu varsayımları görünür kılmak.
Takip sorularını tetiklemesi gereken kelimeler: “assume”, “default”, “simple”, “should”, “usually”. Bunlar genellikle “uygunluğunu doğrulamadan bir seçim yaptım” anlamına gelir.
Faydalı prompt kalıpları:
“Teklifinizi kabul kriterleri olarak yeniden yazın. İçer–gerekli alanlar, hata durumları ve 5 uç durumunu dahil edin. Eğer varsayımlar yaptıysanız listeleyin ve onayımı isteyin.”
Hızı artıran iki başka prompt:
Yetki için:
“Her API rotası ve UI aksiyonu için roller ve izinleri gösterin. Her rol için: izin verilen aksiyonlar, reddedilen aksiyonlar ve başarısız olması gereken bir örnek istek.”
Hangi konuların her zaman insan tarafından doğrulanması gerektiğine karar verin ve kısa tutun:
Uzun temizliklerin çoğu aynı küçük tercihten başlar: çıktı çalıştığı için güvenmek.
“Benim makinemde çalışıyor” klasik tuzaktır. Bir özellik yerel testleri geçebilir ama gerçek veri boyutları, gerçek izinler veya biraz farklı bir ortamla başarısız olabilir. Düzeltme acil yamalar yığınına dönüşür.
Şema sürüklenmesi diğer bir mıknatıs. Tablolar net isimler, kısıtlar ve default'lar olmadan evrildiğinde bir dizi özel migration ve garip geçici çözümler ortaya çıkar. Sonra biri “status ne anlama geliyor?” diye sorar ve kimse yanıt veremez.
Yetki sonradan eklenirse ağrılıdır çünkü varsayımları yeniden yazdırır. Her şeyi herkes yapabilir şekilde kurarsanız, rastgele endpoint'ler ve ekranlar boyunca haftalarca delikleri kapatırsınız.
Yıkıcı işlemler en yüksek sesli felaketlere yol açar. “Projeyi sil” veya “veritabanını sıfırla” kolay uygulanır ama soft delete, snapshot veya geri alma planı yoksa kolayca pişman olunur.
Birkaç tekrar eden neden:
Checkpoint'leri kalıcı kılmanın en kolay yolu, zaten yaptığınız anlara eklemektir: bir özelliğe başlama, merge etme, dağıtma ve doğrulama.
Hafif bir ritim:
Koder.ai ile çalışıyorsanız, planlama modu “inşa etmeden önce” checkpoint'i olarak hizmet edebilir: “siparişler giriş yapmış kullanıcı tarafından oluşturulabilir, ancak sadece admin durum değiştirebilir” gibi kararları üretmeden önce yazın. Snapshots ve rollback ayrıca “emin değilim”i güvenle geri almak için daha kolay hale getirir.
Beş dakika her şeyi yakalamaz. Ancak pahalı hataları onlar hâlâ ucuzken güvenilir şekilde yakalar.
Özellik üretildikten hemen sonra, dağıtımdan hemen önce ve veriye, yetkiye, faturalamaya veya üretim ayarlarına dokunan herhangi bir değişiklikten sonra bir checkpoint kullanın. Bu anlar en büyük "patlama yarıçapına" sahip, bu yüzden küçük bir inceleme pahalı hataları erken yakalar.
Beş dakikalık bir zamanlayıcı ayarlayın ve her seferinde aynı adımları uygulayın: değişikliği bir cümleyle tanımlayın, neleri etkilediğini kontrol edin (veri, roller, ortamlar), dört riskli alanı tarayın, tek bir basit gerçeklik testini çalıştırın ve sonra devam etme, prompt'u düzeltme veya geri alma kararı verin.
Çünkü hatalar çapraz kesitlidir. Küçük bir şema hatası API'lere, ekranlara, raporlara ve migration'lara yayılabilir; daha sonra düzeltmek genellikle birden fazla katmanı yeniden yazmayı gerektirir. Değişiklik taze iken yakalamak genellikle hızlı bir düzenlemeyle çözülür.
Tabloların ve alanların gerçek dünya kavramlarıyla eşleştiğini doğrulayın, isimlendirme tutarlı olsun, ilişkiler eksiksiz olsun ve kısıtların kasıtlı olduğundan emin olun (not null, unique, foreign key). Ayrıca sık kullanılan sorgular için indeksleri kontrol edin ki veri büyüdüğünde performans çökmesin.
UI'nin doğru söylediğini varsaymayın ve sunucu tarafı kurallarını test edin. Roller açık ifadelerle tanımlansın, başlangıçta en az yetki verilsin ve sahiplik kontrollerini sunucu tarafında doğrulayın—başka bir kullanıcının kaydına ID değiştirerek erişmeyi deneyin. Listeleme/arama/indirme endpoint'lerini de kontrol edin, sadece ana ekranları değil.
Veriyi silebilecek veya üzerine yazabilecek her işlemi listeleyin: import, reset, toplu güncellemeler, rebuild, seed komutları ve geniş admin araçları dahil. Tehlikeli işlemler için açık onay isteyin (type-to-confirm en iyisi), etki alanını dar tutun, kim tetiklediğini loglayın ve kullanıcı verileri için soft delete tercih edin.
Çoğu iş verisi için varsayılan olarak soft delete kullanın; böylece kazaları geri alabilir ve hataları araştırabilirsiniz. Kalıcı silme yalnızca gerçekten gerekli olduğunda kullanılsın ve üretime göndermeden önce geri alma planını bir cümleyle açıklayabildiğinizden emin olun.
Geliştirme ve üretim için farklı veritabanları ve anahtarlar kullanın, gizli anahtarları kodda bırakmayın ve dağıtım zamanında enjekte edin. CORS, yönlendirme URL'leri ve OAuth callback'lerin gerçek domainle eşleştiğini doğrulayın. Ayrıca üretimde logging ve hata raporlamayı açın ama hassas verileri loglamamaya dikkat edin.
Bunu bir güvenlik ağı olarak görün, düşünmenin yerine geçmesin. Riskli değişiklikler öncesi anlık görüntü (snapshot) alın; inceleme gerçek risk bulursa hemen geri alın ve eksiklikleri giderip daha net bir prompt ile yeniden üretin.
Bir dakikalık tarama için maliyetli hatalara odaklanın: şema açıklığı ve kısıtlar, varsayılan-inkar (default-deny) yetki ve sunucu tarafı kontroller, geri alınamaz işlemler için onay ve kurtarma ve dev/prod ayrımının temiz olması. Bitirirken şunu sorun: gerçek bir kullanıcının burada yapabileceği en kötü şey ne? Eğer cevap veri kaybı, veri sızıntısı veya üretimi bozmak ise, durun ve sıkılaştırın.