Refactoring’in Sağladığı Ekonomik Avantajlar

• Bir ajanın yazdığı 17.155 satırlık Rust veri erişim katmanını aşamalı olarak refactor edince, aynı özellik değişikliği için gereken giriş token’ları 159.564’ten 27.360’a düşerek %83 azaldı
• Toplam kod miktarı neredeyse aynı kalsa da ilgili kod yüksek uyumluluğa sahip dosyalara ayrılınca, ajan değişiklik için gereken minimum dosya kümesini okuyabilir hâle geldi
• Giriş token’ları, en büyük dosya yeterince küçülene kadar belirgin biçimde azalmadı; sonunda veri katmanı 19 Rust dosyasına bölündü ve en büyük dosya boyutu 17.155 satırdan 3.695 satıra indirildi
• Çıkış token’ları ve özellik uygulama miktarı neredeyse değişmedi; Claude da uygun refactoring’i kendi başına seçemedi veya güvenilir şekilde uygulayamadı, bu yüzden planlama ve yürütmede insanın aktif yönlendirmesi gerekti
• Sonnet 5’in $3/MTok giriş fiyatına göre değişiklik başına tasarruf yalnızca yaklaşık $0,397 olsa da, bundan sonra veri erişim katmanı her değiştirildiğinde maliyetin tekrar tekrar düşme olasılığı görüldü

---

Ajanın oluşturduğu 17.155 satırlık dosya

• İş destek uygulaması; dinamik güncellenip sorgulanabilen bir web arayüzüne, modal pencerelere ve otomatik kayda, harici sistem entegrasyonlarına, makine öğrenimi ve metin analizine, arka plan işlerine ve otomatik dağıtım ortamına sahipti
• Toplam yaklaşık 150 bin satırın yaklaşık 120 bin satırı Rust, kalanı TypeScript ve Terraform’du; çoğu Claude Code ve kısmen Cursor kullanılarak ajan tarafından yazıldı
• Geliştirici, ara sıra meraktan bakması dışında kodu okumadı veya incelemedi
• Veri erişim katmanı, tüm okuma-yazma sorgularında aynı HTTP istek ayarlarını ve JSON kodlama-kod çözmeyi tekrarlayarak 6.000 satırın üzerine çıktı ve sonunda tek bir Rust dosyası 17.155 satıra ulaştı
• Bu modülde tekrarların giderilmesi ve iç dil yoktu; fonksiyon çıkarma sınırlıydı, sınıf çıkarma da neredeyse hiç yoktu. Ancak korunacak arayüzler ve net sınırlar bulunduğu için refactoring deneyi için uygundu

Aynı değişikliği tekrarlayan ölçüm yöntemi

• Amaç, mevcut refactoring’e token yatırımı yaparak gelecekteki özellik değişikliklerinin token tüketimini azaltmanın mümkün olup olmadığını görmekti
• Ajan önceki işlerden öğrenmediği için, her aşamada yeni bir alt ajandan tam olarak aynı değişiklik istendi; böylece öğrenme etkisinin karışması önlendi
• Deney şu sırayla yürütüldü
  • Katı refactoring ilkelerine göre genel plan yazıldı
  • Tek bir prompt ile temsili değişiklik tanımlandı
  • Alt ajanın değişikliği yapıp token tüketimini raporlaması sağlanarak başlangıç değeri ölçüldü
  • Değişiklik sonucu atıldıktan sonra bir refactoring adımı uygulandı
  • Aynı değişikliği yeniden yaptırıp sonucu atma süreci tekrarlandı
  • Aşama bazında token maliyeti, çalışma süresi ve kod satır sayısı kaydedildi
• Claude gerçek zamanlı token sayısını güvenilir biçimde veremediği için gönderilen-alınan karakter sayısını raporlaması istendi; tiktoken ile karakter sayısı 4’e bölünerek token yaklaşıklandı

Aşamalara göre ölçüm sonuçları

