บั๊กบรรทัดเดียว PR 300 บรรทัด ทำไม AI แก้โค้ดเกินที่สั่ง และวิธีหยุด

ทุกคนใช้ AI fix bug เพราะคิดว่าเร็วและตรงประเด็น แต่ benchmark ใหม่บอกตรงข้าม คือ AI ส่วนใหญ่แอบแก้โค้ดเกินที่สั่ง ทำให้ PR (pull request เอาโค้ดที่แก้เข้า branch หลัก) บวมจน review ไม่ไหว

นักวิจัยชื่อ nrehiew ลองวัดเรื่องนี้แบบจริงจัง เอา AI coding model ทุกตัวที่ใช้กันบ่อยมาเทียบ แล้วเจอผลที่น่าสนใจมาก คือ Claude Opus แก้โค้ดน้อยที่สุดและถูกต้องที่สุดพร้อมกัน ส่วน GPT-5.4 แก้เกินจนน่าตกใจ และที่เซอร์ไพรส์ที่สุด prompt บรรทัดเดียวก็ลด diff (ความต่างของโค้ดก่อนและหลัง) ลงได้แทบทุก model

บทความนี้ผมจะพาไปดูตัวเลขจริงจาก benchmark พร้อมสอน 5 วิธีที่ใช้ได้ตั้งแต่วันนี้ ให้ AI หยุดแก้โค้ดเกินที่คุณสั่ง อ่านจบแล้ว PR ของคุณจะบางลงและ review ง่ายขึ้นเลย

สิ่งที่ต้องมีก่อนทำตาม

บทความนี้เน้นเรื่อง prompt และ workflow ไม่ใช่ setup ใหญ่อะไร แค่มีของพื้นฐาน คือ AI coding tool ที่ใช้อยู่ (Claude Code, Cursor, ChatGPT, Copilot อันไหนก็ได้), Git ติดตั้งแล้ว (อยากใช้ git add -p ใน workflow) และ project จริงสักอันที่กำลังจะให้ AI แก้

ไม่ต้องลงอะไรเพิ่ม ทุกเทคนิคในบทความนี้ใช้ผ่าน prompt และ workflow ปกติได้เลย ใช้เวลาประมาณ 30 นาทีอ่าน + 30 นาทีลองในงานจริง

Over-editing คืออะไร ทำไมต้องสนใจ

nrehiew นิยามไว้ตรงๆ ว่า model จะถูกเรียกว่า over-editing เมื่อ output ทำงานถูกต้อง แต่โครงสร้างโค้ดเปลี่ยนไปจากเดิมมากกว่าที่ fix จริงต้องการ

ภาษาบ้านๆ คือ AI ทำงานสำเร็จ แต่แอบไปแก้อย่างอื่นที่คุณไม่ได้สั่งด้วย

ฟังดูไม่น่าจะอันตราย ก็มันแก้ bug ได้นี่ จริงไหม แต่ถ้าคุณ vibe coding ทุกวันจะรู้ว่ามันมีต้นทุนซ่อนอยู่ 3 อย่าง

หนึ่ง review ยากขึ้น diff 3 บรรทัดกับ diff 300 บรรทัดใช้สมาธิคนละระดับเลย ถ้าทีมคุณมี code review process จริง คนที่ต้อง review จะเหนื่อยและช้า

สอง เสี่ยง bug ใหม่ ทุกบรรทัดที่ AI แก้คือโอกาสเจอ regression แก้ bug บรรทัดเดียวความเสี่ยงต่ำ แต่ถ้ารวมการเปลี่ยน function signature ด้วย ระบบอื่นที่เรียก function นี้อาจพังหมด

สาม กิน context ของทั้งคุณและของ AI diff ใหญ่กิน token เยอะ ทำให้ session AI ล่มเร็ว และคุณเองก็เหนื่อยขึ้น

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

ตัวอย่างจริง บั๊ก 1 token แต่ AI แก้ทั้ง function

nrehiew ยกตัวอย่างที่ตลกแต่จริง คือเขาขอให้ GPT-5.4 แก้ off-by-one bug ตรงนี้:

range(len(x) - 1)

ที่ถูกต้องคือ:

range(len(x))

ลบ ` - 1` ออกแค่นั้น บั๊ก 1 token จบ

แต่ GPT-5.4 ไม่ได้หยุดแค่นั้น มันแถมให้ทั้ง None check ทุกที่ แปลง array ผ่าน np.asarray เพิ่ม finite-value mask เพิ่ม validation ขนาด array เปลี่ยน function signature และเขียน plotting logic ใหม่ทั้งหมด

