กรณีศึกษาส่วนตัวว่าด้วยข้อจำกัดของการสร้างโค้ดด้วย AI และการสูญเสียสัมผัสแบบมนุษย์
(github.com/jackdoe)- เป็นไลบรารีสำหรับอิมพลีเมนต์โปรโตคอล SWD เพื่อดีบัก RP2350 RISC-V core โดยใช้ Raspberry Pi Pico2 ในโครงสร้างที่ให้ Pico อีกตัวทำหน้าที่เป็นโพรบ
- โค้ดประมาณ 80% ถูกสร้างโดย AI (Claude) โดยผู้เขียนทำต้นแบบพื้นฐานจากออสซิลโลสโคปและเอกสารก่อน แล้วให้ AI ขยายโค้ดต่อ
- ระหว่างทำโปรเจกต์ ผู้เขียนประสบกับ ความรู้สึกต่อต้านและความคลางแคลงอย่างรุนแรง จาก โครงสร้างโทเค็นที่ไร้ความหมายของโค้ด AI, การสูญเสียบริบท, และ การสูญเสียความเป็นเจ้าของโค้ด
- ในทางกลับกัน เมื่อใช้ AI เป็นเครื่องมือเสริม เช่น วิเคราะห์เอกสาร ถอดรหัสข้อมูล และสร้างสตรักต์ ผู้เขียนกลับได้ประสบการณ์เชิงบวก
- กรณีนี้เผยให้เห็นปัญหาเรื่องคุณภาพ สัมผัส และความเป็นเจ้าของของโค้ดที่ AI สร้าง พร้อมตั้งคำถามพื้นฐานต่อแก่นแท้ของการเขียนโปรแกรมและบทบาทของมนุษย์
0. VIBE CODE WARNING
- โค้ดทั้งหมดราว 80% เป็นโค้ดที่ AI สร้าง (vibe coded) และ README ส่วนใหญ่ก็ถูกสร้างอัตโนมัติเช่นกัน
- ผู้เขียนอ้างอิงออสซิลโลสโคปและเอกสารเพื่ออิมพลีเมนต์ SBA, การอ่าน/เขียนรีจิสเตอร์, abstract command, PROGBUF ด้วยตนเองก่อน แล้วค่อยให้ AI จัดทำให้เป็นไลบรารี
- เมื่อโค้ดเพิ่มจาก 1,000 บรรทัดเป็น 4,000 บรรทัด ผู้เขียนก็สูญเสียทั้งโครงสร้างและความหมายของโค้ดไปโดยสิ้นเชิง จนไม่รู้สึกว่าเป็นโค้ดที่ตัวเองเขียน
- AI ตีความ
dap_read_mem32ผิด ทำให้เกิดข้อผิดพลาดของโปรโตคอลและโค้ดที่ไร้ตรรกะจำนวนมาก - ผลลัพธ์คือทำโค้ดเกือบ 10,000 บรรทัดเสร็จใน 10 ชั่วโมง แต่ไม่มีทั้งความรู้สึกสำเร็จหรือความรู้สึกว่าตัวเองเติบโตขึ้นเลย
ความแตกต่างระหว่างโค้ดของ AI กับโค้ดของมนุษย์
- โค้ดที่มนุษย์เขียนประกอบด้วยโทเค็นที่มีเจตนาและจุดมุ่งหมาย จึงพอทำความเข้าใจได้ แต่โทเค็นในโค้ด AI กลับอ่านยากเพราะเป็นการจับคู่ที่ไร้ความหมาย
- บางส่วนของโค้ด AI มีคุณภาพดีกว่ามนุษย์ด้วยซ้ำ แต่บรรทัดถัดลงมาอาจเป็นโค้ดผิดพลาดที่ดูเหมือนถูกต้องแค่ภายนอก
- ความไม่สม่ำเสมอเช่นนี้และการสูญเสียความไว้วางใจเชิงสัญชาตญาณ ทำให้ความสามารถในการตัดสินใจของโปรแกรมเมอร์เป็นอัมพาต
- ยิ่งโค้ดมีขนาดใหญ่ขึ้น “สัมผัสในการรู้ว่าโค้ดไหนดีหรือแย่ (taste)” ก็ยิ่งหายไป และmental model กับความรู้สึกเป็นเจ้าของก็พังทลาย
อารมณ์ความรู้สึกแบบมนุษย์และความคลางแคลง
- ผู้เขียนตั้งคำถามว่า “นี่คือการเขียนโปรแกรมจริงหรือ?” พร้อมถ่ายทอดความรู้สึกต่อต้านและความละอายใจ
- ในยุคที่ AI เขียนโค้ดแทนได้ มนุษย์ควรสร้างอะไร และควรเข้าไปมีส่วนร่วมได้มากแค่ไหน ผู้เขียนบอกเล่าถึงความสับสนเชิงภววิสัย
- ผู้เขียนไม่มั่นใจด้วยซ้ำว่า การ “ไม่ต้องเขียนโค้ด” คือความก้าวหน้าหรือไม่ หรือการ “ไม่ต้องสร้างแบบจำลองของปัญหา” คือประสิทธิภาพจริงหรือเปล่า
- ผู้เขียนบอกว่าตัวเองยังคงอยากลงมือสร้างบางสิ่งด้วยตัวเองอยู่ แต่ความหมายของสิ่งนั้นกลับเลือนรางลงในสภาพแวดล้อมการพัฒนาที่มี AI เป็นศูนย์กลาง
ประสบการณ์เชิงบวกจากการใช้ AI
- เมื่อใช้ AI กับงานอย่างการวิเคราะห์เอกสาร การถอดรหัสข้อมูลจากออสซิลโลสโคป และการสร้าง C struct อัตโนมัติ ผู้เขียนประเมินว่ามีประสิทธิภาพและน่าพอใจ
- โดยเฉพาะตอนที่อ่านรีจิสเตอร์ตัวแรกและอ่านหน่วยความจำผ่าน SBA ได้สำเร็จ ผู้เขียนรู้สึกถึงความสำเร็จที่แท้จริง
- กล่าวคือ หากใช้ AI เป็นผู้ช่วย ไม่ใช่ผู้เขียนโค้ดแทน ก็ยังเป็นประสบการณ์เชิงบวกได้
ข้อคิดส่งท้าย
- การสร้างโค้ดด้วย AI นั้นรวดเร็ว แต่ก็นำมาซึ่งการสูญเสียความหมาย สัมผัส และความเป็นเจ้าของ
- เมื่อ “รสสัมผัสของโค้ดที่ดี (taste)” ที่มนุษย์รับรู้ได้หายไป แก่นแท้ของการเขียนโปรแกรมก็เริ่มสั่นคลอนตามไปด้วย
- ผู้เขียนปิดท้ายด้วยความหวังว่าปรากฏการณ์นี้จะเป็นช่วงเปลี่ยนผ่านชั่วคราว และยอมรับว่าตัวเองก็ยังไม่รู้ว่า “การเขียนโปรแกรมที่ดีกว่าเดิม” ควรเป็นอย่างไร
ส่วนเทคนิคหลังจากต้นฉบับในหัวข้อ 1~20 เป็นเอกสารอธิบายการอิมพลีเมนต์โปรโตคอลดีบัก RP2350 RISC-V อย่างละเอียด ซึ่งครอบคลุมข้อกำหนดเชิงเทคนิคทั้งหมดของสแตกดีบัก เช่น โครงสร้างชั้น SWD, รีจิสเตอร์ DAP/DAPC, การรัน PROGBUF, การเข้าถึง SBA, การควบคุม hart, การ tracing, การรีเซ็ต, และโครงสร้าง dual hart
อย่างไรก็ตาม ประเด็นหลักคือ กรณีศึกษาส่วนตัว (Vibe Code Warning) ว่าด้วย “ความขาดตอนระหว่างโค้ดที่ AI สร้างกับสัมผัสแบบมนุษย์”
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ฉันเข้าใจความรู้สึกของคนที่บอกว่า “AI ได้พรากความสนุกของการเขียนโปรแกรมไป” แต่ฉันคิดว่า ‘การลงมือทำ’ เทียบกับ ‘การทำให้เสร็จ’ นั้น อย่างหลังสำคัญกว่า
ในอดีต คนที่จุดตะเกียงแก๊สอาจตกงานเพราะหลอดไฟฟ้า แต่สุดท้ายสิ่งสำคัญคือการ มอบแสงสว่างให้เมือง
สำหรับฉัน AI คือเครื่องมือในการทำให้ไอเดียเป็นจริงและสร้างผลลัพธ์ขึ้นมา ฉันยังคงทุ่มเวลาและความพยายามไม่ต่างจาก “โปรแกรมเมอร์ตัวจริง” เพียงแต่โฟกัสอยู่ที่การนิยามปัญหา การแยกโมดูล การทดสอบ การแก้บั๊ก และการปรับปรุงแบบวนซ้ำ
สิ่งสำคัญคือการสร้างโลกที่มนุษย์ยังสามารถรู้สึกถึง ความหมาย ศักดิ์ศรี และความสุข ได้
ถ้าฉันกำลังกินอาหารอร่อย แต่คนที่ทำมันต้องทุกข์ทรมาน หรือถ้าเป็นอาหารที่ฝ่ายไม่หวังดีใช้หุ่นยนต์ผลิตขึ้นมา ฉันก็ไม่ต้องการมัน
สังคมมีไว้เพื่อมนุษย์ ไม่ใช่เช็กลิสต์ที่มีไว้เพื่อประสิทธิภาพเพียงอย่างเดียว
สำหรับโปรเจกต์ส่วนตัวอาจไม่เป็นไร แต่ในสภาพแวดล้อมที่มีลูกค้า ผู้ใช้ หรือผู้ถือหุ้น เราต้องการ ผลลัพธ์ที่พิสูจน์ได้
อุปมาเรื่องตะเกียงแก๊สไม่เหมาะสม เพราะ AI ไม่ใช่ระบบกายภาพแบบไฟฟ้า แต่เป็น ซอฟต์แวร์
ท้ายที่สุด สิ่งสำคัญคือการแก้ปัญหา ถ้าแก้ไม่ได้ มันก็เป็นแค่แรงงานเท่านั้น
หลายคนเขียนโค้ดไม่ใช่แค่เพื่อสร้างซอฟต์แวร์ที่ใช้งานได้ แต่เพราะ ความสุขจากการสร้างสรรค์
“โปรแกรมเมอร์ตัวจริง” เองก็ใช้เวลาไปกับการคิด การนิยาม การทดสอบ และการแก้ไขเช่นกัน
ไม่ว่าจะเป็น ‘เครื่องจ่ายไหมขัดฟันอัจฉริยะ’ เครื่องสั่งซื้อกระดาษชำระอัตโนมัติ หรือบอตอย่าง Clippy ล้วนเป็นการสิ้นเปลืองเวลาและพลังงาน
ไม่ใช่แค่การได้ผลลัพธ์ แต่ความพึงพอใจจากกระบวนการเรียนรู้และความเข้าใจก็มีมากเช่นกัน
ตอนอ่านหนังสือเอาชีวิตรอด Adrift, 76 Days at Sea ฉันรู้สึกว่าความรู้เชิงลึกสามารถเป็นตัวแบ่งระหว่างความเป็นกับความตายได้
มันคล้ายกับประเด็นว่าจะโฮสต์ข้อมูลเองหรือฝากไว้กับบริการแบบรวมศูนย์
เวลาเห็นข้อความบนอินเทอร์เน็ตที่ถ่ายทอดความคิดของฉันได้อย่างสมบูรณ์แบบ ฉันรู้สึกเหมือน ได้รับการปลอบโยน จริง ๆ
ขอบคุณที่เล่าถึงประสบการณ์แบบมนุษย์ แทนที่จะเพิ่มเสียงรบกวนแนว “ให้ปรับพรอมป์แบบนี้”
ถ้าจะหลุดจากสภาวะนี้ ฉันต้องได้นอนเต็มอิ่มสักคืน
มันมักให้คำตอบที่เกือบถูก แต่ในทางจิตวิทยากลับมีความเสพติดคล้ายเครื่องพนัน
มีคนบอกว่า “ฉันเขียนโค้ด 10,000 บรรทัดด้วย AI ใน 10 ชั่วโมง แต่มันแย่มาก” แต่ประสบการณ์แบบนั้นต่างกันได้อย่างสิ้นเชิงตามวิธีเข้าหา
ไม่ว่าจะเป็น การจัดโครงสร้างพรอมป์ การวางแผน การรีวิว การทดสอบ การควบคุมความเร็ว ทุกองค์ประกอบล้วนต่างกันไปในแต่ละคน
นักพัฒนามือใหม่จำนวนมากลองใช้แนวทางด้นสดที่เรียกว่า ‘vibe coding’ แล้วก็ล้มเหลว
ตอนนี้กำลังพักเพราะความเหนื่อยล้าสะสม และสักวันหนึ่งก็มีแผนจะ สร้างเอเจนต์ด้วยตัวเอง
ฉันรู้สึกว่าเอาเรื่องพวกนี้ไปฝากไว้กับบิ๊กเทคอย่าง OpenAI, Microsoft หรือ Anthropic นั้นอันตราย
สุดท้ายฉันคิดว่ามันก็เป็นแค่คำฮิตที่พูดกันไปเท่านั้น
มันเหมือนการหนีไปทำโปรเจกต์แมเนจเมนต์ เพราะไม่อยากเรียนรู้ไลบรารีใหม่
แม้แต่บทความ “Just Talk to It” ที่เคยเป็นกระแส ก็ยังขาดรายละเอียดเชิงลึก
ยิ่งทำแบบด้นสด ก็ยิ่งต้องวางแผนให้รัดกุม นั่นคือใจความที่คุณต้องการสื่อใช่ไหม?
โค้ดที่ถูกเผยแพร่ในตอนนี้ไม่ได้เป็น สิ่งที่มนุษย์สร้างขึ้น อีกต่อไปแล้ว
ถ้าโค้ดแบบนี้ถูกป้อนกลับเข้าไปเป็นข้อมูลฝึก โลกก็อาจเสี่ยงถูกเติมเต็มด้วย ผลลัพธ์ที่ไร้ความหมาย มากขึ้น
มีกรณีคล้ายกันเกิดขึ้นแล้วในงานวิจัยด้านภาษา ที่ข้อความจากเครื่องมีมากเกินไปจนการเก็บข้อมูลแทบไร้ความหมาย
โดยมากแล้วมนุษย์ยังเป็นคนกำหนดทิศทางอยู่
แน่นอน ถ้าเด็กอายุ 12 พิมพ์ว่า “yolo 3d game now” ก็น่ากังวล แต่ขณะเดียวกันมันก็ดูเจ๋งดีเหมือนกัน
เวลาอ่านโค้ดที่ทำแบบ vibe coding มันให้ความรู้สึกเหมือน “English as She is Spoke”
ไวยากรณ์อาจถูกต้อง แต่โค้ดนั้นไม่เหมือนภาษาของมนุษย์
ฉันก็คิดคล้ายกัน
ปกติเวลาพัฒนาแอป ฉันจะสร้าง mental model ขึ้นมาในหัวอยู่หลายวัน และถึงตอนอาบน้ำก็ยังกลับไปจัดโครงสร้างมันใหม่
แต่พอทำแบบ vibe coding บริบทภายในแบบนั้นหายไป และการอ่านโค้ดก็กลายเป็นเรื่องทรมาน
ตรงกันข้าม โค้ดที่ฉันเขียนเองกลับอ่านได้อย่างเพลิดเพลิน
ฉันเข้าใจการเชื่อมต่อระหว่างระบบและการไหลของข้อมูล แต่รายละเอียดการอิมพลีเมนต์กลับพร่าเลือน
ฉันก็มีประสบการณ์คล้ายกัน LLM ทำให้ความสนุกของการเขียนโปรแกรมลดลง
กิจวัตรตอนนี้คือ “เขียนพรอมป์ → รอสักครู่ → ทำซ้ำ → รีวิวโค้ด” วนไปเรื่อย ๆ
แม้จะเข้าใจโครงสร้างของโค้ด แต่เพราะไม่ได้ลงมือจัดการมันเองโดยตรง ความลึกของความเข้าใจ จึงตื้นลง
ถ้ามีการฝึกฝนที่ถูกต้องก็คงเป็นไปได้ แต่ฉันยังไปไม่ถึงจุดนั้น
มันมีประโยชน์กับการสร้างโค้ดทดสอบมาก เขียนเทสต์ดี ๆ เองสักหนึ่งอัน แล้วให้ AI ทำที่เหลือ ก็ช่วยประหยัดเวลาได้
ด้วยวิธีนี้ฉันจะเห็นขีดจำกัดของมัน แล้วค่อยเขียนใหม่เป็นระบบที่ออกแบบดีกว่า
ถึงโค้ดจาก LLM จะเยิ่นเย้อ แต่ฉันก็ยังรู้สึกว่ามันดีกว่า โค้ดประหลาด ที่นักพัฒนายุคก่อนทิ้งไว้
เป็นข้อความที่ค่อนข้างพูดเกินไปหน่อย แต่ฉันก็เห็นด้วย
LLM มีประโยชน์กับ การทำความเข้าใจและสรุปโค้ดเดิม, การทำ autocomplete และ การทำต้นแบบโดยคนที่ไม่ใช่นักพัฒนา แต่
ห้ามนำไปใช้กับ การเขียนโค้ด production เด็ดขาด
ทางแก้คือทำให้โมเดลมี grounding
สำหรับโค้ด วิธีนั้นคือ การพัฒนาแบบขับเคลื่อนด้วยการทดสอบ (TDD)
ให้เขียนเทสต์ก่อน ยืนยันว่ามันล้มเหลว ตรวจสอบเหตุผล แล้วค่อยให้เขียนโค้ด
แบบนี้จะได้ ข้อกำหนดพฤติกรรมของโค้ด และต่อมาก็กลายเป็นเอกสารที่ทั้งคนหรือเอเจนต์ใช้อ้างอิงได้
ฉันลองอ่าน README บน GitHub จนจบ แล้วพบว่าผู้เขียนยอมรับว่าโค้ด 3/4 เป็น สิ่งที่ AI สร้างขึ้น แต่ก็ยัง อ้างสิทธิ์ลิขสิทธิ์ อยู่
มีคำพิพากษาอยู่แล้วว่าเนื้อหาที่ไม่ได้สร้างโดยมนุษย์นั้น ไม่สามารถได้รับความคุ้มครองลิขสิทธิ์ตามกฎหมายได้