• Başlangıç durumunda veri erişim katmanı ve en büyük dosya ikisi de 17.155 satırdı; toplam Rust kodu 50.359 satırdı ve temsili değişiklik için 159.564 giriş token’ı, 1.705 çıkış token’ı ve 342 saniye gerekiyordu
• 15. aşama sonrasında veri erişim katmanı 16.608 satır, en büyük dosya 3.695 satır, toplam Rust kodu 49.812 satırdı; giriş 27.360 token, çıkış 2.113 token, çalışma süresi 454 saniyeydi
• Ara aşamalarda en büyük dosya küçüldükçe giriş token’ları da birlikte azaldı
  • 7. aşamada queries.rs çıkarıldıktan sonra en büyük dosya 15.670 satıra, giriş 151.850 token’a düştü
  • 8. aşamada traits.rs çıkarıldıktan sonra en büyük dosya 13.845 satır, giriş 132.558 token oldu
  • 12. aşamada store/ ayrıldıktan sonra en büyük dosya 9.269 satıra, giriş 104.080 token’a kadar indi
  • Son store/ ayrımından sonra en büyük dosya 3.695 satıra, giriş 27.360 token’a sert biçimde düştü
• Nihai veri erişim katmanı 19 Rust dosyasından oluştu ve en büyük dosya test kütüphanesi oldu
• Ek refactoring’lerde aynı yöntem ilgili test dosyasına da uygulanabilir

Giriş token’larının %83 azalmasının nedeni

• Aynı işin giriş token’ları 159.564’ten 27.360’a düştü ve 132.204 token tasarrufu sağlandı
• Veri erişim katmanının toplam kod miktarı neredeyse değişmediği için sonuç, okunacak kodun azalmasından kaynaklanmıyordu
• Ajan, iş için gereken minimum dosya kümesini belirleyerek giderek daha küçük kod alanlarını okudu; bu durum Claude Code’un düşünme çıktısında ve dosya okuma özetlerinde de görülebiliyordu
• Dosyaları rastgele küçültmek, ilgili kodu bulmak için birden çok dosya okumayı gerektireceğinden aynı etkiyi elde etmek zor olur
• En büyük azalma son ayrımda gerçekleşti; ancak önceki aşamalarda tekrarların çıkarılması ve yinelenen çekirdek yapının oluşturulması, dosya ayrımını mümkün kıldı
• Bu sıra, maliyet düşürmeyi hedefleyerek önceden tasarlanmış değildi; önce yerel tekrarları ortadan kaldırıp ortak çekirdek ortaya çıktıktan sonra daha küçük dosyalara ayıran tipik bir refactoring sürecinden doğdu

Çıkış token’ları ve parasal etki

• Temsili değişiklik yazılırken üretilen çıkış token’ları neredeyse değişmedi, dolayısıyla refactoring gerçek değişiklik boyutunu azaltmadı
• Çıkış token fiyatı giriş token’larının 5 katıydı, ancak mutlak miktarı çok daha düşüktü
• Sonnet 5 giriş fiyatı $3/MTok olarak hesaplandığında, değişiklik başına tasarruf yaklaşık 39,7 sentti
• Hata ayıklama veya daha karmaşık özelliklerde, ya da kod tabanının tamamının refactor edilmesinde tasarrufun birikip birikmeyeceği ve refactoring’in kendi maliyetinin ne olduğu doğrulanmadı
• Çıkış token’larını da azaltan refactoring’in mümkün olup olmadığı belirsiz; basit temsili değişiklikte deterministik olmayan kod üretiminin gürültüsü, yapı değişikliğinden kaynaklanan farkları maskeledi

Claude ile yürütülen refactoring

