ถ้าเคยสงสัยว่า Claude Code กับ Codex จาก OpenAI ต่างกันอย่างไรในการใช้งานจริง การทดลองของ Nate Herk ผู้เชี่ยวชาญ AI Automation บน YouTube ให้คำตอบที่ชัดเจนมาก เขาส่ง prompt เดียวกันให้ทั้งสอง agent แล้วปล่อยให้ทำงานเองแบบอิสระโดยไม่ยุ่งเลยระหว่างทาง ผลที่ได้ไม่ใช่แค่แอปที่ต่างกัน แต่ต่างกันในทุกมิติ ตั้งแต่คุณภาพงาน เวลา ไปจนถึงค่าใช้จ่ายที่ห่างกันหลายเท่า
โจทย์ที่ใช้คือสร้าง Typeform alternative ที่พร้อม go-to-market ได้จริง ไม่ใช่แค่ prototype prompt กำหนดให้ agent ทำงาน 3 เฟส ได้แก่ research, build, และ verify พร้อมย้ำชัดว่าต้องไม่หยุดที่ build แรก ต้องทดสอบ แก้ไข ทดสอบซ้ำ จนแน่ใจว่าแอปสมบูรณ์จริงๆ
- Codex สร้าง "Realform" ใช้เวลาเกือบ 62 ชั่วโมง ค่าใช้จ่ายเกือบ $3,000 ดีไซน์ภาพสวยกว่าแต่ใช้งานท่วมท้น
- Claude Code เร็วกว่าประมาณ 11 เท่า และถูกกว่าประมาณ 6.6 เท่า
- Claude Code เหมาะกับ prompt เป้าหมายกว้างๆ ส่วน Codex ต้องการขั้นตอนละเอียดกว่าจึงทำงานได้ดีที่สุด
- ทั้งสองมีจุดแข็งต่างกัน ไม่มีตัวไหน "ชนะ" ในทุกมิติ
Prompt เดียวกัน ผลที่ต่างกันสุด
Prompt ที่ใช้กำหนดให้ agent ทำงาน 3 เฟส research, build, verify โดยไม่ได้ระบุขั้นตอนละเอียดว่าต้องทำอะไรในแต่ละเฟส แค่บอกว่า "สร้าง Typeform alternative ที่ production-ready" และให้ agent ตัดสินใจเองว่าจะไปถึงเป้าหมายอย่างไร สิ่งที่ขาดไปตามที่ผู้ทดสอบสังเกตเองภายหลังคือเฟส planning ที่ควรแทรกระหว่าง research กับ build เพื่อให้ agent วางแผนรายละเอียดและ map flow ทั้งหมดก่อนลงมือจริง
สิ่งที่น่าสนใจคือ agent ทั้งสองตีความ prompt นี้ต่างกันโดยสิ้นเชิง Claude Code มอง prompt เป็น "เป้าหมาย" แล้วหา path ที่เหมาะสมเอง ตัดสินใจว่าฟีเจอร์อะไรสำคัญ อะไรไม่จำเป็น และทำเท่าที่ต้องทำจริงๆ ส่วน Codex แปล prompt เป็นรายการสิ่งที่ต้องทำแล้ว implement ออกมาอย่างครบถ้วนและซื่อสัตย์ต่อทุก capability ที่นึกออก เมื่อ scope กว้างและ outcome ไม่ได้กำหนดชัด วิธีคิดสองแบบนี้ให้ผลต่างกันมาก
ดูผลงาน: ดีไซน์ที่สวยงาม vs ฟังก์ชันที่ใช้ได้จริง
Codex สร้าง "Realform" ที่ landing page ดูดี มี hero image น่าสนใจ และดูมีชั้นมีระดับ แต่พอเข้าไปถึงส่วน form editor ประสบการณ์ใช้งานกลับท่วมท้น มีตัวเลือกมากเกินไป navigation ไม่ชัดเจน และหลายฟีเจอร์ที่ดูเหมือนทำได้กลับทำได้แค่ครึ่งเดียว เช่น ปุ่มเปลี่ยน theme ที่กดแล้วไม่มีอะไรเกิดขึ้น หรือ workflow logic ที่ถูกสร้างมาแบบ demo ไม่ใช่ production จริง แม้จะมีจำนวน test สูงมากก็ตาม
Claude Code สร้าง "Formora" ที่หน้าตาเรียบกว่า ไม่หรูหราเท่า แต่เปิดมาแล้วรู้เลยว่าต้องทำอะไร form editor ใช้งานง่าย รองรับหลาย field type ตั้งแต่ short text, opinion scale ไปจนถึง ranking มี logic-based branching ที่ใช้งานได้จริง และที่สำคัญที่สุด — publish แล้วโฟร์มทำงานจริง รับ response จริง แสดงผลใน dashboard จริง สิ่งที่พิสูจน์ได้ชัดจากตรงนี้คือ จำนวน feature ที่ implement ไม่ได้สัมพันธ์กับคุณภาพของประสบการณ์ผู้ใช้ agent ที่ทำงานหนักกว่ามากอาจให้ผลที่ใช้งานยากกว่า
ประสบการณ์ที่ดีไม่ได้วัดจากว่า agent ทำงานหนักแค่ไหน แต่วัดจากว่าผู้ใช้รู้สึกสับสนไหมเมื่อเปิดแอปขึ้นมาเป็นครั้งแรก
ตัวเลขที่บอกทุกอย่าง: เวลา ค่าใช้จ่าย และขนาดของ agent
| มิติ | Claude Code | Codex |
|---|---|---|
| เวลา | 5.5 ชั่วโมง | ~62 ชั่วโมง |
| ค่าใช้จ่าย | ~$832 | ~$3,000 |
| Sub-agents | 35 ตัว | 126 ตัว |
| Tool calls | ~2,800 ครั้ง | ~32,500 ครั้ง |
| Output tokens | ~2 ล้าน | ~11 ล้าน |
| Unit tests | 296 | 2,300 |
| Browser tests | 102 | 391 |
Claude Code ใช้ agent น้อยกว่า tool น้อยกว่า แต่ได้งานที่ฟังก์ชันดีกว่า ภายในเวลาที่สั้นกว่า 11 เท่า สิ่งที่น่าสนใจเพิ่มเติมคือ Claude Code มีพฤติกรรม self-organizing ระหว่างทาง — เริ่มต้นด้วย model ที่เบากว่าแล้ว orchestrator สลับตัวเองเป็น Opus 4.8 ซึ่งมี judgment ดีกว่า แล้วค่อยสั่งให้ sub-agents ทำงานด้วย model ที่เหมาะกับงานแต่ละส่วน พฤติกรรมแบบนี้ทำให้ประสิทธิภาพดีขึ้นโดยไม่เพิ่มต้นทุนมากนัก
ประเมินแบบแบ่งหมวด: ใครชนะในแต่ละด้าน
เมื่อประเมินผลแบบแยก 4 หมวด มีทั้งด้านที่ Claude Code ชนะและด้านที่ Codex ชนะชัดเจน
Product Judgment ไปของ Claude Code เพราะโฟกัสสิ่งที่สำคัญจริงๆ และตัดสิ่งที่ไม่จำเป็นออก ส่วน Codex เลือก implement ถึง 135 capability รวมถึงฟีเจอร์ซับซ้อนที่สุดท้ายกลายเป็นภาระ ไม่ใช่คุณค่า ผลคือ UI ที่ท่วมท้นและ feature ที่ยังไม่สมบูรณ์
Architecture ไปของ Codex ระบบ backend ที่ Codex สร้างมี immutable revision, offline recovery, migration safety และ concurrency handling ซึ่งเป็นโครงสร้างที่ engineering team ต้องการในระบบ production จริง แม้ผู้ใช้ทั่วไปจะมองไม่เห็น แต่ฐานรากที่ Codex วางไว้มีความสมบูรณ์กว่า
Testing ไปของ Codex อย่างชัดเจน จำนวน test มากกว่าหลายเท่า ครอบคลุม cross-browser testing, property tests, fault injection และ mobile testing ในขณะที่ Claude Code เน้น security testing และ data correctness แต่ไม่ได้ครอบคลุมกว้างเท่า
Efficiency ไปของ Claude Code ด้วยคะแนน 9.0 จาก 10 เทียบกับ 5.5 ของ Codex — ผลลัพธ์ดีกว่า เวลาน้อยกว่า และงบประมาณต่ำกว่าอย่างเห็นได้ชัด
วิธีพรอมต์ที่เหมาะกับแต่ละ Tool
บทเรียนที่สำคัญกว่าการนับคะแนนชนะแพ้คือการเข้าใจว่าแต่ละ tool ตอบสนองต่อ prompt แบบไหน และควรใช้ในสถานการณ์ไหน
Claude Code ทำงานได้ดีกับ prompt ที่บอก "เป้าหมาย" และให้ agent ตัดสินใจเองว่าจะไปถึงเป้าหมายอย่างไร เหมาะกับงานที่ต้องการ judgment ความคิดสร้างสรรค์ และการตัดสินใจว่าอะไรควรทำอะไรไม่ควรทำ นึกถึงนักออกแบบที่มีประสบการณ์ที่บอกได้เองว่าอะไรคือ "ดี" โดยไม่ต้องอธิบายทุกขั้นตอน
Codex ตอบสนองได้ดีกว่าเมื่อได้รับ prompt ที่ละเอียดและมีขั้นตอนชัดเจน บอกว่าต้องทำอะไรใน step ที่ 1, 2, 3 Codex จะ implement ตามนั้นอย่างครบถ้วนและทดสอบอย่างละเอียด แต่ถ้า scope กว้างเกินไปโดยไม่มีแนวทาง Codex อาจทำงานหนักมากแต่ได้ผลที่ไม่ตรงเป้า การนำ Codex มาทำ security review, bug finding และ adversarial testing บน codebase ที่ Claude Code สร้างแล้วเป็นการผสมที่ได้ผลมากในทางปฏิบัติ
บทสรุป
การทดลองนี้ไม่ได้ตอบว่า Claude Code ดีกว่า Codex หรือในทางกลับกัน แต่แสดงให้เห็นว่าทั้งสอง tool เหมาะกับงานและ prompt style ต่างกัน ถ้าต้องการ agent ที่ตีความเป้าหมายกว้างๆ ได้ดี ทำงานเร็ว และประหยัดงบประมาณ Claude Code มีข้อได้เปรียบชัดเจน ถ้าต้องการระบบที่ทดสอบถี่ถ้วน backend แข็งแกร่ง หรืองาน security hardening Codex มีจุดแข็งที่แตกต่าง แนวทางที่คุ้มค่าที่สุดอาจเป็นการผสมทั้งสอง — ให้ Claude Code สร้าง แล้วให้ Codex ตรวจ
