- Son dönemde Andrej Karpathy'nin şu sözleri gündem oldu: "Kendinizi vibe'a bırakın, üstel büyümeyi kabul edin ve hatta kodun var olduğunu bile unutun."
- "Vibe Coding", net bir plan veya doğrudan kod yazımı olmadan problem çözümünü AI araçlarına devretme eğilimini ifade eder
- LLM (büyük dil modeli) ajanları üzerinden doğal dille komut verildiğinde kod üretmek ve değiştirmek mümkün hale geldi
- 2022: ChatGPT'de kod kopyalama ve düzenleme mümkündü
- 2023: IDE ile entegre Copilot üzerinden kod inceleme ve düzenleme mümkün oldu
- 2024~2025: Projedeki birden fazla dosyayı değiştirme, kendi kendine test etme ve düzeltme mümkün hale geldi
"Vibe Coding" nasıl çalışır
- Hem teknik hem de teknik olmayan kullanıcılar, LLM tabanlı ajanlar aracılığıyla proje kurulumu yapabilir
- Basit komutlarla web sitesi veya uygulama oluşturulabilir (ör. "bir kayak merkezi web sitesi oluştur")
- İlk kurulumdan sonra otomatik düzeltme ve test yapılabilir
-
Örnekler:
- Cursor, GitHub Copilot Agent Mode vb. araçlar dosya düzenleyebilir ve komut çalıştırabilir
- Otomatik düzeltme ve test yapılır → tutarsızlık nedeniyle hatalar oluşabilir
Ajanların özerklik sorunu
- Ajanlar işleri otomatik olarak yapabilir, ancak tam anlamıyla özerk değildir
- Kullanıcı onayı olmadan çalıştırıldığında risk doğabilir (ör. YOLO modunda komut yürütme)
- Kod kalitesi ve doğruluk sorunları ortaya çıkabilir
-
Başlıca sorunlar:
- Mevcut kodu yeniden kullanamama → aynı bileşeni tekrar tekrar oluşturma
- İstemci tarafında sunucu tarafı mantığını çalıştırmaya çalışma
- Hatalı kod düzeltmesinden sonra hata oluşması → düzeltme sırasında başarısız olma
- Unit test yazamama veya kodu bozma
Gerçekçi sınırlamalar
- Claude 3.7 Sonnet gibi modeller eğitim verisinin sınırlarını aşamaz
- Kod tabanında bağlam kaybolduğunda tutarlı değişiklik yapmak mümkün olmaz
- Kod büyüdükçe performans düşer ve bağlamı korumak zorlaşır
- LLM'in bağlam penceresi aşıldığında tutarlılık sorunları ortaya çıkar
-
Somut sorun örnekleri:
- TypeScript arayüzlerini kopyalama
- İstemcide sunucu mantığını çalıştırma
- Yinelenen bileşenleri düzeltmede başarısız olma
- Unit test yazmada başarısız olma
- Kod refactoring sonrasında hataları düzeltememe
Sorunu çözme girişimleri
- Claude Plays Pokémon: ajan gerçek zamanlı etkileşimle oyunu oynar
- Belleği koruma ve tekrar eden hataları düzeltmede başarısız olur
- Uzun vadeli bellek kurmada başarısız olur → sürekli hatalar ortaya çıkar
-
İyileştirme olasılıkları:
- MCP (Model Context Protocol) ve bellek yönetiminin geliştirilmesi gerekir
- Kod düzenlerken LLM'in önceki değişiklikleri doğru biçimde yansıtması gerekir
- Alana özgü bellek ve görev geçmişinin korunması gerekir
Sonuç
- "Vibe Coding", işlevsel bir kavramı hayata geçirmede %80 seviyesine kadar ulaşabilir; ancak güvenilir ve güvenli bir ürün üretmek için deneyimli insanların emeği gerekir
- AI ajanları, yetkin kişilerin bağımsız olarak daha fazlasını üretmesini sağlayabilir; ancak deneyim ve sezgi gerektiren zor problemleri çözebilen insanları ikame edemez
- Mevcut seviyede "Vibe Coding"in gerçekten kullanışlı bir ürüne dönüşmesi zordur ve yetkin geliştiricilerin yardımı şarttır
- "Vibe Coding", kod yazımının yalnızca yardımcı bir aracıdır; tam bir ikame değildir
9 yorum
Özellikle "mevcut seviye" kısmı dikkatimi çekiyor. Acaba LLM'lere insanın zaman kavramıyla mı bakıyoruz?
Yapay zeka ile kod yazarken hissettiğim şey şu: Yapay zekaya kodun yalnızca bir kısmını verseniz bile bağlamı anlayabilmesini sağlamak için, tek sorumluluk ilkesi + TDD tarzı birimlere bölme yaptığınızda, büyük bağlamı okumasına gerek kalmadan, parçanın bağlamıyla da yeterince kavrayabilmesi gerekiyor.
Benim yapay zekayı hobi amaçlı en çok kullandığım alan web oyunu geliştirme ve buna katılıyorum. Ölçek belli bir seviyenin üstüne çıkınca, bir noktadan sonra yapay zekanın odaklanma diyebileceğim bazı kısımlarda belirgin biçimde zayıfladığını fark ediyorsunuz. Ben bunu şu şekilde kullanıyorum: Oyunun içindeki tüm ağaç yapısını ve kaynak kodunu, TOC dahil tek bir dosyada birleştiriyorum; sonra yeni bir thread oluşturup o dosyayı yüklüyor ve çalışmaya devam ediyorum. Ayrıca soru sorarken her zaman mevcut projenin adını açıkça belirterek yanıt vermesini istiyorum. Buna rağmen hâlâ tatmin edici olmayan kısımlar var ama... geçmişte gerçek hayatın yoğunluğu yüzünden başlamayı bile göze alamadığım hobilerimi, nispeten kısa bir sürede tamamlıyor olmaktan çok memnunum.
Kabaca yapıp geri kalan detayları sonradan düzeltme kalıbı gerçekten hoşuma gidiyor
Çeşitli denemeler yapılıyor ama bellek sınırlarının net olduğu da ortada. PoC düzeyinde iyi. Olasılık/kullanılabilirlik açısından hızlı ilerlemek için iyi.
Asıl sorun, daha da fazla uzmanlık gerektirmesi.
Kodlamada zamanın büyük kısmının debug yapmak ve kod okumakla geçtiğini düşünürsek, bunun oldukça abartılı olduğunu düşünüyorum. Yapay zeka yapanlar hep bu tonda konuşuyor ama en azından mevcut duruma bakınca öyle görünmüyor. İnsan eli gerekmeyen bir noktaya gelinirse, özellikle kodlamaya neden ihtiyaç olsun ki? API açıklamasını verip LLM’i backend olarak kullanmak daha iyi olmaz mı?
Pratikte şema ayarlayıp alarak çoğunlukla bu şekilde kullanıyoruz.
Katılıyorum. Başlarda neredeyse büyüleyici bir geliştirme hızı gösteriyor, ancak ölçek büyüyüp dosya sayısı arttıkça bunu yöneten sorumlu kişi (burada insan) bunu etkili şekilde yönetemezse, elinize yalnızca hantallaşmış ve hatalarla dolu bir çıktı geçiyor. İş artık geri döndürülemez bir noktaya gelirse, sadece kredi (Windsurf) ya da istekleri (Cursor) boşa harcamış oluyorsunuz. Zamanla daha iyi hale gelecektir ama şu anda AI koduna %100 güvenmemek gerekir.
Hacker News görüşü
"Yapay zeka abartısı vs. gerçeklik" arasındaki büyük fark, insanların sıkça dile getirdiği üretkenlik rakamlarında yatıyor. Örneğin, YC partnerleri bir şirketin kodlama performansında "100 kat hız artışı" iddiasını aktarıyor. Böyle bir iddia dış gözlemciler için açıkça görünür olurdu; dolayısıyla öz-bildirime ihtiyaç duyulmazdı.
Şu anda outsourcing furyasının peşinden gidiyoruz. Tüm bu abartılı iddialara rağmen gerçeklik farklı. LLM kodlama ajanlarına dair tartışmaları ayırt etmek zor.
Bu, Go topluluğunun bilgisayarların insan Go oyuncularını yenemeyeceğini söylemesine benziyor. Daha iyi sıralama bulan modellere dair örnekler zaten var. Uygun teşvik ve zaman verilirse bilgisayarlar bizi geçecek.
Kodlama LLM'leriyle ilgili yeni bir sorun paylaşılıyor. Offshore geliştiriciler ekibe tamamen entegre durumda. Ancak LLM kullanımı kontrolsüz ve dağınık olduğu için gönderilen pull request'ler bir kâbusa dönüşüyor.
"Vibe Coding", fikrin %80'ini hayata geçirebilir. Ancak güvenilir, güvenli ve değerli bir şey üretmek için deneyimli bir insan gerekir.
Yakın zamanda Claude ve OpenAI o3-mini kullanarak Matlab kodunu Python'a çevirmeye çalıştım ama performans çok kötüydü. Neredeyse her önemli satırda hata vardı. Otomasyon gerektiren bir işti ama başarısız oldu.
Test hiç olmamasındansa "Vibe-TDDing" yapmak daha iyi. Kodlama ve test konusunda anlayışınız varsa, LLM kullanarak olumsuz dış etkileri azaltabilirsiniz.
SaaS nasıl kurulur diye paylaştıktan sonra tuhaf şeyler oldu. API anahtarı kullanımı tavana vurdu, abonelikler atlatıldı ve veritabanında rastgele şeyler oluştu. Bu muhtemelen bir şaka.
Birçok mühendisin AI kodlama araçlarının yeteneklerini ve üretkenlik etkisini küçümsediğini görmek, mesleğim için bana güven veriyor. Cursor'ı bırakmayacağım.