Gerçekten birçok açıdan katılıyorum haha Aşırı bunaltıcı olduğu için artık salıp sadece aldığım para kadar çalışayım moduna geçince, ironik şekilde işlerin daha pürüzsüz ilerlemesinden memnun oluyorlar. Aslında riskli bir geliştirme yönü görsem bile artık umurumda değil durumuna gelmiş oluyorum.
Görüş: Yapay zeka sıkıcı işleri hızla hallettiği için aksine enerji veriyor ve yeni teknoloji stack'lerini öğrenme maliyetini düşürdüğü için olumlu karşılanıyor.
Örnek: Yabancı bir dil veya framework kullanırken, yapay zeka ajanları sayesinde sıkıcı öğrenme sürecini atlayıp doğrudan uygulamaya odaklanılabildi.
Tartışma: 'Vibe coding'in sadece yapay zekadan yardım almak mı, yoksa üretilen kodu incelemeden yalnızca sonuca bakmak mı olduğu konusunda tanımlar farklılaşıyor.
Ortak nokta: Başlangıçta 'kodu incelememe' anlamı taşıyan olumsuz bir nüansı vardı; ancak bugün anlamı genişleyerek yapay zeka destekli kodlamanın genelini kapsayan bir terime dönüştü.
3. "Doğrulama olmadan hız, teknik borçtur" (temkinli bakanlar)
Eleştiri: Kodu anlamadan yalnızca yapay zekanın ürettiği çıktıya güvenmek riskli. Daha sonra ortaya çıkacak bug'ların veya bakım maliyetlerinin (teknik borcun) daha yüksek olacağı düşünülüyor.
Benzetme: "Sürücünün nereye gittiğini bilmeden otonom araca binmesi gibi" denilerek, anlayış olmadan yapılan uygulamanın sonunda problem çözme yeteneğini düşürdüğü vurgulanıyor.
4. "Bağlam değiştirmenin yorgunluğu" (katılanlar)
Katılım: Yapay zeka kod üretirken sık bağlam değiştirme (Context Switching) yaşanıyor ve bunun sonucunda beynin bilişsel yükü hızla artıyor.
Belirti: Yapay zekanın çıktısını inceleyip düzeltme süreci tekrarlandıkça, doğrudan kod yazmaya kıyasla zihinsel yıpranma daha büyük oluyor. 4 saatlik çalışma, tüm gün çalışılmış gibi yorucu hissettiriyor.
Deneyim: Sorunu bizzat çözdüğünde hissedilen başarı duygusu (dopamin) ortadan kayboluyor. Lego'yu kendi ellerinle kurmanın keyfi yerine sadece bitmiş ürüne bakıyormuşsun gibi boş bir his bırakıyor.
Sonuç: Sürecin keyfi olmadan yalnızca çıktıyı hızla üretmeye odaklanan çalışma biçimi geliştiriciyi tüketiyor.
6. "Acemi için zehir, uzman için ilaç" (yetkinliğe göre fark)
Analiz: Deneyimli geliştiriciler yapay zekanın hatalarını hızla fark edip düzeltebildiği için verimlilik artıyor; ancak acemiler yanlış kodu olduğu gibi kullanarak öğrenme fırsatını kaçırma ve kötü kod üretimini artırma riski taşıyor.
7. "Yönetici rolüne zorunlu geçiş" (rol değişimi)
Durum: Geliştiricinin doğrudan kod yazan bir 'üretici'den, yapay zekanın durmadan ürettiği kodu inceleyip düzelten bir 'yönetici/reviewer'a zorunlu olarak dönüştüğü görülüyor.
Yük: Bu durum, 5 junior geliştiricinin (yapay zeka) yazdığı kodu tek başına gerçek zamanlı incelemekle benzer düzeyde yoğun bir stres yaratıyor.
8. "İş mantığını anlamama" (sınırların işareti)
Sorun: Yapay zeka kodu iyi yazsa da iş bağlamını veya genel mimariyi anlayamıyor.
Gerçek: Sonuçta iş gereksinimlerini koda uyarlama ve edge case'leri ele alma gibi karmaşık işler hâlâ insanın sorumluluğunda kalıyor; darboğaz da bu aşamada ortaya çıkıyor.
9. "Dinlenmenin ve boşluğun yok oluşu" (makine zamanı)
Benzetme: Geçmişte fabrika işçilerinin makine hızına göre çalışması gibi, bugün de insanlar yapay zekanın hızlı üretim temposunun peşinden sürüklenerek bir tür 'makine zamanı'na hapsoluyor.
Gereklilik: Derlemenin bitmesini beklemek gibi 'zorunlu molalar' ortadan kalktığı için beynin bilgiyi işlemesine ve dinlenmesine fırsat kalmıyor. Bu yüzden bilinçli olarak mola vermek şart.
10. "Aracın geçiş dönemi sorunu" (gelecek öngörüsü)
Teşhis: Bugünkü yorgunluk, yapay zekanın üretim hızına kıyasla doğrulama araçlarının (test, lint vb.) geride kalmasından doğan uyumsuzluktan kaynaklanıyor.
Çözüm: Üretim hızıyla aynı seviyede doğrulamayı otomatikleştiren araçlar gelişirse, bu yorgunluk sorunu çözülebilir.
1. Biçime yönelik beğeni ve itirazlar ("LinkedIn tarzı mı?")
Eleştiri baskın: Her cümlede satır başı yapılan formatın, "LinkedIn influencer’larının gösteriş meraklısı yazıları" ya da "yapay zeka tarafından üretilmiş metin" gibi göründüğüne dair çok sayıda sert eleştiri var. İçerik olmadan sadece ambalajın abartıldığı söyleniyor.
Kısmi savunma: Bunun, modern insanların kısa dikkat süresi düşünülerek okunabilirliği yüksek bir yerleşim olduğu ya da şiirsel ritim amaçlayan bir üslup tercihi olduğu görüşü de var.
2. 'Kalın arzu'yu hayata geçirme tanıklıkları
Başarı örnekleri: Heykel yapma (sculpting), analog devre tasarımı, kartpostal yazma gibi fiziksel ve zaman alan hobiler sayesinde depresif duyguları aşıp hayatın yoğunluğunu yeniden kazandıklarını anlatan deneyimler paylaşılıyor.
Ekmek pişirme tartışması: Metindeki "verimsiz ekmek pişirme" örneği üzerine, mühendislerin fırın kullanarak "fermantasyon süresini optimize etme" ipuçları paylaşmasıyla ironik bir alt tartışma doğmuş.
3. Felsefi ve dini köken analizi
Eski bilgeliğin yeniden markalanması: Bunun, Budizm’deki "aç ruhlar (Hungry Ghosts)" kavramı ya da Batı felsefesinin klasik temalarını (Augustinus vb.) modern terimlerle (Thin/Thick) yeniden paketlemekten ibaret olduğu yorumu yapılıyor.
İçgörünün geçerliliği: Tamamen yeni bir içerik olmasa da, modern topluma uygun şekilde iyi derlenmiş bir içgörü olduğu konusunda uzlaşma var.
4. İkili karşıtlığa dayalı mantığın sınırları
Kavramların aşırı basitleştirilmesine karşı uyarı: "Tüketim = sığlık, üretim = derinlik" şeması tehlikeli bulunuyor. Derinlikli okuma (tüketim) da kalın olabilir, ticari üretim de sığ olabilir.
Dinlenmenin değeri: Dalgın dalgın oturmak ya da oyun oynamak gibi "sığ görünebilen" faaliyetlerin de toparlanmak için gerekli bir dinlenme biçimi olabileceğinin göz ardı edildiği belirtiliyor.
5. Yapısal ve çevresel nedenlere işaret
Kişinin suçu değil: Asıl sorunun, IT şirketlerinin kasıtlı olarak tasarladığı dopamin ödül sistemi (System) olduğu söyleniyor.
Gerçek hayattaki kısıtlar: "Biz zaten bolluk içindeyiz" öncülüne itiraz ediliyor. Konut giderleri, sağlık masrafları gibi hayatta kalma tehditleri (ekonomik yoksulluk) nedeniyle, insanın rahatça "kalın arzu" peşinden gidemediği gerçekliği dile getiriliyor.
Beyaz olan kod, siyah olan terminal gibi bir teknoloji okuryazarlığı eksikliği durumu değil mi? Loglara bakmayı bilmeme ya da kopyala-yapıştır olmadan hiç geliştirme yapamama haliyle de aşağı yukarı aynı.
Bu yazının yanı sıra Part 1'de kıdemli mühendislerin neden ayrıldığı incelenmiş; ayrıca Part 2 olan The Economic Intervention That Stops Engineer Attrition yazısı da var.
Dün de Mac'te genel depolama alanı açmanın (Claude'a kendi haline bırakıp sildirmek) çok kullanışlı olduğuna dair bir Facebook paylaşımı görmüştüm ama...
Ben böyle şeylere bakarken doğrudan aracın sistem prompt’unun önemine odaklanıyorum. Şu anda Cursor’da kullanırken kişisel olarak opus >= gpt 5.2 > gemini 3 diye düşünüyorum. Onun dışında Sonnet olsun, 5.1 olsun... ben artık kişisel olarak kullanmıyorum. Ama... gpt5.2’de effort seviyesine göre fark çok büyük. Gerçi yüksek effort her zaman daha iyi olmuyor. Bu yüzden ağırlıklı olarak opus ve gemini kullanıyorum. Bazen zor bir problemle karşılaşırsam üçünü de kod yazdırıp birbirlerinin kodunu değerlendirmelerini sağlıyorum, sonra da ben kontrol edip uyguluyorum.
Görünüşe göre --dangerously-skip-permissions seçeneğini sandbox ortamı dışında çalıştıran çok fazla insan var. Acaba "danger"ın ne anlama geldiğini bilmiyorlar mı? TT
Hmm, tersinden bakınca kendi garip kodunu yazıp sonra da "bunu GPT yaptı" diye GPT'yi kalkan gibi kullanan junior'lar da gördüm; o yüzden kişiden kişiye değişiyor gibi.
Görüşünüz için teşekkürler! README'ye yazmak iyi olabilir gibi görünüyor.
Ayrı olarak, açık kaynak bir Rust paketi düzeyindeyse çeşitli ortamlarda kullanılabilir mi diye düşünmüştüm ama iç ağa tamamen izole edilmiş durumlarda zor olacakmış, hüzünlü.
"X gelecektir" cümlesini, aslında "X'in gelecek olmasını isterdim" diye süzgeçten geçirerek okuma bilgeliğine ihtiyaç var gibi geliyor bana.
Gerçekten birçok açıdan katılıyorum haha Aşırı bunaltıcı olduğu için artık salıp sadece aldığım para kadar çalışayım moduna geçince, ironik şekilde işlerin daha pürüzsüz ilerlemesinden memnun oluyorlar. Aslında riskli bir geliştirme yönü görsem bile artık umurumda değil durumuna gelmiş oluyorum.
JavaScript의 간략한 역사
Bunu bu yazıyla birlikte okumak iyi olur.
> Ancak yetki modeli uygulanmadığı için token izinleri kontrol edilemiyor (yanılıyorsam lütfen söyleyin)
Şu anda destekleniyor.
https://code.visualstudio.com/updates/v1_107/…
1. "Hız duygusu enerji verir" (olumlu bakanlar)
2. "Vibe coding'in tanımı tartışması" (terim karmaşası)
3. "Doğrulama olmadan hız, teknik borçtur" (temkinli bakanlar)
4. "Bağlam değiştirmenin yorgunluğu" (katılanlar)
5. "Kodlamanın keyfinin kaybı" (dopamin eksikliği)
6. "Acemi için zehir, uzman için ilaç" (yetkinliğe göre fark)
7. "Yönetici rolüne zorunlu geçiş" (rol değişimi)
8. "İş mantığını anlamama" (sınırların işareti)
9. "Dinlenmenin ve boşluğun yok oluşu" (makine zamanı)
10. "Aracın geçiş dönemi sorunu" (gelecek öngörüsü)
1. Biçime yönelik beğeni ve itirazlar ("LinkedIn tarzı mı?")
2. 'Kalın arzu'yu hayata geçirme tanıklıkları
3. Felsefi ve dini köken analizi
4. İkili karşıtlığa dayalı mantığın sınırları
5. Yapısal ve çevresel nedenlere işaret
System) olduğu söyleniyor.Beyaz olan kod, siyah olan terminal gibi bir teknoloji okuryazarlığı eksikliği durumu değil mi? Loglara bakmayı bilmeme ya da kopyala-yapıştır olmadan hiç geliştirme yapamama haliyle de aşağı yukarı aynı.
Bu yazının yanı sıra Part 1'de kıdemli mühendislerin neden ayrıldığı incelenmiş; ayrıca Part 2 olan The Economic Intervention That Stops Engineer Attrition yazısı da var.
https://codegood.co/writing/…
Dün de Mac'te genel depolama alanı açmanın (Claude'a kendi haline bırakıp sildirmek) çok kullanışlı olduğuna dair bir Facebook paylaşımı görmüştüm ama...
Bir yönetici bu yazıyı görebilse keşke..
Harika görünüyor.
Ben böyle şeylere bakarken doğrudan aracın sistem prompt’unun önemine odaklanıyorum. Şu anda Cursor’da kullanırken kişisel olarak
opus >= gpt 5.2 > gemini 3diye düşünüyorum. Onun dışında Sonnet olsun, 5.1 olsun... ben artık kişisel olarak kullanmıyorum. Ama... gpt5.2’de effort seviyesine göre fark çok büyük. Gerçi yüksek effort her zaman daha iyi olmuyor. Bu yüzden ağırlıklı olarak opus ve gemini kullanıyorum. Bazen zor bir problemle karşılaşırsam üçünü de kod yazdırıp birbirlerinin kodunu değerlendirmelerini sağlıyorum, sonra da ben kontrol edip uyguluyorum.Görünüşe göre
--dangerously-skip-permissionsseçeneğini sandbox ortamı dışında çalıştıran çok fazla insan var. Acaba "danger"ın ne anlama geldiğini bilmiyorlar mı? TTKesinlikle yanlış bir şey yok.
Hmm, tersinden bakınca kendi garip kodunu yazıp sonra da "bunu GPT yaptı" diye GPT'yi kalkan gibi kullanan junior'lar da gördüm; o yüzden kişiden kişiye değişiyor gibi.
Araç kullanan agent’lar gerçekten tehlikeliymiş. Sadece söylediklerini dinleyelim.
Öyleymiş. Windows 11’in yerleşik Not Defteri’ni pek kullanmadığım için bilmiyordum. Teşekkür ederim.
Not Defteri'nde sadece F5'e basmanız yeterli.
Görüşünüz için teşekkürler! README'ye yazmak iyi olabilir gibi görünüyor.
Ayrı olarak, açık kaynak bir Rust paketi düzeyindeyse çeşitli ortamlarda kullanılabilir mi diye düşünmüştüm ama iç ağa tamamen izole edilmiş durumlarda zor olacakmış, hüzünlü.