Yapay zeka yazılım mühendisliğini basitleştirmedi: Sadece kötü mühendisliği daha kolay hale getirdi

• LLM'ler kod yazma hızını artırdı, ancak yazılım mühendisliğinin özsel karmaşıklığını azaltmadı
• Kod üretimi kolaylaştıkça, uzmanlığa artık ihtiyaç kalmadığı yanılgısı yayılıyor ve bazı kuruluşlar bunu gerekçe göstererek mühendis sayısını azaltıyor
• Gerçek zorluk kod yazmak değil; sistem tasarımı, spesifikasyon, doğrulama ve tutarlılığı koruma ve yapay zeka bu alanlardaki yükü aksine hızlandırıyor
• Spesifikasyon (specification), test ve uygulama arasındaki uyumsuzluk (spec drift) hızla derinleşerek sistem güvenilirliğinin çökme riskini büyütüyor
• 40 yılı aşkın kariyerde defalarca görülen bir örüntü olarak, 1990'lardaki Visual Basic döneminde de aynı "uzmanlığa gerek yok" iddiası ortaya çıkmış, ancak sonunda mühendislik disiplinine duyulan ihtiyaç yeniden doğrulanmıştı
• LLM'ler tasarım keşfi ve ilk uygulamayı hızlandırmada güçlü araçlar, ancak mühendislik disiplininin yerine geçmek için değil, onu güçlendirmek için kullanılmalı

---

Sektörün tehlikeli yanılgısı

• LLM'ler kod üretebilir hale gelince, yazılım sektöründe artık yazılım mühendisliğinin kendisine gerek kalmadığı sonucuna varan bir hava oluştu
• Mimari, spesifikasyon ve dikkatli doğrulama gibi disiplinler sanki geçmiş çağlardan kalma kalıntılarmış gibi ele alınıyor
• Bazı kuruluşlarda bu fikir şimdiden politikalara yansımış durumda; yapay zekadaki ilerlemeler gerekçe gösterilerek mühendisler büyük ölçekli biçimde işten çıkarılıyor
• Yapay zeka, yanlış iş kararlarını ya da piyasa baskılarını meşrulaştırmak için kullanılan en yeni bahaneden ibaret
• Yapay zekaya prompt girmek, yazılım mühendisliğini tanımlayan disiplinlerin yerini alıyormuş gibi giderek daha fazla pazarlanıyor

Tekrarlanan tarihsel örüntü

• 40 yılı aşkın kariyerde aynı örüntü tekrar tekrar gözlemlendi: yeni araç ortaya çıkar → zor sorunların çözüldüğü ilan edilir → üretkenlik patlaması ve etkileyici demolar görülür → kadrolar küçültülür → sistem karmaşıklığı artar → sonuçlar sonunda beklentilerin tersine çıkar
• Araçlar ve iddialar değişiyor, ama örüntünün kendisi neredeyse hiç değişmiyor

Uçak bakımı benzetmesi

• Uçak bakımında araçların gelişmesi, bilgisayarlı teşhis, dijital kılavuzlar ve yapay zeka destekli telemetri yorumlama gibi büyük ilerlemeler yaşandı, ama yetkin teknisyenlere duyulan ihtiyaç sürüyor
• Ticari uçaklar, milyonlarca parçadan ve binlerce birbirine bağlı alt sistemden oluşan son derece karmaşık sistemlerdir
• Sorun teşhisi, doğru aracı kullanmak ya da bir kontrol listesini izlemekten ibaret değildir; sistemin gerçek çalışma koşullarında nasıl davrandığına dair deneyim ve muhakeme gerektirir
• Hiçbir havayolu, araçlar gelişti diye eğitimli teknisyenleri kaldırıp onarımı kapı görevlilerine bırakmayı önermez
• Buna rağmen yazılım sektörü, neredeyse bununla aynı argümanı kendi alanı için öne sürüyor

Kendin yap vs profesyonel sistemler

