Vibe kodu, legacy koddur

• Vibe coding, yapay zekanın yardımıyla kodun sezgilere dayanarak hızlıca yazıldığı bir yaklaşım ve sonuçta anlaşılamayan kod, yani legacy kod bırakıyor
• Legacy kod, kimsenin anlamadığı koddur; teknik borç ve bakım sorunları doğurur, yeni özellik eklerken hata çıkma olasılığını yükseltir
• Vibe coding, prototip ya da kısa süreli projeler için hızlı bir geliştirme aracı olabilir; ancak uzun vadeli olarak sürdürülmesi gereken projeler için uygun değildir
• Uzman olmayan birinin büyük bir projeyi vibe coding ile geliştirmesi, bir çocuğa kredi kartı vermek gibi bir risk taşır
• 2025'te de AI ile geliştirme yaparken dikkatli olmak ve anlayış düzeyini korumak önemlidir

---

Vibe coding nedir

• Andrej Karpathy, "vibe coding" terimini, AI'ın kod yazdığı ve kullanıcının kodun varlığını bile unutacak kadar ona aldırmadığı bir programlama biçimi olarak tanımlıyor
• Bu yaklaşım, geliştiricinin yazılan kodun iç yapısını hiç anlamasa bile sonuç elde edebilmesi bakımından geleneksel yazılım geliştirmeden farklıdır

Legacy kodun sorunları ve teknik borç

• Kimsenin anlayamadığı kod zaten legacy koddur
• Bu tür kodlar bakım ve onarımda çok zaman alır; bug düzeltmelerinde ya da yeni özellik eklerken sorunları ciddi biçimde artırır
• Programlamanın özünün çok kod üretmek değil, kavramsal teori inşa etmek olduğu vurgulanıyor

Vibe coding ve prototipleme

• Vibe coding, prototip geliştirme ya da tek kullanımlık projelerde hızlı başlangıç ve hızlı geliştirme sağlar
• Sonrasında bakım gerekmeyecekse, kodun içini bilmemek büyük bir yük oluşturmayabilir
• Bu yüzden geliştirme hızını ciddi ölçüde artırır ve yeni fikirleri denemek için çok uygundur

Vibe coding'in anlama düzeyi spektrumu

• Vibe coding, geliştiricinin koda dair anlayışı ne kadar düşükse o kadar fazla vibe ile ilerleyen bir yöntemdir
• Temel olarak mühendis gereksinimleri ne kadar net anlarsa, vibe coding o kadar azalır
• Programcı olmayan biri web ile native uygulama arasındaki farkı ya da verinin nasıl saklandığını bilmeden kod yazdırmaya çalıştığında, genellikle daha fazla vibe coding ortaya çıkar

Uzman olmayanların büyük ölçekli vibe coding'i: kredi kartına benzer

• Uzman olmayan birinin vibe coding ile büyük bir projeyi inşa etmeye ve sürdürmeye çalışması, kavramı anlamadan bir çocuğa kredi kartı vermeye benzer bir durumdur
• Başta her şey kolay görünebilir, ancak sonrasında çok büyük bakım maliyetleri ve sorunlar gelir
• Sonunda 'fatura' geldiğinde, sorunu çözme becerisi yetersizse durum daha da kötüleşebilir

2025'te AI çağında ciddi geliştirme

• Andrej Karpathy, AI ile geliştirirken dikkat, temkin ve mevcut kodu sürekli öğrenme yaklaşımının mutlaka gerekli olduğunu vurguluyor
• AI'ın abartılı özgüvenine karşı koymak ve iyi kodla kötü kodu ayırt eden insani muhakeme önem taşıyor
• Yalnızca AI'a bırakmamak, kodu mutlaka doğrudan okuyup anlamak gerekiyor

Val Town'ın AI araç kullanımı

• Val Town, Townie adlı AI yardımcısı aracılığıyla kod yazma, çalıştırma, doğrulama ve yinelemeli iyileştirme süreçlerini otomatikleştiriyor
• Townie, vibe coding'e uygun bir araç ve kullanım amacına göre serbestçe kullanılabilir ya da sıkı biçimde kontrol edilebilir
• AI ile geliştirme biçimi çok hızlı evriliyor ve karmaşık yazılım geliştirmede teorik temelin önemi bundan sonra da sürecek

