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

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

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

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

โค้ดตรวจถูกผิดได้ แล้วสถาปัตยกรรมตรวจยังไง

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

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

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

อีกคอมเมนต์หนึ่งมองลึกไปกว่านั้น โดยบอกว่าบางครั้งสิ่งที่ตำราบอกว่าเป็นสถาปัตยกรรมที่แย่ อาจเป็นคำตอบที่ถูกต้องที่สุดสำหรับสถานการณ์นั้นก็ได้ เขายกตัวอย่างเกม DOOM ของ John Carmack ว่าถ้าทำตาม best practice ในยุคนั้น โลกนี้ก็คงไม่มีเกม DOOM เกิดขึ้นมา เขามองว่า AI เก่งเรื่องเสนอทางแก้ตามตำราแบบระบบองค์กรใหญ่ แต่ในวันที่ต้นทุนการเขียนโค้ดถูกลงเรื่อยๆ ทางแก้ที่เรียบง่ายและมนุษย์อ่านเข้าใจได้ทันที จะยิ่งมีคุณค่าสูงขึ้น

วิศวกรระบบอีกคนที่มีประสบการณ์ดูแลระบบ production ขนาดใหญ่ เล่าว่าเขาเคยลองใช้โมเดล Fable ร่วมกับ Astra ช่วยกันสร้างวิดีโอเกม แต่สุดท้ายก็ไม่สำเร็จ แม้ AI Agent จะเขียนโค้ดให้ได้ครบทุกอย่าง เขียนสคริปต์ดักข้อผิดพลาดพื้นฐานได้ หรือแม้กระทั่ง "เปิดเกมขึ้นมาลองเล่นเอง" ผ่าน emulator เพื่อจับภาพหน้าจอมาเช็กผลงานตัวเองได้ แต่เขากลับมองว่าไม่มีทางเทรน AI ด้วย RL ให้รู้ได้เลยว่า "ต้องสร้างเกมแบบไหนถึงจะสนุก" เพราะความสนุกเป็นประสบการณ์ของมนุษย์ที่ไม่ได้เป็นไปตามตรรกะตายตัว

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

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

องค์กรที่สร้างระบบเองด้วย AI เริ่มเรียกคนมารีวิว

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

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

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

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

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

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

ทำให้คนตกลงกันได้ และกล้าค้านไอเดียแย่

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

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

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

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

จากคนเขียนโค้ด เป็นคนส่งซอฟต์แวร์

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

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

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

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

อีกฝั่งบอกตรงๆ ว่า dev จะน้อยลงทุกระดับ

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

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

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

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

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

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

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

dev ซีเนียร์ไทยเริ่มอะไรได้ตั้งแต่สัปดาห์นี้

ถ้าจะนำมุมมองจากกระทู้นี้มาปรับใช้กับการทำงานจริง นี่คือ 4 สิ่งที่คุณเริ่มทำได้ทันที

1. เปิดรับงานรีวิวและกู้ระบบที่สร้างด้วย AI: องค์กรที่แทบไม่มีความรู้ด้านพัฒนาซอฟต์แวร์แต่สร้างระบบใช้เอง คือกลุ่มที่คนรับงาน Fractional ในกระทู้บอกว่าติดต่อเข้ามามากขึ้นเรื่อยๆ สำหรับคนทำงานประจำในบริษัทใหญ่ แผนกอื่นข้างๆ คุณอาจกำลังเจอปัญหานี้อยู่ ลองเริ่มง่ายๆ ด้วยการถามดูว่า มีเครื่องมือภายในตัวไหนที่สร้างกันขึ้นมาเอง แล้วตอนนี้เริ่มติดปัญหาจนไม่มีใครกล้าเข้าไปแตะหรือแก้โค้ดบ้าง
2. ฝึกสร้างฉันทามติ และฝึกคัดค้านเป็นลายลักษณ์อักษร: ถ้าโมเดล AI ยังตามใจผู้ใช้จนไม่ค้านไอเดียที่ไม่เข้าท่าแรงพอ คนในทีมก็ต้องทำหน้าที่นี้เอง ครั้งหน้าถ้าคุณไม่เห็นด้วยกับแผนงาน ลองเขียนข้อคัดค้านสั้นๆ ลงในเอกสาร ระบุเหตุผลให้ชัดว่าไม่เห็นด้วยตรงไหน แล้วเสนอทางแก้ที่ดีกว่าไปด้วย
3. ให้ความสำคัญกับเรื่องประสิทธิภาพ การทดสอบ Observability และการย้ายระบบ: คอมเมนต์หนึ่งแนะนำให้เน้นเรื่องประสิทธิภาพ การทดสอบ และ Observability ส่วนอีกคอมเมนต์บอกว่าการออกแบบเทสต์สำหรับย้ายระบบยังต้องมีคนคุม ลองเลือกระบบที่คุณดูแลอยู่สักตัว แล้วถามตัวเองว่าถ้าพรุ่งนี้ระบบช้าลง คุณจะรู้ตัวจากอะไรก่อนที่ผู้ใช้งานจะเริ่มบ่น
4. เลือกทางออกที่เรียบง่าย เมื่อ AI เสนอวิธีซับซ้อนตามตำรา: ในวันที่ต้นทุนการเขียนโค้ดถูกลง ทางแก้ปัญหาที่คนอ่านเข้าใจได้ทันทีจะยิ่งมีคุณค่าสูง ตามที่คอมเมนต์เรื่องเกม DOOM มองไว้ ก่อนจะเลือกรับแผนโครงสร้างระบบที่ซับซ้อนหลายชั้น ให้ลองตั้งคำถามกลับไปเสมอว่า ทางออกที่เรียบง่ายที่สุดและยังตอบโจทย์การใช้งานได้จริงคืออะไร

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

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

---

ที่มา: บทความ Ask HN: What is the current trajectory of a senior engineer? จาก Hacker News