Anthropic, Claude Code ile büyük ölçekli kod taşıma işlemlerini nasıl gerçekleştiriyor?

Kod göçleri, üretimdeki bir kod tabanını yeni bir dile taşıyan projeler, yakın zamana kadar çok yıllık girişimlerdi.

Geçtiğimiz ay içinde, Anthropic'teki bireysel geliştiriciler, onlarca ila yüz binlerce satır koddan oluşan 10 kod paketini Claude Fable 5, Claude Opus 4.8 ve dinamik iş akışları kullanarak taşıdı.

Jarred Sumner (@jarredsumner), Bun'un kurucu ortağı ve Anthropic'te Teknik Kadro Üyesi, Bun'u Zig'den Rust'a taşımak için Claude Code'u kullandı. Bir milyon satırlık kod, iki haftadan kısa sürede üretildi ve birleştirme öncesinde Bun'un mevcut test süitinin %100'ü CI'da başarıyla geçti. Birleştirme sonrasında on dokuz gerileme ortaya çıktı ve hepsi düzeltildi. Rust taşıması Haziran ayında Claude Code içinde yayınlandı.

Mike Krieger (@mikeyk), Anthropic Labs'in eş lideri, bir Python kod tabanını bir hafta sonu boyunca 165.000 satır TypeScript'e taşıdı. Bu, yüzlerce ajan, sekiz aşama kapısı, üç rakip inceleme turu ve her komutun çıktısını Python orijinaliyle karşılaştıran son bir eşlik kontrolü içeriyordu.

Claude Code'un yeni yetenekleri, bu uzun süredir ertelenen projeler için denklemi değiştiriyor. Aşağıda, bu göçlerin bize öğrettiklerinden yola çıkarak artık kullandığımız altı adımlık süreç yer alıyor.

Temel içgörü, kodu düzeltmediğinizdir. Kodu üreten süreci (döngüyü) düzeltirsiniz.

Dilleri neden ve ne zaman taşımalı

Ekipler, ilk kurulumları ile mevcut projeleri arasındaki ortam değişiklikleri nedeniyle göç başlatır. Ya bilinen bir ödünleşim sınırlayıcı hale gelmiştir, ya daha iyi bir yaklaşım ortaya çıkmıştır ya da orijinal ekosistem küçülmektedir.

Örneğin, Jarred başlangıçta Zig'i seçmişti çünkü C seviyesinde performansı radikal bir basitlikle sunuyordu, bu da tek başına bir kurucunun "LLM öncesi sıkışık bir Oakland dairesinde Bun'u 1 yılda yazması" için idealdi. Bu basitlik, burada yazdığı bilinen ödünleşimlerle birlikte geliyordu.

Bun'un CLI'sı aylık 10 milyondan fazla indirme alıyor ve Claude Code içinde yoğun olarak kullanılıyor.

Daha geçen çeyrekte bile, bu ödünleşimler yol haritasını dondurmayı ve kaynakları çok çeyrekli bir projeye ayırmayı haklı çıkarmaya yetmezdi. Çeyrekler veya yıllar boyunca iki paralel kod tabanını sürdürebilirsiniz ve eğer sonuç %90 eşlik ise, başladığınızdan daha büyük bir baş ağrınız olurdu.

Şimdi, en kötü senaryo, dalı silip tekrar denemektir.

Yine de haklı bir iş gerekçesi olması gerekiyor. Milyon satırlık göçler artık dört yıllık bir proje boyunca 3 ila 4 milyon dolarlık mühendislik kaynağına mal olmasa da, yine de on binlerce ila yüz binlerce dolar veya daha fazlasına mal oluyor. Örneğin, Bun göçü, API fiyatlandırmasında yaklaşık 165.000 dolar olan 5,9 milyar önbelleğe alınmamış girdi token'ı ve 690 milyon çıktı token'ı tüketti. Mike'ın taşımasının ana kısmı 27 milyon token'dı.

Jarred'in milyon satırlık PR'ı.

