ถ้าคุณเป็นนักศึกษาสายคอมหรือโปรแกรมเมอร์ปีแรกที่กำลังกังวลว่า AI จะมาแย่งงานไหม Sean Goedecke วิศวกรซอฟต์แวร์ผู้เขียนบล็อกสายเทคโนโลยี เพิ่งเขียนคำแนะนำถึงวิศวกรซอฟต์แวร์มือใหม่โดยตรง ในบทความ Advice to a beginning software engineer ที่เผยแพร่เมื่อ 26 กันยายน 2026 เขาไม่ได้เริ่มด้วยคำปลอบใจให้รู้สึกดี แต่เปิดเรื่องด้วยคำเตือนว่า ให้ระวังคำแนะนำจากวิศวกรทั้งหลายเอาไว้ให้ดี

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

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

คำทำนายว่าอาชีพนี้จะจบสิ้น มีมาแล้วทุกยุค

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

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

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

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

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

มือใหม่ไม่มีอำนาจต่อรองพอจะต่อต้าน AI

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

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

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

อย่าเป็น meat proxy ที่ทำหน้าที่แค่ส่งต่อคำตอบ

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

คนที่ทำแบบนั้น เขาเรียกว่าเป็น “meat proxy” หรือตัวกลางมนุษย์ที่ทำหน้าที่แค่รับคำตอบจาก AI แล้วส่งต่อให้คนอื่นโดยไม่ผ่านการคิดวิเคราะห์ของตัวเองเลยแม้แต่ขั้นตอนเดียว โดยคำนี้หยิบมาจากบทความ Don't be a meat proxy

ลองนึกภาพง่ายๆ ว่ารุ่นพี่ถามในแชตว่าทำไมถึงออกแบบระบบแบบนี้ คุณก็ก๊อปคำถามไปถาม AI แล้วก๊อปคำตอบที่ AI พิมพ์กลับมาวางตอบรุ่นพี่ทันที จังหวะนั้นเองที่คุณกลายเป็น meat proxy เต็มตัว

เขามองว่า คนส่วนใหญ่กลายเป็น meat proxy เพราะความตื่นตระหนก รู้สึกว่าทักษะของตัวเองหมดความหมายแล้ว และมองว่าโมเดลฉลาดกว่าตัวเอง เลยคิดว่าคงทำอะไรไม่ได้นอกจากก้มหน้าทำตามที่ Claude หรือ GPT-6 แนะนำ การปล่อยให้ AI แบกรับความรับผิดชอบแทนอาจทำให้รู้สึกโล่งใจในระยะสั้น เพราะอย่างน้อยตอนนี้ความรับผิดชอบก็เป็นของ AI ไม่ใช่ของเรา แต่เขาย้ำชัดเจนว่านี่เป็นวิธีคิดที่ไม่เข้าท่าเลย

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

และถ้า AI อธิบายอะไรมาแล้วคุณยังไม่เข้าใจ เขาให้ทางเลือกไว้แค่สองทาง คือ “ซักถามต่อจนกว่าจะเข้าใจจริงๆ” หรือไม่ก็ “อย่าเอาวิธีนั้นไปใช้” ส่วนการก๊อปไปส่งต่อทั้งที่ยังไม่เข้าใจ ไม่อยู่ในตัวเลือกตั้งแต่แรก

ถามเฉลี่ยหนึ่งคำถามทุก 30 วินาที

คำแนะนำที่บอกให้ถามกลับจะใช้ได้จริงก็ต่อเมื่อคุณรู้วิธีถาม ซึ่งเขาลงรายละเอียดวิธีถามไว้ในบทความ You should all be asking way more questions ที่เผยแพร่ไปก่อนหน้านั้นหนึ่งวัน (25 กันยายน 2026)

เขาเปิดบทความด้วยการเล่านิสัยส่วนตัวว่า เวลาที่มีใครมาอธิบายอะไรให้ฟัง เขาจะถามแทรกเฉลี่ยหนึ่งคำถามทุกๆ 30 วินาที คำถามส่วนใหญ่เป็นคำถามสั้นๆ แค่เพื่อยืนยันว่าตัวเองเข้าใจถูกต้อง เช่น “ที่บอกว่า X หมายถึง Y ใช่ไหม” หรือ “X ตัวนี้คือตัวเดียวกับที่พูดถึงตอนเล่าเรื่อง Z ใช่หรือเปล่า”

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

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

