Cara Melakukan Migrasi Kode Skala Besar dengan Claude Code

 (claude.com)
1 poin oleh GN⁺ 1 jam lalu | Belum ada komentar. | Bagikan ke WhatsApp
  • Para developer Anthropic menggunakan Claude Fable 5, Claude Opus 4.8, dan workflow dinamis untuk memindahkan 10 paket kode berukuran puluhan ribu hingga ratusan ribu baris dalam sebulan terakhir; alih-alih memperbaiki kode satu per satu, mereka memperbaiki proses iteratif yang menghasilkan kode
  • Migrasi Bun dari Zig→Rust menghasilkan 1 juta baris dalam kurang dari 2 minggu dan lulus 100% test yang sudah ada sebelum merge; proyek Python→TypeScript memindahkan 165.000 baris selama akhir pekan dengan memanfaatkan ratusan agent, 8 gerbang bertahap, dan 3 tinjauan adversarial
  • Migrasi skala besar mudah diparalelkan, kode yang ada berperan sebagai spesifikasi sekaligus jawaban benar, dan kegagalan compile/test otomatis membuat antrean pekerjaan berikutnya, sehingga cocok untuk membangun loop verifikasi objektif
  • Proses dilakukan bertahap: menyiapkan kriteria penilaian, menyusun rulebook, peta dependensi, daftar gap, stress test aturan, translasi penuh, compile, eksekusi, hingga perbandingan perilaku; error berulang tidak diperbaiki per file, melainkan dengan memperbaiki aturan tingkat atas lalu meregenerasi
  • Biayanya masih puluhan ribu hingga ratusan ribu dolar atau lebih, tetapi branch yang gagal bisa dibuang dan dicoba ulang; migrasi Bun menghabiskan sekitar 165.000 dolar berdasarkan harga API, lalu mencapai penurunan penggunaan memori, ukuran binary 19% lebih kecil, dan peningkatan performa workload nyata 2–5%

Pendekatan memperbaiki loop generasi, bukan kodenya

  • Migrasi kode AI adalah cara agent memindahkan codebase produksi ke bahasa atau framework baru
    • Engineer menulis aturan migrasi dan loop verifikasi, bukan menerjemahkan file secara langsung
    • Agent mengulang translasi, compile, dan test sampai perilaku kode baru cocok dengan sumbernya
    • Proyek yang dulu memakan waktu bertahun-tahun dapat dipangkas menjadi hitungan minggu
  • Di Anthropic, Claude Fable 5, Claude Opus 4.8, dan workflow dinamis digunakan untuk memigrasikan 10 paket kode berukuran puluhan ribu hingga ratusan ribu baris dalam sebulan
  • Prinsip operasi utamanya bukan menambal langsung kode yang dihasilkan, melainkan memperbaiki loop yang membuat kode tersebut

Contoh migrasi nyata

  • Migrasi Bun dari Zig→Rust

    • Jarred Sumner memigrasikan Bun dari Zig ke Rust dengan Claude Code
    • Menghasilkan 1 juta baris kode dalam kurang dari 2 minggu
    • Lulus 100% test suite Bun yang sudah ada di CI sebelum merge
    • 19 regresi yang ditemukan setelah merge semuanya sudah diperbaiki
    • Port Rust dimasukkan ke Claude Code pada bulan Juni
    • Bun memiliki lebih dari 10 juta download bulanan dan juga digunakan secara luas di dalam Claude Code

  • Migrasi Python→TypeScript

    • Mike Krieger memigrasikan codebase Python menjadi 165.000 baris TypeScript selama akhir pekan
    • Menggunakan ratusan agent, 8 gerbang bertahap, dan 3 tinjauan adversarial
    • Melakukan pemeriksaan ekuivalensi akhir yang membandingkan output semua command dengan sumber Python
    • Ia berulang kali membuang seluruh hasil migrasi lalu memperbaiki aturan dan workflow; hasil eksekusi ketiga yang akhirnya dipakai