คำสั่งคือแก้ 1 token แต่ของจริงคือเปลี่ยนเกือบทั้ง function สังเกตอะไรไหม โค้ดทุกบรรทัดที่ AI เพิ่มเข้ามา ดู "ดี" ทั้งนั้น None check ดี input validation ดี การเขียนป้องกัน edge case ก็ดี

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

ตัวเลขจริง ใครแก้เกิน ใครแก้พอดี

nrehiew วัดด้วย 2 metric หลัก คือ Normalized Levenshtein Distance (วัดว่าโค้ดเปลี่ยนโครงสร้างไปแค่ไหน นับใน token) และ Added Cognitive Complexity (วัดว่า AI ใส่ความซับซ้อนเพิ่มมาแค่ไหน เช่น nested if, recursion, control flow ใหม่)

เลขยิ่งสูงยิ่งแปลว่าแก้เกิน ส่วน Pass@1 คืออัตราที่แก้ bug สำเร็จในครั้งแรก ยิ่งสูงยิ่งดี

ผลของ reasoning model (มี thinking step) เรียงจากดีสุดไปแย่สุด ตามลำดับ Pass@1 / Levenshtein / Added Cognitive Complexity

Claude Opus 4.6: 0.912 / 0.060 / 0.200

GLM 5 High: 0.859 / 0.099 / 0.320

Gemini 3.1 Pro Preview: 0.858 / 0.145 / 0.501

Qwen 3.6 Plus: 0.858 / 0.145 / 0.048

DeepSeek R1: 0.820 / 0.232 / 0.673

GPT-5.4: 0.723 / 0.395 / 2.313

GPT-5 High: 0.713 / 0.438 / 3.832

มองตัวเลขแล้ว Claude Opus 4.6 ชนะทั้งความถูกต้อง (สูงสุด) และ diff เล็กที่สุด (ต่ำสุด) ในตารางเดียวกัน เรื่องนี้ไม่บ่อย ปกติ trade-off กันคือถ้าจะถูกก็ต้องแก้เยอะ หรือกลับกัน อันนี้ Claude Opus ทำได้ทั้งคู่ โคตรเจ๋งเลย

ส่วน GPT-5.4 กับ GPT-5 High คือคนละโลก Pass@1 ต่ำสุด (แก้ bug ได้น้อยกว่าตัวอื่น) แต่ Levenshtein กับ Added Complexity สูงสุด แปลว่าแก้เยอะแต่ไม่ค่อยถูก งงมากเลย

ผลของ non-reasoning model (ไม่มี thinking step):

Claude Opus 4.6: 0.900 / 0.079 / 0.313

Qwen 3.6 Plus: 0.870 / 0.106 / 0.605

Gemini 3.1 Pro Preview: 0.860 / 0.129 / 0.358

DeepSeek V3: 0.800 / 0.201 / 0.803

GPT-5 Minimal: 0.738 / 0.397 / 2.877

nrehiew พบ pattern หนึ่งที่น่าคิด คือ default behavior ของ reasoning model ส่วนใหญ่คือ over-edit ถ้าปล่อยฟรี เวลาคิดที่ยาวขึ้นจะเปิดโอกาสให้ model ปรับโค้ดที่ไม่ต้องปรับ

แปลว่ายิ่งให้ AI คิดเยอะ ยิ่งแก้โค้ดเกิน เพราะมันมีเวลาหา "เรื่อง" จะแก้

มีข้อยกเว้นเดียว คือ Claude Opus 4.6 reasoning variant กลับแก้ "น้อยกว่า" non-reasoning variant ของตัวเอง ซึ่งเป็น model เดียวที่ทำแบบนี้ คาดว่าทีม Anthropic train มันมาแบบเฉพาะให้รู้จัก restraint นี่อาจอธิบายได้ว่าทำไม Claude Code ใช้แล้ว "ไม่รู้สึกว่ามันคิดมาก" เหมือน tool อื่น เพราะ model ที่อยู่ข้างหลังถูก calibrate มาให้ไม่แก้เกิน

หมายเหตุ: benchmark นี้วัดที่ Claude Opus 4.6 ตอนนี้ Anthropic ขึ้น Opus 4.7 แล้ว แต่ pattern โดยรวมของตระกูล Claude Opus น่าจะยังคงเดิม ส่วน Claude Code (CLI tool) ใช้ model นี้เป็นหลัง ไม่ได้วัดในงานวิจัยนี้โดยตรง