• Claude koda bakıp uygulanacak refactoring’i kendi başına seçemedi; gerçek sonuçlar, prompt’un doğrudan talimat verdiği işlere karşılık geldi
• Geliştirme harness’inde açık bir refactoring aşaması bulunmasına rağmen Claude bunu kullanarak 17.155 satırlık dosyayı iyileştirmedi
• Planlama sürecinde Claude Code ilk adım olarak fonksiyon çıkarmayı bulurken, Claude.ai tüm istemci sınıfının çıkarılmasını da belirledi
• Mekanik değişikliklerde grep ve sed kullanan Python betikleri kullanıldı; ancak betikler girintileme yüzünden sık sık karışıklık yaşadı
• En değerli mağaza dosyası ayrımı ilk denemede atlandı ve sonraki aşamada yeniden uygulandı; bu nedenle ölçüm sonuçlarındaki aşama sayısı ile ekteki plan adımları uyuşmuyor
• Tüm deney yaklaşık 8 saat sürdü ve çoğunlukla gözetimsiz ilerledi
  • 6 saat 40 dakika sonra eksik aşama fark edilerek bir kez müdahale edildi
  • Test çalıştırmalarını ciddi biçimde yavaşlatan nedenin yavaş otel Wi‑Fi’ından çok, aşırı büyümüş Cargo geçici derleme önbelleği olduğu ortaya çıktı

Temsili değişiklik prompt’u

• Her alt ajana yalnızca kod tabanı ve mimari belgeler verildi ve aynı ItemWatchStore asenkron public trait’ini uygulaması istendi
• Trait şu üç metodu içeriyordu
  • watch_item(&self, item_id: &str, user_id: &str) -> Result<()>
  • unwatch_item(&self, item_id: &str, user_id: &str) -> Result<()>
  • watched_items_for_user(&self, user_id: &str) -> Result<Vec<String>>
• Watch bilgisi Firestore’daki item_watches koleksiyonunda itemId, userId, createdAt alanlarıyla saklandı
• Ayrı bir Rust kayıt struct’ı olmadan item ID’lerinin Vec<String>’i döndürüldü
• FakeStore’a bellek içi Vec<(String, String)> alanı eklendi; FirestoreStore ise mevcut HTTP desenini aynen kullanarak uygulandı
• Yanıtın sonunda okunan dosyaları ve karakter sayılarını, ayrıca yanıt karakter sayısını JSON olarak çıktılaması istendi; kodu commit etmemesi söylendi

Uygulanan refactoring planı

• 1. aşama — FirestoreClient sınıfını çıkarma

  • Alan sorgusu koordinasyonu ile Firestore HTTP aktarımı sorumlulukları ayrıldı
  • reqwest::Client, project_id, MetadataAuth, URL ve kimlik doğrulama header işleme yeni struct’a taşındı
  • Plana göre FirestoreStore uygulamasından yaklaşık 1.200 satır azaltılıp istemciye yaklaşık 120 satır ekleniyordu

• 2. aşama — extract_doc_id, new_link fonksiyonlarını çıkarma

  • 20 belge parser’ında ID çıkarma ve 62 kez tekrarlanan Link oluşturma ortaklaştırıldı
  • Yaklaşık 500 satır tasarruf bekleniyordu

• 3. aşama — link sorgu pipeline fonksiyonlarını çıkarma

  • Yaklaşık 15 yerdeki sorgu sonucu toplama ve yaklaşık 8 yerdeki tek hedef ID sorgulama deseni ortaklaştırıldı
  • Yaklaşık 200 satır tasarruf bekleniyordu

• 4. aşama — FakeStoreInner link koşul fonksiyonlarını çıkarma

  • Yaklaşık 15 metotta tekrarlanan inner.links.iter() varyasyonları iki metoda ayrıldı
  • Yaklaşık 120 satır tasarruf bekleniyordu

• 5. aşama — Firestore değer oluşturma fonksiyonlarını ekleme

  • 128’den fazla kez tekrarlanan string, timestamp vb. json! ifadeleri dört fonksiyon çağrısıyla değiştirildi
  • Çok satırlı makroları tek satırlık çağrılara dönüştürerek yaklaşık 80 satır tasarruf bekleniyordu

• 6. aşama — FieldsBuilder çıkarma

  • Yaklaşık 20 encoder’daki field map oluşturma deseni builder ile birleştirildi
  • Yaklaşık 40 satırlık encoder’ları yaklaşık 12 satıra indirerek toplam 500-600 satır tasarruf bekleniyordu

