Deep Dive: Claude Code ย้ายโค้ดล้านบรรทัดใน 11 วัน

ล้านบรรทัดใน 11 วันเกิดขึ้นได้อย่างไร

วันที่ 16 กรกฎาคม 2026 Anthropic เผยกระบวนการที่ทีมใช้ทำ Large-scale Code Migration ด้วย Claude Code ครับ

กรณีที่ดังที่สุดคือ Jarred Sumner ผู้ร่วมก่อตั้ง Bun และสมาชิกทีมเทคนิคของ Anthropic ใช้ Claude Code ย้าย Bun จาก Zig ไป Rust

ตัวเลขจาก Anthropic ระบุว่า:

• ผลิต Rust Code ราวหนึ่งล้านบรรทัดในเวลาไม่ถึงสองสัปดาห์
• Test suite เดิมผ่าน 100% ใน CI ก่อน Merge
• หลัง Merge พบ 19 regressions ซึ่งแก้แล้ว
• Rust port ถูกนำไปใช้ใน Claude Code ตั้งแต่เดือนมิถุนายน

อีกกรณีคือ Mike Krieger จาก Anthropic Labs ย้าย Python codebase ไปเป็น TypeScript 165,000 บรรทัดในหนึ่งสุดสัปดาห์ โดยใช้ Agent หลายร้อยตัว, แบ่งงานผ่าน 8 phase gates, ใช้ adversarial review 3 รอบ และปิดท้ายด้วย parity check ที่เทียบ Output ของทุก Command กับระบบ Python เดิม

ถ้าอ่านแค่ตรงนี้ ข่าวจะฟังเหมือน “Coding Agent ทำโปรเจกต์หลายปีให้เสร็จในวันหยุด”

แต่พออ่านวิธีทำจริง ผมมองว่าบทเรียนสำคัญไม่ใช่จำนวน Agent ครับ

มันคือประโยคนี้:

อย่าซ่อม Code ทีละจุด ให้ซ่อม Process ที่ผลิต Code นั้นออกมา

เรื่องนี้เปลี่ยนสมการ Migration แต่ไม่ได้ทำให้ Migration ฟรี

Anthropic ประเมินว่าในอดีตการย้ายโค้ดระดับล้านบรรทัดอาจใช้ทรัพยากรวิศวกร 3 ถึง 4 ล้านดอลลาร์และกินเวลาราว 4 ปี

Bun migration รอบนี้ใช้ 5.9 พันล้าน uncached input tokens และ 690 ล้าน output tokens คิดเทียบ API Price ราว 165,000 ดอลลาร์

ตัวเลขนี้ถูกกว่าการทำโปรเจกต์หลายปีมาก แต่ก็ยังไม่ใช่เงินค่ากาแฟครับ

และต้องอ่านให้ถูกด้วยว่า 165,000 ดอลลาร์เป็น API-price-equivalent estimate ที่ Anthropic รายงาน ไม่ได้แปลว่า Bun จ่าย Invoice เท่านี้จริง

คำถามแรกจึงไม่ใช่ “Claude Code ทำได้ไหม”

แต่คือ “ปัญหาปัจจุบันแพงพอที่จะย้ายหรือยัง”

ตัวอย่างของ Bun มีเหตุผลทางธุรกิจชัดเจน ตัวระบบมีมากกว่า 10 ล้าน Downloads ต่อเดือนและถูกใช้หนักใน Claude Code ส่วนผลลัพธ์หลังย้ายก็วัดได้:

• Benchmark ที่ Build ซ้ำ 2,000 รอบ ใช้ Memory ลดจาก 6,745 MB เหลือ 609 MB
• Binary เล็กลง 19% บน Linux และ Windows
• HTTP Serving, next build และ tsc เร็วขึ้น 2 ถึง 5%

ส่วนโปรเจกต์ของ Mike มี Bottleneck ตอน Release เพราะ Python toolchain ใช้เวลาประมาณ 8 นาทีต่อ Platform หรือรวม 30 นาทีทั้ง Build Matrix หลังย้ายใช้เวลาราว 2 วินาที, Startup เร็วขึ้น 6 เท่า และเลิกใช้ Deployment Pipeline แยกได้

นี่คือวิธีคิดที่ดีครับ Migration ต้องมีตัวเลขก่อนและหลัง ไม่ใช่ทำเพราะภาษาใหม่กำลังมาแรง

ก่อน Step 1 ต้องมี Judge

