Programcı Kimliği Krizi
(hojberg.xyz)- Programcı kimliği, son dönemde AI ve LLM araçlarının ortaya çıkışıyla tehdit altında
- Programlama kültürü, 1950’lerde MIT’nin hacker etiğinden doğdu; bizzat kod yazmayı derin bir zanaat olarak görüp, hassas mantığı ve problem çözümüne dalmayı temel değerler saydı
- Ancak bugün AI endüstrisi ve LLM araçları, geliştiricileri basit birer şartname yazarı ya da operatöre dönüştürmeye çalışıyor; doğrudan kod yazmak yerine doğal dille talimat verilen "vibe-coding" yaklaşımını dayatıyor
- LLM tarafından üretilen kod deterministik değil ve hataya açık; geliştiricinin kodu bizzat okuyup yazarken edindiği derin kavrayış ve yoğunlaşmayı ortadan kaldırarak kod tabanıyla olan bağı koparıyor
- Şirketler verimlilik artışını gerekçe göstererek araç kullanımını zorunlu kılıyor; ekip içi işbirliği ve mentorluk kültürünü AI ile etkileşimle değiştirirken geliştiriciler arasındaki insani bağı zayıflatıyor
- Programlamayı sadece çıktı değil, düşünme ve anlama süreci olarak gören özsel değer kayboluyor; geliştiriciler kendi becerilerini, keyiflerini ve mesleki kimliklerini korumak için bu değişime direnmek zorunda
Programcının özü ve geleneği
-
Kod yazmak, basit bir iş değil, geliştiricinin kimliğinin ta kendisidir; editör ise zanaatin işlendiği ve akış durumuna (flow) girilen bir atölye, hatta bir mabettir
- Vim gibi araçlarla düşünce ile kod arasına bariyer koymadan çalışılır, gerçek dünyayı etkileyen maddi olmayan bir dünya yaratılır
- Bulmacayı çözme sürecinin kendisi, ortaya çıkan resimden daha önemlidir; parmaklardan buffer’a uzanan beceri akışında zaman kaybolur
-
1950’lerin sonlarında MIT’de yeni bir programlama kültürü doğdu; deneysel ve düzen karşıtı eğilimleri olan hackerlar, Flexowriter ve TX-0 bilgisayarlarını kullanarak kusursuz programların peşine düştü
- Amaç, "The Right Thing" fikri etrafında zarif ve sade kod yazmaktı
- Tech Model Railroad Club üyeleri makine diline gömülerek dijital büyüyü öğrendi ve keşfettikleri bilgiyi diğer öğrencilerle paylaşan bir kültür kurdu
-
Building 26’daki hesaplama potasında kodlama becerileri dövüldü; yaklaşık 70 yıl önce şekillenen bu kültür, bugün de sürüyor ve geliştiricilerin zihinlerinde ve makinelerde yaşamaya devam ediyor
- Kadim hackerların mirası, derin ve bedensel bir beceri olarak kaldı; bunun üzerine tutkulu bir endüstri kuruldu
- Geliştiriciler hâlâ aynı hayret, başarı hissi ve bulmaca çözümündeki zarafetle motive oluyor
-
Ancak programcı kimliğini oluşturan bu çekirdek değerler tehdit altında; bir zamanlar parlak ve net görünen programlamanın geleceği, şimdi uğursuz bir karanlık, aldatmaca ve belirsizlikle örtülmüş durumda
AI endüstrisinin dayattığı yeni kimlik
-
Milyarlarca dolarlık AI endüstrisi, Hacker News topluluğu ve LinkedIn’deki LLM savunucuları, yazılım geliştirmenin geleceğinin programlamaya pek benzemediğini öne sürüyor; bir yıl önce mem gibi görünen "vibe-coding" artık ana akıma giriyor
- Geliştiriciler artık kod yerine Markdown ile şartname yazmak zorunda; kod tabanının köşelerini keşfetmenin, bulmaca çözüp sırları açığa çıkarmanın getirdiği derin yoğunlaşma ve beceri derinliği kayboluyor
- Onun yerine geliştirici adına ajanlar düşünürken, dağınık dikkat ve context switching kabul edilmek zorunda kalıyor; yaratıcı problem çözme makineye bırakılıyor ve geliştirici basit bir operatöre dönüşüyor
-
Bazı geliştiriciler bu değişimi ve "Specification Engineering" adlı yeni kimliği memnuniyetle karşılıyor; operatör olup Steve Jobs gibi "orkestrayı yönetme" fikrinden heyecan duyuyor
- Kodlamaya ilgileri yokmuş gibi görünürken neden programcı oldukları sorgulanıyor; sanki Woz ile Jobs’u birbirine karıştırmış gibiler
- Prompt, Context, Specification "Engineering" yaklaşımının programcılara parlak ve müreffeh bir kariyer sunacağı pek inandırıcı görünmüyor
-
Bu, becerinin, ustalığın ve emeğin değer kaybetmesi anlamına geliyor; geliştiricinin kendine özgü soyut düşünme yeteneği artık gerek duyulmayan alanlara itiliyor ve zaten ürün yöneticileri ile tasarımcıların kapladığı sahaya taşınıyor
Şirket içi güç dengelerindeki değişim
-
Şirketlerde bu yeni kimlik dayatılırken güç dengeleri değişiyor; yanlış yerde verimlilik artırma saplantısıyla geliştiriciler giderek daha somut biçimlerde LLM kullanmaya zorlanıyor
- Uyum sağlamazsanız kapı dışarı edilirsiniz; ya kendi gereksizliğinizi ilan eden ürünleri kullanırsınız ya da istifa edersiniz
- Geçmişte yönetimin geliştiricinin araçlarını bu kadar ayrıntılı biçimde dikte ettiği neredeyse hiç görülmemişti
-
Geliştiriciler aşçı ya da marangoz gibi kendi araçlarını kürate edip inceltmekle büyük gurur duydu; editör ayarları, dotfile düzenlemeleri ve geliştirme ortamı yapılandırmalarıyla araçlarını kendi düşünme biçimlerine göre kişiselleştirdi
- Araç setini becerinin bir parçası olarak kişiselleştirmeye yıllarını verdi ama günlük işle neredeyse bağı olmayan yöneticilerin buna emir vermesi bir ihlal gibi hissettiriyor
- Şirketlerde onlarca yıl ayrıcalıklı konumda olan programcılar için bu anlatı, yönetimin dengeyi yeniden kendi lehine çevirmesi için yeni bir yol sunuyor
LLM ile programlama dilleri arasındaki özsel fark
-
Bazıları LLM’in etkisini düşük seviyeli dillerden yüksek seviyeli dillere geçişe benzetiyor (Assembly’den Fortran’a), ancak bu birçok açıdan yanlış bir benzetme
- Fortran programlamaya kökten bağlıydı; beceriyi ortadan kaldırmaya çalışmak yerine onun üzerine inşa edildi ve programlamanın hassasiyetini ile ifade gücünü yok etmeden genişletti
- Fortran verilen girdiler için her zaman doğru sonucu başarıyla üretirdi; oysa LLM dünyasında bunların hiçbiri geçerli değil
-
Bilgisayarlar ve programlama son derece sinir bozucu olabilir, ama en azından hassasiyet konusunda her zaman güvenilirdi; programlama yoluyla ne talimat verdiyseniz onu tam olarak yapardı
- Bilgisayarın hassasiyetine duyulan bu bağımlılık ve güven yüzünden, sohbet botları istenen işi yaptığını söyleyerek gaslighting yaptığında buna inanmak kolaylaşıyor
-
LLM’ler ve yaptıkları iş özünde hataya açıktır; hem büyük dil modellerinin doğası hem de doğal dille talimat verme yöntemi yanlış anlamaya açıktır
- Deterministik olmamaktan hoşlanmayan programcıların böyle bir yaklaşımı seçmesi ilginçtir; çünkü onlar öngörülebilirlik, bileşebilirlik, idempotency ve kırılgan olmayan entegrasyon testlerini tercih eder
- LLM kodu ise bunun tam tersi olan tutarsız bir kaosu temsil eder
-
Dijkstra, "On the foolishness of 'natural language programming'" metninde doğal dilin işleri basitleştireceği varsayımının sorgulanması gerektiğini belirtmiş, biçimsel metinlerin avantajının geçerli sayılmak için yalnızca birkaç basit kuralı karşılamasının yeterli olması olduğunu vurgulamıştı
Derin kavrayış ve yoğunlaşmanın kaybı
-
AI destekli geliştirmeyi katılık ve bürokrasiyle vibe-coding’den ayırma çabası var, ancak bu temel özü gözden kaçırıyor
- LLM’in ürettiği kod, insanın kendi yazdığı ya da bir PR’da incelediği kod kadar dikkatle okunmuyor; LLM ile kodlamada gözleri camlaştıran içkin bir şey var
- Üstünkörü bakılıyor, insan bunaltılıyor ve sıkılıyor; CI geçip program derlenince tehlikeli tuzaklar körlemesine kabul ediliyor
- Testlerin gerçekten çalışacak şekilde ayarlanıp ayarlanmadığına, var olmayan kütüphanelerin içe aktarılıp aktarılmadığına ya da bütün bir kütüphanenin sıfırdan yeniden yazılıp yazılmadığına bakılmıyor
-
Bir kitabın incelemesi ya da özeti, onu doğrudan okuma deneyiminin yerini tutamaz; yüzlerce sayfa boyunca her cümleyi dikkatle sindirip fikirler üzerinde düşünmek gerekir
- Aynı şekilde AI’ın tamamladığı işin özetini hızlıca geçmek, alan, problem ve olası çözümler hakkında derin bir anlayış kurmayı elinizden alır ve kod tabanıyla bağınızı keser
- Cehaletin uçurumuna atlayıp konuyu ve sonuçlarını ortaya çıkarmak, öğrenmek ve anlamak hem tatmin edicidir hem de iyi yazılım için zorunludur
- Sahiplik, özne olma hali ve derin, tatmin edici çalışma; ajan sekmeleri arasında parçalanmış dikkatle yer değiştirir
-
Joan Didion, "Ne düşündüğümü, ne gördüğümü, neye bakıp onun ne anlama geldiğini anlamak için yazarım" demişti; Peter Naur da "Programming as Theory Building" yazısında aynı fikri ele alır
- Naur’un "Theory" kavramı, kod tabanına dair anlayışı somutlaştırır; nasıl çalıştığını, biçimselliğini ve gerçek dünyanın temsilini içerir
- Bu bağlam ve içgörü yalnızca yoğunlaşma yoluyla elde edilebilir; Naur, "Theory"yi yazılımdan da öte, programlamanın asıl çıktısı ve gerçek ürünü olarak tanımlar
- Ancak iyi gelişmiş bir "Theory" ile kod tabanına genişletmeler ve hata düzeltmeleri etkili biçimde uygulanabilir
-
İyi tasarım yoğunlaşmadan doğar; metin buffer’ında ileri geri gidilen çalışmalardan ve çoğu zaman klavyeden uzakta geçen düşünme anlarından çıkar
- Tüm kod tabanını zihinde tutmak mümkün olmadığından, modüllere, sınıflara ve fonksiyonlara dalarak bulanık zihinsel modeli netleştirmek gerekir
- Kodu okuyup yazarak bilişi genişletmek, aşinalığı ve problem alanına dair anlayışı yeniden kazanmak gerekir
-
Bağlamın bir kısmı kurulur ve sayısız yetersiz denemeden sonra nihayet çözüme ulaşılabilir; kötü tasarımın uyumsuzluğunu hissetmek gerekir
- İğrenç ve tekrarlı kod yazarken ancak daha iyi, daha özlü, daha zarif, daha bileşebilir ve yeniden kullanılabilir bir yolun var olduğu fark edilir
- Bu, insanı durup problem üzerine derin düşünmeye, bir adım geri çekilip baştan başlamaya iter
- Buna karşılık AI ajanlarıyla çalışma sürtünmesizdir; bu yüzden alternatif çözümlerden kaçınılır ve kabul edilen şeyin mükemmel mi, sıradan mı, korkunç mu, hatta zararlı mı olduğu bilinmez
Ekip işbirliği ve insani bağın çöküşü
-
LLM merkezli kodlamanın bilişsel borcu, beceri erozyonunun ötesine uzanır; dikkat süresi kısalmış "slop-jockey"ler işlerini pull request’lere ve tasarım dokümanlarına boca ederek işbirliğini bozar ve ekipleri aksatır
- Kod incelemesi yapan ekip arkadaşları, artık son kalite kontrol katmanı değil ilk katman olduklarını fark etmenin sarsıntısını yaşıyor
- Yeni eklenmiş ama hiç çağrılmayan fonksiyonları, halüsinasyon ürünü kütüphane eklemelerini, bariz runtime ya da derleme hatalarını işaret etmek zorunda kalıyorlar
- Kendi kodunu açıkça yalnızca yüzeysel biçimde gözden geçirmiş olan yazar ise sorumluluk almıyor ve "Claude böyle yazdı. Aptal AI işte, haha" diyor
-
Müdahaleci yöneticiler ve tasarruf peşindeki üst düzey yöneticiler, ekiplerde insan etkileşimini azaltma yönünde baskı yapıyor; muhtemelen bunu bilinçsizce yapıyorlar
- İzole ve bağlarından koparılmış halde, artık çalışma deneyiminin etrafına duvarlar örmeye yetkilendiriliyor ve teşvik ediliyorsunuz
- Bir pair programmer’a ihtiyaç duyduğunuzda, çözüm fikirlerini karşılıklı tartışmanız, prototip üretmeniz, mimari çizmeniz ya da kod tabanının anlaşılması güç bölümleri hakkında bir uzmana danışmanız gerektiğinde, insan yerine LLM’e yaslanıyorsunuz
- Artık bir onboarding buddy’ye, mentora ya da takım arkadaşına gerek yok; onun yerine makineyle konuşabilirsiniz
- LLM ile insan temasından kaçınmak o kadar kolaylaşıyor ki bu durum yeni standarda dönüşebilir
Programcı kimliğinin savunulması
-
AI abartısı anlatısına ne kadar kolay uyum sağladığımız, becerinin planlı biçimde silinmesine aktif olarak katıldığımız ve düşünme araçlarımızdan ne kadar gönüllü vazgeçtiğimiz sarsıcı
- Hobisini mesleğe dönüştürebilmiş şanslı insanlardık; şimdi ise slop’la başa çıkmak için ne kadar katı ve titiz süreçler kurarsak kuralım, işin eğlenceli kısmını dış kaynakla devredip yerine buyurgan bir angarya koymuş oluyoruz
-
LLM’ler, yazılımın karmaşıklığına karşı yörüngeden atılan bir nükleer bomba çözümü gibi görünüyor; gerçek sorunu çözmek yerine semptomları tedavi etmek için çok daha karmaşık ve daha bulanık bir şeye başvuruyor
sedyerine Claude kullanmak ya da saatlerce doküman taradıktan sonra bile netleşmeyen bir kütüphane veya framework hakkında cevap istemek sorun olmayabilir- Ama sadece bir operatör ya da kod inceleyicisi olup eğlenceli ve ilginç işlerde arka koltuğa geçmek istenmiyor
-
Tekrarlı işlerde yardımcı olan, kod tabanını anlamaya ve doğru programı yazmaya destek veren araçlar tercih ediliyor; benim yerime düşünmek üzere tasarlanmış ürünler ise rahatsız edici geliyor
- Ürettiğim yazılıma dair kendi anlayışım üzerindeki özneyi ortadan kaldıran ve ekip arkadaşlarımla bağımı koparan ürünler reddediliyor
- LLM’ler tüm abartıyı hak etse bile, yine de bütün bunları ve beceriyi kaybedeceğiz
- İnsanlar, makinelerden ve onları destekleyen şirketlerden daha önemlidir; biz geri kalanlar onların sattığı yeni Amerikan rüyasının peşine düşerken kazanan onlar oluyor
- Karşılığında ise eleştirel düşünme becerimizi, keyfimizi, ustalığımızı, mahremiyetimizi ve belki de gezegeni veriyoruz
3 yorum
Genel olarak katılıyorum
Özellikle context switching? Prompt isteyip bekleme süresinde odak dağılıyor ve üretkenliğin düşmesine neden oluyor. LLM hızı artıp anında yanıt gelirse bu belki çözülebilir
Yazının kendisi, sonucu en baştan belirleyip ona göre kaleme alınmış gibi güçlü bir izlenim veriyor. Geliştiriciden sahiplik duygusunun kaldırılması meselesi, LLM’den bağımsız olarak "zanaatkârlık çağı vs sanayileşme çağı" üzerine bir tartışma gibi okunuyor.
Hacker News görüşü
Beni en çok etkileyen şey, kod inceleyicilerinin artık kalite kontrolün son aşaması değil, ilk savunma hattı haline geldiklerini fark ettikçe giderek mental olarak yıpranmaları. İnceleme isteği geliyor ama artık yeni eklenmiş ve hiç çağrılmayan fonksiyonları, bir anda eklenmiş kütüphaneleri, bariz runtime ya da derleme hatalarını tek tek yakalamak zorundalar. Kodu yazan kişi sorumluluktan kaçıp “Claude yazdı da ondan, AI hata yapmış haha” diye geçiştiriyor. LLM’lerin devreye girmesinden sonra Brandolini yasası’nın (saçmalığı çürütmek için gereken enerjinin onu üretmekten çok daha fazla olması) daha da gerçek hissedildiği bir dönemdeyiz. Deneyimi az ya da teknik olarak yetersiz geliştiriciler birkaç dakikada binlerce satır kod dökünce, sistemin sağlığını gerçekten garanti etme sorumluluğu artık kod inceleyicilere yıkılıyor. PR’lerdeki eklenen/çıkarılan LoC farkına bakınca, LLM’in yazdığı PR’ler neredeyse sürekli sadece ekleme yapıyor; deneyimli kıdemli mühendisler ise yeni kod ekledikleri kadar mevcut kodu da silme eğiliminde oluyor
Bence bu teknik bir problem değil, insan problemi. Böyle bir şey bir kez olursa çok sert uyarılmalı, ikinci kez tekrar ederse yöneticiye gönderilip reddedilmeli. PR’ı kim yazmış olursa olsun sonuçta ortaya çıkan işin altında kendi adı var; kod berbatsa sorumluluğu da kendisine ait olmalı
Artık büyük ekiplerde kod incelemesi yapmıyorum ama böyle bir durumda olsaydım, bu tür sorumluluktan kaçmayı bir kez tolere edebilirdim; tekrar ederse o kişiyi ekipten çıkarmaya çalışırdım. Bu da mümkün değilse ben ayrılırdım. O kadar korkunç bir ortam
Son zamanlarda üretkenliğimin düştüğünü hissetmemin bununla ilgili olduğunu düşünüyorum. Bir yandan daha fazla kodu daha hızlı üretme baskısı var, öte yandan agent benzeri şeyler kullanınca yazdığım kodun tüm bağlamını tam olarak kavrayamıyorum. Kaliteyi ancak satır satır dikkatle inceleyebildiğim bir kapsam içinde garanti edebiliyorum; sınır da burada. O yüzden son dönemde AI’yı daha yavaş ve daha temkinli kullanıyor, doğrudan elimle yazdığım kısmı artırıyorum. Net type tanımlarını ya da bir spec’i birçok özelliğe tekrar tekrar uygulamak gerektiğinde AI biraz yardımcı oluyor ama o durumda bile sonucun her zaman güvenilir olduğu söylenemez
Kariyeri daha uzun kıdemli mühendisler, ekledikleri kadar mevcut kodu da budama eğiliminde olur. Negative 2,000 Lines Of Code yazısına da bakmaya değer
LLM devreye girdiği anda sorumluluğu kime yüklediğimize dair bakış açımızın daha geniş bir toplumsal problem olduğunu düşünüyorum. İnsanlar sonuç iyi olunca bunu kendi başarıları sayıyor, kötü olunca da kolayca AI’yı suçluyor. Uygun birkaç dava örneği çıktı mı bu kültürün ciddi biçimde değişeceğini düşünüyorum
Uzun zamandır sektöre giren insanların kodu bir zanaat olarak değil, kolay para kazanma aracı olarak gördüğünü hissediyorum. Açık kaynak altyapı geliştiricilerinin geçinmekte zorlandığını anlatan yazıları gördüğümden beri, kafede kod yazan geliştiricilerden bootcamp’lere, “sadece kod öğren yeter” hareketine, Leetcode grinder’larına, San Francisco’da kira pahalı diye arabasında yaşayan geliştiricilere kadar hep aynı çizgi var; şimdi de AI ile kendini otomatikleştirip işini kaybetme meselesi gündemde. Sorun, geliştiricilerin gerçek profesyoneller olarak görülmemesi. Standartlar gevşek, etik kurallar yok, tutarlı bir beceri seti yok, temsil de yok. Hatta sektördekiler kendi çıkarlarını savunmakta bile aciz. Avukatların barosu, doktorların tabip odaları var; geliştiricilerin ise sadece ontolojik kaygısı var. Artık patronlar “AI ile seni otomatikleştirip işini ortadan kaldırırım” diye gözdağı verebiliyor. Diğer meslekler kendi çıkarlarına bu kadar düşman değil; neden özellikle bu sektörde böyle olduğunu ben de sorguluyorum
“Coder” ile yazılım mühendisi aynı şey değil bence. Sırf bir bootcamp bitirip Python’la basit programlar yazabiliyor diye birine yazılım mühendisi denemez. Ben diplomam olduğunu söyleyince bunun elitizm olduğu, bilgisayar mühendisliğinde öğrenilen şeylerin iş hayatında işe yaramadığı bile söyleniyor. Ama diploması olmadan da kendi kendini yetiştirip müthiş mühendis olan örnekler elbette var. Yine de bir şekilde standart olması gerektiğine katılıyorum. En yeni buzzword’lü unicorn startup’a katılan bootcamp mezununu sadece tebrik edebilirsin ama Therac-25 gibi hassas sistemleri mutlaka resmi eğitim almış insanların yapmasının daha doğru olduğunu düşünüyorum
Patronun “otomatikleştirmezsen işin gider” demesi mi? Bu zaten bizim işimiz. Emeği otomatikleştirmek yaptığımız işin özünde var ve kendi işyerini otomatikleştirme fırsatıyla bunu anlayabilme kapasitesi en yüksek meslek grubu da biziz
Öğretmenliğin de geliştiriciliğe benzeyen yanları var bence. Harika öğretmenler var, berbat öğretmenler var, arada kalan çok kişi de var. Bir konuyu çok iyi bilmek, onu çok iyi öğretebileceğin anlamına gelmiyor. Belki de geliştiriciler makinelere ders veren öğretmenlerdir. Kimi zaman bir karakter, bir düşünce öğreterek; kimi zaman da genel bir üslupla
LLM’i bir kenara bırakırsak, bazen yazdığım ve kendimle gurur duyduğum, gerçekten çok iyi tamamlanmış kodlar oluyor. Yapısından her satırına kadar sebepsiz hiçbir karar yok; o kodda ben uzmanım ve ona tamamen hâkimim. Ama kodların çoğunu öyle kusursuz yazmıyorum. Çoğu zaman “iş bitsin yeter” diyerek kendime biraz daha düşük standartlar tanıyorum. Yine de arada bir gerçekten odaklanıp iyi bitirdiğim kodlar çok tatmin edici oluyor; hayatımdaki en iyi kod deneyimleri bunlar. LLM’i de düşününce, bir yandan yüksek kaliteyle kod yazmak kolaylaşmış gibi, bir yandan da zorlaşmış gibi. Psikolojik olarak derin odak halindeyken LLM’i iyi kullanıp daha hızlı ve daha yüksek standartta sonuç üretebiliyorsun. LLM’in yazdığı koddan çok daha iyisini yazabilirim ama LLM’in yardımıyla daha da iyi kod da yazabilirim. Sorun şu ki bu odak halini korumak gittikçe zorlaşıyor. LLM’in ürettiği kodu üstünkörü gözden geçirip, görünüşü de güzel, çalışıyor da diye kolayca geçiriyorsun. Ama böyle geçilen kodlar azar azar bozuluyor ve bu körelmiş halle geçirmeye devam ettiğinde iş işten geçmiş oluyor. Sonuçta kişi kendi kodunun uzmanı olamıyor ve elde sadece gevşek kod yığınları kalıyor
Bu denemeyi okurken gerçekten “tam benim düşündüğüm şey” hissi yaşadım. İş yerinde AI kullanmayı denedim ama çoğu durumda çıkan sonuç o kadar zayıftı ki sonunda neredeyse her şeyi ben baştan yazdım. Gereksiz düşünme süresini ya da problem çözmeyi AI’ya devretmenin kariyerim için yapılabilecek en kötü şey olduğuna iyice ikna oldum. AI sadece orta kalite bir metin üreticisinden ibaret
“Bu insanlar neden programcı olmaya karar verdi, kodun kendisine hiç ilgi duymuyor gibiler” sorusuna karşılık ben “amaç problem çözmek” noktasını vurguluyorum. Kod yazmak araçtır, amaç değil. “Editör ayarlarıyla, dotfile’larla, geliştirme ortamıyla oynamak” eğlenceli olabilir ama ben bunu gereksiz karmaşıklık olarak görüyorum ve seve seve devrederim
Editörü, dotfile’ları ve geliştirme ortamını bizzat kurmak sonuçta kendi çalışma ortamına aşinalık kazandırır, araç becerini geliştirir ve daha verimli bir düzen oluşturur. Build script’ine dokunmak gerektiğinde “çağrılan kişi” olmanın sebebi de bu tür hakimiyettir. On, yirmi yıldır Git kullandığı halde merge conflict’i ya da temel kullanımı bilmeyen o kadar çok insan var ki, sonunda can sıkıcı bütün işler gerçekten aracı öğrenmiş insanların üstüne kalıyor
“Bunun değeri yok” türü iddialar mantıksal olarak sonuna kadar götürülürse “var olmanın ne değeri var ki?” noktasına kadar gider
Dünyadaki neredeyse her işin amacı problem çözmektir ama madem öyle, onca meslek arasından neden özellikle yazılımı seçtin diye merak ediyorum
“Amaç problem çözmektir, kodlama sadece araçtır” görüşüne %100 katılıyorum. AI kodlamayı benim yerime yapacaksa buna üzülenler daha çok “kod sanatçısı” tipler; ne üretildiğinden çok üretimin biçimine bağlanıyorlar. Ben probleme odaklanan biriyim, o yüzden AI’nın kodlamayı üstlenmesine hiç üzülmüyorum
“Kodlama amaç değil araçtır” iddiası da, “editörle uğraşmak eğlenceli olabilir ama değersizdir” iddiası da son derece öznel. Problem çözme ortadan kalksa bile sırf kod yazmayı sevecek insanlar var; hatta dünyada çözülecek hiç problem kalmasa bile sadece kodlamaktan keyif alacak çok kişi olurdu
Bu yazıyı gerçekten ilginç buldum. LLM ile programlama konusunda hissettiklerimle neredeyse birebir örtüşüyor. Ben sadece kod yazmayı sevdiğim için bu işi yapan biriydim ve bunu meslek olarak da severek sürdürdüm. Ama artık işte, eskiden sevdiğim bu hobimi yaşatamıyor olmak üzücü. Yaptığım şey tamamen başka bir işe dönüştü
Ben biraz yaşlıyım. 1995 civarında bugünle tamamen farklı bir ortamda programlama yapıyordum. O zaman mühendis hedef müşteriyi, teknoloji yığınını, sektör gidişatını biliyordu ve gerçekten kontrol sahibiydi. Kendi kodu kendi oyun alanıydı; istediği gibi baştan kurar, girinti ya da parantez stilini bile kendisi seçerdi (bozulursa da kendi düzeltirdi). Unit test diye bir şey yoktu (olsa olsa parametre kontrolü), resmi kod incelemeleri neredeyse yoktu; daha çok ofiste sohbet ederek, whiteboard başında tartışarak ilerlerdik. Hata varsa hemen düzeltirdin. Sonunda yönetim kazandı ve artık o “kovboy kodlama” dönemi geri gelmeyecek gibi görünüyor. 90’lardaki Apple’ı özlemek mümkün ama oraya geri dönemeyiz. Yine de çok eğlenceliydi
Ben de benzer dönemde başladım ama biz ISO 9001 nedeniyle düzenli kod incelemesi yapardık. Çıktıları yazıcıdan alır, üç kişi aynı odada toplanıp tüm satırları tek tek kontrol eder ve imzalardı. Bunu endüstriyel kontrol RTOS’unda yapıyorduk. Proje yönetimi ise 40 feet’lik bir Gantt chart’ı yazdırıp duvara asmak şeklindeydi. Tam anlamıyla waterfall dönemi
Ben 2000’lerin sonlarında başladım ve o zaman kariyer yolları ile uzmanlık alanlarının sınırları çok daha netti. Sistem yöneticileriyle geliştiriciler belirgin biçimde ayrılmıştı ama şimdi benden sistem operasyonu rolünü de üstlenmem bekleniyor; dolayısıyla işin kapsamı daha da büyüdü. Sistem tarafındaki becerileri sadece hobi olarak geliştirmiştim ve gerçek işte o alanı üstlenince vendor dokümantasyonu ile eğitimlerin ne kadar kötü olduğunu görüp iyice uzaklaşmak istedim
Sektörün tamamı yeniden kovboy kodlamaya dönmez ama bazı ortamlarda bu tarzın hâlâ yaşayabileceğini düşünüyorum. Örneğin WhatsApp’ta 2011–2019 arasında oldukça serbest bir ortam vardı. Her ortam farklıdır; hatayı önceden yakalamanın maliyetiyle production’dan sonra düzeltmenin maliyetine göre uygun yaklaşım değişir. Ben kişisel olarak hata düzeltme maliyetini düşük tutan yaklaşımı seviyorum. Tabii bu, utanılacak hatalar yapmamaya çalışmamak ya da gerekli testleri yapmamak anlamına gelmiyor
Artık iş dünyası kafası, vibe coder’lar ve script kiddie’ler o kadar çoğaldı ki her şey berbat hale geldi gibi geliyor
Kovboy kodlamanın sorunu, güvenilmez tek bir kişinin bütün takımı mahvedebilmesi. Organizasyon büyüdükçe zayıf halkalar da kaçınılmaz olarak artıyor ve sorunların patlamasını önlemek için giderek daha büyük süreçler gerekiyor. Güvene dayalı küçük elit ekiplerde kovboy kodlama en verimli yöntem olabilir ama adayların becerisini işe alımda doğru değerlendirmek çok zor olduğundan büyük organizasyonlara hiç uygun değil. Muhtemelen bundan sonra da sadece küçük şirketlerde ya da büyük şirketlerin küçük ekiplerinde yaşamayı sürdürebilir
Yazarın “<i>LLM’ler, yazılım karmaşıklığını hedef alan son çare nükleer silah çözümü gibi. Gerçek sorunu çözmek yerine semptomları hafifletmek için daha da büyük bir karmaşıklık getiriyorlar</i>” sözüne katılmakta zorlanıyorum. AI kullanımının asıl amacı, “yaratıcı ve pahalı yüksek becerili yeteneği” AI tasarlayan çok az sayıdaki şirkette merkezileştirmek ve diğer tüm şirketlerde yaratıcı çalışanları işten çıkarıp geriye yalnızca basit iş gücü bırakmak. Yani amaç, bütün işletmelerdeki karmaşıklığı AI ile sadeleştirmek. “Oz Büyücüsü” örneğinde olduğu gibi kimse perdenin arkasına bakmak istemiyor; herkes sadece işinin kolaylaşmasını istiyor. Uzun vadeli riskleri görmezden gelip kısa vadeli kazancı toplamanın sonucu bu
Bu yazıyı gerçekten çok sevdim. Problemi çözmenin koddan daha önemli olduğu yönündeki bazı görüşlere de katılıyorum. Ama bana göre, derin düşünce gerektiren sorunları bile AI’ya bırakmaya başlarsak, zamanla bu derin problem çözme becerisinin kendisi körelebilir. Sadece “bana bir şey yap” diye komut vermek gerçek problem çözme değil