Programcı olmayanların ölçüsüz vibe coding'ine uyarı

• Programcı olmayan birinin binlerce dolar harcayıp devasa bir uygulama fikrini vibe coding ile geliştirmesi iyi bir yöntem değildir
• Sonuçta, kodun içini doğrudan okuyup analiz edecek insan gözüne her zaman ihtiyaç vardır; anlaşılamayan legacy kodu düzeltmeye çalışmaktansa en baştan iyi tasarlayarak yeniden yapmak daha etkilidir

Sonuç ve tavsiye

• Karmaşık yazılımlar inşa ederken teorik temel kritik önemdedir
• AI ilerledikçe programlama biçimleri hızla değişse de insan geliştiricinin uzmanlığı hâlâ önemlidir
• Uzman olmayan biri AI ile büyük ölçekli bir uygulama yapmaya çalışırsa, sonunda tüm kodu okuyup baştan yeniden yazmak daha iyi olabilir

[servent2616]

Bunu bir çocuğa kredi kartı vermeye benzetmek
uygun bir benzetme olmuş.
Ya da bir çocuğa bıçak vermeye de benzetilebilir gibi görünüyor.

[actofvalor]

Yapay zeka tarafından üretilen koda yorumları da ekleyen ve kod akış diyagramları gibi şeyler çizen bir kod üretme yapay zekası çıkarsa, bir ölçüde faydalı olabilir.

[draupnir]

Oldukça katıldığım bir görüş. Aslında bunun bir kısmını bizzat yaşıyor da sayılırım…
Bir yandan da model performansındaki değişimlere bağlı olarak bu kısmın nasıl evrileceğini merak ediyorum.

[optionzero]

O kadar doğru bir söz ki, okuyunca insanın içinden "işte bu" demek geliyor. Kod bilmeyenler vibe coding yaparken "vay" diyor ama kod bilenler "neden? niye böyle?" diyor.

[qscwdv531]

Yorumların durumu içler acısı.

[kgun9]

O zaman bir arabayı, iç yapısını tamamen anlayana kadar asla kullanamaz mıyız?

[onetoday]

İç yapısını anlamadan araba yapmak = vibe coding

[hackerst]

Kullanabilirsiniz. Ama onu yapamazsınız.

[sinbumu]

Bunun yöntem ve teknoloji meselesi olduğunu düşünüyorum; sadece yapay zeka kullanmayıp organik el kodlaması yapmak gerektiğini söyleyenler, mühendislik hesap makinesi yerine abaküs kullanalım ya da Excel fonksiyonlarını kullanmayıp her şeyi elle yazalım diyenler gibi geliyor.

[elbanic]

Bu yanlış bir benzetme. Mühendislik hesap makinesi de tıpkı hesap makinesi ya da Excel gibi, girilen değerlere göre doğru sonuç verir. Eğer yapay zeka kullanıcının öngördüğü sonucu aynen üretseydi, şimdiye kadar defalarca ortaya çıkan yeni teknolojilerden o kadar da farklı bir teknoloji olmazdı. Zaman geçtikçe güvenlik ve halüsinasyonlarla ilgili kaygıların büyümesinin nedenlerinden biri de bu. Yani Gen AI kontrol edilebilir değil. Mevcut LLM'lerin sınırları anlaşılmalı ve uygun yerlerde kullanılmalıdır.

[tensun]

Şu anda vibe coding artık emekleme döneminde ve bence gelecek yıl ya da sonraki yıl olgunlaşmış bir geliştirme metodolojisi haline gelecek. DevOps nasıl AIDevOps’a dönüşüyorsa, bunun da AI Agile veya Vibe Agile’a dönüşeceğini düşünüyorum.

[GN⁺]

Hacker News görüşleri

