หยุดรับจูเนียร์เพราะ AI ทำงานง่ายๆ ได้แล้ว คือการแก้ผิดจุด
การเลิกรับวิศวกรจูเนียร์เพราะ AI ทำงานง่ายๆ ได้แล้ว ไม่ได้แก้ปัญหาที่แท้จริง ทีมควรแก้วิธีแบ่งงานและพัฒนาคนที่มีอยู่ให้ทำงานเก่งขึ้น

ในพอดแคสต์ตอนหนึ่ง ผู้สัมภาษณ์ถาม CTO ของบริษัทเทคขนาดใหญ่ตรงๆ ว่ายังรับวิศวกรจูเนียร์เข้าทีมหรือไม่ Francisco Trindade ฟังแล้วแปลกใจ เพราะตอนนี้คนในวงการถามเรื่องนี้กันอย่างจริงจังแล้ว เขาจึงเขียนถึงเรื่องนี้ในบทความชื่อ The Kids Are Alright
พาดหัวรองของบทความนั้นบอกว่า การไม่รับวิศวกรจูเนียร์ไม่ได้แก้ปัญหาตามที่หลายคนคิด ส่วน Stack Overflow Blog เผยแพร่อีกบทความหนึ่งเมื่อวันที่ 5 สิงหาคม 2026 บทความนี้พูดถึงองค์กรที่มีพนักงานหนึ่งหรือสองคนเริ่มใช้เอเจนต์ก่อนและทำงานได้มากกว่าคนอื่น เมื่อเห็นความแตกต่าง ผู้บริหารจึงอยากรู้ว่าพนักงานเหล่านั้นมีอะไรพิเศษ เพื่อให้ทุกคนในทีมทำแบบเดียวกันได้ ประเด็นร่วมของทั้งสองบทความคือ องค์กรต้องแก้วิธีแบ่งงานและวิธีพัฒนาคน ไม่ใช่เลิกรับคนที่มีอายุงานน้อย
ข้อโต้แย้งนี้เคยมีมาก่อน แค่คราวนี้อ้าง AI
ความคิดที่จะไม่รับคนอายุงานน้อยมีมานานแล้ว บริษัทเทครับเฉพาะวิศวกรระดับซีเนียร์มานาน เพราะเห็นว่าระบบภายในซับซ้อน และคนที่ยังไม่ชำนาญอาจทำให้ระบบเสียหาย
Trindade เล่าถึงบริษัทหนึ่งที่เขาเคยทำงานด้วย บริษัทนี้รับเฉพาะคนระดับซีเนียร์ขึ้นไป ผลคือหัวหน้าหาคนมาทำงานง่ายๆ ให้เสร็จไม่ได้ เพราะทุกคนคิดว่างานเหล่านั้นไม่เหมาะกับระดับของตัวเอง
ต่อมาบริษัทเดิมเริ่มรับคนที่มีอายุงานน้อยลง และเปิดโปรแกรมฝึกงานเพื่อรับเด็กจบใหม่ ไม่กี่ปีต่อมา คนที่เคยเป็นอินเทิร์นบางคนได้เป็นวิศวกรระดับกลาง และทำงานได้ดีกว่าคนที่บริษัทรับเข้ามาเป็นซีเนียร์ตั้งแต่แรก Trindade สรุปว่า การใช้ AI เป็นเหตุผลไม่รับจูเนียร์ก็คือความคิดเดิมที่ผิดอยู่แล้ว เพียงเปลี่ยนมาใช้เหตุผลใหม่
ข้อแรก ทีมเล็กลงได้ แต่ยังไงก็ต้องหาคนมาเติม
วันหนึ่งวิศวกรที่เก่งจะออกไปทำโจทย์ที่ใหญ่กว่า เรื่องนี้เกิดขึ้นไม่ว่าจะมี AI หรือไม่ เอเจนต์อาจช่วยให้ทีมใช้คนน้อยลงได้ แต่ทีมก็ยังต้องมีคนทำงาน เพราะฉะนั้น สักวันบริษัทก็ต้องหาคนมาแทนคนที่ออกไป
เมื่อถึงตอนนั้น บริษัทมีสองทางเลือก ทางแรกคือรับคนจากตลาดแรงงาน ซึ่งต้องเสียค่าใช้จ่ายในการหาคน คนใหม่ยังต้องใช้เวลาราวหกเดือนเพื่อทำความเข้าใจระบบของบริษัท ทางที่สองคือเลื่อนตำแหน่งคนที่รู้จักระบบอยู่แล้ว บริษัทจะเลือกทางที่สองได้ก็ต่อเมื่อมีคนในทีมที่พร้อมพัฒนาขึ้นมารับตำแหน่งนั้น
ข้อสอง ถ้าวงการเปลี่ยนเร็วจริง ประสบการณ์คือของที่เสื่อมค่าเร็ว
ข้ออ้างข้อที่สองคือ วงการนี้เปลี่ยนเร็วมากจนไม่คุ้มที่จะพัฒนาคนที่ยังไม่มีประสบการณ์ Trindade ตอบด้วยประสบการณ์ของตัวเองตอนเริ่มทำงานเป็นที่ปรึกษา ทีมของเขาเรียกเก็บค่าบริการจากลูกค้าในอัตราที่แพงมาก แต่ต้องใช้เวลาสัปดาห์แรกของโปรเจกต์เพื่อตั้ง repo สำหรับเก็บโค้ดและทำให้ CI รันได้ บางโปรเจกต์ต้องรอเครื่องอีกเป็นสัปดาห์จึงจะเริ่มงานได้
ปัจจุบัน งานเดียวกันทำเสร็จได้ด้วยคำสั่งเดียวและใช้เวลารออีกราวสิบนาที ทักษะการตั้งระบบเก็บโค้ดอย่าง Subversion ที่เขาเคยใช้ไม่มีประโยชน์กับงานในปัจจุบันแล้ว แต่เขายังทำงานในสายนี้อยู่ เขาสรุปเรื่องนี้ไว้ว่า
ถ้าวงการเปลี่ยนเร็วขนาดนั้นจริง ประสบการณ์ก็มีมูลค่าลดลง คนที่คิดว่าจูเนียร์ปรับตัวไม่ทันกลับมีความรู้เก่าที่ต้องเลิกใช้มากกว่าคนอื่น
ดังนั้น เหตุผลเรื่องการเปลี่ยนแปลงอย่างรวดเร็วจึงใช้สนับสนุนข้ออ้างนี้ไม่ได้ ถ้าความรู้หมดประโยชน์เร็ว คนที่มีความรู้เก่าสะสมไว้มากกว่าก็ต้องเลิกใช้ความรู้เหล่านั้นมากกว่า
ข้อสาม ถ้าเอเจนต์เขียนโค้ดแทน จูเนียร์เหลืออะไรให้ทำ
ข้ออ้างข้อสามเป็นความเชื่อที่คนยึดถือมากกว่าสองข้อแรก ถ้าวิศวกรมีหน้าที่สั่งงานและตรวจงานเอเจนต์ คนที่เพิ่งเริ่มทำงานจะเหลืองานอะไรให้ทำ Trindade บอกว่าความคิดนี้มองว่างานของวิศวกรมีเพียงการส่งโค้ด ทั้งที่งานจริงทั้งก่อนและหลังมี AI คือการสร้างซอฟต์แวร์ที่มีประโยชน์ต่อลูกค้า ปัจจุบันต่างจากเดิมเพียงตรงที่เอเจนต์เป็นผู้เขียนโค้ด
คนยังต้องตัดสินใจเรื่องต่างๆ ตอนนี้วิศวกรยังตัดสินใจเรื่องเทคนิคเป็นหลัก หากวันหนึ่งต้องตัดสินใจเรื่องเทคนิคน้อยลง วิศวกรก็ต้องตัดสินใจแทนว่าสิ่งใดมีประโยชน์ เช่น ต้องดูว่าสิ่งที่สร้างขึ้นแก้ปัญหาให้ลูกค้าได้จริงหรือไม่ นอกจากนี้ยังต้องดูว่าสิ่งนั้นทำงานร่วมกับฟีเจอร์ที่มีอยู่ในโปรดักต์ได้หรือไม่
ถ้ามองงานวิศวกรแบบนี้ จูเนียร์ก็ยังมีงานทำ ซีเนียร์อาจคุมเอเจนต์หลายตัวและทำโปรเจกต์หนึ่งได้ด้วยตัวเอง ส่วนจูเนียร์ก็คุมเอเจนต์และทำโปรเจกต์ที่ง่ายกว่าได้ด้วยตัวเอง
ปัญหาที่ซ่อนอยู่คือวิธีส่งงานต่อกันในทีม

