ไฟล์โค้ดภาษา Rust ไฟล์เดียวยาว 17,155 บรรทัด ไม่มีมนุษย์พิมพ์สักบรรทัด

มันรวมโค้ดฐานข้อมูลทั้งหมดของแอปราว 150,000 บรรทัด แอปนี้ให้เอเจนต์เขียนโค้ดทั้งหมด โดยใช้ Claude Code เป็นหลักและ Cursor เป็นบางครั้ง ผู้สร้างแอปคือ Giles Edwards-Alexander เขาเป็น CTO ของ Thoughtworks บริษัทนี้ให้คำปรึกษาด้านซอฟต์แวร์ ส่วนเขารับผิดชอบงานในยุโรป ตะวันออกกลาง รวมถึงอินเดีย

เขาใช้ไฟล์นี้วัดว่าโค้ดรกทำให้บิล AI แพงขึ้นแค่ไหน แล้วเขียนผลไว้บน martinfowler.com เขาสั่งให้เอเจนต์แก้โค้ดชิ้นเล็กด้วยคำสั่งหรือพรอมต์เดิมทุกรอบ ตอนโค้ดฐานข้อมูลยังอยู่ไฟล์เดียว เอเจนต์ต้องอ่านข้อความเข้าไปคิดเป็น 159,564 input token กว่าจะเสร็จ พอจัดโครงสร้างครบ 15 ขั้น งานเดิมใช้ 27,360 โทเคน ลดลง 83%

แต่ตัวเลขที่น่าจำไม่ใช่ส่วนลด โค้ดฐานข้อมูลลดจาก 17,155 เหลือ 16,608 บรรทัด แทบไม่ต่าง โค้ดไม่ได้หายไป สิ่งที่หายไปคือโทเคนที่เสียกับการอ่าน

โทเคนหมดกับการอ่าน ไม่ใช่การเขียน

เอเจนต์ไม่ได้เริ่มงานด้วยการเขียนโค้ด มันต้องหาของที่เกี่ยวข้องแล้วอ่านเข้าไปใหม่ก่อน ทุกตัวอักษรที่อ่านคือ input token ที่ต้องจ่าย

โค้ดฐานข้อมูลนี้หนักเป็นพิเศษ มีโค้ดท่อนเดิมซ้ำอยู่หลายแห่ง และโค้ดหลายหน้าที่ยังกองรวมกันแทบไม่แยกเป็นส่วนย่อย ส่วนที่แอปอื่นเรียกใช้ยังแยกจากโค้ดข้างในชัดเจน และต้องไม่ถูกแก้จนแอปอื่นใช้ไม่ได้ ข้างในคือโค้ด 17,155 บรรทัดติดกัน เอเจนต์ไม่รู้ว่าโค้ดที่ต้องแก้อยู่ตรงไหน ทางเดียวคือกวาดอ่านก้อนใหญ่

งานตัวอย่างอ่าน 159,564 โทเคน แต่เขียนราวสองพันโทเคน แม้โทเคนฝั่งเขียนแพงกว่าห้าเท่า แต่มีน้อยกว่ามาก บิลจึงขึ้นกับสิ่งที่เอเจนต์ต้องอ่าน ไม่ใช่สิ่งที่เขียน

context window จำกัดปริมาณเนื้อหาที่เอเจนต์อ่านและเก็บไว้พิจารณาได้ต่อรอบ วิศวกรทีม Claude Code ของ Anthropic เคยบอกว่าเพดานนี้คือข้อจำกัดสำคัญของงานซอฟต์แวร์ขนาดใหญ่ ไฟล์ยาวจึงเบียดพื้นที่สำหรับข้อมูลอื่นออกไปมาก

วัดได้เพราะเอเจนต์เริ่มใหม่จากศูนย์ทุกครั้ง

การพิสูจน์ว่าโค้ดสะอาดแล้วทำงานง่ายขึ้นเป็นเรื่องยาก เพราะคนที่ลงมือแก้ย่อมคุ้นกับโค้ดมากขึ้นเรื่อยๆ รอบสองจึงเร็วกว่ารอบแรกอยู่ดี ไม่ว่าโค้ดจะเปลี่ยนไปหรือเปล่า

เอเจนต์ไม่มีปัญหานี้ มันเริ่มจากศูนย์ทุกครั้งและจำไม่ได้ว่าเพิ่งเปิดไฟล์ไหน ข้อจำกัดนี้จึงกลายเป็นเครื่องมือวัดที่ยุติธรรม