Ancak, göç durumunun artık varoluşsal olması gerekmiyor. Değişiklik günlüğünde bir yıllık bellek hatası yamaları veya kronik bir darboğaz, artık bunu haklı çıkarabilir.

Derleme adımı, Mike'ın projesinin itici gücüydü. Ekibinin üzerinde çalıştığı dahili araç, kullanıcılara tek bir binary olarak gönderiliyor. Bu binary'i Python araç zinciriyle üretmek, platform başına yaklaşık sekiz dakika sürüyordu ve her sürümde derleme matrisi boyunca toplam 30 dakikalık bir bekleme anlamına geliyordu. Taşımadan sonra, aynı derleme yaklaşık iki saniye sürüyor, binary 6 kat daha hızlı başlıyor ve ekip ayrı bir dağıtım hattını kullanımdan kaldırabildi.

Yapay zeka kod göçü denklemini neden değiştiriyor

Fable ve Opus 4.8, alt ajanlarla paralel iş akışlarını devretme, yönlendirme ve doğrulama konusunda özellikle iyiyken, belirtilen hedeflere doğru birden çok yol bulma konusunda da başarılıdır.

Büyük kod göçleri, bu gelişmiş modeller için özellikle etkili bir kullanım durumudur çünkü:

• İş paraleldir. Çalışma, dosyalar ve crate'ler gibi binlerce bağımsız birim üzerinde yürütülebilir, böylece ajanlar birbirini beklemek yerine aynı anda çalışabilir.
• Bağlam açık ve kapsamlıdır. Eski kod, model için harika bir spesifikasyon görevi görür.
• Yerleşik bir hakem vardır. Birçok büyük kod tabanı, ajanların çalışmalarını doğrulamak için kullanabileceği bir test süiti içerir.
• Kuyruk kendini yazar. Bir derleyici veya test çalıştırması başarısız olduğunda, bu bir ajanın düzeltmesi için bir sonraki öğe haline gelir.
• Tutarlılık ve uç durum işleme gerektirirler: incelemeciler, her bulgunun arkasındaki kuralı belirtir, böylece bir ihlal sessiz bir sapma yerine bir kuyruk öğesi haline gelir.

Büyük kod göçleri için altı adım

Ek ayrıntılar için Jarred'in blogunu okuyabilirsiniz.

Ön koşullar

Göç projenize başlamadan önceki bir ön koşul, güçlü bir yargıcın yerinde olmasıdır, aksi takdirde bir çıkış koşulunuz veya başarı ölçütünüz olmaz.

Bu yargıcı oluşturmak için:

• Mevcut testleri kategorize edin. Hangi testlerin harici çağrılar olarak ifade edilebilir olduğunu ve hangilerinin taşınmayacak dahili bileşenlere bağlı olduğunu belirlemek için Claude'u kullanın.
• Taşınabilirlik için yeniden yazın. Dışa dönük testleri, hem orijinal hem de taşınan sürüme karşı çalıştırılabilen iddialara dönüştürün. Yeniden yazılan testlerin iddiaları zayıflatmadığını doğrulamak için rakip ajanlar kullanın.
• Yargıcı doğrulayın. Geçtiğini onaylamak için orijinal koda karşı çalıştırın. Ardından, başarısız olduğunu onaylamak için kasıtlı olarak bozuk koda karşı çalıştırın — hatayı yakalamayan bir yargıç, yargıç değildir.

Bu, çoğunlukla Jarred'in metodolojisini takip eder ve her aşamada incelemeler ve kapılar bulunur. Mike benzer bir genel yapıyı benzer döngü iş akışları kullanarak izledi, ancak tüm göçü baştan sona çalıştırdı, kuralları ve iş akışını sonuçlara göre revize etti ve üçüncü çalışmaya kadar her seferinde çıktıyı atarak tekrar çalıştırdı.

Adım 1 — Kural kitabını, bağımlılık haritasını ve boşluk envanterini oluşturun

Sıra önemlidir: kural kitabı, boşluk envanterinden önce gelmelidir. Boşluk envanteri, kural kitabının varsayılanlarının kapsamayacağı şeyler tarafından tanımlanır ve ikisi birlikte ortak bir denetimde test edilir.