• Geliştirici olmayan bir arkadaşımla ilgili bir hikâye. Arkadaşım geçen yıl bir SaaS ürünü bizzat kodlayıp yayına aldı; neredeyse hiç pazarlama yapmadan, sadece ağızdan ağıza yayılma ve inbound ile gelir üretmeye başladı. Geliştirmede Replit ve Supabase kullandı; müşteri geri bildirimleri geldikçe uygulamanın giderek daha karmaşık hâle geldiğini düşününce bu gerçekten etkileyici. Bence bu pazarda mevcut iki oyuncu vardı ve arkadaşım çok daha düşük aylık ücretle daha modern bir ürün sununca onlar bundan hoşlanmadı gibi görünüyor (mevcut ürünlerin hepsi Windows için masaüstü yazılımıydı). Bu yüzden bir hacker tutup arkadaşımın SaaS’ına saldırttılar; bu hacker’lar para talep etmeden saldırdı. Ne yazık ki arkadaşım deneyimsiz olduğu için hızlı hızlı kod yazarken çok sayıda açık bıraktı. İlk olarak, frontend kodunda kullanıcı listesi görünür durumdaydı ve hacker bütün müşterilere e-posta gönderebildi. İkinci olarak, hacker Stripe anahtarlarını ele geçirip tüm müşterilere iade yaptı. Üçüncü olarak da hacker hâlâ XSS denemeleri yapıyor ve bazen alanlarda <script>alert()</script> gibi etiketler görünüyor. Benim vardığım sonuç şu: deneyimsiz biri vibe-coding yaparsa teknik borç hemen birikmeye başlıyor. Ama aynı zamanda, bu arkadaşın mühendislik deneyimi olmadan birkaç ay içinde ticari potansiyeli olan bir ürünü doğrulamış olması da şaşırtıcı. Şimdi açıkları kapatmak için geliştirici işe alıyor. Bu kadar dağınık ve güvenlik açısından zayıf kodla, sadece birkaç yüz dolar harcayarak makul bir iş potansiyelini kanıtladığına göre, sonuçta bu sürecin değerli olduğunu düşünüyorum

  • Bunun rakip firmaların işi olduğunu varsaymak bana daha çok sorumluluktan kaçma gibi geliyor. Aslında daha muhtemel senaryo şu: otomatik zafiyet tarayıcıları siteyi buldu, sistem fazla savunmasız olduğu için bir saldırgan içeri girip ortalığı karıştırdı. İnternete açık servislerde bu tür exploit trafiğini sık görenler bunu iyi bilir

  • Bu, mühendislik deneyimi olmadan bir ev inşa edip sonra birinin gelip tekmeyle yıkmasına ahlaki açıdan benziyor. Sorun vibe coding’in kendisi değil; kritik kararları alacak bilgiye sahip olmamak. Bu mesele hukuki sorumluluğa kadar uzanabilir

  • Piyasada zaten mevcut oyuncular varsa, işin doğrulanması için gerçekten böyle bir MVP’ye ihtiyaç var mıydı? Esasen daha ucuza sunarsan insanların mevcut sağlayıcıdan geçip geçmeyeceğini test etmeye gerek yok. Arkadaşının aldığı ders şu: bazı müşteriler başta ücret öder (ama elde tutma verisi yok), fakat sonunda gerçek bir ürün yapmak için insan işe almak zorunda kalacak ve o zaman da fiyat avantajı azalacak. Pazarlamaya ciddi para harcamaya başladığında daha çok zorlanacak. Sonunda yine aynı noktaya geliyoruz: fikirlerin tek başına hiçbir değeri yok, önemli olan uygulama becerisi

  • Arkadaşının neredeyse hiçbir sorumluluk üstlenmeden işine devam edebilmesi bu sektörün temel sorunu. Eğer yazılım diğer mühendislik alanları kadar sıkı düzenlenseydi, geliştirici ya da şirket müşteri verisi sızdırmanın hukuki bedelini ödemek zorunda kalırdı

  • İşin doğrulandığını varsaysak bile, müşteri açısından bu kazanç değil zarar olabilir. Hem para ödüyorlar hem de önemli verilerini güvenlik açısından zayıf bir yere emanet ediyorlar; ayrıca ürünün gerçekten düzgün çalışıp çalışmadığı bile belirsiz. Şimdi geliştirici işe alıp düzeltmeye çalışıyor ama bu düşündüğü kadar kolay olmayacak. AI’nin eğitim materyali, verimlilik veya öğrenme aracı olarak kullanılmasına varım; ama arada insan olmadan bırakılırsa sonuç korkunç olabilir