Anthropic บอกชัดว่า ถ้าไม่มี Judge ที่แข็งแรง อย่าเพิ่งเริ่ม Migration

Judge ในที่นี้ไม่ใช่ Agent ที่เก่งที่สุดมานั่งอ่าน Code แล้วบอกว่า “Looks good”

มันคือกลไกที่รันกับระบบเก่าและระบบใหม่ด้วยเงื่อนไขเดียวกัน เช่น:

• Portable test suite
• API fixtures
• Command output diff
• Golden scenarios
• Performance benchmark
• Smoke test ที่จงใจทำให้พังแล้วต้องจับได้

วิธีตรวจ Judge ที่ผมชอบมากคือ:

1. รันกับระบบเดิมแล้วต้องผ่าน
2. รันกับ Code ที่จงใจทำให้ผิดแล้วต้องไม่ผ่าน

ถ้า Test จับ Code ที่จงใจทำให้พังไม่ได้ Test นั้นก็ยังไม่ใช่ Judge ครับ

ปัญหาคือ Test เดิมจำนวนมากผูกกับ Internal Function ของภาษาเก่า พอย้ายภาษา Function เหล่านั้นอาจไม่มีแล้ว

ทีมจึงต้องแยกว่าอะไรคือ Observable Behavior ที่ผู้ใช้หรือระบบอื่นเห็นจริง แล้วเขียน Assertion ที่รันเทียบได้ทั้งสองฝั่ง

6-Step Migration Loop จาก Anthropic

1) สร้าง Rulebook, Dependency Map และ Gap Inventory

อย่าเริ่มด้วยการแจกไฟล์ให้ Agent แปลครับ

เริ่มจากการตอบก่อนว่า Code ใหม่จะรักษาโครงสร้างเดิมหรือออกแบบใหม่

ถ้ารักษาโครงสร้างเดิม Rulebook จะคล้าย Lookup Table เช่น:

• Type นี้ใน Zig ไปเป็นอะไรใน Rust
• Error Handling แบบเดิมเปลี่ยนเป็น Pattern ไหน
• Library ตัวไหนใช้แทนกันได้
• Lifetime, Pointer และ FFI boundary จัดการอย่างไร

ส่วน Gap Inventory คือรายการที่แปลตรง ๆ ไม่ได้ เช่น Behavior ที่ซ่อนอยู่, Lazy Compilation, Cyclic Import, Runtime Flag หรือ Known Quirk ที่ระบบอื่นพึ่งอยู่

Dependency Map ทำหน้าที่จัดลำดับว่าอะไรต้องมาก่อนหลัง

ตรงนี้เหมือนวางผังย้ายบ้านครับ ถ้าขนของเข้าบ้านใหม่ก่อนต่อไฟต่อประปา เราจะได้กล่องเต็มบ้าน แต่ยังอยู่ไม่ได้

2) Stress-test Rulebook ด้วย Mini Migration

ก่อน Fan-out ไป 1,448 ไฟล์ Jarred ให้ Agent แปล Sample แค่ 3 ไฟล์ด้วย Rulebook แล้วให้อีก Agent แปลแบบ “Senior Rust Engineer” จากนั้นใช้ Diff สร้าง Rule ใหม่

ขั้นเล็ก ๆ นี้จับปัญหา Critical ได้ 2 เรื่องก่อนที่ข้อผิดพลาดจะกระจายไปทั้ง Repository

นี่คือหลัก ทดลองเล็ก แต่ตั้งใจหาจุดพัง

ถ้าเป็น Migration แบบ Redesign ที่เทียบไฟล์ต่อไฟล์ไม่ได้ ให้โจมตี Design Document ด้วย Reviewer แยก Context และลอง Disposable End-to-End Run แทน

3) ทำ Work Queue ให้ Mechanical และ Resumable

Queue ไม่ควรจำอยู่ในบทสนทนาของ Agent ครับ

Script ควรสร้างรายการ Pending จาก State บน Disk เช่น ไฟล์เป้าหมายมีแล้วหรือยัง, Test กลุ่มไหนผ่านแล้ว และ Batch ไหนต้องทำใหม่

ผลคือถ้า Session หยุดกลางทาง ระบบสามารถสร้าง Queue ใหม่จาก State จริงแล้วทำต่อได้

แต่ละ Batch ใช้รูปแบบ:

1. Implementer แปลหรือแก้
2. Reviewer สองตัวตรวจจาก Context แยกกัน
3. ถ้าสอง Reviewer ไม่ตรงกัน ส่งให้ตัวที่สามตัดสิน
4. ถ้าพบข้อผิดพลาดซ้ำ ให้เพิ่ม Rule แล้ว Generate Batch ที่เกี่ยวข้องใหม่

