รายงานภาคสนาม 8 เคสจริง: coding agent เร่งซอฟต์แวร์วิทยาศาสตร์ได้ 60 เท่า แต่ตัดสินไม่ได้ว่าวิทยาศาสตร์ถูกหรือผิด

(หมายเหตุ: รายงานนี้เผยแพร่เมื่อ 28 กรกฎาคม 2026 เราตามเก็บช้ากว่าปกติ แต่เนื้อหาละเอียดพอที่จะคุ้มค่าอ่านย้อนหลัง)

รายงานส่วนใหญ่ที่บอกว่า “AI ช่วยเขียนโค้ดได้ดีแค่ไหน” วัดกันบนเบนช์มาร์กสังเคราะห์ รายงานฉบับนี้ต่างออกไป: Scientific computing in the age of agentic AI: an exploratory field report เก็บ 8 เคสที่ทีมจริงเอา coding agent ไปแก้ซอฟต์แวร์วิทยาศาสตร์ที่ใช้งานจริงอยู่ ส่วนใหญ่ในสายชีววิทยาเชิงคำนวณ แล้วให้เจ้าของงานแต่ละคนเขียนสะท้อนบทเรียนเอง

ผู้เขียนมี 21 คนจาก OpenAI, UNC Chapel Hill, Allen Institute for AI, Open Athena AI Foundation, Garvan Institute, University of Maryland, Seqera, Altos Labs, Helmholtz Munich, NVIDIA, MinosAI, Chicago Booth, Harvard Medical School และ Dana-Farber

โจทย์ที่รายงานตั้งไว้ตรงประเด็นสำหรับใครที่เคยแตะโค้ดวิจัย: ซอฟต์แวร์วิทยาศาสตร์มักถูกเขียนโดยทีมเล็กภายใต้แรงจูงใจที่ให้รางวัลกับ “ผลงานตีพิมพ์” มากกว่า “การดูแลระยะยาว” ผลคือหนี้ทางเทคนิคกองพะเนิน — และนั่นคือสิ่งที่ agent น่าจะเก่ง เพราะมันคืองานที่ต้องใช้แรงงานวิศวกรรมเยอะแต่ไม่ต้องการไอเดียใหม่

ตัวเลขที่ได้จริง

ผลลัพธ์กระจายกว้างมาก ตั้งแต่ปรับ build system เฉย ๆ ไปจนถึงเขียนไลบรารีใหม่ทั้งตัว:

โปรเจกต์	สิ่งที่ทำ	ผล
RustQC	รวมเครื่องมือ QC 15 ตัวของ RNA-seq เขียนใหม่เป็น Rust	ชุดข้อมูล paired-end มนุษย์ 186 ล้าน read: 15 ชม. 34 นาที → 14 นาที 54 วินาที (>60 เท่า) ดิสก์ I/O 2.5TB → 0.1TB
HelixForge	เขียน BamSurgeon ใหม่ให้รันบน GPU	ขั้นตอน editing เร็วขึ้น 98.6 เท่า, end-to-end 59.6 เท่า (1,609.6 วินาที → 27.0 วินาที)
rustar-aligner	เขียน STAR (C/C++ กว่า 20,000 บรรทัด) ใหม่จากศูนย์เป็น Rust	ความตรงกับ STAR 99.815% (single-end) / 99.883% (paired-end)
MHCflurry	ย้าย backend จาก TensorFlow ไป PyTorch	แก้เกือบ 10,000 บรรทัดใน ~130 ไฟล์ ออกเป็น MHCflurry 2.2.0 โหลดน้ำหนักเดิมได้ไม่ต้องเทรนใหม่
bayesm → bayesm-rs	เขียนแพ็กเกจ R ใหม่เป็น Rust	เร็วขึ้น 2–20 เท่า (เคส camera: 2.31× เธรดเดียว / 4.35× แปดเธรด ที่ R=100,000 และ 2.71× / 9.51× ที่ R=200,000)
hifiasm	ปรับประสิทธิภาพตัวประกอบจีโนม	ลดเวลารัน 25.1% บนเบนช์มาร์กสังเคราะห์ 200Mb (~15% บนข้อมูลมนุษย์)
cyvcf2	ปรับ build system ให้ทันสมัย	ส่ง patch ให้ maintainer เดิมพิจารณา
HI.SIM	ปรับไลบรารีจำลองพันธุกรรม	ลดเวลารัน ~31% และเป็น เคสเดียวที่แทบไม่มีมนุษย์แทรกแซง หลังตั้งต้น

เครื่องมือที่ใช้ปนกันหลายตัว: Claude Code (Sonnet 4.5/4.6), Codex, GPT-5.2, GPT-5.5 Pro และ GPT-5.6 — ไม่ใช่การเชียร์เครื่องมือใดเครื่องมือหนึ่ง

