Kod Yazmak Asla Gerçek Darboğaz Değildi
(ordep.dev)- Yazılım geliştirmede darboğaz, kod yazmak değil; kod inceleme, bilgi aktarımı, test, hata ayıklama, iş birliği/iletişim gibi çeşitli insan merkezli süreçlerde ortaya çıkar
- LLM sayesinde kod üretiminin kendisi çok kolaylaştı, ancak buna karşılık anlama, doğrulama ve güven için gereken maliyet ve yük daha da arttı
- Hızlı kod üretimi, inceleme yapanlar, entegrasyonu gerçekleştirenler ve bakım sorumluları için daha fazla yük yaratır; ekibin genel hızı da gerçekte artmaz
- Kodu anlama en zor kısımdır; LLM kod üretse bile, ekip içinde güven ve bağlam paylaşımı olmadan kalite garanti edilemez
- LLM; prototipleme ve otomasyonda güçlüdür, ancak yazılım geliştirmenin temeli olan dikkatli tasarım, inceleme ve paylaşılan bağlamı ikame edemez
Kod Yazımındaki Gerçek Darboğaz
- Uzun yıllardır kod yazma işi başlı başına yazılım mühendisliğinin darboğazı olmadı
- Asıl darboğaz; kod inceleme, mentorluk ve eşli programlama yoluyla bilgi aktarımı, test, hata ayıklama ve iş birliği/iletişim maliyetlerinde ortaya çıkıyor
- Bilet yönetimi, planlama toplantıları, çevik toplantılar gibi karmaşık süreçler hızı daha da yavaşlatıyor
- Kalite güvencesi için gerekli bu süreçler, gerçekte kod yazmanın kendisinden çok daha fazla zaman ve düşünce gerektiriyor
- Ancak LLM sayesinde çalışan kod üretmenin maliyeti sıfıra yaklaşıyor
- Buna karşın kodu anlama, test etme ve güven oluşturma maliyeti daha da yükseliyor
- İlk uygulama hızı arttı, ancak inceleme/entegrasyon/bakım kapsamına giren daha fazla kod oluştuğu için yük büyüyor
LLM İşin Doğasını Değiştirir – Onu Ortadan Kaldırmaz
- Claude gibi LLM araçları ilk uygulama hızını artırır, ancak sonunda daha fazla kodun daha kısa sürede sisteme girmesi nedeniyle inceleme ve bakım sorumluları üzerinde daha büyük bir yük oluşturur
- Bu yük özellikle şu durumlarda ağırlaşır
- Kodun yazarı, sisteme eklediği kodu gerçekten yeterince anlayıp anlamadığından emin değildir
- Üretilen kod, alışılmadık kalıplar kullanır ya da mevcut teamülleri ihlal eder
- Sınır durumları ve istenmeyen yan etkiler açık biçimde görünmez
- Sonuç olarak kod üretmek kolaylaşsa da, doğrulamanın zorluğu artar ve ekip genelinde gerçek hız artışı sağlanamaz
- Geliştiriciler arasında eskiden “kopyala-yapıştır mühendisliği” diye bir şaka vardı; LLM ile bu durum çok daha fazla büyüdü
Asıl Zor Olan Kodu Anlamak
> “Kodun en büyük maliyeti onu yazmak değil, anlamaktır”
- LLM sayesinde kod üretimi hızlansa da, davranışı akıl yürütmeyle çözümlemek, ince hataları bulmak ya da uzun vadeli bakımın güvence altına alınması asla kolaylaşmaz
- Özellikle incelemeyi yapan kişi, üretilen kod ile doğrudan yazılmış kodu ayırt edemediğinde veya seçilen çözümün nedenini kavramakta zorlandığında durum daha da güçleşir
Ekipler Hâlâ Güven ve Paylaşılan Bağlama Dayanır
- Yazılım geliştirme, özünde iş birliğini varsayar ve tamamen paylaşılan anlayışa, uyuma (alignment) ve mentorluğa dayanır
- Kod, tartışma ve inceleme hızından daha hızlı üretildiğinde ekip, gerçekte kaliteyi doğrulamamış olsa bile kalite zaten doğrulanmış gibi bir yanılgıya kapılabilir
- Bu da inceleyicilerin ve mentorların psikolojik yükünü artırarak, ekip genelindeki hızı yeni bir biçimde yavaşlatabilir
LLM Güçlüdür Ama Özünü Çözmez
- Hızlı prototipleme, scaffold ve otomasyon için LLM çok değerlidir; ancak net düşünme, özenli inceleme ve derinlemesine tasarım ihtiyacını ortadan kaldırmaz
- Kod yazmanın maliyeti düşmüş olsa da, ekibin kodu birlikte anlaması ve ona anlam yüklemesi için gereken maliyet değişmez
- Gerçek darboğaz hâlâ "anlama ve iş birliğinde"
7 yorum
Ben tam da bu yazıda anlatılan becerilerde eksiği olan ve LLM'e ciddi şekilde bağımlı bir geliştiriciyim.
Teknik bilgim yetersiz olduğu için AI olmadan WBS'ye uygun şekilde çalışmak zor bir durum ama...
En azından kıdemli geliştiricilerin review süresini azaltmak için benim ne yapmam iyi olur..?
Ek olarak kendi bilgimi de artırabilirsem güzel olur...
İnceleme süresini kısaltmak istiyorsanız, yazdığınız kodun hangi bağlamda ortaya çıktığı ve çeşitli uygulama yöntemleri arasından neden onu seçtiğiniz gibi konularda kararı kendiniz vermeli ve bunu açıklayabilmelisiniz. Bunun için 3.'ü hafta sonlarında ya da boş zamanlarınızda düzenli olarak yapmanız gerekir; ayrıca popüler kütüphaneleri veya başkalarının GitHub'a yüklediği kodları rastgele inceleyip kod yapısı ve uygulama tarzı gibi şeyleri analiz etmeniz faydalı olur.
Güzel sözleriniz için çok teşekkür ederim!!
Yine de personel azaltmalarına bakınca insanın içi kararıyor... 12 projeyi 4 kişi nasıl yapsın ki... Üstelik içlerinden biri bir yandan yönetim de yaparken...
Çok üzgünüm, gerçekten çok zorlanıyor olmalısınız.
Hacker News görüşü
Deneyimli bir mentor olarak, hırslı ama henüz olgunlaşmamış stajyerlere rehberlik ederken bir günde bir ya da iki haftalık kod ürettiklerini gördüm. Ama benim işim eskisinden daha da zorlaştı. Code review yaparken stajyerler yazdıkları kod üzerine yeterince derin düşünmediği için geri bildirimlerim onlara iyi geçmiyor. Basit bug’lar ya da ufak tefek sorunlar neredeyse ortadan kalktı ama geriye kalan problemler daha incelikli ve daha karmaşık; ayrıca açıklamaları da çok daha zor. Üstelik daha önce hiç görmediğim yeni tür bug’lar da çıkıyor. Dışarıdan düzgün görünen kod gerçekte hiç çalışmayabiliyor; tamamlanmış gibi duran şeylerin en temel kısımları bile bozuk olabiliyor. LLM ile çalışan junior’lar, basit ama konuşmaya değer kod sunmak yerine, birçok açıdan işbirliği ve bakım sorunları yaratan karmaşık kodu tek seferde bitmiş gibi üretmeye daha yatkın. Sonuçta bir PR’ı son kaliteye kadar cilalamaya yarayan geleneksel “kademeli iyileştirme” yaklaşımı artık düzgün çalışmıyormuş gibi geliyor. Geri bildirim verdiğimde, mevcut PR’ı düzeltmek yerine bambaşka bir yaklaşım getiriyorlar ve bu da çoğu zaman yeni sorunlar doğuruyor. Böyle olunca senior’lar, junior’lardan daha uzun süreyi bu tek PR’a harcıyor. Junior tarafı kendini çok üretken hissediyor olabilir ama senior reviewer’ların geri bildirimi giderek eskisi kadar sıcak ya da teşvik edici olmuyor. Sonuç olarak zorunlu tuttuğumuz çok sayıdaki test case bir nebze işe yaradı ama bu testler bile benzer sorunlar yüzünden sınıra dayanıyor
Bu tür “bitmiş gibi görünen ama hiç çalışmayan” kodu görünce, geçmişte yaşadığım 250 bin dolarlık yurtdışı yazılım geliştirme projesi aklıma geldi. Spesifikasyonlara bakınca her şey doğru gibiydi ama gerçekte tamamen tutarsız bir sistemdi. Belgedeki yorumlara takılıp sağduyusal kısımları kaçırdıkları için sonunda tüm projeyi doğrudan çöpe atmıştık. Şimdi bunun LLM sayesinde otomatikleşip bedavaya yaklaşmış olması etkileyici
Bu soruna tamamen katılıyorum. Kendi deneyimimde de LLM ile binlerce satır kodu çok hızlı üretebiliyorsun ama asıl zor iş code review, bug düzeltme, güvenlik açığı inceleme, refactoring ve gereksiz kodu kaldırma. Sonunda çoğu zaman doğrudan kendim kod yazmak daha verimli oldu. LLM’leri en gerçekçi biçimde otomatik tamamlama ya da basit parçalar üretmek için kullanmak mantıklı. Eğer junior araya LLM koyup sonra ben de onun üzerinden iletişim kuracaksam verim daha da düşer. Şu anda LLM ile daha üretken olduğunu düşünen insanlar, belki de aslında bu önemli işleri tamamen atladıkları ya da hiç önemsemedikleri için öyle hissediyor. Gerçekte ürün kalitesini önemseyen az sayıda kişi, devasa kod miktarını sırtlamak zorunda kalıyor. Bazen gereksiz yere zor insanlar gibi görülüyorlar ama aslında kullanıcıya en iyi ürünü ulaştırmaya çalışan asıl kahramanlar onlar. Net bir çözüm yok; hatta durumun daha da kötüleşeceği anlaşılıyor. Sadece LLM kullanarak yetişmiş geliştiriciler sektöre akmaya devam edecek ve araç şirketleri de abartılı pazarlamayı sürdürecek. Sonuçta kaliteyi koruma yükü daha da artacak
Senior’ların tek bir PR’a junior’lardan daha fazla emek harcadığı bu “effort inversion” durumunu ben de yaşıyorum. Benim durumumda PR yazarları blog yazısı ya da basın bülteni hazırlamak için AI kullanıyor; ama konu uzmanı olan ben çıktıyı alınca AI halüsinasyonlarını ve hatalarını düzeltmek için harcadığım süre 3-4 katına çıkıyor. Onların işi normalde beni desteklemekti, şimdi ben onlara yardım etmek zorunda kalıyorum. Üstelik AI halüsinasyonları her seferinde farklı olduğu için her defasında yeniden uğraşıyorum. Bunu yöneticilere de ilettim; böyle giderse gelecek yıl PR ekibinin yarısı ortadan kalkabilir. E-postayı kopyalayıp ChatGPT’ye yapıştırıp tekrar bana gönderecek bir role gerek yoksa bunu ben doğrudan yapabilirim
“Review sırasında verdiğim geri bildirim iyi aktarılmadı” kısmını biraz daha açabilir misin diye merak ediyorum. Ben de benzer bir sorun yaşıyorum; çözüm ya da içgörü varsa paylaşmanı isterim
Ben de şunu ekleyeyim: Önceki nesiller, refactoring ve unit test yoluyla yazılım yapısını ve tasarımını doğal olarak derinlemesine öğreniyordu. Ama ileride LLM unit testleri de üretirse, geliştiricinin “Benim gerçekten neye ihtiyacım var?”, “Bunu daha basit yapmanın yolu ne?” gibi öz değerlendirme ve öğrenme fırsatları kaybolabilir. Benim gözümde “developer”, “engineer” ve “architect” arasındaki fark tam da burada ortaya çıkıyor. LLM ya da “vibe coding” bu zihniyeti asla geliştirmez. Go gibi sözdizimi yükü düşük dillerde bu tür tasarım hataları review sırasında daha kolay açığa çıkıyor. Go’nun unit test yapısı, kod karmaşıklığını teşhis etmekte faydalı. Sonuçta daha iyi test/review yöntemlerine ihtiyacımız var. Fuzz testing, unit test ve integration test tek başına yetmiyor. Kodun içindeki dallanmaların gerçekten çağrılıp çağrılmadığını, koşulların sağlanıp sağlanmadığını mantıksal olarak doğrulayabilecek otomatik test framework’lerine ihtiyaç olduğunu düşünüyorum
LLM sayesinde yeni yazılım geliştirme maliyeti neredeyse sıfıra yaklaşıyor ama o kodu derinlemesine anlamanın, test etmenin ve güvenmenin maliyeti hiç olmadığı kadar yükselmiş gibi geliyor. Yine de deneyimime göre LLM’in ürettiği kod, çoktan ayrılmış birinin bırakıp gittiği ve hakkında doğru düzgün soru bile soramadığın eski kodlardan ya da internette dolaşan kodlardan o kadar da daha kötü değil. Hatta LLM test kodu yazarken insanlar gibi üşenmiyor ya da yorulup üstünkörü geçmiyor. Benim felsefem “her kod potansiyel bir borçtur” varsayımıyla başlıyor. Bu yüzden kodun güvenilirliği konusunda o kadar da kaygılanmıyorum. Gerçekten de AI ile büyük bir codebase oluşturup yeterince çalışır hale getirdim; tabii alan doğrulanabilir olmalı ve bol test ile iterasyon yapılmalı. Sonuç olarak LLM çıktılarıyla kod üretimi hızlandı ama kod yazmanın zihinsel uyarıcılığı azaldığı için beynimin de tembelleştiğini hissediyorum. Asıl önemli olan gereksinim tanımı, tasarım gibi ön taraftaki zihinsel işlere doğru bir çağ değişiyor
LLM olmasa bile sektör zaten “kod kıtlığı” değil, pazar talebi ve sermaye sınırları nedeniyle geliştirme hızında sınıra dayanmıştı. Tooling o kadar iyi hale geldi ki kod yazmanın kendisi artık merkezde değil. İlk dönemlerden tamamen farklı bir ortamdayız. Bill Gates’in gençlik yıllarından bir anı geliyor aklıma: yalnızca “kod yazabiliyor olmak” başlı başına kıt bir kaynaktı. Şirketler acil ihtiyaçtan 16 yaşındaki Gates ile Paul Allen’ı işe alıyor, onların sadece hızlı kod yazabiliyor olmasına bile şaşırıyordu. Bugünse asıl soru “Ne geliştireceğiz ve bunun üzerinde iş kurulabilir mi?”
ilgili video
Kodlamanın darboğaz olmamasının pazar talebiyle ilgili olduğu görüşüne katılıyorum. AI patlamasından önce Marc Andreessen de “sermaye bol ama yatırım yapılacak iyi fikir az” demişti. Bunun gerçeği tam yansıttığını düşünmüyorum ama en azından veriler açısından bakınca sözünde bir inandırıcılık var gibi görünüyor
Bill Gates’le ilgili eski hikâyede olduğu gibi, yüksek kaliteli kod yazma ve onu derinlemesine anlama becerisi hâlâ nadir bir kaynak. Fark şu ki artık sektör genelinde bu beceriyi önemsemeyen bir hava var
AI etkisini analiz ederken verimliliği fazla abartma eğilimindeyiz. Oysa gerçek ekonomi çok daha karmaşık biçimlerde darboğaz üretir. Kod üretimi 100 kat artsa bile bunun gerçekten ne kadar işe yarayacağı belirsiz
Son zamanlarda bazı insanların anlattıkları fazla karamsar geliyor. Eğer bir junior, çalışmayan, bizzat test/verify etmediği ve sadeleştirmediği devasa bir kod yığınını; üstelik dokümantasyon, yorum ya da açıklama olmadan teslim ediyorsa, bu zaten başlı başına “insana gömülü bir LLM sürümü” diye tanımlanabilir. Sonuçta önemli olan eleştirel düşünme ve ortaya çıkan sonuçtan sorumluluk alma bilinci. Hatta LLM’in geri bildirime mevcut junior yazılım mühendislerinden daha iyi tepki verme ihtimali olduğunu düşünüyorum
Ben de bir zamanlar kod yazmanın darboğaz olduğunu sanıyordum ama 10 yılda asıl zorluğun teknolojiyi iş ile hizalamak olduğunu gördüm. B2B ya da SaaS gibi müşteriden müşteriye değişen karmaşık kod yığınlarının olduğu ortamlarda bile teknoloji iş ihtiyaçlarına gerçekten uyduğunda her şey akıcı ilerliyor. Artık teknoloji yeterince ilerlediğine göre, asıl mesele geliştiricinin egosu ve müşteri değerine odaklanma becerisi. Müşterinin gerçekten ne istediğini, buna para ödeyip ödemeyeceğini, hatta baştan bir web arayüzü gerekip gerekmediğini düşünmek gerekiyor. Geliştiricilerin kendi tatmini için yaptığı “cat toy feature”lar bulut maliyetlerini artıran gerçek nedenlerden biri. Daha da üzücü olan, agresif teşvikler, hisse opsiyonları ya da yüksek maaşlar atarak bu temel sorunun çözülememesi. Yazılımı iyi yapma konusunda bir “misyon duygusu” taşıyan birinin, en azından tek bir kişinin bile müşteriyle doğrudan temas edip işi doğru yapmaya niyetli olması gerekiyor
Organizasyonda LLM’in gerçekten yardımcı olduğu anlar daha çok kişisel projelerim ya da side project’lerim oldu. Küçük bir sorunu çözmek için uygulama geliştirirken, zaman az olduğu için kod yazmak gerçekten büyük bir darboğaza dönüşüyor. Bu tür projelerde LLM kullanımı %100
Buna ben de yüzde yüz katılıyorum. Günde 1-2 saati Claude code’a ayırınca hafta sonu biterken kullanılabilir bir sonuç çıkıyor. Kısa zaman yatırımıyla fikir doğrulama ve deney yapmak kolaylaşıyor. Bu tür LLM araçlarının profesyonel organizasyonlarda da muazzam değer ürettiğini düşünüyorum. Normalde zaman olmadığı için yapılamayan çeşitli yönetim araçlarını ya da otomasyon sistemlerini hızlıca prototiplemek mümkün. Bir çalışma arkadaşının DB query ya da basit otomasyona ihtiyacı varsa Claude’a sorup sonra review ederek doğrudan yapıştırmak yeterli olabiliyor. Mühendis olmayan kişilerin bile kendi alanlarındaki tekrar eden işleri çözebilmesini sağlamak, benim mcp-front[0] projemin amaçlarından biri
mcp-front GitHub
Açıkçası kariyerimin şu anki aşamasında haftalarca yoğunlaşmak zor; yılların birikimiyle hep non-functional requirement’ları ve uzun vadeli etkileri de düşünüyorum. Test gibi şeyleri atlasam bile sonunda yine düşünmem gereken çok fazla konu oluyor
Robert C. Martin’in “kodu okumaya harcanan zaman, yazmaya harcanandan 10 kat fazladır” sözünü hatırlattı
ilgili alıntı
Ne yazık ki onun clean code tarzı bazen bağlamı parçalayıp niyetin anlaşılmasını daha da zorlaştırabiliyor
Daha kötüsü, yazma süresini kısaltırken okuma süresini artırıp toplam iş yükünü hiç azaltmıyor olabilir
Kimse bahsetmedi ama Joel Spolsky’nin 2 Ekim 2000 tarihli yazısını anmak isterim
Joel on Software: Painless Functional Specifications (2000)
Gerçek darboğaz kod değil, functional spec’tir. Yazılımın nasıl çalışması gerektiğini İngilizce, diyagramlar, user story’ler vb. ile açık biçimde tarif etmek çok daha önemlidir. Spesifikasyon iyi kurulmuşsa LLM de tek seferde gayet iyi çözümler, testler ve integration test’ler üretebilir. Konu çok büyükse, spesifikasyonu tek bir Markdown dosyasında tutmak yerine wiki gibi özelliğe göre bölüp bağlantı ve referanslarla yönetmek gerekir. Gerçek rekabet avantajı implementasyon zorluğunda değil, spesifikasyona ne kadar emek verildiğinde yatıyor
Yazarın görüşüne katılmıyorum. Büyük şirketlerde kod darboğaz olmayabilir ama startup açısından kaynaklar sınırlı ve verimli planlama daha önemliydi. Yani gerçekten çalışan kodu üretmenin kendisi pek çok durumda en büyük darboğazdı. Sonuçta bu tür tartışmalarda “AI/LLM ne kadar faydalı” sorusunu genellemek mümkün değil. Bazı ekiplerde kod darboğazdı, bazılarında değildi
Hepimizin bildiği gibi LLM’in ürettiği kod çoğu zaman berbattır ve review bile edilemez. Junior’ın gönderdiği LLM kodu tuhaf göründüğünde nedenini soruyorsun, kendisi de bilmiyor; sadece LLM’in ürettiğini söylüyor. Sonuçta bu eğilim kod bakımına sadece “noise” ve “overhead” ekliyor. Eğer LLM kullanımından kaçınmak mümkün değilse review ve bakımı da mecburen LLM’e devretmek gerekecek. Elbette sonuç daha da karmaşık bir spaghetti olacak. Ama gerçekçi olmak gerekirse çoğu iş dünyası senaryosunda kalite aslında o kadar önemli değil; LLM kodu kabaca iş görüyorsa yeterli sayılıyor. Ya da ihtiyaç oldukça üstüne yeni LLM katmanları eklenerek sonunda bir şekilde çözülmesi yeterli kabul ediliyor