อย่าไล่ Hand-patch ทุกไฟล์ เพราะเราจะรักษาอาการ แต่ไม่รักษาสาเหตุ

4) Compile แล้วจัดกลุ่ม Error

Compiler เป็น Source of Truth ที่ดี แต่ตำแหน่งของมันใน Loop ขึ้นกับต้นทุน

กรณีของ Mike, TypeScript Compiler เร็วพอที่จะรันทุก Loop

กรณีของ Jarred, Cargo Build ใช้เวลาหลายนาที ถ้าปล่อยให้ Agent ทุกตัว Build เองพร้อมกัน เครื่องจะกลายเป็นร้านกาแฟที่ทุกคนสั่ง Espresso Shot เดียวกัน 64 แก้วครับ

วิธีที่เหมาะกว่าคือมี Orchestrator รัน Build รอบเดียว แล้วแยก Error List ให้ Fixer Agents ทำงานเป็นกลุ่ม

ถ้าเจอ Error แบบเดียวกันเป็นพันจุด อย่าแก้พันจุดก่อน ตรวจว่า Rulebook หรือ Architecture Boundary ผิดหรือไม่

5) Smoke Test แล้วจัด Crash ตาม Root Cause

หลัง Compile ผ่าน ให้เปิดระบบใน Controlled Environment และรันเส้นทางหลัก

อย่าแจก Crash หนึ่งอันต่อ Agent แบบไร้ภาพรวม เพราะ Crash หลายตัวอาจเกิดจาก Root Cause เดียวกัน

จัดกลุ่มก่อน เช่น:

• Module initialization
• Memory boundary
• Missing runtime behavior
• Configuration drift
• Dependency cycle

แล้วแก้สาเหตุ upstream เพื่อไม่ให้ Batch ถัดไปผลิตปัญหาเดิม

6) รัน Full Test และ Parity Loop

ขั้นสุดท้ายคือรัน Test Suite กับระบบใหม่ และเทียบ Behavior กับระบบเดิม

ถ้า Build แพง ให้มี Build Daemon ตัวเดียวรับ Patch จาก Fixers, Batch การ Rebuild และส่งผลกลับไปยัง Queue

ถ้าไม่มี Test Suite ที่ Port ข้ามภาษาได้ ก็ยังไม่จบเกมครับ

Mike ให้ Claude สร้าง Parity Harness จาก 7 Real-world Scenarios รันกับทั้ง Python และ TypeScript แล้ว Diff Output ทุกกรณี จากนั้นสร้าง Fixer แยกต่อ Scenario จนทั้งหมดผ่าน

หลังจากนั้น Claude ยังสร้าง End-to-End Tests เพิ่มและรันแก้ตอนกลางคืนต่อเนื่อง 4 คืน เพื่อจับ Paper Cuts ที่ Scenario เดิมไม่ครอบคลุม

ประเด็นไม่ใช่ให้ AI สร้าง Test แล้วเชื่อ AI อีกที แต่ให้ระบบเก่าเป็น Reference และให้ Output ที่ต่างกันกลายเป็นงานที่ต้องอธิบาย

Tests ผ่าน 100% แล้วยังมี Regression ได้

จุดที่ทำให้บทความนี้น่าเชื่อกว่าข่าว Success Story ทั่วไป คือ Anthropic ใส่ตัวเลขที่ไม่สวยไว้ด้วยครับ

Bun ผ่าน Test Suite เดิม 100% ก่อน Merge แต่หลัง Merge ยังพบ 19 regressions

และประมาณ 4% ของ Rust Code อยู่ใน unsafe blocks โดย Anthropic อธิบายว่าส่วนใหญ่เป็น Pointer Operation สั้น ๆ ที่ขอบเขต C/C++

ฝั่งนักพัฒนาก็มีเสียงวิจารณ์แรง โดยเฉพาะ Andrew Kelley ผู้สร้าง Zig ที่ตั้งคำถามเรื่องคุณภาพและ Reviewability ของ Code ที่ผลิตด้วย Agent จำนวนมาก

ผมมองว่าไม่ต้องเลือกว่าจะเชื่อฝั่งไหนทั้งหมดครับ

สิ่งที่ข้อมูลสองฝั่งบอกตรงกันคือ:

• AI ทำให้ปริมาณ Code เพิ่มเร็วมาก
• Existing Tests ช่วยได้มาก แต่ไม่เห็นทุก Behavior
• Code Review แบบอ่านล้านบรรทัดไม่ใช่ Strategy
• ทีมต้อง Review ผลลัพธ์, Known Differences, Runtime Metrics และ Regression หลัง Merge

คำว่า Done ของ Migration จึงไม่ใช่ “Agent บอกว่าเสร็จ” หรือ “CI เขียว” อย่างใดอย่างหนึ่ง

มันคือ Behavior สำคัญผ่าน, Known Difference ถูกบันทึก, Performance ถึงเป้า, Rollback ยังอยู่ และ Production Observation ไม่พบปัญหาที่รับไม่ได้

ทำไมไม่ควรให้ Model ตัวเดิม Review ตัวเองอย่างเดียว

งานวิจัยเดือนพฤษภาคม 2026 ชื่อ Articulate but Wrong ทดลอง Code Modernization 1,980 ครั้งกับ 11 โมเดลบนชุด Python 2 ที่มี Semantic Traps

ผลที่รายงานคือ:

• Semantic-preservation drift เกิด 39.7% ในกลุ่ม Semantic Trap เทียบกับ 7.0% ในกลุ่มควบคุม
• เมื่อให้โมเดลที่สร้างงาน Review ตัวเอง มันพลาด Semantic Drift ของตัวเอง 31.7%
• ราคาและความสามารถรวมของโมเดลไม่ได้ทำนาย Drift ได้เป็นเส้นตรง

นี่เป็น Benchmark ระดับ Code Snippet ไม่ใช่การ Audit Bun migration โดยตรงครับ

แต่บทเรียนสอดคล้องกันมาก: อย่าใช้ความมั่นใจของผู้สร้างเป็น Judge เพียงตัวเดียว

ใช้ Separate Context, Different Review Role และ Deterministic Oracle เมื่อทำได้

AI ช่วยเราออกแบบ Test ได้ แต่สิทธิ์ตัดสินต้องอยู่กับ Behavior ที่สังเกตได้

โปรเจกต์แบบไหนควรลองก่อน

Code Migration ด้วย Agent เหมาะเมื่อมีองค์ประกอบเหล่านี้:

1. Business pain ชัด เช่น Build ช้า, Memory Leak ซ้ำ, Ecosystem หด หรือ Hiring ยาก
2. ระบบเก่ายังรันได้ เพื่อใช้สร้าง Reference Output
3. งานแยกเป็น Unit ได้ เช่น File, Package, Endpoint หรือ Command
4. มี External Behavior ให้เทียบ ไม่ต้องพึ่ง Internal Function อย่างเดียว
5. มี Budget สำหรับ Compute และ Review ไม่ใช่ Token อย่างเดียว
6. ยอมลบ Branch ได้ ถ้า Mini Migration หรือ Business Case ไม่ผ่าน

ถ้ายังไม่มี Test, ไม่มี Fixture, ไม่มีคนรู้ว่า Behavior ไหนห้ามเปลี่ยน และ Production แก้ตรง ๆ โดยไม่มี Sandbox ผมไม่แนะนำให้เริ่มจาก “ย้ายทั้งระบบ” ครับ

เริ่มจาก Module หนึ่งตัวที่มี Input/Output ชัดก่อน

Operator Kit: AI Code Migration Readiness Canvas

คัดลอก Canvas นี้ไปกรอกกับโปรเจกต์ได้เลย

A. Business Case

ระบบ/Module ที่กำลังพิจารณาย้าย:
ภาษาเดิม -> ภาษาเป้าหมาย:
ปัญหาปัจจุบันที่วัดได้:
ต้นทุนต่อเดือน/Release:
ผลลัพธ์ที่คาดหลังย้าย:
งบ Token/Compute สูงสุด:
งบ Human Review:
เหตุผลที่ควรทำตอนนี้:
เงื่อนไขที่ทำให้ยกเลิกโครงการ:

B. Frozen Reference

Version/Commit ของระบบเดิม:
Runtime และ Environment:
Configuration ที่ใช้เป็น Golden Path:
Fixtures/Test Data:
Real-world Scenarios:
Metrics ก่อนย้าย:
Known Bugs ที่ต้องรักษาหรือแก้โดยตั้งใจ:

C. Judge Contract

