Ben bir yazılım mühendisi değilim

• Yazılım mühendisi kimliğini reddetmesi, 23 yıl önce aldığı “iyi bir hacker ama mühendis değil” değerlendirmesiyle başlıyor
• Ajan paradigması, deterministik olması gereken programları deterministik olmayan programlarla yazma yöntemi gibi hissettiriyor
• Koda duyulan güven, okunabilirlik, anlaşılabilirlik, verimlilik, akıl yürütülebilirlik ve aynı girdide aynı çıktıyı veren yeniden üretilebilirlikte yatıyor
• İş yerindeki agentic user flows ve AI kullanım KPI’ları, iyi koddan çok metrikleri ve doğal dil girdisini öne çıkaran bir yaklaşım olarak algılanıyor
• AI sektörünün gelecek tasavvuru, yazılım geliştirmeyi ikame etmenin ötesinde düşüncenin etrafına hendek kazma hayali gibi görünüyor

---

Yazılım mühendisliği ve ajan paradigması

• Kendisini yazılım mühendisi kimliğinin dışında konumlandırması, 23 yıl önce bir iş arkadaşından “iyi bir hacker” ama mühendis olmadığı yönünde bir yorum duymasına dayanıyor
• Son dönemdeki “yeni ajan paradigması”, Waylon Smithers gibi bir makineye hata yapmamasını söyleyip, ortaya çıkan sonucu uzman yazılım mühendisliği diye paketlemek gibi görünüyor
• Deterministik olmayan çıktılar üreten programlarla deterministik olması gereken programlar yazma yaklaşımı, yazılım mühendisliğinin geleceği olarak sunuluyor
• Koda dair temel inanç hâlâ okunabilirlik, anlaşılabilirlik, verimlilik, yeterli düzeyde akıl yürütülebilirlik ve aynı girdide aynı çıktıyı veren yeniden üretilebilirlik üzerine kurulu
• Gerçek sistemlerde yeniden üretilebilirlik zaten zor olduğu için, kod yazma pratiğinin kendisi “hareketli kumlar” üzerine kurulmamalı
• Birleşik alt sorgular ve toplama ifadelerinden oluşan görünümlerin sorgu performansı üzerindeki etkisi, Inversion-of-Control, işlevleri metotlardan ayırıp bağımsız test edilebilir hâle getiren tasarım gibi ayrıntılar hâlâ önemli

AI merkezli geliştirme akışına güvensizlik

• İş yerinde talep edilen agentic user flows tam olarak ne anlama geldiği belli olmayan şeyler ve doğal dil giriş kutusunun küçük bir seçenek kümesinden seçim yapmaktan neden daha iyi olduğu da ikna edici değil
• Yazılım geliştirme yaşam döngüsünün tüm aşamalarında ajan kullanma yönünde bir eğilim var ve elle kod yazmanın COBOL kullanmak gibi görüleceği de söyleniyor
• Ajanlar, bağlama göre çıktıyı değerlendiren LLM prompt wrapper’ları gibi görünüyor ve fiilî çıktı çoğu zaman yetersiz hissettiriyor
• AI kullanım miktarı bir KPI olarak izleniyor, ancak son 23 yılda KPI’lardan daha önemli olan şey iyi kod yazmaktı
• Geçmişte yazdığı kod için “matematik mezununun yazdığına benziyor” denmiş ve bunu büyük bir iltifat olarak almış
• Aynı iş yerindeki bir staff software engineer’ın uygulamasında açık arayüzler yoktu, DI container bir public static üye olarak açığa çıkarılmıştı ve CSV yapılandırması, tablo verilerine uygun olduğu için değil “iş kullanıcılarının kullanması kolay” olduğu için seçilmişti
• Bu uygulamanın çok kötü olduğunu söylediği için sorun yaşadı ve bu olay ironik biçimde kendisinin yazılım mühendisi olmadığı sonucuna götürdü
• Zeki bulduğu insanlardan iki kez, AI’ın yazılım yazımının ve sektörün geleceği olduğu için bunu kabul etmesi gerektiği yönünde tavsiye aldı, ancak bu tutum ona özensiz görünüyor
• Denediği AI yazılımı, düşünme sürecine yardımcı olmaktan çok onu engelliyor ya da aktif olarak devralıyor gibi hissettirdi; bu tür bir sahiplenme endişe verici
• Büyük AI şirketlerinin liderleri, yazılım geliştirme sektörünün geleceğinden neşeyle söz ediyor, ürünlerinin istihdam üzerinde devastating effects yaratacağını söylüyor ve “intelligence too cheap to meter” ifadesini kullanıyor
• Bu geleceğin korkunç olmasının nedeni, makinelerin herkesi ataşa dönüştüreceği düşüncesi değil; onların düşüncenin etrafına hendek kazmayı hayal etmeleri

