Yapay zekâyla ürün geliştirirken yapılan 5 hata

Yapay zekâ araçları sayesinde bir hafta sonunda çalışan bir uygulama çıkarmak artık mümkün. Bu, solo kurucular için büyük bir fırsat. Ama aynı hız, eskiden aylar sonra ortaya çıkacak hataları da birkaç güne sığdırabiliyor.

Simon Willison, "vibe coding" kavramını, üretilen kodu umursamadan yapay zekâyla kod üretmek olarak tanımlıyor. Ona göre bu, düşük riskli prototipler ve hafta sonu projeleri için gayet iyi. Sorun, aynı yöntemle müşteri verisi tutan ve para alan bir ürün çıkarmaya çalıştığında başlıyor.

Bu yazıda Hacker News tartışmalarından, güvenlik araştırmacılarının bulgularından ve bu araçları her gün kullanan geliştiricilerin deneyimlerinden derlenmiş beş hatayı bulacaksın.

Hata 1: Güvenliği "sonra bakarım"a bırakmak

Bu, en pahalıya patlayan hata. Örnekler gerçek ve yakın tarihli.

Semafor'un Mayıs 2025 haberine göre Replit çalışanı Matt Palmer ve bir meslektaşı, Lovable ile yapılmış ve platformun sitesinde öne çıkarılan 1.645 uygulamayı taradı. Bunlardan 170'inde herkesin kullanıcı bilgilerine erişebildiğini buldular. Açığa çıkan veriler arasında isimler, e-posta adresleri, finansal bilgiler ve yapay zekâ servislerine ait gizli API anahtarları vardı.

The Register'ın Şubat 2026 haberinde ise Lovable üzerinde yapılmış bir sınav ve not görüntüleme uygulaması anlatılıyor. Araştırmacı Taimur Khan, uygulamada altısı kritik 16 açık buldu. Haberde aktarılana göre veritabanında satır düzeyinde güvenlik ve rol bazlı erişim kontrolü yoktu. Hatalı bir kimlik doğrulama fonksiyonu giriş yapmış kullanıcıları engelleyip giriş yapmamış olanları içeri alıyordu. 18.697 kullanıcı kaydı etkilendi. Lovable tarafı, her projeye yayından önce ücretsiz bir güvenlik taraması yapıldığını, önerileri uygulamanın ise kullanıcıya kaldığını söyledi.

Bir de Mart 2025'te X'te paylaşılan bir paylaşım var. Namanyay Goel'in yazısında aktarıldığına göre, tamamen yapay zekâyla ve elle tek satır kod yazmadan yaptığını söyleyen bir kurucu, uygulamasının saldırı altında olduğunu duyurdu. Abonelikler atlatılıyor, API anahtarları limitine kadar kullanılıyor, veritabanı bozuluyordu. Kurucu teknik biri olmadığı için sorunu çözmesinin uzun sürdüğünü de yazmıştı.

Ne yapmalı? Willison'ın listesi iyi bir başlangıç: gizli anahtarların koda ya da tarayıcıya sızmadığından emin ol, özel veriyle çalışıyorsan verinin nereye gittiğini kontrol et ve kullandığın ücretli API'lerde mutlaka harcama limiti tanımla. Veritabanı erişim kurallarını tek tek kontrol et. Kullanıcı verisi tutan bir ürünü yayına almadan önce bilen birine baktır.

Hata 2: Anlamadığın kodu ürüne almak

Yapay zekânın yazdığı her parça tek başına mantıklı görünebilir. Sorun, bütün bir araya geldiğinde ortaya çıkıyor.

Mo Bitar, Ocak 2026'da yazdığı ve HN'de 600'ü aşkın yorum alan yazısında iki yıl ajanlarla kod yazdıktan sonra çoğunlukla elle yazmaya döndüğünü anlatıyor. Ona göre ajanların yaptığı değişiklikler tek tek bakınca iyi görünüyor, ama kod tabanının tamamını okuduğunda ortaya dağınık bir yapı çıkıyor. Ayrıntılı şartnameler yazmayı da denemiş. Ama gerçek şartnamelerin iş ilerledikçe değiştiğini, ajanların ise baştaki kararlarını sonradan güncellemediğini söylüyor. Bu yüzden bu kodu kullanıcılarına satmak ve verilerini koruyacağına söz vermek istemediğini yazıyor.

Willison'ın kendi kuralı da tam bu noktayla ilgili. Bir başkasına ne yaptığını tam olarak açıklayamayacağı hiçbir kodu depoya göndermiyor. Bunu ürün kalitesinde yapay zekâ destekli programlamanın altın kuralı olarak görüyor.