• Daha önce de geliştirici olmayanlar ya da junior geliştiriciler Microsoft Access, Excel vb. ile kolayca uygulama yapıp dağıttı. O zaman da sınırlar, ölçeklenme sorunları ve bakım kabusları vardı; ama aynı zamanda bu dalga profesyonel geliştiricileri daha iyi çözümler üretmeye de itti. PC yaygınlaşırken de aynısı olmuştu; mainframe geliştiricileri PC dünyasının “dağınık” kodunu görünce dehşete düşüyordu

• Neredeyse otuz yılı aşkın süredir yazılım mühendisi olarak çalışıyorum ve bu yazının tüm yorumlarını okudum. Ama vibe coding’i eleştiren neredeyse bütün gerekçelerin, bugüne kadar gördüğüm “insan eliyle yazılmış” hemen her kod tabanı için de geçerli olduğunu düşünüyorum (tabii istisnalar var)

  • Atılmak üzere yapılmış bir prototip neden kötü olsun, anlamıyorum. Bu iş kurmanın en önemli aşaması. Legacy code için de aynı şey geçerli. Gerçekten para kazandıran kodların büyük kısmı, o organizasyondaki geliştiricilerin gözünde zaten legacy sayılıyordur

  • Şaka yollu söylenir ya, trunk’a merge edildiği anda her şey legacy code olur

  • Kısmen katılıyorum ama vibe coding’in sorunu, insanları doğru dürüst araştırma yapmadan, mevcut kod tabanının yapısını ya da gereken çözümün ne olduğunu incelemeden bodoslama dalmaya teşvik etmesi. Daha dün Rust’a hâkim olmayan bir ekip arkadaşım vibe coding ile yeni bir özellik yaptı; dışarıdan bakınca “çalışıyor” ama aslında tam bir facia (tokio async context içinde senkron I/O, lock’lar, kendi channel implementasyonu vs.). Zaten güvenli async abstraction’lar varken gidip yeni ve yanlış abstraction’lar üretmiş. Biraz araştırsa ya da önce yardım istese mevcut koddan örnek alabilirdi

• Bütün kodlar bir gün legacy olur. Junior olduğum dönemden beri, benim ve diğer junior geliştiricilerin yazdığı sayısız production script ve servis kodunu code review etmiş biri olarak, bu kadar mutlak bir bakış bana fazla geliyor. Bu sorun çoğu organizasyonda tekrar tekrar yaşanıyor. LLM tabanlı kodun kalitesini eleştiren yazılar yazılmasını anlıyorum ama kariyeri boyunca başkalarının sistemlerini düzeltmiş, genişletmiş ya da refactor etmiş geliştiriciler bu gerçeği daha iyi bilir. Yazılım mühendisliği dünyasına makine mühendisliğindeki gibi tutarlılık, sertifikasyon, sorumluluk ve gerçek sonuçlara dair katı standartlar ile hukuki riskler gelmedikçe bu tartışmanın pek anlamı yok. Modern IT sektörü bunun tam tersi bir felsefeye, yani ‘agile’, ‘hızlı yap, bozulursa da olsun’ anlayışına dayanıyor. Hızlıca, az tasarımla, sık dağıtım yapılıyor; yanlış bir şey çıkarsa geri alınıyor, arıza olursa da “yapacak bir şey yok” deniyor. Yazılım oyuncak gibi ele alınıyor. Belki %1’lik kesim bunu düzgün yaptığını iddia eder ama çoğunluk etmiyor

  • Söylediklerinin hepsi doğru; buna şunu da eklerim: kod sonuçta bir bilim değil. “Doğru” kodun ölçütü bağlama göre değişir. Kod sadece hedefe ulaşmak için bir araçtır