[GN⁺]

Lobste.rs görüşleri

• Mary Walton'ın W. Edwards Deming kitabında buna benzer bir anekdot var. Bir fabrika işçisi, makine arızası yüzünden sadece hatalı ürün çıkmaya başladığını fark edip bildirmiş ama bakım gecikince kendisi düzeltmeye çalışmış; o sırada amiri gelip makineyi olduğu gibi çalıştırmasını söylemiş.
  Sonuçta ona “hatalı ürün üretmesi” söylenmiş oluyordu ve o da “Benim işçi olarak gururum nerede? Keşke amirim bana hiç değilse makineye gösterdiği kadar saygı gösterseydi” demiş. Yani hatalı ürün üretip bunun için para almak istemiyormuş.

  • Bu kitap mı? https://deming.org/the-deming-management-method-by-mary-walton/
    Okumaya değer mi?

• Yazardan çok daha az deneyimim var ama kariyerimin başlarında, CSV'nin çeşitli sorunları yüzünden bazı iş akışlarını CSV dışına taşımaya çalışmıştım; o zaman bana “iş tarafındaki süreçler için CSV daha kolay” denmişti.
  O dönemde ben de yazar gibi bu cevabı oldukça kötü bulmuştum ama zaman geçtikçe bunun doğruya daha yakın bir değerlendirme olduğunu düşünmeye başladım.

• Eğer “23 yıl önce biri bana yazılım mühendisi olmadığımı söyledi” türünden aptalca bir görüş seni hâlâ rahatsız ediyorsa, çözümün başkalarının fikirlerini o kadar önemsememek olduğunu düşünüyorum.
  İşvereninin saçma politikaları ya da çalışma arkadaşlarının özensizliği seni bezdiriyorsa, başka bir şirket bulursun. Dünyada 8 milyar insan var; bunların çoğu bilgisayarların onlar için bir şeyler yapmasını istiyor ve onların da önemli bir kısmı programlama için para ödüyor.
  Bu bana, “İlk kez bir fırında çalışırken iş arkadaşım kruvasanların daha fazla tereyağı satmak için Big Dairy'nin komplosu olduğunu söyledi, ben de bunu dünya görüşümün temeline koyup bir daha asla fırında çalışamayacağıma karar verdim” demek gibi geliyor. Yazarın yaşı yazmıyor olsa liseli sanırdım ama 23 yıl öncesinden söz ettiğine göre o yaşları çoktan geçmiş olmalı.

  • Bu yazının neden flag'lendiğine dair ancak tahmin yürütebilirim ama o tahminimden oldukça eminim. Yine de asıl mesele, üslubunun kaba olması değil, yazının ana argümanını ıskalamış olması.
    Yazının meselesi, yazarın gerçekten yazılım mühendisi olmaması değil; büyük olasılıkla uzun süre bu unvanla çalışmıştır. Mesele daha çok, kendisini bu unvandan dışlama tavrının sektörün dönüşmüş hâline verilmiş bir tepki olması.
    Adeta “Bu mühendislik değil, saçmalık. Eğer yazılım mühendisi olmak bundan ibaretse, ben o değilim” diyor.
    Ben şahsen bu duyguya katılıyorum. Yazılım geliştiriciler olarak yaptığımız işe “mühendislik” demenin, başka mühendislik dallarına hakaret gibi geldiği çok oldu. Özellikle de böyle derken aslında ürettiklerimizle pek ilgilenmememiz yüzünden.
    İnşaat mühendisleri bir köprünün çökmesini gerçekten son derece ciddiye alır; büyük bir çöküş yaşandığında bütün sektör tepki verir, ders çıkarır ve bunun bir daha olmaması için uğraşır. Buna karşılık sözde yazılım “mühendisleri”, tamamen önlenebilir nedenlerle üretim ortamını defalarca çökertip sonra bunu özgeçmişlerinde başarı hikâyesi gibi yazabiliyor.
    Günümüz yazılım mühendisliği anlayışı hakkında — yani gerçekten dağıtıma çıkan koda önem vermeyip onun yazımını başka bir “zekâya” devretme eğilimi hakkında — ne düşündüğümü tahmin edebilirsiniz.
    Bunun neden olduğunu anlıyorum ve ne yapılması gerektiğine dair tüm cevaplara sahipmişim gibi konuşmak istemem. Ama buna ciddi bir iş, yani “mühendislik” süsü vermeyelim.