Ne yapmalı? Para alacağın ürünün kodunu en azından ana hatlarıyla okuyabiliyor olmalısın. Anlamadığın bir parça varsa, yapay zekâdan onu açıklamasını iste. Açıklamayı da anlamıyorsan o parça henüz ürüne hazır değil.

Hata 3: Test yazdırmamak

Bitar'ın yazısının HN tartışmasında Willison, ajanların büyük bir tasarım değişikliğini yüzlerce yere uygulayabildiğini hatırlatıyor. Örneğin tüm API çağrılarını kimlik doğrulama, yeniden deneme ve hız sınırlaması yapan tek bir sınıftan geçirmek gibi. Ama bunun güvenle yapılabilmesi için bir şart koyuyor: ajanlara baştan otomatik bir test seti de yazdırmış olmalısın. Değişikliğin bir şeyi bozup bozmadığını o testler gösteriyor.

The Register haberinin HN tartışmasında bir yorumcu, uygulamadaki ters çalışan kimlik doğrulama hatasının aslında bir insanın da yapabileceği türden olduğunu söylüyor: bir ünlem işaretini unutursun ve mantık tersine döner. Ona göre fark şu: bir insanın, yaptığı değişikliğin sonucunu deneyip görme ihtimali daha yüksek. Aynı başlıkta başka bir kullanıcı, bu vakada erişim kurallarını sınayan testlerin gerektiğini yazıyor.

Test yoksa her yeni özellik eskilerden birini sessizce bozabilir. Bunu da genelde bir müşteri sana yazdığında öğrenirsin.

Ne yapmalı? Yapay zekâdan her yeni özellikle birlikte test de iste. En azından giriş yapma, ödeme ve veri kaydetme gibi kritik akışların testleri olsun. Her değişiklikten sonra testleri çalıştır.

Hata 4: Kapsamı yapay zekâya bırakmak

Ernie Hsiung, Haziran 2025'te yazdığı yazıda iki haftalık bir hafta sonu projesinin nasıl kontrolden çıktığını anlatıyor. Başlangıçtaki fikir basitti: Obsidian notlarını tarayıp özet çıkaran bir eklenti. Sonunda elinde birden fazla yapay zekâ sağlayıcısını destekleyen bir katman, denetim kayıtlı bir gizlilik sistemi, 13 tür örüntü tanıyan bir motor ve dört katmanlı bir önbellek vardı. Kendi tahminine göre kapsam altı kat büyümüştü.

Hsiung'un çıkardığı ders net. Yapay zekâ asistanı onayladığın her özelliği yapar, bu yüzden kapsamı başlamadan önce belirlemen gerekir. İşin ilginç tarafı, çalışan bir ilk sürüm çok önce hazırdı ama o özellik eklemeye devam etmişti. Daha sonra daha basit bir istemle baştan yazdığında proje yaklaşık yüzde 99,5 küçüldü.

Ne yapmalı? İlk sürümün kapsamını tek sayfaya yaz ve yapay zekâya her oturumun başında bunu ver. Yeni bir özellik aklına geldiğinde onu bir "sonra" listesine ekle. Kullanıcı istemeden o listeden bir şey çıkarma.

Hata 5: Çıktıya ve hissine fazla güvenmek

Yapay zekâyla çalışırken çok üretken hissedebilirsin. Ama his ile sonuç aynı şey değil.

fast.ai'den Rachel Thomas, Ocak 2026'daki yazısında bu durumu "karanlık akış" olarak adlandırıyor. Ona göre yapay zekâyla kod üretmek, kumar makinelerine benzer şekilde, kayıpları kazanç gibi gösteren bir geri bildirim döngüsü yaratabiliyor. Thomas, METR'nin bir çalışmasına atıf yapıyor: geliştiriciler yapay zekâyla yaklaşık yüzde 20 daha hızlı olduklarını düşünmüş, ölçümde ise yaklaşık yüzde 19 daha yavaş çıkmışlar.

Bitar'ın yazısı da aynı noktaya varıyor. İnceleme sırasında makul görünen kodun yine de kötü olabildiğini, bu yüzden ajan çıktısını ciddi bir denetim olmadan yayına hazır saymadığını söylüyor.

Ne yapmalı? Üretkenliği hissinle değil, sonuçla ölç. Bu hafta kaç kullanıcı neyi kullanabildi? Kaç hata kapandı, kaç yenisi açıldı? Yapay zekânın "hallettim" dediği her şeyi kendin bir kez dene.

Türkiye'den bir örnek