• Hobi projeleri, kişisel küçük uygulamalar ve yeni fikir denemeleri başlı başına sorun değildir; bilişim tarihindeki en heyecan verici fikirlerin bazıları bu tür deneylerden doğdu
• Ancak profesyonel yazılım geliştirme tamamen farklı bir kategoridir: ödeme işleme, hassas veri saklama, altyapı yönetimi ve insanların her gün güvendiği sistemleri işletme
• Müşteriler, sistemlerin doğru çalışmasını, evrilirken de doğruluğunu korumasını ve bunları inşa eden kişilerin sistemin nasıl çalıştığını anladığını doğal olarak bekler
• Bu beklenti, profesyonel mühendisliğin temel koşuludur; disiplin ve uzmanlığın kaçınılmaz hale geldiği nokta da burasıdır

Kod hiçbir zaman zor kısım değildi

• Yazılım geliştirmede kod yazmanın en zor kısım olduğu düşüncesi eski bir yanlış anlamadır
• Sözdizimini (syntax) yazmak, sistem kurmanın her zaman en az ilgi çekici kısmıydı; asıl zor iş, sistem davranışını belirlemek, bileşenlerin etkileşimini tasarlamak ve karmaşıklık arttıkça anlaşılabilirliği korumaktır
• Bu, kodlama değil mühendislik problemidir
• Kod üretme çabasının azalması bu sorunları ortadan kaldırmaz; yalnızca daha büyük ve daha karmaşık sistemleri daha hızlı inşa etmeyi mümkün kılar
• Bunun üretkenlik artışı olduğu düşüncesi bir yanılsamadır: yük yalnızca başka bir yere taşınmıştır
  • Kod incelemesi ve üretilen kodla başa çıkmak için gereken bilişsel yük, kod yazmaktan daha büyük bir üretkenlik kaybı etkenidir
  • Alttaki davranış yeterince anlaşılmadan sadece hızın artması, karmaşıklığın taşınamaz hale geldiği anı yalnızca öne çeker; sonuç da yine yanlıştır

Daha önce görülen örüntü: Visual Basic dönemi

• 1990'larda Visual Basic için de benzer vaatler vardı: programlamanın demokratikleştiği ve uzman bilginin artık gereksiz olduğu iddia ediliyordu
• Gerçekte Visual Basic, onsuz muhtemelen hiç yapılmayacak birçok uygulamayı mümkün kıldı
• Ancak sistemler büyüyüp birbirine bağlandıkça, yazılım çıktısı üretmekle güvenilir sistem mühendisliği yapmanın aynı şey olmadığı yeniden keşfedildi
• Bugün yaşanan, aynı örüntünün daha da büyütülmüş bir versiyonu: düşürülen eşik uygulama geliştirme değil, doğrudan kod üretimi eşiği
• Buradan da uzmanlığa artık ihtiyaç kalmadığına dair cazip inanç doğuyor

Hizalanma (Alignment) sorunu

• Güvenilir yazılım, mühendislik dışında neredeyse hiç konuşulmayan bir şeye, hizalanmaya (alignment) dayanır
• Sistemler, davranışa dair bir fikirle başlar → bu fikir spesifikasyon olarak belgelenir → mühendisler bu spesifikasyonu testlere ve üretim koduna dönüştürür
• Bir sistemin uzun vadeli güvenilirliği için spesifikasyon, test ve uygulamanın üçünün de sürekli hizalı kalması gerekir
• Bu üçü birbirinden sapmaya başladığında, sistem yavaş yavaş bütünlüğünü kaybeder
  • Spesifikasyon artık uygulanmayan davranışları tarif eder
  • Testler davranışın yalnızca bir bölümünü doğrular, geri kalanı boşta kalır
  • Sonradan ekibe katılan mühendisler, özgün tasarımı yansıtıyor da olabilir yansıtmıyor da olabilir olan kodu okuyarak sistem davranışını tahmin etmeye başlar
• Zamanla bu tahminler birikir ve sonunda ortaya kimsenin gerçekten anlamadığı bir sistem çıkar
• Bu olguya "spec drift" deniyor: sistemin açıklaması ile sistemin kendisi giderek birbirinden uzaklaşıyor
  • Kod değişmiştir ama spesifikasyon aynı kalmıştır
  • Spesifikasyon evrilmiştir ama testler sabit kalmıştır
  • Davranış yavaş yavaş değişmiş, başlangıçtaki niyetin ne olduğundan artık kimse emin olamamaktadır
• Hizalanma bozulduğunda güvenilirlik uzun süre ayakta kalamaz

Yapay zeka drift'i hızlandırıyor

