บริษัทพัฒนาซอฟต์แวร์จัดการงานอย่าง Asana เคยมีไฟล์เทสต์ค้างอยู่กว่า 4,000 ไฟล์ที่ยังใช้ Enzyme เครื่องมือเขียนเทสต์หน้าเว็บรุ่นเก่าที่ทำให้โค้ดอัปเกรดยากขึ้นเรื่อยๆ การย้ายโค้ดเทสต์เหล่านี้ออกจาก Enzyme เป็นงานที่ต้องไล่แก้ทีละไฟล์เป็นพันๆ ไฟล์ ทั้งน่าเบื่อและกินเวลามาก แถมทำเสร็จแล้วก็ไม่ได้ฟีเจอร์ใหม่ให้ผู้ใช้เห็น ทีมงานจึงจัดงานนี้ไว้ท้ายคิว เป็นงานประเภท "มีเวลาก็ค่อยทำ" และประเมินกันว่าถ้าทำไปเรื่อยๆ คงต้องใช้เวลาราว 5 ปีถึงจะเสร็จ

แต่เมื่อทีมงานตัดสินใจนำ Codex AI ช่วยเขียนโค้ดของ OpenAI มาช่วยไล่แก้ทีละไฟล์ ผลปรากฏว่าสามารถย้ายโค้ดออกจาก Enzyme ทั้งหมดได้สำเร็จในเวลาเพียง 2 สัปดาห์ โดยใช้วิศวกรเข้ามาช่วยตรวจสอบและดูแลจริงราวสัปดาห์ครึ่ง และจ่ายค่ารันโมเดลรวมค่าเซิร์ฟเวอร์ไปประมาณ 12,000 ดอลลาร์ สิ่งที่น่าสนใจจริงๆ จึงไม่ใช่แค่ตัวเลข 12,000 ดอลลาร์ แต่คือคำว่า 5 ปีที่เคยติดอยู่ในแผนเดิม ซึ่งสะท้อนว่างานกองนี้ไม่เคยหายไปไหน เพียงแต่ไม่เคยคุ้มค่าพอที่จะเริ่มลงมือทำด้วยแรงคน

งานย้ายระบบมักแพ้คิว ไม่ใช่เพราะทำไม่ได้

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

ก่อนยุค AI ต้นทุนการทำงานพวกนี้สูงมาก ตัวอย่างเช่นในปี 2021 บริษัทซอฟต์แวร์อย่าง Sentry ต้องใช้เวลานานถึง 1 ปีครึ่งเพื่อแปลงโค้ดส่วนแสดงผลหน้าเว็บจาก JavaScript ไปเป็น TypeScript ทั้งระบบ ซึ่งประกอบด้วยโค้ด 1,100 ไฟล์ รวม 95,000 บรรทัด และใช้วิศวกรราว 10 คน ถ้าคำนวณจากต้นทุนเฉลี่ยของวิศวกรที่ประมาณ 300,000 ดอลลาร์ต่อคนต่อปี โปรเจกต์นี้ก็มีต้นทุนสูงถึง 2-4 ล้านดอลลาร์ เพียงเพื่อปรับปรุงโค้ดเก้าหมื่นกว่าบรรทัด

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

Enzyme กับ React Testing Library มีวิธีคิดคนละแบบ

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

ลองดูตัวอย่างโค้ดเทสต์ของทั้งสองฝั่ง เพื่อตรวจสอบว่ากดปุ่มแล้วตัวเลขเพิ่มจาก 2 เป็น 3:

// Enzyme
const wrapper = mount(<Counter initialCount={2} />);
expect(wrapper.find('p').text()).toBe('Count: 2');
wrapper.find('button').simulate('click');
wrapper.update();
expect(wrapper.find('p').text()).toBe('Count: 3');

// React Testing Library
const user = userEvent.setup();
render(<Counter initialCount={2} />);
expect(screen.getByText('Count: 2')).toBeInTheDocument();
await user.click(screen.getByRole('button', { name: 'Increment' }));
expect(screen.getByText('Count: 3')).toBeInTheDocument();

ฝั่ง Enzyme เริ่มด้วยคำสั่ง mount() เพื่อสร้างออบเจกต์ wrapper จากนั้นจะตรวจสอบทุกอย่างผ่าน wrapper เช่น ใช้ wrapper.find('p') เพื่อเจาะดูแท็ก <p> ภายในโครงสร้างคอมโพเนนต์ และใช้ simulate('click') เพื่อจำลองการคลิกปุ่มโดยตรง สรุปคือ Enzyme ให้ความสำคัญกับโครงสร้างภายในของคอมโพเนนต์