เขาเริ่มจากเลือกงานที่ทำบ่อยมาเป็นตัวอย่าง งานนี้คือเพิ่มระบบติดตามรายการในโค้ดฐานข้อมูล ต้องเพิ่มฟังก์ชันในชุด ItemWatchStore สามตัว สำหรับเริ่มติดตาม (watch_item) ยกเลิกติดตาม (unwatch_item) และดูรายการที่ผู้ใช้ติดตาม (watched_items_for_user) แล้วทำให้ใช้ได้ทั้งกับฐานข้อมูลจริงและตัวจำลองสำหรับทดสอบ

จากนั้นให้เอเจนต์ตัวใหม่ที่จำรอบก่อนไม่ได้ลงมือ มันได้รับเพียงพรอมต์หนึ่งชุด โค้ดทั้งหมดของแอป และเอกสารที่อธิบายโครงสร้างระบบ พอเสร็จก็บันทึกตัวเลขแล้วทิ้งโค้ดที่แก้ทั้งหมด

ขั้นต่อไปคือจัดโครงสร้างโค้ดใหม่หนึ่งขั้น แล้วให้เอเจนต์ตัวใหม่ทำงานตามพรอมต์เดิม จดตัวเลขโทเคน เวลาที่ใช้ และจำนวนบรรทัดไว้ ก่อนทิ้งโค้ดที่แก้อีกครั้ง ทำซ้ำจนครบ 15 ขั้น จึงเปรียบเทียบผลของงานเดิมในแต่ละโครงสร้างได้โดยไม่มีความคุ้นเคยมาปน

ตัวเลขโทเคนเป็นค่าประมาณ ไม่ใช่บิลจริง Claude Code ยังรายงานจำนวนโทเคนระหว่างทำงานได้ไม่แม่นพอจะเชื่อถือ ทั้งที่คิดเงินเป็นโทเคนอยู่ทุกวัน วิธีที่ใช้แทนคือให้เอเจนต์นับตัวอักษรในข้อความที่อ่านเข้าไปและเขียนออกมา จากนั้นใช้ tiktoken ช่วยคำนวณโดยหารจำนวนตัวอักษรด้วยสี่ ตัวเลขนี้ใช้เทียบก่อนกับหลังได้ แต่ไม่ควรอ่านเป็นยอดเงินจริง

159,564 เหลือ 27,360 แต่โค้ดแทบเท่าเดิม

สองแถวแรกลดพร้อมกัน แต่แถวสุดท้ายแทบเท่าเดิม ผลจึงไม่ตรงกับคำอธิบายว่าเอเจนต์อ่านน้อยลงเพราะโค้ดน้อยลง โค้ดแค่ย้ายจากไฟล์ยักษ์ไฟล์เดียวไปอยู่ในไฟล์ Rust 19 ไฟล์ในโฟลเดอร์เดียวกัน

จำนวน input token ไม่ได้ลดทีละขั้น ช่วงแรกตัวเลขแทบเท่าเดิม พอเริ่มแยกไฟล์ใหญ่จึงดิ่งลง

เอเจนต์รู้แล้วว่าต้องเปิดไฟล์ไหน

ก่อนรีแฟกเตอร์ เอเจนต์รู้เพียงว่าโค้ดสำหรับเพิ่มระบบติดตามรายการอยู่ในไฟล์ 17,155 บรรทัด แต่ไม่รู้ว่าอยู่ช่วงไหน จึงต้องอ่านหาเอง

หลังรีแฟกเตอร์ โค้ดเดิมกระจายเป็น 19 ไฟล์ตามหน้าที่ มีทั้งคำสั่งดึงข้อมูล การแปลงข้อมูลเข้าออก ตัวจำลองสำหรับทดสอบ และไฟล์เก็บข้อมูลที่แยกตามกลุ่มงาน ชื่อไฟล์จึงเป็นป้ายบอกทาง เอเจนต์เปิดอ่านแค่ไฟล์ที่เกี่ยวกับงานตรงหน้า คนที่ทำการทดลองไล่อ่านบันทึกว่าเอเจนต์คิดอะไรและเปิดไฟล์ไหน แล้วพบว่าแต่ละขั้นมันอ่านโค้ดเป็นก้อนเล็กลงจริง