บทความนี้ไม่ได้แค่ปลอบใจจูเนียร์ แต่บอกว่าปัญหาอยู่ที่วิธีทำงานของทีม ทีมที่ไม่รู้ว่าจะให้คนอายุงานน้อยทำอะไร มักใช้กระบวนการทำงานที่วงการประกาศเลิกใช้ไปตั้งแต่สิบกว่าปีก่อน กระบวนการนี้เริ่มจาก product manager คิดโจทย์คนเดียว แล้วส่งให้ดีไซเนอร์ทำงานต่อคนเดียว จากนั้นหัวหน้าเทคจะแบ่งงานเป็นทาสก์ย่อย สุดท้าย คนที่มีอายุงานน้อยกว่าคนอื่นในทีมจะได้รับทาสก์ย่อยเหล่านั้น
เมื่อทีมทำงานแบบนี้ การให้เอเจนต์ทำขั้นตอนสุดท้ายแทนคนก็ดูสมเหตุสมผล แต่สิ่งที่ต้องแก้คือกระบวนการทำงาน ไม่ใช่คนที่รับงานในขั้นตอนสุดท้าย
ตัวอย่างต่อไปนี้แสดงวิธีมอบงานที่ต่างกันสองแบบ
| แบบที่หั่นมาให้แล้ว | แบบที่มอบเป็นผลลัพธ์ของลูกค้า |
|---|---|
| เพิ่ม endpoint สำหรับส่งออกไฟล์ CSV | ทำให้ลูกค้าส่งออกประวัติการเรียกเก็บเงินของตัวเองได้ |
งานแบบที่มอบเป็นผลลัพธ์ของลูกค้ายังมีคำถามหลายข้อให้คนทำงานตัดสินใจ
- ไฟล์ที่ลูกค้าส่งออกควรมีข้อมูลอะไรบ้าง
- ลูกค้าควรรอนานแค่ไหน จึงจะถือว่าระบบดึงข้อมูลย้อนหลังสิบปีได้เร็วพอ
- ฟีเจอร์นี้ควรทำงานร่วมกับฟีเจอร์ส่งออกอื่นที่มีอยู่แล้วในโปรดักต์อย่างไร
เมื่อมอบงานแบบหลัง คนทำงานจะได้ตัดสินใจด้วยตัวเอง ไม่ได้มีหน้าที่เพียงเขียนโค้ดตามทาสก์ย่อยที่คนอื่นเตรียมไว้
ถ้าวิศวกรทั้งทีมได้ทำเฉพาะทาสก์เชิงเทคนิค องค์กรก็ต้องแก้ประสิทธิผลของการทำงาน ไม่ใช่แก้เรื่องจูเนียร์กับ AI สุดท้าย คนเพียงไม่กี่คนจะต้องจัดการเรื่องซับซ้อนทั้งหมดและทำให้งานส่วนอื่นต้องรอ ในเวลาเดียวกัน คู่แข่งอาจให้ทุกคนในทีมสร้างสิ่งที่มีประโยชน์ต่อลูกค้าได้โดยตรง
อีกด้านของเรื่องเดียวกัน คนที่วิ่งไปก่อนกับคนที่รอทางที่ปูไว้
บทความของ Stack Overflow Blog เริ่มด้วยปัญหาที่พบในองค์กร บางองค์กรมีวิศวกรหนึ่งหรือสองคนเริ่มใช้ coding agent ก่อนคนอื่น และทำงานได้มากกว่าคนอื่นมาก เมื่อผู้บริหารเห็นความแตกต่างนี้ ก็อยากรู้ว่าคนกลุ่มนั้นมีอะไรพิเศษ เพื่อหาวิธีทำให้ทุกคนในทีมทำแบบเดียวกัน บทความบอกว่าวิธีนี้ไม่ได้ช่วยให้ทั้งองค์กรใช้ AI ได้จริง และองค์กรยังใช้วิธีอื่นได้
Vivek Raghunathan รองประธานฝ่ายวิศวกรรมของ Snowflake อธิบายเรื่องนี้ใน Leaders of Code ซึ่งเป็นช่วงหนึ่งของ Stack Overflow Podcast เขาใช้คำว่า explorer และ exploiter จาก reinforcement learning มาอธิบาย จากประสบการณ์ของเขา พนักงานในองค์กรราว 5% เป็น explorer คนกลุ่มนี้อยากทดลองความสามารถของเครื่องมือเกินกว่างานที่ได้รับมอบหมาย และนำผลงานที่ทำเองมาให้คนอื่นดูโดยไม่มีใครขอ พนักงานอีกราว 95% เป็น exploiter คนกลุ่มนี้ไม่อยากค้นหาวิธีใช้เครื่องมือด้วยตัวเอง และอยากใช้วิธีที่คนอื่นเตรียมไว้ให้แล้ว
เขาย้ำว่าคำว่า exploiter ไม่ใช่คำด่า คำนี้อธิบายความชอบแบบหนึ่งที่มีอยู่จริงและเป็นประโยชน์ต่อองค์กร
ความผิดพลาดคือการคิดว่า explorer กับ exploiter เป็นคนสองกลุ่มที่เปลี่ยนแปลงไม่ได้ ที่จริงแล้ว แต่ละคนชอบทดลองด้วยตัวเองไม่เท่ากัน และความชอบนี้เปลี่ยนได้ ผู้นำจึงควรช่วยให้คนส่วนใหญ่กล้าทดลองมากขึ้น ไม่ใช่แบ่งว่าใครพิเศษหรือไม่พิเศษ และไม่ใช่รับคนที่ชอบทดลองจากบริษัทอื่นเข้ามาแทน
ทางลัดสี่ทางที่ใช้ไม่ได้