ส่วน React Testing Library ไม่มีตัวแปร wrapper ให้เรียกใช้ แต่ใช้คำสั่ง render() เพื่อเรนเดอร์คอมโพเนนต์เป็นหน้าเว็บจริง แล้วค้นหาองค์ประกอบต่างๆ อย่างที่ผู้ใช้งานเห็น เช่น screen.getByText('Count: 2') เพื่อหาข้อความที่ปรากฏบนหน้าจอ หรือ screen.getByRole('button', { name: 'Increment' }) เพื่อหาปุ่มตามบทบาทและข้อความบนปุ่ม โดยไม่อ้างอิงโครงสร้างโค้ดภายใน

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

Airbnb ย้าย 3,500 ไฟล์ใน 6 สัปดาห์ ด้วยระบบที่ปล่อยให้ AI ลองผิดลองถูกเอง

อีกหนึ่งกรณีศึกษาที่เกิดขึ้นก่อนและมีรายละเอียดชัดเจนคือ Airbnb ที่เปิดเผยในเดือนมีนาคม 2025 ว่าใช้โมเดล AI อย่าง Claude 3.7 Sonnet ย้ายไฟล์เทสต์คอมโพเนนต์จำนวน 3,500 ไฟล์ออกจาก Enzyme ได้สำเร็จภายใน 6 สัปดาห์ จากเดิมที่เคยประเมินไว้ว่าถ้าทำด้วยมือทั้งหมดจะต้องใช้เวลาของวิศวกรถึง 1 ปีครึ่ง

สิ่งที่น่าสนใจจากบทความของ Airbnb Engineering ไม่ใช่แค่เรื่องตัวโมเดล แต่เป็นกระบวนการทำงานที่แบ่งออกเป็น 3 ขั้นตอน:

1. สร้างระบบให้ AI แปลงโค้ดแล้วรันเทสต์ซ้ำโดยอัตโนมัติ ถ้าเทสต์ไม่ผ่าน ก็ให้ AI อ่านข้อผิดพลาดแล้วลองแก้ใหม่ทันที ระบบนี้แปลงไฟล์ได้สำเร็จถึง 75% ของทั้งหมด 3,500 ไฟล์ ภายในเวลาเพียง 4 ชั่วโมง
2. สร้างกระบวนการเฉพาะสำหรับไฟล์ที่ซับซ้อน ไฟล์อีก 25% ที่แปลงไม่ผ่านในรอบแรกต้องใช้กระบวนการแปลงโค้ดที่รองรับกรณีเฉพาะมากขึ้น ทีมงานสร้างกระบวนการนี้แล้วปล่อยให้ระบบทำงาน 4 วัน ผลคือแปลงไฟล์กลุ่มนี้เพิ่มได้อีก 97%
3. วิศวกรเก็บงานส่วนสุดท้าย ไฟล์ที่เหลืออีกราว 3% ซับซ้อนเป็นพิเศษ วิศวกรเข้ามาแก้ไฟล์กลุ่มนี้ด้วยตนเองโดยมี AI คอยช่วย และใช้เวลาประมาณ 1 สัปดาห์

หัวใจสำคัญของความสำเร็จนี้ไม่ได้อยู่ที่การเขียน Prompt ให้สมบูรณ์แบบตั้งแต่แรก แต่อยู่ที่การสร้างระบบให้ AI รู้ผลทันทีเมื่อแปลงโค้ดผิดพลาด ซึ่งนี่คือแก่นของแนวคิด agent loop ที่ให้ AI ลงมือทำ ตรวจสอบผลลัพธ์ และแก้ไขตัวเองจนกว่างานจะเสร็จ งานย้ายเทสต์จึงเหมาะกับแนวทางนี้มากเป็นพิเศษ เพราะมีตัวชี้วัดความถูกต้องที่ชัดเจนอยู่แล้วจากการรันเทสต์ ซึ่งบอกได้ทันทีว่าโค้ดที่แปลงแล้วรันผ่านหรือไม่ผ่าน AI จึงมีข้อมูลไปแก้ต่อได้เองในรอบถัดไป

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

ตัวอย่างเช่น Uber ย้ายเทสต์ 600,000 ตัว บนโค้ด 15 ล้านบรรทัด จากเฟรมเวิร์กเขียนเทสต์ภาษา Java รุ่นเก่าอย่าง JUnit 4 เป็น JUnit 5 ได้สำเร็จภายใน 4 เดือน โดยใช้วิศวกรเพียง 2 คนทำงานร่วมกับ AI แก้ไขโค้ดไปถึง 1.25 ล้านบรรทัด คิดเป็นแรงคนรวมทั้งโปรเจกต์เพียง 8 เดือนเท่านั้น หรือโปรเจกต์ Bun ที่เป็นเครื่องมือรันโค้ด ก็แปลงโค้ดข้ามภาษาจาก Zig เป็น Rust ได้ถึง 530,000 บรรทัดในเวลา 2 สัปดาห์ ด้วยค่าเรียกใช้โมเดล AI ผ่าน API ราว 165,000 ดอลลาร์

ตัวเลข 5 ปีของ Asana ต้องอ่านบริบทให้ครบ

