(Bu, 17 Aralık'ta Seul Claude Code Meetup'ta yapılan sunumun materyalidir. Sunumun tamamı için şu bağlantıya bakabilirsiniz.)
KORCA AX ekibinin 'iç danışmanlık' hedefi
- KORCA'da iyi ajan tabanlı mühendislik pratiklerini kalıcı hale getirmek ve bunları birlikte sürekli geliştirebilecek bir zemin oluşturmak.
- KORCA, 'ajan tabanlı mühendislik pratikleri'ni, 'yazılımın kalitesini ve üretkenliğini aynı anda artıracak yönde AI ajanlarını kullanmak için uygulanan yöntemler' olarak tanımlıyor
- Mühendislik yetkinliğinin KORCA'nın bir diğer temel rekabet avantajı haline gelmesini sağlamak.
- Bunun için Moonlight ekibine destek vermeye başladılar
Moonlight'ın durumu
- KORCA'nın amiral ürünü Moonlight, kendini 'birlikte makale okuyan yapay zeka iş arkadaşı' olarak konumlandırıyor
- 'PDF ile sohbet etme', ChatGPT'nin en erken dönemlerinden beri var olan bir fikir. Moonlight, bu çok sayıdaki rakip ürün arasından ayakta kalmayı başardı ve bugünlerde J eğrisinin başlangıç aşamasında (özellikle son dönemde Çin'de abone sayısı hızla artıyor)
- Buraya gelene kadar sayısız deneme-yanılma oldu, ancak temel rekabet gücü, özellik geliştirme hızını ve ritmini bir şekilde koruyabilmekti
- Hız için alınan bazı erken kararlar
- typescript strict: false
- Otomatik testleri minimumda tutmak
- Tekrara ve hardcoding'e izin vermek
- Rol ayrımı yok. Ekip üyelerinin neredeyse tamamı (7 kişiden 6'sı) kodlama ajanlarıyla geliştirip PR açıyor
- Ancak iş rayına oturunca, biriken teknik borç yavaş yavaş zorlamaya başladı
- Ürün daha karmaşık hale geldi, ekibe çok sayıda yeni kişi katıldı ve aynı anda yürüyen deney sayısı arttı
- Ürün geliştirme hızı biraz biraz yavaşladı, kaygı ise giderek büyüdü
- Kod inceleme yükü birkaç kişinin üstünde yoğunlaştı ve büyük küçük hatalar ortaya çıkmaya başladı
AX ekibinin önündeki acil görevler
- [Ürün] Moonlight ürününün kalitesi artarken, özellik ekleme ve iyileştirme hızı da artsın!
- [Ekip] Herkesin Moonlight kodunu daha kolay değiştirebilmesini ve dağıtımdan sonraki stresin azalmasını sağlayalım!
- [Kültür] 1 ve 2 için Moonlight ekibi ile AX ekibi birlikte çalışarak iyi ajan tabanlı mühendislik pratiklerini keşfetsin, uygulasın, geliştirsin ve bunları zamanla şirket içine yaysın!
→ Kodlama ajanları daha iyi yanıtlar verebildiğinde sorunların büyük kısmının çözüleceği düşünüldü
Ajanların daha iyi yanıt vermesi için ne gerekir?
[1] En baştan iyi bir yola girmelerini sağlamak
- Kod tabanının kalitesi yüksekse bu, 3 açıdan avantaj sağlar
- Gereksiz bağlam daha az verilir (Less is More)
- Ajan mevcut iyi kalıpları takip eder
- Önceden eğitildiği kodlar içinde, yüksek kaliteli kodların kümelendiği bölgelerden örneklenen yanıtların gelme olasılığını artıracak şekilde yönlendirme yapılabilir
- Yüksek kaliteli bağlam verildiğinde iyi yanıtlar çıktığını gösteren çok sayıda araştırma var.
- (Kişisel tahmin) import sırası düzenlenmiş bir kod tabanında ajana istek gönderildiğinde ne olur? Ön eğitim verisindeki import sırası düzenli kodların genel olarak daha yüksek kaliteli olma ihtimali daha yüksek değil midir?
- Anthropic blogu'ndan: "Sadece ilgi çekici fontlar kullandırmak bile diğer tasarım öğelerini de iyileştiriyor"
[2] Yanlış bir yola sapmalarını engellemek
- Tür hatası kontrolü, linter hatası kontrolü, otomatik testler, ölü kod taraması, dosya uzunluğu kontrolü, karmaşıklık kontrolü, bağımlılık ilişkilerini zorunlu kılma, test kodu ile production kodu oranını zorlama gibi çeşitli statik analiz araçlarıyla yanlış yollar engellenebilir (kriterler geçilene kadar yeniden çalıştırılırlar)
[3] Onlardan daha çok iyi yaptıkları işleri istemek
- İnsanların, LLM'lerin ve algoritmaların iyi yaptığı şeyler farklıdır. Hangi durumda hangisini kullanacağını akıllıca seçmek zaman ve maliyet tasarrufu sağlar
- Örn.) i18n key unutulmamasını söylemek yerine eksik i18n key'leri bulan script'i çalıştırmasını istemek
- Kimin ne zaman neyi iyi yaptığı, zamanla ve problemin alanına göre değişir. Kendi alanında bu 'sezgiyi' güncel tutma alışkanlığı edinmek avantaj sağlar
- Örn.) Yeni bir model çıktığında kendi benchmark'ınızla test etmek, sosyal medyada bilinen örnekleri takip etmek
[4] Yapamadıkları işlerde onlara yardımcı olmak
- Ancak gerçekten yapamadıklarından her zaman emin olmak gerekir. Devretmesi riskli değilse ya da aşırı verimsiz değilse, işi insanlardan çok AI/algoritmaların yapması daha iyidir. (Token maliyetleri sonuçta elektrik faturası seviyesine kadar ucuzlayacaktır)
- Gerçekten yapamıyorlarsa? Başka bir LLM'ye inceletmek
- Örn.) En basit haliyle, "Bunu sanki acemi bir geliştirici yazmış gibi..."
- AI'ın işi daha iyi yapmasını istiyorsak, ona işi daha iyi yapabileceği bir ortam sunmalıyız. Başka bir deyişle, (mevcut) ajanın (burada) iyi yapamayacağı şeyleri insanlar, algoritmalar ve diğer ajanlar desteklemelidir
Dikkat edilen noktalar
- Moonlight artık uçmaya yeni başlamış bir roket, AX ekibi ise dışarıdan gelen bir misafir
- Dışarıdan gelen birilerinin bir şeyleri tasarlayıp 'yapıp vererek' dönmesi yaklaşımından kesinlikle kaçınıldı
- Kalite artırma çabası, özellik geliştirme hızını mümkün olduğunca yavaşlatmamalı
- Normal çalışma biçimini fazla değiştirmeyen işler ile daha meydan okuyucu ama etkili işleri uygun bir oranla karıştırmaya karar verildi
→ AX ekibi ile Moonlight ekibinin 'birlikte' takıma ve ürüne uygun pratikleri keşfedip uyguladığı; bu süreçte de kod ve ürün kalitesinin yanı sıra ekip yetkinliğinin de birlikte arttığı bir tablo hedeflendi
Son 4 haftada elde edilen başlıca sonuçlar
[1] İyi alışkanlıklar yerleşiyor, iyi kalıplar keşfediliyor
- Her gün, PR incelemesi gerektirmeyen çok küçük refactoring (tidying) commit'leri atmak
- Geçmişteki örnek niteliğindeki commit'leri (ör. yeni model desteği gibi) taklit eden prompt'lar ve bu tür kalıpları keşfedip toplayan prompt'lar
- Kıdemli geliştirici gibi davranan code review SKILL
[2] Kod kalitesi metrikleri ölçülmeye ve görünür kılınmaya başlandı. Kod satırı sayısına kıyasla hata/uyarı sayısı hızla düşüyor
- Kod kalitesi metrikleri bazen kademeli, bazen de dramatik biçimde azalıyor
- Günlük tidying çalışmaları kod tabanını her gün biraz daha iyileştirdiği için, bir noktada büyük refactoring'lere ve büyük işlere girişilebileceği hissi oluştu
- knip, paket paket uygulanarak eski ve kullanılmayan kodların da silinmesini sağladı
- Metrikler her zaman birbirini tamamlamalıdır. 1000 satırlık kodda 1000 hata olması yerine, 100 bin satırlık kodda 5000 hata olması çok daha iyidir. Bu yüzden yalnızca toplam sayıya değil, satır başına hata oranına bakılarak daha sağlıklı yönetim göstergeleri tanımlandı
- Yorum ve boşluklar hariç anlamlı satır sayısı tokei ile ölçüldü
[3] Bir yılı aşkın süredir devam eden bellek sızıntısı sorunu giderildi
- repomix dahil çeşitli araçlar ve prompt teknikleri seferber edilerek, birkaç denemenin ardından bir yılı aşkın süredir süren bellek sızıntısı çözüldü
- Sunucu instance tier'ını düşürebilecekleri için mutlu olduklarını söylüyorlar
[4] Her hafta paralel yürüyen birkaç deneyi daha kolay ve güvenli şekilde ekleyip çıkarmayı mümkün kılan soyutlama yapıları, prompt'lar ve script'ler ortaya çıktı
Sonuç olarak, kod kalitesi giderek yükseliyor, özellik geliştirme daha güvenli ama aynı zamanda daha hızlı hale geliyor ve ekibin (ajan tabanlı) mühendislik yetkinliği istikrarlı biçimde artıyor; bu üçlü uyumlu şekilde ilerliyor
Deneme-yanılmalar
- Elbette her şey baştan iyi gitmedi. Aslında iki şeyi aynı anda yapmak istiyorlardı
- Biraz riskli olsa da değeri yüksek değişiklikleri tek seferde almak: strict seçeneğini açmak, sert eslint kuralları eklemek, ölü kodları topluca silmek vb.
- Değeri daha düşük olsa da güvenli şekilde adım adım ilerlemek: her gün tidying commit'i bırakmak vb.
- Ama ilki fazla kaygı yarattığı için 'yapılamadı', ikincisi ise sıkıcı bulunduğu için 'yapılmadı'
- Bunun yerine yaklaşım şöyle değiştirildi
- Zorlu işleri daha güvenli hale getirmek (dosya dosya tsc strict açıp düzeltmek ve kapatmak, minimum kurallarla eslint uygulamak, her seferinde bir pakette knip çalıştırmak vb.)
- Güvenli işleri daha değerli hale getirmek (yakın tarihli değişiklikler için tidying önerileri veren prompt'lar oluşturmak vb.)
- Hâlâ çözülmesi gereken pek çok konu var
- typescript: strict açmak
- zod kullanarak sunucu-istemci sözleşmelerini uyumlu hale getirmek
- Daha sıkı eslint rule'ları eklemek
- Daha yüksek otomatik test kapsamı
- Daha çeşitli statik analiz araçlarıyla yanlış yolları daha güçlü biçimde kapatmak
- Birlikte, istikrarlı biçimde ve asla yavaşlamadan ilerliyorlar
One More Thing: Benim öğrenme + debugging alışkanlığım
Böyle durumlarda AI'a sorup uzmanlara da danışarak çapraz doğrulama yapmak çok şey öğretiyor. Bu süreç GitHub PR ve issue'larında, ayrıca Slack'te de kayıt altına alınıp organizasyonla paylaşılıyor
- Benim bilmediğimi başkası biliyor
- Bu kişi bu bilgiye/deneyime nasıl ulaştı? Bu sorunu hangi sinyalle fark etti?
- Benim hatalarım, bug'larım ya da kod tabanındaki anti-pattern'ler keşfediliyor
- Bu problemin ortaya çıkması kaçınılmaz hale getiren nedenler nelerdi? Bir dahaki sefere daha az hata yapmak ve hataları daha erken fark etmek için yapıyı nasıl iyileştirmek gerekir?
Kapanış
- AI'ın daha iyi yanıtlar vermesini sağlayabilirsek, ürün ekibinin yaşadığı sorunların önemli bir kısmı çözülür
- Kod tabanının kalitesini artırarak (en baştan iyi bir yola yönlendirerek) ve çeşitli araçlar devreye alarak (yanlış yolları engelleyerek)
- Ekip üyelerinin ajan tabanlı mühendislik yetkinliğini yükseltecek şekilde onlara destek olarak (iyi yaptıkları işleri istemek, zorlandıkları işlerde yardımcı olmak)
- AI ile akıllıca iş birliği yapıldığında, ekibin yetkinliği artıp iyi bir çalışma ortamı kurulduğunda, 'kalite artışı' ile 'özellik ekleme/iyileştirme hızındaki artış' aynı anda pekâlâ mümkündür
- 'Dışarıdan' iyi bir şey getirip yardım etmek yerine, 'içeride' birlikte keşfedip deneyelim. Ölçelim, görünür kılalım, kutlayalım ve birbirimizden öğrenelim
3 yorum
Meetup haberi de çıkmış.
[İzlenim] "Kore'de Claude bir numaralı kullanıcı ortaya çıktı"... Anthropic meetup etkinliğine gidince
https://n.news.naver.com/mnews/article/092/0002402940
Ayda yaklaşık 1,8 milyon won vay be
Bu, junior geliştiricilerin aktif katılımını ve gelişimini destekleyebilecek bir yöntem olarak da anlamlı görünüyor.
Evet, doğru haha o tarafta da çok çalışıyoruz.