• 7. aşama — queries.rs ayırma

  • 32 LinkQuery sabiti ve ilgili tipler ayrı modüle taşındı
  • Mevcut çağrı yerleri değiştirilmeden mod.rs içinde yaklaşık 800 satır azaltıldı

• 8. aşama — traits.rs ayırma

  • 17 public trait ve ilgili hata tipleri taşınıp yeniden export edildi
  • mod.rs içinde yaklaşık 1.900 satır azaltılsa da yeni dosya da yaklaşık 1.900 satır oldu

• 9. aşama — traits/ dizinini alanlara göre bölme

  • Trait’ler planning.rs, content.rs, people.rs, system.rs olarak ayrıldı
  • Tanımlar ve çağrı yerleri değiştirilmeden dosya başına boyut yaklaşık 300-650 satırla sınırlandı

• 10. aşama — codec.rs ayırma

  • Belge encoder-decoder’ları, parser’lar, FieldsBuilder ve değer oluşturma fonksiyonları taşındı
  • 6. aşamadan sonra yaklaşık 400-500 satırlık bir modül oldu ve mod.rs içinde yaklaşık 500 satır azaltıldı

• 11. aşama — fake_store.rs ayırma

  • FakeStore, FakeStoreInner ve 18 trait uygulaması taşındı
  • mod.rs içinde yaklaşık 4.700 satır azaltıldı

• 12. aşama — FirestoreStore uygulamasını ayırma

  • store/mod.rs içinde struct, constructor, FirestoreClient, MetadataAuth bırakıldı; trait uygulamaları alan bazlı dosyalara ayrıldı
  • Yaklaşık 10.000 satırlık dosya, her biri 120-650 satırlık 10 dosyaya dönüştürüldü ve mod.rs yaklaşık 100 satırlık yeniden export dosyası hâline getirildi

• 13. aşama — testleri hedef modülle birlikte konumlandırma

  • Test kodu değiştirilmeden her uygulama dosyasının altına taşındı
  • mod.rs içinde yaklaşık 2.000 satır azaltıldı ve her dosyaya ilgili testlerden 200-700 satır eklendi

Sınırlar ve sonraki deneyler

• Refactoring planı yazma ve yürütmede harcanan token’lar ayrıca sayılmadığı için refactoring yatırım maliyeti doğru hesaplanamıyor
• O zaman dilimindeki toplam kullanıma göre üst sınır 5 milyon token, ancak buna planın iki kez yazılması, deney ve temsili değişiklik tasarımı ile diğer işler de dahil
• Deney konusu hâlâ greenfield aşamasında ve tek bir geliştiricinin kurup yönettiği büyük ölçekli tek bir uygulama olduğu için sonuçlar genellenemez
• Sonraki işler için doğru refactoring token ölçümü, daha karmaşık değişiklikler, daha geniş kapsamlı refactoring, sürekli refactoring ve yaklaşımların göreli değerlerinin karşılaştırılması gerekiyor
• Bu deney, refactoring ile elde edilen zaman ve parasal değeri refactoring’in kendi maliyetiyle birlikte ölçebilmek için bir başlangıç noktası oldu

[GN⁺]

Hacker News görüşleri

