AI, daha az değil daha fazla mühendislik disiplini gerektiriyor
(charitydotwtf.substack.com)- Yapay zeka kod üretim kalitesinin yükselmiş olması, kod incelemesini bırakma sinyali değil; kodun ucuz ve hızlı biçimde yeniden üretilebildiği bir ortamda doğrulama ve operasyon disiplininin daha da güçlü olmasını gerektiriyor
- 2025 sonlarında Opus 4.5 sonrasında yapay zeka, en azından yaygın örüntülerde, orta seviye bir yazılım mühendisine yakın kalitede kodu daha hızlı ve daha ucuza üretebilir hale geldi; agentic harness, araç kullanımı, function calling ve MCP bu dönüşümü destekliyor
- Kod üretim maliyeti neredeyse sıfıra yaklaşırken, kod satırları özenle korunacak değerli bir varlık olmaktan çıkıp, mevcut anlayışın maddileştirilmiş yeniden üretilebilir bir önbelleğine daha yakın hale geliyor
- Immutable infrastructure nasıl çalışan sunucuları yerinde düzeltmek yerine değiştirmeyi mümkün kıldıysa, yapay zeka çağında uygulama kodunda da değişikliğin kendisinden çok davranış doğrulaması, characterization test, capture/replay, trafik bölme ve gözlemlenebilirlik önem kazanıyor
- Deterministik olmayan sistemler, insanların kalite kapısı olarak dayanmasına kıyasla trace, production eval ve hızlı geri bildirim döngüleri gibi mühendislik disiplini gerektiriyor; yapay zeka, yazılımın hâlâ teknologlara ve disipline ihtiyaç duyduğu gerçeğini ortadan kaldırmıyor
2025'te tersine dönen kod üretim ekonomisi
- 2025'in büyük bölümünde, yapay zeka tarafından üretilen kodun “slop” olduğu ve öyle kalabileceği yönündeki görüş makul ve ana akım bir değerlendirmeydi
- 2025 Kasımında Opus 4.5 sonrasında yapay zeka, en azından yaygın örüntülerde, orta seviye bir yazılım mühendisine benzer kalitede kodu çok daha hızlı ve ucuz biçimde üretebilir hale geldi
- Opus 4.5 tek bir neden olmaktan çok bir eşik noktasına daha yakın
- agentic harness, LLM'i araçlarla birlikte bir döngüye sokan kod yapısıdır
- Bu tür harness'ler 2025 ortasında gerçekçi bir forma ulaştı ve ilk işaretleri 2024 sonuna kadar uzanıyor
- tool use, function calling ve MCP, 2025 boyunca birikerek yıl sonunda genel amaçlı kullanılabilirliğe dönüştü
- İlk değişimde “görürsem inanırım” türü bir şüphecilik hoş görülebilirdi, ancak aynı hızda bir değişim yeniden ortaya çıkarken aynı tavrı sürdürmek zor
Kod, değerli bir varlıktan yeniden üretilebilir bir çıktıya dönüşüyor
- 2025'te yaşanan temel değişim, kod üretiminin ekonomisinin tersine dönmesiydi
- Kod üretmenin zor, uzun süren ve pahalı olduğu durumdan, fiilen anlık ve ucuz olduğu bir duruma geçildi
- Kod satırları yeniden kullanılıp özenle korunacak bir şey olmaktan çıkıp, atılabilir ve tekrar üretilebilir bir şeye dönüştü
- Yazılım mühendisliği ekiplerinin gerçek çıktısını paylaşılan anlayış olarak gören bir bakış da var
- Bu anlayış, insanların zihninde bir önbellek gibi tutulur; GitHub commit'leri ve production deploy'ları ile diske yazılır
- Ancak insan hafızası unutkandır, tekrara karşı duyarsızlaşır ve küçük ayrıntıları kaçırmaya yatkındır
- Zihinsel modeller, kullanıcıların gerçekten karşılaştığı dünyadan sürekli sapar
- SRE bakış açısından iyi yazılım ekiplerinin gerçek çıktısı production'dadır
- “Only prod is prod”
- Production, geliştirmeden sonraki bir yer olarak değil, geliştirmenin bir aşaması olarak ele alınmalıdır
Phoenix Architecture ile immutable infrastructure arasındaki benzerlik
- Honeycomb, 2025 Ağustosunda bir AI mandate yayımladı ve bir devtools şirketi olarak en yeni teknolojinin zor problemlerini ele alması gerektiğine karar verdi
- Chad Fowler'ın Phoenix Architectures, yapay zeka kod çağını immutable infrastructure ile ilişkilendiriyor
- Chad Fowler, 2013'te “immutable infrastructure” ifadesini ortaya atan kişi
- Relocating Rigor, Martin Fowler'ın Thoughtworks meetup özetinde değindiği yazı
- The Death and Rebirth of Programming yazısının özü, çalışmakta olan şeyi düzeltmeyip değiştirme ilkesi
- immutable infrastructure, stateless services, containers, blue-green deployments ve infrastructure as code aynı varsayımı paylaşır
- Yapay zeka bu varsayımı altyapıdan uygulama koduna genişletiyor
- Yeniden yazma maliyeti düştükçe yerinde düzeltme daha riskli hale gelir, mutation entropi biriktirir, replacement ise bunu sıfırlar
- The Deletion Test, tüm implementasyonu sildiğinizi hayal etmeyi öneriyor
- Silmenin korkutucu olmasının nedeni kodun kendisinden çok, gerekli davranışın ne olduğunu, hangi başarısızlıkların kabul edilemez olduğunu, hangi değişmezlerin her zaman korunması gerektiğini ve yeni sürümün doğruluğunun nasıl değerlendirileceğini bilmemektir
- Unutulmuş edge case'leri düzelten bug fix'lerin ne olduğunu bilmemek de aynı sorundur
- Bu bir kod problemi değil, bir değerlendirme problemidir
- Kod, bilginin yaşadığı tek yer olduğunda değerli hale gelir
- Geçmişte darboğaz kod üretme emeği olduğu için, kodu kalıcı bir varlık gibi ele almak makuldü
- Yeniden üretim kolaylaştığında kod, şu anda yararlı ama eskidiğinde atılabilir bir anlayışın maddileştirilmiş görünümü gibi çalışır
Sunucuları yeniden ürettiğimiz gibi kodu da yeniden üretebilmeliyiz
- El işçiliğiyle bakım yapılan server pet'lerden immutable infrastructure cattle modeline geçiş deneyimi, mutability'nin anlayışın düşmanı olduğu dersini verdi
- Çalışan çıktıları yerinde düzeltmek drift yaratır
- Drift, sistem bakımını zorlaştırır
- Honeycomb her salı günü bir cron ile en eski Kafka düğümünü öldürüyor
- Bu yaklaşım sayesinde bootstrapping ve balancing süreçlerinin tekrarlanabilir olduğundan emin olabiliyorlar
- Veri yeniden üretilebilir; önemli olan taahhütler başka yerdedir
- Kodu da aynı şekilde yeniden üretemiyorsanız, bu o kodu yeterince anlamadığınızın işaretidir
- Hangi taahhütleri verdiğinizi bilmiyorsunuzdur
- Hangi bağımlılıkların kırılacağını bilmiyorsunuzdur
- Çoğunu ancak kırarak keşfedersiniz
- Uzun süren ve sancılı migration'lar, rewrite'lar, legacy code değişimleri ve strangler fig, kod satırlarının fazla sorumluluk üstlendiği örneklerdi
- Kodun içinde geliştirici niyeti, kullanıcı beklentisi, örtük ve açık davranışlar ile geçmiş bug'ların izleri birbirine bağlanmıştı
İnceleme konusu yalnızca kod satırları değil
- Kod satırlarını sürdürmenin ve değiştirmenin maliyeti yüksek olduğu için diğer çıktılar yeterince gelişemedi
- Mimarinin nasıl değiştiğini anlamak ve tartışmak için yeterli çıktı yok
- Çoğu zaman mimarinin kendisi bile koddan silik biçimde çıkarımlanıyor
- İdeal yön, mimari diyagramları tartışıp üzerinde uzlaşmak ve ardından bu değişimden kodu yeniden üretmeye daha yakın
- Tüm kodların insan anlayışını baypas ederek yapay zeka tarafından spesifikasyona göre üretileceğini varsayamayız
- Olasılık alanının tamamı, spec'in ne olduğuna ya da ne olabileceğine bağlı
- Acı verici bir veritabanı migration'ı yaşamış olanlar, kullanıcı beklentilerini yeniden oynatılabilir ve otomatikleştirilebilir bir biçimde çıkarmanın ve biçimselleştirmenin zor olduğunu bilir
- Araçlar henüz yok ama ilgili fikirler zaten var
- Operasyon ve QA'dan gelen behavioral test, characterization test, capture/replay ve traffic splitter buna örnek
- Bu teknikler, neyin doğru olması gerektiğinden çok gerçekte ne olup bittiğini gözlemlemeye ve kodlamaya yakındır
- İyi anlamdaki observability de buna dahildir
İnsanlar doğrulama amaçlı kalite kapısı olmaya uygun değil
- Production'daki deterministik olmayan kod, aslında daha önce yapılması gerekenleri zorunlu hale getiriyor
- trace enstrümantasyonu
- production ortamında test ve eval
- production'ı geliştirme sonrası değil, geliştirmenin bir aşaması olarak ele alma
- İnsan beyni doğrulama için uygun değildir
- Tekrarlayan ve küçük farkları sürekli kontrol etmede makineler kadar iyi değildir
- İnsanın rolünü yalnızca kalite kapısı yeteneğine indirgerseniz, yazılım kalitesi kırılgan hale gelir
- İnsanlar yaratıcılık, ilham ve mantıksal sıçramalar gibi alanlarda uzun süre önemli kalabilir; ama validation alanında makineleri yenen taraf olarak konumlandırmak zordur
Yapay zeka çağının sonucu disipline dönüş
- Son iki yılın AI söyleminin birçok mühendise yabancı ve korkutucu gelmesinin nedeni, bazı AI seslerinin yazılımın artık bir mühendislik problemi olmadığını söylüyor gibi görünmesiydi
- “SaaS is dead”
- “Making AI great at coding was the strategy that unlocks everything else”
- Adam Jacob, yazılım işlerinde büyük değişim bekleyen biri olarak anılıyor
- 2025 vibe coding yılıysa, 2026 disipline dönüş yılı gibi görünüyor
- Yapay zekanın orta seviye bir yazılım mühendisi kadar kod satırı üretebilir hale gelmesi, mümkün geleceklerin aralığını istikrarsız biçimde genişletti
- Zihindeki bilgi, sisteme kodlanana kadar yapay zeka tarafından kullanılamaz
- Hızlı ve kısa geri bildirim döngüleriyle çalışan yazılım ekipleri çok az
- Oran yaklaşık %5, kesin olarak %10'un altında diye sunuluyor
- Yapay zeka araçları bu çalışma biçimini eskisine göre daha ulaşılabilir hale getirebilir
- Mühendislik disiplini olmadan yalnızca yapay zekayla devasa yatırım getirisi yaratılması, yakın vadede endişe edilmesi gereken bir durum değil
- Birçok ekip bunu deneyecek, ancak değerli olan şey disposability değil durability tarafından desteklenendir
- Kullanıcılar her gün Slack'e giriş yaptıklarında düğmelerin ve menülerin hafifçe değişmesini istemez
- Finansal işlemlerin yalnızca çoğu durumda tamamlanmasını da istemez
- Determinizm ortadan kalkmaz
- Yapay zeka sihir değildir ve yazılım hâlâ mühendisliktir
- Teknoloji, teknologlara ihtiyaç duyar
- Bundan sonra incelenmesi gereken çıktılar yalnızca kod satırları değil, başka tür mühendislik çıktıları da olacaktır
1 yorum
Hacker News görüşleri
Artık kimin sistemi anlayıp AI'yi etkili kullandığını, kimin hiçbir şey bilmeden sadece LLM kopyala-yapıştırı saçtığını ayırt etmek çok daha zorlaştı
2025'ten önce düşük performans gösteren ya da sadece idare eden kişiler, katkıları az olduğu için nispeten görünür olurdu; şimdi ise tüm mühendisler makul görünen PR'lar, kod incelemeleri, teknik tasarım belgeleri vb. döküyor
C-seviyesi yöneticilerin AI'yi azami ölçüde kullanma yönündeki sert baskısının etkisi büyük ve her mühendis açısından da mümkün olduğunca çok üretmenin avantajlı olduğu oyun teorik bir tepki bu
Makul görünen belge ve kodların içinde tamamen boğuluyoruz ve bu hacmi işlemek için tekrar AI'ye bel bağlıyoruz
Bu dönemin artçı etkisi, ölçek açısından özellikle belirgin olan tuhaf bir teknik borç biçimi olacak gibi görünüyor
LLM'ler çok üretmeyi ve bir şeyler eklemeyi sever ama gerçekten yetkin mühendisler daha az kod ve daha az hareketli parçayla daha fazla iş sonucu üretir
Sık sık “Bir süreci otomatikleştirmek için AI kullanmak istiyorum ama süreç dokümantasyonu eksik, bu yüzden AI'nin yardım etmesini umuyorum” sözünü duyuyorum
Hiçlikten sonuç üretilemeyeceğini anlatsanız da tüm AI tartışmaları sonunda yine aynı yere dönüyor
O AI otomasyonuna koyulacak dokümanları üretme çözümü de AI kullanmak olunca, AI ile doküman üretip AI ile özetleyip AI'nin açıkladığı bir ouroboros ortaya çıkıyor
Kodda da aynısı olacak; AI ile binlerce satır üretilecek, sonra yine AI ile açıklanacak
Bugünlerde LLM sayesinde sadece katkı miktarına bakıldığında çalışkan görünmek fazlasıyla kolay
Fark şu ki artık yetersiz biri, dikkatli ve deneyimli bir mühendisten kelimenin tam anlamıyla birkaç basamak daha fazla çıktı üretebiliyor
PR kusursuz bir geçit değil ama şu anda sahip olduğumuz neredeyse tek geçitlerden biri ve kimin çaba gösterdiği, kimin göstermediği epey net
Mülakat aşamasındaki algoritma soruları sistem bilgisine sahipmiş gibi yapanları tamamen elemiş olmalı, değil mi?
“Bu bir kod sorunu değil, bir değerlendirme sorunu”, “Kod ancak bilgi yalnızca kodun içinde yaşadığında kıymetli olur” sözlerine katılıyorum
Tüm gün AI'nin yazdığı kodu okumak acı verici ve insanın en yetkin olması gereken anlarda beyni eriten korkunç bir yöntem
Elle programlamada; kodu okuyup yazdığınız, derlenene, çalışana ya da istediğiniz davranışı gösterene kadar düzelttiğiniz üretken ve tatmin edici bir geri bildirim döngüsü vardır
AI kodu bunun yarısını devralmakla kalmıyor, sondaki o “klik” anını da daha az tatmin edici hale getiriyor. Çünkü o ana ulaşmak için bir yerlerde biraz hile yapılıp yapılmadığından emin olamıyorsunuz
AI tarafından üretilen kodu programlamanın tek kalıcı çıktısı yapmak, sektör için bir çıkmaz sokak
Charity'nin ilginç bir çalışma alanı olarak işaret ettiği ve doğru şekilde atılması gereken şey mimari diyagramlar ve spesifikasyonlar
Benim şüphem, bunun daha çok insanların bizzat yazdığı prompt'lara, Markdown planlarına ve yönlendirici metinlere yakın olduğu yönünde
İnsan olarak doğrudan ürettiğimiz şeye odaklanmak, “AI talimatlarımı izledi mi?” temel döngüsünün zeminini oluşturur ve kod incelemesinde de daha yüksek kaldıraç sağlar
PR aşamasına gelindiğinde Claude'a yeterince girdi verip kodu yeniden ürettirebilirsiniz ama sektörün bugünkü varsayılanı, o oturumun tamamını çöpe atıp yalnızca kodu dağıtmak. Bu ters bir yaklaşım
Büyük kod yığınları insanlar tarafından fiilen incelenemez ama işin içine LLM girince birçok kişi bunu unutuyor gibi görünüyor
Her gün incelemem için devasa kod yığınları geliyor ve gerçekten bunaltıcı
Yine de AI'nin daha iyi geldiğini düşündüren şey, kuralları yazdığınızda en azından onlara uyma eğiliminde olması
Offshore geliştiricilerin önemli bir kısmı aynı hataları her gün tekrarlıyor
Galiba şirketimizin daha iyi offshore geliştiriciler işe alması gerekiyor
Eskiden kodlama yoluyla kurduğum sistem zihinsel modelinin bir kısmını artık kod incelemesine dayanarak oluşturuyorum
Sistemin ayrıntılarını anlamak ve hatırlamak zorlaşıyor; bizzat “ürettiğiniz” bilginin sadece okuduğunuz bilgiden daha iyi hatırlandığını düşünürsek bu şaşırtıcı değil
Eğitim biliminden çıkarılan dersleri kod incelemesini genişletmeye uyguluyorum; bu size anlamlı geliyorsa konuşmak isterim
Geçici bir çözüm olarak Claude'dan oturum özetini commit mesajının bir parçası olarak yazmasını isteyebilirsiniz ama daha yapılandırılmış ve daha yüksek seviyeli bir araç olup olmadığını bilmek isterim
İyi tasarlanmış bir plana uyan, doğrulanabilir kod istiyorsanız fiilen sözde kod yazıp bunu AI'ye çevirtmeniz gerekir
Durum buysa, en başta neden AI'ye kod yazdırdığımız sorgulanmalı
Şahsen planlamayı, yazmayı ve hata ayıklamayı kendim yapmayı daha eğlenceli buluyorum. Zaten programlamayı sevmemi sağlayan şey de buydu
Son zamanlarda bunu gerçekten çok düşünüyorum
Yazılım geliştirmeye dair sezgilerimin önemli bir kısmı, 25 yıl boyunca “bir kodu yazmanın ne kadar sürdüğü” üzerine biriken deneyime dayanıyor
Her şeyi bozmayacak ama biri basarsa biraz dağınık hale gelecek bir edge case doğrulamasını ekleyip eklememeyi düşünürken, birkaç saat daha kod yazmak gerekecekse bunu atlayabilirdim
Ama tek bir prompt yeterliyse neden yapmayayım?
Yeni bir özelliği anlaşılır kılmak için özel bir API gezgini iyi olurdu ama eskiden bu yatırımın gerekçesini göstermek mümkün olmazdı
Ama Codex ile 10 dakika sürüyorsa durum değişiyor ve gerçekten de öyle oldu: https://tools.simonwillison.net/datasette-extras-explorer#ur... sürüm notlarında da bağlantı veriliyor https://docs.datasette.io/en/latest/changelog.html#extra-sup...
Daha büyük ölçekte, eskiden hiç düşünmediğim projeler de var. Özel bir SQLite SELECT sorgu ayrıştırma kütüphanesine ihtiyaç vardı ama buna bir haftadan fazla harcamaya değmezdi
Ama şimdi mümkün: https://github.com/simonw/sqlite-ast
İnsanlar, daha hızlı kod satırı üretebilmenin değerli olduğunu söylersen buna çok öfkelenip tepeden bakabiliyor
Elbette çıktıyı “kod satırı sayısı” ile ölçmek aptallık
Ama değer sunan, doğrulanmış kod satırlarının sayısını ölçmek aptallık değil ve artık bunu daha hızlı yapabiliyoruz
Google’ın değerli olmasının nedeni veriyi içine çekip reklam geliri üretmesi ve harcamasının gelirine kıyasla düşük olması
O kadar çok “bahis” vardı ya? Komik, peki ne oldu onlara?
Mühendislik uğruna mühendisliğin ekonomi için hiçbir değeri yok, yani anlamsız
Kimsenin duymak istemediği acı gerçek şu ki, herhangi bir andaki ekonominin içinde var olabilecek şeyler sınırlıdır; yalnızca değerli ve ekonomik olarak sürdürülebilir olanlar hayatta kalır
Umursamayan çok kişi var ama umursayanlar da var
Bu yazıyı beğendim ve diğer birçok yorumun öyle düşünmediği anlaşıldığı için ben de kendi görüşümü yazayım.
Yeni bir kod tabanına başlarken mümkün olduğunca hızlı şekilde faydalı bir katkı sağlayan kişi nasıl olunur? Ben doğrudan insanlarla konuşmaya ve insanlar tarafından yazılmış belgelere giderim.
Bu sistemin başlangıçta çözmeye çalıştığı sorunun ne olduğunu, ilk tasarımın ne olduğunu, en büyük sorunun ne olduğunu ve şu anda kimlerin kullandığını kontrol ederim.
Bunları bilirsem neden o şekilde yapıldığını tahmin edebilirim; bu da kodu okumayı çok daha kolay hale getirir.
Bu blog yazısı da ilgi gördü: https://blog.gpkb.org/posts/just-send-me-the-prompt/
Charity, çok eski bir probleme bakıp yeni teknolojinin bir tür yeni çözüme yol açmasını bekliyor gibi görünüyor.
Muhtemelen mevcut nesil araçların, yapay zeka destekli yazılım geliştirme hikâyesinin sonu olduğunu düşünmüyordur.
Söylediği şey de tasarım dokümanlarını Claude code'a atıp gitmek değil. Tasarım dokümanları da eksiksiz değildir; bu yüzden onboarding sırasında insanlarla konuşmanız, eski ticket'ları ve postmortem'leri de okumanız gerekir.
Production'da altyapının neden bugünkü haline geldiğini anlamanın zor olmasından hoşlanmadığımız için artık Infrastructure as Code yapıyoruz.
Kod tabanlarının da varsayılan durumu aynı şekilde “neden bugünkü haline geldiğini anlamanın zor olması”dır; bu da “Programming as Theory Building”den önce de gözlemlenmiş bir sorundu.
Bu yüzden, altyapıda olduğu gibi yazılım geliştirmenin de “kodun neden bugünkü haline geldiğini” daha net hale getiren araçlar etrafında değişmesini bekliyor gibi görünüyor.
Yeni bir kod tabanına girerken önce insanlarla konuşup insanlar tarafından yazılmış belgelere bakmak doğru yaklaşım, ama birçok mühendislik ekibinde böyle belgeler hiç yok.
Kararlar ya bir mühendisin kafasının içinde alınıyor ya da kaydedilmeyen sohbetlerde veriliyor; spesifikasyonlar ise ya temizlik sırasında silinmiş ticket'lardaki birkaç satır nottan ibaret oluyor ya da takip aracı değişirken kayboluyor.
Kod tabanının ya da özelliğin bir haritası yok, ADR yok, observability neredeyse yok.
Geriye sadece kod kalıyor; neler olduğunu anlamak için kodu okumanız ve yakın zamanda o alana commit atmış mühendise bunu neden öyle yaptığını hatırlayıp hatırlamadığını sormanız gerekiyor.
Biri bir değişiklik yaptığında, tamamen alakasız sandığı kod tabanının öbür ucu bile kırılabiliyor.
Yapay zeka için daha fazla disiplin gerektiği doğru, ama teoride bu disiplin, iyi bir mühendis olmayı öğrenmekten çok daha kolay öğrenilebilir.
20 yıl önce iyi, ölçeklenebilir C kodu yazmak için ya dahi olmanız ya da teknolojiye gerçekten adanmış olmanız gerekirdi.
ASan, LSan, UBSan, TSan, GDB gibi sayısız aracı avucunuzun içi gibi bilmeniz gerekirdi; bir de DWARF dosyalarını doğrudan okumak zorundaysanız daha da beterdi.
Bunlarda kısa sürede ustalaşmak pratikte zordu; bir yandan da sistem tasarımı öğrenmeniz gerekiyordu ki bu da neredeyse ona dik, ayrı bir yetenek alanıydı.
Artık yapmanız gereken, kullandığınız dilin ve framework'ün risk noktalarını bilmek, LLM'e bunları test etmesini söylemek, yeterince test edilip edilmediğini doğrulayacak altyapıya sahip olmak ve gerçek testlerle implementasyonu okumak.
Rust kodunu okuyup anlamak, Rust geliştirirken çıkan büyülü hata mesajlarını debug etmekten çok daha kolay.
Belirli bir senaryoda Loom testi gerektiğini fark etmek ve bunun gerçekten yazılıp yazılmadığını tespit edecek bir araç yapmak da daha kolay.
C ya da Zig kullanmaya devam etseniz bile, her aracı tek tek öğrenmektense onları ne zaman kullanmanız gerektiğini bilmek ve bunu tespit etmek çok daha kolay.
SQL okumak zor değil; iş dünyasındaki insanların neredeyse yarısı da bunu yapabilir. Python yalnızca biraz daha zor, Rust da 50 sayfalık bir okuma kılavuzuyla anlaşılabilir; bunu deneme-yanılmayla 10 yıl harcamanın maliyetiyle kıyaslayınca bu çok küçük bir bedel.
“LLM'ler bilinemez şekillerde çalışıyor”dan “o halde daha fazla disiplin gerekir”e, oradan da “o zaman her şey yolunda”ya giden yol bana net görünmüyor.
Her şeyin yolunda olduğu sonucuna katılıyorum ama bu düşünce zincirinin açık bir güzergâh sunduğunu düşünmüyorum.
Eğer bunu gerçekten çalışır hale getirmeye niyetliyseniz ve neyin başarısızlığa yol açtığını anlamaya biraz zaman ayırıyorsanız, LLM'leri kullanarak inanılmaz işler başarabilirsiniz.
LLM'ler karmaşık şeyler üretmenin maliyetini neredeyse sıfıra indirdiği için, aslında durumu çok daha karmaşık hale getirecekler.
Mühendislik her zaman disiplin ve bir şeyi çalışır hale getirme işiyle ilgiliydi, ama eskiden değerli olabilmek için önceden sahip olunması gereken bir teknik beceri yığını gerekiyordu.
Bunun büyük kısmı artık ortadan kalktı ve her şey eskisine göre çok daha kolaylaştı.
Disiplin hâlâ gerekli, ama ateşin içinde 10 yıl yuvarlanmakla kıyaslayınca disiplin ucuzdur diye düşünüyorum.
Az önce yaklaşık 200 satırlık şu PR'ı incelemek için bir hafta harcadım: https://github.com/ncruces/wasm2go/pull/37
Bunu deneyimli bir kullanıcı göndermişti ve büyük ihtimalle en ileri LLM'lerden birine de danışmıştı.
Buna rağmen bir şeyler yanlış hissettirdi. Anlamadım ve anlamadan merge etmeyi de düşünmedim.
Hatta ileride sorun çıkaracak şekilde hatalı olduğundan da şüphelendim.
Bu yüzden dört farklı şekilde inceledim: anlamaya ve iyileştirmeye çalışmak, daha iyi bir algoritmayla yapmak, sorunu upstream'de düzelterek bundan kaçınmak ve bunu benim zihnime uygun biçimde baştan yazmak.
Cevabın ikinci ya da üçüncü seçenek olacağını sanıyordum; ama ikincisi doğru cevap olsa da onu kullanmak için projeyi baştan yapmak gerekiyordu, üçüncüsünün gerçekten işlemesini çok istedim ama işlemedi.
Sonunda birinciyle dördüncüyü karıştırmak zorunda kaldım; hâlâ tamamen emin değilim ama artık sorunu da çözümü de anlıyorum.
Benim yaklaşımımın daha iyi olduğunu düşünmem elbette doğal.
Yine de her iki tarafın da yorumlarını kaldırıp bir LLM'e review yaptırdım.
LLM, orijinal PR'ın açıkça daha iyi olduğunu söyledi; ben neden öyle olmadığını açıklayınca bu kez benim haklı olduğumu söyledi.
Yorumları ekleyip tekrar denediğimde LLM'ler benimkinin daha iyi olduğunu söylüyor. Çünkü gerçek sorunu ben buldum.
Ama bunun, gerçekten daha iyi olduğu için mi yoksa ben onu öyle söylemeye yönlendirdiğim için mi öyle dediğini bilmiyorum.
Yazıyı okuyunca, “bütün modeller yanlıştır” özdeyişinin unutulmuş gibi geldi
Bu, “gerçekçi” “simülasyon” RPG sevenlerin sık yaptığı bir hata da sayılır
Bir şeyi yeterince kapsayıcı biçimde modellerseniz, o model artık doğrudan şeyin kendisi olur
Gerçek bir yerin tüm ayrıntılarını içeren bir konum modeli yapmak için 1:1 ölçekli bir model gerekir; bu da sonuçta o yerin bir kopyasıdır
Bir sistemin işlevlerinin %100’ünü güvenilir biçimde yeniden üretecek kadar ayrıntılı bir plan, yani modele verilecek prompt, muhtemelen o sistemin kaynak kodunun kendisidir
BT ve programlamanın büyük kısmının aslında iyi anlaşılmış parçaları birleştirmekten ibaret olup olmadığını sık sık merak etmişimdir
8 yıl önce, LLVM’i çok daha basit bir sistemle değiştirip elle yapılan optimizasyonu basit bir yapay zeka “optimizer”ıyla neden değiştiremeyeceğimizi düşünmüştüm
Basit derlenmiş kodu “optimize edilmiş” koda dönüştürmesi için eğitmenin yeterli olacağını sanmıştım ama o dönemki fikir birliği, yapay zeka sistemlerinin kullanılabilecek kadar güvenilir biçimde doğru kod üretmesinin zor olduğu yönündeydi
Yapay zeka böyle düşük seviyeli kodu bile ikame edemiyorsa, yüksek seviyeli sorunların doğal olarak çok daha uzakta olması gerekirdi
Ama insanlar yapay zekayı yüksek seviyeli sorunlarda kullanıyor
Benim hipotezim, modern dijital mühendisliğin büyük bölümünün plug and play olduğudur
2023’ten önce HN’de herkesin, kod satırı sayısını azaltmayı en güçlü kıdemli göstergesi diye yere göğe sığdıramadığını hatırlıyorum
Sadece, LLM kaynaklı kod satırı seline karşı yüzme yarışını kazanmak için akıntı fazla güçlü
Ayrıca LLM’lerin iyi kod yazabildiği yönündeki yazı varsayımına da katılmıyorum
Çalışan kod yazıyorlar ama sanki Demogorgon yazmış gibi görünüyor; bakınca insanın midesi bulanıyor
Kötü, ama bir insanın asla yazmayacağı türden kötü
Yeni başlayan bir geliştiricinin yazdığı spagetti kodu okurken duyulan rahatsızlıktan farklı; daha çok karnınızın bir yerinde Cthulhu’nun yumurtası çatlıyormuş gibi bir iğrençlik
Eski çalıştığım şirkette bir kıdemlinin, işe girdikten yönetici olana kadar sadece kod sildiğini hatırlıyorum
Bu yazıyı okumak eğlenceli değildi
Cümlelerin kendisi ve her paragraf ayrı ayrı fena değildi ama bütün olarak dağınıktı ve cüretkâr olacak ama anlamsızdı
Gerçekten çok fazla kelime vardı ama aslında söylenen şey çok az gibiydi
Mesela 2025’te kod üretiminin ekonomisinin tersine döndüğü ifadesi doğru değil
Eskiden üretim süreci 3D baskı gibi katı biçimde eklemeliyse, şimdi olsa olsa CNC frezeleme gibi çıkarma odaklı bir yaklaşımın eklenmesi söz konusu
Gereken “şekil” pek değişmedi ve belli toleransları önemsiyorsanız gereken insan emeği de değişmedi
Piyasanın talep ettiği ölçüde ürünleri hâlâ önemsemek, yeniden kullanmak, bakımını yapmak ve kürasyonunu yapmak gerekiyor
“Kod satırları inceleme için ideal çıktı değildir” sözüne de katılmıyorum
Burada “ideal” ne demek?
Küçükken tüm sınavlarda kural “çözüm yolunu göster”di
Bunun nedeni sadece yarın çıkacak ürünü değil, gelecek neslin zihinsel modellerini ve düşünme süreçlerini de iyileştirmek istememizdi
Dili takip etmek gerçekten zordu ve yazının ana fikri de belirgin değildi
Böyle yazılar görünce yazılım mühendisi işlerinin yok olacağı iddiasına daha da şüpheyle yaklaşıyorum
2026’daki yazılım mühendisliği işi 2020’dekinden farklı, 1990’dakinden bahsetmeye bile gerek yok; o halde neden 2026’daki işin ya aynen kalacağına ya da tamamen ortadan kalkacağına dair bu sahte ikiliği kabul edelim?
Çok uzun zaman önce Google’da çalışırken tüm kodun review edilmesi fikri bana yeni gelmişti
Ondan önce MS’te kod CD’ye yazılıp kutuya konuyordu; bu yüzden çoğu şey, projenin sonundaki riskli ana kadar gözden geçirilmiyordu
2000 ile 2004 arasında yazılım mühendislerinin zamanını kullanma biçimi keskin biçimde değişti ve bunun, ortak anlayışı artırıp işbirliğini teşvik ettiği için daha iyi olduğunu düşünüyorum
Yapay zeka kod yazıp insanlar review’a daha fazla zaman ayırırsa, bu mutlaka kötü bir şey olmayabilir
Ama yapay zeka kodu yeterince iyi hâle gelirse, kapsamlı review isteğe bağlı görülmeye başlanacak
O zaman yazılım mühendisinin işi eskisine göre çok farklı olacak; ne çok kod yazacak ne de review’a çok zaman harcayacak
IDE’ler dodo kuşu gibi yok olabilir
Odak, yapay zeka kodlama ekibinin görevden sapmamasını sağlayacak hedefler ve test düzenekleri kurmaya kayabilir
Projenin nereye gittiğini iyi bilen yazılım mühendisleri mimariye daha fazla zaman ayırabilir. Çünkü hedef makul biçimde değiştiğinde yapay zekanın her şeyi baştan yazmasını istemezsiniz
Keşfe de daha fazla zaman ayrılabilir. Bir şeyi bir şekilde yapıp, başka bir şekilde yapıp, bir başka şekilde daha yapıp sonra karşılaştırmak ve farklı yaklaşımlardan yeni fikirler üretmek gibi
Kimseden daha iyi tahminlerim yok ama rolün ortadan kalkacağı fikrine güçlü biçimde karşı çıkıyor, daha önce defalarca olduğu gibi evrileceği fikrini destekliyorum. Yalnız bu kez belki hiç olmadığı kadar hızlı olabilir
“Koda kalıcı bir şey gibi davranmamızın nedeni, kod üretme emeğinin darboğaz olmasıydı” sözüne katılmıyorum
Koda kalıcı bir şey gibi davranmamızın nedeni, onu tek doğruluk kaynağı olarak görmemizdi
Bilgisayarlar dokümanı değil, kodu çalıştırır
Gereksinim dokümanı kodla çelişiyorsa, varsayılan yaklaşım gereksinim dokümanının yanlış olduğunu düşünmekti
Kodu spesifikasyondan ayıramazsınız. Çünkü kod spesifikasyonun kendisidir