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

เมื่อวันที่ 8 สิงหาคม Senko Rašić เขียนบทความโต้ประโยคนี้ในบล็อกของตัวเอง โดยพาดหัวว่าประโยคดังกล่าวเป็นการดูถูกโปรแกรมเมอร์ทุกคน วิธีโต้ของเขาคือยิงคำถามกลับเป็นชุด แล้วปล่อยให้คนอ่านหาคำตอบเอง จากนั้นคนในเธรดบน Lobsters ก็ถกกันต่อยาวถึง 27 คอมเมนต์ คนในเธรดแบ่งเป็นสองฝ่ายที่เห็นต่างกัน แต่เหตุผลของทั้งสองฝ่ายก็มีน้ำหนัก

ถ้าเขียนโค้ดเป็นเรื่องง่าย แล้วทำไมวงการนี้ถึงเป็นแบบนี้

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

• โปรแกรมเมอร์เป็นที่ต้องการและได้ค่าตอบแทนสูงมาหลายปีแล้ว ตั้งแต่ก่อนยุคดอกเบี้ยต่ำที่ผลักให้บริษัทเทคเร่งจ้างคน
• ความเครียด งานล้นมือ และภาวะหมดไฟมีมานาน ก่อน AI จะเริ่มยิง PR ห้าพันบรรทัดใส่ทีมเสียอีก
• บริษัทยังตามหาโปรแกรมเมอร์ระดับ 10x rockstar และยังคัดคนด้วยรอบสัมภาษณ์แบบ leetcode ที่ให้แก้โจทย์อัลกอริทึม
• วงการยังต้องผลิตทั้งหนังสืออ้างอิงเล่มหนา บูตแคมป์ และหลักสูตรปริญญา เพื่อสอนสิ่งที่ควรจะง่าย
• ซอฟต์แวร์ที่ปล่อยออกมาก็ยังพังอยู่บ่อยๆ

คำถามชุดที่สองพลิกมองจากอีกด้าน ถ้าการตัดสินใจว่าจะสร้างอะไรเป็นส่วนที่ยากกว่าจริง ทำไม product manager จึงไม่ได้ค่าตอบแทนสูงกว่า developer และไม่ต้องผ่านรอบสัมภาษณ์ที่เข้มกว่า ทำไมคนทำ market research คนทำ UX และทีม customer success จึงไม่ใช่ดาวเด่นของวงการ ทำไม business analyst ถึงถูกมองต่ำ และทำไมโปรแกรมเมอร์ถึงหงุดหงิดเมื่อเซลส์รับปากลูกค้าว่าจะมีฟีเจอร์นั้นเพื่อปิดดีล

คำถามเหล่านี้ไม่มีเฉลยแนบมาด้วย แต่ทำให้เห็นชัดว่าวิธีที่วงการปฏิบัติต่องานสองอย่างนี้ไม่ตรงกับสิ่งที่ประโยคดังกล่าวบอก

ต้องอ่านประโยคนี้แบบไหน มันถึงยังฟังขึ้น

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

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

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

อีกเสียงหนึ่งแย้งว่า ต่อให้งานง่ายก็ไม่ได้แปลว่าไม่ควรทำให้เป็นอัตโนมัติ การกดปุ่มวันละครั้งหรือสัปดาห์ละครั้งไม่ใช่เรื่องยาก แต่ก็ยังคุ้มที่จะเขียน cron job มาทำแทน ส่วนอีกคนเล่าถึงงาน refactor ที่แค่ไล่แก้ตามขั้นตอน งานนี้ไม่ยากแต่กินเวลาราวสามชั่วโมง ตั้งแต่แก้โค้ด รอดู error จาก compiler แล้วไล่แก้ต่อทีละจุด เจ้าตัวบอกว่าถ้าไม่มี LLM ช่วย ก็คงไม่ทำงานนี้ตั้งแต่แรก

เส้นแบ่งระหว่างข้อสังเกตกับข้ออ้าง

ในเธรดเดียวกัน มีสองคอมเมนต์ที่จับประเด็นหลักของเรื่องนี้ได้ตรงกว่าความเห็นอื่น

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

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

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

แล้วควรลงแรงฝึกอะไรต่อ

ข้อสรุปของบทความต้นทางไม่ได้เลือกข้างใดข้างหนึ่ง

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

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

ส่วนคนที่เพิ่งเริ่มหรือยังอยู่ระดับจูเนียร์ ควรลงลึกกับพื้นฐานว่าซอฟต์แวร์ทำงานจริงอย่างไร ตั้งแต่ pointer และ recursion ซึ่งเป็นการเรียกตัวเองซ้ำ ไปจนถึงลำดับชั้นของหน่วยความจำและการทำงานของ HTTP ความรู้เหล่านี้ยังได้ใช้ แม้จะทำเฉพาะงานฝั่งหน้าเว็บหรือปลั๊กอิน WordPress นอกจากนี้ยังควรเรียนโครงสร้างข้อมูลและฝึกโจทย์แบบ leetcode รวมถึงกล้าถามอยู่เสมอว่าทำไม และจริงๆ แล้วมันทำงานอย่างไร

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

---

ที่มา:

• บทความ "Code was never the hard part" is an insult to all programmers จาก blog.senko.net
• เธรดสนทนาเรื่อง "Code was never the hard part" is an insult to all programmers จาก Lobsters