Yapay zeka ile yaptığım uygulamayı düzelttirmek: süreç, maliyet, doğru adres

Yapay zeka ile çıkardığın bir uygulama tıkandığında düzelttirme süreci üç adımdan geçer: önce kodun gerçek durumunu öğrenirsin, sonra kapsam ve sabit fiyat çıkar, en son düzeltme ve teslim gelir. Maliyeti belirleyen saatlik ücret değil, hangi katmanın bozuk olduğu: kimlik doğrulama ve ödeme en pahalıya patlar, arayüz metni en ucuza gelir. Aşağıda kendi kodunu nasıl teşhis edeceğini, sürecin gerçekte nasıl işlediğini, maliyeti neyin belirlediğini ve kimseyle konuşmadan önce ne hazırlaman gerektiğini anlatıyoruz.

Kendi kodunu ilk beş dakikada nasıl teşhis edersin

Bir geliştirici projeni teslim aldığında ilk beş dakikada tam olarak şunlara bakar: kaç dosya var, ne kadar kod var, geride kaç çözülmemiş TODO/FIXME işareti bırakılmış, hiç test var mı. Bu dört sayı, kimse fiyat vermeden önce kapsamı gösterir. Depo erişimin hâlâ elindeyse (Lovable, Bolt, Cursor, Replit dahil çoğu araç GitHub'a export'a izin veriyor), aynı dört komutu sen de çalıştırabilirsin.

$ git ls-files | grep -E '\.(js|jsx|ts|tsx)$' | grep -v node_modules | wc -l
$ git ls-files | grep -E '\.(js|jsx|ts|tsx)$' | grep -v node_modules | xargs wc -l | tail -1
$ grep -rInE "TODO|FIXME" --include=*.js --include=*.jsx --include=*.ts --include=*.tsx . | grep -v node_modules | wc -l
$ find . -path ./node_modules -prune -o -type f \( -name "*.test.*" -o -name "*.spec.*" \) -print | wc -l

Yöntemi somutlaştırmak için gerçek bir prodüksiyon deposuna karşı çalıştırdık, bu sitenin kendi kod tabanına. Senin rakamların bununla eşleşmeyecek; önemli olan yöntem, çünkü herhangi bir kod tabanında aynı şekilde çalışıyor.

Sıfır TODO ve sıfır test dosyası bu depo için doğru. Tipik bir vibe coding çıktısından tam tersini bekle: onlarca TODO ve sıfır test norm, tek bir test dosyası bile nadir. Teşhisin bulabildiği ile bir düzeltmenin gerçekte gerektirdiği arasındaki bu fark, sabit fiyatın kod okunmadan asla verilmemesinin sebebi.

Süreç nasıl işliyor: erişimden teslime dört adım

İşi kim yaparsa yapsın, dürüst bir süreç aynı sırayla ilerler.

3. adım ancak 2. adım bittikten sonra gelir. Kimse kodu okumadan gelen bir teklif, rakama bürünmüş bir tahmindir. Bu sürecin diğer tarafını, yani işi yapacak geliştiriciyi nasıl seçeceğini ayrı yazımızda anlattık: vibe coded uygulamayı düzeltecek geliştirici aramak. Bu yazı, birini seçtikten sonra sürecin ve maliyetin nasıl göründüğüne odaklanıyor.

Kurtarmak mı, yeniden yazmak mı

2. adımdaki teşhis genelde bu iki cevaptan birine çıkar.

Maliyeti gerçekte ne belirliyor

Saat değil, katman. Bozuk bir uygulamanın bazı kısımları ucuza düzelir, bazıları neredeyse hiç ucuza gelmez.

Nerede tasarruf edebilirsin, nerede edemezsin

Bazı köşelerden kısmak güvenli. Bazıları şimdi tasarruf ettirdiğinden fazlasını sonra geri alır.

• Bilinen hataların listesini kendin çıkar. Saatlerce keşif okumasını ortadan kaldırır.
• Arayüz kullanıcı için zaten işliyorsa yeni bir tasarım geçişini atla.
• Zaman kazanmak için NDA'yı atlama. Hiçbir maliyeti yok ve iki tarafı da korur.
• Kimsenin salt okunur yerine doğrudan tam yönetici erişimiyle başlamasına izin verme.
• Bilinen bir güvenlik açığını "ikinci faza" erteleme. Kapatılana kadar istismar edilebilir kalır.

Ajansa gitmeden önce hazırlaman gereken beş şey

1. Kod tabanı hâlâ Lovable, Bolt ya da benzeri bir platforma sıkışmışsa GitHub'a çıkar. Export yazımıza bak, neyin geldiğini gösteriyor.
2. Bildiğin her hatayı, nasıl tekrar edildiğiyle birlikte yaz.
3. Alan adı, hosting ve API anahtarlarına şu an kimin eriştiğini listele.
4. Görüşmeden önce gerçekçi bir bütçe aralığı çıkar, sonra değil. Vibe coding maliyet hesaplayıcı projenin gerçek durumundan bir tahmin çıkarıyor.
5. Gerçek kullanıcı verisi varsa, kimse projeye dokunmadan önce yedeğini al.

Bu süreç her zaman gerekli değil

Uygulamanın henüz gerçek kullanıcısı yoksa ve risk altında gerçek veri yoksa, birini işe almak henüz erken olabilir. Daha yavaş ama bedava, kendi başına düzeltmek bu aşamada mantıklı bir tercih. Vibe coding'i doğru yapmayı anlatan yazımız, tek başına ilerleyen bir projenin bu noktaya hiç gelmemesini sağlayan disiplini kapsıyor.

Sık sorulan sorular

İlk teşhis gerçekten ücretsiz mi?
Genelde evet, ama erişimi göndermeden önce doğrudan sor. Bunu konuşmayı bile reddetmek kendi başına küçük bir uyarı işareti.

Sabit fiyat proje ortasında değişir mi?
Sadece salt okunur incelemede görünmeyen yeni bir kapsam ortaya çıkarsa, o da ekstra iş başlamadan önce açıkça konuşulup onaylanmalı, sonradan faturalanmamalı.

Süreç boyunca verilerim güvende mi?
Derinlemesine erişimden önce NDA ve baştan salt okunur erişim, bunu garanti eden iki kontrol. 1. adımda tam yönetici erişimi istenmesi uzaklaşma sebebi.

Sürecin tamamı ne kadar sürer?
Teşhis genelde birkaç gün. Düzeltmenin kendisi, hangi katmanların bozuk olduğuna göre yukarıdaki maliyet faktörlerine bakarak günlerden birkaç haftaya kadar değişir.

Kurtarma işe yaramazsa ne olur?
Kodu önce okuyan bir inceleyici bunu genelde sen henüz bir şey ödemeden, yeniden yazım önerisiyle erken söyler. Bu itilmesi değil güvenilmesi gereken bir işaret.

Uygulamanın kodunu yayına girdiğinden beri kimse baştan sona okumadıysa, o ilk salt okunur inceleme, bizim yapay zeka projesi tamamlama sürecimizin de başladığı yer.