Kural kitabı

Kural kitabının tam şekli, başlangıçta yapmanız gereken önemli mimari kararlara bağlıdır. Bunların başında, yeni kodun aynı yapıyı mı izleyeceği yoksa tamamen yeniden mi tasarlanacağı gelir.

Birincisiyse (Jarred), kural kitabı öncelikle, daha zor çevrilecek bileşenler için boşluk envanterine işaret ederken diller arasında türleri ve deyimleri çeviren arama tabloları olacaktır. İkincisiyse (Mike), bir tasarım belgesi olacaktır.

Jarred, kural kitabını Claude ile sohbet ederek oluşturdu ve her belirsizlik alanı için bir politika oluşturdu. Ayrıca, kendi sezgilerine dayanarak 8 farklı yaygın hata modu kategorisini incelemek için özel olarak tasarlanmış sekiz alt ajan kullandı.

Bağımlılık haritası

Paralel bir göç için iş akışlarını etkili bir şekilde bölmek için dosya bağımlılıklarını anlamanız gerekir, böylece hangi dosyaların önce taşınacağını ve hangi dosyaların aynı toplu işte yer alacağını bilirsiniz. Claude Code, bu haritayı oluşturmak için deterministik bir komut dosyası oluşturmak ve çalıştırmak üzere ajanlar gönderebilir.

Boşluk envanteri ve şüpheci incelemeciler

Yeni dilin, eski dilden farklı gereksinimleri vardır ve bunların karşılanması gerekir. Zig'den Rust'a geçişte fark, manuel bellek yönetimiydi (C ve C++ aynı şekilde çalışır). Örneğin:

1// Zig
2
3fn readConfig(allocator: std.mem.Allocator) ![]u8 {
4    const buf = try allocator.alloc(u8, 1024);
5    // ...buf'u doldur...
6    return buf; // çağıran bunu serbest bırakmalıdır — ancak bunu yalnızca yorum söyler
7}
8
9// 'defer allocator.free(buf)' ifadesini unutan bir çağıran yine de derlenir — sızıntı yalnızca çalışma zamanında ortaya çıkar.

1fn read_config() -> Vec<u8> {
2    let buf = vec![0u8; 1024];
3    // ...buf'u doldur...
4    buf // sahiplik çağırana geçer; bellek otomatik olarak serbest bırakılır
5}
6
7// Taşındıktan sonra kullanmak mı? İki kez serbest bırakmak mı? İkisi de derlenmez.
8// Serbest bırakmayı unutmak mı? Unutulacak bir free çağrısı yok — drop otomatiktir.

Python'dan TypeScript'e geçişte fark, arayüzler ve sözleşmelerdi. Python, hangi şekilde bir nesneyi kabul edeceğini veya ne döndüreceğini bildiren bir sözleşme gerektirmez, ancak TypeScript gerektirir.

Hem Jarred hem de Mike, bu örtük bilgiyi yakalayan boşluk envanter dosyaları oluşturdu. Jarred bu boşlukları önceden envantere aldı, biz de burada bunu yapıyoruz. Mike ise önce çevirmeyi ve ardından denetim yaparak boşluk envanterini oluşturmayı seçti. Her ikisini de yapmanız gerekebilir.

Bir boşluk envanter dosyası oluşturmak için bu örnek Claude Code istemine göz atın.

Adım 2 — Kuralları zorlayın

Bu adımda Jarred, kural kitabını kullanarak üç dosyayı çevirmesi için bir ajan, "kıdemli bir Rust mühendisi gibi" üç dosyayı çevirmesi için bir ajan ve yeni çeviri kuralları oluşturmak için farkı kullanması için bir ajan kullandı. Bu aşamada, 1.448 dosyaya yayılırsa sayısız sorun yaratacak iki kritik sorunu yakaladı.