ตัวเลข RustQC น่าสนใจเป็นพิเศษ เพราะ Philip Ewels (Seqera) ระบุว่าผลลัพธ์ เทียบเท่าเชิงตัวเลขและใช้ร่วมกับ MultiQC ได้ ทำให้การสลับ pipeline เดิมมาใช้เป็นแค่การแก้ config บรรทัดเดียวและย้อนกลับได้ นอกจากนี้การเขียนใหม่ตัวอื่นก็ได้ผลด้วย — Trim Galore เร็วขึ้น 7 เท่า, FastQC-Rust เร็วขึ้น 3 เท่า และเขาเอาบทเรียนกลับไปแก้ FastQC ตัว Java ต้นฉบับจนได้ 3 เท่าเท่ากัน

บทเรียนที่มีค่าที่สุด: ให้ agent สองตัวเถียงกัน

เคส MHCflurry เป็นเคสที่มีรายละเอียดวิธีทำงานมากที่สุด และเป็นเคสที่ผมคิดว่านักพัฒนาควรอ่าน

ทีมพยายามย้าย MHCflurry ออกจาก TensorFlow/Keras ที่ไม่มีคนดูแลแล้วมาหลายรอบ — รวมถึงความพยายามด้วย agent ตั้งแต่ต้นปี 2025 โดยใช้ aider กับ Claude 3.5 Sonnet และ o1 ซึ่ง ล้มเหลว ผู้ทำ (S.F.) เขียนตอนปิด PR ว่า “ผมได้เรียนรู้ว่าการสร้างโค้ดด้วย AI มันไร้เดียงสาแค่ไหน ถ้าคุณปล่อยให้มันเล่าเรื่องของตัวเองโดยไม่ตั้งคำถามซ้ำแล้วซ้ำอีก และไม่เรียกร้องเทสต์/ดีบัก/log/การวิเคราะห์เพิ่ม” — และมองย้อนกลับหนึ่งปีเขาสรุปว่าคอขวดอยู่ที่ ความสามารถของโมเดล ไม่ใช่ harness

รอบที่สำเร็จเกิดขึ้นช่วงปลายมกราคมถึงกลางมีนาคม 2026 ด้วยรูปแบบที่รายงานเรียกว่า “adversarial pairing”: ให้ Claude Code กับ Codex สลับบทบาทกันเป็นผู้เขียนและผู้รีวิว ทีมตัดสินใจดึง Codex เข้ามาเป็นตัวที่สองหลังจากทำงานด้วย Claude Code ตัวเดียวแล้วยังติดปัญหาเชิงตัวเลขที่ละเอียดอ่อนอยู่นาน บทเรียนที่เขาเขียนไว้ตรง ๆ คือ

“การจับคู่แบบปฏิปักษ์ชนะการใช้ agent ตัวเดียว การให้ Claude Code กับ Codex สลับบทบาทผู้เขียน/ผู้รีวิว ดูจะช่วยให้หลุดจากจุดตัน เพราะ agent สองตัวจับ error คนละแบบในการรีวิวของมัน”

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

อีกบทเรียนที่ใช้ได้ทันที: กำหนดเกณฑ์การยอมรับเป็นตัวเลข ทีม MHCflurry ตั้งเกณฑ์ว่าต้องได้ค่าต่างสัมพัทธ์และสัมบูรณ์เล็กมากในทุกปริมาณที่โมเดลทำนาย บนชุด allele/peptide ที่กำหนดไว้ล่วงหน้า (ตรวจจริง 315 คู่ allele-peptide) และ รักษาความเข้ากันได้ย้อนหลัง — เขียน loader ให้โค้ดใหม่อ่านน้ำหนักเก่าได้ ทำให้เทียบความเท่ากันบนโมเดลที่ปล่อยจริงแทนที่จะต้องเทรนใหม่

คอขวดย้ายไปอยู่ที่ “การตรวจสอบ”

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

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

รายละเอียดที่หนุนข้อสรุปนี้กระจายอยู่ทุกเคส:

• rustar-aligner — การไต่จาก 90% parity ขึ้นไปต้องอาศัยการไล่ trace อย่างระมัดระวัง ไม่ใช่แค่บอก agent ให้ “แก้ให้ตรงขึ้น”
• RustQC — ต้องตรวจกับข้อมูล sequencing สาธารณะจริงหลายสิ่งมีชีวิตและหลายวิธีเตรียมไลบรารี เพราะ edge case จำนวนมากโผล่เฉพาะตอนรันที่สเกลจริง ชุดข้อมูลเล็ก ๆ ไม่พอ และช่วง “แก้ให้ output ตรงเป๊ะ” กินเวลาอีกหนึ่งเดือน ทั้งที่งานเริ่มต้นใช้เวลาแค่ไม่กี่วัน
• bayesm-rs — เวอร์ชันแรกของการเขียน bayesm.HART ใหม่กลับ ช้ากว่าเดิม 3.6 เท่า (50.0 วินาที เทียบกับ 13.9 วินาที เธรดเดียว) เพราะรูทีนหนึ่งไปสร้างเมทริกซ์ใหญ่ใหม่ซ้ำ ๆ หลังแก้แล้วจึงเร็วขึ้น 2.6 เท่า — ตัวอย่างที่ดีว่า “เขียนใหม่เป็น Rust” ไม่ได้แปลว่าเร็วขึ้นโดยอัตโนมัติ
• hifiasm — GPT-5.2 ไม่ค่อยเก่งเรื่องจัดลำดับความสำคัญ ผู้เขียนสังเกตว่ามันทุ่มเวลากับจุดที่ให้ผลตอบแทนน้อย และบางครั้งติดอยู่กับแนวทางที่มองแคบ

