นักพัฒนาซอฟต์แวร์ที่ใช้ชื่อว่า Glyph เปิดบทความ Programming Isn’t Special บนบล็อก Deciphering Glyph ด้วยการเปรียบเทียบคนสองกลุ่มไว้อย่างชัดเจนตั้งแต่ย่อหน้าแรก

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

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

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

คำถามที่ว่า dev ควรต่อต้าน AI แบบศิลปินไหม มีคำตอบที่สวนทางกันอย่างสิ้นเชิงจากสองบทความที่ไม่ได้เขียนตอบกัน แต่ออกมาในเวลาไล่เลี่ยกัน

• Glyph มองว่า "ควร" เพราะการเขียนโปรแกรมก็คืองานศิลปะ ไม่ต่างจากงานเขียนหรืองานวาดภาพ
• Sean Goedecke มองต่างออกไป ในบทความ Software's centaur age may last decades เขาชี้ว่า dev ที่ทำงานคู่กับ AI ทำผลงานได้เหนือกว่าทั้งคนที่เขียนโค้ดคนเดียว และเหนือกว่า AI ที่ทำตามลำพัง เขาประเมินว่ายุคทำงานร่วมกันแบบนี้อาจอยู่อีก 10–20 ปี และคนที่ไม่ยอมปรับตัวมาจับคู่กับ AI ต่างหากที่จะเป็นฝ่ายแพ้

แต่พออ่านบทความทั้งสองชิ้นจนจบ เรามองว่าทั้งสองฝั่งกลัวสิ่งเดียวกัน นั่นคือ dev ที่พึ่งพา AI มากเกินไป จนเลิกทำความเข้าใจโค้ดที่ตัวเองสร้างขึ้นมา

Deferred บทกวีของคนที่เบื่อ callback

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

เรื่องราวเริ่มต้นจากการเขียนโปรแกรมแบบ client/server ที่ต้องสั่งงานข้ามเครื่องผ่านระบบ RPC ซึ่งเป็นการสั่งให้อีกเครื่องทำงานแล้วรอผลส่งกลับมา ในยุคนั้น ทุกครั้งที่ส่งคำสั่งไป เราจะต้องแนบฟังก์ชันไปด้วยสองตัวเสมอ ตัวแรกคือ callback เพื่อทำงานต่อเมื่อได้ผลลัพธ์ และตัวที่สองคือ errback เพื่อรับมือตอนระบบพัง Glyph บอกว่า แม้ฟังก์ชันสองตัวนี้จะทำงานได้ดี แต่หน้าตาโค้ดกลับดูรกและชวนหงุดหงิดเวลาใช้งาน

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

ตามที่ Glyph เล่า แนวคิดของ Deferred ส่งต่อไปยัง MochiKit.Async พัฒนาต่อเป็น jQuery Deferred ต่อยอดเป็น JavaScript Promises จนกลายมาเป็น async/await ในที่สุด

Deferred จึงเป็นต้นทางสายหนึ่งของ async/await ตามที่ Glyph เล่า แต่ตรงนี้ต้องแยกแยะให้ชัดเจน เพราะ Glyph ไม่ได้คิดค้น Promise หรือ async/await เขายอมรับอย่างตรงไปตรงมาว่าเขาไม่ใช่คนแรกที่คิดค้น แต่หยิบยืมไอเดียมาจาก Promises ของภาษา E และแนวคิดอื่นอีกหลายอย่างมารวมกัน เขาเองก็ไม่อยากให้ใครยกย่องเกินจริง เพราะการมีบทกวีสักชิ้น ไม่ได้แปลว่าจะต้องเป็นบทกวีที่ดีเสมอไป

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

ปกป้องงานน่าเบื่อ เพราะฝีมือก่อตัวขึ้นจากตรงนั้น

Glyph บอกว่า ถ้าเขาไม่เคยต้องทนเขียน callback ด้วยมือซ้ำๆ เป็นพันครั้ง เขาก็คงไม่มีทั้งฝีมือและแรงผลักดันที่จะคิดค้น Deferred ขึ้นมา