แต่อย่าอ่านผลนี้เป็นสูตรว่าไฟล์เล็กดีกว่าไฟล์ใหญ่ แล้วซอยไฟล์ยาวเป็นชิ้นเท่าๆ กัน เจ้าตัวมองว่าการหั่นแบบสุ่มคงช่วยได้ไม่เท่านี้ ต่อให้ไฟล์เล็กลง เอเจนต์ก็ยังต้องเปิดหลายไฟล์เพื่อหาโค้ด สิ่งที่ช่วยประหยัดคือแต่ละอย่างอยู่ในไฟล์ที่เดาตำแหน่งได้

ลำดับก็สำคัญ โทเคนลดแรงที่สุดช่วงท้ายที่แยกตัวเก็บข้อมูลเป็นไฟล์ย่อย แต่ขั้นก่อนไม่ได้เสียเปล่า ขั้นเหล่านั้นรวบโค้ดซ้ำและจัดโครงสร้างในไฟล์เดียว จนเห็นชัดว่าส่วนไหนทำงานร่วมกันและควรแยกไฟล์อย่างไร เจ้าตัวบอกว่าไม่ได้วางแผนให้ผลมาลงที่ขั้นนี้ มันเป็นผลจากลำดับรีแฟกเตอร์ตามปกติ

39.7 เซนต์ที่เจ้าตัวบอกว่าไม่เยอะ

ส่วนลด 83% ฟังดูมาก แต่พอตีเป็นเงินแล้วอยู่ที่ราว 39.7 เซนต์ต่อการแก้หนึ่งครั้ง ราคาของโมเดล Sonnet 5 ตอนนั้นอยู่ที่สามดอลลาร์ต่อหนึ่งล้านโทเคน เจ้าตัวก็บอกว่าไม่เยอะ

ประเด็นจึงอยู่ที่คำว่าต่อการแก้หนึ่งครั้ง หลังจากนี้ทุกงานที่แตะโค้ดก้อนนี้จ่ายน้อยลง ส่วนโค้ดที่ยังรกก็ทำให้เสียโทเคนอ่านใหม่ทุกครั้งที่กลับไปหา

ส่วนราคาของการรื้อโครงสร้างรอบนี้ไม่มีตัวเลขแน่นอน เพราะไม่ได้นับโทเคนของช่วงวางแผนและลงมือไว้ตั้งแต่ต้น รู้เพียงว่าไม่เกินห้าล้านโทเคน และยังรวมการวางแผนสองรอบ การออกแบบการทดลอง และงานอื่นช่วงเดียวกัน

งานนี้กินเวลาราวแปดชั่วโมง และเวลาเกือบทั้งหมดคือการปล่อยให้เอเจนต์ทำงานไปเอง เขาเข้าไปสั่งงานเพิ่มแค่ครั้งเดียว ตอนผ่านไปหกชั่วโมงสี่สิบนาที เพราะเอเจนต์ดูเหมือนเสร็จแล้ว แต่จริงๆ ข้ามขั้นตอนและต้องสั่งใหม่

ส่วนโทเคนฝั่งเขียนไม่ลด งานรื้อโครงสร้างครั้งนี้ไม่ได้ย่อโค้ดที่เอเจนต์เขียนออกมาให้สั้นลง งานเดิมยังใช้โทเคนฝั่งเขียนพอๆ กันตั้งแต่ต้นจนจบ ลดเพียงโทเคนที่ใช้ตอนอ่าน ถ้าอยากกดบิลให้อยู่ในกรอบตั้งแต่วันนี้ นั่นเป็นงานของการวางกติกาและเครื่องมือคุมงบตอนปล่อยเอเจนต์ทำงานเอง ซึ่งเป็นคนละเรื่องกับการจัดโครงสร้างโค้ด

ข้อสำคัญคือ ทั้งหมดนี้มาจากการทดลองเพียงรอบเดียว บนแอปใหม่ที่มีนักพัฒนาดูแลอยู่คนเดียว ผลจะเหมือนกันไหมในโค้ดเบสเก่าที่ซับซ้อน หรือถ้ารีแฟกเตอร์ทั้งโปรเจกต์แล้วจะคุ้มแค่ไหน ยังเป็นคำถามที่การทดลองนี้ทิ้งไว้ให้ตอบต่อ

Claude Code ยังไม่รู้เองว่าควรรีแฟกเตอร์ตรงไหน

