Codex กับ Claude Code ตัวไหนเขียนโค้ดได้ดีกว่ากัน คนที่ใช้จริงมาทั้งคู่ยังตอบสวนกันเอง

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

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

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

เรื่องแรกที่เสียงตรงกัน คอมเมนต์ของ Claude ที่เล่ายาวเกินจำเป็น

รายงานที่ตรงกันจากคนที่ไม่ได้ทำงานร่วมกันเลยคือ โมเดลฝั่ง Claude ชอบใส่คอมเมนต์ในโค้ดยาวเกินความจำเป็น

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

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

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

อีกฝั่งก็มีนิสัยของตัวเอง Codex ชอบสร้างระบบเกินกว่าที่โจทย์ขอ

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

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

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

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

ตรงที่รายงานสวนกันเอง ตั้งแต่จังหวะหยุดจนถึงบุคลิก

เสียงหนึ่งบอกว่า Claude ชอบทำเกินที่สั่ง เดาเจตนาของเราแล้วลงมือกับสิ่งที่ยังไม่ได้ขอ ส่วน Codex ทำเท่าที่บอก แล้วหยุดทันทีที่เห็นว่าน่าจะเสร็จ

อีกเสียงกลับรายงานตรงกันข้ามทั้งคู่ บอกว่าโมเดลหลักที่ Codex เรียกใช้อย่าง GPT-5.6 ไล่ทำไม่หยุดจนไม่รู้ว่าควรพอตรงไหน ขณะที่ Claude Opus 5 โมเดลรุ่นท็อปของอีกฝั่ง ถอดใจเร็วเกินไป และบางครั้งบอกว่าเสร็จแล้วทั้งที่ข้ามขั้นตอนตรวจที่รันไม่ผ่านไปเฉยๆ

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

อีกเรื่องที่รายงานสวนกันคือบุคลิก บางคนสรุปความรู้สึกจากการใช้มาทั้งคู่ไว้สั้นๆ

Claude เหมือนคนพูดมากและชอบตอกกลับ ส่วน Codex เหมือนช่างที่ทำงานเงียบๆ จนเสร็จ

แต่คนอีกกลุ่มรายงานตรงกันข้ามอย่างชัดเจนว่า Claude เดาสิ่งที่คิดไว้ในหัวได้แม่นยำกว่า ส่วน GPT-5.6 ทำตามคำสั่งตรงเกินไปจนได้ของที่ไม่ตรงใจ ทั้งที่ไม่ได้ทำอะไรผิดจากที่พิมพ์สั่งไปเลยสักคำ

ชื่อเดียวกัน แต่คนละรุ่นคนละโปรแกรม

คำว่า Claude ในบทสนทนาพวกนี้เป็นชื่อตระกูล ไม่ได้หมายถึงเครื่องมือเพียงตัวเดียว ในตระกูลนั้นมีตัวโมเดลอย่าง Claude Opus 5 และ Fable โมเดลตัวท็อปจาก Anthropic แล้วยังมีโปรแกรมที่เรียกใช้โมเดลลงไปแก้ไฟล์จริงอย่าง Claude Code อีกชั้นหนึ่ง ฝั่ง Codex ก็ประกอบขึ้นแบบเดียวกัน มีทั้งแบบพิมพ์คำสั่งในเทอร์มินัลและแบบหน้าต่างโปรแกรม โดยข้างในเรียกโมเดลอย่าง GPT-5.6 อีกที

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

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

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

รีวิวที่ตอบสามข้อนี้ไม่ได้ บอกเราได้แค่ว่าคนเขียนถูกใจอะไร แต่ยังไม่ได้บอกว่าอะไรเหมาะกับงานตรงหน้าของเรา

บิลกับโควตาขยับเร็วกว่าที่คิด

ตัวเลขอีกชุดที่คนพูดถึงกันไม่ได้เกี่ยวกับคุณภาพโค้ด แต่อยู่ที่ค่าใช้จ่ายรายเดือน

ค่าบริการของเครื่องมือกลุ่มนี้คิดจากหน่วยนับปริมาณข้อความอย่างโทเคน ที่นับทั้งคำสั่งที่ส่งเข้าไปและคำตอบที่ได้จากโมเดล ยิ่งงานยาว โทเคนก็ยิ่งหมดเร็ว คนหนึ่งบอกว่าโทเคนที่ตัวเองใช้กับโมเดล Claude ลดลง 83% ภายในเดือนเดียว ตอนนี้เหลือใช้แค่ถามสั้นๆ กับอ่านเอกสารวิจัย อีกคนใช้โควตาของแพ็กเกจ Claude Max หมดภายในราวสิบนาทีในงานหนักชิ้นเดียว แล้วตัดสินใจลดแพ็กเกจลงมาเป็น Pro พร้อมสมัครแพ็กเกจ Codex เดือนละ 200 ดอลลาร์แทน ส่วนคนที่ใช้แพ็กเกจ 20 ดอลลาร์ก็เจอโควตาหมดไปสองรอบในงานเดียว แล้วไปจบงานที่เหลือด้วยการจ่ายค่าโทเคนของโมเดลฝั่ง OpenAI ตรงๆ ราว 0.40 ดอลลาร์

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

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

งานที่ประเมินไว้ไม่กี่ร้อยบรรทัด แต่ได้ diff กลับมา 25,000 บรรทัด

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

คนหนึ่งส่งงานที่ประเมินไว้ว่าน่าจะแก้ไม่กี่ร้อยบรรทัดพร้อมเทสต์ให้ GPT-5.6 ทำ สิ่งที่ได้กลับมาคือ diff หรือรายการโค้ดที่มีการแก้ไข ยาวกว่า 25,000 บรรทัด ทั้งบรรทัดที่เพิ่มเข้ามาและที่ตัดออก จากนั้นเขาเปิดโมเดลตัวเดิมขึ้นมาใหม่อีกหน้าต่างให้ช่วยประเมิน แล้วให้ Claude ประเมินแยกอีกทาง ทั้งสองตัวตอบตรงกันว่าราว 98% ของ diff ก้อนนั้นควรตัดทิ้ง

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

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

งานหน้าตาแบบไหน เหมาะกับตัวไหน

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

• งานขอบเขตแคบ รู้ปลายทางชัด อย่างแก้จุดเดียว จูนความเร็ว หรือไล่พิสูจน์เชิงตรรกะแบบลุยยาว เข้าทาง Codex และ GPT-5.6 ที่ทำตามคำสั่งตรงและไม่วอกแวก
• งานหน้าเว็บและงานดีไซน์ ที่ต้องเดาว่าเราอยากได้หน้าตาประมาณไหน เข้าทาง Claude Opus 5 ซึ่งมีคนรายงานว่าเดาได้ใกล้เคียงกับสิ่งที่ต้องการมากกว่า
• งานกำกวมและงานวางโครงสร้าง ที่ยังไม่รู้ว่าคำตอบควรหน้าตายังไง เข้าทาง Fable โดยมีคนใช้วิธีให้ Fable เป็นตัวคุมงาน แล้วส่ง GPT-5.6 ไปทำงานย่อยเป็นลูกทีมอีกที

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

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

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