ความคิดนี้คือหัวใจของหัวข้อ 'ปกป้องงานจำเจ' หรือ Defend The Mundane ในบทความของเขา เพราะถ้าเราให้ AI เข้ามาทำงานพื้นฐานที่น่าเบื่อไปจนหมด ทั้งงานเขียนคำโฆษณา งานกราฟิกธรรมดา หรืองานรับทำ theme WordPress ซ้ำๆ เท่ากับว่าเรากำลังตัดโอกาสฝึกฝนที่คนทำงานต้องใช้ยกระดับฝีมือทิ้งไปด้วย เขาชี้ว่าการเรียนรู้ตามตำราเป็นเรื่องดี แต่ทักษะของจริงส่วนใหญ่สร้างขึ้นจากการลงมือทำงานจริง และที่ผ่านมาก็เป็นแบบนี้มาตลอด

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

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

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

งานชุ่ยก็คืองานชุ่ย ไม่ว่าจะออกมาในสื่อไหน

สีส่วนใหญ่ในโลกมีไว้ทาผนัง

ความเห็นในกระทู้ Lobsters ไม่ได้เข้าข้าง Glyph ไปทั้งหมด

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

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

อีกคนบอกว่า ความเป็นศิลปะของโค้ดมีแค่ dev ด้วยกันเท่านั้นที่มองเห็น เพราะเวลาโปรแกรมทำงานจริง ผู้ใช้งานไม่มีทางแยกออกเลยว่าโค้ดเบื้องหลังนั้นมนุษย์หรือ AI เป็นคนเขียน ขณะที่อีกคนชี้ว่า งานเขียนโปรแกรมพิเศษตรงที่เนื้องานจำนวนมากคือ "การค้นคว้าแบบใช้ครั้งเดียวทิ้ง" เช่น การนั่งขุดเอกสารสเปกฮาร์ดแวร์อย่าง datasheet หรืออ่านคู่มือที่เขียนไว้แย่ๆ ของ framework (ชุดโครงสร้างโค้ดสำเร็จรูป) ซึ่งงานพวกนี้ AI ทำได้ดีมาก

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

ถ้าข้อสังเกตนี้เป็นจริง ก็ช่วยอธิบายได้ทั้งฝั่งศิลปินที่บอกว่า AI เขียนโค้ดได้สบายๆ และฝั่ง dev ที่มองงานภาพหรืองานเขียนของสายอื่นด้วยสายตาแบบเดียวกัน

ยุค centaur จากกระดานหมากรุกถึง Claude Code

หันมาดูมุมมองของ Sean Goedecke บ้าง เขาเปิดเรื่องด้วยคำศัพท์จากวงการหมากรุก

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

Goedecke ชี้ว่า วงการซอฟต์แวร์เข้าสู่ยุคแบบนี้มาตั้งแต่ปี 2022 แล้ว และไล่เรียงให้เห็นว่าการจับคู่ระหว่างคนกับ AI พัฒนามาอย่างไรบ้าง:

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

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

ข้อสรุปของเขาจึงมีสองด้าน:

1. คนล้วนสู้ไม่ได้แล้ว: ทุกวันนี้ไม่มีใครอ้างได้อย่างมีน้ำหนักอีกแล้วว่า วิศวกรที่ไม่ยอมใช้ AI จะเอาชนะทีม centaur ได้
2. AI ล้วนก็ยังสู้ทีมที่คนจับคู่กับ AI ไม่ได้: agent ที่ทำงานตามลำพังโดยไม่มีคนคอยกำกับ ก็ยังเอาชนะทีม centaur ไม่ได้เช่นกัน เพราะผลงานที่น่าประทับใจทั้งหมดที่เขาเห็นจากโมเดล AI ล้วนมีวิศวกรซอฟต์แวร์ฝีมือดีคอยคุมอยู่เบื้องหลังทั้งสิ้น