• LLM'ler kod üretimini dramatik biçimde hızlandırır; bu hem en büyük güçleri hem de riskin ortaya çıktığı noktadır
• Kod, etrafındaki mühendislik disiplinden daha hızlı üretildiğinde, spec drift yaratan kuvvet de hızlanır
• Bir zamanlar dikkatli düşünce ve elle uygulama gerektiren değişiklikler artık saniyeler içinde yapılabiliyor
• Sistemin bütün bölümleri, davranışın hâlâ spesifikasyona uyup uymadığı kimse tarafından doğrulanmadan önce yeniden yazılabiliyor
• Kod genel olarak makul görünebilir, derlenebilir, okunaklı olabilir ve mevcut testleri bile geçebilir; ama sistemi yöneten hizalanma çoktan kaybolmuş olabilir
• Üretkenlik gibi görünen şey, gerçekte eskisine göre çok daha hızlı biçimde yanlış hizalanma (misalignment) yönüne gidebilme kapasitesidir

Yapay zekanın gerçekten yardımcı olduğu alanlar

• LLM'ler bir hata değil; düşünerek kullanıldıklarında mühendislerin sistemleri keşfetme ve tasarlama biçimini ciddi ölçüde iyileştirebilirler
• Özellikle güçlü oldukları alanlar: sorunlar üzerine akıl yürütme, tasarım alternatiflerini keşfetme, karmaşık sistemleri özetleme ve uygulamanın ilk aşamalarını hızlandıran taslaklar üretme
• Zorlandıkları alanlar ise zaman içinde sıkı disiplin ve tutarlılık gerektiren işlerdir
• Spesifikasyon, test ve uygulama arasındaki hizalamayı korumak hâlâ mühendislik sorumluluğudur; hiçbir araç bu sorumluluğun yerini alamaz, yalnızca destek olabilir
• Asıl fırsat, LLM'leri mühendislik sürecinin sessizce yerine geçen bir unsur olarak değil, onu güçlendiren bir araç olarak kullanmaktır

Konuşmalı yazılım mühendisliği

• LLM'lerin açtığı ilginç imkânlardan biri, yazılım mühendisliğinin bazı bölümlerinin daha konuşmalı (conversational) hale gelebilmesidir
• On yıllardır sistem tasarım araçları katıydı: spesifikasyonlar belgelere, mimari diyagramlara sıkışıyor; bunlara giden muhakeme ise toplantılarda ve koridor sohbetlerinde kayboluyordu
• LLM'lerle mühendisler fikirleri etkileşimli biçimde keşfedebilir, varsayımları test edebilir ve tasarım çalışmalarını doğal konuşmaya daha yakın bir biçimde yürütebilir
• Ancak konuşma mühendislik değildir: konuşma fikirleri keşfetme biçimidir; mühendislik ise fikirler doğrulanabilir, test edilebilir ve sürdürülebilir bir forma yakalandığında başlar
• Yeni nesil mühendislik araçlarının görevi, karmaşık sistemlerin gerektirdiği disiplini kaybetmeden bu iki dünyayı nasıl bağlayacağını öğrenmektir

Uzmanlık hâlâ önemli

• Profesyonel yazılım, inşa ettikleri sistemlerin gerçekte nasıl çalıştığını anlayan mühendislere hâlâ ihtiyaç duyar
• Araçlar geliştirmeyi hızlandırabilir, ancak karmaşık sistemleri tasarlamak, bunlar üzerinde akıl yürütmek ve onları sürdürmek için gereken uzmanlığı ortadan kaldıramaz
• Sektör bu gerçeği unutmaya tehlikeli derecede yakın durumda
• LLM'ler deneyimli mühendisleri çok daha üretken hale getirebilir, ancak güvenilir sistemler kurmak için gerekli mühendislik disiplininin yerini almaz
• Bu araçları tapınarak değil, etkili biçimde kullanmak gerekir

[GN⁺]

Hacker News görüşleri