Bu tür bir zorlama testi, yalnızca yapıyı koruyan göçlerde işe yarar; burada aynı dosyanın iki çevirisi satır satır karşılaştırılabilir. Kural kitabınız Mike'ınki gibi bir yeniden tasarımsa, eşdeğer test, tasarım belgesine doğrudan rakip incelemecilerle saldırmak ve ardından tek kullanımlık bir uçtan uca çalıştırmayla doğrulamaktır.

Her durumda, çevrilmiş dosyaları atın. Amaç, kademeli ilerleme kaydetmek değil, kuralları iyileştirmektir.

Adım 3 — Her şeyi çevirin

Kalan adımlar için, aynı çoklu ajan döngü mimarisini çalıştırırsınız: uygula, incele ve düzelt.

Uygulayıcı işini daha küçük modellere devredebilir ve incelemecileri daha büyük modellerde tutabilirsiniz. Örneğin Mike, ana göç için 12 alt ajan gönderdiğinde Claude Sonnet'i kullandı.

İş kuyruğu mekanik olmalıdır. Bir toplu iş komut dosyası, çevrilmiş dosyanın diskte olup olmadığını kontrol ederek neyin bittiğine karar verir, ardından bekleyen dosyaları uygulayıcı ajanlar için gruplara ayırır. Kuyruk her seferinde diskten yeniden oluşturulduğu için, göç doğası gereği sürdürülebilirdir.

Çevirmenin güvenle yürütemeyeceği her şey, adım 4'te ele alınmak üzere "// TODO(port): <sebep>" ile işaretlenir.

İki rakip inceleyici, ayrı bağlamlar kullanarak uygulayıcıların çalışmalarını değerlendirir ve incelemeciler arasındaki anlaşmazlık üçüncü bir ajana gider. Bir inceleyici dosyalar arasında aynı hatayı yakalamaya devam ettiğinde, düzeltme dosya başına yapılmaz. Kural kitabına bir cümle ekler ve etkilenen grubu yeniden oluşturursunuz. Kural kitabı bu adım boyunca büyümeye devam eder; kod asla buna karşı elle yamalanmaz.

Bu adımda dikkat edilmesi gereken önemli bir tasarım kararı, derleyicinin nerede olduğudur. Mike, TypeScript derleyicisini her döngü içinde çalıştırdı çünkü bir birimi saniyeler içinde kontrol eder. Jarred, derleyiciyi döngüden tamamen çıkardı ve bir sonraki adıma erteledi çünkü cargo dakikalar alır.

Adımlar 4, 5, 6 — Derleyin, çalıştırın ve davranışı eşleştirin

Bu üç adım aynı döngü mimarisini paylaşır ve giderek daha az insan yargısı gerektirir, bu nedenle bunları birlikte ele alıyoruz.

Jarred bunu, tüm çalışma alanı boyunca derleyiciyi bir kez çağıran bir orkestratör komut dosyasıyla yürüttü. "Düzeltici ajanlar" daha sonra rakip incelemeyle paralel olarak hata listesini gözden geçirdi. Derleme yeniden çalışır, tekrar eder.

Hata listesini incelemek, ayarlama gerektirebilecek sistemik sorunları yakalamak için yararlıdır. Örneğin Jarred, Zig'in tembel derlemesinin tolere ettiği döngüsel içe aktarmaları düzelttikten sonra ortaya çıkan binlerce Rust modül hatasıyla karşılaştı. Hangi bağımlılığın silineceğini, taşınacağını veya sınırın yeniden yapılandırılacağını sınıflandırmak için mantığı kodlayarak döngüyü düzeltti.

Adım 5'in ayrıca derleyici hata listesine benzer mekanik bir doğruluk kaynağı vardır: duman testinden gelen çökmeler. Yine, döngü düzeltmesi, sorunları kategorilere ayırmaktı, bu durumda nedenleri, rakip alt ajanlar tarafından incelenen temel nedene göre gruplandırmaktı.

Adım 6 ve hikayemizin sonu, iki kod tabanı arasında programların davranışını karşılaştırmaktır.

Dosyalarımız artık çevrildi, derlendi ve duman testi yapıldı.

