- Son 50 yılı aşkın süredir yazılım geliştirmeyi basitleştirip geliştiricilere bağımlılığı azaltma girişimleri tekrar tekrar ortaya çıktı
- 1960'lardaki COBOL ile başlayıp CASE araçları, Visual Basic, low-code·no-code ve son dönemdeki AI kod yardımcılarına kadar aynı örüntü sürdü
- Her teknoloji üretkenliği artırdı, ancak karmaşıklığı ele alan düşünme süreci hâlâ insanın sorumluluğunda kaldı
- AI, geliştiricilerin kapasitesini büyütüyor, ancak iş problemlerini anlama ve muhakemeyi ikame etmiyor
- Bu tekrar eden girişimler, araçların sınırından çok problemin karmaşıklığını gösteriyor ve sonuçta asıl önemli olan insanın düşünme becerisine yatırım oluyor
Tekrarlanan örüntünün başlangıcı
- Her 10 yılda bir “bu kez geliştirme daha kolay olacak” vaadi ortaya çıkıyor
- 1969'da Apollo programının ardından yazılım temel bir teknoloji olarak öne çıktı
- Ancak geliştirmenin uzmanlık bilgisi, yoğun odak ve zaman yatırımı gerektirdiği ortaya çıktı
- İşte bu noktada, “geliştirmeyi basitleştirip iş gücünü azaltalım” şeklindeki kalıcı hayal başladı
COBOL: İş birimlerinin doğrudan kod yazabileceği inancı
- COBOL, adındaki Common Business-Oriented Language ifadesinin de gösterdiği gibi, iş birimlerinin İngilizce cümle yazar gibi kod yazabilmesi için tasarlandı
- Ancak pratikte mantık, veri yapıları ve sistem tasarımının karmaşıklığı yerinde kaldı ve sonunda yeni bir uzman COBOL geliştiricileri katmanı oluştu
- “Herkes kod yazabilir” vizyonu gerçekleşmedi
1980'ler: CASE araçlarının otomatik üretim vaadi
- CASE (Computer-Aided Software Engineering) araçları, diyagramlardan otomatik kod üretme vaadiyle ortaya çıktı
- Şirketler, üretkenliğin 10 kat artmasını bekleyerek büyük ölçekli yatırımlar yaptı
- Ancak üretilen kod; performans sorunları, bakım zorluğu ve model uyumsuzluğu nedeniyle başarısız oldu
- Mantıksal karmaşıklığı anlamaya hâlâ ihtiyaç duyulduğu için sorun çözülmedi
1990'lar: Visual Basic ve Delphi yaklaşımı
- Sürükle ve bırak yöntemi ile UI'ı kolayca oluşturmayı mümkün kılarak geliştirmeye giriş eşiğini düşürdü
- Basit uygulamalar yapılabildi, ancak entegrasyon, güvenlik, performans ve bakım gerektiren karmaşık sistemlerde hâlâ deneyimli geliştiricilere ihtiyaç vardı
- Sonuç olarak geliştirici talebi azalmadı, aksine büyüdü
2000'lerden sonra: Web framework'leri, low-code, no-code
- Ruby on Rails “configuration'dan çok convention” ilkesini, low-code·no-code platformları ise “kodsuz geliştirme”yi öne çıkardı
- Belirli alanlarda hız artışı ve daha geniş katılım sağlansa da, uzman geliştirici ihtiyacı sürekli arttı
- Tekrarlanan soru şu oldu: “Bu örüntü neden sürüp gidiyor?”
Karmaşıklığın doğası
- Yazılım ilk bakışta basit görünebilir, ancak gerçekte karmaşıklık ayrıntılar ve istisna işleme noktasında patlar
- Örnek: stok rezervasyonu çakışması, ödeme başarısızlığı, e-posta hizmetinin kesilmesi
- Bu tür ayrıntılı kararlar, tam da geliştirme eyleminin özüdür ve hiçbir araç bunu ortadan kaldıramaz
AI çağında yeni bir bölüm
- AI kod yardımcıları doğal dille kod üretiyor ve açıklama, debugging, iyileştirme önerileri sunuyor
- Bu gerçek bir ilerleme, ancak problem tanımı, güvenlik, entegrasyon ve bakım konusundaki muhakeme hâlâ insanın rolü
- AI, geliştiricinin üretkenliğini büyütüyor, ancak muhakeme ve bağlam anlayışını ikame etmiyor
Hâlâ yetersiz olan geliştirme kapasitesi
- Teknoloji sıçramalı biçimde ilerledi, ancak yazılım talebi arzı aşıyor
- Şirketler “daha hızlı, daha çok üretmenin yolunu” ararken geliştirmeyi basitleştiren araçlara umut bağlıyor
- Ancak darboğaz yazma hızı ya da sözdizimi değil, karmaşıklık üzerine düşünebilme becerisi
Liderlerin sorması gereken soru
- Soru “Bu araç geliştiricilerin yerini alır mı?” olmamalı
- “Karmaşık problemleri çözmeye yardımcı oluyor mu?”
- “Tekrarlayan işleri azaltıp yaratıcı problemlere odaklanmayı sağlıyor mu?”
- “Yeni teknik beceriler öğrenmeyi gerektiriyor mu?”
- Bu sorular, araçların sınırlarını ve insan düşüncesinin kaçınılmazlığını fark etmeyi sağlar
50 yılın dersi: Sorun mekanik değil, zihinseldir
- COBOL sözdizimini basitleştirdi, CASE yazmayı ortadan kaldırdı, AI ise tüm fonksiyonları üretiyor; ama temel zorluk hâlâ yerinde
- Yazılım geliştirme, ‘düşünceyi somutlaştırma eylemi’dir ve bu, araçlarla ikame edilemez
- Mimari tasarım ya da tıbbi teşhis gibi, asıl değer düşünme sürecinin kendisidir
Bundan sonraki yön
- Yeni araçlar çıkmaya devam edecek, ancak en önemli şey insanın düşünme gücüne yatırım
- AI·low-code·yeni framework'ler denenmeli, ancak karmaşıklığı anlama becerisi kurumun temel yetkinliği hâline getirilmeli
- Apollo programında olduğu gibi, başarıyı belirleyen unsur araçlardan çok düşüncenin hassasiyeti
Hayalin sürmesinin nedeni
- “Geliştiricilerin yerini alma hayali” başarısızlık değil, araç inovasyonunu tetikleyen iyimserliktir
- Her girişim tam bir ikamede başarısız olsa da, yeni nesil faydalı araçlar ortaya çıkardı
- COBOL, iş sistemleri geliştirmenin yaygınlaşmasını sağladı
- CASE, görsel modellemenin gelişimini destekledi
- Visual Basic, geliştirmeye erişilebilirliği artırdı
- AI, geliştirme biçimindeki değişimi hızlandırdı
- Sonuçta sınırlayıcı olan araçlar değil, çözmeye çalıştığımız problemlerin karmaşıklığıdır
- Yeni araçları reddetmeye gerek yok; önemli olan gerçekçi beklentileri ve insan muhakemesinin önemini kabul etmek
5 yorum
Hacker News görüşleri
Bu AI devrimi dalgasına bakınca, kodlamanın büyük kısmının özsel karmaşıklık değil, arızi karmaşıklık olduğunu fark ediyor insan
Bu, insan için kavramsal olan işlerin AI için prosedürel işlere dönüşmesi demek
Örneğin eskiden Java'da
public static void main(String[] args)yazmak için birçok kavram öğrenmek gerekirdi, ama AI'ye sadece “sınıfın giriş metodunu yaz” prompt'unu vermek çoğu zaman o kodu neredeyse kesin olarak üretmesine yetiyorİnsan için zor olan prosedürel işler AI için kolayken, toplum bu tür prosedürel emek etrafında yapılandığı için inovasyon yayıldığında birileri yükselecek, birileri de acı çekecek
“No-code geliştiricilerin yerini alacak” iddiası her seferinde tekrar ediliyor, ama pratikte daha fazla geliştirici işi yarattı
COBOL, VB, Squarespace ve şimdi de AI — araçlar giriş bariyerini düşürdükçe daha çok insan bir şeyler üretmeye çalışıyor ve sonunda sınırlara çarpınca gerçek geliştiricilere ihtiyaç duyuluyor
Basit ve tekrarlı işler ortadan kalkıyor ama neyin yapılacağını tanımlamak ve debug etmek hâlâ geriye kalıyor
AI karmaşık projeleri kendi başına kodlayabilirse, insanların ayrıntılarla uğraşmasına gerek kalmayacağı için geliştirici talebi azalabilir
Geçmişte internet, bulut, mobil ve makine öğrenimi gibi büyük trendler vardı, ama gelecekte de böyle 'büyük problemler' çıkmaya devam edip etmeyeceğinden emin değilim
Son 20 yılda sistem yönetimi alanında da aynı deseni gördüm
“Daha yüksek soyutlama uzman işini demokratikleştirir” vaadi tekrar tekrar sunuluyor, ama pratikte olan şey maliyetli bir yeniden icat
Kubernetes gibi araçların karmaşıklığı gizlediği söyleniyor ama sonuçta geliştiriciler temel kavramları bilmeden aynı problemleri daha pahalı biçimde yeniden öğreniyor
Excel bunun tipik örneği — korkunç hatalar üretti ama erişilebilirlik sayesinde başarılı oldu
Sonuçta hepimiz aynı anda hem “Excel'in erişilebilirliğini” hem de “mühendisliğin güvenilirliğini” istiyoruz, ama ikisine birden sahip olamıyoruz
Gerçekte olan, ölçek büyüdükçe iş karmaşıklığının daha üst seviyeye taşınması
Bu desenin tekrar etmesinin nedeni piyasa teşvikleri
Şirketler AI'yi her derde deva bir çözüm gibi paketlemek zorunda, çünkü ancak o zaman hisse fiyatı yükseliyor; böylece ortaya gerçek performanstan çok inanç satan bir yapı çıkıyor
Eninde sonunda gerçeklik ortaya çıktığında piyasa karışacak
Aslında geliştirici sayısı azaltılabilirdi
Şirketler daha seçici işe alım ve eğitim yatırımı yapsaydı
Ama gerçek tam tersiydi ve web framework'leri üretkenliği artırmaktan çok eğitim maliyetini düşürmek ve iş gücü havuzunu genişletmek için yapıldı
Orta kademe yöneticiler ve üst yönetim teknoloji departmanlarını sadece maliyet merkezi olarak görüyor
Bu yüzden AI'yi her basın bülteninde anıp personel giderlerini düşürmekten söz ediyorlar
Gerçekte maliyetler AI yüzünden değil, offshore iş gücüyle yer değiştirme sayesinde azaltılıyor
Geriye kalan onshore ekipler ise daha fazla işi sırtlanarak üretkenliği yükseltiyor
Sorun personel maliyetini düşürmek değil, genel bir yatırım daralması
Sonuçta AI veri merkezi yatırımları üzerinden sermayeyi içine çekerek işleri azaltıyor
AI'nin amacı geliştiricilerin yerini almak değil, soyutlama seviyesini yükselterek daha karmaşık problemleri ele almayı sağlamak
İlk bilgisayarlardaki kablolama programlamasından assembly'ye, oradan C'ye, Python'a ve framework'lere uzanan süreçte geliştiriciler giderek daha yüksek seviyedeki sorunlarla uğraşır oldu
Ancak önceki aşamaların hepsi deterministik ve doğrulanabilir dönüşümlerdi, üretken AI'nin farkı ise deterministik olmaması
Bununla ilgili olarak The Story of Mel okunmaya değer
LLM'ler derleyiciler gibi token, AST, IR vb. şeyleri görünür kılmadığı için opak kalıyor
Doğal dil tabanlı deterministik olmayan sistemler, önceki nesil soyutlamalara benzemiyor
Bu yüzden “assembly'den C'ye geçiş” benzetmesi uygun değil
Dijkstra'nın dediği gibi, bilim zor olduğu için nefret edilir, o güce sahip bilim insanları da öyle
EWD1041 orijinal bağlantısı
Tersine, geliştiriciler de her zaman geliştirici olmayan meslekleri otomatikleştirme hayali kurdu
AI bu hayalin en güncel versiyonu
2000'lerin başında üniversitede Rational Rose UML zorunlu dersti
O dönemde bir startup CEO'su “artık sadece diyagram çizeceğiz, kod otomatik üretilecek, geliştiricilere gerek kalmayacak” diyordu
Ama sonuçta o kehanet gerçekleşmedi
Makineler, makineler için kod üretir.
İnsanların makine dilinin üstüne kurduğu kumdan kale, eninde sonunda yıkılmaya mahkûmdur.
...böyle bir şey de söylenebilir tabii lol