• Şu an ilginç bir şey oluyor. Mühendislikten pek anlamayan insanlar, hatta bir yere kadar anlayıp da bunu doğru anlatmayanlar, internette yanlış bir anlatı yayıyor. Bunlar artık junior geliştiricilerin 10 kat üretken olduğunu, hatta PM’lerin bile doğrudan kod deploy ettiğini iddia ediyor. Ama bir an gözünüzü kapatıp bu koşullarda ortaya çıkan kodu düşünün: o kod %100 legacy code, hatta atılacak kod. Sorunun özü AI’nin ya da PM’in Figma’dan doğrudan kod çıkarabilmesi, junior’ın da bol bol prompt yazması değil. Beklentiyle gerçeklik arasındaki uçurumun asıl nedeni, yıllar süren tartışmalarla tanımlanmış terim ve kavramların doğru ayırt edilememesi.
  Lean prototype ile disposable prototype (MVP bile değil) aynı şey değil. MVP ancak lean prototype başarılı biçimde doğrulandıktan sonra yapılabilir. Ürün de MVP’den farklıdır.
  Vibe coding araçları disposable prototype’ları hızla üretmekte mükemmel; LLM entegre IDE’ler ise gerçek ürün yapımına daha uygun. Bugünkü aşamada sadece gerçek mühendisler LLM prompt’larıyla lean prototype kodlayabiliyor; geri kalanlar disposable kodla çalışan basit yazılımlar üretiyor

  • “Ürün, MVP’den farklıdır” demişsin; bunu çalıştığım neredeyse tüm şirketlere söylemek isterdim. Son zamanlarda yönetim kurulları ve C-level kadrolarındaki “bu çeyrek bir şey çıkarın da ne olursa olsun” tavrı çok yaygın olduğu için geliştiriciler bir MVP yapıp hemen sonraki projeye geçiyor. Gerçekten vibe coding olsun ya da olmasın, pratikte özellik zengin görünüyorsa gerçek kaliteye bakılmadan iş metrikleri yükseliyor. Aslında gerçek mühendislerin (artık buna ‘geliştirici’ deniyor galiba) öncülük ettiği prototipleme ortamı çok nadir. Belki oyun sektöründe veya bazı tech şirketlerinde görülür. Çoğu yer yalnızca MVP üretmeye odaklanmış durumda. Vibe coding sadece MVP üretim hızını artırıyor, kalite ise aynı oranda feda ediliyor

  • “Terimlerin tanımı”nın içeriği boşaltılarak birbirine karıştırılması eğilimi son 10 yılda sektörde gözle görülür biçimde arttı. Bu terimler aslında sayısız kitap, tartışma ve uzun yıllara yayılan düşünsel birikimle anlam kazandı. Deneyimli bir geliştirici tek bir kelime kullandığında, onun içinde tüm o deneyim ve tartışma bağlamı da taşınıyordu. Ama yeni başlayanlar bu bağlam olmadan, kelimeleri sadece yüzeysel olarak “kopyalayıp” anlamını tanımlamadan kullanıyor. Sonuç olarak kimse terimin başlangıçta ne anlama geldiğini ya da neden o duruma uygun olduğunu bilmiyor. Örneğin "'agile', 'technical debt', 'DevOps' ve en son ‘vibe coding'" gibi. HN’de semantic drift hakkında bir yazı da paylaşılmıştı. Yazılım sektöründe bu sık görülen bir durum.
    Teknik bir örnek olarak JavaScript’te 'object', 'JSON', 'dictionary', 'hashmap' terimlerinin birbirine karıştırılarak kullanılmasını verebiliriz. Normalde her birinin anlamı farklı ama JS geliştiricileri için hepsi çoğu zaman tek kelimeyle ‘object’. Bu da dilsel ve kavramsal çözünürlüğün tek bir ‘piksel’e düşmesi gibi

  • Eskiden geliştiriciler birbirlerinin koda yaklaşımından söz ederdi. Ama şimdi artık kimsenin anlayamadığı kod yüzünden geliştirici yorgunluğu muazzam biçimde arttı. Eskiden böyle durumlarda bir mühendis bozuk yerleri işe yarar hâle getirir, bir mimar da karmaşıklığı azaltırdı. Şimdi LLM çağında 100 kat fazla kod akıyor ama mühendisler ve mimarlar bu akışın tamamen dışında kalıyor. Bizzat yaşadığımız durum bu.
    Eğer bu sorunu çözecek bir test yöntemi (TDD MCP server, DDD MCP server ya da herhangi bir workflow/mimari) geliştirilebilirse, trilyon dolarlık startup çıkar. Code review verimliliğini ciddi biçimde artırıp ölçekleyebilen araçlara çok ihtiyaç var

  • Bence önce “çalışan yazılım”ın ne demek olduğunu daha net tanımlamak gerek. Mesela LLM’in ürettiği UI’lar hep birbirine benziyor ve içinde ince ama ciddi hatalar saklı oluyor. Bir kez kullanıcı testi yapıldığında sorun hemen ortaya çıkıyor. Ayrıca generative UI zaten çoğu zaman sadece trendlere yapışıyor, gerçekten yeni bir şey üretmiyor

  • Büyük şirketlerin kurum içi kullanım için nasıl kod yazdığını hiç gördün mü? Vibe coding’den pek farkı yok. Hatta LLM’i pentest geçecek şekilde ayarlarsan hiç değilse bir şey yapmaya çalışıyor. Büyük şirketlerin umurunda bile olmuyor