Kapan migrasi bahasa layak dipertimbangkan kembali

  • Migrasi dapat dipertimbangkan jika lingkungan teknologi telah berubah sejak pengembangan awal sehingga kompromi lama menjadi batasan, pendekatan yang lebih baik muncul, atau ekosistem aslinya menyusut
  • Zig menyediakan performa setara C dan kesederhanaan, cocok untuk fase awal ketika Bun dikembangkan sendirian, tetapi kesederhanaan itu punya kompromi yang diketahui
  • Dulu, migrasi bahasa mengharuskan penghentian roadmap dan alokasi sumber daya selama beberapa kuartal
    • Dua codebase mungkin harus dipelihara paralel selama beberapa kuartal atau bertahun-tahun
    • Jika kesesuaian perilaku akhir hanya 90%, beban maintenance bisa menjadi lebih besar daripada sebelum mulai
    • Kini ada opsi untuk menghapus branch yang gagal dan menjalankannya lagi
  • Migrasi 1 juta baris tidak lagi harus menuntut biaya engineering 3–4 juta dolar selama 4 tahun, tetapi tetap bisa memakan puluhan ribu hingga ratusan ribu dolar atau lebih
    • Migrasi Bun mengonsumsi 5,9 miliar token input tanpa cache dan 690 juta token output
    • Berdasarkan harga API, biayanya sekitar 165.000 dolar
    • Pada port Mike, bagian inti menggunakan 27 juta token
  • Alasan bisnis untuk migrasi tidak lagi harus sampai menentukan hidup-mati; memperbaiki bug memori yang berulang selama setahun atau satu bottleneck kronis saja bisa cukup menjadi pembenaran

  • Mengatasi bottleneck build Python

    • Tool internal Mike dikirim ke pengguna sebagai satu binary, tetapi membuat binary per platform dengan toolchain Python membutuhkan sekitar 8 menit
    • Pada seluruh matriks build, setiap rilis harus menunggu sekitar 30 menit
    • Setelah migrasi ke TypeScript, compile turun menjadi sekitar 2 detik, startup binary 6 kali lebih cepat, dan pipeline deployment terpisah juga dibuang

Mengapa agent AI cocok untuk migrasi

  • Pekerjaan paralel dimungkinkan
    • Pekerjaan dapat dipecah menjadi ribuan unit independen seperti file dan crate, lalu diproses banyak agent secara bersamaan
  • Kode yang ada berperan sebagai spesifikasi yang jelas dan komprehensif
    • Ini juga dapat digunakan sebagai referensi utama untuk membuat instruksi bagi agent penerjemah
  • Test suite berperan sebagai penilai bawaan
    • Jika verifikasi bersifat objektif, model dapat mengulang pekerjaan selama beberapa hari berdasarkan jawaban benar tanpa manusia terus-menerus menengahi kualitas
  • Kegagalan compile atau test otomatis menjadi item pekerjaan berikutnya, sehingga kebutuhan menulis antrean kerja terpisah berkurang
  • Konsistensi dan penanganan exception dapat dimasukkan ke dalam loop
    • Reviewer menghubungkan tiap masalah dengan aturan yang dilanggar
    • Cara menyelesaikan exception berubah menjadi aturan yang diikuti semua agent berikutnya
    • Alih-alih ketidakcocokan perilaku yang diam-diam, pelanggaran aturan menjadi item kerja eksplisit
  • Fable dan Opus 4.8 digunakan untuk mendelegasikan, mengarahkan, dan memverifikasi pekerjaan paralel sub-agent, serta mencari beberapa jalur menuju tujuan
  • Penggunaan token dioptimalkan dengan pola konsultasi yang menggabungkan beberapa kelas model

