Vibe coding ve agentic engineering, istediğimden daha fazla birbirine yaklaşıyor
(simonwillison.net)- vibe coding ile agentic engineering başlangıçta kod incelemesi ve hesap verebilirlik ölçütleriyle birbirinden ayrılıyordu; ancak kodlama ajanlarının güvenilirliği arttıkça gerçek üretim işlerinde bu sınır bulanıklaşıyor
- vibe coding, kodu neredeyse hiç incelemeden istenen sonuç çıkarsa kabul etme yaklaşımı olduğu için kişisel araçlarda faydalı olabilir; ancak başkalarının verileri ve kullanıcı deneyimi söz konusu olduğunda sorumsuz bir yöntem gibi görünüyor
- Claude Code gibi ajanlar JSON API endpoint'leri, SQL sorguları, testler ve dokümantasyonu tekrar tekrar iyi şekilde hallettikçe, üretilen her kod satırını incelememe durumu ortaya çıkıyor; bu da insan ekiplerin aksine itibarı ya da sorumluluğu olmayan bir şeye güvenme riskini yaratıyor
- artık 100 commit, iyi bir README ve kapsamlı testleri olan bir repository'yi 30 dakikada oluşturmak mümkün; bu yüzden sadece dış görünüşe bakarak kaliteyi değerlendirmek zorlaştı ve asıl ölçüt birinin o yazılımı düzenli olarak kullanmış olması haline geldi
- yapay zeka araçları yazılım mühendisinin deneyimini ikame etmekten çok güçlendiriyor; kod üretim hızı günde 200 satırdan 2.000 satıra çıkınca darboğaz tasarım, doğrulama, operasyon ve gerçek kullanıma kayıyor
Vibe coding ile agentic engineering arasındaki sınır
- Heavybit High Leverage podcast Ep. #9'da yapay zeka kodlama araçları konuşulurken, vibe coding ile agentic engineering'in gerçek işlerde birbirine daha fazla yaklaştığı görülüyor
- Daha önce Not all AI-assisted programming is vibe coding (but vibe coding rocks) yazısında vibe coding ile sorumlu yapay zeka destekli programlama açıkça ayrılmıştı; ikincisine daha sonra agentic engineering denmeye başlandı
- vibe coding, kodu neredeyse hiç incelemeden, hatta programlama bilmiyor da olabilecek bir kullanıcının istediği çıktıyı talep edip çalışıyorsa kabul etmesi, çalışmıyorsa yeniden istemesi yaklaşımıyla tanımlanıyor
- Hataların yalnızca kişinin kendisine zarar verdiği kişisel araçlarda vibe coding yararlı olabilir; ancak başkalarının verileri ve kullanıcı deneyimi söz konusu olan yazılımlar geliştirirken sorumsuz bir yaklaşım gibi görünüyor
- agentic engineering ise profesyonel bir yazılım mühendisinin güvenlik, sürdürülebilirlik, operasyon ve performans gibi kısıtları anlayarak yapay zeka araçlarını kendi kapasitesinin en üst seviyesinde kullanması anlamına geliyor
- Amaç daha düşük kaliteli çıktıları daha hızlı üretmek değil, daha yüksek kaliteli production sistemlerini daha hızlı oluşturmaktır
- Sorun şu ki kodlama ajanları daha güvenilir hale geldikçe, production düzeyindeki işlerde bile üretilen her kod satırı artık gözden geçirilmiyor
Kod incelemesini atlatan güven
- Claude Code'dan bir JSON API endpoint'i oluşturmasını ve bir SQL sorgusu çalıştırıp sonucu JSON olarak dökmesini istediğinizde bunu doğru yapacağına dair bir güven oluşuyor
- Otomatik testler ve dokümantasyon eklemesini istediğinizde de sonucun iyi olacağını beklemeye başlıyorsunuz ve bu süreçte gerçek kodu incelemediğiniz durumlar ortaya çıkıyor
- Kodu incelemediyseniz, onu production'da kullanmanın sorumlu bir davranış olup olmadığına dair bir suçluluk hissi kalıyor
- Bu durum, büyük bir organizasyonda engineering manager olarak çalışırken başka bir ekibin yazılımını kullanma biçimine benzetilebilir
- Başka bir ekip bir görsel yeniden boyutlandırma servisi sunuyorsa, genellikle o ekibin yazdığı her kod satırını okumazsınız
- Dokümantasyona bakar, görseli yeniden boyutlandırmayı dener ve sonra kendi özelliğinizi yayına alırsınız
- Ancak hata ya da performans sorunu gördüğünüzde Git repository'sine bakabilirsiniz
- Çoğu durumda ilgili servisi yarı kara kutu gibi ele alırsınız
- Ajanlara da giderek aynı şekilde yaklaşılmaya başlanıyor; ancak insan ekiplerin aksine Claude Code'un profesyonel bir itibarı ya da hesap verebilirliği yok
- İnsan ekipler geçmişte iyi yazılımlar geliştirerek itibar oluşturabilir ve kötü sonuçların kendi profesyonel itibarlarını etkileyeceğini bilir
- Claude Code böyle bir itibara sahip olamaz; ama tekrar eden basit işleri tercih edilen tarza uygun biçimde doğru yaparak güven kazanıyor
- Burada sapmanın normalleşmesi unsuru var
- Model, yakından denetlenmeden de doğru kod yazdıkça güven artıyor
- Sonrasında yanlış bir anda aşırı güven yüzünden zarar görme riski de aynı ölçüde büyüyor
Yazılımı değerlendirmek zorlaşıyor
- Eskiden bir GitHub repository'sinde 100 commit, iyi bir README ve otomatik testler varsa, projeye ciddi emek ve özen harcandığını düşünmek kolaydı
- Artık 100 commit, şık bir README ve tüm kod satırlarını kapsayan testleri olan bir Git repository'sini 30 dakikada oluşturmak mümkün
- Böyle bir repository, uzun süreli emek ve dikkatle geliştirilmiş bir projeyle dışarıdan bakınca aynı görünebilir
- Gerçekte de o kadar iyi olabilir; ancak dışarıdan anlamak zor ve kendi projeleriniz için de aynı sorun geçerli
- Testlerin ve dokümantasyonun kalitesinden daha önemli görülen ölçüt, birinin o yazılımı gerçekten kullanmış olması
- Sonuç vibe coded olsa bile, onu üreten kişi son iki haftadır her gün kullanmışsa, neredeyse hiç çalıştırmadan ortaya atılmış bir çıktıya göre çok daha değerli kabul ediliyor
Darboğaz kod yazımından başka aşamalara kayıyor
- Günde 200 satır kod yazılan bir durumdan 2.000 satıra çıkıldığında, yazılım geliştirme yaşam döngüsünün başka bölümleri kırılmaya başlıyor
- Mevcut yazılım geliştirme yaşam döngüsü, günde birkaç yüz satır kod üretme hızına göre tasarlanmıştı
- Darboğazdaki değişim yalnızca aşağı akış aşamalarını değil, yukarı akış aşamalarını da etkiliyor
- Jenny Wen'in sunumu, mevcut tasarım sürecinin “tasarımı doğru yapmak zorundasınız” varsayımı üzerine kurulu olduğunu öne sürüyor
- Çünkü işi mühendislere devredip onların üç ay boyunca yanlış şeyi inşa etmesi felaket olur
- Tasarım, maliyetli bir uygulama sürecine yol açtığı için kapsamlı tasarım süreçleri kullanılır
- Ama build süreci üç ay sürmüyorsa, yanlış yapmanın maliyeti çok düştüğü için tasarım süreci çok daha fazla risk alabilir
Buna rağmen yazılım mühendisliği kariyerinin bittiğini düşünmeme nedenim
- Ajanlarla konuşmak, çoğu insana anlaşılması güç bir “moon language” gibi görünüyor
- Bilgisayarların artık kendi başına kod yazabiliyor olması, yazılım mühendisliği kariyerinin bittiği anlamına gelmiyor; bunun nedenlerinden biri bu araçların mevcut deneyimi güçlendirmesi
- Ne yaptığını bilen biri, yapay zeka araçlarıyla birlikte çok daha hızlı ilerleyebilir
- Yapay zeka araçlarını kullandıkça, yazılım üretmenin kendisinin ne kadar zor olduğu tekrar tekrar ortaya çıkıyor
- Ulaşılmak istenen hedefler, eldeki tüm yapay zeka araçlarına rağmen hâlâ zor kalıyor
- Matthew Yglesias, tweet'inde “Beş ay sonra fark ettim ki vibecode yapmak istemiyorum. Profesyonelce yönetilen yazılım şirketlerinin yapay zeka kodlama desteğini kullanarak daha fazla, daha iyi ve daha ucuz yazılım ürünleri üretip bunları bana satarak benden para kazanmasını isterim” diye yazdı; buna katılıyorum
- Bu, sıhhi tesisatla ilgili yeterince YouTube videosu izledikten sonra evinizin tesisatını kendiniz tamir edebilecek olsanız bile, yine de bir tesisatçı tutmayı tercih etmenize benzetiliyor
SaaS ve şirket içi geliştirmenin riski
- Şirketlerin SaaS kullanmak yerine kendi çözümlerini geliştirebilmesinin yarattığı tehdit konusunda da, gerçek kullanım ile doğrulanmış yazılımı tercih etme ölçütü aynen geçerli
- Kişisel projelerde, en az birkaç hafta boyunca onu yapan kişinin bizzat kullandığı araçları tercih ediyorum
- Bunu enterprise sürümüne uyarlarsak, en az iki farklı büyük şirket tarafından altı ay boyunca başarıyla kullanılmamış bir CRM'i benimsemek istemem
- Risk almadan önce gerçekten çalıştığı kanıtlanmış çözümler istiyorum
1 yorum
Hacker News görüşleri
Vibe coding ve LLM'ler disiplinsiz mühendislik organizasyonları ya da mühendisler yaratmadı; yalnızca mevcut sorunları görünür kılıp hızlandırdı
Birçok mühendisin kod yazım standartları ve pratikleri gevşek ya da hiç yok, birçok ekibin de kodu üretim ortamına dağıtma standartları zayıf
Bu yeni bir olgu değil; sadece yazılım geliştirme yaşam döngüsünde standartlara hiç uymamış birey ve ekiplerin artık çok daha fazla kod üretmesi ve fikirleri somutlaştırmasının kolaylaştığı anlamına geliyor
Hızlı kod yazdığı için iyi mühendis olan bir ekip arkadaşı hiç görmedim
Tanıdığım en iyi mühendisler, deneyim ve dikkatli muhakemeye dayanarak takımla kritik içgörüler paylaşan ve sistemin yönünü iyiye çeviren kişilerdi
“Claude, bana bir sistem kur. Ama iyi kur. Teşekkürler!”
Eskiden kod tabanı özellik geliştirmeye direnmeye başlayınca o anki darboğaz düzeltilir, sonra bir sonraki direnç noktasına kadar ertelenirdi
Özellik geliştirirken bir miktar refactoring yapılan bir yaklaşımdı, ama frontier modeller “sorun olduğu an”ı daha ileri itiyor
Verilen kod yığınını belli bir noktaya kadar idare edebildikleri için, LLM daha fazla regresyon üretse ya da daha fazla gereksinimi kaçırsa da bu daha çok böyle görünür; insana işin zorlaştığı hissi daha az gelir
Sonra bir anda o kadar çok şey bozulur ki düzeltmek gerekir, ama tüm kod tabanı benim vermediğim kararların fraktal katmanları haline gelmiştir ve çözmesi zordur
Kodu doğrudan düzenlemediğiniz için, “bunu böyle eklersem gerginlik yaratır” duygusunu bedensel olarak hissetme refleksi kaybolur; bu yüzden refactoring için bir çıkış yolu bulmak da zorlaşır
Kod her zaman refactor edilebilir ve ajana küçük, modüler parçalarla dosyalar yazması zorlanabilir
İster ajan yazsın ister insan, iyi mühendislik iyi mühendisliktir
Şimdilik en azından mimariyi anlayıp yöneten bir insan olmalı; ajanlar keşif ve öneri konusunda çok iyi yardımcı olabilir
Son birkaç haftadaki gelişmeleri kaçırmadıysam, AI daha güvenilir hale gelmiş gibi değil; daha çok hatalar daha incelikli hale gelmiş gibi görünüyor
Kod derlenmiyorsa bunu bulmak kolaydır ve derlenip çalışmıyorsa da bir yere kadar bulmak kolaydır
Ama derlenip çalışırken bazı sınır durumlarında yanlış davranıyorsa, güvenlik açığı taşıyorsa ya da teknik borç ve şüpheli mimari kararlar getiriyorsa bunu bulmak çok daha zordur ve inceleme yükü hiç azalmaz
Hatta kulağa makul gelen kod, bariz kötü koda göre inceleme sırasında zihinsel olarak daha yorucudur
Önce çeşitli testler yazdırır, sonra kodun bunlara uyup uymadığını kontrol eder ve ajanın kodu doğru organize etmesini sağlarsınız
Ama şu anda yukarıdan gelen baskı o kadar fazla ki her yerde geniş çapta uygulansın isteniyor; buna karşı çıkmak ise çok yıldırıcı ve kariyer açısından da kısıtlayıcı olduğu için insanı yıpratıyor
Bariz sorunları işaret ettiğinizde bir o kadar dolambaçlı çözüm çıkıyor, o dolambaçlı çözümlerde de kısa süre sonra başka sorunlar ortaya çıkıyor ve sonsuz yeni çözümler doğuyor
Bir noktadan sonra bütün bunlar makinenin kendisi için yapılan iş gibi hissettiriyor
Birçok şirkette asıl hedef bulanıklaşıyor ve geriye sadece LLM'nin kendisi kalmış gibi görünüyor
Şirketin geleceğini buna bağlayıp bu vizyonu hayata geçiren insanlar sonuçlardan kaçabilecekleri yumuşak bir çıkış garantisine mi sahip, yoksa akılcılık bütünüyle mi terk ediliyor, bilmiyorum
Sağlam mühendislik ilkeleriyle sorunlar hafifletilebilir, ama bilişsel yük, geliştirici zamanı, para ve sınırlı kaynaklar açısından gerçekte ne kadar verim oluştuğu şüpheli
“Günde 200 satırdan 2.000 satıra çıkabiliyorsanız ne bozulur?” cümlesinde, mühendislik çıktısının ölçütü olarak kod satırı sayısı kullanmak utanç verici
200 satırı incelemekle 2.000 satırı incelemek tamamen farklı bir iş yükü
Aynı programı bu kez kafamda yeniden kurup ChatGPT'yi sadece arama ve otomatik tamamlama gibi kullandığımda aynı sonuç 1.500 satırda çıktı
Çaba farkı da dürüst olmak gerekirse çok büyük değildi, ama elle yazılmış yaklaşımın avantajı, önce vibe coding sürümü sayesinde ne yapmak istediğimi zaten düşünmüş olmam olabilir
Yazılım incelemesinin girdisi olarak kod satırı sayısını kullanmak mantıklı
Çünkü kelimenin tam anlamıyla her satırı okumak zorundasınız
Sadece geliştirici üretkenliğinin tek ölçütü olarak berbattır ve sorun da bu şekilde kullanılmaya çalışıldığında çıkar
Yine de birçok şirket, ekip, dil ve uygulama bağlamında anında sezgisel olarak anlaşılabilen ve karşılaştırılabilen neredeyse tek metrik olduğu için kullanışlıdır
Aynı ekip aynı üründe çalışsa bile 1.000 satırlık bir değişiklik hızla bitebilir, 1 satırlık bir hata düzeltmesi ise günler süren debugging gerektirebilir
Bu yüzden PR, özellik ya da story point'leri bağlam dışı karşılaştırmak zordur; sektörde standart bir geliştirici üretkenliği metriği mümkün olsaydı herkes kullanırdı ama bunun doğası gereği zor olduğunu düşünüyorum
Bu tür karşılaştırmalarda bağlamın aynı olduğunu varsaymak işe yarar
Örneğin belirli bir şirkette, belirli bir ürünü, belirli bir teknoloji yığını ve kalite süreciyle geliştiren ekip dün N1 satır, bugün AI ile N2 satır üretiyorsa zaman içinde N1 ile N2 arasındaki fark gerçek etkiyi yaklaşık olarak gösterir
Sıkı AI destekli geliştirme üretkenliği çalışmaları da genel olarak aynı grupta AI kullanımından önceki ve sonraki PR'leri karşılaştıran A/B test tarzı ölçümler yaptı
Bana göre fark, pipeline'ın kalitesi ve sıkılığı
Vibe coding, bir ya da birkaç deneme yapıp sonucu kabaca kontrol ettikten sonra bozulana kadar kullanma yaklaşımıdır
Hafif proof of concept'ler veya riski düşük kişisel, aile içi ya da küçük ekip uygulamaları için uygundur
Agentic engineering ise işlevsel doğruluk, performans, altyapı, dayanıklılık/kullanılabilirlik, ölçeklenebilirlik ve bakım kolaylığı gibi daha geniş kaygıları önemser
İş akışını yöneten çok aşamalı bir pipeline vardır; proje alımı, seçimi, spesifikasyon, epic'lere ayırma, story'lere ayırma, kodlama, dokümantasyon ve dağıtım gibi aşamalar içerebilir
Her aşamada test geçme ya da performans eşiği gibi belirleyici kalite kapıları ile iş değeri, spesifikasyonun bütünlüğü, kod zarafeti ve ubiquitous language'ın sıkılığı ile sadeliği gibi düşmanca incelemeler bir arada bulunur
Bu da bir slider
Bazen tek bir özelliği dağıtmak için röportaj yapıp token yakmak, üç tur düşmanca inceleme, değer tahmini ve ayrıntılı spesifikasyon yapmak istemez ve bileti doğrudan sisteme atarsınız
Opus, GPT-5.5 ve daha küçük modelleri her gün kullanıyorum ama tüm işi onlara vermiyorum
Spesifikasyonları tanımlayıp iyileştirmeye epey emek verseniz bile, insan PR incelemesinden geçmeyecek aptalca şeyler hâlâ yapıyorlar
Çıktıya güvendiyseniz ya da büyük bir ajan pipeline'ı kurup sahte bir istikrar hissi edindiyseniz, bunların kod tabanına sessizce sızmasına izin vermek kolay olurdu
10 yıl sonra daha iyi olabilir ama bugünün vibe coding'i ve agentic engineering pipeline'ları bana LLM'lere bütünüyle devretmenin aynı temasının varyasyonları gibi görünüyor
Bu sabah bile tek bir dosyada Opus on Max'e değişiklik yaptırabileceğimi düşündüm ama neredeyse her turda hata yaptı ya da bir şeyi kaçırdı ve düzeltmem gerekti
Önerdiği kod büyük ölçüde çalışırdı ama gereksiz yere karmaşıktı ve benim elle basitleştirdiğim kısımları yeniden geriye götürdü
Bu durum binlerce ajan commit'iyle çarpıldığında kod tabanı hızla kötüleşir
Geliştirme ekipleri tasarım, test ve inceleme gibi doğru süreçler olmadan üretmeye çalıştıklarında zorlanır
Bu, ajan kodlamadan önce de böyleydi ama şimdi özellikle daha da öyle; bu süreçte ajanlardan nasıl yararlanacağını anlayan ekipler en başarılı olanlar olacak
Kodlama ajanlarının ilk denemede çözüme çok yaklaştığını ama son %10 ya da %5'i tutturmak için muazzam emek gerektiğini hissetmediniz mi
Soruna yaklaşımınızı değiştirirseniz ajan bu boşluğu kapatabilir
10 yıl önce her 10-15 dakikada bir kodlamayı bırakıp refactoring, test ve analiz yaparak her şeyin mükemmel olup olmadığını kontrol ederdim
Çünkü bir bug daha sonraki tüm kodu kirletirdi
Kodlama ajanları bunu yapamıyor ve hataları ya da yanlış mimariyi taşıyarak ilerliyor
İçgüdüsel olarak ajanı ara ara durdurmak istersiniz ama çeşitli nedenlerle bu mümkün değil
Bunun yerine maliyet çok ucuz olduğu için ajanın ilk hata yaptığı noktayı bulup prompt'u düzeltmeli ve kodu düzeltmek yerine her şeyi silip baştan yeniden çalıştırmalısınız
Prompt mükemmel kod üretmeye başlayana kadar bu döngüyü sürdürmeniz yeterli
Buna insanın hâlâ çok iş yapması gerektiği itirazı gelecektir ama mesele tam da bu
İnsan hâlâ gerekli ve aracı bu şekilde kullanırsanız kod yazma hızı 10 kat artar
“Çalışan bir şey”i oldukça hızlı yapabilirsiniz ama başka seçenekleri değerlendirip iyileştirmek, test etmek ve güven oluşturmak uzun sürer
Ana fikir doğru ama sınırın nerede olduğu konusunda kimsenin fikri yok
Önümüzdeki yaklaşık 1 yıl boyunca herkes bunu keşfetmeye çalışacak; bu yüzden de “GitHub'ı yeniden icat etmemiz gerekiyor” lafını çok duyuyoruz
Çoğu durumda o son bölümü de makineleştirmek için yatırım yapmak ekonomik olarak mantıklı değildir
Bence LLM sağlayıcıları en baştan yanlış yaklaşımı seçti
Emeğin yerine geçmeye odaklanmak yerine emeği tamamlamaya odaklanmaları gerekiyordu ve görünüşe göre pahalı bir ders aldılar
Baştan başlamak daha iyi olabilirdi ama başlarken istediğim mimarinin nasıl görünmesi gerektiğini bilmiyordum
LLM mevcut mimariye özellik uydurmakta zorlanıyor diye çalışan tüm kod tabanını atıp yeniden başlayamazsınız
Akıllı, alçakgönüllü ve öğrenmeye devam eden birinin yazdığı harika bir yazı
Hoşuma giden cümlelerden biri şuydu: “Bilgisayarların kendi kodlarını yazabiliyor olması, yazılım mühendisi kariyerinin bittiğinden korkmamamın birçok nedeninden biri değil. Kısmen bunun nedeni, bunların mevcut deneyimin birer amplifikatörü olması. Ne yaptığınızı biliyorsanız çok daha hızlı koşabilirsiniz”
Bir de şu kısmı beğendim: “Bu araçları kullanırken yaptığımız işin ne kadar zor olduğunu sürekli yeniden hatırlıyorum. Yazılım yapmak delicesine zor. Dünyadaki tüm AI araçlarını verseniz bile burada başarmaya çalıştığımız şey hâlâ gerçekten çok zor”
Yukarı akış işlerin de birlikte değiştiği tespiti çok yerinde
Özellikle tasarım araçları çok hızlı evriliyor; artık Figma tarafında kalan çeviri maliyetine katlanmaya değmez gibi görünüyor
Korkutucu olan kısım, kod tabanında AI karmaşıklığı katmanlarının birikmesi ve insanların artık kodu anlayamaması yüzünden en güncel modellerin bunu çözümleyip değiştirmesinin yüksek maliyetli hale gelmesi
Yakında kod yeniden kullanımı ortadan kalkabilir ve insanlar sürekli tekerleği yeniden icat ederek para yakmaya başlayabilir
İlk Android uygulamaları yapılırken IDE kullanmak zorunluydu ve bir düğmeye basınca “Hello World” bildirimi gösterebilmek için saçma miktarda boilerplate code yazmak gerekiyordu; insanın ruhunu emen bir deneyimdi
Tekrar edin: Çoğu yazılım ömrünün büyük kısmını bakım aşamasında geçirir
Dolayısıyla yazılımın kazandırdığı paranın da büyük bölümü bakım aşamasında kazanılır
Sektör neredeyse 100 yıl geçmesine rağmen bunu hâlâ anlamış değil
Alan Kay'in bilgisayar devriminin henüz gerçekleşmediğine dair sözü %100 doğru
Bugünkü tüm ilerlemelere rağmen araçlar genel olarak hâlâ taş devri seviyesinde
Benim büyük umudum, AI'ın bizi mevcut paradigmayı geri dönülemez şekilde tamamen kıracak noktaya kadar hızlandırması ve sonunda yeni, farklı ve daha iyi bir şey yapabilmemiz
O yüzden şimdilik AI ile yazılım geliştirme yaşam döngüsüne bir jetpack takalım ve sonuna kadar deneyelim
Hızlı hareket edelim ve gerçekten bir şeyleri kıralım
Zamanında yapılmış bir gözlem ve bana da çok doğru geliyor
Nispeten basit bir toplu indirme → dönüştürme → API endpoint'i kurmam gerekiyordu ve epey ayrıntılı bir prompt yazdım ama veri kaynağı gibi uygulama ayrıntılarının çoğunu boş bıraktım
Opus 4.7, bunu benim yapacağıma yaklaşık %90 benzer şekilde kurdu ve yardımcı metotlarla adım adım doğrulamayı çok daha fazla ekledi
Çok iyiydi ve bana daha zor problemler üzerine düşünme alanı açtı
Esasen bir Python geliştiricisiyim ama Rust ya da Go gibi aşina olduğum fakat aynı seviyede olmadığım başka backend dillerini de düzenli kullanıyorum
Tek bir dilde yoğunlaşmış yaklaşık 13 yıllık deneyimim ve diğer dillere dair formal öğrenimim olduğu için LLM'leri yönlendirmek çok daha kolay oluyor
Sözdizimi, temel yapı taşları, paket yöneticisi, testler vb. şeyleri öğrenme yükü, eski programlama yöntemlerine kıyasla büyük değil
Kısa süre önce Claude cowork/code ile raporlama otomasyonu yapan geliştirici olmayan bir çalışma arkadaşıma yardım ettim
O kişi business intelligence tarafını iyi anlıyordu ama bir RDP açıp satıcı veritabanının üzerindeki MS Access soyutlamasına değer yazan bir pyautogui sarmalayıcısını vibe coding ile kurmak için gerekli temel ifadelerde zorlanıyordu
Meslek olarak geliştiricilik önümüzdeki 5-10 yıl boyunca güvende gibi görünüyor