• Aslında bütün kod legacy. Bu yüzden vibe coding’in hızlıca çok kod üretmesi onu özel yapmıyor. Sonuçta kimsenin anlayamayacağı “kendi elimle yazdığım kod” da aynı ölçüde kötü olabilir. Bütün kod, bakım açısından bakıldığında bir yüktür. Kütüphaneler de ancak yükü azaltabilir; sık değişen ya da arayüzü eskimiş olanlar daha da kötü bir legacy örneğidir.
  Uzun süre kod yazmış insanlar sonunda çözümün daha az üretmek, yani genel olarak ihtiyacı azaltmak olduğu sonucuna varır. Bütün karmaşıklık eninde sonunda “gelecekteki benim hatırlamayacağı bir problem”e dönüşür. Gerçekte gereksinimler de sürekli değişir ve uzmanların söylediği gereksinimler bile yanlış olabilir (hatta o ‘uzman’ siz olabilirsiniz)

  • “Bütün kod legacy’dir” görüşüne katılmıyorum. Bazı kodlar küçüktür ve geliştirici hâlâ hepsini kafasında tutabildiği için tamamen ‘canlı’dır. Legacy’nin pratik tanımı, çok büyük olup organizasyonda artık aktif bir sahibi kalmamış koddur. Vibe code ise üretildiği anda bu iki koşulu da karşılıyor

  • Legacy, artık paydaşı kalmadığı için bakımın da bağlamın da zorlaştığı şeydir

  • Mümkün olan en az kodla problemi çözmeyi isterim. Mesele, kodun benim problemim olmamasını sağlamak. İşin özü abstraction’ların ne kadar “sızdırdığı”; şu anda LLM’lerin ürettiği abstraction’lar çok kötü. Ne kadar iyileşeceği belirsiz.
    Kod anlamayı daha eğlenceli, kolay ve ucuz kılan araçlara yatırım yapmak isterdim. Arkadaşım Glen’in bu konuda ilham verebilecek bir projesi var: https://glench.github.io/fuzzyset.js/ui/
    Geoffrey Litt’in dediği gibi, LLM’ler kodumuzu anlamamıza yardım eden geçici görselleştirme araçları, debugger’lar vb. üretmekte çok daha faydalı olabilir

  • Her kod risk taşır ama her kod legacy değildir. Vibe coding ile üretilen kodda baştan bağlam ya da sahiplik olmadığı için hemen legacy’ye dönüşüyor gibi

  • “Bütün kod legacy’dir” itirazına karşı şunu söylerim: çok derinlemesine anladığım bir projede bir bug’ın nedenini tek seferde tespit edebiliyor ve yeni özelliğin nasıl implemente edileceğini zihnimde kurabiliyorsam, o kod legacy değildir

• Bence “koda matematik gibi bakılan dönem” sona erdi. Gerçek dünyaya bağlı yeterince büyük yazılımlar, matematiksel ispat gibi kusursuz biçimde doğru (true) olduklarını garanti edemez. Gerçek sistemler; formel garantiler, deneyim temelli tasarım, deneysel test, zanaatkârlık ve performans ölçütlerine dayanan mühendislik ürünleridir.
  Bu eğilim en küçük script’lere kadar yayılacak. Çoğu yazılımın zaten matematiksel olarak ispatlanmasına gerek yok. Amacına hizmet etmesi yeterli. Programlama zanaatına saygım sonsuz ama artık bu kısmı biraz bırakmanın zamanı geldi.
  Sonuçta gelecek şu iki seçenekten biri gibi görünüyor