Portable Tests ที่รันได้ทั้งสองฝั่ง:
Command/API Output ที่ต้องเท่ากัน:
State/Data ที่ต้อง Reconcile:
Performance Budget:
ตั้งใจทำให้พังแบบไหนเพื่อทดสอบ Judge:
ใครเป็นเจ้าของคำตัดสินสุดท้าย:

Checklist:

• [ ] Judge ผ่านกับระบบเดิม
• [ ] Judge จับ Deliberately Broken Version ได้
• [ ] Test ไม่ถูกแก้ให้อ่อนลงเพื่อให้ Code ใหม่ผ่าน
• [ ] ความต่างที่ตั้งใจอนุญาตถูกบันทึกแยก
• [ ] มี Scenario ที่ครอบคลุม Edge Case และ Failure Path

D. Rulebook และ Gap Inventory

Type/Idiom Mapping:
Library Replacement:
Error Handling:
Concurrency/Async Policy:
Memory/Pointer/FFI Policy:
Configuration/Feature Flags:
ส่วนที่แปลตรง ๆ ไม่ได้:
ส่วนที่ต้อง Redesign:
ส่วนที่ Out of Scope:

E. Mechanical Queue

State เก็บที่ไหน:
Done ของหนึ่ง Unit วัดอย่างไร:
Batch Size:
จำนวน Concurrent Agents:
Build/Compiler Strategy:
Implementer Role:
Reviewer Role:
Disagreement Resolver:
วิธี Resume หลัง Session หยุด:

F. Promotion Decision

Behavior Parity:
Known Differences:
Performance Result:
Security/Unsafe Review:
Cost จริงเทียบ Budget:
Open Regressions:
Rollback Plan:
Post-merge Observation Window:
Owner ที่ Approve:

เลือกผลลัพธ์หนึ่งข้อ:

• [ ] ยังไม่พร้อม ต้องสร้าง Judge ก่อน
• [ ] พร้อมทำ Mini Migration
• [ ] Mini Migration ผ่าน พร้อมขยายเป็น Batch
• [ ] ขยายแล้ว แต่ยังไม่พร้อม Merge
• [ ] พร้อม Merge พร้อม Rollback และ Observation Plan

ลองแบบ 7 วันก่อนคิดระดับล้านบรรทัด

สำหรับทีมทั่วไป ผมแนะนำ Pilot สั้น ๆ:

วัน 1: เลือก Module ที่มี Business Pain และ Freeze Reference

วัน 2: สร้าง Judge และทำ Deliberate Break Test

วัน 3: เขียน Rulebook กับ Gap Inventory

วัน 4: ทำ Mini Migration 3 ถึง 5 Units

วัน 5: Compare, Review และแก้ Process

วัน 6: รัน Compile, Smoke และ Parity Test

วัน 7: สรุป Cost, Review Load, Behavior Difference และตัดสินใจว่าจะขยายหรือลบ Branch

ถ้า Pilot ยังตอบไม่ได้ว่าระบบใหม่ “เหมือนเดิมตรงไหน ต่างอย่างตั้งใจตรงไหน และคุ้มตรงไหน” อย่าเพิ่งเพิ่ม Agent ครับ

เพิ่มความชัดก่อน แล้วค่อยเพิ่มความเร็ว

สรุป

Claude Code ทำให้ Code Migration ใหญ่เร็วขึ้นจริงครับ และตัวอย่างของ Bun แสดงให้เห็นว่าระดับล้านบรรทัดไม่จำเป็นต้องหมายถึงโปรเจกต์ 4 ปีเสมอไปแล้ว

แต่สิ่งที่ทำให้เรื่องนี้ใช้ได้จริงไม่ใช่ Prompt ลับหรือ Agent จำนวนมาก

มันคือระบบที่มี:

• Business Case ชัด
• Judge ก่อนเริ่ม
• Rulebook ที่โตจาก Failure จริง
• Queue ที่ Resume ได้
• Separate Reviewer Context
• Compiler, Smoke Test และ Parity Harness
• Post-merge Observation

ในความเห็นของผม ข่าวนี้ไม่ได้บอกว่า “ให้ AI ย้ายระบบแทนคน”

มันบอกว่า คนสามารถออกแบบโรงงาน Migration ที่ AI ทำงานซ้ำจำนวนมากให้ได้ โดยคนยังเป็นเจ้าของ Rule, Budget และคำว่า Done

ล้านบรรทัดใน 11 วันเป็นพาดหัวครับ

แต่ของที่ควรขโมยกลับไปใช้ คือ Judge หนึ่งตัว, Rulebook หนึ่งชุด และ Mini Migration หนึ่ง Branch