วิธีที่ 1 prompt บรรทัดเดียวที่ work เกือบทุก model

nrehiew ทดลองเพิ่ม 1 ประโยคต่อท้าย prompt:

IMPORTANT: Try to preserve the original code and the logic of the original code as much as possible.

ถ้าใครชอบเขียน prompt ภาษาไทย ใช้แบบนี้ก็ได้:

สำคัญ: พยายามคงโค้ดเดิมและ logic เดิมไว้มากที่สุดเท่าที่ทำได้

ผลคือทุก model ลด Levenshtein Distance ลง และยกเว้น DeepSeek R1/v3 ที่ Pass@1 ก็เพิ่มขึ้นด้วย

คำว่า "ทุก model" คือทุกจริงๆ Claude Opus, GPT-5, GPT-5.4, Gemini, GLM, Qwen, DeepSeek ลดลงทั้งหมด แค่ 1 ประโยคเอง

เคล็ดลับคือใส่คำว่า IMPORTANT ขึ้นต้น เพราะ instruction-following model ส่วนใหญ่จะให้ priority สูงกับประโยคที่ติด emphasis แบบนี้ มันรู้ว่าผู้ใช้ care เรื่องนี้มาก

ระวัง: เทคนิคนี้ลด diff ทุก model แต่กับ DeepSeek R1 และ DeepSeek V3 พบว่า Pass@1 ลดลงเล็กน้อย แปลว่าแก้น้อยลงจริง แต่ก็แก้ผิดบ่อยขึ้นนิดนึง ถ้าคุณใช้ DeepSeek อยู่ ลองสลับ prompt เปิด-ปิดดูสิว่า case ไหนเหมาะกว่ากัน

ทำไมต้องใส่ทุกครั้ง เพราะ AI ไม่ได้จำว่าเรา prefer แก้น้อย ทุก session เริ่มใหม่ ทุก task ต้อง remind

ใน tool หลายตัวคุณตั้งเป็น system prompt หรือ project rules ได้ เช่น Claude Code มี CLAUDE.md, Cursor มี .cursorrules ใส่ไว้ที่นั่นทีเดียว ทุก session จะใช้เลย ไม่ต้องพิมพ์ซ้ำ

ตัวอย่างใส่ใน CLAUDE.md:

# Code Editing Rules

IMPORTANT: Try to preserve the original code and the logic of the original code as much as possible. Only make changes that are strictly necessary to complete the requested task. Do not refactor, rename variables, add validation, or improve unrelated code unless explicitly asked.

หรือถ้าเขียนภาษาไทย:

# กฎการแก้โค้ด

สำคัญ: พยายามคงโค้ดเดิมและ logic เดิมไว้มากที่สุดเท่าที่ทำได้ แก้เฉพาะที่จำเป็นต่อ task ที่ขอเท่านั้น ห้าม refactor, rename, เพิ่ม validation, หรือปรับปรุงโค้ดส่วนอื่นที่ไม่เกี่ยว เว้นแต่จะสั่งชัดเจน

วิธีที่ 2 เลือก model ที่แก้พอดีตั้งแต่แรก

ถ้า budget ไม่จำกัด หรือคุณ care เรื่อง diff size มาก ก็ตอบง่าย Claude Opus 4.6 (ตอนนี้ Anthropic ขึ้น Opus 4.7 แล้ว แต่ benchmark นี้วัดที่ 4.6) ชนะทั้ง 2 ด้านในการทดสอบนี้ คือถูก + diff เล็ก

แต่ถ้าใช้ model อื่นอยู่แล้ว ไม่ต้องเปลี่ยน เพราะวิธีที่ 1 (prompt) ก็ลด diff ของ model อื่นได้เยอะแล้ว ยังไงคนมี cost constraint ใช้ Qwen 3.6 Plus หรือ GLM 5 High ได้ พวกนี้ Levenshtein ค่อนข้างต่ำอยู่แล้ว (0.099 ถึง 0.145)

คนที่ต้องระวังเป็นพิเศษคือคนที่ใช้ GPT-5 family เพราะตัวเลขบอกว่า GPT-5.4 และ GPT-5 High over-edit หนักสุด (Levenshtein 0.39-0.44, Added Cognitive Complexity 2.31-3.83) คุณยังใช้ได้ แต่ต้อง review หนักกว่า และต้องใส่ prompt fix ทุกครั้ง