Şimdi onları parçalara ayırma ve (ön koşul aşamasından) test süitini onlara karşı çalıştırma zamanı. Başarısızlıkları, başarısız testleri her iki kod tabanına karşı inceleyen "düzeltici ajanlarla" ele alın. Rakip incelemeciler, düzeltmelerini kontrol eder.

Bu döngüdeki bir sonraki aşama, binary'i yeniden oluşturmasına izin verilen tek süreç olan bir derleme arka plan programıdır. Düzelticiler yamalar yazar; arka plan programı bunları gruplar, bir kez yeniden oluşturur, etkilenen testleri yeniden çalıştırır ve sonuçları geri besler. Bu, en pahalı işlemi seri hale getirir ve birden çok ajanın bağımsız olarak tetiklemesini önler.

Mike'ın yaklaşımı burada önemlidir, çünkü birçok geliştiricinin yerleşik veya taşınmış bir test süiti olmayacaktır. Mike, Claude'a hem yeni taşınan hem de orijinal Python kod tabanına karşı 7 gerçek dünya senaryosunu çalıştırmak için küçük bir komut dosyası oluşturttu ve sonuçların farkını aldı. Başarısız olan her senaryo kendi düzeltme ajanını aldı ve yedisi de geçene kadar döngü çalıştı.

Ardından bir adım daha ileri gitti. Claude, kendi uçtan uca test süitini tasarladı ve gece boyunca otonom olarak çalıştırdı, bozulanları düzeltti ve arka arkaya dört gece yeniden çalıştırdı. Sonuç olarak, hiçbir senaryo listesinin tahmin edemeyeceği küçük sorunları yakaladı.

Buradan çıkarılacak ders, eksik bir test süitinin bu adımı engellemediğidir. Bir hakemi devralamıyorsanız, Claude'a bir tane oluşturtun. Orijinal kod tabanınız her iki durumda da temel gerçekliktir.

Kod göçü en iyi uygulamaları

Her çalışma bize bir öncekinin öğretmediği bir şey öğretti. Ancak birkaç uygulama her projede geçerli oldu:

• Bu kılavuzu körü körüne takip etmeyin. Her göç farklıdır. Buna bir başlangıç noktası olarak davranın ve taahhüt etmeden önce belirli göçünüzü Claude ile planlayın.
• Bireysel başarısızlıklara odaklanmayın. Bireysel başarısızlıklar döngünün işidir. Dikkatiniz kalıplara ait olmalıdır.
• İncelemeyi rakip ve doğrulamayı mekanik yapın. Komut dosyalarının — bir derleyici, bir fark, bir test süiti — hakem olmasına izin verin.
• En büyük modeli her şey için kullanmayın. Daha küçük modeller, yüksek hacimli uygulama yayılımını iyi halleder; en büyük modelinizi incelemeciler ve diğer ajanların izleyeceği kuralları yazan her şey için saklayın.
• İnsan saatlerini önden yükleyin. Kural kitabı ve zorlama testi en çok zaman alan kısımlardır. Sonrasındaki her şey çoğunlukla kuyrukların tükenmesidir.

Kodu değil, döngü sonuçlarını inceleyin

Jarred'in Bun göçü artık üretimde, ancak her göçün ödünleşimleri vardır. Örneğin, Rust kodunun yaklaşık %4'ü "unsafe" blokların içinde yer alır, çoğunlukla C/C++ sınırlarında tek satırlık işaretçi işlemleridir.

Ancak yeni kod tabanı ölçülebilir şekilde daha iyidir. Ekibin araçlarının tespit edebildiği her bellek sızıntısı düzeltildi: 2.000 tekrarlı derlemenin bir kıyaslaması, bellek kullanımını 6.745 MB'tan 609 MB'a düşürdü. Binary, Linux ve Windows'ta %19 daha küçük. Ve diller arası optimizasyon, onu HTTP sunumu ve next build, tsc gibi gerçek dünya iş yüklerinde %2-5 oranında hızlandırdı.

Tolere ettiğiniz kod tabanını seçin ve Claude'a göç sürecinin bunun için nasıl göründüğünü sorun.