Prasyarat: menilai ekuivalensi sumber dan port

  • Sebelum memulai migrasi, dibutuhkan penilai yang kuat untuk mengevaluasi kode sumber dan target dengan standar yang sama
    • Tanpa penilai, tidak ada kriteria sukses maupun kondisi selesai
    • Test yang bergantung pada fungsi internal bahasa sumber mungkin tidak dapat dijalankan apa adanya pada kode target
  • Test yang ada diklasifikasikan menjadi test yang bisa diekspresikan sebagai panggilan eksternal dan test yang bergantung pada implementasi internal yang tidak akan di-port
  • Test perilaku eksternal ditulis ulang menjadi assertion yang dapat dijalankan di sumber maupun port
    • Agent adversarial memverifikasi bahwa assertion tidak melemah selama proses penulisan ulang
  • Jalankan penilai pada kode sumber untuk memastikan berhasil, lalu periksa juga apakah ia gagal pada kode yang sengaja dirusak
  • Jarred memiliki test suite besar yang ditulis dalam bahasa ketiga, yaitu TypeScript
  • Mike membuat harness ekuivalensi dengan 7 skenario penggunaan nyata dan memperlakukan setiap perubahan perilaku sebagai bug yang harus diperbaiki

Tahap 1: rulebook, peta dependensi, dan daftar gap

  • Artefak dasar bukan sekadar hasil translasi, melainkan daftar lokasi yang perlu direfaktor, rulebook cara menerjemahkan, dan peta dependensi yang menentukan urutan kerja
  • Urutan penyusunan penting
    • Nilai default rulebook harus ditentukan dulu agar item yang tidak bisa ditangani oleh default itu dapat didefinisikan sebagai daftar gap
    • Rulebook dan daftar gap divalidasi bersama lewat audit bersama

  • Rulebook

    • Bentuk rulebook berbeda tergantung apakah kode baru akan mempertahankan struktur lama atau didesain ulang sepenuhnya
    • Jika struktur dipertahankan seperti Jarred, pusatnya adalah tabel padanan antara tipe dan idiom lintas bahasa, sementara komponen yang sulit diterjemahkan merujuk ke daftar gap
    • Jika didesain ulang seperti Mike, rulebook berperan sebagai dokumen desain
    • Jarred berdiskusi dengan Claude untuk membuat kebijakan bagi setiap area ambigu, lalu menyusun 8 sub-agent agar masing-masing meninjau 8 kategori error yang diperkirakan

  • Peta dependensi

    • Dalam migrasi paralel, dependensi file harus dipahami untuk menentukan file mana yang dipindahkan lebih dulu dan file mana yang dimasukkan ke batch yang sama
    • Pada kode legacy tanpa manifest eksplisit dan codebase seperti C/C++ atau Python, dependensi harus ditemukan dan dipetakan secara langsung
    • Agent Claude Code dapat membuat peta melalui loop menulis, menjalankan, meninjau, dan memperbaiki script deterministik
    • Contoh umum dapat dilihat di prompt peta dependensi

  • Daftar gap bahasa dan reviewer skeptis

    • Daftar gap mencatat pengetahuan yang tersirat di kode lama tetapi harus dibuat eksplisit di bahasa target
    • Pada Zig→Rust, gap utamanya adalah cara manajemen memori
    • Di Zig, fakta bahwa caller harus membebaskan buffer bisa saja hanya ada di komentar; jika lupa dibebaskan, kode tetap compile dan leak baru ditemukan saat runtime
    • Di Rust, ownership berpindah ke caller dan memori dibebaskan otomatis; penggunaan setelah move atau double free tidak akan compile
    • Pada Python→TypeScript, gap utamanya adalah interface dan kontrak
    • Python tidak mengharuskan deklarasi bentuk objek yang diterima maupun nilai yang dikembalikan
    • Di TypeScript, kontrak untuk method, argumen, dan bentuk return harus ditulis agar compile
    • Jarred membuat daftar gap sebelum translasi, sedangkan Mike membuatnya setelah translasi pertama dalam proses audit; kedua pendekatan bisa digunakan tergantung proyek
    • Contoh umum dapat dilihat di prompt pembuatan daftar gap