• Yazının öncülüne katılmıyorum. Mühendisliğin genel olarak kolaylaştığını düşünüyorum; iyi yönde de kötü yönde de. Eskiden de anlamaktan çok bir sürü null check ekleyen insan görürdüm. Şimdi bunun sadece büyük ölçekte yaygınlaştığını görüyoruz. Öte yandan iyi mühendislik de daha fazla ivme kazandı; eskiden haftalar süren bir özelliğin birkaç günde yapıldığına da şahit oldum

  • Yazının biraz abartılı olduğunu düşünüyorum. İyi mühendislik de LLM tabanlı ajanların yardımından faydalanabilir, ama sonucun doğrulanması hâlâ insanın işi. Kötü mühendislik bu adımı atladığı için, Amdahl yasası açısından bakıldığında LLM'ler kötü mühendisliği çok daha fazla hızlandırıyor
  • Kötü mühendislik çok daha kolaylaştı, iyi mühendislik ise biraz kolaylaştı. Bu yüzden eskiden iyi mühendislik yapan insanlar artık üç kat daha fazla kötü mühendislik yapıyor
  • Kurumsal uygulama geliştirmede, mock testlerinin sadece beklenen değeri döndürüp döndürmediğini kontrol ettiğini gördüm. Bunun ne anlamı var diye düşünüyorum
  • LLM'nin sihirli bir kâhin olmadığını unutmak kolay. Çıktıyla nasıl ilgilendiğiniz, sonucun kalitesini belirliyor. Olduğu gibi kullanılabildiği durumlar var ama çoğu zaman düzeltme gerekiyor. “LLM öyle dediyse doğrudur” tuzağına düşmek çok kolay olduğu için kötü mühendislik de kolaylaşıyor
  • Asıl yazıya katılsak bile, pratikte yazılım kalitesinin iyi ya da kötü olmasının çok da önemli olmadığı pek çok uygulama alanı var. Çoğu zaman sadece çalışması yeterli

• Yüz tane birim testiyle bile kodun doğruluğunu kanıtlamanın zor olduğu durumlar var. Geliştiricilerin çoğu neyin yeterli olduğunu bilmiyor. Vibe coding kullananların çoğu testleri bile makineye yaptırıyor. Sistem tasarımına gelince, bütünsel güvenliği ve zamansal değişmezlikleri garanti edebilecek bir tasarım gerekiyor. Ama çoğu kişi sadece kutular ve oklar çizip “best practice”lerden bahsediyor. Yazılım, Sussman etkisinde olduğu gibi doğa bilimlerine daha yakın; bu yüzden gözleme daha fazla zaman harcıyoruz. GenAI'yi araç olarak kullanmak faydalı olabilir ama düşünmeyi bırakıp araca bağımlı olmak tehlikeli

  • Birim testinin ne olduğunu bile bilmiyorum ama AI sayesinde gerçek işte çok faydalı olan programlar yapabiliyorum. Elit programcılar para verseniz bile e-postalara cevap vermiyor

• Birkaç yılda bir yeni bir araç çıktığında “yazılım mühendisliğinin zor kısmı çözüldü” deniyor. Verimlilik fırlıyor, demolar etkileyici oluyor ve sektör kendini övüyor. Ama çok geçmeden işten çıkarmalar geliyor. Gerçek bir atılım olsa güzel olurdu ama sonucu işten çıkarma olacaksa bunun pek anlamı yok. Sonunda soru aynı kalıyor — amaç işleri azaltmaksa, insanlar geçimini sağlayamaz hâle geldiğinde şirket vizyonunun anlamı ne?

  • Amaç bireysel istihdam değil. Nihai hedef AGI inşa etmek ve bu süreçte geliştirici maaşlarıyla istihdamın zaten zirveyi geride bıraktığını düşünüyorum. Bazı AI süper geliştiricileri hariç
  • Karmaşıklığı ortadan kaldırmanın imkânsız olduğunu düşünüyorum. Gerçeklik ve insanların kendisi karmaşık. Yazılımın basit olabileceği fikri gerçekçi değil. Daha geniş açıdan bakınca hedef sanki sonunda orta sınıfın yok oluşu gibi görünüyor
  • Talep yoksa başka bir iş yapmak gerekir. Reddedersen aç kalırsın
  • Kapitalizm, alt sınıfın varlığına dayanır. Onlar diğer işçiler üzerinde baskı oluşturur ve daha düşük ücretleri, daha kötü koşulları kabul ettirir. Programcılar sadece bir süreliğine bu gerçeklikten korunmuştu. Bu yapı göçmen emeğiyle de bağlantılı; şirketler onlara tehlikeli işler yaptırabilir ve itaat etmezlerse sınır dışı etmekle tehdit edebilir. Sonuçta bunların hepsi işgücü maliyetini düşürmeye yönelik bir sistem