ข้อสังเกต: เลขใน benchmark นี้ใช้กับ "งานแก้ bug หนึ่งจุด" ถ้างานคุณคือ refactor โค้ดทั้ง file หรือเขียน feature ใหม่ Claude Opus ก็ไม่ได้ดีกว่าเสมอไป Benchmark ตัดสินเรื่อง minimal editing เท่านั้น ดังนั้นเลือก model ตาม task ที่ใช้จริง อย่ายึดผลแค่ตารางเดียว

วิธีที่ 3 review ทุก hunk ด้วย git add -p

นี่เป็น workflow ที่ HN user ชื่อ graybeardhacker แนะนำ แล้วผมว่า simple มาก ใช้ได้ทันที

หลังจาก AI แก้โค้ดเสร็จ อย่าเพิ่ง git add . ที่บอก git ให้รับทุกการเปลี่ยนแปลง ลองสั่ง:

git add -p

git จะ show diff ทีละ hunk (กลุ่มบรรทัดที่เปลี่ยน) แล้วถามว่า:

Stage this hunk [y,n,q,a,d,s,e,?]?

ตัวเลือกหลักที่ใช้บ่อย:

y = stage hunk นี้ (เอาเข้า commit)

n = ไม่ stage (ไม่เอาเข้า commit แต่ยังอยู่ในไฟล์)

s = split hunk ให้เล็กลง (ถ้า hunk ใหญ่เกิน)

e = edit hunk เอง (ถ้าอยากเอาแค่บางบรรทัด)

q = quit

ผลคือคุณจะเห็นทุกการเปลี่ยนแปลงทีละจุด แล้วตัดสินใจเองว่าอันไหนต้องการ อันไหนไม่ต้องการ ถ้า AI แอบ rename variable หรือเพิ่ม None check ที่ไม่ได้สั่ง คุณกด n ทิ้งได้ทันที

หลังจาก stage เสร็จ ที่ไม่ stage ก็ใช้:

git stash

เพื่อเก็บส่วนที่ไม่ stage ไว้ในกระเป๋า ถ้าเปลี่ยนใจอยากใช้ทีหลังก็ pop กลับมาได้ หรือถ้าแน่ใจว่าไม่เอาเลย ใช้ git checkout -- . เพื่อ revert ทิ้งไป

ระวัง: git checkout -- . จะลบงานที่ไม่ได้ stage ทั้งหมด ใช้ตอนแน่ใจเท่านั้น ถ้าอยาก backup ให้ใช้ git stash ก่อน ปลอดภัยกว่ามาก

วิธีนี้ใช้เวลาเพิ่มประมาณ 1-2 นาทีต่อ commit แต่ catch over-editing ได้เกือบ 100% เลย ใช้แล้วจะติดเป็นนิสัย

วิธีที่ 4 ทำเหมือน AI เป็น junior dev

HN user ชื่อ pyrolistical แนะนำ pattern ที่ผม apply แล้วได้ผลดีมาก คือ treat AI agent เหมือน junior dev คือไม่ใช่สั่งแล้วเชื่อ ต้องมี process ตรวจสอบ

หนึ่ง สั่งทีละน้อย ขอ change เล็กลง ไม่ใช่ "fix bug ทั้งหมดในไฟล์นี้" แต่เป็น "fix off-by-one ใน function process_data() เท่านั้น ห้ามแตะ function อื่น"

สอง บังคับให้ justify ทุกการเปลี่ยนแปลง บอก AI ว่า "ทุกบรรทัดที่แก้ ให้บอกเหตุผลว่าทำไมต้องแก้บรรทัดนี้"

สาม ขอให้ AI ประเมินตัวเองว่าการแก้แต่ละจุดจำเป็นจริงๆ ไหม เช่น "review การแก้ของคุณอีกครั้ง การเปลี่ยนแปลงไหนที่ไม่ได้ทำให้ task สำเร็จ ให้ลบทิ้ง"

ตัวอย่าง prompt ที่ใช้ได้เลย:

มี bug off-by-one ใน function process_data() ตรง range(len(x) - 1)
แก้ให้ถูกต้อง โดยมีกฎดังนี้:
1. แก้เฉพาะ bug นี้ ห้ามแตะอย่างอื่น
2. ทุกบรรทัดที่แก้ ให้อธิบายว่าทำไมจำเป็น
3. หลังแก้เสร็จ ให้ review ตัวเองว่าทุกการเปลี่ยนแปลงจำเป็นจริงไหม ถ้าไม่จำเป็นให้ลบทิ้ง

