- NoCode’dan AI’a kadar, geliştiricilerin yerini alacağını iddia eden teknolojiler tekrar tekrar ortaya çıkıyor; ancak gerçekte olan, teknolojik değişime göre rollerin dönüşmesi oluyor
- NoCode geliştiricileri ortadan kaldırmadı; bunun yerine NoCode uzmanlarını ve entegrasyon becerisine sahip teknologları ortaya çıkardı, bulut ise DevOps mühendisi gibi ileri uzmanlık alanları yarattı
- Bugünkü AI geliştirme araçları da benzer bir yolda ilerliyor; AI’ın kod yazdığı bir çağda bile sistem mimarisi tasarlama yeteneği hâlâ temel önem taşıyor
- AI yerel optimizasyonda iyi olsa da tüm sistemi tasarlamada zayıf kalıyor ve yüksek üretim hızı nedeniyle yapısal hataları hızla kalıcı hâle getirme riski taşıyor
- Sonuçta geliştiricilerin yerini alma söylemi, teknoloji yığınındaki değişime bağlı bir evrim ve derinleşme anlamına geliyor; temel role ise hâlâ ihtiyaç var
From NoCode to AI-Assisted
- Birkaç yılda bir, yazılım geliştiricilerinin yerini alacağı iddia edilen yeni bir teknoloji ortaya çıkıyor
- "Kodlamanın sonu", "artık herkes uygulama yapabilir", "çocuklar bile kod yazıyor" gibi abartılı beklentiler içeren benzer başlıklar tekrar tekrar üretiliyor
- Yöneticiler ve danışmanlar bu akıma dikkat kesiliyor ve bütçelerin bu yöne kaydığı görülüyor
- Ama gerçeklik her zaman “yerini alma” değil, “dönüşüm” oldu
- Daha karmaşık hâle gelen teknolojileri yöneten yeni roller ve daha ileri uzmanlık gerektiren meslekler ortaya çıkıyor; ücret seviyeleri de yükselme eğilimi gösteriyor
- NoCode, uzman teknik bilgi olmadan uygulama geliştirilebileceği beklentisini yarattı; ancak sonunda veri modelleme, entegrasyon, bakım gibi karmaşık sorunlar varlığını sürdürdü ve bunları çözmek için yeni meslekler doğdu
- Bulut, sistem yöneticilerine artık gerek kalmayacağı inancını yarattı; fakat gerçekte DevOps mühendisi gibi ileri düzey uzmanlıklar talep edilmeye başlandı ve ücretler arttı
- AI da aynı şekilde, “AI kodu bizim yerimize yazar” gibi görünse de gerçekte AI’ı yönetip orkestre edebilen yetkin geliştiricilerin önemi daha da artıyor
Tekrarlanan yerini alma vaatlerinin bitmeyen atlıkarıncası (The Endless Carousel of Replacement Promises)
NoCode/LowCode devrimi
- Sezgisel arayüzlerle herkesin uygulama geliştirebileceğini savunan NoCode/LowCode devrimi ortaya çıktı
- Ancak sahada, veri modeli tasarımı, mevcut sistemler ve veritabanlarıyla entegrasyon, istisna yönetimi, bakım gibi yeni sorunlar ortaya çıktı
- Bunun sonucunda sıradan geliştiriciler değil, alan bilgisini ve teknik sınırları aynı anda anlayan NoCode uzmanlarına ihtiyaç doğdu
- Bu kişiler, mevcut geliştiricilerden daha yüksek maaşlar alıyor
Bulut devrimi
- Buluta geçildiğinde sistem yöneticilerine artık ihtiyaç kalmayacağı yönünde büyük bir beklenti vardı
- Ancak bulut yönetimi uzmanlığı ve karmaşıklık aksine daha da arttı
- Geleneksel sistem yöneticileri DevOps mühendisine dönüşerek daha yüksek ücretler almaya başladı; altyapı otomasyonu, deployment pipeline’ları, dağıtık sistem yönetimi gibi işlerin seviyesi yükseldi
- İş ortadan kalkmadı; yalnızca yeni bir çalışma biçimine evrildi
- Mikroservislere geçişte de karmaşıklık arttı ve sonunda sistemi temelden yönetebilen uzmanların rolünün ne kadar önemli olduğu ortaya çıktı
Offshore geliştirme dalgası
- Yurtdışı outsourcing ile maliyetlerin düşürülebileceğine dair bir inanç oluştu; ancak iletişim sorunları, kalite düşüşü ve alan bilgisi eksikliği nedeniyle zorluklar yaşandı
- Sonunda strateji, dağıtık ekip organizasyonu, net sahiplik ve güçlü mimari yönüne evrildi; bu da toplam maliyetin başlangıçta beklenenden daha yüksek olmasına yol açtı
AI kod asistanı devrimi
- Artık gündemde olan vaat, AI’ın otomatik olarak kod üreteceği fikri
- İlk pratik gerçeklikte, AI’ın ürettiği kod çoğu zaman ince hatalar ve tutarlılık problemleri barındırıyor
- Kıdemli mühendisler AI çıktısını gözden geçirip düzeltmek için çok zaman harcıyor; deneyimli geliştiriciler ise çok daha fazla değer üretiyor
- Sadece AI desteğiyle kurulan sistemlerde çoğu zaman sistematik bir mimari eksik kalıyor
- Yani teknoloji, teknisyenin yerini almıyor; onun uzmanlığını daha yüksek bir soyutlama katmanına taşıyor
Bu döngüyü özel kılan şey
- İnsanların gözden kaçırdığı temel nokta: Kod bir varlık değil, bir borçtur
- Kod ne kadar hızlı ve kolay üretilirse, bakım, güvenlik ve refactoring yükü de o kadar artar
- AI fonksiyon düzeyinde optimizasyon yapabilir ama tüm sistemi tasarlama becerisi sınırlıdır
- Uygulama hızı arttıkça yapısal hataların hızla kalıcılaşma riski vardır
- Sonuç olarak, AI çağında da gerçek varlık sistem mimarisi tasarlama yeteneğidir ve bu, yerini alma değil güçlendirme konusudur
- "AI geliştiricilerin yerini alacak" iddiası şu temel yanlış anlamalardan doğuyor
- Kod bir varlık değil, bir borçtur gerçeği
- Kod sürekli bakım, doğrulama, güvenlik yönetimi ve yenileme gerektirir; satır sayısı arttıkça bu borç da büyür
- AI’ın kodu hızlı üretmesi, yalnızca borcun da o hızda birikmesi anlamına gelir
- Yani AI yerel optimizasyonda (fonksiyonlar, kısmi özellikler) iyi olsa da küresel tasarım ve mimari kararlarında yetersiz kalır
- Uygulama hızı arttıkça yanlış tasarımın tüm sistemde "kemikleşme" riski büyür
- Tek seferlik kısa ömürlü site projelerinde bu büyük sorun olmayabilir; ancak uzun vadede gelişen sistemler için ölümcül olabilir
- Teknoloji inovasyonunun kalıbı değişmiyor
- Sistem yöneticileri DevOps mühendisi oluyor, backend geliştiricileri ise bulut mimarına dönüşüyor
- Ancak AI her şeyi hızlandırıyor. Hayatta kalan ve gelişen beceri kod yazmak değil
- Asıl mesele sistemleri tasarlamak (Architecting systems). AI’ın yapamadığı tek şey tam olarak bu
19 yorum
Ben biraz daha temkinli çalışan biriyim; bu yüzden AI araçlarını önemli işlerde hiç kullanmadım, en fazla Google ya da Stack Overflow’da arattığım şeyleri Gemini ya da ChatGPT’ye sormaya çevirdim diyebilirim. Kullanıyorum ama...
AI’den bir şey yapmasını isterken, fonksiyon düzeyinde "şu girdiyi verince şu çıktıyı üreten bir fonksiyon yaz" deyip onu almak, ardından da AI’nin ürettiği fonksiyondan dönen değerlerin gerçekten doğru olup olmadığını kontrol eden mantığı kendim yazmak şeklinde kullanırsam fena olmayabilir diye düşünüyorum.
Tüm bağlamı yapay zekanın iyi anlayabileceği bir biçimde tamamen düzenleyebilir miyiz? sorusuna karşı ben şüpheciyim. İnsanlar, yalnızca o anda yaptıkları geliştirme için yüzeyde gerekli olan bağlamın ötesinde, örtük bağlamlara da sahip ve geliştirme yaparken bunları da hesaba katıyor; ancak bu bağlamı insanların iyi rafine edilmiş ifadelerle yazıya dökebileceğini henüz düşünmüyorum. Bunun yapay zekanın sorunu olmaktan çok insanın bir sınırı olduğunu düşünüyorum. Özellikle de günümüz insanlarının yazma becerisinin pek iyi olduğunu düşünmüyorum.
Korkutucu olan bence şu anın kendisi değil, daha çok gidişat gibi görünüyor..
Şimdi durum hiç de öyle değil.
Tüm mesleklerin yerini alacağı bir gelecek kapıda ve geliştiriciler de bunlardan yalnızca biri.
Böyle bir şey hiç trend olmadı.
Tam olarak aynı değişim olmamış olabilir.
Ama bu, modern çağın çok öncesinde pek çok mesleğin zaten geçtiği bir dönüşüm. Örneğin fotoğrafın ortaya çıkmasıyla sanatçıların, otomatikleşmiş fabrikalarla zanaatkarların yaşadığı değişim gibi. Kodlama da bana farklı görünmüyor.
Bence yenilik sıradanlaştığında, sonuç olarak bugün olduğundan daha fazla mühendise ihtiyaç duyulacak. Çünkü kullanıcıların beklentileri yükselecek ve daha büyük, daha karmaşık şeyler yapmak gerekecek. Tıpkı Kızıl Kraliçe hipotezinde söylendiği gibi.
Elbette iş türlerinin değişmesi ya da belirli görevlerin ortadan kalkması oldukça olası. Nasıl ki bir noktada dizgicilik ortadan kaybolduysa. Bu bağlamda, sistem tasarlamak da muhtemelen daha da yükselmiş soyutlama düzeyinin bir metaforu ya da örneği olacaktır.
Bence herkes geliştiricileri bir şeyle ikame etmek istiyor.
Üstelik pek bir iş yapmadan çok para aldıklarını düşünen epey insan var gibi görünüyor.
Gerçekte yer değiştirip değiştirmediğinden bağımsız olarak, bu tür söylemlerin sürekli gündeme gelmesinin sebebinin kışkırtıcı olmaları olduğunu düşünüyorum.
Çoğu zaman böyle çarpıcı başlıklar atıldığında, en başta gerçeğin ne olduğu ya da "yer değiştirme" denen şeyin nasıl tanımlanabileceği üzerine derinlemesine düşünülmüş olma ihtimali pek olmuyor.
Gerçekten iyi düşünülmüş yazılar ise daha çok yapay zekanın ya da başka araçların şu anda nereye kadar gelebildiğini ve hangi yöne doğru geliştiğini ele alıyor. Ama böyle sıkıcı başlıklara da sıradan insanların tıklayacağı pek yok.
Kışkırtıcı başlıklar çok fazla..
"Her yıl %10 işten çıkarma yapan Zuckerberg: 'Gelecek yıl yapay zeka geliştiricilerin yarısının yerini alacak' [Yoon Min-hyuk'un Silikon Vadisi View]" https://m.sedaily.com/NewsView/2GRQ1RKIYC
"'Yapay zekanın en iyi yaptığı iş kodlama'… MS yeniden yapılanmada ilk hedef 'geliştiriciler'" https://n.news.naver.com/mnews/article/009/0005494133
"'Böyle giderse işi bile kaybedeceğiz' endişesi 'gerçek' mi oluyor?… Kaygı içindeki sektör" https://econmingle.com/economy/…
"[Yumi's Pick] 'Yeni mezun SW geliştiricisi almıyoruz'… 'AI coding'in tadına bakan şirketlerde organizasyon verimliliği 'start' aldı" https://v.daum.net/v/20250522162617091
"'Yapay zeka analiz, tasarım ve kodlamanın hepsini yapıyor'… LG CNS, geliştirici yerine 'AI programmer' kullanacak" https://zdnet.co.kr/view/?no=20250528092405
Kademeli olarak yer değiştirdiğini düşünmek gerekiyor.
Aynı iş sonucunu elde etmek için gereken kişi sayısının azaldığı bir gerçek.
"Sistemi tasarlamak" konusunda da, daha önce 10 kişinin yaptığı iş 8 kişi + yapay zeka desteğiyle çözülebiliyorsa
zaten 2 kişi yer değiştirmiş demektir.
Sistem tasarımı tarafı da
Genelde prompt yazarken bunu dikkate almadan dahil ettikleri için olabilir mi
Sorun galiba vibe coding’in sonrasını toparlamanın pek iyi yönetilememesi.
Kişisel deneyimlerime dayanarak bu görüşe katılıyorum. Yapay zeka da sonuçta bir araç; 1'den 99'a kadar gerçekten hızlı ve iyi ama her zaman geriye kalan o son 1 eksikmiş gibi geliyor.
Katılıyorum ama sanırım mesele "sistem tasarımı"ndan çok "sistem tasarımı yoluyla karmaşık sorunları çözmek" değil mi?
Kolay işlerin daha da kolaylaştığına, zor işlerin ise giderek daha da zorlaştığına inanıyorum.
Ha ha
Hacker News görüşleri
Yakın zamanda freelancer olarak "tek kullanımlık pazarlama landing page'leri" gibi işleri düzeltme deneyiminden söz ediyor; kontrol takıntısı olan müşterilerin her zaman AI'ın düzgünce halledemeyeceği garip gereksinimler eklediğini ve sonunda ortalığı toparlama işinin yine kendisine kaldığını anlatıyor. AI ne kadar akıllı olursa olsun, yazılım problemlerinin teknik olmaktan çok, insanların sürekli "gereksiz karmaşıklık" üretmesinden kaynaklandığı görüşünde. Sonuçta geliştiricinin en büyük silahının “hayır” demek olduğunu, ancak AI'lar birbiriyle rekabet ettiğinde insanlardaki gibi içlerinden en az birinin mutlaka “evet” diyeceği endişesini dile getiriyor.
Yazılım kusursuz biçimde uygulanabilir; ama gereksinimlerin kendisi teknik gerçekliği yansıtmıyorsa sonuçta sadece kaos çıkar. Bu, klasik “requirements bug” kavramı. AI artık format veya destek durumu gibi pratik kısıtlarla da başa çıkabiliyor (ör. gif şeffaflığı desteklemez), ama “logoyu her noktasının merkeze eşit uzaklıkta olduğu bir kare yap” gibi absürt talepleri insanlar üretmeye devam edecek düşüncesi öne çıkıyor. jpg yazım hatasına da mizahi bir gönderme var.
“Hayır” ile “evet” arasında, “bu gerçekten doğru mu” diye sorgulatan 50 ton gri olduğu deneyimi aktarılıyor. Birinin “veritabanını indirilebilen” bir web sayfası istediği ama aslında kastının basit bir csv dışa aktarma olduğu örneğinde olduğu gibi, bağlamı yorumlamanın önemi vurgulanıyor. chatgpt'nin bu tür nüansları gerçekten anlayıp anlayamayacağı sorgulanıyor.
“Reddetmek” gerçekten de geliştirici işinin en zor ve en yorucu kısmı. Birçok geliştirici aslında bu rolü sevmiyor ya da bunun kendi işi olmadığını düşünüyor. Sonuçta bir projenin gerçek başarısını teknoloji değil, paydaşlarla kurulan “insandan insana” iletişim belirliyor; bu yüzden “fiilen PM rolünü de üstlenen geliştiriciye” her zaman ihtiyaç olacağına inanılıyor.
Tüm bunların sözde
Peoplewarekitabında çok iyi anlatıldığı söyleniyor. “Umarım bütün sorunların teknik olur” sözünü bu yüzden sevdiğini belirtiyor; çünkü gerçekte kodla çözülen sorunlar, birkaç uç örnek dışında, hiçbir zaman o kadar zor olmadı.Bunun iyi bir nokta olduğu ve AI'ın zamanla karmaşıklığı tahmin edip uyarı verme konusunda oldukça iyi hale gelebileceği yorumu var. Satrançta AI'ın insanlardan çok daha iyi değerlendirme/yargı yeteneği göstermesi buna benzetiliyor. Burada AI sadece LLM ile sınırlı olmasa da, bu kategorideki ilerleme de kabul ediliyor.
Yazıda geçen “AI sistem tasarlayamaz (architecting)” iddiasına katılmayan bir görüş var. Aslında AI'ın bu alanda zaten giderek daha iyi olduğu, sadece gerekli koşulların adlarının sürekli değiştirilerek tartışmanın yerinin kaydırıldığı söyleniyor. Ancak AI'ın kendi başına ne istemesi gerektiğine ya da kullanıcının motivasyonlarını onun yerine belirleyemediği belirtiliyor (tabii fikir önerebilir). Bundan sonra da birilerinin gerçekten harekete geçip sorun çözmek istemesi gerekecek; toplum böyle işliyor. Geliştiricinin rolü değişebilir ama sorun çözme işi hâlâ insana ait.
“Geliştirici” kelimesinin anlamının değiştiği söylense de, özün en başından beri aynı olduğu görüşü dile getiriliyor. Programlama özünde belirsiz gereksinimleri açık koda dönüştürme işi. Geçmişte yöntem makine kodu ve delikli kartlardan framework'lere, GUI'lere ve görsel araçlara kadar değişti; ama kod yazmanın hâlâ en etkili yöntem olmasının sebebi açıklık ve aktarılabilirlik. LLM'ler mevcut kalıpları sürdürmede güçlü olsa da, gerçekten özgün işlerde veya doğal dille açıklama yapılması gereken durumlarda oldukça yetersiz kalabiliyor. Piyasa şu an aşırı hype modunda, ama her yeni teknolojide olduğu gibi yine sadece bazı şeyler değişecek.
Şirketlerin AI nedeniyle junior işe alımını azaltması gibi değişimlerin şimdiden hissedildiği gözlemi paylaşılıyor. AI mimarileme dışında her şeyi yaparsa, sonuçta daha az mühendise ihtiyaç duyulan bir yapıya gidileceği endişesi var.
AI'ın hâlâ architecting yapamadığı kesin bir dille savunuluyor. Architecting ile planning'in farklı olduğu, planning'in kısıtları, çözümleri ve kaynakları dağıtıp tahmin üretme yeteneği olduğu söyleniyor. AI'ın bunu etkili biçimde yapabildiği seviyeye hâlâ uzak olduğu belirtiliyor. Gerçek architecting ise çok katmanlı işbirlikçi ve rekabetçi tasarım demek; AI bir katmanda hata yaparsa bütün sistem bozulabilir. Böyle sistemleri güvenli biçimde tasarlayıp denetleyebilecek olanın hâlâ insanlar olduğu vurgulanıyor.
Yeterli bağlam bilgisi verilirse AI'ın ne istendiğini oldukça iyi anlayabileceği görüşü de var. Bunun aslında mahremiyet ihlali uyarılarıyla da ilişkili olduğu söyleniyor. Güçlü sistemler ve bağlam farkındalığı teknolojileri organizasyonların eline geçtiğinde, AI'ın sizin isteklerinizi ve hatta bir sonraki hamlenizi bile “yeterince” tahmin edebilir hale gelmesinin daha da korkutucu olduğu belirtiliyor.
AI'ın architecting değil, sadece simülasyon yaptığı; hatta çoğu zaman kodlamayı bile düzgün yapamadığı yönünde açık bir eleştiri de var.
İş dünyasının kaliteyi önemsediği varsayımının yanlış olduğu savunuluyor. Şirketler yalnızca kârlılığa bakar; yüksek kaliteyi ancak müşteri isterse sunar. Açıkçası müşteriler de gerçekte kaliteden çok fiyat/performans açısından “en iyi” ürünü sever; bu yüzden Amazon'dan en ucuz aracı alıp benzer derecede özensiz (
vibe code) kodları tekrar tekrar üretirler görüşü paylaşılıyor. Sonuçta kaliteyi gerçekten önemseyen tek grubun mühendisler olduğu, bu yüzden mühendis bakış açısından kalitenin belirleyici olacağı gelecek tahminlerinin rahatça göz ardı edilebileceği söyleniyor.Buna karşılık, kalitenin bir farklılaşma noktası olabileceği yorumu geliyor. iPhone çıktığında daha fazla özelliğe sahip pek çok rakip vardı; ama daha akıcı ve rafine bir UI sununca pazarı ezip geçtiği hatırlatılıyor.
En sevdiği kalite odaklı şirket olarak Fractal Audio örnek veriliyor. Gitar için donanım tabanlı modelleyiciler (amfi ve pedalboard simülatörleri) üreten küçük bir şirket olduğu, arka arkaya yenilikçi güncellemeler yaptığı ve CEO'sunun analog modelleme performansına takıntılı olduğu anlatılıyor. Büyük şirketlerden çok daha üstün kalite sunduğu, komisyon, abonelik ya da ünlü pazarlaması olmadan; doğrudan satış ve ücretsiz algoritma güncellemeleriyle konumlandığı söyleniyor. Kalite sayesinde pazar payı kazanmış canlı bir örnek olarak, tüm işlerin mutlaka “en düşük fiyat en düşük kalite” rekabeti içinde olmadığı savunuluyor.
Müşterilerin kaliteye önem vermediği görüşüne itiraz edilerek, eğer kalite gerçekten önemsiz olsaydı tüm startup'ların sadece kusurlu ve ucuz ürünler üretip büyük başarı ve gelir elde etmiş olması gerekirdi deniyor.
Gerçekte başarılı yazılım ürünlerinin çoğunun çok yüksek kalitede olduğu sıralanıyor: Google, iPhone, Stripe, Notion vb. Piyasada uzun ömürlü olan ürünlerin yavaş ya da bug dolu olmadığı; tersine kalitenin başarı faktörü olduğu savunuluyor. Buna karşı örnek duymadığını da ekliyor.
Kalitenin belli bir eşiğe kadar modülerleşme, abonelikleşme ve internet bağlantısı yüzünden silikleşebileceği, ancak her şeyin aniden çöktüğü bir gelecek riskinin de bulunduğu söyleniyor. Cihazların tuğlaya dönmesi, basit bir sitenin bile 12 saniyede açılması, toplumsal altyapı ve devlet sistemlerine milyarlar harcanmasına rağmen bunların istikrarsız kalması ve günlük konuşmaların LLM'lerle yapılır hale gelmesi gibi riskler hatırlatılıyor.
Geçmişteki UML tabanlı “mimar spesifikasyonu yazar, geliştirici boşlukları doldurur” tarzı örgütsel devrimin aşırı karmaşık sistemler ürettiği ve çevikliği yok ettiği hatırlatılıyor. Ardından gelen “agile” yaklaşımının da yanlış anlaşılıp geliştiricilerin mikroyönetimi, güvensizlik ve yaratıcılıktan uzak örgüt kültürlerine dönüştüğü söyleniyor. Sonuçta başarılı ekiplerin ortak özelliğinin, kullanılan araç ya da süreçten bağımsız olarak, geliştirici olmayan kişilerin geliştiricilerin işine gerçekten ilgi göstermesi ve sorunları birlikte çözmesi olduğu belirtiliyor. Tersine, karmaşıklığı azaltma girişimlerinin ise her zaman başarısız olduğu değerlendirmesi yapılıyor.
“Mimarileme en değerli beceri ama AI'ın yerini alamayacağı alan” iddiasına karşı, AI'dan açıkça sistem mimarisi tasarlaması istendiğinde gerçekte karşılaşılan tasarımcıların en az %30'undan daha iyi sonuçlar verdiği sıkça görüldüğü söyleniyor. Sorunun, AI kullanıcılarının bu tür isteklerde pek bulunmaması olduğu ileri sürülüyor.
Mevcut LLM'lerin eğitim verisinde çoğunlukla orta seviye (
best practice) cevaplar bulunduğu için, doğal olarak insan tasarımcıların alt üçte birlik kesiminden daha iyi; yani sağduyuya dayalı “makul” tasarımlar ürettikleri görüşü var. Buna karşılık eğitim verisinde olmayan tamamen yeni alanlarda ya da yüksek performans gerektiren sektörlerde insanın “ilk ilkelerden düşünme” yeteneğine daha çok ihtiyaç duyulacağı, LLM'in tasarladığı bir DB kernel'inin de yenilikçi olmaktan çok temel düzeyde kalacağı tahmin ediliyor.Yazının kendisinin ChatGPT ile yazılmış gibi görünen o tipik stile sahip olduğu eleştiriliyor: kısa cümleler, tekrarlar, “X değil X+1”, “X değil karşıtı-X” türü ifade oyunlarının aşırı kullanılması. HN'de böyle yazıların çok upvote almasına da şaşırılıyor.
Yazarın aslında kendi becerisini (architecting) değişmez ve yerini doldurulamaz sanmasından kaynaklanan bir “wishful thinking” içinde olduğu yorumu yapılıyor. Eğer başka bir yeteneği çok güçlü olsaydı, bu kez de onu vazgeçilmez göreceği söyleniyor.
Mimarın özünün, gereksinimleri ve kısıtları doğru anlayıp sisteme yansıtabilme yeteneği olduğu; yani iyi prompt yazabilmek, verilen cevabı dikkatlice okuyabilmek ve gerektiğinde güçlü biçimde itiraz edebilmek olduğu özetleniyor.
Gerçek hayatta karşılaşılan “mimarların” önemli bir kısmının, aslında IT altyapısında derin uzmanlığı olmadan sadece çizim aracı veya Excel kullanmayı yeterli sandığı; yönetici gibi göründükleri ama işin özünü gerçekte ancak az sayıda kişinin yerine getirebildiği söyleniyor.
AI'a “aşırı” bağımlı şirketlerin, ironik biçimde inovasyon dalgasına karşı daha savunmasız hale gelebileceği görüşü dile getiriliyor. AI çağında asıl önemli olanın kod üretkenliği değil, kod kalitesini yönetmek olduğu; ancak piyasanın otomatik kod üretimine fazlasıyla odaklandığı söyleniyor. Satya Nadella'nın “MS kodunun %30'u AI tarafından yazılıyor” sözünden bahsediliyor. GitHub'da ayda ortalama 20'den fazla olay/arıza yaşandığı da kanıt olarak veriliyor: githubstatus.com/history. Verimlilik peşinde koşarken kaliteyi düşürüp sonradan bunun bedelini ödeyecek şirketler olacağı; özellikle MS ölçeğinde olmayan küçük ve orta ölçekli firmaların çökme riski taşıdığı savunuluyor.
Buna karşılık, AI'ı görmezden gelen şirketlerin daha çok zorlanacağını savunan bir karşı görüş var.
“AI'ı aşırı kullanan şirketler uzun vadede daha büyük maliyet üstlenir” iddiası ve buna ilişkin bir yazı paylaşılıyor: AI: Accelerated Incompetence
“Kod bir varlık değil, borçtur” görüşüne %100 katılanlar var. Hedefin, amaca en az kodla ulaşmak olduğu; AI'ın ise kodu fazla kolay ürettiği için kod borcunu daha da büyüttüğü endişesi dile getiriliyor.
Teknolojik ilerlemenin üretkenlik paradoksuna ilişkin bir wiki bağlantısı da paylaşılıyor: Productivity paradox
Modern AI'ın kod ürettiği çağın, eskiden MS FrontPage ile web sitesi yapılan ve html'nin %90'ının gereksiz kodla dolu olduğu “cruft çağı”na benzediği benzetmesi yapılıyor.
Öte yandan, kod kolayca ikame edilebiliyorsa borç bakış açısının da anlamsızlaşabileceği; gelecekte hata olduğunda programcının AI'a kodu yeniden yazdırıp yükü azaltabileceği şeklinde ters bir bakış da sunuluyor.
Kodu yaratıcı ve sanatsal bir ifade biçimi olarak gören bir bakış da var. Okuması kolay ve zarif bir kod görüldüğünde güzelliğinin hemen hissedilebildiği deneyimi paylaşılıyor.
FORTRAN'ın ilk çıktığı dönemde (1954) bile “Fortran kodlama ve debug etme işini ortadan kaldıracak” sloganının kullanıldığını hatırlatan bir bağlantı paylaşılıyor: BackusEtAl-Preliminary Report
Bu tartışmaların tabanında, teknolojik ilerlemenin yakında sınıra dayanacağı varsayımının yattığı söyleniyor. Eğer bu varsayım yanlışsa, bir gün AI'ın tüm altyapıyı, logları, finansal verileri ve dokümanları kavrayıp işi bütünsel olarak anlayıp tasarlamasının da önünde bir engel olmayabilir. AI modelleri hâlâ büyüyor; yetenekleri artıyor ve ucuzluyor. Bu yüzden bir gün ikamenin özüne kadar ulaşılacağı görüşüne daha yakın duranlar var.
Geliştirici işten çıkarmalarının teknolojik ilerlemeden değil, belirsizliğe verilen bir reaksiyondan kaynaklandığı; teknoloji/AI gerekçesinin sonradan uydurulan bir mazeret olduğu görüşü de var. Örnek olarak, daha 5 yıl önce firmaların maliyetine rağmen daha fazla SW mühendisi alıp üretkenliği artırmaya çalıştığı hatırlatılıyor. Dolayısıyla asıl kök sebebin maliyet olmadığı savunuluyor.
"Geliştiricilerin yerini alacak" söylemi neden tekrar tekrar gündeme geliyor?
Yapay zeka vibe coding işini gözden geçirecek birini arıyorum; her şeyi zaten yaptım ama hata veriyor, şöyle ufakça düzeltiverin türü dış kaynak iş talepleri şimdiden çıkmaya başladı, oysa baştan yeniden yapmak daha hızlı olur.
Bunu ben de yaşadım; gerçekten korkunçtu...
Bilmeyen insanlar mı, yoksa umursamayan insanlar mı bilmiyorum ama her neyse, böyle çok kişi var...
Çeviride de durum aynı... AI işe yarar mı? Evet ama sanki birçok insanı zor durumda bırakıyor gibi...
İlk bakışta kulağa makul geliyor ama düzelten kişinin açısından bakınca iş daha da artıyor, hüzün hüzün
Ürpertici hahaha