• “Kodlama zaten zor kısım değildi” sözüne katılıyorum. Uzmanlar zaten ne yapılacağını biliyordu, sadece tekrar eden işler can sıkıcıydı

  • Kod bakımı hâlâ insan ve deneyim meselesi. “Hangi kodun yazılmaması gerektiği” daha da önemli hâle geldi. Artık kod üretmek çok kolay olduğu için, spagetti kod üretmenin çok kolay olduğu bir dönemdeyiz
  • LLM tartışmasının özü burada. Kimi insanlar sadece sonuç istiyor, kimileri ise bakım yapılabilirlik ve kararlılık istiyor. İki yaklaşım da gerekli ve prototiple üretim rollerinin doğal biçimde ayrışacağını düşünüyorum
  • Gerçekten yetenekli insanlar hâlâ işi kendileri yapmak istiyor. Bu LLM yüzünden değil, zaten hep böyleydi. Hatta en çok fayda görenler “sözdizimi girmek eğlenceli değil” diyenler oldu. Benim içinse yazı yazmak başlı başına tek ilginç kısım

• AI'ya aşırı bağımlı olan junior geliştiriciler ileride temelleri bilmedikleri için bunun bedelini ödeyecek. Sonunda iş güvencesi sadece deneyimli insanlarda kalacak

• “Kod yazmak zor kısım değildi” iddiasına katılmak zor. Elbette her zaman zor değil ama zaman kısıtı olduğunda kod yazmak darboğaz oluyor. AI, geçmişte imkânsız olan denemeleri mümkün kılıyor ve daha fazla mühendislik zamanı kazandırıyor

  • “Ciddiye almak zor” deyip sonunda yine de katılmakta bir çelişki var. Orijinal metin çok daha ince nüanslar içeriyor
  • Kod yazmak en çok zaman tüketen işti ve AI bunu öne çıkarıyor. Yazı yazmayı herkes yapabilir ama asıl beceri kodu okuyabilmek. Baltanın yerine motorlu testere alan bir oduncu gibi; verim artıyor ama verilen zarar da büyüyebiliyor

• AI, iyi mühendisliği de kolaylaştırdı. Sonuçta bu bir davranış yükselteci

  • İyi mühendisler artık daha da iyi iş çıkarabiliyor ama çoğu insan property testing'in ne olduğunu bile bilmiyor. Böyle insanlara AI'nın ne kadar faydalı olacağı şüpheli
  • İnternet tüm dünya bilgisini birbirine bağladı ama insanlar sonunda yine laf kalabalığına ve tüketimlik içeriğe gömüldü. İnsan doğasını hesaba katarsak AI da muhtemelen benzer bir yoldan gidecek
  • Yaratıcı problemler çoğu zaman doğrudan kod yazma sürecinde çözülüyor. AI kullanıldığında bu zihinsel devre daha az çalışıyor
  • DORA raporu gibi veriler de bunu destekliyor
  • “AI, mevcut davranışların bir yükseltecidir” cümlesi gerçekten çok yerinde. Bunu aynen kullanmak isterim

• Ben bir AI şüphecisiyim, ama bunun iş arkadaşlarımın işini elinden aldığını düşünmüyorum. Bunun yerine bana zaman kazandırıyor. Google'dan daha iyi bir araştırma aracı olarak kullanıyorum; kod tabanında gezinmek, yardımcı fonksiyon üretmek ve hataları gözden geçirmek için faydalı

  • Ben de katılıyorum. Sonunda AI kullanımının varacağı noktanın bu olduğunu düşünüyorum

• Bu günlerde yazılım mühendisliği ile araştırma arasındaki ayrım daha belirgin hâle geliyor. AI, keşif odaklı araştırmada inanılmaz bir araç. Bir olasılık görürsem o noktada SWE moduna geçip kodu anlıyor, değiştiriyor ve kendi deneyimimle şekillendiriyorum. AI'nın rolü sınırlı ama yine de faydalı

  • LLM'ler insanlardan çok daha geniş bir bilgi alanını anında tarayabiliyor. Ama son karar yine insanın zevkine ve kalite sezgisine bağlı

• Bu insanların (kötümserlerin) vazgeçmesine kadar daha kaç model çıkması gerekecek? İki mi? Üç mü?