- Son dönemde IT sektöründe "vibe coding cleanup" adlı yeni bir hizmet kategorisi ortaya çıktı:
Vibe Coding Cleanup as a Service
- Yapay zeka tarafından üretilen kodların büyük kısmının production için uygun olmadığı gerçeği belirginleşirken, bunları düzenleyip düzelten yeni bir hizmet pazarı doğdu
- Andrej Karpathy 2025 başında "Vibe Coding" kavramını tanımladıktan sonra geliştiricilerin %92'si yapay zeka araçlarını kullanmaya başladı; ancak kod kalitesi düşüşü ve güvenlik açıkları sorunu ciddi biçimde ortaya çıktı
- Geliştiriciler fiilen yapay zekanın ürettiği tutarsızlıklar, tekrarlar ve mantıksız iş mantığını çözmeye uzmanlaşmış durumda; özel pazar yerleri ve danışmanlık hizmetleri yayılıyor
- Yapay zeka küçük görevlerde çok başarılı olsa da sistem bağlamını dikkate alamadığı için yapısal borç ve güvenlik sorunları üretiyor; bu da "temizlik ekonomisi" diye yeni bir endüstriyel fırsat yaratıyor
- Şirketlerin yapay zeka ile kodlamayı başarılı şekilde kullanabilmesi için prototipi yapay zekaya bırakırken, mimari, güvenlik ve test temizliği süreçlerine uzman insan kaynağı yatırımı yapması gerekiyor
Vibe coding'in ortaya çıkışı ve yayılması
- 2025 başında Andrej Karpathy "vibe coding" terimini kullanınca kavram yerleşti
- Doğal dil diyaloğu üzerinden tüm fonksiyonları üretme yaklaşımı
- Verimliliği 10 kat artırabileceği beklentisiyle hızla yayıldı
- GitHub'a göre geliştiricilerin %92'si yapay zeka kodlama araçları kullanıyor
- Copilot her ay milyarlarca satır kod üretiyor
- Ancak GitClear analizine göre yapay zeka kodu kullanıldığında %41 daha yüksek kod değişim oranı görülüyor
- İki hafta içinde geri alınan ya da yeniden yazılan kod miktarı belirgin biçimde artıyor
- Stanford araştırmasında, yapay zeka desteği kullanan geliştiricilerin güvenliği daha zayıf kod yazdığı, üstelik bunu daha güvenli sandığı görüldü
- Yapay zeka araçları; girdi doğrulama eksikliği, eski bağımlılıkların kullanımı ve muğlak tasarım kararları nedeniyle çeşitli anti-pattern'leri büyüten sorunlara yol açıyor
Temizlik ekonomisinin gerçeği
- Son dönemde IT sektöründe vibe coding cleanup adında yeni bir hizmet alanı sessizce ortaya çıktı
- İlk başta "yapay zekanın ürettiği darmadağın kodu düzeltmek" düzeyinde bir şakayken, artık gerçek bir iş fırsatına dönüşüyor
- 404 Media'nın araştırmasına göre bazı geliştiriciler yalnızca yapay zeka kodu temizleyerek kariyer kuruyor
- "AI spaghetti" diye anılan tutarsızlıkları, tekrarları ve alakasız mantığı söküp atma işi
- Ulam Labs, Vibe Coding Cleanup hizmetini temel servislerinden biri olarak tanıtıyor
- VibeCodeFixers.com adlı özel bir pazar yeri de ortaya çıktı
- Birkaç hafta içinde 300'den fazla uzman katıldı ve onlarca proje eşleşmesi yapıldı
- Tipik müşteri: "binlerce dolarlık OpenAI kredisi tüketmiş ve yarım çalışan bir prototipe sahip startup"
Yapay zeka kodu neden başarısız oluyor
- Sorun, yapay zekanın doğası gereği kötü kod yazması değil; sistem bağlamını anlamadan yerel olarak optimize edilmiş kod üretmesi
- Sonuçta tutarsız desenler, tekrar eden mantık ve güvenlik boşlukları birikiyor; bu da teknik borç yaratıyor
- Georgetown University araştırmasına göre yapay zeka tarafından üretilen kodların en az %48'i güvenlik açığı içeriyor
- Gizli bilgilerin açığa çıkması, eski kütüphanelerin kullanımı, yük altında oluşan race condition'lar vb.
- Daha da ciddi olan nokta, geliştiricinin kendisinin yapay zekanın ürettiği kodu yeterince anlamadığı için sorunları doğru tespit edememesi
- Thoughtworks bunu "yetenek borcu" olarak tanımlıyor
- Ekiplerin kod bakım yeteneğini kaybedip yapay zekaya bağımlı hale gelmesi
Pazar fırsatı
- Temizlik pazarı hızla büyüyor, ancak somut rakamları ölçmek zor
- Gartner, 2028'e kadar kurumsal geliştiricilerin %75'inin yapay zeka kod asistanı kullanacağını öngörüyor
- Bu da çoğu projede temizlik ihtiyacı doğacağı anlamına geliyor
- Bunların yalnızca bir kısmı bile cleanup gerektirse, ölçek açısından çok büyük yeni bir pazar ortaya çıkıyor
- Ekonomik açıdan da cazip
- Startup'lar yapay zeka ile hızlıca MVP geliştiriyor, ardından temizlik için benzer süre ve maliyet harcıyor
- Buna rağmen hâlâ geleneksel geliştirmeden daha hızlı
- Temizlik uzmanları saat başına 200-400 dolar talep ediyor
- Sabit ücretli paketler, yapay zeka kod denetimi ve "Vibe-to-Production" pipeline'ları gibi ürünleştirilmiş hizmetler de yayılıyor
- Thoughtworks'e göre yapay zeka kullanılan projelerde refactoring oranı düşüyor, kod değişkenliği artıyor ve gerçek production'a geçmeden önce büyük ölçekli bir temizlik süreci zorunlu hale geliyor
- Çok sayıda danışmanlık şirketi, yapay zeka kodu cleanup veya remediation rolüne özel yetenekler işe almaya başladı
- Sonuç olarak cleanup pazarı gerçek, hızla büyüyor ve hâlâ geniş ölçüde keşfedilmemiş durumda
Mühendisliğe etkisi
- Yazılım geliştirme yöntemlerinde temel bir dönüşüm yaşanıyor
- Geliştirme süreci, yapay zeka uygular → insan mimari, test ve temizlikle ilgilenir şeklinde bir iş bölümü modeline dönüşüyor
- Gergely Orosz, yapay zeka araçlarını "çok hevesli bir junior geliştirici" olarak tanımlıyor; hızlı kod yazıyorlar ama her zaman denetime ihtiyaç duyuyorlar
- Ancak yapay zeka her zaman junior geliştirici seviyesinde kaldığı ve senior seviyeye yükselmediği için, temizlik uzmanlarının rolü sürekli gerekli olacak
- Yeni kariyer yolları da açılıyor
- Junior geliştiriciler temizlik becerilerini öğrenirse 2 yıl içinde senior seviyesinde maaşa ulaşabilir
- Yapay zekanın güçlü ve zayıf yönlerini anlayan senior'lar yüksek değer üretebilir
- Başarılı olan şirketler, yapay zekayı en çok kullananlar değil; temizlik süreçlerini sistematik biçimde kuranlar olacak
- Sağlam bir cleanup süreci kuran organizasyonlar pazarda rekabet avantajı elde edebilir
Donado Labs'in yaklaşımı
- Donado Labs, çok sayıdaki vibe code temizleme deneyimine dayanarak, yapay zekanın hızlandırma için faydalı olduğunu ama mutlaka uzman bir temizlik sürecine ihtiyaç duyduğunu vurguluyor
- Prototipleme ve tekrar eden işler için yapay zekayı, çekirdek mimari ile güvenlik ve testleri ise insanları görevlendiriyor
- "Vibe to Production" hizmetiyle yapay zeka prototiplerini kurumsal düzeye taşıyacak şekilde düzenliyor
- Buna testler, güvenlik güçlendirmesi ve dokümantasyon da dahil
- Yapay zeka ile kodlamayı başarılı kullanan şirketler, en çok yapay zeka kullananlar değil; yapay zekayı akıllıca kullanıp temizliğe yatırım yapanlar
- Temel nokta, teknik borç birikmeden cleanup'ı paralel yürütmek
- Yapay zekanın programcıların yerini alacağı iddiasına karşı asıl soru şu: "O kodun temizliğini kim yapacak?" ve işte gerçek iş fırsatı da burada
4 yorum
GPT’nin ilk dönemlerinde, kodlama işlerini dışarıya yaptıranlara “AI ile prototip yaptım, biraz tamamlanırsa yeter” deyip fiyat kırmaya çalışan insanlar vardı.
> Düzenleme uzmanları saat başına 200~400 dolar talep ediyor
Ama dürüst olmak gerekirse, bunu yapan biri gerçekten var mı?
Vibe coding ortaya çıkmadan önce de dağınık kodu toparlayan bir servis olsa iyi olur diye düşünmüştüm; gerçekten biri yapmış. Ama şirketimizde bunun devreye alınacağını sanmıyorum :(
Bir ara yapay zeka çizimlerinde parmakları düzelten dış kaynak işleri modaydı... ama şimdi onu bile artık yapmıyorlar.
Görünüşe göre AI cleanup da benzer bir yolu izleyecek gibi.
Hacker News görüşü
Oldukça uzun zamandır işletmeler üzerinden “düzenleme” projeleri alıyorum
Eskiden çoğunlukla neredeyse hiç çalışmayan kodu dış kaynak ajanslardan alırdık, ama bugünlerde bunun kaynağı sanki LLM’lere kayıyor
Sonuçta aynı sorunların tekrar ettiğini görüyorum
Sadece maliyeti düşürme yöntemi değişmiş gibi
Kısa yolu seçmek için anlaşılır nedenler var, ama bunun da bir bedeli olabileceğini yeterince fark etmediğinizde asıl sorun başlıyor
Yönetici, çalışan, dış kaynak fark etmeksizin sonuçlar benzer oluyor
Henüz özellikle vibe coding platformlarının yapısını iyileştirme hizmetini ayrı bir başlıkla pazarlamayı denemedim, ama belki artık denemenin zamanı gelmiştir
Avustralya yazılım pazarı küçük olduğu için böyle deneylerin sonuçlarını çok da duymuyoruz
Bence vibe coding ile dış kaynak geliştirme arasındaki fark, üretilen kod miktarında
Bir keresinde vibe coding ile basit bir yardımcı script yazdırdım; ben kendim yazsaydım muhtemelen mevcut kodun üçte biri kadar olurdu ve edge case’lerin çoğunu hiç ele almazdım bile (gereksiz exception handling de vardı, gerçekten faydalı olanlar da)
Benim yaptığım tek şey, kodu tararken yanlışlıkla home directory silinebilir diye temp dosyası silen tek bir satırı kaldırmak olmuştu
Ama sonra daha derin veri işleri yaparken bazı temp dosyalarının kaybolduğunu fark ettim; meğer iki yerde daha silme kodu varmış
Aslında insanın okuyup denetlemesi için kod miktarı fazla olduğundan hepsini kontrol etmek gerçekçi değil
Yine de hız açısından bakınca inanılmaz verimli olduğu kesin
Ben de bundan sonra kodu satır satır okumaktansa sandbox içinde AI ile test çalıştırmayı planlıyorum
Özellikle Claude Code gibi “plan mode” olan araçlarda büyük bir fark var
Şirketimde bu aralar Claude Code’u çok kullanıyorum; her zaman önce plan mode’da konuşarak “bunu nasıl uygulayacağız” diye soruyor, sonra birkaç tur konuşmayla iyi bir tasarıma yönelik ayrıntılı planı netleştiriyorum
Ardından AI hangi kodu üreteceğini (kod diff’iyle birlikte) tam olarak söylüyor ve ben son onayı verdikten sonra gerçek kodu üretiyor
Buna karşılık, geçmişte dış kaynak bir ekibin yazdığı kodu incelediğimde, içinden çıkılması imkânsız bir spagetti kod yığınıyla karşılaşmıştım
Sırf SEO için bile olsa siteye vibe-coding ile ilgili terimler eklemek iyi bir fikir olabilir
Ben de benzer bir şey düşündüm
Ama proje vibe-coded olduğu için kod baştan sona bug dolu hale geldiyse, benim gidip bug’ları düzeltip yapıyı toparlamam yeterli mi?
Başta bunu kuracak uzmanlığı olmayan bir şirket, bakımını sonrasında nasıl sürdürebilir, merak ediyorum
Bence dış kaynak geliştirme ile LLM tabanlı geliştirme sonunda benzer yetkinlikler gerektiriyor
Yani gereksinimleri netleştirme, iletişim, paydaş yönetimi, spesifikasyon tanımlama, test ve dokümantasyon gibi mühendisliğin temel taşlarına hâlâ ihtiyaç var
Karpathy’nin "vibe coding" kavramının bu şekilde yaygınlaşması bana biraz garip geliyor
Muhtemelen gerçek geliştirme deneyimi çok olmayan insanlar arasında böyle popüler olmuştur diye düşünüyorum
Hatırladığım kadarıyla vibe coding, “AI ile konuşup akışa güvenerek ilerlemek ve üretilen kodu neredeyse hiç kontrol etmemek” gibi bir yaklaşım, adeta bir flow hali
Kalitenin az da olsa önemli olduğu ciddi yazılımlarda bu gerçekten korkunç bir yöntem
Twitter memeleri, kişisel deneyler ya da evde kullanılan küçük script’ler için belki kullanılabilir ama düzgün bir ürün geliştirirken saçma geliyor
Bu kadar konuşulmasının nedeni muhtemelen Karpathy gibi ünlü birinin buna havalı bir isim vermesi; başkası söyleseydi muhtemelen kaybolup giderdi
AI öncesinde de junior ya da nispeten deneyimsiz geliştiriciler zaten buna benzer şekilde kod yazıyordu
Bir yerlerden kopyala-yapıştır yapıp çalıştığını görünce bırakıyor, tuhaf bug’lar ya da core dump çıkınca da kaynak kodun sırasını değiştirip sorunu zar zor yok etmeye çalışıyorlardı
Bu tarz çalışma şekli şirkette en azından uyarı almanıza, performans iyileştirme planına girmenize, hatta daha kötüsü kapı dışarı edilmenize yol açabilir
Uzman olmayan kişiler, yazılım mühendisleriyle iletişim kurarken çoğu zaman istedikleri sonucu alamıyordu
vibe coding’in ortaya çıkışı, bugüne kadar nasıl yazılımlar teslim ettiğimiz üzerine düşünmemiz gerektiğini gösteriyor bence
Gerçekten de bildiğim vibe coded startup’ların yazılım kalitesi berbat, ama istedikleri şeyi yaptığı sürece kalite şu aşamada onlar için önemli değil
Yazılım kalitesi işlerine somut zarar verene kadar, geliştirici işe alıp kendi fikirlerinin sulandırılması riskini almak istemeyeceklerdir
Sonuçta çöp gibi olsa bile istediklerini hemen kullanabilmek, istemedikleri “mükemmel” yazılımdan daha iyi bir seçenek haline geliyor
İsteseniz de istemeseniz de vibe coding ortadan kaybolmayacak
Ben de kişisel olarak bu kavrama pek katılmıyorum ama organizasyon içinde meslektaşlarıma bazen “bunu vibe coded yaptım” diyorum
Bizde bunun anlamı daha çok “kodun büyük kısmını AI ile otomatik ürettik”
Ama böyle üretilen kodu incelemeden doğrudan production’a çıkarmayı asla düşünmem
Daha çok “havalı bir app’i vibe coding ile hızlıca denedim” gibi, hafif deneysel bir anlamda kullanıyorum
Karpathy sanırım vibe coding’i, nereye kadar gidebildiğini görmek için denenebilecek “mümkün bir deney” olarak anlatıyordu; eğlenceli bir sınama gibi
Şirkette gerçekten sadece vibe coding ile ürün yapın diye bir tavsiye verdiğini sanmıyorum
İnsanlar bu ifadenin bağlamını fazla keyfi yorumladı
Hatta Karpathy bunu kastettiğini bir YouTube videosunda da açıklamıştı
İlgili yazı
Karpathy YouTube: Software Is Changing (Again)
İnsanlar zor işleri artık kolayca yapabileceklerine inanmak istediği için yanlış anlama daha da büyüdü diye düşünüyorum
Ben hâlâ o tweet’in de aslında bir şaka ya da “YOLO coding” özgürlüğünü anlatan bir ifade olduğunu düşünüyorum; gerçek iş süreçleri için öneri değildi
Sadece o an hissettiği özgürleşmeyi eğlenceli biçimde yazmıştı
Şu anda vibe coding neredeyse her türlü AI kodlama yardımını küçümsemek ya da alaya almak için kullanılan bir terim haline geldi
Hangi araç olursa olsun iyi de kullanılabilir kötü de, ama bugünlerde “vibe coding ne kadar aptalca” memesi internette hızla karşılık buluyor
Artık yorucu olmaya başladı
Yazının ana argümanı şu: "Bir startup, vibe coding sayesinde MVP’yi haftalar daha erken çıkarabiliyorsa ve sonra benzer zaman ile maliyet harcayıp temizleme yapmak zorunda kalsa bile, yine de geleneksel geliştirmeden daha hızlı olabilir"
Gerçekten öyle mi, merak ediyorum
Benim gördüğüm kadarıyla geliştirici doğrudan kendisi yapıp AI yardımından yararlandığında hız farkı o kadar büyük olmayabiliyor
Özellikle MVP ya da prototipin daha sonra doğrudan production’a gireceği biliniyorsa, mimariyi en baştan doğru kurmak uzun vadede daha mantıklı geliyor
Ama ürün ekipleri ve yöneticiler genelde bu süreyi israf olarak görüyor
vibe coding’in asıl avantajı, ürün ekibinin geliştiriciye anlatmak zorunda kalmadan istediğini kendisinin doğrudan deneyebilmesi
Belki de pazarda fırsat olan şey, doğrudan kod üretmekten çok spesifikasyonu ve prototipi netleştiren vibe coding tabanlı ürün araçlarıdır
Böyle araçlar geliştiricilere daha iyi spesifikasyon sunabilir, iş tarafına da daha fazla katkı ve inisiyatif verebilir
Startup dünyasında pazara çıkış çok kritik olduğu için, toplamda daha fazla zaman ve para harcansa bile, daha hızlı çıkış sağlıyorsa teknik borcu kabul etmek tamamen rasyonel bir karar olabilir
İnsanların teknik borç biriktirmesinin nedeni de bu
Twitter da ilk başta Ruby on Rails tabanlı bir web app olarak başlamıştı; Justin Bieber tweet attığında sunucular çöküyor ve fail-whale çıkıyordu
Ama büyüdükçe uzmanlar işe alındı ve sistem sonunda daha sağlam ve daha ölçeklenebilir bir yapıyla baştan düzgün biçimde yeniden kuruldu
MVP’den çok prototip düzeyinde işe yarayabilir ama,
prototipi prod’a koymama yönünde kurumsal ve kişisel disiplin yoksa vibe coding’den uzak durmak gerekir diye düşünüyorum
Şirket yönetimine “şu an kullandığınız havalı kodun içi berbat, komple yeniden yazılmalı” demenin ne kadar zor olduğunu herkes bilir
Böyle durumlarda no-code araçlar aslında çok daha güvenli
Çoğu MVP ve prototipin sonunda çok geçmeden production’a çıktığı gerçek
Birinin şu sözünü hatırlıyorum: “MVP kodu mide bulandıracak kadar kirli görünmüyorsa, kod kalitesine fazla zaman harcıyorsundur”
Sonunda tüm o geçici çözümler şirketin omurgasına dönüşüyor
Sırf bu tür düzenleme işleri yapan bir hizmete "C-Suite cleanup as a Service" denebilir belki, ama öyle reklam yapsan kimse satın almaz gibi geliyor
Yazıyı okur okumaz, em-dash olmasa bile bunun Claude tarafından yazıldığı çok net hissettirdi
Elbette OP kendi fikirlerini ve malzemelerini prompt olarak vermiştir, ama bazı ifade kalıpları ve cümle tonları LLM’lerde çok sık görülen şeylerle birebir aynıydı; okurken biraz zorlandım
Belki de bu tür metinler yakında “LLM üslubu” diye demode sayılacak
Şimdi sırada vibe-writing cleanup as a service var gibi görünüyor
Ben yıllardır em-dash’i çok kullanırım, ama galiba artık bunu bilinçli olarak azaltmam gereken bir döneme girdik
Microsoft Word otomatik olarak tireyi em-dash’e çeviriyor
Bence vibe coding, DIY tesisatçılığa benziyor
Kendin deniyorsun, banyoda su patlarsa sonunda acil çağrı tesisatçısını yüksek ücretle çağırmak zorunda kalıyorsun
O süreçte bir dahaki sefere biraz daha fazla şey öğrenmiş oluyorsun
Benzer bir benzetme ama profesyonel tesisatçılar da DIY’ı destekleyen araçları gayet iyi kullanır
Fark şu ki profesyoneller, bunları ne zaman ve ne ölçüde kullanmaları gerektiğini bilir
Hatta bence daha da kötü
Tesisat işinde ne yaptığını gözünle görürsün, ama vibe kodda bir gün bir şey aniden çalışmaz hale gelir ve nedenini de bilemezsin
YouTube’da profesyonellerden daha titiz çalışan DIY tesisatçılar da sıkça görülüyor
Sanırım mesele, vibe coder’ın bu deneyimlerden gerçekten bir şey öğrenip öğrenmeyeceği
Bunu zaman gösterecek
Bu benzetme gerçekten çok yerinde geliyor
Nasıl baskı altındaki bir emlakçı evi satmak için apar topar tesisat işi yapıyorsa, startup kurucuları da yatırımcıların ve müşterilerin ilgisini çekmek için hızla bir şey demo’layıp sonra gerçek uzmanları çağırarak temizletiyor
Şanslılarsa büyük bir felaketi önceden engelleyebiliyorlar
Janitor Engineer ifadesinin zaten sektörde var olmasına şaşırdım
Ayrıca, "Why AI code fails at scale" sonrasındaki makale bağlantılarının hepsi bozuk görünüyordu; bu kadar yeni bir yazıda olması ayrıca tuhaf geldi
Bu arada umarım bunu kimse kırıcı bulmaz
Ben de vibe coding moda olduktan sonra, AI’nın ürettiği kod yığınlarını çözüp temizleyen bir “all-organic-code” danışmanına dönüşmeyi, yarı şaka bir emeklilik planı olarak aklımda tutuyorum
Gerçekten nadir olan şey ise yeni, sıfırdan projeler yani greenfield işler
vibe coding, dokümantasyonu ve mimari netliği hızla aşındırıyor
Şirketler yalnızca üretilen kod token’ı miktarını ve prototip hızını önemli metrikler sanıyor, gizli bakım ve temizlik maliyetlerini görmezden geliyor
Artık asıl beceri üretmek değil, temizlemek
Gerçek ustalık, en baştan doğru yönlendirip düzgün yazılım elde etmekte
Claude Code gibi şeyleri “işte son teknoloji bu” diye görenler var, ama iyi sonuç almak için çok daha fazla müdahale gerekiyor
Aslında geleneksel mühendislikten o kadar da farklı değil
Mesele maliyeti düşürmek ve gereksinimleri karşılamak
Bakım kolaylığını açıkça talep etmezseniz, aslında tam da hedeflenen sonuç(?) ortaya çıkıyor
Bunun neden dokümantasyonun ölümü olduğunu merak ediyorum
En başta sadece dokümanı yazıp, daha sonra kodun o dokümanla uyumlu olup olmadığını denetleyerek geliştirme yapmak da mümkün
Ya da koddan doküman ürettirip, onun uygunluğunu elle incelemek de mümkün
Şirketimiz onlarca yıldır müşterilerin acil durum sistemlerinde (arıza vb. yüzünden ciddi mali kayıp oluşuyor ve kendileri çözemiyorlar) acil toparlama işi yapıyor
Son birkaç yılda bu tür vakalar oldukça hızlı artıyor
vibe code birçok açıdan legacy code’a benziyor
İnsan koduna güvenmediği için değişiklik yapmaktan çekiniyor; hem iç kalitesi hem dış kalitesi düşük oluyor
Ama farklı yönleri de var
Kodun yaşıyla kıyaslandığında miktarı düşük, takvim baskısı yüksek ve beklentiler şişirilmiş oluyor
En maliyet etkin yaklaşım, hataları runtime’a bırakmak değil, mümkün olduğunca design ya da compile time öncesine çekmek
Sorun şu ki AI sayesinde herkes runtime’a kadar fazla hızlı koşuyor
Bu arada “Vibe code is legacy code (val.town)” yazısına bakmaya değer
İlgili HN gönderisi
Legacy code her zaman kötü olmak zorunda değil
Genellikle karmaşık olur ya da dokümantasyonu zayıftır ve uzun yıllar boyunca irili ufaklı operasyonel yamalar birikmiştir
Yeni gereksinimler gibi birçok operasyonel mesele yansıtıldığı için canlı ortamda gayet iyi de çalışabilir
Sorun, kod tabanını bilen insanların ortadan kaybolması ve hatta kullanılan dili ya da araçları bilen kimsenin kalmamasıdır
Vibe coding’in güçlü tipli dillere de uygulanıp uygulanamayacağını merak ediyorum
Vibe ile üretilmiş kodun legacy code gibi ele alınabileceği fikrine katılıyorum
Ama insanlar gerçekten vibe code üzerinde de değişiklik yapmaktan bu kadar çekiniyor mu, emin değilim
LLM ile kod üretiminin ileride ortadan kalkabileceğini düşünüyorum
Yazı, LLM kodunun her zaman üretileceğini ve her zaman temizliğe ihtiyaç duyacağını varsayıyor; ama belki de LLM maliyeti + temizlik maliyeti, geliştirici maaşından sürekli daha pahalıysa, sonunda insanlar yeniden doğrudan insan eliyle yazmaya dönebilir mi?
LLM ile kod üretip sonra kontrol ederek kullanmak, vibe coding ile aynı şey değil
vibe coding’de tamamlanan kod çoğu zaman hiç kontrol edilmeden doğrudan kullanılıyor
Ama iki yaklaşımın da ortadan kalkacağını sanmıyorum
Günümüzde AI tabanlı vibe coding’in modası yavaş yavaş geçiyor
Çünkü yakında daha iyi AI’lar gelecek
Bütün gün vibe coding yapmak sonunda maliyet olarak taşınamaz hale gelebilir
Aşırı destek ve kolaylık hissi yüzünden herkesin kapıldığı heyecan bir yanılsama da olabilir; sonra gerçek ortaya çıkınca sancılı bir ayılma yaşanır
Ama örneklerden beslenen tahmine dayalı tamamlama ve otomatik üretim yardımcı araçlarının yönü asla kaybolmayacak
Eskiden syntax highlighting olmadan da kod yazılıyordu ama bugün kimse özellikle öyle yapmak istemiyor
DFS gibi bir şeyi sekseninci kez yeniden yazmak, programcı olarak özsaygımı artırmıyor