Tahap 2: stress test aturan

  • Sebelum migrasi penuh, aturan diguncang dengan migrasi percobaan kecil untuk menemukan masalah
  • Jarred membandingkan tiga pekerjaan agent
    • Agent pertama menerjemahkan 3 file berdasarkan rulebook
    • Agent kedua menerjemahkan ukuran yang sama seolah-olah merupakan engineer Rust berpengalaman
    • Agent ketiga menulis aturan translasi baru berdasarkan perbedaan kedua hasil tersebut
  • Proses ini menemukan 2 masalah serius sebelum menyebar ke seluruh 1.448 file
  • Cara ini hanya bekerja pada migrasi yang mempertahankan struktur, karena dua hasil translasi file yang sama dapat dibandingkan baris demi baris
  • Jika didesain ulang seperti Mike, reviewer adversarial harus menyerang dokumen desain dan memverifikasinya lewat eksekusi end-to-end yang bisa dibuang
  • Semua file yang diterjemahkan dalam percobaan harus dibuang; tujuannya adalah memperbaiki aturan, bukan kemajuan kode secara bertahap
  • Contoh tugas umum dapat dilihat di prompt stress test

Tahap 3: translasi seluruh kode

  • Semua tahap berikutnya menggunakan loop multi-agent implementasi→review→perbaikan
  • Implementasi massal dapat diserahkan ke model kecil, sementara review ditangani model besar
    • Saat memparalelkan migrasi inti, Mike menggunakan 12 sub-agent Claude Sonnet
  • Antrean kerja dikelola secara mekanis
    • Script batch menilai status selesai dari keberadaan file hasil translasi di disk
    • File yang tersisa dibagi menjadi batch untuk agent implementasi
    • Setiap kali dijalankan, antrean dibangun ulang dari status disk, sehingga pada dasarnya bisa dihentikan lalu dilanjutkan
  • Jika agent terlalu berhati-hati dan hanya menangani sedikit pekerjaan, instruksi bisa dibuat lebih langsung dengan konteks bahwa compiler akan menangkap error pada tahap berikutnya
  • Item yang belum dapat ditangani dengan yakin ditandai sebagai // TODO(port): <reason> dan diselesaikan pada tahap 4
  • Setelah itu, daftar kerja dibuat otomatis dari error compile, crash smoke test, dan kegagalan test

  • Review adversarial dan pembaruan aturan

    • Dua reviewer adversarial dengan konteks independen mengevaluasi hasil implementasi, dan jika pendapat berbeda, agent ketiga memutuskan
    • Jika error yang sama berulang di banyak file, file tidak diperbaiki satu per satu
    • Tambahkan satu kalimat ke rulebook dan regenerasi batch yang terdampak
    • Rulebook terus berkembang bahkan selama tahap translasi, dan kode yang bertentangan dengan aturan tidak ditambal manual

  • Posisi compiler dalam batch

    • Jika waktu compile singkat, compiler dapat dimasukkan ke dalam loop translasi
    • Mike menjalankan compiler TypeScript di setiap loop karena compile per unit selesai dalam beberapa detik
    • Jika compile lama, tunda ke tahap berikutnya
    • Jarred melarang penggunaan compiler dalam loop translasi karena menjalankan cargo memakan waktu beberapa menit
    • Mulai tahap ini, prompt menjadi lebih pendek; contohnya dapat dilihat di prompt awal translasi