หมากรุกอยู่ 20 ปี งานถักอยู่ 200 ปี

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

แล้วยุค centaur ของงานซอฟต์แวร์จะยาวนานแค่ไหน? Goedecke แจกแจงเหตุผลของทั้งสองฝั่งไว้ดังนี้:

• เหตุผลที่อาจทำให้สั้นกว่าหมากรุก: งานซอฟต์แวร์สร้างมูลค่าทางเศรษฐกิจมหาศาล เม็ดเงินที่ทุ่มลงมาแก้โจทย์นี้จึงมากกว่าวงการหมากรุกแบบเทียบกันไม่ติด นอกจากนี้ AI ที่เก่งพอจะทำงานซอฟต์แวร์ได้ ยังส่งผลกระทบต่ออาชีพอื่นเป็นวงกว้าง จนอาจเกิดแรงกระเพื่อมอย่างวิกฤตเศรษฐกิจหรือความวุ่นวายในสังคมที่ย้อนกลับมากระทบงาน dev อีกทั้งเทคโนโลยีเองก็เปลี่ยนเร็วขึ้นเรื่อยๆ
• เหตุผลที่อาจทำให้ยาวกว่าหมากรุก: ยิ่งเราสร้างซอฟต์แวร์ได้ง่ายขึ้น ปริมาณงานโดยรวมที่ต้องทำก็ยิ่งมากขึ้น แม้สัดส่วนงานที่คนทำจะลดลง แต่ปริมาณงานที่คนทำโดยรวมอาจเพิ่มขึ้นได้ อีกทั้งหมากรุกอาจเป็นกรณีที่ยุค centaur สั้นผิดปกติ เพราะในอดีตอย่างกรณีงานถัก ยุคนี้เคยอยู่ยาวนานถึง 200 ปี

เขาบอกว่า ถ้าจะหาเหตุผลเพิ่มก็คงหาได้อีกหลายข้อ แต่ความจริงที่ต้องยอมรับคือ ไม่มีใครรู้แน่ชัดว่าจะออกมาในรูปแบบไหน หมากรุกคือกรณียุค centaur ล่าสุดที่มีให้ศึกษา และเป็นงานที่เจอระบบอัตโนมัติจาก AI ในลักษณะเดียวกับงานซอฟต์แวร์ สมมติฐานตั้งต้นที่สมเหตุสมผลจึงเป็นการมองว่ายุคนี้น่าจะยาวพอๆ กัน และนี่คือที่มาของตัวเลขคาดการณ์ "10 ถึง 20 ปี"

อย่างไรก็ดี ตัวเลข 10–20 ปีนี้เป็นเพียงการประเมินส่วนตัวของ Goedecke จากการเทียบกับหมากรุก ไม่ใช่ผลสรุปจากงานวิจัย และสิ่งที่เขาประเมินคือ "ช่วงเวลาที่คนจับคู่กับ AI จะเก่งที่สุด" ไม่ใช่คำสัญญาว่างาน dev จะปลอดภัยไปอีก 20 ปี เพราะตามเหตุผลในฝั่งที่มองว่าเวลาอาจสั้นกว่านั้น แรงกระเพื่อมทางเศรษฐกิจก็อาจกระทบงานได้อยู่ดี

อย่ารีบลาออก แต่อย่าเป็นแค่คนส่งต่องาน

จากตัวเลขคาดการณ์นี้ Goedecke แนะนำไว้ 3 ข้อ:

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

ข้อสอง จงจับคู่กับ AI: เขาเขียนไว้อย่างตรงไปตรงมาว่า วิธีที่จะแพ้อย่างแน่นอนในยุค centaur คือการไม่ยอมเป็น centaur การมองว่า AI เป็นแค่กระแสชั่วคราวเคยเป็นจุดยืนที่ฟังขึ้นในปี 2023 แต่วันนี้เลยจุดนั้นมาไกลมากแล้ว

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