• Çoğu BT şirketinin görmezden geldiği geliştirici en iyi uygulamalarının yapay zeka en iyi uygulamaları olarak yeniden keşfedilmesi eğlenceli
  Eskiden belgeleri kodun içinde tutmak, sadece Jira işi atmak yerine projenin tüm bağlamını aktarmak ve uzun vadeli üretkenlik için refactoring yapmak sıkıcı bulunurdu
  Şimdi aynı şeyler, yapay zeka dokümantasyonunu kod ve CLAUDE.md içinde tutmak, prompt'larla aşırı ayrıntılı kontrol etmemek ve yapay zeka verimliliği için refactoring yapmak denince ilgi çekici karşılanıyor

  • Yapay zeka ajanlarının, insan ekip arkadaşlarından daha tutarlı biçimde aynı işi yapmasını sağlamak çok daha kolay
    İnsanlar doğru yöntemi bilse bile meşgul olabilir ya da dikkatleri dağılabilir; ajanlar ise sıkıcı işlerden usanmadığı için, insanlarda etkisi kanıtlanmış ama düzenli uygulaması zor olan süreçler pratikte mümkün hale geliyor
    Ortak bir spesifikasyona dayanarak uygulama ve testlerin ayrı ajanlar tarafından yazılması ve bir denetim ajanının bunları doğrulaması sağlanmış; böylece sonuçlar birbirini kirletmiyor. Bu, IBM'in 1980'lerde insanlar için geliştirdiği cleanroom engineering yaklaşımının yapay zekayla geniş ve tutarlı biçimde uygulanması demek
  • Bu yazıyla bağlantılı kişi, 20 yıldan uzun süre önce Refactoring kitabını yazarak bu terimi yaygınlaştıran Martin Fowler
    Yani eski bir pratiği yapay zeka modasına uyacak şekilde yeniymiş gibi paketlemek değil; 20 yılı aşkın en iyi uygulamaların hâlâ geçerli olduğunu kanıtlarıyla göstermek
  • Yapay zeka öncesi ve sonrası arasındaki büyük fark, insanların oldukça iyi bir uzun dönem bağlam yönetimi becerisine sahip olması
    Ajanların ise her oturumda bağlamı yeniden edinmesi gerektiğinden, en iyi uygulamaların değeri çok daha büyüyor ve etkisi de hemen görülüyor
  • Yapay zeka çılgınlığı sayesinde istenen geliştirici deneyimi iyileştirme işlerine bütçe çıkabiliyor olması güzel, ama gerekçenin yanlış olması buruk hissettiriyor
    Yine de bir saat boyunca CLI'ı 100 kez çalıştırıp yeni bir flag'in kullanılabilirliğini test edebilmek iyi
  • İnsanlar, SharePoint'teki eski belgeler, toplantıda yarım kulak duyulan genel bağlam ve düşük refactoring önceliğine rağmen kalite ve takvim biraz kötüleşse de bir şekilde sonuç çıkarabiliyor
    Buna karşılık yapay zeka, böyle bir temel olmadığında çok kötü performans gösteriyor ya da hiç çalışmıyor; bu yüzden sağlıklı mühendislik pratikleri uzun vadeli bir iyileştirme değil, zorunlu bir önkoşul haline geliyor
    Gerçekte net etki sıfır olsa bile, yapay zekayı iş akışına sokmak düzgün geliştirme pratiklerini yerleştirmek için bir gerekçe sağladığı ölçüde faydalı

• Bu yazının, yapay zeka araçlarının gerçekte nasıl kullanıldığına dayanarak somut ve nicel bir eleştiri getirmesi hoş
  Gerçek kullanım örnekleri olmadan toplumsal riskleri muğlak biçimde tartışan yazılardan çok, yapay zekanın neyi yapamadığını ölçümlerle gösteren yazılar daha faydalı
  Aynı nedenle Boko Haram üyeleriyle görüşerek yapay zekanın terörde nasıl kullanıldığını inceleyen rapor da etkileyiciydi