Tahap 4–6: compile, eksekusi, dan kecocokan perilaku

  • Ketiga tahap memiliki struktur loop yang sama, dan semakin ke belakang semakin sedikit penilaian manusia yang dibutuhkan
  • Tergantung bahasa dan skala proyek, tahap compile dapat diserap ke tahap translasi penuh

  • Tahap 4: Compile

    • Jarred mengonfigurasi script orkestrator agar menjalankan compiler sekali di seluruh workspace
    • Agent perbaikan memproses daftar error secara paralel, melewati review adversarial, lalu build ulang; proses ini diulang
    • Review daftar error digunakan untuk menemukan masalah sistemik, bukan error individual
    • Setelah circular import yang diperbolehkan oleh lazy compilation Zig diperbaiki, muncul ribuan error modul Rust
    • Logika untuk mengklasifikasikan dependensi mana yang dihapus, dipindahkan, atau batasnya direstrukturisasi ditambahkan ke loop

  • Tahap 5: Eksekusi dan smoke test

    • Crash yang terjadi dalam smoke test berperan sebagai jawaban mekanis seperti daftar error compile
    • Masalah tidak ditangani satu per satu, melainkan dikelompokkan berdasarkan akar penyebab lalu ditinjau sub-agent adversarial

  • Tahap 6: Membandingkan perilaku dengan sumber

    • Setelah translasi, compile, dan smoke test selesai, kode dibagi, lalu test suite yang disiapkan pada tahap awal dijalankan pada sumber dan port
    • Agent perbaikan meninjau test yang gagal bersama kedua codebase, dan reviewer adversarial memeriksa hasil perbaikannya
    • Batasi agar hanya build daemon yang boleh membangun ulang binary
    • Agent perbaikan menulis patch, dan daemon mengumpulkan patch lalu rebuild hanya sekali
    • Test yang terdampak dijalankan ulang dan hasilnya dikembalikan
    • Pekerjaan dibuat serial agar banyak agent tidak menjalankan build mahal masing-masing
    • Jika kegagalan yang sama berulang di banyak test, perbaiki aturan tingkat atas yang menciptakan bug itu dan regenerasi hanya file yang terdampak oleh aturan tersebut

  • Jika tidak ada test suite

    • Mike membuat Claude menghasilkan script kecil yang menjalankan 7 skenario nyata pada kode Python asli dan port baru lalu membandingkan hasilnya
    • Setiap skenario yang gagal diberi agent perbaikan terpisah dan proses diulang sampai ketujuhnya lulus
    • Claude juga merancang test suite end-to-end sendiri dan menjalankannya otonom semalaman
    • Pekerjaan memperbaiki error dan menjalankan ulang diulang selama empat malam
    • Daftar skenario yang ditulis sebelumnya juga menemukan masalah usability kecil yang sulit diprediksi
    • Meski tanpa test yang sudah ada, Claude dapat membuat penilai dengan menjadikan codebase sumber sebagai jawaban benar

Prinsip operasi yang terlihat dari eksekusi berulang

  • Alih-alih mengikuti panduan apa adanya, rencanakan migrasi bersama Claude sesuai karakteristik proyek sebelum mulai
  • Biarkan agent perbaikan menangani kegagalan individual, sementara manusia fokus pada pola error yang berulang
  • Susun review secara adversarial dan verifikasi secara mekanis
    • Review adversarial berguna untuk pekerjaan berdurasi panjang dan mungkin sepadan dengan konsumsi token tambahan
    • Gunakan script seperti compiler, diff, dan test suite sebagai penilai akhir
  • Jangan gunakan model terbesar untuk semua pekerjaan
    • Model kecil digunakan untuk memparalelkan implementasi massal
    • Model terbesar difokuskan pada review dan penulisan aturan yang akan diikuti agent lain
  • Waktu kerja manusia harus diinvestasikan di awal pada rulebook dan stress test; proses setelahnya sebagian besar adalah menghabiskan antrean
  • Status selesai harus bisa ditentukan secara mekanis, misalnya “file output ada di disk”, dan antrean harus dapat dilanjutkan

Hasil dan batasan migrasi Bun

  • Port Rust Bun sedang berjalan di produksi, tetapi sekitar 4% kode Rust berada di dalam blok unsafe
    • Sebagian besar adalah operasi pointer satu baris di batas C/C++
  • Semua memory leak yang dapat dideteksi tool sudah diperbaiki
    • Dalam benchmark yang mengulang build 2.000 kali, penggunaan memori turun dari 6.745MB menjadi 609MB
  • Ukuran binary Linux dan Windows turun 19%
  • Melalui optimasi lintas bahasa, performa workload nyata seperti layanan HTTP, next build, dan tsc meningkat 2–5%
  • Dalam migrasi skala besar, yang harus ditinjau adalah hasil yang dibuat loop dan pola iterasinya, bukan setiap baris kode yang dihasilkan

Materi terkait

Bacaan terkait

Belum ada komentar.

Belum ada komentar.