คนที่ไม่เคยคิดเรื่องนี้เลย กำลังเสี่ยงกลายเป็นเพียง meat proxy หรือคนที่ทำหน้าที่แค่ส่งต่อผลงานของ AI ไปอีกทอด ส่วน dev มือใหม่ที่กำลังกังวลเรื่องนี้ อ่านต่อได้ที่คำเตือนถึง dev มือใหม่ว่าอย่าเพิ่งตื่นตระหนก

สองฝั่งกลัว dev แบบเดียวกัน

เมื่อวางสองบทความเทียบกัน จุดร่วมกลับเด่นชัดยิ่งกว่าจุดที่เห็นต่าง

ฝั่ง Glyph กลัวว่าการใช้ AI จะตัดทอนความเข้าใจและการตัดสินใจเชิงสร้างสรรค์ทิ้งไป ส่วนฝั่ง Goedecke ที่บอกให้จับคู่กับ AI ก็ยืนยันว่า งานดีทุกชิ้นที่เขาเห็นมีวิศวกรเก่งๆ คุมอยู่ และคุณค่าที่คนยังเหลือคือการทำให้งานตรงกับที่องค์กรต้องการ เราจึงมองว่า ทั้งสองฝั่งต่างกลัวคนแบบเดียวกัน นั่นคือ dev ที่ปล่อยให้ AI คิดแทนทุกอย่าง จนตัวเองไม่เข้าใจงานที่ส่งออกไป

ทางเลือกของ dev ในวันนี้ จึงไม่ใช่เรื่องขาวดำว่าจะใช้หรือไม่ใช้ AI แต่อยู่ที่ว่าจะยกส่วนไหนให้มันต่างหาก

• ถ้ายกให้หมด ก็เสียโอกาสฝึกและความเข้าใจแบบที่ Glyph เตือน
• แต่ถ้าไม่ยกให้เลย ก็เสี่ยงที่จะแพ้ทีมที่ทำงานคู่กับ AI แบบที่ Goedecke เตือน

เราจึงขอแนะนำแนวทางปฏิบัติจริง 3 ข้อ:

1. ให้ AI รับงานค้นคว้าแบบใช้ครั้งเดียวทิ้งและงานซ้ำซาก: เช่น การค้นหาวิธีใช้จาก datasheet หรือเอกสาร framework แต่เก็บการตัดสินใจเชิงออกแบบไว้ทำเอง เช่น จะแบ่งระบบออกเป็นส่วนอะไรบ้าง หรือส่วนไหนควรทุ่มเททรัพยากรมากกว่ากัน
2. อ่านและรีวิวทุกอย่างที่ AI เขียนจนสามารถอธิบายให้คนอื่นฟังได้: เพราะสิ่งที่ agent พลาดในตอนนี้มักเป็นการทำไม่ตรงกับที่ทีมต้องการ มากกว่าจะเป็นบั๊กธรรมดา และคนที่รู้ว่าทีมต้องการอะไรได้ดีที่สุดก็คือคนในทีมเอง
3. ถ้ายังเป็นมือใหม่ ให้ยอมผ่านงานน่าเบื่อด้วยตัวเองบ้าง: แบบที่ Glyph ต้องทนเขียน callback ด้วยมือนับพันครั้งก่อนจะคิด Deferred ได้ เพราะงานธรรมดาเหล่านั้นคือสนามฝึกที่ฝีมือจะค่อยๆ ก่อตัวขึ้นมา ส่วนคำถามว่าในยุคนี้ยังต้องเรียนเขียนโค้ดอยู่ไหม อ่านต่อได้ในยังต้องเรียนเขียนโค้ดไหมในปี 2026

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

---

ที่มา:

• บทความ Programming Isn’t Special จาก Glyph
• บทความ Software's centaur age may last decades จาก Sean Goedecke
• กระทู้ Programming Isn’t Special บน Lobsters