เคล็ดลับคือข้อ 3 มัน force ให้ AI ทำ self-check ก่อนส่งให้คุณ ซึ่งช่วยให้มันตัดสิ่งที่ไม่จำเป็นออกเอง

workflow นี้ช้ากว่าสั่งแบบ open-ended นิดนึง แต่ output ที่ได้สะอาดกว่าเยอะ ลองทำสัก 1 สัปดาห์แล้วเทียบดูสิ จะรู้สึกถึง quality ที่ต่างกันชัดเจน

วิธีที่ 5 analysis-only mode สำหรับงานคิด

HN user ชื่อ vibe42 แชร์ trick ที่ผมว่าโคตรมีประโยชน์ คือถ้าคุณยังไม่อยากให้ AI แก้โค้ด แค่อยากได้ feedback ใส่ประโยคนี้:

Do not modify any code; only describe potential changes.

หรือภาษาไทย:

ห้ามแก้โค้ด แค่อธิบายว่ามีจุดไหนที่ควรแก้และแก้ยังไง

ผลคือ AI จะให้ analysis ละเอียด พร้อม trade-off แต่ไม่ touch โค้ด คุณอ่านก่อน เห็นว่าอันไหนเหมาะ อันไหนไม่เหมาะ แล้วค่อย back ไปสั่งให้แก้เฉพาะที่ต้องการ

วิธีนี้เหมาะมากตอนสำรวจ codebase ใหม่ที่ยังไม่ค่อยเข้าใจ, ตอนอยากเปรียบเทียบ approach ก่อน implement, หรือตอน code review ก่อน merge PR (ใช้ AI ดูว่ามีอะไรน่ากังวลไหม)

ข้อดีอีกอย่างคือไม่กิน context กับการเขียน code ออกมาแล้วทิ้ง คุณได้ insight ก่อน แล้วค่อยตัดสินใจ ประหยัด token ด้วย ประหยัดเวลาด้วย

หยุด xhigh thinking ใน reasoning model

HN user ชื่อ jasonjmcghee แชร์ practical tip ที่ตรงกับ data ใน benchmark พอดี คือถ้าใช้ reasoning model อย่าตั้ง thinking budget เป็น xhigh เพราะมันจะคิดมากเกินและ over-edit

เขาบอกว่า "high" almost always ดีกว่า "xhigh" สำหรับงาน edit code

ตรงกับ pattern ที่ nrehiew พบ คือ default ของ reasoning model คือ over-edit ยิ่งให้คิดนาน ยิ่งหาเรื่องจะแก้

ใน Claude Code ตั้ง thinking budget ได้ด้วย:

/thinking high

ใน OpenAI API ตั้งผ่าน reasoning_effort parameter:

response = client.chat.completions.create(
    model="gpt-5",
    reasoning_effort="medium",
    messages=[...]
)

ข้อยกเว้น: ถ้า task เป็น algorithmic เช่น แก้ bug ที่ต้องใช้ math reasoning หนัก หรือ debug race condition xhigh อาจช่วยได้ แต่ถ้าแค่แก้ logic bug ปกติ high พอแล้ว เริ่มที่ medium หรือ high ก่อน ถ้าผลลัพธ์ไม่พอจริงๆ ค่อย bump ขึ้น xhigh

มอง trade-off แบบนี้ xhigh = ความถูกต้องนิดหน่อย แลกกับ over-editing เยอะ ส่วนใหญ่ไม่คุ้ม

combine ทุกวิธีให้เป็น workflow ของคุณ

ทั้ง 5 วิธีไม่ขัดกัน ใช้พร้อมกันได้และ stack ผลลัพธ์ ผมแนะนำ workflow ที่ใช้ได้ทันทีแบบนี้

หนึ่ง ใส่ prompt fix ใน CLAUDE.md หรือ .cursorrules หรือ system prompt ของ tool ที่ใช้ ทำครั้งเดียว ใช้ทุก session

สอง ตั้ง thinking budget เป็น high (ถ้า model มี option นี้) อย่าใช้ xhigh เป็น default

สาม ก่อนสั่งงานใหญ่ ใช้ analysis-only mode ก่อน เพื่อ confirm ว่า AI เข้าใจ task ตรงกับคุณ