• 100 bin satır, 50.000 test ile tüm gereksinimleri garanti eden ama kimsenin kolay kolay okuyamadığı bir program, toplam maliyet 50 bin dolar (API token maliyeti)

• İnsan eliyle tasarlanmış 30.000 satır, 3.000 test, zarif abstraction’lar, aynı gereksinimleri karşılayan program, toplam maliyet 300 bin dolar (geliştirici maaşı)
  Ben bir yazılım tüketicisi olsam, ayrıntılar umurumda değilse ve sadece fiyata bakıyorsam, kesinlikle 6 kat ucuz olanı seçerim

  • Yeni dış gereksinimler geldiğinde değişiklik gerekeceğini de hesaba katmak lazım. Böyle durumlarda, eğer söz konusu yazılım işin çekirdeğiyse, sağlayıcıyı değiştirmek zorunda kalabilirsin. Bu yüzden ister B2B ister B2C olsun, bakım ve destek her zaman kritik. Yazılımın değişime uyum sağlayabilmesi gerekir

  • Yani şu şaka da buradan çıkıyor: “Bu kodu ben ve Copilot anlıyorduk. Artık sadece Copilot anlıyor.”

  • “Gerçek dünyaya bağlı yeterince büyük sistemlerin matematiksel olarak doğru olduğu kanıtlanamaz” sözüne formel doğrulama alanında çalışanlar şiddetle itiraz edebilir ya da içten içe katılabilir

  • İki senaryo arasında sürüm yükseltmesi gerektiğinde hangisinin daha ucuz ve hızlı olduğuna bakmak gerekir. Şu an için insan geliştirici tarafının daha ucuz olduğunu düşünüyorum ama gelecek konusunda emin değilim

  • Aslında gerçek hayatta bu iki seçeneğin de örneğini pek görmedim

• Nihai evrim aşaması, insanların okumasına bile gerek olmayan tamamen makine odaklı bir programlama dili olabilir mi diye düşünüyorum. LLM neden ille de Python ya da Swift gibi insan dostu dillere çevirmek zorunda olsun? Doğrudan çalışır sonucu üretse yeter; o zaman bakım kavramı da anlamını yitirir. Henüz orada değiliz ama günün birinde buraya gideceğiz gibi geliyor

  • İyi yazılım her zaman bakım hâlinde olmalıdır. Çünkü sürekli yeni gereksinimler çıkar. Bir kez özellik çıkarıp sonsuza kadar bitmiş sayılacağı inancı başlı başına komik. Gelecekteki değişiklikleri hesaba katan kod, test ve dokümantasyon bu yüzden önemli. LLM’ler anlamsız black-box kodlar üretmeye başlarsa bundan daha korkutucu bir şey olamaz. LLM’lerin insan seviyesinde kodlamaya ulaşıp da kimsenin bunu umursamaması bilimkurgu alanına girer. Kod yazmak, gerçekten faydalı yazılım üretme sürecinin yalnızca bir parçasıdır

  • Aslında machine code zaten böyle bir şey değil mi? LLM’ler insanların okuyacağı arayüzler için optimize edildiği için JSON üretiyorlar, BSON ise neredeyse hiç kullanılmıyor

  • Bunun hangi problemi çözeceğini söyleyebileceğimizden emin değilim. Ama hangi problemleri yaratacağı oldukça açık

  • Bu, LLM’in insanlar için yazılmış kodu öğrenip içselleştirmesi, sonra tekrar kod üretip istenen davranışı elde etmeye çalışması gibi bir “telefon oyunu” hissi veriyor. Acaba davranışı doğrudan üretmesi mümkün olmaz mı diye düşündürüyor

  • İnsanların okuması zor dillere örnek olarak Malbolge verilebilir. Hatta ilk "Hello World" programı bile genetik algoritma ile üretilmişti

• Orijinal gönderinin yazarıyım. Hepinizle sohbet etmeyi dört gözle bekliyorum

• ‘vibe coding’ terimi fazla kusursuz bir ifade. Tıpkı ‘cloud computing’in anlamının aşırı genişlemesi gibi. Eskiden elastik biçimde EC2 instance açıp işi bitince kapatmayı ifade ederdi, ama metafor o kadar sezgiseldi ki sonunda Gmail bile bütünüyle ‘cloud’ diye anılır oldu.