• Yapay zeka olmadan doğrudan yapılan refactoring'i gerçekten seviyorum
  Görünür hiçbir değişiklik olmasa da, şu an hemen sonuç üretmeyen bir web sitesini gelecekte çok daha kolay yönetilebilir hale getirmesi tatmin veriyor
  Yerleşik kalıplarla çoktan çözülmüş sorunları geçmişte yazılmış tuhaf dolambaçlı kodların yeniden çözmeye çalıştığını bulup bunları en iyi uygulamalara taşırken yeni teknik borç oluşturmamak, bulmaca çözer gibi keyif veriyor
  Kimlik doğrulama dahil her şeyi özensizce kendim uygulayarak iç işleyişi zor yoldan öğrendim; bunun sonucunda da önümüzdeki 10 yıl boyunca keyifle uğraşacağım refactoring işleri çıktı

  • Fowler'ın Refactoring kitabını okuyup bunun bilimsel/araştırma kodunda işe yarayıp yaramayacağından şüphe etmiştim; ama memnun olmadığım bir kod yapısına deneme amaçlı uyguladıktan sonra bakış açım tamamen değişti
    Kod tabanı bir sistemdir sözünü somut olarak anlamaya başladım ve kodu çekip itebileceğiniz sürekli bir organizasyon ya da ağ gibi daha yüksek bir seviyeden görür oldum
    Yapay zekanın bu öğrenme sürecini ortadan kaldırabilmesi, junior geliştirici sorununu daha görünür kılıyor. Sezgi kazanmak için bizzat derine inmekten başka yol yok; Naur 40 yıl önce uyarmış olsa da bu ders sürekli unutuluyor
  • Belki de Windows 98 disk birleştirme ekranını izlerken alınan dopamin ödülü yüzündendir
  • Bu duygu, bir zanaatkâr olarak duyulan gururdur. Anlayan kişiye açıklama gerekmez, anlamayana ise hiçbir açıklama yetmez
  • Refactoring sırasında regresyonu önlemek için ne ölçüde test suite'i güvenlik ağı olarak kurduğunu merak ediyorum
  • Çeşitli refactoring kalıplarını ve gerçek uygulama örneklerini inceleme süreci keyifli

• Ajanın refactoring yaparken insan katılımının gerekli olduğunu düşünüyorum
  Üretici modelin ilk işe odaklanırken kaçırdığı noktaları bir inceleme modeli bulabilir, ancak projenin genel amacını ve kodun nasıl birleştiğini gerçekten anlayıp tekrarları ya da daha zarif yapıları ayırt edebileceği şüpheli
  Refactoring işini bir kodlama ajanına bırakmak, bir travma cerrahından atletik performansı artırmasını istemeye benzer; düzgün yapılması için bütüncül bir bakış gerekir
  Büyük dosyaları birkaç dosyaya bölmek tek başına yüzeysel bir refactoring olarak kalır. Hangi kodun birlikte durması gerektiğine ve nelerin yardımcı fonksiyonlara çıkarılacağına dair bir teori yoksa, bu çarpanlara ayırmaktan çok büyük bir sayıyı küçük sayılara bölüp sonra yeniden toplamaya benzer
  Ajan bazen API'den zaten alınan değerleri yeniden saklayıp hesaplayan sistemler kuruyor, ama insan proje bütününe bakıp JSON içindeki belirli bir anahtarda gereken verinin zaten bulunduğunu daha isabetli biçimde tespit edebiliyor

  • Mevcut LLM'ler de belirli bir kod bölümünde somut refactoring talimatı verilirse bunu gayet iyi yerine getiriyor. Örneğin veri sınıfı yerine functools.partial ile Command deseni uygulanması gibi karmaşık bir isteği de karşılayabiliyor
    Dosya sınırlarının mantıksal alt sistem sınırlarını temsil ederek akıl yürütmeyi kolaylaştırdığı ve diğer dosyaların içeriğinin varsayılan olarak opak kabul edildiği fikri de eğitim verilerinde bolca yer alıyor
    Bu yapının avantajının sadece insan bilişinin tesadüfi bir özelliği değil, nesnel yönleri de olduğunu düşünüyorum
  • İnsan yanında durup yönü açıklarken, aylar sürecek refactoring işinin büyük bölümünü yaklaşık bir haftada bitirdim
    Refactoring deneyimim, başkalarının kod tabanlarıyla çalışma biçimim ve özgün tasarımcı olarak geçmişteki ve bugünkü niyetleri açıklayabilmem yardımcı oldu
    Bağımlılık kırılganlığı az olan ve LLM'lerin daha kolay ele aldığı niş bir dildi; JavaScript ve Python tarafındaki önyargı kaldırılınca iş hızı ciddi biçimde arttı
    Bu, birkaç popüler dilde script yazılan ama ortam gereksinimleri nedeniyle hepsinin JVM üzerinde çalıştırıldığı bir JSR-223 projesiydi: https://en.wikipedia.org/wiki/Scripting_for_the_Java_Platform
  • Ajanların refactoring yapamadığı değerlendirmesi artık eskidi; bugün çok iyiler
    Bu işe alım piyasasında en güncel öncü model tabanlı kodlama ajanlarını kullanmak ve bunların yetenekleriyle sınırlarını doğru bilmek gerekiyor; mülakatta tersini savunmak elenme nedeni olabilir

