โปรแกรมเมอร์กับสแตนด์: อาชีพนี้จะเหลืออยู่ไหม เมื่อ AI เขียนโค้ดแทนได้หมด?

โดย Nokka (นก-กา) | 5 พ.ย. 2026

บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

ในการ์ตูนเรื่อง JoJo's Bizarre Adventure มีช่วงหนึ่งที่ตัวละครชื่อฮอลลี่ คูโจได้รับพลังที่เรียกว่าสแตนด์โดยไม่พร้อม เธอควบคุมมันไม่ได้ และสแตนด์นั้นก็เริ่มกัดกินร่างของเธอเองช้า ๆ [1]

ผมคิดถึงตอนนี้ทุกครั้งที่เห็นคนเอาตัวแทน AI ไปต่อกับระบบจริงทั้งที่ยังไม่รู้ว่ามันทำอะไรได้และทำอะไรไม่ได้

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

สแตนด์ในเรื่องคืออะไร และทำไมมันถึงเข้ากับงานเรา

ในเรื่อง สแตนด์ถูกอธิบายว่าเป็นรูปร่างที่จิตใจนักสู้แผ่ออกมา แต่ละตัวมีความสามารถพิเศษเฉพาะตัว และปรากฏตัวครั้งแรกในภาคที่สามหรือ Stardust Crusaders ปี 1989 [1]

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

เทียบกับเอเจนต์แล้ว ความสามารถของมันไม่ใช่ตัวปัญหา ปัญหาคือการยื่นความสามารถนั้นให้คนที่ยังไม่มีวิธีตรวจสอบมัน

แผนที่เทียบระหว่างสแตนด์กับเอเจนต์

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

การจับคู่แบบนี้ทำให้เห็นทันทีว่า ข้อได้เปรียบไม่ได้อยู่ที่ใครมีโมเดลแรงกว่า แต่อยู่ที่ใครตั้งกติกาได้คมกว่า

ฝั่งที่บอกว่าเกมเปลี่ยนแล้ว: AI-native SDLC ของ Anthropic

Anthropic เผยแพร่คู่มือชื่อ The AI-native SDLC playbook เมื่อ 21 ส.ค. 2026 โดยแบ่งวงจรพัฒนาซอฟต์แวร์เป็นหกช่วง คือ Plan, Design, Build, Test, Deploy และ Maintain [2]

แกนของคู่มือคือประโยคสั้น ๆ ว่าการเขียนโค้ดไม่ใช่คอขวดอีกต่อไปแล้ว คอขวดย้ายไปอยู่ที่การวางแผน การตรวจ และการปล่อยของ ซึ่งยังวิ่งด้วยความเร็วคน [2]

เอกสารไม่ได้มีไว้ส่งต่อ แต่มีไว้สั่งงาน

ในคู่มือ ช่วง Plan ให้คนเขียนปัญหาด้วยภาษาของตัวเองเป็นไฟล์ intent.md ระบุว่าอยากได้อะไร เพราะอะไร และมีข้อจำกัดอะไร [2]

พอไฟล์นั้นผ่านการอนุมัติ เอเจนต์จะแปลงเป็น spec.md ที่ผูกกับนโยบายขององค์กร จากนั้นตอนสร้างงาน วิศวกรเปิดโหมดวางแผนให้เอเจนต์อ่านโค้ดโดยยังไม่แก้อะไร แล้วถามซ้ำ จนได้ plan.md ที่คนอื่นอ่านแล้วลงมือต่อได้ [2]

intent.md  ->  spec.md  ->  plan.md  ->  โค้ด  ->  PR  ->  deploy
   คนเขียน     เอเจนต์+คน     เอเจนต์+คน     เอเจนต์    ด่านตรวจ

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

ด่านตรวจที่ห้ามให้เอเจนต์แก้ด่านตัวเอง

ช่วง Test ของคู่มือมีข้อกำหนดข้อหนึ่งที่ผมคิดว่าสำคัญที่สุดในเอกสารทั้งฉบับ คือเอเจนต์ที่กำลังแก้โค้ดต้องไม่สามารถลดความเข้มของชุดทดสอบที่ตรวจโค้ดนั้นได้ [2]

วิธีที่เขาแนะนำคือใช้ hook บล็อกการแก้ไฟล์ทดสอบระหว่างงานซ่อมบำรุง [2]

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

คู่มือยังแนะนำให้เก็บงานจริง 20 ถึง 50 งานมาเขียนเป็นชุดทดสอบ และรันชุดนั้นทุกครั้งที่มีการแก้ CLAUDE.md สกิล หรือฮุก เพราะค่าตั้งเหล่านี้คือสิ่งที่บังคับพฤติกรรมของเอเจนต์ [2]

pstack: ทางของคนที่ไม่เชื่อว่าปริมาณคือคุณภาพ

อีกแนวคิดที่ยกมาคือ pstack ซึ่งเป็นชุดสกิลที่เขียนโดย poteto ผู้ใช้ GitHub รายนี้เคยทำงานที่ Meta, Netflix และ Cursor และอยู่ทีม React Compiler [3]

เจ้าของเขียนไว้ใน README ตรง ๆ ว่ามีความรู้สึกว่านักพัฒนากำลังปล่อยโค้ดขยะออกมาเยอะขึ้น และเขาไม่ต้องการปล่อยงานแบบทีมศิลปินขยะยี่สิบคน [3]

ประโยคที่ผมชอบที่สุดใน README คือถ้าอยากไปเร็ว ให้ลงลึกก่อน เพราะปริมาณงานที่ไม่มาพร้อมคุณภาพไม่ใช่เป้าหมาย [3]