วิธีแรกที่ใช้ไม่ได้คือพยายามดูตั้งแต่ต้นว่าใครจะเป็น explorer เพราะ Raghunathan บอกว่าไม่มีทางดูออก คนที่โพสต์ว่าตัวเองทำงานได้เร็วขึ้นเป็นร้อยเท่า ไม่ได้มีอายุงานมากกว่าหรือมีชื่อเสียงมากกว่าคนอื่นก่อนจะมีเอเจนต์ AI ทำให้ความอยากรู้ ความยืดหยุ่น และความเต็มใจที่จะเรียนรู้สิ่งใหม่ของคนเหล่านี้เห็นชัดขึ้น
วิธีที่สองคือออกแบบระบบสำหรับคนที่เป็น exploiter เท่านั้น วิธีนี้ช่วยให้ทั้งทีมทำงานพื้นฐานได้ดีขึ้นจริง แต่จะไม่มีใครทดลองว่าเครื่องมือเหล่านี้ทำอะไรได้มากกว่านั้น องค์กรจึงไม่รู้ว่าเครื่องมือช่วยทำงานได้มากที่สุดแค่ไหน
วิธีที่สามคือออกแบบระบบสำหรับคนที่เป็น explorer เท่านั้น วิธีนี้ใช้กับคนทั้งองค์กรไม่ได้ เพราะพนักงานอีกราว 95% ยังทำงานแบบเดิมและเร็วขึ้นเพียงเล็กน้อย ตัวอย่างผลงานเด่นเพียงสองสามชิ้นจึงไม่ทำให้ผลงานรวมขององค์กรดีขึ้น
วิธีสุดท้ายคือคิดว่าเรื่องนี้เป็นปัญหาการรับคน แล้วไปรับคนที่อยู่ในกลุ่ม 5% เพิ่ม Raghunathan บอกว่า การประเมินคนนอกบริษัทไม่ได้แม่นยำกว่าการประเมินพนักงานที่มีอยู่ สิ่งที่องค์กรทำได้จริงคือช่วยให้พนักงานปัจจุบันกล้าทดลองมากขึ้น
สิ่งที่ต้องจัดการจริงๆ
Raghunathan บอกว่า ขั้นแรกองค์กรควรเปิดโอกาสให้คนที่อยากทดลองเสนอตัว แล้วรับฟังคนเหล่านั้นอย่างจริงจัง คนกลุ่มนี้หาได้ไม่ยาก เพราะพวกเขาจะเข้ามาหาเองโดยไม่มีใครเรียก พร้อมยืนยันว่าเรื่องที่ทำอยู่เร่งด่วน และอยากให้คนอื่นดูผลงานที่ทำเสร็จแล้ว
ขั้นต่อมาคือนำสิ่งที่คนกลุ่มนี้ค้นพบมาจัดให้เป็นความรู้ที่สอนต่อได้ ไม่ใช่แค่ชมผลงานแล้วจบ องค์กรต้องจัดเวลาเรียนรู้อย่างจริงจัง จัดให้คนที่ใช้เครื่องมือเหล่านี้ได้พูดคุยกัน และให้สอนงานกันแบบตัวต่อตัว เพราะการนั่งทำงานใกล้กันไม่ได้ทำให้คนเรียนรู้เรื่องเหล่านี้เอง
จากนั้นให้วัดว่าคนทั้งทีมเปลี่ยนแปลงไปมากน้อยเพียงใด เช่น ไตรมาสนี้มีกี่คนที่กล้าทดลองมากขึ้นจริงๆ และมีกี่คนที่ยังทำงานเหมือนเมื่อหกเดือนก่อน ไม่ควรวัดด้วยจำนวนคนที่ทำงานเก่งเป็นพิเศษเพียงไม่กี่คน บทความสรุปว่า ผู้นำต้องสร้างระบบเพื่อหาคนที่พร้อมทดลองได้เรื่อยๆ ผู้นำยังต้องเปลี่ยนสิ่งที่คนเหล่านั้นค้นพบให้เป็นความรู้ที่สอนต่อกันได้ และช่วยให้พนักงานทั้งองค์กรพัฒนาขึ้น แทนที่จะปล่อยให้เรื่องเดิมเกิดขึ้นเองอีกครั้ง
แล้วเรื่องนี้ทำอะไรได้บ้าง
คนที่เพิ่งเริ่มทำงานและเด็กจบใหม่
- ควรแสดงให้เห็นว่าตัวเองตัดสินใจได้ว่าควรทำอะไรและทำไปเพราะอะไร ไม่ใช่แค่แสดงว่าเขียนโค้ดได้
- ฝึกรับงานที่ระบุผลลัพธ์ซึ่งลูกค้าจะได้รับ แล้วคุมเอเจนต์จนทำงานนั้นเสร็จได้ด้วยตัวเอง
- AI ช่วยให้ความอยากรู้และความเต็มใจที่จะเรียนรู้สิ่งใหม่ส่งผลต่องานมากขึ้น
หัวหน้าทีมและเจ้าของธุรกิจ
- ตรวจดูว่างานที่มอบให้ทีมเป็นทาสก์เชิงเทคนิคที่แบ่งไว้แล้ว หรือเป็นงานที่ระบุผลลัพธ์ซึ่งลูกค้าจะได้รับ
- จัดเวลาให้ทีมเรียนรู้อย่างจริงจัง อย่าคิดว่าคนในทีมจะเรียนรู้จากกันเองโดยไม่ต้องจัดการอะไร
- อย่าวัดความสำเร็จของการใช้ AI ในทีมจากคนที่ทำงานเก่งเพียงสองสามคน
ดังนั้น เวลาเข้าประชุมควรเลิกถามว่ายังรับจูเนียร์อยู่ไหม แล้วถามว่าทีมนี้มอบงานให้กันแบบไหน
ที่มา:
- บทความ The Kids Are Alright จาก Francisco Trindade
- บทความ Explorers, exploiters, and the myth of the 100x engineer จาก Stack Overflow Blog
ชอบเรื่องแนวนี้ มีอีบุ๊คฟรีให้อ่านต่อ
Vibe Coding สำหรับคนไม่ใช่โปรแกรมเมอร์ ใช้ Claude Code สร้าง landing page, mini app และ prototype จริงโดยไม่ต้องเขียนโค้ด
กดสมัครแล้วเราจะส่งเทคนิค AI และของแจกใหม่ๆ ให้ทางอีเมล เลิกรับได้ตลอด
Claude Cowork · The Business Playbook

ฉบับภาษาไทย 15 บท เรียนรู้ผ่านโปรเจกต์จำลองต่อเนื่องทั้งเล่ม ตั้งแต่ตั้งค่า Workspace จัดการไฟล์ เชื่อมแอป ตั้งระบบอัตโนมัติ จนถึงสร้าง Plugin