• Özlü bağlam, yalnızca token tüketimini azaltmakla kalmaz; akıl yürütmeyi de iyileştirir ve tek bir bağlama daha fazla katman sığdırıp bunları daha akıllıca işlemeyi mümkün kılar
  İyi soyutlamaya yönelik refactoring, yalnızca test edilen örneklerde değil, içe ve dışa doğru genellenen örneklerde de doğru olma ihtimali daha yüksek, daha iyi genelleşen yazılımlar üretir
  Bunu destekleyen bilgi kuramı ve Bayes matematiği vardır; ekonomik ve enerji açısından verimli yazılımın daha doğru hale gelmesi zarif bir rastlantı gibi görünüyor
  Esas nokta kodun entropisini azaltmak

  • Dünyada ve evrenin herhangi bir yerinde entropi azaltımı, bir şey inşa etmek olarak görülebilir
  • İnsan okunabilirliğini hedeften çıkarıp amaç fonksiyonunu yalnızca token tüketimini azaltmak yaparsanız, nereye varacağınızı kestirmek zordur
    LLM'ler zaten az bağlamla bile anlamı oldukça iyi çıkarıyor

• Veri sunulmuş olması ilginç; iyi ayrılmış kodda LLM'lerin büyük fayda sağladığı ama böyle kodu kendi başlarına üretme konusunda çok da güçlü olmadıkları yönündeki kişisel gözlemimle örtüşüyor
  Muhtemelen çoğu insan geliştirici için de durum benzer

  • Ayrı olarak dağınık kod temizleme süresini bütçeye koyuyorum ve şu anda yan pencerede de bunu yapıyorum
    Genel olarak AI'dan kazanım büyük, ama toparlama zamanı da gerekiyor ve hâlâ her satırı okumak gerektiğini düşünüyorum
    Başka ekiplerin ilerlemesini engellememek için bazı incelemeleri erteledim; şimdi sonradan normalden daha büyük bir teknik borcu ödüyorum, ama önce darboğazı açmak daha değerliydi
    AI her anlamda teknik borcu daha kolay çekilebilir hale getirdi ve iyi yönlendirilirse bu borcu kapatmada da epey iyi. Yine de sonuç kişiden kişiye değişiyor: https://news.ycombinator.com/item?id=49035455
  • Varsayılan durumda ben de aynı sonucu gördüm, ama refactoring yönünü somut biçimde verdiğimde daha iyi ayrılmış kod üretebildi
    İyi düzenlenmiş kod örnekleri veya açık kaynak depoları üzerinden ne yapılması ve ne yapılmaması gerektiğini göstermek çok yardımcı oluyor

• Refactoring'in ekonomik faydasının çoğu, token tasarrufundan çok insanların anlama düzeyinin artmasından geliyor
  Gece 3'te gelen arıza çağrılarını daha hızlı çözmeyi, üretim ortamına çıkan hataları azaltmayı ve rakiplerden daha hızlı teslim etmeyi sağlıyor
  Hepsinden önemlisi, sistemi anlayınca insanlar sorumluluk ve sahiplenmeyi daha istekli üstleniyor; bu da sorun çıktığında daha hızlı düzeltmelerini ve iyileştirme alanlarına daha hevesle atılmalarını sağlıyor

