Yapay Zeka Sohbet Robotu ChatGPT'nin Yazılımcıları İşsiz Bırakması Neden Zor Gözüküyor?
chatgpt, son dönemin en heyecan veren gelişmelerinden biri. özellikle 5-6 yılda aı alanında bir çok hayal kırıklığı yaşamımıza rağmen medeniyetimizin geldiği noktayı özetlemesi açısından oldukça önemli.
tabii böyle bir teknolojinin ortaya çıkışıyla beraber heyecan-döngüsü de (hype-cycle) başlamış oldu. bunların arasında en ilginç olanlarından bir tanesi ise yazılımcıların işsiz kalacağı yönündeki kehanet olmalı. nedenleri sonsuz çeşitlilikte olsa da temelde bir kaç noktayı gözden kaçıran insanlarda bu tür bir beklenti maalesef var. gelin yazılımın neden otomatize edilemeyeceğini size hızlıca anlatayım. umarım birkaç şey öğrendiğiniz keyifli bir yazı olur.
1) yazılımcılıyı anlayamamış olmak
chatgpt kesinlikle çok etkileyici. zaten yazının sonlarına doğru yazılıma ve yazılımcılara yapabileceği etkiler açısından da konuşacağız. son dönemde karşımıza çıkan örneklere göz gezdirdiğiz de, bunların daha çok dar bir alanda çok iyi tanımlanmış problemlerin çözümleri üzerine kurulu olduğunu görüyor olacağız. buradaki en önemli nokta probleminin tanımının kesin ve iyi yapılmış olması.
bu cümlenin yazılımcıların yüzünde tebessüm oluşturmuş olması normal çünkü yazılım aktivitesi boyunca bırakın iyi ve kesin çerçevelenmiş problem bildirimi bulmayı çoğu zaman üstünkörü yapılmış bir analizi bile bulamayabilirsiniz. geleneksel yöntemlerde yapılan analizler ise maalesef problemin özünü yakalamaktan çok kelime salatasıyla yazılımcıların angaje olma şanslarını azaltıyor. özellikle danışmanlık firmalarıyla çalışmaya başladığınız da ağdalı cümleler ve genel-geçer olmayan bir terminoloji ile yazılmış dökümanların yazılımcılarda nasıl bir etki yarattığını çok iyi biliyorum.
son dönemde ise buna benzer sebepler yüzünden analiz işlemi refinement (düzeltme, rötuşlama) denilen toplantılarda kollektif bir şekilde 10-15 dakika içinde yapılmaya başlandı. temelde yatan varsayım ne yaparsak yapalım önceden hazırlanmış detaylı bir analizin yazılım iklimindeki gerçeklik ile temas ettiğinde geçerliliğini yitireceği varsayımı üzerine kurulu. bu yüzden de analizi detaylı yapmak yerine işin kabul kriterleri belirli hale getirip ve iş tanıma olabildiğince bağlamsal bilgi ekleyip geri kalan detayların yazılımcılar tarafından çözülmesi bekleniyor.
uzun lafın kısası bir yazılımcı artık sadece kod yazmaktan ziyade çözüm üretme esnasında yazılım problemlerine içkin olan belirsizliklerin tanımlanması ve teknik düzlem ile iş düzlemi arasında açık kalan noktalar üzerinde genel bir mutabakata varılmasını da sağlıyor. yani işin içinde gözle görülür bir iletişim bileşeni mevcut.
o yüzden işlemsel, yani bir soruya bir cevap üreten, bu tür bir chat botunun yetenekleri yazılımcılar için vazgeçilmez olsa da onları yerlerinden etmekten uzak çünkü işler sadece tek bir problemden değil, çözümleri bulanık olan bir problem yumağından oluşuyor. bugün için birinin onları anlamlandırıp, önceliklendirip ve konsensüs çerçevesinde çözmesi gerek. bu yüzden sizlerde takdir edersiniz ki chatgpt bir ikameden ziyade bir yardımcıyı temsil ediyor. hatta iş bu tür etkileşimli (conversational) meslekleri otomatize etmeye geldiğinde bile yazılımcılardan farklı olarak daha çok endişelenmemiz gereken birçok meslek grubu var.
2) yazılımı anlayamamış olmak (teknik tasarımın imkansızlığı)
bir çok mühendislik dalında, üretilecek çözümler önce detaylı bir analize, tasarım ve test sürecine tabi tutulur. ardından tekrarlanabilir süreçlerden oluşan üretim bandına girer. üretim bandında ise birörnek tasarım binlerce kez çoklanır. sürecin küçük adımınlarında yapılabilecek küçük optimizasyonlar ölçek ekonomisi gereği katlanır ve karlılığı arttırır. burada en önemli nokta analiz, tasarım ve test süreçleri üretimden önce yapılıp tamamlanmasıdır. yani mühendisler belirli koşullar ve gerekler için bir çözüm tasarlar ve bu çözüm defalarca gerçek dünyada test ederler. eğer çözüm gerçekten istenen sonuçlara ulaşıyorsa üretim bandına gönderilir ve aynı şablon binlerce kez kopyalanır.
söz konusu yazılım geliştirme olduğunda analizin bir kısmı, tasarım, geliştirme ve test süreçleri aynı anda ilerler. yazılımcı bir yandan kodunu yazar, diğer yandan da yazdığı kodun doğruluğunu test ederek kademeli bir şekilde ilerler. geliştirme süreci bittiği anda tasarım süreci de bitmiş olur. yani yazılım süreçlerinde diğer mühendislik süreçlerinin aksine bir yalın ve pür bir üretim aşaması yoktur. bu bir çok genç yazılımcı arkadaşımızın dikkat etmediği ancak pratik sonuçları oldukça önemli bir noktaya parmak basar.
bizim teknik tasarım olarak bildiğimiz süreçlerin bütün hepsi test edilebilirliği olmadığı için fikirleri aktarmak üzere geliştirilmiş iletişim araçlarından ibarettir. burası çokomelli. bir diğer deyişle prototipleyip test edemediğiniz diyagramların herhangi bir değeri yoktur. hatta bu tasarımlar koltuk mimarı dediğimiz kodlamayıp sadece diyagramlar çizen insanlar tarafından yapıldığında yazılım sisteminin gerçekliğinde ve ona içkin olan belirsizlikler yüzünden bir çok kez hatalı ve yanıltıcı olur. bir çok geliştirici defalarca ellerine verilen analizi hatalı buldukları olmuştur.
buna istinaden, 1994 yılında jack reeves bu noktalara işaret edip yazılımda geleneksel mühendisliklerin tasarım süreçlerine benzeyen tek noktanın kaynak kodun (yani yazılmış kodun) kendisi olduğunu öne sürdü. özet geçmek gerekirse, reeves yazılımcıları bir çözüm tasarımcısı olarak pozisyonluyor ve üretim bandı mantığına karşı çıkıyordu. tabi ki de yazılım çevrelerinde etkisi güçlü oldu. çünkü yazılım'ın şöyle bir tarihini karıştırdığınız da göreceğiniz şey yazılımın çok genç bir alan olduğu ve bir çok sürecini üretim ve inşaat sektörlerinden almış olduğudur. mimar, mimari, geliştirme, geliştirici, tasarım örüntüleri, waterfall, kanban, altyapı, framework gibi kavramlar üretim ve inşaat mühendisliğinden ihraç edildiler. kelimelerin ihraç edilmesiyle beraber mantalite de beraberinde geldi. ve yaratıcı ve organik bir süreç olarak anlamlandırılmak yerine sanki öngörülebilir ve planlanabilir teknik bir süreç olarak konumlandırıldı. bu mantalitenin bir sonucu olarakta 80'lerda yazılım krizi denilen her büyük yazılım projesinin bir şekilde batması ile sonuçlanan bir dönem yaşadık. (daha fazla bilgi "software crisis" anahtar kelimesi ile arama yapılabilir.)
bu girdaptan 90'larda yükselen extreme programming, craftsmanship, scrum ve çevik süreçlerde vasıtasıyla çıkılmaya çalışıldıysa da bana kalırsa ancak 2010'lardan sonra taşlar yerine yavaş yavaş oturmaya başlandı. artık yazılım detaylı analiz süreçlerinden arınmış onun yerine yazılımcısına ve onun yeteneklerine güvenen süreçler etrafından şekillenmeye başladı.
şimdi konuyu bağlayalım...
yazılım dediğimiz şey yönergelerin veya tasarımların koda dökülmüş hali değildir. aksine yazılım yaşayan canlı organizmaya benzeyen sistemler bütünüdür. ve tüm bu teknik tasarım kod blokları halinde, yani kodlama yapılırken, geliştirilir. ve her bir adımda çıkan yeni bilgiler, hatalar ve zorunluluklar dikkate alınarak çeşitli ödünleşimler yapılır. burası yine çokomelli. bu ödünleşimler sadece teknik seviyelerde değil sosyal seviyelerden (organizasyon şeması) başlayıp süreç seviyeleri iner oradan da teknik seviyelere nüfuz eder. ve her bir karar bir başka seviyedeki sonuçları etkiler.
chatgpt gibi işlemsel (transactional) araçlar bu tür ödünleşimleri yapmak için tasarlanmadılar. hatta, elimizde bu kararları kantatif olarak ölçebilecek bir mekanizma olmadığı için herhangi bir veri seti de yok. doğal olarak bu tür organik yapılara benzeyen bu tür sistemleri yönetebilmek ve geliştirebilmek için hala daha insanlara ihtiyacımız var.
3) yazılı anlayamamak - zımni bilgi problemi
bir önceki paragraflarda da gördüğümüz gibi yazılım geleneksel mühendislik yöntemlerine benzemiyor. hatta sw craftsmanship gibi hareketler yazılım geliştirme süreçlerini zanaat süreçleriyle bir tutuyor. böyle bir durumda hangi yazılım yazılacağını makineye kim anlatacak? yani bu soruyla düşündürülmek istenen şey, bir şeyi tanımlayabilmek için onu önceden deneyimlemiş olmak gerek. eğer makineye bir veri modeli oluşturtmak istiyorsanız bunun doğru tasarım olup olmadığı noktasında daha önce bu modeli tasarlamış ve alternatifler hakkında düşünebilen birilerinin yardımına ihtiyacınız var.
bu tür bir bilgi ise zanaat işlerinde yaparken öğrenilen bilgi yani zımni bilgi (tacit knowledge) olarak geçiyor. yani bir nevi pratik bilgi. iyi yazılımcı ile kötü yazılımcı arasındaki farkı da işte bu işi yaparken öğrenilen pratiğe dayalı bilgi oluşturuyor. birçok farklı paradigma, yaklaşım ve araç biliyor olabilirsiniz ancak bu araçların pratik kullanım noktaları ve kusurları konusunda yeterli bilgiye sadece onu gerçekleyerek erişebilirsiniz. o yüzden bir makinenin yarattığı çözümleri değerlendirecek insanlara ihtiyacımız var. ve bu insanlar yazılım geliştirmeden sadece kitap, blog yazısı, video veya podcast dinleyerek bu bilgiye erişemezler. zımni bilgi kabiliyet için zorunluluktur.
işte bu noktada, yani belirli bir hacmin üzerinde çözüm gerektiren problemlerde, problemi tasvir edebilseniz çözümün optimal olup olmadığı noktasında kabiliyetlerini geliştirmiş insanlar ihtiyaç var ki bu da bizi bir sonraki noktaya getiriyor.
4) otomasyonun paradoksu
1944 yılında bilişsel psikolog lisanne bainbridge'in yaptığı araştırma ile otomasyona dair ironik noktalar ortaya kondu. araştırma özellikle nükleer reaktörler çerçevesinde yapılmış olsa da sonuçlar diğer alanlara rahatlıkla uygulanabilir.
otomasyonla ilgili temel yanılgı insan gücünün denklemden çıkartılması olmuştur. ancak otomatize edilen sistemlerde karmaşıklık katlanarak artar. bu tür durumlarda çıkacak olan problemleri çözmek içinse daha yetkin insanlar gerekir. bunu bir örnek ile açıklamak daha kolay olacak.
her kuyuda tulumba tipi su pompasının olduğu ve her kuyuda bir yetkilinin bulunduğu basit bir sistem hayal edin. kim suya ihtiyacı varsa yetkili kişiyle iletişime geçerek gerekli miktarı yine yetkili kişi vasıtasıyla elde ediyor. bu sistemde çıkabilecek en büyük sorun büyük ihtimalle yetkili kişinin hasta olması veya tulumbada çıkacak mekanik problemler olabilir. iki probleminde çözümü oldukça basittir. yetkili hastalanırsa yedeklerden biri göreve verilebilir veya tulumba bozulursa herhangi bir kent sanayii sitesinde tamir ettirebilir.
bunun tam kontrastı olaraksa, insan faktörünü ortadan kaldıran bir otomasyon projesi düşünün. kim su isterse merkezi bir nokta ile iletişime geçiyor ve oradan en yakın su pompasına yönlendiriliyor. tüm su pompaları tam otomatik sistemlerle değiştiriliyor ve kuyular sürekli olarak sensörler vasıtasıyla gözetleniyor.
böyle bir sistem çıkacak problemler basit yöntemlerle çözülemez. kendi alanlarında yetkin makine, yazılım ve inşaat ekipleri gerektirir. bir noktadan sonra basit ve tekrar edilebilir insan faktörünü ortadan kaldırmış olsanız da daha yetkin ekiplere bağımlılığınızı arttırmış durumda olursunuz. burdaki en kritik nokta otomasyona karşı çıkmak değil, sadece otomasyonun insan faktörünü ortadan kaldırdığı yönündeki inanışın yanlışlığına dikkat çekmektir. yani bir diğer deyişle otomasyon insan faktörünü daha önemsiz hale değil daha önemli hale getirir.
aynı şey chatgpt gibi araçlar için de geçerli. bu tür araçlar vasıtasıyla yapılacak olan otomasyonlar ve onların entegrasyonları doğaları gereği daha karmaşık olacak ve bir müdahale gerektiğinde daha yetkin bir insan grubuna ihtiyaç duyacaklardır. ve takdir edersiniz ki, bu yetkin insanlar yazılım ile iç-içe bir ömür geçiren kişilerden yani yazılımcılardan oluşacaktır. bu noktada yazılımcılardan ziyade diğer meslek grupları daha büyük bir tehlikenin içerisindeler.
yazılım soyut ve stratejik planlama kabiliyetlerine ihtiyaç duyduğuna daha değinmedim bile. yazıyı da haddinden fazla uzatmak istemiyorum. o yüzden burada bağlayacağım.
sonuç olarak
yazılım soyut, sistemsel ve stratejik düşünme yeteneklerine ihtiyaç duyan belirsizlikler içinde yetersiz analiz araçlarıyla sistemler sistemi yaratma işidir. ancak en gizli formülü ise artan karmaşıklık karşısında bu sistemleri yönetilebilir tutmakta yatar. chatgpt çok açık ki yazılımcıların yolculuğunda onlara küçük fonksiyonlar yazdırmakta, debug'ı kolaylaştırmakta, testleri geliştirmekte veya kaba-taslak kod çıktıları almakta çok ama çok faydalı olacak. ancak bir yazılımcıyı yerinden edebilecek noktaya erişebilmesi için sistemsel, soyut ve stratejik olarak düşünebilmesi gerekiyor ki bu tür bilgiler oldukça bağlamsal yani kurumlardan kurumlara veya problemlerden problemlere göre değişen şeyler. doğal olarak her spesifik bir probleme uygun ai train edemeyeceğimiz için bu tür araçların mevcut problemler için jenerik kalmaları çok olası. jenerik kalmasalar bile otomasyonun insan faktörü gerekliliğini daha yetkin bir noktaya çekmesi yüzünden yazılımcıları yerinden etmekten çok onlara olan ihtiyacı arttıracaktır.
Yapay Zekanın Doktorluk Mesleğini Bitirme İhtimali Ne Durumda?