Ankara'da küçük bir dil kursu işleten biri, öğrenci yoklamalarını ve ödemeleri takip eden bir uygulamayı yapay zekâyla birkaç günde çıkarabilir. Bu harika. Ama uygulamada öğrencilerin adları, telefonları ve ödeme bilgileri olacak. Burada beş hatanın her biri gerçek bir risk demek.

Veritabanı erişim kuralları kontrol edilmezse bir öğrencinin bilgisi bir başkasına görünebilir. Test yoksa yeni bir rapor ekranı eklerken ödeme kaydı bozulabilir. Kapsam belirlenmezse yoklama uygulaması bir anda tam bir okul yönetim sistemine dönüşmeye çalışır ve hiç bitmez. Kullanıcı verisi tutuyorsan bunun sorumluluğu da sende. Bunu unutma.

Yapay zekâyı bırakmak zorunda değilsin

Bu yazının amacı seni yapay zekâdan uzaklaştırmak değil. Willison da Thomas da bu araçları kullanmaya devam etmeyi, ama sorumlu bir süreçle kullanmayı öneriyor. Prototip, deneme ve iç kullanım için yapay zekâya geniş alan ver. Para aldığın ve başkalarının verisini tuttuğun kısımda ise kontrolü elinde tut.

Bu hafta yapılacak

1. Kullandığın her ücretli API ve yapay zekâ servisinde bir harcama limiti tanımla.
2. Kodunda ve tarayıcıya giden dosyalarda gizli anahtar olup olmadığını kontrol et.
3. Veritabanındaki her tablonun kim tarafından okunup yazılabildiğini bir listeye çıkar.
4. Giriş, ödeme ve veri kaydetme akışları için yapay zekâya test yazdır ve çalıştır.
5. İlk sürümün kapsamını tek sayfaya yaz ve her oturumun başında yapay zekâya ver.

Sık sorulanlar

Hiç kod bilmiyorum, yine de yapay zekâyla ürün çıkarabilir miyim?

Prototip çıkarabilirsin ve fikrini test edebilirsin. Ama kullanıcı verisi tutacak ve para alacaksan, yayına almadan önce kodu bilen birine güvenlik kontrolü yaptırman gerekir.

Araçların kendi güvenlik taraması yeterli mi?

Faydalı ama tek başına yeterli değil. The Register haberindeki örnekte Lovable, güvenlik taramasının önerilerini uygulamanın kullanıcıya kaldığını söylüyor. Taramayı çalıştır, çıkan her uyarıyı ciddiye al ve kendin de kontrol et.

Test yazmak beni yavaşlatmaz mı?

Kısa vadede biraz. Ama test olmadan yapılan her değişiklik, eski bir özelliği bozma riski taşıyor. Yapay zekâ testleri de hızlıca yazabildiği için ek maliyet düşük.

Hangi işleri gönül rahatlığıyla yapay zekâya bırakabilirim?

Willison'ın tarifiyle düşük riskli işleri: prototipler, iç kullanım araçları, tek seferlik betikler. Hata çıksa bile kimsenin zarar görmeyeceği işler.

Dayanak

• Not all AI-assisted programming is vibe coding (but vibe coding rocks) — Simon Willison: Açıklayamadığın kodu göndermeme kuralı, gizli anahtar ve harcama limiti uyarıları.
• Two publishers and three authors fail to understand what "vibe coding" means — Simon Willison: Vibe coding'in tanımı.
• After two years of vibecoding, I'm back to writing by hand — Mo Bitar: Bakımı zorlaşan kod ve çıktıya güven sorunu.
• After two years of vibecoding — Hacker News tartışması: Willison'ın test seti ve büyük çaplı değişiklik yorumu.
• The hottest new vibe coding startup Lovable is a sitting duck for hackers — Semafor: 1.645 uygulamadan 170'inde açık bulunması.
• Vibe coded Lovable-hosted app littered with basic flaws exposed 18K users — The Register: Erişim kontrolü olmayan uygulama ve 18.697 kayıt.
• Vibe coded Lovable-hosted app littered with basic flaws exposed 18K users — Hacker News tartışması: Ters çalışan kimlik doğrulama, değişikliği deneme ve erişim testleri üzerine yorumlar.
• Vibe Coding is a Dangerous Fantasy — Namanyay Goel: Saldırıya uğrayan kurucunun hikâyesi ve görünmez karmaşıklık.
• Well, this is a learning moment — Ernie Hsiung: Altı kat büyüyen kapsam ve yüzde 99,5 küçülen yeniden yazım.
• Breaking the Spell of Vibe Coding — Rachel Thomas, fast.ai: "Karanlık akış" kavramı ve algılanan ile ölçülen hız farkı.