• Asıl nokta refactoring'in token tüketimini azaltması; bunu soyut konuşmak yerine nicel olarak göstermeleri güzel
  Ancak Fowler, 《Refactoring》 kitabında refactoring'in vazgeçilmez önkoşulunun sağlam testler olduğunu söylemişti ve AI'dan bağımsız olarak gerçek faydanın burada olduğunu düşünüyorum
  İyi testler, ister insan ister robot kaynaklı olsun regresyonları engeller ve her iki tarafın da okuyabileceği bir spesifikasyonu kod olarak bırakır: https://www.oreilly.com/library/view/refactoring-improving-the/9780134757681/

  • Yazı martinfowler.com'da yayımlanmış olsa da Martin tarafından yazılmamış; yazar olarak Thoughtworks CTO'su Giles Edwards-Alexander görünüyor
  • Asıl mesele, tasarruf tutarının yalnızca birkaç on sent düzeyinde olması
    Sonnet 5 fiyatını MTok başına 3 dolar sayarsanız, veri erişim katmanına dokunan gelecekteki değişikliklerde sağlanan tasarruf 39,7 sent ediyor
    OpenAI'ın fiyat indirimleri, açık modeller ve uzun vadede token fiyatlarının düşmesi düşünüldüğünde, saati yaklaşık 100 dolar olan kıdemli bir geliştiricinin refactoring'i yönlendirme maliyetiyle örtüşmeyebilir

• Ajanın ürettiği kod, neredeyse yalnızca ajanın okuyup anlayabileceği kadar devasa bir yığına dönüştü; burada bunun özellik mi, bug mı, yoksa ortaya çıkan bir özellik mi olduğundan çok gerçekliğin kendisi önemli.
  AI araçlarıyla üretilen kodu yönetebilmek için yeniden AI araçlarına bağımlı hale geliyoruz.
  Ancak insanlar da zaten korkunç derecede büyük dosyalar ve monorepo'lar üretti; LLM sayesinde bunları düzenlemek ve refactor etmek nihayet katlanılabilir hale geldi.
  Kod tabanı insanların anlayamayacağı kadar büyük ve dağınık hale gelmişken LLM bizi kurtarabilir; kişisel olarak dev dosyalardan nefret etsem de Fowler tarzı düzenleme ilkeleri artık o kadar önemli olmayabilir, bu da acı bir durum.

  • Ajan kodunu yalnızca ajanların anlayabildiği iddiası temelden doğru değil; size öyle geliyorsa LLM kullanımı yanlıştır.
  • Kötü kod zaten hep vardı ama AI, kötü işe alımın zarar alanını 1.000 kat büyüten yeni bir sorun.
    Ortalama ya da bazen iyi iş çıkaran çalışanlar bile, eskiden şirket süreçleri yüzünden yapamadıkları şeyleri yıldırım hızıyla uygulayabilir hale gelerek tersine kötü çalışana dönüşebilir.
  • LLM'in %100 yazdığı kod tabanlarında da okuma veya istediğim yeri bulma konusunda sorun yaşamadım; bunu yapmak, kodu kendim yazdığımdan daha zor değildi.
  • Ajanın ürettiği kodun, insanların yazdığı en kötü koddan daha kötü olduğu bir durum hiç görmedim.
    Ajan devasa dosyalar ya da fonksiyonlar üretirse, bunu yapmamasını söylemek yeterli oluyor ve buna uyuyor.

• Refactoring, sağlıklı bir geliştirme ekibinin en iyi göstergelerinden biri bence.
  Refactoring'in kendi başına faydaları var ama bu değer ürün sorumlularına ya da özellik iş listelerinde pek görünmez.
  Ekip, yazılımın genel sağlığı için refactoring yapıyorsa bu; geliştiricilerin iyi yazılım için önerileri rahatça dile getirebildiği ve bu önerilerin ciddiyetle ele alındığı anlamına gelir.
  Yazılım çürümesi, ekipte yüksek kaliteli yazılım vizyonunu hayata geçirecek motivasyon ya da yetki olmadığında en ağır hale gelir; ekip mükemmellik konusundaki yargısını uygulayabiliyorsa bu genelde iyi bir işarettir.
  Elbette Ruby, Node ve Rust'tan geçip yeniden ajan dostu teknolojiye baştan yazmak gibi aşırılıklar da var, ama kurumsal ortamlarda iyileştirme için izinleri olmadığını hisseden ekipler çok daha yaygındır.