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

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

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

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

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

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

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

ประโยคนี้ยืนได้ตรงไหน และบทความเองเกินไปตรงไหน

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

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

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

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

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

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

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

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

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

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

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

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

สิ่งที่บทความเสนอให้ทำแทนคือการทำความเข้าใจทั้งระบบที่กำลังสร้างและเหตุผลที่สร้างมันขึ้นมาให้ลึกพอกัน จากนั้นคำแนะนำจึงแยกไปตามระดับประสบการณ์ คนที่เป็นซีเนียร์อยู่แล้วไม่ควรลงลึกเฉพาะสายของตัวเอง แต่ควรเรียนรู้เรื่องที่อยู่ข้างเคียงด้วย เช่น 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