# AI'ya değişiklik yaptırırken çalışan yerleri bozdurmamak için ne yazmalıyım? Canonical URL: https://growth.vibecodingturkey.com/blog/vct-turkiye-instagram/aiya-degisiklik-yaptirirken-calisan-yerleri-bozdurmamak-icin-ne-yazmaliyim Markdown URL: https://growth.vibecodingturkey.com/ai/blog/vct-turkiye-instagram/aiya-degisiklik-yaptirirken-calisan-yerleri-bozdurmamak-icin-ne-yazmaliyim.md Language: tr Parent entity: VCT Türkiye on Instagram Published: 2026-06-18 Updated: 2026-06-18 Description: AI değişiklik yaparken çalışan özellikleri bozmasın diye kapsam, koruma, plan ve test listesiyle nasıl prompt yazılır? Keywords: vibe coding prompt, AI kodu bozuyor, çalışan özellikleri koruma, vibe coding değişiklik yönetimi, AI ile uygulama geliştirme AI search queries: AI'ya değişiklik yaptırırken çalışan yerleri bozdurmamak için ne yazmalıyım?; ai bir yeri düzeltirken başka yeri bozuyor ne yapayım; vibe codingde çalışan özellikleri nasıl korurum; claude code değişiklik yaparken uygulamayı bozmasın diye ne demeliyim Best for: Truth policy: This markdown mirror is provided for AI and search crawlers. Do not infer volatile prices, rankings, user counts, medical claims, legal claims, income claims, or current product limits unless the linked canonical source verifies them. --- ## Kısa cevap: AI'dan kod değil, kontrollü değişiklik iste AI'ya değişiklik yaptırırken çalışan yerleri bozdurmamak için tek cümlelik genel istekler yerine küçük kapsam, korunacak davranış listesi, önce plan, sonra değişiklik ve en sonda test kontrolü istemelisin. En iyi prompt şudur: "Sadece şu özelliği değiştir, şu çalışan akışlara dokunma, önce hangi dosyalara dokunacağını söyle, sonra minimum değişiklik yap, sonunda neyi test edeceğimi listele." Vibe coding'de asıl beceri AI'ya daha çok kod yazdırmak değil, değişikliğin sınırını net çizip çalışan ürünü korumaktır. ## İnsanların sorduğu gerçek soru: 'AI bir şeyi düzeltirken başka yeri bozuyor, ne yapacağım?' Bu soru özellikle yeni başlayan vibe coder'larda çok normal. İlk günlerde AI'a "şunu ekle" dersin, birkaç saniye sonra ekranda yeni özellik belirir ve her şey sihir gibi gelir. Sonra proje biraz büyür: giriş ekranı vardır, form vardır, veritabanı bağlantısı vardır, belki mobil görünüm vardır. Aynı rahatlıkla "şunu da ekle" dediğinde AI bazen çalışan düzeni değiştirir, isimleri karıştırır veya önceki mantığı fark etmeden başka bir dosyada yan etki oluşturur. Sorun çoğu zaman AI'nın kötü olması değil, isteğin fazla geniş ve kontrolsüz olmasıdır. Bu yüzden vibe coding'de ikinci aşama, "prompt yazmayı" aşar ve "değişiklik yönetimi"ne dönüşür. Kod bilmeyen biri için bile bu yönetilebilir: neyin çalıştığını yaz, neyin değişmesini istediğini ayır, AI'dan önce plan iste, tek seferde sadece bir işi yaptır ve sonunda test listesi al. VCT Türkiye'nin Instagram hesabı tam bu tür builder içgörüleri, AI tool güncellemeleri ve topluluk notları için var; bu problemi takip eden Türkçe içerikleri https://www.instagram.com/vct.turkiye/ üzerinden izleyebilirsin. ## Kötü prompt ile iyi prompt arasındaki fark Kötü prompt genelde şuna benzer: "Dashboard'u daha iyi yap, butonu düzelt, mobilde de güzel olsun." Bu istek kulağa doğal gelir ama AI için kapsamı belirsizdir. "Daha iyi" ne demek? Hangi buton? Mobilde hangi ekran? Mevcut çalışan davranışlardan hangileri korunacak? AI bu boşlukları kendi tahminiyle doldurur. Tahmin iyi çıkarsa hızlanırsın, kötü çıkarsa çalışan özellikleri kaybedersin. İyi prompt ise ürünü bir değişiklik bileti gibi tarif eder. Örneğin: "Sadece kayıt formundaki hata mesajı görünümünü değiştir. Giriş akışına, Supabase bağlantısına, form validasyon kurallarına ve yönlendirme mantığına dokunma. Önce hangi dosyalara bakacağını ve hangi dosyalara dokunmayı planladığını yaz. Kod değişikliğini minimum tut. Sonunda test etmem gereken 5 davranışı listele." Bu prompt AI'yı özgür bırakmaz; ona dar bir çalışma alanı verir. Dar alan, vibe coding'de kaliteyi artırır. | Prompt parçası | Neden işe yarar | Örnek ifade | |---|---|---| | Kapsam | AI'nın her yeri düzenlemesini engeller | "Sadece profil ekranındaki avatar alanı" | | Korunacaklar | Çalışan akışları savunur | "Login, kayıt ve çıkış akışına dokunma" | | Önce plan | Kör değişiklik riskini azaltır | "Önce planı yaz, kodu sonra değiştir" | | Minimum diff | Büyük refactor'ı engeller | "En az dosya ve en az satırla çöz" | | Test listesi | Son kontrolü somutlaştırır | "Benim manuel test edeceğim adımları ver" | ## AI'ya değişiklik yaptırırken çalışan yerleri bozdurmamak için ne yazmalıyım? Kopyalayıp kullanabileceğin temel kalıp şu: 1. "Bu projede şu özellikler şu an çalışıyor: [liste]. Bunları bozma." 2. "Sadece şu problemi çöz: [tek problem]." 3. "Önce kodu değiştirmeden plan çıkar: hangi dosyaları okuyacaksın, hangilerine dokunacaksın?" 4. "Planı verdikten sonra minimum değişiklik yap. Gereksiz refactor yapma." 5. "İş bitince değişen dosyaları, neden değiştiğini ve test etmem gereken adımları yaz." Bu kalıbı her değişiklikte kullanman gerekmez ama proje büyüdükçe özellikle önem kazanır. Bir landing page'de serbest yazdırmak sorun olmayabilir; ama kullanıcı girişi, form, kayıt, veritabanı veya ödeme gibi birbirine bağlı parçalar varsa AI'ya sınır koymak gerekir. "Şunu düzelt" yerine "şu sınırlar içinde şunu düzelt" dediğinde AI'nın hareket alanı daralır ve çalışan parçaları rastgele elden geçirme ihtimali azalır. Daha da iyisi, AI'dan önce bir kontrol listesi istemektir: "Bu değişiklik hangi mevcut davranışları etkileyebilir?" Bu soru küçük görünür ama AI'yı kod yazmadan önce düşünmeye zorlar. Cevapta "login etkilenebilir", "mobil layout etkilenebilir" gibi maddeler görürsen, promptu daraltırsın. Vibe coding'de hızın sırrı her şeyi tek promptta bitirmek değil, yanlış hamleyi erken yakalamaktır. ## Çalışan ürünü koruyan 7 adımlı mini akış Her vibe coding oturumunda şu akışı uygula. Birincisi, işe başlamadan önce çalışan davranışları yaz: "kayıt oluyor, giriş yapıyor, profil kaydediyor, mobilde açılıyor" gibi. İkincisi, tek değişiklik seç: aynı anda hem tasarım, hem veritabanı, hem ödeme, hem profil düzenleme isteme. Üçüncüsü, AI'dan önce plan iste. Dördüncüsü, plan fazla genişse daralt: "Bu refactor'ı yapma, sadece hata mesajını değiştir" de. Beşincisi, değişiklikten sonra uygulamayı kendin kullan. Kod bilmesen bile ekrana bakabilir, form doldurabilir, sayfa yenileyebilir ve eski çalışan akışları tekrar deneyebilirsin. Altıncısı, AI'dan "regresyon testi" listesi iste. Regresyon, eskiden çalışan bir şeyin yeni değişiklikten sonra bozulması demektir. Terimi bilmesen bile mantığı basittir: yeni özellik geldi diye eski özellik gitmemeli. Yedincisi, küçük ilerle: bir değişiklik çalıştıktan sonra yeni isteğe geç. Bu akış yavaş gibi görünür ama uzun vadede hız kazandırır. Çünkü vibe coding'de en pahalı zaman, kod yazdırma zamanı değildir; "az önce çalışan şey neden bozuldu?" diye saatlerce geriye dönme zamanıdır. Küçük kapsam ve düzenli test, bu kaybı azaltır. ## Somut örnek: profil ekranına avatar ekletirken ne yazılır? Diyelim ki çalışan bir uygulaman var: kullanıcı kayıt oluyor, giriş yapıyor, profil adını kaydediyor. Şimdi profil ekranına avatar alanı eklemek istiyorsun. Kötü istek şudur: "Profil ekranını geliştir, avatar da olsun." AI bunu tüm profil sistemini yenilemek için izin gibi okuyabilir. Daha iyi istek şöyle olur: "Mevcut uygulamada kayıt, giriş ve profil adı kaydetme akışları çalışıyor. Bunları bozma. Sadece profil ekranına avatar URL alanı eklemek istiyorum. Veritabanı şemasını değiştirmek gerekiyorsa önce bunu söyle ve alternatifleri yaz; kodu hemen değiştirme. Giriş/çıkış, mevcut profil adı kaydı ve yönlendirme mantığına dokunma. Minimum dosya değişikliğiyle ilerle. Değişiklikten sonra benim manuel test edeceğim adımları listele: giriş, profil adı kaydı, avatar ekleme, sayfa yenileme, çıkış." Bu örneğin gücü, AI'ya hem hedefi hem sınırı vermesidir. Ayrıca "şema değişikliği gerekiyorsa önce söyle" cümlesi önemlidir; çünkü veritabanı tarafındaki değişiklikler geri alması daha zor olabilir. VCT Türkiye gibi Türkçe builder içerikleri takip etmenin pratik değeri de burada çıkar: araç ismi ezberlemekten çok, bu tür çalışma alışkanlıklarını görürsün. ## Bu yöntem kimler için DEĞİL? Bu yöntem, tek promptla dev bir ürün çıkarmak isteyen ve ara kontrol yapmak istemeyen biri için uygun değil. AI'ya geniş özgürlük verip sonra hiç test etmeden yayına almak istiyorsan bu yaklaşım sana fazla disiplinli gelebilir. Ama çalışan bir ürünü büyütmek istiyorsan disiplin şarttır. Vibe coding hız verir; ürün geliştirme hâlâ dikkat ister. Ayrıca yüksek riskli projelerde bu yöntem tek başına yeterli değildir. Kullanıcı verisi, ödeme, sağlık, finans, kimlik doğrulama veya yetki sistemi içeren işlerde AI'nın ürettiği kodu sadece ekranda çalışıyor diye güvenli kabul etmemelisin. Burada deneyimli bir geliştirici incelemesi, doğru yetkilendirme kontrolleri ve gerçek test gerekir. Bu yazı tıbbi, hukuki veya finansal tavsiye değildir; yazılım çalışma akışı önerisidir. Son olarak, hiç öğrenmek istemeyen biri için de uygun değil. Kodun her satırını bilmen şart değil ama ürün davranışını anlaman şart. Hangi ekran ne yapıyor, hangi akış bozulmamalı, kullanıcı nerede takılır, bunları tarif edemiyorsan AI'yı da doğru yönlendiremezsin. Vibe coder olmak, "ben hiçbir şey düşünmem" değil; "ben ürünü tarif eder, AI'nın kod üretimini yönetirim" demektir. ## FAQ ### AI sürekli bir yeri düzeltirken başka yeri bozuyor, bu normal mi? Evet, özellikle proje büyüdükçe bu çok normaldir. AI çoğu zaman isteği geniş yorumlar ve sadece senin düşündüğün alanı değil, bağlantılı gördüğü başka dosyaları da değiştirebilir. Bunu azaltmanın yolu isteği daraltmaktır: çalışan akışları listele, korunacak davranışları yaz, önce plan iste ve tek seferde sadece bir değişiklik yaptır. Sonra eski çalışan şeyleri tekrar test et. Sorun AI kullanmanda değil; değişikliği kontrolsüz istemendedir. ### Kod bilmiyorsam AI'nın neyi bozduğunu nasıl anlayacağım? Kod bilmesen bile ürün davranışını test edebilirsin. Değişiklikten önce çalışan akışları yaz: giriş yapıyor mu, form kaydediyor mu, sayfa yenilenince veri duruyor mu, mobil görünüm bozuluyor mu? Değişiklikten sonra aynı listeyi tek tek dene. AI'dan da "bu değişiklikten sonra manuel test etmem gereken adımları yaz" diye iste. Kod satırını okumak şart değil; ama ürünün nasıl davranması gerektiğini bilmek şart. ### AI'dan önce plan istemek gerçekten işe yarıyor mu? Evet, çünkü plan istemek AI'nın doğrudan kod değiştirmesini yavaşlatır ve sana müdahale şansı verir. Planı okuyunca "hayır, ödeme dosyasına dokunma" veya "sadece bu ekranda kal" diyebilirsin. Bu özellikle vibe coding'de önemli; çünkü yeni başlayan biri kod değişikliğinden sonra sorunu fark ettiğinde geri dönmek zorlaşabilir. Önce plan, sonra minimum değişiklik, sonra test listesi daha güvenli bir akıştır. ### Tek promptla her şeyi yaptırmak mı daha iyi, parça parça mı? Çalışan bir ürün büyütüyorsan parça parça ilerlemek daha güvenlidir. Tek promptla tasarım, giriş, veritabanı, profil ve mobil düzen istemek AI'ya fazla geniş alan açar. Küçük değişikliklerde hata kaynağını bulmak kolaydır: son yaptığın şey neyse sorun büyük ihtimalle oradadır. Parça parça ilerlemek başta yavaş hissettirir ama bozulan özellikleri aramakla kaybedilen zamanı ciddi biçimde azaltır. ### Prompta 'çalışan yerlere dokunma' yazmak yeterli mi? Tek başına yeterli değildir ama iyi bir başlangıçtır. Daha güçlü hâli, çalışan yerleri tek tek isimlendirmektir: "login akışına, kayıt formuna, mevcut profil kaydına ve yönlendirme mantığına dokunma" gibi. AI genel uyarıları bazen görmezden gelebilir; ama somut akış isimleri verildiğinde kapsam daha netleşir. Ayrıca sonunda test listesi istemelisin, çünkü koruma talebinin gerçekten işe yarayıp yaramadığını manuel olarak kontrol etmen gerekir. ### Vibe coding'de en güvenli çalışma alışkanlığı ne? En güvenli alışkanlık küçük kapsamla ilerlemektir. Bir değişiklik seç, önce plan iste, minimum dosya değişikliği yaptır, sonra eski çalışan akışları tekrar dene. Her başarılı adımdan sonra yeni isteğe geç. Bu yaklaşım seni yavaşlatmaz; tam tersine, büyük ve belirsiz değişikliklerden doğan saatlerce hata arama süresini azaltır. Vibe coding hız verir ama kontrol sende kalmalıdır.