พาดหัวข่าวใน กรณีศึกษาจาก OpenAI ระบุว่า Asana ทำงานวิศวกรรมที่ต้องใช้เวลา 5 ปีเสร็จได้ใน 2 สัปดาห์ โดยเสียค่าใช้จ่ายเพียง 12,000 ดอลลาร์ เมื่อเทียบกับแผนเดิมที่ประเมินไว้สูงถึง 6 ล้านดอลลาร์ ตัวเลขนี้ดูน่าประทับใจจนจดหมายข่าวด้านวิศวกรรมซอฟต์แวร์อย่าง The Pragmatic Engineer ต้องเข้าไปสัมภาษณ์หัวหน้าทีมพัฒนาประสิทธิภาพวิศวกรของ Asana เพื่อเจาะลึกว่าตัวเลข 5 ปีนี้มีที่มาอย่างไร

คำอธิบายจาก ฝั่ง Asana เอง ช่วยให้เห็นภาพจริงมากขึ้น Asana เริ่มโปรเจกต์ย้ายออกจาก Enzyme มาตั้งแต่ปี 2024 และในรอบแรกใช้ AI ช่วยแปลงไฟล์ไปแล้วประมาณ 25% ของทั้งหมด ซึ่งเน้นเลือกไฟล์ที่คุ้มค่าที่สุดก่อน เช่น ไฟล์ที่แปลงง่ายหรือไฟล์ที่แก้บ่อย ส่วนไฟล์ที่เหลืออีกราว 75% ถูกจัดเป็นงานความสำคัญต่ำประเภท "มีเวลาก็ค่อยทำ" ซึ่งต้องต่อคิวรองจากงานย้ายระบบอื่นๆ ที่สำคัญกว่า

ดังนั้น ตัวเลข "5 ปี" จึงไม่ใช่เวลาที่วิศวกรต้องนั่งทำติดต่อกันเต็มเวลา แต่เป็นระยะเวลาโดยประมาณกว่างานก้อนนี้จะเสร็จตามลำดับความสำคัญในคิวงานจริง ส่วนตัวเลข "6 ล้านดอลลาร์" เป็นการคำนวณเบื้องต้น เริ่มจากนำเวลาเฉลี่ยที่ต้องใช้แปลงโค้ดด้วยมือทีละไฟล์มาคูณกับจำนวนไฟล์ที่เหลือกว่า 3,000 ไฟล์ จากนั้นรวมเวลาที่ต้องใช้ไล่ลบร่องรอยของเฟรมเวิร์กเก่าออกจากระบบเฝ้าติดตามการทำงานและเครื่องมือตรวจวิเคราะห์โค้ดอัตโนมัติ แล้วคูณด้วยอัตราค่าจ้างของวิศวกร

ประเด็นที่น่าสนใจคือ ทีม Asana ตั้งใจเลือกงานที่มีลำดับความสำคัญต่ำมาทดลอง เพราะต้องการพิสูจน์ว่า AI ช่วยย่นเวลาการย้ายระบบได้จริงหรือไม่ และงานที่ค้างคิวมานานแบบนี้ก็เป็นตัวเลือกที่เหมาะกับการทดสอบพอดี เพราะถ้าสำเร็จก็จะได้ข้อพิสูจน์ที่นำไปขยายผลต่อได้ทั่วทั้งองค์กร แม้ระยะเวลาจริงอาจเป็น 1 ปีครึ่งเหมือนเคสของ Airbnb ไม่ใช่ 5 ปีเต็ม แต่บทเรียนสำคัญก็ยังเหมือนเดิม นั่นคืองานที่เคยแพงเกินไปจนไม่คุ้มที่จะเริ่มทำในอดีต วันนี้เริ่มทำได้แล้วด้วย AI

งานแรกที่ควรส่งให้ AI Agent คือหนี้ทางเทคนิค ไม่ใช่ฟีเจอร์ใหม่

เมื่อต้องนำระบบอัตโนมัติอย่าง AI Agent มาใช้ในทีม ของใหม่มักดึงความสนใจไปก่อนเสมอ แต่ฟีเจอร์ใหม่มักขาดสิ่งที่ Agent ต้องการมากที่สุด นั่นคือ "นิยามความถูกต้องที่ชัดเจนตั้งแต่แรก" ในทางกลับกัน หนี้ทางเทคนิค หรือโค้ดเก่าที่ค้างอยู่ในระบบและรู้ว่าต้องแก้อย่างไร กลับมีเกณฑ์ความถูกต้องที่ชัดเจนอยู่แล้ว

ถ้าต้องการเริ่มใช้ AI Agent ลองสำรวจคิวงานในทีม แล้วเลือกงานที่ตรงกับเงื่อนไข 3 ข้อนี้:

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

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

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

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

ที่มา: บทความ The Pulse: We need to talk about migrations with AI จาก The Pragmatic Engineer