รูปแบบร่วมของทุกเคส (ยกเว้น HI.SIM) คือ มนุษย์เป็นคนตั้งเป้าที่วัดได้อย่างอิสระ ก่อนจะยอมรับว่างานเสร็จ — MHCflurry เทียบกับ prediction จากน้ำหนักที่ปล่อยแล้ว, hifiasm ใช้ workload ที่กันไว้กับเกณฑ์ลำดับ read ที่กำหนดล่วงหน้า, rustar-aligner เทียบพฤติกรรมระดับ read กับ STAR, RustQC เทียบ output ทั้ง pipeline

และรายงานทิ้งคำถามที่ยังไม่มีคำตอบไว้: ใครจะดูแลของที่เขียนใหม่ต่อ cyvcf2 เลือกส่ง patch กลับให้ maintainer เดิม ส่วน rustar-aligner แยกเป็นโปรเจกต์ใหม่เพราะ STAR ไม่มีคนดูแลแล้ว รายงานเตือนว่าการเขียนใหม่ด้วย AI เสี่ยงจะกลายเป็น “โค้ดร้างของวันพรุ่งนี้” ถ้าไม่มีแผนความเป็นเจ้าของที่ชัดเจน

มุมมอง AI Curator

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

สำหรับทีมไทย ผมเห็นสามอย่างที่เอาไปใช้ได้เลยโดยไม่ต้องอยู่ในวงชีวสารสนเทศ

หนึ่ง — งานที่ควรให้ agent ทำก่อน คืองาน migration ที่มีของเดิมเป็นตัวเทียบ ระบบเก่าที่ยังรันอยู่ในองค์กรไทยเยอะมาก: PHP รุ่นเก่า, Python 2, สคริปต์ ETL ที่ไม่มีคนกล้าแตะ, รายงานที่ผูกกับไลบรารีที่ตายไปแล้ว งานพวกนี้คือจุดที่รายงานแสดงว่าได้ผลจริง เพราะเราตรวจได้ว่า output เหมือนเดิมไหม ต่างจากงาน greenfield ที่ไม่มีอะไรให้เทียบ

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

สาม — adversarial pairing เป็นแพตเทิร์นที่ลองได้ทันทีและแทบไม่มีต้นทุนเพิ่ม ทีมไทยส่วนใหญ่ผูกกับ agent ตัวเดียวเพราะซื้อ subscription ตัวเดียว แต่บทเรียนจาก MHCflurry คือ agent คนละตระกูลจับ error คนละแบบ ถ้าติดจุดตันที่แก้เท่าไรก็ไม่ผ่าน ลองสลับให้อีกตัวมารีวิว โดยเฉพาะกับบั๊กเชิงตัวเลขที่ “ดูเหมือนถูก” — แต่ก็อย่าหลงเชื่อว่ารีวิวด้วย agent แทนมนุษย์ได้ รายงานเตือนไว้ชัดว่ามันดัน agent ไปขยายโค้ดโดยไม่จำเป็นได้เหมือนกัน

ประเด็นสุดท้ายที่ไม่ค่อยมีใครพูด: รายงานนี้ทำโดย OpenAI แต่เคสที่สำเร็จที่สุดหลายเคสใช้ Codex ร่วมกับ Claude Code และบทเรียนเด่นคือ “ใช้สองตระกูลดีกว่าตระกูลเดียว” การที่แล็บหนึ่งเผยแพร่ข้อค้นพบที่บอกให้คนใช้ของคู่แข่งด้วย เป็นสัญญาณที่ดีต่อคุณภาพของรายงาน — และเป็นสิ่งที่หายากพอจะควรบันทึกไว้

แหล่งข่าว

• Scientific computing in the age of agentic AI: an exploratory field report — เอกสารฉบับเต็ม PDF (28 ก.ค. 2026)
• Scientific computing in the age of agentic AI — หน้าประกาศของ OpenAI
• AI coding agents can modernize research software, but can’t judge if the science is right — The Decoder
• OpenAI report links coding agents to faster science software builds — AI News