Claude Code ทำตามพรอมต์ตรงตัว สั่งอะไรก็ทำตาม มันเลือกเองไม่ได้ว่าควรรื้อโครงสร้างอย่างไร ระบบพัฒนาแอปนี้มีขั้นตอนรีแฟกเตอร์อยู่แล้ว แต่ไม่เคยทำให้เอเจนต์แตะไฟล์ 17,155 บรรทัด ไฟล์จึงโตต่อไปทั้งที่มีเครื่องมือจัดโครงสร้างโค้ดอยู่

แผนยังต่างกันตามช่องทาง เมื่อขอแผนผ่าน Claude Code ขั้นแรกที่ได้มีเพียงการแยกโค้ดบางส่วนเป็นฟังก์ชันย่อย แต่เมื่อขอผ่านหน้าเว็บ Claude.ai กลับได้ข้อเสนอให้แยกทั้งคลาสออกเป็นส่วนใหม่ ซึ่งเปลี่ยนโครงสร้างได้มากกว่า

ตอนลงมือ เอเจนต์ใช้สคริปต์ Python สั่งให้ grep กับ sed ค้นและแทนข้อความ จึงสับสนเรื่องการเยื้องบรรทัดบ่อย ส่วนขั้นที่มีค่าที่สุดอย่างการแยกตัวเก็บข้อมูลเป็นไฟล์ย่อยกลับถูกข้ามในรอบแรก ต้องย้อนมาทำทีหลัง จำนวนขั้นที่วัดจึงไม่ตรงกับแผนแรก

ผลจึงสวนทางกับความหวังว่าเอเจนต์จะดูแลความสะอาดของโค้ดเอง คนยังต้องชี้ว่าจะรื้อตรงไหนและอย่างไร เอเจนต์เป็นแรงงานที่ทำตามคำสั่งได้เร็ว

เริ่มจากไฟล์ที่ยาวผิดปกติในโปรเจกต์

ถ้าคุณให้ AI ช่วยเขียนโค้ดอยู่ทุกวัน แล้วโควตาหรือโทเคนหมดเร็วขึ้นเรื่อยๆ ลองทำสามอย่างนี้

• หาไฟล์ที่ยาวผิดสังเกต ดูว่าไฟล์ไหนทำให้เอเจนต์ต้องกวาดอ่านทั้งไฟล์ทุกครั้งที่สั่งงาน ไฟล์นั้นมักเป็นจุดที่เสียโทเคนอ่านมากที่สุด
• ค่อยๆ แยกไฟล์ อย่าซอยทีเดียว รวมโค้ดซ้ำในไฟล์ก่อน แล้วแยกเป็นไฟล์ตามหน้าที่ ทดสอบทุกขั้นเพื่อให้ย้อนกลับได้หากมีปัญหา
• ชี้เป้าเอง อย่ารอโมเดลเสนอ คนที่รู้ว่าโค้ดส่วนไหนถูกแก้บ่อยที่สุดคือคุณ ไม่ใช่โมเดล AI

ถ้าอยากได้ตัวเลขของโปรเจกต์ตัวเอง ก็ใช้วิธีเดียวกัน เลือกงานที่ทำบ่อยหนึ่งชิ้น เขียนพรอมต์ไว้ใช้ซ้ำ วัดก่อนรีแฟกเตอร์ แล้ววัดอีกครั้งด้วยพรอมต์เดิมหลังรีแฟกเตอร์ ทิ้งงานทั้งสองรอบ เพราะต้องการตัวเลข ไม่ใช่โค้ด

เอเจนต์ลืมทุกอย่างทุกรอบ

สิ่งที่ทำให้การทดลองนี้วัดผลได้ กับสิ่งที่ทำให้บิลแพง เป็นเรื่องเดียวกันพอดี นั่นคือเอเจนต์ที่ไม่จำว่าเมื่อวานเปิดไฟล์ไหนไปบ้าง

ตอนนี้โครงสร้างโค้ดไม่ได้ช่วยแค่คนที่มารับช่วงต่อ มันยังเป็นคำใบ้ให้เครื่องมือที่ลืมทุกอย่างเมื่อเริ่มงาน และต้องกลับมาอ่านคำใบ้เดิมทุกครั้งที่สั่งงาน

---

ที่มา: บทความ The Economic Benefit of Refactoring จาก martinfowler.com