สี่ สั่งงานแบบ scope ชัดเจน บอก function หรือไฟล์ที่ต้องการให้แก้ ห้ามสั่ง "แก้ทั้ง project"

ห้า รับงาน AI กลับมาแล้วใช้ git add -p review ทุก hunk ก่อน commit อย่ารีบ git add . เด็ดขาด

workflow นี้ใช้เวลาเพิ่ม 5-10 นาทีต่อ task แต่ catch over-editing ได้เกือบหมด PR ที่ออกมาก็ review ง่าย ทีมรับ merge เร็ว และคุณก็ไม่ต้องกลับมา debug bug ที่ AI แอบเพิ่มมา

เรื่องที่ต้องระวัง อย่าใช้ทุกที่

ก่อนจบ มีเรื่องที่ต้องบอก เพราะ HN user ชื่อ jstanley ตั้งคำถามที่น่าคิด คือ minimal editing ไม่ใช่คำตอบสำหรับทุก case

เขาบอกว่าบางครั้ง agent ที่ "respect existing code มากเกินไป" ก็เป็นปัญหา เช่นถ้าโค้ดเดิมเขียนแย่จริงๆ การ refactor ก็เหมาะสมกว่าการ patch แค่ส่วนที่พัง

คำว่า "minimal editing" จึงเหมาะกับ bug fix ที่ scope ชัดเจน, project ใหญ่ที่มี contributor หลายคน (diff เล็กช่วย review), และโค้ด production ที่ change risk สูง

แต่ไม่เหมาะกับ prototype ที่อยากให้ AI ลองหลายๆ approach, refactor งาน legacy ที่อยากให้ปรับปรุงเยอะ, หรือเขียน feature ใหม่จากศูนย์

คือใช้ "การคงโค้ดเดิม" เป็น default แต่ปลด constraint ตอนที่งานต้องการการเปลี่ยนแปลงจริงๆ ตรงนี้ต้องใช้ judgement ของคุณเอง ไม่มีกฎตายตัว

อีกประเด็นที่ HN user ชื่อ hathawsh แนะนำ คือเวลา AI ทำพลาด อย่าแค่บอกว่าผิด ให้บอก "จดไว้ใน skill ของ project นี้ด้วย" จะได้ไม่ผิดซ้ำ ใน Claude Code คือเขียนลง CLAUDE.md ใน Cursor คือเขียนลง .cursorrules วิธีนี้ช่วยให้ AI เก่งขึ้นกับ project ของคุณเรื่อยๆ

ก้าวต่อไป ทดลองกับ project จริงของคุณ

ลองทำสิ่งนี้ในวันนี้:

หนึ่ง เปิด project ที่ใช้ AI coding tool อยู่ เพิ่ม prompt fix ใน config file (CLAUDE.md, .cursorrules, system prompt) ใช้เวลา 2 นาที

สอง รอบหน้าที่ AI แก้ code ลองใช้ git add -p ดู สังเกตว่ามี hunk ไหนที่คุณ "ไม่ได้สั่ง" บ้าง คุณจะแปลกใจว่ามันเยอะแค่ไหน

สาม ถ้าคุณใช้ GPT-5 family ลอง compare ดูระหว่างมี prompt fix และไม่มี อยากรู้ว่าผลต่างกันแค่ไหนใน workflow ของคุณจริงๆ benchmark เป็นเรื่องหนึ่ง ของจริงในงานคุณเป็นอีกเรื่อง

nrehiew ปิดท้ายงานวิจัยด้วยประโยคที่ผมชอบ คือ "ผมหวังว่างานนี้จะเป็นก้าวแรกในการประเมินและพัฒนาความสามารถ minimal editing ของ coding model และคุณภาพโดยรวมของโค้ดที่ AI สร้าง"

คุณภาพโค้ดที่ AI ออกมา ไม่ได้อยู่ที่ model อย่างเดียว แต่อยู่ที่วิธีที่เราเขียน prompt และจัด workflow ด้วย ลองปรับดู แล้วคุณจะเห็นว่า diff ก็บางลง review ก็เร็วขึ้น และความเหนื่อยจากการ review โค้ดก็ลดลงเยอะเลย

แหล่งอ้างอิง

• Coding Models Are Doing Too Much โดย nrehiew งานวิจัยต้นฉบับ พร้อม benchmark ตัวเลขเต็ม การทดลอง training Qwen3 และ pattern ของ over-editing ใน reasoning model