Seviye 1 · Oturum Ustalığı
Kimlik hedefi: "Ajana net iş tarif eden kişi." Bu seviyede tek bir Claude Code oturumunu baştan sona bilinçli yönetmeyi öğreniyorsunuz: işi tarif etmek, yapılanı izlemek, "bitti" dendiğinde inanmamak.
Bu seviyenin kavramları (başlamadan 10 dk sözlük ön-okuması): oturum · istem · bağlam penceresi · token · compaction · plan mode · diff · halüsinasyon · migration
DERS 1.1 İlk istem: işi tarif etme sanatı
1 · Tanımİstem (prompt), yapay zekâya verdiğiniz yazılı iş tarifidir. Vibe coding'de sizin "kaleminiz" kod değil, istemdir.
2 · İşlev ve amaçÇıktının kalitesi, istemin kalitesinin aynasıdır. Müteahhide "güzel bir ev yap" derseniz sonucu şansa bırakırsınız; "3 oda, güney cephe, şu bütçe, şu tarihe" derseniz denetlenebilir bir iş ısmarlamış olursunuz. Kötü istem, AI'ı tahmin yürütmeye zorlar — tahminlerin faturası sizin ürününüze kesilir.
3 · Nasıl yapılırİyi istem 4 parçadan oluşur: bağlam (neredeyiz) + hedef (ne istiyorum) + kısıtlar (nelere dokunma / nelere uy) + kabul kriteri (bittiğini neyle anlayacağız). Şablon:
Bağlam: [Proje ne, hangi klasörde, şu an ne durumda]
Hedef: [Tek cümlede ne istiyorum]
Kısıtlar: [Şu dosyalara dokunma / şu kütüphaneyi kullan / tasarımı bozma]
Kabul kriteri: [Şunu yapabildiğimde iş bitmiştir; şu komut hatasız geçmelidir]
Örnek: "Bağlam: sandbox klasöründeki not uygulaması. Hedef: her nota kaç karakter yazıldığını gösteren sayaç ekle. Kısıt: mevcut tasarım renklerini değiştirme, yeni paket kurma. Kabul: notu yazarken sayaç canlı güncellenmeli, npm run build hatasız geçmeli."
4 · Ne ters gider + çözümüEn sık hata: hedefi söyleyip kısıtı ve kabul kriterini atlamak. Belirtisi: AI "iyileştirme" bahanesiyle istemediğiniz yerlere dokunur, siz de bitti mi bitmedi mi bilemezsiniz. Çözüm: işi geri sarmayın; kısıt ve kriteri ekleyip "bu tarife göre yeniden değerlendir" deyin. İkinci sık hata: tek istemde beş iş istemek — işler birbirine dolanır. Çözüm: bir istem = bir iş.
5 · AlternatiflerKısa/net işlerde tek cümle yeter ("yazım hatasını düzelt") — 4-parça şablon bürokrasi olur. Büyük/belirsiz işlerde ise şablon bile yetmez: önce plan mode (ders 1.3) ile keşif yaptırılır.
6 · Denetim penceresiKırmızı bayraklar: (a) AI, istemediğiniz dosyalara dokundu → kısıt ihlali; (b) sonucu görünce "ben bunu mu istemiştim?" duygusu → kabul kriteri baştan yoktu, bu sizin bulgunuz. Kontrol adımı: iş bitince kendi kabul kriterinizi kendiniz deneyin (uygulamayı açın, o özelliği kullanın). İkinci-ajan denetim istemi (yeni/temiz bir oturumda):
Şu işi bir başka ajan yaptı: [isteminizi yapıştırın]. Yapılan değişiklikleri incele:
istemdeki kısıtlara uyulmuş mu, kabul kriteri gerçekten sağlanıyor mu? Sadece denetle,
hiçbir şeyi değiştirme. Bulgularını "uyuyor / uymuyor + kanıt" formatında listele.
7 · Mini egzersiz (SANDBOX)Üret: yukarıdaki karakter-sayacı istemini sandbox uygulamasında aynen kullanın. Denetle: kabul kriterinin iki maddesini kendiniz test edin (sayaç canlı mı, build geçiyor mu).
8 · Kontrol soruları(1) İyi istemin 4 parçası nedir? (2) Kabul kriteri olmayan bir işin "bittiğini" kim, neye göre söylemiş olur? (3) "Bir istem = bir iş" kuralı neyi önler?
9 · Mentor istemi
VibeUni Seviye 1 Ders 1.1'in (istem yazma: bağlam+hedef+kısıt+kabul kriteri) hocası ol.
Önce konuyu bana 3 basit adımda anlat. Sonra benden gerçek hayatımdan bir iş isteyip
onu birlikte 4-parça isteme çevirelim. Sonunda dersin 3 kontrol sorusunu sözlü sınav
gibi sor, cevaplarımı değerlendir, eksiklerimi söyle. Jargon kullanma.
DERS 1.2 Bağlam penceresi: ajan neden "unutuyor"?
1 · TanımBağlam penceresi = modelin aynı anda aklında tutabildiği metin; token ile ölçülür. Dolunca compaction devreye girer: eski mesajlar özetlenir, detay kaybolur.
2 · İşlev ve amaçBunu bilmeyen kullanıcı, uzun oturumda kalitenin neden düştüğünü anlamaz ve AI'a kızar. Bilen kullanıcı, bağlamı bütçe gibi yönetir: masaya sadece işle ilgili evrakı koyar.
3 · Nasıl yapılırÜç pratik kural: (1) Konu değişince /clear — yeni işe temiz sayfayla başlayın; eski konunun çöpü yeni işin kalitesini düşürür. (2) Dosya boca etmeyin — "şu klasördeki her şeyi oku" yerine "sadece şu iki dosyaya bak". (3) Uzun oturumda ara özet isteyin: "şu ana kadar ne yaptık, neredeyiz — 5 maddede özetle" (bu özet, compaction'da kaybolacak bilgiyi güvenceye alır).
4 · Ne ters gider + çözümüBelirti: AI, yarım saat önce kararlaştırdığınız bir kuralı "unutur". Sebep: compaction o detayı özete almamıştır. Çözüm: kuralı tekrar yazın; kalıcı olması gerekiyorsa oturuma değil dosyaya koyun (Seviye 2'de CLAUDE.md dersi tam bunun için var).
5 · AlternatiflerKısa işlerde hiçbirini düşünmeyin — pencere zaten yetiyor. Çok büyük işlerde alternatif strateji: işi oturumlara bölmek (her oturum tek parça) ya da alt ajanlara dağıtmak (Seviye 3).
6 · Denetim penceresiKırmızı bayrak: oturum uzadıkça cevaplar genelleşiyor, daha önce söylenen kurallar deliniyor. Kontrol: "Bu oturumda sana verdiğim kısıtları listele" deyin — listede eksik varsa bağlam aşınmış demektir; kritik işse /clear + tarifle yeniden başlayın.
7 · Mini egzersiz (SANDBOX)Üret: bir oturumda önce bir kural koyun ("değişkenlere Türkçe isim verme" gibi), sonra 15-20 mesajlık alakasız sohbet yürütün, sonra kurala tabi bir iş isteyin. Denetle: kurala uyulmuş mu? (Çoğu zaman uyulur — ama aşınmayı gözlemleme refleksi kazanırsınız.)
8 · Kontrol soruları(1) Compaction'da ne kaybolur? (2) Ne zaman /clear kullanılır? (3) Kalıcı olması gereken kural nereye yazılır, neden oturuma değil?
9 · Mentor istemi
VibeUni Seviye 1 Ders 1.2'nin (bağlam penceresi, token, compaction, /clear) hocası ol.
Bağlam penceresini masa metaforuyla anlat, compaction'ı örnekle göster. Sorularımı
cevapla. Sonunda 3 kontrol sorusunu sor ve cevaplarımı değerlendir. Jargon kullanma.
DERS 1.3 Plan mode: önce plan, sonra iş
1 · TanımPlan mode = Claude Code'un "incele ve planla ama hiçbir şeye dokunma" kipi. Shift+Tab ile açılır; AI dosyaları okur, plan sunar, siz onaylayınca uygulamaya geçer.
2 · İşlev ve amaçDenetimin ilk ve en ucuz kapısı: hatayı iş yapılmadan önce, plan aşamasında yakalarsınız. Yapılmış işi geri almak pahalıdır; plandaki yanlışı düzeltmek bedavadır. İnşaat metaforu: projeyi çizimken değiştirmek ile duvarı yıkıp yeniden örmek arasındaki fark.
3 · Nasıl yapılır(1) Riskli/büyük işlerde Shift+Tab ile plan mode'a geçin. (2) İşi 4-parça şablonla tarif edin. (3) Gelen planı OKUYUN — özellikle "hangi dosyalara dokunacak" listesini. (4) İtirazlarınızı planda dile getirin ("3. adım gereksiz, çıkar"). (5) Plan aklınıza yatınca onaylayın. Ne zaman plan mode: birden çok dosyaya dokunan işler, "nasıl yapılacağını bilmediğim" işler, geri alması zor işler. Ne zaman gerek yok: tek dosyalık küçük düzeltmeler.
4 · Ne ters gider + çözümüHata 1: planı okumadan onaylamak — plan mode'u tiyatroya çevirir. Çözüm: en azından "dokunulacak dosyalar" ve "kapsam dışı" bölümlerini her zaman okuyun. Hata 2: planda her şeyi mükemmelleştirmeye çalışıp işe hiç başlayamamak. Çözüm: plan "yeterince iyi" olunca başlayın; küçük pürüzler işte düzelir.
5 · AlternatiflerKüçük işte plan mode yerine istemin sonuna "önce ne yapacağını 3 maddede söyle, onayımı bekle" eklemek de hafif bir plan kapısı kurar.
6 · Denetim penceresiPlan okurken kırmızı bayraklar: (a) dokunulacak dosya listesi işin tarifinden geniş ("neden 12 dosya?"); (b) planda geri alınamaz bir işlem var (veritabanı silme/değiştirme, toplu silme) — bkz. ders 1.7; (c) plan, sizin koyduğunuz bir kısıtı "iyileştirme" adına deliyor. İkinci-ajan denetimi (temiz oturumda):
Şu planı bir ajan hazırladı: [planı yapıştırın]. Sen uygulamadan SADECE eleştir:
gereksiz genişlik var mı, riskli adım var mı, eksik durum (edge case) var mı?
En fazla 5 maddelik eleştiri listesi ver.
7 · Mini egzersiz (SANDBOX)Üret: sandbox uygulamasına "notları önemli/normal diye işaretleme" özelliğini plan mode ile isteyin; plana en az bir itiraz yazın (gerçek bir itiraz bulun). Denetle: onayladığınız planla yapılan işi karşılaştırın — plan dışına çıkılmış mı?
8 · Kontrol soruları(1) Plan mode hangi üç iş türünde şarttır? (2) Planda ilk okumanız gereken iki bölüm hangileri? (3) Plandaki hata ile yapılmış işteki hatanın maliyet farkı nedir?
9 · Mentor istemi
VibeUni Seviye 1 Ders 1.3'ün (plan mode) hocası ol. Plan mode'un ne olduğunu ve ne
zaman kullanılacağını inşaat metaforuyla anlat. Bana örnek bir plan göster ve içine
bilerek 2 sorun sakla; bulabilecek miyim dene. Sonunda 3 kontrol sorusunu sor.
DERS 1.4 Ajanın yaptığını okuma: diff
1 · TanımDiff = değişikliğin satır satır gösterimi: eksili/kırmızı satırlar silinen, artılı/yeşil satırlar eklenen. Claude Code her düzenlemede size diff gösterir.
2 · İşlev ve amaçKod bilmeyenin en güçlü denetim aracı. Kodu yazamazsınız — ama şunları kod bilmeden okuyabilirsiniz: AI hangi dosyalara dokundu, ne kadar dokundu, silme mi ekleme mi yaptı. Bu üç bilgi, denetimin yarısıdır.
3 · Nasıl yapılırHer diff'te üç soruyu sorun: (1) Dosya doğru mu? "Menüyü değiştir" dedim, neden ödeme dosyası değişiyor? (2) Boyut orantılı mı? Küçük istek → 400 satırlık diff = alarm. (3) Kırmızı satırlar ne? Eklenen kadar önemlisi silinendir: "bu silinen blok neydi, neden gitti?" — bilmiyorsanız AI'a sorun: "bu diff'te sildiğin bölüm ne işe yarıyordu, silmek neden güvenli?"
4 · Ne ters gider + çözümüHata: diff'leri okumadan hep onaylamak (özellikle otomatik-onay modunda). Sonuç: haftalar sonra "bu ne zaman değişmiş?" sürprizleri. Çözüm: en azından dosya adlarını HER ZAMAN okuyun — 2 saniyelik bakış, sürprizlerin çoğunu yakalar.
5 · AlternatiflerDiff'i satır satır okuyamayacak kadar büyük işlerde: "yaptığın değişiklikleri dosya dosya, teknik olmayan dille özetle" isteyin ve özeti diff'teki dosya listesiyle karşılaştırın — özette geçmeyen dosya varsa sorun.
6 · Denetim penceresiKırmızı bayraklar: tariften geniş dosya listesi · orantısız boyut · açıklanamayan silmeler · isteminizde geçmeyen yeni paket/bağımlılık eklenmesi. İkinci-ajan denetimi (temiz oturumda):
Bu projede az önce şu iş yapıldı: [istem]. Son değişiklikleri (git diff) incele ve bana
teknik olmayan dille raporla: hangi dosyalar neden değişmiş, işin tarifiyle örtüşmeyen
değişiklik var mı, silinenler arasında riskli görünen var mı? Hiçbir şeyi değiştirme.
7 · Mini egzersiz (SANDBOX)Üret: sandbox'ta küçük bir değişiklik isteyin. Denetle: diff'e üç soruyu uygulayın ve bir silinen satır seçip "bu neden silindi?" diye sorun — cevabın ikna ediciliğini tartın.
8 · Kontrol soruları(1) Diff'te üç temel soru nedir? (2) Neden silinen satırlar eklenenlerden daha çok dikkat ister? (3) Kod bilmeden diff'ten hangi üç bilgiyi okuyabilirsiniz?
9 · Mentor istemi
VibeUni Seviye 1 Ders 1.4'ün (diff okuma) hocası ol. Bana kısa, uydurma bir diff göster
(10-15 satır) ve satır satır ne anlama geldiğini öğret. Sonra içinde kasıtlı bir "kapsam
dışı değişiklik" olan ikinci bir diff göster; bulmamı iste. Sonunda 3 kontrol sorusu.
DERS 1.5 "Bitti" lafına güvenmeme: doğrulama + ikinci ajan
1 · TanımDoğrulama = işin bittiğine dair kanıtı AI'ın beyanından değil, gözlemden almak: çalıştır, dene, test/build koştur. İkinci-ajan denetimi = işi yapan ajana değil, temiz bir oturuma denetletmek.
2 · İşlev ve amaçBu ders, bu programın kalbidir. "Tamamdır, çalışıyor ✓" cümlesi bir iddiadır, kanıt değil. AI kendi işine karşı iyimserdir (tıpkı insanlar gibi). Aynı ajana "emin misin?" demek de zayıf denetimdir — kendi hatasına kördür. Temiz oturum, önyargısız bakar.
3 · Nasıl yapılırÜç katmanlı doğrulama merdiveni, ucuzdan pahalıya: (1) Kendin dene: uygulamayı aç, o özelliği bizzat kullan — kabul kriterindeki maddeleri tek tek işaretle. (2) Mekanik kapılar: npm run build ve varsa testler — "geçti/geçmedi" cevabı tartışmasızdır. (3) İkinci ajan: temiz oturumda denetim istemi (aşağıda). Kritik işlerde üçü birden; küçük işlerde ilk ikisi yeter.
4 · Ne ters gider + çözümüKlasik senaryo: "bitti" dendi, siz denemediniz, üç gün sonra kullanıcı buldu. Çözüm sistemiktir: kabul kriterine (ders 1.1) her zaman "şu komut hatasız geçmeli" gibi mekanik bir madde koyun — doğrulamayı isteğe bağlı olmaktan çıkarır. İkinci tuzak: AI'ın "test ettim, çalışıyor" demesi. Sorun: neyi nasıl test ettiğini görmediniz. Çözüm: "hangi komutu çalıştırdın, çıktısı neydi — aynen göster" deyin.
5 · AlternatiflerHer işte üç katman şart değil: yazı düzeltmesi için build yeter; para/veri işleyen kodda üç katman + gerçek deneme şart. Denetim derinliğini işin geri alınamazlık derecesine göre ayarlayın.
6 · Denetim penceresiKırmızı bayraklar: kanıtsız "çalışıyor" beyanı · "testleri geçti" ama test çıktısı gösterilmedi · sizin denemediğiniz hiçbir akış yok. İkinci-ajan denetim istemi (temiz oturum — bu dersin ana aracı):
Bu projede "[işin tarifi]" işinin bittiği iddia ediliyor. Sen bağımsız denetçisin:
1) Değişiklikleri incele, 2) kabul kriterlerini gerçekten sağlayıp sağlamadığını
kanıtıyla kontrol et (gerekiyorsa build/test çalıştır), 3) kırılabilecek uç durumları
listele. Hiçbir şeyi düzeltme — sadece "GEÇTİ/KALDI + kanıt" raporu ver.
7 · Mini egzersiz (SANDBOX)Üret: sandbox'a küçük bir özellik yaptırın. Denetle: (a) kendiniz deneyin, (b) build koşturun, (c) ikinci-ajan denetimini uygulayın. Üç katmanın bulgularını karşılaştırın — ikinci ajan ilk ikisinin görmediği ne buldu?
8 · Kontrol soruları(1) "Bitti" beyanı neden kanıt değildir? (2) Doğrulama merdiveninin üç basamağı nedir? (3) Neden işi yapan ajana değil temiz oturuma denetletiriz?
9 · Mentor istemi
VibeUni Seviye 1 Ders 1.5'in (doğrulama + ikinci-ajan denetimi) hocası ol. "İddia ile
kanıt farkını" günlük hayat örnekleriyle anlat. Bana üç katmanlı doğrulama merdivenini
ezberletme; bir senaryo ver, hangi katmanları uygulayacağımı sor. Sonunda 3 kontrol sorusu.
DERS 1.6 Rayından çıkan oturum: durdur, yönlendir, baştan başla
1 · TanımRayından çıkma = AI'ın yanlış yöne gitmesi: yanlış anlamış, yanlış dosyada geziyor ya da hatayı yamayla kapatıp aynı hatayı büyütüyor. Araçlarınız: ESC (o an durdur), yeniden yönlendirme (yeni talimat), /clear (temiz sayfa).
2 · İşlev ve amaçBatık maliyet tuzağına karşı sigorta: "bu kadar ilerledik, devam etsin" duygusu, yanlış yönde daha da ilerletir. İyi yönetici, yanlış giden işi erken durdurur.
3 · Nasıl yapılırKarar ağacı: (1) Küçük sapma (yanlış dosyaya yöneldi) → ESC + tek cümle düzeltme: "dur — o dosya değil, şu dosya." (2) Yanlış anlama (işin özü yanlış anlaşılmış) → ESC + tarifi baştan, bu kez 4-parça şablonla. (3) Kısır döngü (aynı hataya üçüncü yama) → devam ettirmeyin; /clear + temiz oturumda işi yeniden tarif edin ve öğrendiklerinizi tarife ekleyin ("şu yaklaşım denendi, işe yaramadı — farklı yol izle"). Üç yama kuralı: aynı soruna üçüncü yamada oturumu değiştirin.
4 · Ne ters gider + çözümüHata: kızgınlıkla "hayır! yanlış! düzelt!" yazmak — bilgi içermeyen düzeltme, yeni tahmin turu başlatır. Çözüm: her düzeltme yeni bilgi içersin: ne yanlış, doğrusu ne, neye dokunulmayacak. İkinci hata: bozuk oturumda ısrar — bağlam kirlenmiştir, yanlış varsayımlar özetlere sinmiştir. Temiz sayfa çoğu zaman daha hızlıdır.
5 · Alternatiflerİş yarı yolda ama oturum yorgunsa: önce "şu ana kadarki durumu ve kalan işleri 5 maddede yaz" deyin, çıktıyı kopyalayın, /clear sonrası yeni oturuma bu özetle başlayın — ilerlemeyi kaybetmeden temiz sayfa.
6 · Denetim penceresiKırmızı bayraklar (durdurma sinyalleri): aynı hataya 3. yama · "bir de şunu deneyelim" turlarının artması · dokunulan dosya sayısının istikrarlı büyümesi · sizin anlamadığınız gerekçelerle kapsam genişlemesi. Kontrol: 10 dakikada bir kendinize sorun — "şu an hangi işi yapıyoruz ve bu, benim istediğim iş mi?"
7 · Mini egzersiz (SANDBOX)Üret: kasıtlı belirsiz bir istem verin ("uygulamayı daha iyi yap"), AI yanlış yöne gidince ESC ile durdurun. Denetle: aynı işi 4-parça şablonla yeniden isteyin; iki sonucu karşılaştırın — fark, tarif kalitesinin kanıtıdır.
8 · Kontrol soruları(1) Üç yama kuralı nedir ve neden var? (2) İyi bir düzeltme mesajında ne bulunur? (3) İlerlemeyi kaybetmeden temiz sayfaya nasıl geçilir?
9 · Mentor istemi
VibeUni Seviye 1 Ders 1.6'nın (rayından çıkan oturumu yönetme) hocası ol. Bana üç
senaryo ver (küçük sapma / yanlış anlama / kısır döngü) ve her birinde ne yapacağımı
sor; cevaplarımı karar ağacına göre değerlendir. Sonunda 3 kontrol sorusu.
DERS 1.7 Vibe coding'in sınırları (anti-müfredat)
1 · TanımBu ders "nasıl yapılır" değil, "ne zaman yaptırılmaz" dersidir. İki sınır türü: (a) AI'a serbest bırakılmayacak işler, (b) AI'ın kendinden eminliğine güvenilmeyecek durumlar (halüsinasyon).
2 · İşlev ve amaçVibe coding'in tek gerçek felaket senaryosu, geri alınamaz hasardır. Kod bozulursa eski kayda dönersiniz (Seviye 2); ama silinen canlı veri, yanlış çekilen para, sızan şifre geri gelmez. Sınırları bilmek, gaza değil frene hâkim olmaktır — ehliyetin asıl konusu budur.
3 · Nasıl yapılır — serbest bırakılMAyacak işler listesiBu işlerde AI öneri hazırlar, son adımı siz atarsınız (veya adım adım onayla ilerletirsiniz):
- Canlı veritabanına yapısal müdahale (migration, tablo/sütun silme, toplu güncelleme) — önce yedek, sonra deneme kopyasında prova, en son canlı.
- Ödeme kodu — tutar hesabı, iade, abonelik mantığı: satır satır anlayarak, gerçek küçük tutarla test ederek.
- Güvenlik-kritik değişiklikler — giriş/yetki mantığı, şifre işleme: mutlaka ikinci-ajan denetimi + sizin senaryo testiniz ("başkasının verisini görebiliyor muyum?").
- Toplu silme/üzerine yazma —
rm -rf, "force" içeren komutlar, toplu e-posta gönderimi: komutun ne yapacağını açıklatmadan onay yok.
4 · Ne ters gider + gerçek vakalar
Gerçek vaka 1: Gerçek bir üründe, veritabanı şeması uyuşmazlığını çözmek için "sıfırla ve yeniden kur" tarzı bir komut (
db push --force-resetbenzeri) çalıştırıldı — canlı verinin tamamı silindi. Ders: "force/reset" kelimesi geçen hiçbir komut, canlı sistemde açıklamasız onaylanmaz.
Gerçek vaka 2: AI, var olmayan bir kütüphane fonksiyonunu kendinden emin biçimde kullandı; hata ancak çalıştırınca ortaya çıktı. Ders: eminlik tonu, doğruluk kanıtı değildir — kanıt, çalışan koddur.
Çözüm kalıbı: "Claude emin görünüyor ama içimde şüphe var" anında iki hamle: (1) "bu yaklaşımın kaynağı ne, hangi dokümana dayanıyor?" diye sorun; (2) ikinci ajana bağımsız doğrulatın.
5 · AlternatiflerSınır işleri tamamen elle yapmak da bir seçenek değil — hata oranınız AI'dan yüksek olabilir. Doğru model: AI hazırlar + açıklar, siz anlayıp onaylarsınız. Anlamadığınız hiçbir şeyi onaylamayın; "bunu bana lise öğrencisine anlatır gibi anlat" demek meşru bir denetim aracıdır.
6 · Denetim penceresiKırmızı bayraklar: komutta force, reset, drop, delete, rm -rf kelimeleri · "canlı/prod" ortamda çalışıldığının fark edilmemesi · AI'ın kaynak gösteremediği kesin iddialar. Onay öncesi istem:
Bu komutu onaylamadan önce bana açıkla: tam olarak ne yapacak, geri alınabilir mi,
en kötü senaryoda ne kaybederim, daha güvenli bir alternatifi var mı?
7 · Mini egzersiz (SANDBOX)Üret: AI'dan sandbox'taki bir klasörü silen komut hazırlamasını isteyin ama ÇALIŞTIRTMAYIN. Denetle: yukarıdaki onay-öncesi istemi uygulayın; "en kötü senaryo" cevabını kendi cümlelerinizle yazın. (Bu refleks, gerçek üründe sizi kurtaracak olan şeydir.)
8 · Kontrol soruları(1) Serbest bırakılmayacak dört iş kategorisi nedir? (2) Kod hatası ile veri hatası arasındaki temel fark nedir? (3) "Emin görünüyor ama şüphedeyim" anında iki hamleniz nedir?
9 · Mentor istemi
VibeUni Seviye 1 Ders 1.7'nin (vibe coding'in sınırları) hocası ol. Bana 6 kısa senaryo
ver; her birinde "serbest bırakılır / son adım bende / asla" kararını vereyim, sen
değerlendir. Sonunda 3 kontrol sorusunu sor.
Seviye 1 Mezuniyeti
Görev (SANDBOX): Sandbox uygulamasına orta boy bir özelliği (örn. notları arama kutusu) şu zincirle ekletin: 4-parça istem → plan mode → plana en az bir itiraz → onay → diff okuma (üç soru) → üç katmanlı doğrulama (kendin dene + build + ikinci-ajan denetimi). Zincirdeki her halkayı uyguladıysanız mezunsunuz.
Seviye-sonu mentor istemi (kümülatif):
VibeUni Seviye 1'in bitirme sınavını yap. Yedi dersin (istem, bağlam, plan mode, diff,
doğrulama, rayından çıkma, sınırlar) kontrol sorularından karışık 7 soru sor; her
cevabımı değerlendir. Zayıf çıktığım dersleri söyle ve o dersleri tekrar etmemi öner.
Sonraki seviye: seviye-2-proje.md — reponuzu ajana hazırlamak.