pstack มีสกิลที่เป็นเครื่องมือมากกว่าคำสอน เช่น blast-radius ที่ให้เอเจนต์พิสูจน์ว่าการเปลี่ยนแปลงเล็ก ๆ ไปกระทบอะไรอีกบ้างด้วยการรันโค้ดจริง ไม่ใช่การยืนยันลอย ๆ [3]

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

ฝั่งที่วัดแล้วว่าไม่ตรงกับคำโฆษณา

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

METR ทำการทดลองแบบสุ่มกับนักพัฒนาระดับสูง 16 คนจากรีโปโอเพนซอร์สขนาดใหญ่ ให้ทำงานจริง 246 งาน แล้วเทียบว่ามี AI ช่วยกับไม่มี [4]

ผลคือกลุ่มที่ได้ใช้ AI ใช้เวลานานกว่าเดิม 19 เปอร์เซ็นต์ [4] ที่น่าสนใจกว่านั้นคือนักพัฒนาคาดไว้ว่าจะเร็วขึ้นราวหนึ่งในสี่ [4] พอทำงานเสร็จ พวกเขายังคิดว่าเร็วขึ้น 20 เปอร์เซ็นต์ทั้งที่ช้ากว่าเดิม [4]

ช่วงปลายปี 2025 ทีมเดิมกลับมาวัดใหม่ด้วยเครื่องมือรุ่นใหม่ [5] กลุ่มนักพัฒนาเดิมเร็วขึ้น 18 เปอร์เซ็นต์ แต่ช่วงความเชื่อมั่นอยู่ที่ -38 ถึง +9 [5] กลุ่มใหม่เร็วขึ้น 4 เปอร์เซ็นต์ โดยมีช่วง -15 ถึง +9 [5] ทั้งสองช่วงคร่อมศูนย์ และ METR เขียนเองว่าข้อมูลชุดนี้ให้สัญญาณที่เชื่อถือไม่ได้ และเป็นหลักฐานที่อ่อนมากสำหรับขนาดของความเร็วที่เพิ่มขึ้น [5]

นี่คือตัวอย่างที่ดีของความซื่อสัตย์ทางวิชาการที่ผมอยากเห็นในวงการเครื่องมือ AI

ใครหายไปจากสนามจริง ๆ

งานวิจัยจาก Stanford Digital Economy Lab เผยแพร่เมื่อ พ.ย. 2025 ใช้ข้อมูลค่าจ้างรายเดือนจาก ADP พบว่าคนทำงานอายุ 22 ถึง 25 ปีในอาชีพที่รับผลจาก AI มาก มีการจ้างงานลดลง 16 เปอร์เซ็นต์เทียบกับกลุ่มควบคุม ขณะที่คนมีประสบการณ์ยังทรงตัว [6]

ผู้เขียนระบุว่าการปรับตัวเกิดจากการจ้างงานมากกว่าค่าตอบแทน [6] และเกิดหนักในอาชีพที่ AI เข้าไปแทนที่ มากกว่าอาชีพที่มันเข้าไปช่วยเสริม [6]

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

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

คำตอบของผม: อาชีพยังอยู่ แต่ชั้นของงานเปลี่ยน

ผมแบ่งงานพัฒนาซอฟต์แวร์เป็นสามชั้น แล้วมองว่าอนาคตของแต่ละชั้นต่างกัน

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

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

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

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

สิ่งที่ผมคิดว่าต้องฝึก ถ้าอยากมีสแตนด์ของตัวเอง

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

สอง หัดสร้างด่านตรวจ ทุกงานที่ให้เอเจนต์ทำ ต้องมีวิธีพิสูจน์ที่ไม่พึ่งคำบอกเล่าของเอเจนต์เอง

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

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

กับดักที่ผมอยากเตือน

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

โค้ดที่เพิ่มเร็วขึ้นทำให้หนี้ทางเทคนิคโตเร็วขึ้น คู่มือของ Anthropic เตือนเองว่าการตรวจทีละบรรทัดใช้ไม่ได้แล้วเมื่อเอเจนต์เขียนโค้ดเกือบทั้ง diff [2] แต่การเลิกตรวจก็ไม่ใช่ทางออก

ตัวเลขความเร็วต้องอ่านให้ดี ทั้งเลข 19 ที่ช้าลง และเลข 18 ที่เร็วขึ้น ต่างมีเงื่อนไขกำกับทั้งคู่ [4][5]

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

ปิดท้าย

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

คนที่ฝึกเอเจนต์จนรู้จักข้อจำกัดของมัน จะทำงานได้มากกว่าคนที่เขียนโค้ดเก่งแต่อย่างเดียว และคนที่ไม่มีด่านตรวจจะสร้างความเสียหายได้เร็วกว่าคนรุ่นก่อนมาก

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

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

[1] Wikipedia · JoJo's Bizarre Adventure (2026) · https://en.wikipedia.org/wiki/JoJo%27s_Bizarre_Adventure
[2] Anthropic · The AI-native SDLC playbook, Louis Claxton (21 ส.ค. 2026) · https://claude.com/blog/the-ai-native-sdlc-playbook
[3] Cursor Plugins · pstack README โดย poteto (2026) · https://github.com/cursor/plugins/tree/main/pstack
[4] METR · Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (10 ก.ค. 2025) · https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
[5] METR · We are Changing our Developer Productivity Experiment Design (24 ก.พ. 2026) · https://metr.org/blog/2026-02-24-uplift-update/
[6] Stanford Digital Economy Lab · Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of AI, Brynjolfsson และคณะ (13 พ.ย. 2025) · https://digitaleconomy.stanford.edu/app/uploads/2025/12/CanariesintheCoalMine_Nov25.pdf