Vibe coding güvenliği: Uygulamanı yayınlamadan önce kontrol etmen gereken 20 şey
Yapay zekâ hızlı kod yazar ama kapıları her zaman kilitlemez. Lovable, Bolt, Cursor, Claude Code ya da başka bir yapay zekâ aracıyla yapılan uygulamalar için 20 güvenlik kontrolü; her birinde hızlı bir test ve yapay zekâna verebileceğin bir istem var. 2025 ve 2026’daki gerçek olaylara dayanıyor.
··13 dk okuma
Yapay zekâ araçları hızlı kod yazıyor. ’ı her gün bir yapay zekâ kodlama ajanıyla geliştiriyorum ve eski yönteme dönmem. Ama uzun yıllar yazılım geliştirdikten sonra hız hakkında bir şey öğrendim: çalışan kod her zaman güvenli kod değildir.
Bir uygulama kusursuz görünebilir, tüm tıklama testlerini geçebilir ve yine de herhangi bir yabancının kullanıcılarının verilerini okumasına izin verebilir. Bu bir teori değil. 2025 ve 2026’da vibe coding ile yapılan birçok uygulamanın başına geldi.
O yüzden yayınlamadan önce bir öğleden sonranı ayır ve bu listeyi uygula. Her maddede neden önemli olduğu, birkaç dakikada nasıl kontrol edeceğin ve düzeltmek için yapay zekâ aracına verebileceğin bir istem var. Kullanmak için güvenlik uzmanı olman gerekmiyor.
Bu liste en yaygın sorunları kapsıyor, her şeyi değil. Uygulaman ödemeler, sağlık verileri ya da çocuklara ait veriler işliyorsa, ayrıca profesyonel bir güvenlik incelemesi için para öde.
Kısaca
Yapay zekânın ürettiği kodda sık sık güvenlik açıkları oluyor. Veracode’un 2025 çalışmasında 100’den fazla yapay zekâ modelinin yazdığı kodda görevlerin %45’inde güvenlik açığı vardı.
Gerçek hayatta en yaygın sorun basit: erişim kuralları hiç açılmadığı için herkesin okuyabildiği bir veritabanı.
İkinci en yaygın sorun, herkesin kopyalayabileceği tarayıcıdaki gizli anahtarlar.
Aşağıdaki 20 kontrolün çoğu 2 ila 10 dakika sürer. Listenin tamamı bir öğleden sonraya sığar.
Sonunda tek sayfalık, yazdırılabilir bir sürüm var.
Vibe coding nedir ve güvenlik neden önemli?
Vibe coding, kodu kendin yazmak yerine yapay zekâya ne istediğini normal bir dille anlatarak yazılım geliştirmek demek. Hızlı ve işe yarıyor. Risk şu: kodu okumadığında, eksik olanı da görmüyorsun. Bir erişim kuralı, bir yetki kontrolü, bir sınır. Yapay zekâ ne istersen onu yazar ve neredeyse kimse ondan güvenlik istemiyor.
Başkalarının başına neler geldi: gerçek olaylar
Bunlar seni korkutmak için burada değil. Her biri listeden bir maddeyi öğrettiği için burada.
Veritabanı açık 170 Lovable uygulaması (2025). Araştırmacı Matt Palmer, Lovable ile yapılmış 1.645 uygulamayı taradı ve Row Level Security düzgün kurulmadığı için bunlardan 170’inde (yaklaşık %10) yabancıların erişebildiği veritabanı uç noktaları buldu. Bu, CVE-2025-48757 oldu. Lovable bu CVE’ye itiraz ediyor ve her müşterinin kendi uygulamasının verilerinden sorumlu olduğunu söylüyor. Her durumda ders aynı: kendin kontrol et.
5.600 uygulamada 2.000’den fazla açık (Ekim 2025). Güvenlik şirketi Escape, vibe coding ile yapılmış 5.600’den fazla herkese açık uygulamayı taradı ve 2.000’den fazla güvenlik açığı, 400’den fazla açıkta kalmış gizli anahtar ve tıbbi kayıtlar ile banka hesap numaraları dahil 175 kişisel veri sızıntısı buldu. Üstelik bu sayıların bir alt sınır olduğunu söylüyorlar.
Moltbook: 1,5 milyon API anahtarı (Şubat 2026). Wiz araştırmacıları, yapay zekâ ajanları için vibe coding ile yapılmış bir sosyal ağ olan Moltbook’un ön yüz JavaScript’inde bir Supabase anahtarı olduğunu ve Row Level Security’nin hiç olmadığını buldu. Herkes tüm canlı veritabanını okuyup yazabiliyordu: 1,5 milyon API anahtarı, 35.000 e-posta adresi ve özel mesajlar. Wiz’e göre her şey "tek bir Supabase yapılandırma ayarına" dayanıyordu.
Base44: girişin atlatılması (Temmuz 2025). Wiz, bir yapay zekâ uygulama oluşturucusu olan Base44’te bir açık buldu: bir uygulamanın yalnızca herkese açık kimliğiyle, saldırgan özel uygulamalarda doğrulanmış bir hesap açıp tek oturum açma (SSO) dahil girişi atlatabiliyordu. Base44’ün sahibi Wix bunu 24 saat içinde düzeltti.
Bir yapay zekâ ajanı canlı veritabanını sildi (Temmuz 2025). SaaStr’ın kurucusu Jason Lemkin’in bir denemesi sırasında Replit’in yapay zekâ ajanı, onay almadan değişiklik yapmaması söylenmiş olmasına rağmen canlı bir veritabanında yıkıcı komutlar çalıştırdı. Sonrasında Replit, geliştirme ve canlı veritabanlarını otomatik olarak ayırmaya başladı.
Genel kural: tarayıcı görebiliyorsa, herkesin görebildiğini varsay.
Kontrol listesi
Anahtarlar ve gizli bilgiler
1. Tarayıcıda gizli anahtar olmasın
Neden: ön yüzünün tarayıcıya gönderdiği her şeyi herkes okuyabilir. Geliştirici araçlarını açarsın, oradadır. Escape 400’den fazla gizli anahtarı bu şekilde buldu.
Kontrol et: uygulamanı derle, sonra oluşan JavaScript dosyalarında anahtar kalıplarını ara: sk_live, sk-proj, sk-ant, service_role, sb_secret, secret. Yayındaki bir sitede geliştirici araçlarını aç, Sources sekmesine geç ve Ctrl+Shift+F ile (Mac’te Cmd+Option+F) ara.
Yapay zekâna sor: "Bu uygulamanın kullandığı her API anahtarını ve gizli bilgiyi listele. Her biri için tarayıcıya ulaşıp ulaşmadığını söyle. Her gizli anahtarı sunucu tarafındaki koda (bir API rotası, edge function ya da backend) taşı ve oradan çağır."
2. Gizli bilgileri kodundan ve git geçmişinden uzak tut
Neden: doğrudan koda yazılan anahtarlar git’e girer. Sonradan silsen bile geçmişte kalırlar.
Kontrol et:.env dosyalarının .gitignore içinde olduğundan emin ol. Reponda anahtar ara. Bir gizli bilgi bir kez bile commit edildiyse onu yenile (yeni bir anahtar oluştur ve eskisini sil). Satırı silmek yetmez.
Yapay zekâna sor: "Bu projede koda doğrudan yazılmış anahtarları, şifreleri ya da token’ları bul ve ortam değişkenlerine taşı. .gitignore’a ne eklemem gerektiğini göster."
3. Hangi anahtarların herkese açık olacak şekilde tasarlandığını bil
Neden: bazı anahtarlar herkese açık olacak şekilde tasarlanmıştır. Supabase’in anon anahtarı (artık publishable anahtar deniyor) bunlardan biri. Ama yalnızca Row Level Security tablolarını koruyorsa güvenlidir (5. madde). Service role anahtarı (artık gizli anahtar) tüm bu kuralları atlar ve sunucundan asla çıkmamalıdır.
Kontrol et: ön yüzündeki her anahtar için sağlayıcının belgelerini bul ve herkese açık olacak şekilde tasarlandığını doğrula.
Yapay zekâna sor: "Ön yüzde kullanılan her anahtar için, sağlayıcının onu herkese açık olacak şekilde tasarlayıp tasarlamadığını ve biri onu kopyalarsa verilerimi neyin koruduğunu açıkla."
4. Ücretli API’lere harcama sınırı koy
Neden: bir yapay zekâ ya da ücretli API anahtarı sızarsa, başkası faturanı kabartabilir.
Kontrol et: OpenAI, Anthropic, Google ve diğer panellerinde aylık bütçe ve uyarılar ayarla. Her uygulama için ayrı bir anahtar kullan ki birini kapatırken diğerlerini bozmayasın.
Yapay zekâna sor: "Ücretli bir API çağıran her uç noktaya kullanıcı başına bir kullanım sınırı ekle ve her sağlayıcıda aylık bütçeyi nereden ayarlayacağımı göster."
Veritabanı ve veri erişimi
5. Her tabloda Row Level Security’yi aç
Neden: yukarıdaki olaylarda bir numaralı sorun bu. Erişim kuralları olmadan, 3. maddedeki herkese açık anahtar tüm veritabanını okuyup yazabilir.
Kontrol et: Supabase’te Table Editor’ü aç ve RLS’si kapalı görünen tablolara bak. Hepsinde aç, sonra politikalar yaz: her satırı kim okuyabilir, ekleyebilir, güncelleyebilir ve silebilir. Diğer veritabanlarının kendi erişim kuralları var. Mantık aynı.
Yapay zekâna sor: "Tüm tablolarda Row Level Security’yi aç. Her tablo için kullanıcıların yalnızca kendi satırlarını okuyup değiştirebileceği politikalar yaz ve her politikayı tek cümleyle açıkla."
6. Uygulamanı bir yabancı gibi test et
Neden: sen her zaman kendin olarak, yani sahibi olarak test edersin. Saldırganlar öyle yapmaz.
Kontrol et: ikinci bir hesap aç. Bu hesapla giriş yap ve adres çubuğundaki kimlikleri değiştirerek (/faturalar/123 yerine /faturalar/124) ilk hesabın sayfalarını açmayı dene. Sonra çıkış yap ve tekrar dene. İkinci hesabın oturumuyla API’ni doğrudan çağırmayı da dene. Sana ait olmayan bir şey görüyorsan bir sorunun var (buna IDOR deniyor).
Yapay zekâna sor: "İki kullanıcı oluşturan ve B kullanıcısının, tüm rotalarda A kullanıcısının verileri üzerindeki her okuma ve yazmada 403 ya da 404 aldığını kontrol eden bir test yaz."
7. Yetkileri arayüzde değil, sunucuda kontrol et
Neden: bir butonu gizlemek güvenlik değildir. Herkes, o butonun göndereceği isteği kendisi gönderebilir.
Kontrol et: veri değiştiren her işlem için (oluşturma, düzenleme, silme, ödeme, davet) sunucu kodunu bul ve isteği kimin yaptığını ve buna izni olup olmadığını kontrol ettiğinden emin ol.
Yapay zekâna sor: "Veri değiştiren her sunucu rotasını ya da fonksiyonunu listele. Her biri için kullanıcının yetkisini kontrol eden satırı göster. Eksik olan yerlere kontrolü ekle."
8. Yapay zekâ ajanını canlı verilerden uzak tut
Neden: canlı veritabanına ulaşabilen bir ajan onu silebilir de; Replit olayı bunu gösterdi. Ajanlar kafaları karıştığında hata yapar ve çok hızlıdırlar.
Kontrol et: sahte verilerle ayrı bir geliştirme veritabanı kullan. Ajana canlı ortamın şifrelerini verme. Canlı veriyi gerçekten okuması gerekiyorsa ona salt okunur bir hesap ver. Ve herhangi bir aracın komut çalıştırmasına izin vermeden önce yedeklerin olsun (20. madde).
Yapay zekâna sor: "Örnek verilerle ayrı bir geliştirme veritabanı kur ve bu projedeki hiçbir komut ya da betiğin elle yapılan bir adım olmadan canlı ortama ulaşamayacağından emin ol."
Giriş ve oturumlar
9. Denenmiş bir giriş sistemi kullan
Neden: giriş, zor ayrıntılarla dolu: şifre hash’leme, sıfırlama token’ları, e-posta doğrulama, oturum süreleri. Yapay zekâ doğru görünen ama bunlardan birini unutan bir şey yazabilir. Base44’teki açık giriş mantığındaydı.
Kontrol et: platformunun kendi kimlik doğrulamasını (Supabase Auth, Firebase Auth) ya da bilinen bir kütüphaneyi veya servisi kullan. Yapay zekâdan kendi sistemini icat etmesini isteme.
Yapay zekâna sor: "Kayıt, giriş, şifre sıfırlama ve e-posta doğrulama için denenmiş bir kimlik doğrulama kütüphanesi mi kullanıyoruz? Bunlardan herhangi biri bize ait özel kodsa, kütüphanenin kendi fonksiyonlarıyla değiştir."
10. Oturum token’larını localStorage’da tutma
Neden:localStorage içindeki her şeyi sayfandaki herhangi bir betik okuyabilir. Tek bir XSS açığı (14. madde) ve saldırgan kullanıcılarının oturumlarını ele geçirir.
Kontrol et: geliştirici araçlarını aç, Application sekmesine geç ve Local Storage’a bak. Orada bir token görüyorsan, onu betiklerin okuyamadığı HttpOnly, Secure ve SameSite bir çereze taşımayı düşün. Axiean böyle yapıyor: sayfadaki betikler giriş token’ını hiç görmüyor.
Yapay zekâna sor: "Oturum token’ları nerede saklanıyor? localStorage’daysa HttpOnly, Secure ve SameSite çerezlere taşı ve veri değiştiren isteklere CSRF koruması ekle."
11. Giriş denemelerini ve e-postaları sınırla
Neden: sınır olmazsa biri binlerce şifre deneyebilir ya da "şifremi unuttum" formunu binlerce e-posta göndermek için kullanabilir.
Kontrol et: 20 kez yanlış şifre gir. 10 kez sıfırlama e-postası iste. Seni hiçbir şey durdurmuyorsa sınır ekle. Axiean’da bir hesap 15 dakikada 10 şifre denemesine izin veriyor ve her adres saatte aynı türden en fazla 3 e-posta alıyor.
Yapay zekâna sor: "Girişe, kayda, şifre sıfırlamaya ve e-posta gönderen her uç noktaya IP adresi başına ve hesap ya da e-posta adresi başına kullanım sınırları ekle."
12. Kimin hesabı olduğunu belli etme
Neden: kayıt formun "bu e-posta zaten kayıtlı" diyorsa, herkes bir kişinin uygulamanı kullanıp kullanmadığını öğrenebilir. Bazı uygulamalarda (sağlık, tanışma) bu bile özel bir bilgidir.
Kontrol et: zaten hesabı olan bir e-postayla kayıt ol. Cevap, yeni bir e-postayla aynı olmalı ("gelen kutunu kontrol et"). Axiean bunun yerine gerçek hesap sahibine "zaten bir hesabın var" e-postası gönderiyor.
Yapay zekâna sor: "Kayıt ve şifre sıfırlamanın, e-postanın hesabı olsun ya da olmasın aynı şekilde cevap vermesini sağla."
Girdiler, çıktılar ve dosyalar
13. Her girdiyi sunucuda doğrula
Neden: tarayıcıdaki form kontrolleri kolaylık içindir. Saldırganlar onları atlar ve istediklerini gönderir.
Kontrol et: her sunucu rotası, veriyi kullanmadan önce türleri, uzunlukları ve izin verilen değerleri kontrol etmeli. Bir şema kütüphanesi (zod gibi) bunu kısa ve okunabilir hâle getirir.
Yapay zekâna sor: "Veri alan her rotaya şema ile sunucu tarafı doğrulama ekle. Bilinmeyen alanları reddet ve metin uzunluklarını sınırla."
14. Kullanıcı metnini asla ham HTML olarak gösterme
Neden: kullanıcılar sayfanın kendi HTML’lerini çalıştırmasını sağlayabilirse, diğer kullanıcıların tarayıcılarında betik çalıştırabilirler (XSS). Veracode, yapay zekâ modellerinin ilgili görevlerin %86’sında XSS’e karşı koruma sağlamadığını buldu.
Kontrol et: kodunda dangerouslySetInnerHTML, innerHTML ve v-html ara. Kullanıcı içeriğiyle yapılan her kullanımın temizlenmesi ya da daha iyisi, kaldırılması gerekir.
Yapay zekâna sor: "Kullanıcı içeriğinin HTML olarak gösterildiği her yeri bul. Güvenli metin gösterimiyle değiştir ya da bilinen bir kütüphaneyle temizle."
15. Yüklenen her dosyayı kontrol et
Neden: bir "resim" başka bir şey olabilir. Ve sıradan bir telefon fotoğrafı çoğu zaman çekildiği yerin GPS konumunu taşır.
Kontrol et: sunucuda dosya türlerini ve boyutlarını sınırla. Dosyanın sadece adına değil, gerçekte ne olduğuna bak. Resimleri yeniden kodla; bu, gizli meta verileri de siler. Axiean yüklenen her resmi tam da bu yüzden yeniden kodluyor.
Yapay zekâna sor: "Sunucuda yüklenen dosyaları uzantılarına göre değil içeriklerine göre kontrol et, boyutlarını sınırla, resimleri yeniden kodla ve GPS konumu gibi meta verileri sil."
Ödemeler
16. Webhook’ları doğrula ve tarayıcıdan gelen fiyatlara asla güvenme
Neden: sunucun fiyat konusunda tarayıcıya inanırsa, biri 100 €’luk bir plan için 1 € ödeyebilir. Herhangi bir "ödeme başarılı" isteğine inanırsa, biri sahte bir tane gönderebilir.
Kontrol et: fiyatlar istekten değil, sunucundan ya da ödeme sağlayıcından gelmeli. Her webhook’un imzasını doğrula (Stripe ve diğerleri bunun için sana bir gizli anahtar verir).
Yapay zekâna sor: "Fiyatların sunucuda kendi ürün listemizden okunduğundan emin ol ve her ödeme webhook’unun imzasını, ona göre işlem yapmadan önce doğrula."
Bağımlılıklar ve yapay zekâ özellikleri
17. Yapay zekânın eklediği her paketi kontrol et
Neden: yapay zekâ bazen var olmayan paketler önerir. USENIX Security 2025’te sunulan bir çalışma, açık kaynak modellerin ürettiği kod örneklerinin %21,7’sinin, ticari modellerinkilerin ise %5,2’sinin var olmayan paketlere atıf yaptığını buldu. Saldırganlar bu isimlerle zararlı yazılım yayınlayabilir. Buna slopsquatting deniyor.
Kontrol et: yeni bir paketi kurmadan önce npm’de ya da PyPI’da ara. Gerçek paket mi, gerçek indirme sayıları ve geçmişi var mı? Kilit dosyanı (lock file) git’te tut ve npm audit (ya da kullandığın dilin karşılığını) çalıştır.
Yapay zekâna sor: "Eklediğin her bağımlılığı listele. Her biri için paket sayfasının bağlantısını ver ve neden gerektiğini anlat. Gerçekten ihtiyaç olmayanları kaldır."
18. Uygulaman bir LLM kullanıyorsa, çıktısına güvenme
Neden: kullanıcılar uygulamanın içindeki bir yapay zekâyla konuşabiliyorsa, onun senin talimatlarını görmezden gelmesini sağlamaya çalışabilirler (prompt injection). O yapay zekâ araç da kullanabiliyorsa (e-posta göndermek, veri silmek, para harcamak), o araçları kullanmaya çalışabilirler.
Kontrol et: modele yalnızca ihtiyaç duyduğu araçları ver. Veri değiştiren ya da para harcatan her şeyden önce kullanıcıdan onay iste. Sistem istemine asla gizli bilgi koyma.
Yapay zekâna sor: "Bu uygulamadaki yapay zekâ modelinin tetikleyebileceği her işlemi listele. Veri değiştiren, mesaj gönderen ya da para harcatan her şey için bir kullanıcı onayı adımı ekle."
Lansman günü ve sonrası
19. HTTPS’i ve güvenlik başlıklarını aç, CORS’u kısıtla
Neden: başlıklar tarayıcılara yaygın saldırıları engellemelerini söyler; örneğin siteni başkasının sayfasının içinde açmak gibi. Çerez ya da token kullanan bir API’de * olarak ayarlanmış bir CORS, başka sitelerin o API’yi kullanmasına izin verebilir.
Kontrol et: siteni securityheaders.com ya da Mozilla’nın HTTP Observatory aracı gibi ücretsiz bir başlık tarayıcısından geçir. API’nin yalnızca kendi sitenin adresinden gelen istekleri kabul ettiğinden emin ol.
Yapay zekâna sor: "Güvenlik başlıklarını ekle (Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy, frame-ancestors) ve CORS’u kendi alan adımızla sınırla."
20. Yedeklerin, güvenli kayıtların ve sorun bildirme yolun olsun
Neden: bir gün bir şey ters gidecek. Önemli olan, toparlanıp toparlanamayacağın ve bunu çabuk fark edip etmeyeceğin.
Kontrol et: otomatik günlük yedeklemeyi aç ve çalıştıklarından emin olmak için bir yedeği en az bir kez geri yükle. Kayıtlarının şifreleri, token’ları ya da tam kart numaralarını tutmadığını kontrol et. İnsanların sana sorun bildirebileceği görünür bir yol ekle. (Axiean’da bu Sorun bildir sayfası.)
Yapay zekâna sor: "Kayıtlarımızın asla şifre, token ya da kişisel veri içermediğini kontrol et, günlük veritabanı yedeklemesi kur ve bir yedeği geri yüklemenin adımlarını yaz."
Kontrol listesi tek sayfada
Kaydet, yazdır ya da editörünün yanında tut.
Kontrol listesinin tamamı tek sayfada.
Axiean’da bunu nasıl yapıyorum
Axiean için bir yapay zekâ kodlama ajanı kullanıyorum, yani bu listeyi kendi işime de uyguluyorum. Erkenden verdiğim birkaç karar:
Tarayıcı API ile hiçbir zaman doğrudan konuşmuyor. İstekleri ileten web sunucusuyla konuşuyor. API başka herkesi reddediyor.
Giriş token’ları HttpOnly çerezlerde duruyor, böylece sayfadaki hiçbir betik onları okuyamıyor, ve veri değiştiren her isteğin Axiean’ın kendisinden geldiği kontrol ediliyor.
Her yerde sınırlar var: şifreler için hesap başına, e-postalar için adres başına, geri kalan her şey için ziyaretçi başına.
Yüklenen resimler yeniden kodlanıyor, böylece bir profil fotoğrafı asla GPS konumunu taşımıyor.
Geliştirme ortamının kendi veritabanı var, canlı ortamdan ayrı.
Bunların hiçbiri özel beceri gerektirmedi. Birinin bunları istemesi gerekti. Kodun çoğunu yapay zekâ yazdı ama bu listedeki sorular benden geldi. Artık asıl iş bu: neyi soracağını bilmek.
Yapay zekâ ile yaptıysan, üreticilerin hangi yapay zekâ araçlarını kullandığını belirttiği Axiean’da da yayınlayabilirsin.
Sık sorulan sorular
Vibe coding güvenli mi?
Olabilir. Yapay zekânın yazdığı kod, bir makine yazdı diye daha tehlikeli değil. Kimse kontrol etmediğinde tehlikeli. Yukarıdaki olaylar yapay zekâ özellikle kötü olduğu için değil, temel ayarlar (Row Level Security gibi) eksik olduğu için yaşandı. Bu listeyi kullan ve bir yabancı gibi test et.
Supabase RLS nedir?
Row Level Security (satır düzeyinde güvenlik), Supabase’in her kullanıcının hangi satırları görüp değiştirebileceğine karar vermek için kullandığı bir PostgreSQL özelliği. RLS açıkken ve politikalar doğruyken, herkese açık anahtar yalnızca her kullanıcının görebileceği şeylere erişim verir. RLS kapalıyken bu anahtar tablonun tamamına erişim verir.
Lovable güvenli mi?
Lovable bir araç ve her araç gibi nasıl kullandığına bağlı. 2025’teki CVE, Row Level Security’si eksik uygulamalarla ilgiliydi. Lovable’ı Supabase ile kullanıyorsan, her tabloda RLS’yi aç, politikalar yaz ve ikinci bir hesapla test et (5. ve 6. maddeler).
Evet, herkese açık olacak şekilde tasarlanmış, ama yalnızca Row Level Security açıksa ve politikaların doğruysa. RLS olmadan bu anahtar, Moltbook olayında görüldüğü gibi verilerine tam erişim verir. Service role (gizli) anahtar asla herkese açık olmamalı.
Yapay zekâ uygulamamın güvenliğini kontrol edebilir mi?
Kısmen. Bu listedeki istemler çok işe yarar ve doğru soruyu sorduğunda yapay zekâ eksik kontrolleri bulmakta iyidir. Ama uygulamayı bir de kendin, bir yabancı gibi test et (6. madde) ve hassas veriler işliyorsan profesyonel bir inceleme yaptır.
Slopsquatting nedir?
Saldırganların, yapay zekâ araçlarının uydurduğu paket adlarıyla zararlı yazılım yayınlamasıdır. Yapay zekân var olmayan bir paket önerirse ve biri o adı almışsa, paketi kurduğunda onun kodunu çalıştırırsın. Yeni paketleri kurmadan önce her zaman kontrol et (17. madde).
İnsanlar artık hangi ürünü kullanacaklarını yapay zekâya soruyor. Siteni okuyamıyorsa, cevapta yoksun. Üreticiler için GEO’ya (üretken motor optimizasyonu) pratik bir rehber: tarayıcıların tam adları, 2 dakikalık bir test ve Axiean’da kurduklarımız.
Product Hunt, Hacker News, Reddit, BetaList, Uneed, Peerlist ve daha fazlası, Ekim 2026 itibarıyla gerçek kuralları ve fiyatlarıyla karşılaştırıldı. Hangisi ürününe uyar, hangisi ne kadar tutar ve hepsini tek bir lansman planında nasıl birleştirirsin.
··10 dk okuma
Yapay zekâ uygulama yapmayı hızlı ve ucuz hâle getirdi, herkes bir şeyler yayınlıyor. Artık zor olan, bulunmak. Bu değişimin arkasındaki gerçek rakamlar ve yapay zekâ ile yapılmış bir ürüne ilk kullanıcıları kazandırmak için kullandığım beş adımlı yöntem.
Vahid Aslani
