Yapay zeka geliştirmede günler kazandıran insan inceleme kontrol noktaları

Neden 5 dakikalık insan incelemeleri çok zaman kazandırır

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:

• Veri şeması: yanlış tipler, eksik kısıtlar, kafa karıştırıcı isimler, eksik indeksler.
• Yetki ve izinler: kullanıcılar görmemesi/duzenlememesi gerekeni görebilir ya da adminler işlerini yapamaz.
• Yıkıcı işlemler: silme/üstüne yazma/toplu güncellemeler çok kolay çalışıyor ve kurtarma yok.
• Dağıtım ayarları: yanlış env değişkenleri, geliştirme/üretim verisinin karışması, özensiz gizli anahtar yönetimi, domain yanlış konfigürasyonu.

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.

Basit bir 5 dakikalık checkpoint rutini

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.

Rutinin kendisi

1. Değişikliği bir cümleyle adlandırın (kullanıcılar artık ne yapabiliyor?).
2. Patlama yarıçapını kontrol edin (hangi veri, roller ve ortamları etkiliyor?).
3. Riskli kenarları tarayın (şema, yetki kuralları, yıkıcı işlemler, deploy ayarları).
4. Bir gerçeklik testi çalıştırın (çalıştığını kanıtlayan en basit akış).
5. Karar verin: devam et, prompt'u ayarla ve yeniden üret, ya da geri al.

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.

Şema sağlığı: veri problemlerini erkenden yakalayın

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ı:

• İsimler gerçeği yansıtıyor: tablolar konuştuğunuz şeyleri temsil etmeli (users, invoices, subscriptions).
• İsimler okunaklı ve tutarlı: bir stil seçin (created_at vs createdAt) ve ona sadık kalın.
• İlişkiler eksiksiz: birden-çeğe vs çoktan-çoğa doğru yerde kullanılmış.
• Kısıtlar kasıtlı: zorunlu alanlar nullable olmasın, zarar veren çoğaltmalar (email, invoice_number) engellensin, durum alanlarının tanımlı bir kümesi olsun.
• Büyüme uygulamayı bozmaz: yaygın aramalar için indeksler var ve büyük blob'ları yanlış yerde saklamıyorsunuz.

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 kuralları: kim ne yapabilir (ve nasıl doğrulanır)

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:

• Her rol için ana nesnelerde create/read/update/delete'i doğrulayın.
• Sahiplik kontrolü: kullanıcılar yalnızca kendi kayıtlarını görmeli, açıkça paylaşılmadıkça.
• Bir tahmin denemesi yapın: bir ID değiştirerek başka bir kullanıcının öğesini açın.
• Yöneticiye özel işlemlerin gerçekten sadece admin’lerde olduğundan emin olun (faturalama, dışa aktarma, kullanıcı yönetimi).
• Gizli erişimleri kaçırmayın: listeleme endpoint'leri, arama, indirmeler.

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: kazara veri kaybını önleyin

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:

• Tehlikeli işlemler için açık onay (type-to-confirm en iyisidir).
• Kapsamın sınırlandırılması (tek kayıt, tek kullanıcı, tek workspace) — kolay bir “tümünü” değil.
• Kimin tetiklediğini ve neyin etkilendiğini loglama.
• Güvenli varsayılanlar: dry run, önizleme veya arşivleme yerine silme.

Ç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.

Dağıtım ayarları: küçük konfig hataları yangın çıkarır

Ç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ü:

• Dev ve prod farklı veritabanları ve anahtarlar kullanıyor.
• Gizli anahtarlar kodda değil, deploy sırasında enjekte ediliyor.
• Originler, yönlendirmeler ve callback'ler gerçek domain ile eşleşiyor.
• Özel domain temel ayarları doğru (DNS doğru yerde, HTTPS bekleniyor).
• Üretim logging ve hata raporlaması açık (hassas veri loglamadan).

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.

Merge öncesi 60 saniyelik kontrol listesi

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.

• Şema: Varlıklar mantıklı mı? İlişkiler doğru mu? Kısıtlar var mı (unique, not null)? Büyüme sorguları veya depolamayı bozacak mı?
• Yetki: Varsayılan-inkar mı? Her kaynağı kimlerin create/read/update/delete yapabildiğini açıklayabiliyor musunuz? Sahiplik kontrolleri sunucu tarafında mı (sadece UI'da değil)?
• Yıkıcı işlemler: Geri alınamaz işlemler için onay var mı? Soft delete kullanılmalı mı? Geri alma planı (snapshot, backup, reversible migration) var mı?
• Dağıtım: Dev ve prod ayrılmış mı? Gizli anahtarlar koddaki değil mi? Domain ve yönlendirmeler doğru mu?

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.

Örnek: haftalar süren temizliği önleyen 5 dakikalık inceleme

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:

1. Veritabanı değişikliği cascade delete kullanıyor ve faturalar ile aktivite loglarını da siliyor. Test verisi için sorun olmayabilir ama gerçek CRM'de raporlama, denetimler ve müşteri geçmişi zarar görür.
2. Endpoint sadece kullanıcının giriş yapmış olduğunu kontrol ediyor, admin rolü kontrolü yok. Herhangi bir personel herhangi bir müşteriyi silebilir.

Pratikte hızlı bir inceleme:

• Non-admin bir test kullanıcıyla butona tıklayın ve başarısız olduğunu doğrulayın.
• Endpoint'i kontrol edin ve yetkisi olmayan kullanıcıları reddettiğini onaylayın.
• Şemayı tarayın ve faturalar, notlar ve loglara ne olduğuna bakın.
• UI'nın onay isteyip istemediğini ve hangi verilerin silineceğini gösterip göstermediğini doğrulayın.
• Denemeden önce doğru veritabanına test yaptığınızdan emin olun.

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).

Değişiklikleri kabul etmeden önce netlik zorlayan prompt'lar

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:

• “Veri modeli değişikliklerini önce/sonra tablosu olarak gösterin. Her alan için: tip, nullability, default ve migration riski.”
• “Tanıttığınız tüm yıkıcı operasyonları listeleyin (drop table/column, delete endpoint'leri, cascade kuralları). Her biri için nasıl geri alınır ve hangi veriler kaybolur gösterin.”

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:

• Yetki kuralları ve admin aksiyonları
• Silmeler, cascade'ler, geri döndürülemez migration'lar
• Ortam ve dağıtım ayarları (prod vs staging)
• Ödeme, e-posta ve kullanıcı veri akışları
• Geri alma planı (snapshot veya release point)

Günler süren temizlemeye yol açan yaygın hatalar

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:

• Kısıtlar olmadan şema değişiklikleri (unique, not null, foreign keys)
• Sadece UI'da olan izin kuralları yerine sunucu tarafı kontrollerin olmaması
• Onay ve kurtarma olmadan delete endpoint'leri
• Staging ve prod'u “neredeyse aynı” saymak
• Kim neyi değiştirdiğine dair kayıt olmaması

Sonraki adımlar: checkpoint'leri nasıl çalışma şeklinizin bir parçası yaparsınız

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:

• İnşa etmeden önce: veri şekli üzerinde anlaşın (tablolar, anahtar alanlar) ve roller (kim neyi create/read/update/delete edebilir).
• Merge’den önce: auth, yıkıcı işlemler ve üretim verisine dokunan her şey için 60 saniyelik kontrolü yapın.
• Dağıtımdan önce: ortam ayarlarının (domainler, gizliler, e-posta, depolama, bölge) hedefle eşleştiğini onaylayın.
• Dağıtımdan sonra: gerçek bir kullanıcı akışını baştan sona çalıştırın.

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.