นึกภาพแผนงานตามไปในหัวระหว่างฟัง

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

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

ระหว่างที่ไล่เช็ก 3 เรื่องนี้ในหัว ถ้าได้ยินอะไรที่ฟังดูคลุมเครือน่าสงสัย เขาจะถามแทรกทันทีว่า “เดี๋ยวนะ ตรงนี้จะทำงานยังไงนะ”

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

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

5 คำถามก่อนปล่อยให้ AI agent ลงมือ

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

ทุกวันนี้เขาทำงานร่วมกับโมเดลอย่าง GPT-6-Astra และ Claude Opus 5.5 เป็นหลัก ทั้งสองตัวเป็นโมเดลที่ดีและไม่ค่อยพลาดเรื่องโค้ด สั่งให้ทำอะไรก็มักทำได้ ซึ่งเขาเสริมว่าข้อนี้อาจต่างไปถ้าทำงานต่างสายงานหรือใช้ภาษาโปรแกรมอื่น แต่เรื่องการออกแบบ ทั้งสองตัวพลาดอยู่ตลอด

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

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

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

1. “ใน codebase นี้ มีตรงไหนทำเรื่อง X ไว้อยู่แล้วหรือเปล่า” ใช้ตอนที่ AI agent กำลังจะสร้างฟังก์ชันหรือระบบใหม่ ทั้งที่ในโปรเจกต์อาจมีระบบเดิมทำไว้อยู่แล้ว
2. “service Y รองรับการยืนยันตัวตนแบบนี้จริงๆ ใช่ไหม หรือคุณกำลังคิดไปเองว่าเราต้องไปสร้างส่วนนั้นเพิ่ม” ใช้ตอนที่แผนงานกำหนดให้ 2 ระบบต้องเชื่อมต่อสื่อสารกัน
3. “ระบบย่อยที่คุณเสนอมานี้ จำเป็นต่อข้อกำหนด Z จริงๆ หรือเปล่า หรือที่จริงมันไปตอบโจทย์อื่นที่คุณคิดขึ้นมาเอง” ใช้ตอนที่ AI agent ออกแบบระบบให้ใหญ่และซับซ้อนเกินกว่าโจทย์ที่ได้รับ
4. “ทำไมต้องไปแก้ interface ของ A ด้วย” ใช้ตอนที่แผนงานเริ่มไปแตะต้องจุดที่มีโค้ดส่วนอื่นเรียกใช้งาน A อยู่
5. “ทำไมต้องแก้ไฟล์นี้ มันไม่เกี่ยวกับสิ่งที่เรากำลังทำไม่ใช่เหรอ” ใช้ตอนเห็นไฟล์ที่ไม่น่าจะเกี่ยวข้อง โผล่เข้ามาในรายการที่ AI agent กำลังจะแก้ไข

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

ฉลาด เป็นมิตร และตั้งใจทำความเข้าใจงาน

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

คำว่า “ตั้งใจทำความเข้าใจงาน” ในความหมายของเขา คือการพยายามทำความเข้าใจระบบที่เรากำลังทำงานด้วย แทนที่จะคิดง่ายๆ ว่าเดี๋ยวคงมีคนอื่นมารับช่วงดูแลต่อ คนที่เป็น meat proxy จะข้ามขั้นตอนนี้ไปทั้งหมด ขณะที่การถามคำถามทุกๆ 30 วินาที คือการค่อยๆ ต่อภาพความเข้าใจนั้นขึ้นมาทีละคำถาม

ถ้าจะให้เริ่มจากเรื่องเดียว การบ้านที่เราอยากชวนให้ลองคือ ครั้งหน้าที่ AI agent เสนอแผนงานมา ก่อนกดยืนยันให้มันลงมือทำ ลองหยิบคำถามจาก 5 ข้อข้างบนไปถามมันก่อนอย่างน้อยหนึ่งข้อ

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

---

ที่มา:

• บทความ Advice to a beginning software engineer จาก Sean Goedecke
• บทความ You should all be asking way more questions จาก Sean Goedecke