LLM กำลังกัดกินอาชีพวิศวกรรมซอฟต์แวร์ของฉัน และฉันไม่รู้ว่าควรทำอย่างไร
(human-in-the-loop.bearblog.dev)- เครื่องมือพัฒนาที่ขับเคลื่อนด้วย LLM เข้ามามีส่วนร่วมตั้งแต่การเขียนเอกสารออกแบบ วางแผนการพัฒนา เขียนโค้ด ไปจนถึงดีบัก ทำให้ความเชี่ยวชาญเฉพาะทางด้านแบ็กเอนด์การชำระเงินและการเงินที่สั่งสมมา 10 ปีมีความแตกต่างลดลง
- ในสายการเงินและการชำระเงิน ความรู้โดเมน เคยเป็นความได้เปรียบจากประสบการณ์เรื่อง PCI compliance, double-entry ledgers, escrows, reconciliation, payment lifecycles และ bank transfer idempotency แต่เมื่อโมเดลเริ่มมองเห็นจุดเชื่อมของโครงสร้างระบบได้ ก็เกิดแรงกระแทกครั้งแรก
- เมื่อมี Claude Code, Codex, MCP และ DataDog MCP การทำ ดีบักอัตโนมัติ ก็ขยายตัวขึ้น โดยสามารถแก้บั๊กบางส่วนได้จากเพียง stack trace และบริบทจาก Sentry และต่อมาก็จัดการบั๊กในระบบกระจายได้ 90% แบบจบในครั้งเดียว
- เสาหลักที่เหลืออย่าง คุณภาพโค้ด และสถาปัตยกรรมก็ถูกย่อลงเหลือแค่คำว่า “taste” และกำลังไปสู่กระแสที่ยอมรับ codebase ระดับ
C·Dที่ LLM จัดการได้ แทน codebase ระดับA·Bที่มนุษย์อ่านง่าย - หากต้องการรักษาความสามารถในการจ้างงานระยะยาว ก็ต้องย้ายความเชี่ยวชาญไปยังพื้นที่ที่ LLM ยังทำได้ไม่ง่ายหรือไม่ดีนัก แต่การ เปลี่ยนไปทำสายวิจัย ก็ถูกจำกัดด้วยประเทศที่อยู่อาศัย การแข่งขันในการสมัคร ภาระครอบครัว และความเป็นไปได้ของ RSI
พื้นหลังอาชีพ
- เป็นวิศวกรซอฟต์แวร์มืออาชีพมา 10 ปี เริ่มจากเว็บฟรอนต์เอนด์เพราะดีบักง่ายกว่า แต่ภายหลังก็ย้ายมาสาย แบ็กเอนด์
- ได้เข้าไปทำงานพัฒนาซอฟต์แวร์ด้านการเงิน การทำบัญชี (bookkeeping) และการประมวลผลการชำระเงินโดยบังเอิญ และได้สัมผัส ความเป็นอิสระ สูงจากความสัมพันธ์ที่ใกล้ชิดและตรงไปตรงมากับ Product Manager และผู้มีส่วนได้ส่วนเสีย
- สั่งสมความรู้โดเมน เช่น PCI compliance, double-entry ledgers, escrows, reconciliation, payment lifecycles และ bank transfer idempotency
- กลยุทธ์อาชีพในการเป็นผู้เชี่ยวชาญโดเมน เป็นการตัดสินใจที่ชัดเจนเพื่อสร้างความแตกต่างด้วยความเชี่ยวชาญในสาขาที่เริ่มมีสัญญาณว่าความต้องการผู้เชี่ยวชาญโดเมนกำลังเพิ่มขึ้น
เสาแรกที่เริ่มพังทลาย: ความรู้เฉพาะโดเมน
- ปีที่แล้วได้ย้ายไปทำงานที่บริษัทสายการเงิน โดยก่อนหน้านี้แม้บริษัทเก่าจะมีองค์ประกอบด้านการชำระเงินและการเงินสูง แต่ก็ไม่ได้โฟกัสเฉพาะการเงินล้วน ๆ
- บริษัทใหม่ เปิดรับ AI เต็มรูปแบบ และให้บัญชี ChatGPT กับ Claude Enterprise ตั้งแต่วันแรก พร้อมสนับสนุนให้ใช้ AI ในการค้นคว้า สำรวจ และเขียนโค้ด
- แต่มีเงื่อนไขว่า โค้ดทุกบรรทัดที่จะขึ้นโปรดักชันต้องตรวจสอบเองและรับผิดชอบเองทั้งหมด
- โปรเจกต์แรกคือการรื้อทำระบบชำระเงินออนไลน์แบบเลกาซีที่เละเทะ ซึ่งได้รับมอบหมายเพราะเคยมีประสบการณ์สร้างระบบแบบนี้มาก่อน
- Design Docs ที่ต้องเขียนก่อนลงมือเขียนโค้ด จำเป็นต้องให้ทั้งวิศวกรและ Product Manager อ่านเข้าใจได้ และเป็นเอกสารที่ต้องใช้มุมมองเชิงสถาปัตยกรรมมากกว่าการเจาะลึกทางเทคนิค
- Design Docs ฉบับแรกเขียนโดยใช้ AI ช่วยเพียงเล็กน้อย ตอนนั้นยังมอง LLM ว่าเป็น “stochastic parrots” แต่ตอนนี้ไม่ได้ยึดมุมมองนั้นแล้ว
- ฟีดแบ็กจากผู้จัดการคือ แม้จะส่งโค้ดได้เร็วดี แต่ใช้เวลาทำ Design Docs นานเกินไป และควรใช้ AI ให้มากขึ้น
- ตอนนั้นโมเดลยังไม่เก่งเท่าปัจจุบัน แต่ก็มีประสิทธิภาพพอจะเร่งความเร็วในการเขียนและการตัดสินใจ
- นั่นคือช่วงเวลาที่คุณค่าของความรู้ที่สั่งสมมาหลายปีเกี่ยวกับ trade-off ในการพัฒนา วิธีการทำงานของ acquiring และการออกแบบ idempotency เพื่อป้องกันการเรียกเก็บเงินซ้ำ เริ่มลดลง
- โมเดลยังต้องอาศัยการปรับจูนอยู่มาก แต่ก็สามารถจับจุดเชื่อมว่าโครงสร้างระบบควรจัดอย่างไรได้ ซึ่งนี่คือส่วนที่ยากที่สุดและปกติต้องอาศัยประสบการณ์ทำงานหลายปีถึงจะก่อรูปขึ้นในหัวได้
- มีทั้งบทความอธิบายบนเว็บ เอกสารเทคนิค และบล็อกโพสต์จำนวนมากเกี่ยวกับการนำเครื่องมือทางเทคนิคไปใช้กับโดเมน ทำให้ประเมินได้ว่าโมเดลสามารถดูดซับสิ่งเหล่านี้เข้าไปเป็นข้อมูลฝึกได้
- ยังเคยคาดหวังว่าพื้นที่ที่มนุษย์จะยังโดดเด่นกว่าคือการดีบัก และประสบการณ์กับ race condition ในระบบโปรดักชันรวมถึงการดีบักระบบกระจาย จะเป็นฐานของความสามารถในการจ้างงานระยะยาว
เสาที่สองที่เริ่มพังทลาย: การดีบักและระบบกระจาย
- หลังจาก LLM เก่งขึ้นทั้งการเขียนเอกสารและช่วยวางแผนการพัฒนา มันก็เก่งการเขียนโค้ดด้วย และกระแสยิ่งขยายหลัง Claude Code กลายเป็นที่ฮือฮาในครึ่งหลังของปี 2025 และการมาถึงของ Codex
- ก่อนหน้านั้นก็ใช้ LLM เขียน unit test อยู่ทุกวัน แต่ยังไม่ไว้ใจพอจะมอบหมายการพัฒนาทั้งหมดให้ทำ
- กระบวนการนำ AI มาใช้ในการเขียนโค้ดมากขึ้นเป็นก้าวถัดไปที่เป็นธรรมชาติ และเพราะชอบทั้งการเขียนโค้ด การขึ้นโปรดักชัน และการทำให้ผู้ใช้พึงพอใจพอ ๆ กัน จึงเป็นการแลกเปลี่ยนที่ยอมรับได้
- แม้ LLM จะเก่งขึ้นมากในการเขียนโค้ด แต่ก่อนหน้านี้มันยังดีบักความยุ่งเหยิงที่โมเดลเองหรือมนุษย์สร้างไว้ไม่ได้ จึงยังมีบทบาทมากกว่าการคอยจูนหุ่นยนต์
- แต่หลังการมาของ MCP, เวิร์กโฟลว์แบบเอเจนต์ และ Claude 4.5 เสาหลักด้านการดีบักก็เริ่มสั่นคลอน
- Claude 4.5 แก้บั๊กได้ราว 60% จากเพียง stack trace และบริบทเล็กน้อย และในหลายกรณีแค่ลิงก์ Sentry ที่เปิด Sentry MCP ไว้ก็เพียงพอ
- บางครั้งก็สร้างวิธีแก้ที่ฟังดูสมเหตุสมผลแต่ผิดทั้งหมด
- ณ จุดนี้ก็เลิกสงสัยในเครื่องจักรไปแล้ว และได้เห็น Claude Code แก้บั๊กที่เมื่อก่อนอาจต้องใช้เวลาทั้งวันในการไล่ได้จบในครั้งเดียว
- ต่อจากนั้น เมื่อมี 4.6, 4.7, GPT 5.5, Opus 4.8 และ DataDog MCP ก็กลายเป็นสภาพที่ CLI สามารถแก้บั๊กในระบบกระจายได้แบบ one-shot
- ครอบคลุมทั้งบั๊กที่เมื่อก่อนแก้ไม่ได้ บั๊กที่ต้องใช้เวลาสองวันเต็มในการดีบัก และบั๊กในระบบกระจายที่มี observability ไม่เพียงพอ
- ไม่ว่าจะเป็น race condition แปลก ๆ corner case ที่คาดไม่ถึง ปัญหาจาก third-party integration หรือ edge case ของ API ที่ไม่มีเอกสาร ก็แก้ได้ 90% แบบจบในครั้งเดียว
- ยังคงต้องมีคนคอยรีวิวโค้ดและจูนหุ่นยนต์อยู่ จึงยังมีงานทำ แต่ก็กลายเป็นวิศวกรแบบสินค้าสำเร็จรูปไปแล้ว
- ความเชี่ยวชาญโดเมนด้านการเงินและการชำระเงิน สัญชาตญาณในการดีบัก และความรู้เรื่องระบบกระจาย เปลี่ยนสภาพเป็นความรู้ที่วิศวกรซีเนียร์คนอื่นสามารถใส่เป็นพรอมป์ต์ให้ LLM ปรับจูนตามได้
- ต่างจากสิ่งที่เคยสอนกันมาว่าทั้งสาย generalist และ specialist ต่างก็มีบทบาท ตอนนี้ตลาดกำลังมุ่งไปสู่การทำให้ทุกคนเป็น generalist
- ถ้าทุกคนกลายเป็น generalist และความต้องการไม่เพิ่มตาม ราคาของ generalist ก็จะลดลง และในตอนนี้ความต้องการก็กำลังลดลงด้วย
เสาที่สามที่ยังไม่พัง: คุณภาพโค้ดและสถาปัตยกรรม
- เสาที่เหลืออยู่ตอนนี้คือคุณภาพโค้ดและสถาปัตยกรรมซอฟต์แวร์ ซึ่งปัจจุบันถูกย่อเหลือเพียงคำว่า “taste”
- ตลอดอาชีพที่ผ่านมา ชอบการรีแฟกเตอร์ ให้ความสำคัญกับโค้ดที่ดี และเคยต่อรองเวลาในสปรินต์เพื่อทำสิ่งเหล่านี้มาโดยตลอด
- เป็นเส้นทางอาชีพที่ชอบถกเรื่อง trade-off และโครงสร้าง codebase ในหัวข้ออย่าง DDD, Hexagonal และ Clean Architecture
- เอเจนต์เป็นเครื่องมือที่อ่อนแอมากในการดูแลให้ codebase อยู่ในสภาพเป็นระเบียบ
- หากไม่คอยจูน ปัญหา circular dependency จะเกิดขึ้นอย่างรวดเร็ว
- เพิ่มโค้ดซ้ำ ใส่คอมเมนต์ที่ไม่จำเป็น ปะปน pure function กับ side effect และมองข้ามหลักการ SOLID
- ความสามารถนี้ควรเป็นพื้นที่ที่ช่วยรักษาความสามารถในการจ้างงานของมนุษย์ แต่ทั้งอุตสาหกรรมกลับลดทอนมันเหลือคำว่า “taste” และกำลังย้ายไปสู่โลกที่ความสำคัญของการจัดระเบียบโค้ดลดลง
- มนุษย์ยังคงมีบทบาทในการจูนเอเจนต์เพื่อป้องกันไม่ให้ codebase กลายเป็นสปาเกตตีที่เต็มไปด้วยกราฟ circular dependency
- ถึงจะไม่อยากได้ codebase ระดับ
Fที่แตะอะไรแล้วพัง แต่ระดับCหรือDตอนนี้กลับกลายเป็นสิ่งที่ยอมรับได้ - เหตุผลที่ไม่ต้องการ codebase ระดับ
AหรือBอีกต่อไป คือ codebase กำลังถูกสร้างขึ้นมาเพื่อให้ LLM จัดการ มากกว่าจะให้มนุษย์อ่าน - หากซอร์สโค้ดในตอนนี้ถูกเขียนขึ้นเพื่อให้เครื่องอ่านแทนที่จะเป็นมนุษย์ ก็กลายเป็นสถานการณ์ที่เลือกพุ่งเป้าไปที่เครื่องได้เช่นกัน
- ความรู้ด้านคุณภาพโค้ดและสถาปัตยกรรมก็กำลังสูญเสียคุณค่าเช่นกัน และเวลาที่ทุ่มให้กับการอ่านหนังสือ ฝึกปฏิบัติจริง ถกเถียงกับวิศวกรคนอื่น และเขียน ADR ก็กำลังกลายเป็นสิ่งไร้ประโยชน์
แล้วตอนนี้ควรทำอย่างไร
- ในช่วงนี้ยังมองว่าอย่างน้อยก็ยังรักษางานไว้ได้ (อย่างน้อยก็ในบริษัทปัจจุบัน) แต่ ภาพระยะยาว ยังไม่แน่นอน
- ในระยะยาว สิ่งที่ใช้เวลาเรียนรู้มา 10 ปี หรือมากกว่านั้นหากนับประสบการณ์ก่อนเป็นมืออาชีพ กำลังมีมูลค่าลดลงเรื่อย ๆ
- แม้แต่เสาหลักสุดท้ายของความเชี่ยวชาญก็ถูกย่อเหลือเพียง “taste”
- ราว 8 เดือนก่อน บริษัทปัจจุบันมี การปลดพนักงาน (ซึ่งตามคำอธิบายของบริษัทไม่ได้เกี่ยวกับ AI) และอดีตเพื่อนร่วมงานที่เก่งมากหลายคนซึ่งถูกเลย์ออฟก็ยังหางานอยู่จนถึงตอนนี้
- หลายคนในกลุ่มนี้กำลังเจอปัญหาเดียวกัน คือความเชี่ยวชาญเฉพาะโดเมนอย่างเดียวไม่สามารถสร้างความแตกต่างได้อีกต่อไป
- ตอนนี้บริษัทกลับมาเปิดรับบางตำแหน่งอีกครั้ง แต่ความคุ้นเคยกับโดเมนไม่ได้เป็นจุดสร้างความต่างที่แข็งแรงอีกแล้ว
- เมื่อก่อนตำแหน่งงานจะประกาศในรูปแบบ “Software Engineer - Area” แต่ตอนนี้ใช้เพียง “Software Engineer” และค่อยจัดทีมหลังผู้สมัครตอบรับข้อเสนอแล้ว
- นี่คือการเปลี่ยนแปลงที่สร้างโอกาสการจ้างงานที่ดีกว่าให้กับ วิศวกรที่เก่งแต่ไม่เคยมีโอกาสสั่งสมประสบการณ์โดเมนเชิงลึก
- และก็เป็นการเปลี่ยนแปลงที่ทำให้แม้แต่วิศวกรเก่ง ๆ ที่สะสมความรู้โดเมนมาตลอดชีวิต ก็ต้องมา แข่งขันอยู่ในเลนเดียวกัน
- ทางเลือกเดียวในการรักษาความสามารถในการจ้างงานระยะยาวคือ ย้ายความเชี่ยวชาญโดเมนไปยังพื้นที่ที่ LLM ยังทำได้ไม่ง่ายหรือไม่เก่งนัก
- จึงกำลังคิดถึงทางเลือกอย่างการกลับไปเรียนมหาวิทยาลัยเพื่อเรียนคณิตศาสตร์ สถิติ และ Machine Learning ขั้นสูง แล้วสมัครงานวิจัยใน frontier lab
- ประเทศที่อาศัยอยู่ไม่มี frontier lab และสถาบันวิจัยจำนวนน้อยที่มีอยู่ก็มีผู้สมัครล้นหลาม
- ด้วยเหตุผลด้านครอบครัว จึงย้ายไปประเทศอื่นได้ยาก
- และกว่าจะย้ายได้จริง ก็ยังมีความเป็นไปได้ว่า RSI (recursive self-improvement) อาจทำให้นักวิจัยไม่จำเป็นอีกต่อไป
- ถ่ายทอดความอับจนหนทางถึงขั้นกำลังพิจารณาเปลี่ยนงานอดิเรกอย่างงานไม้ให้กลายเป็นอาชีพ
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
อะไรนะ? ผมสั่งงาน LLM ทั้งวันก็จริง แต่ไม่มีทางยอมเป็น ผู้รับผิดชอบผลิตภัณฑ์การเงิน เด็ดขาด
เสาหลักข้อแรกยังคงอยู่ ผู้เขียนอาจไม่รู้ขอบเขตอิทธิพลของตัวเอง แต่จากหลักฐานอย่าง PR ที่ถูกย้อนกลับ ผมรู้ว่าพอออกนอกขอบเขตที่ตัวเองรู้ลึก ผมก็แยกไม่ออกแล้วว่าเอเจนต์กำลังพล่ามมั่วหรือเปล่า แม้แต่เอเจนต์ระดับท็อปของเราที่มีสิทธิ์เข้าถึงระบบกระจายของผู้เขียนเองก็ยังผิดบ่อย มองภาพแคบ และทำเรื่องโง่ ๆ ซ้ำ ๆ สุดท้ายก็ต้องอาศัย ความเชี่ยวชาญ ของวิศวกรในทีมช่วยพากลับเข้าที่เข้าทาง
Mythos ตัดสินอย่างมั่นใจว่าโค้ดบางส่วนใน codebase ของเราละเมิดข้อบังคับบางอย่าง และบอกว่าถ้าเดินหน้าด้วยวิธีปัจจุบันจะมีความเสี่ยงร้ายแรง แต่ความจริงไม่ใช่แบบนั้น มันหลอนข้อกำหนดทางกฎหมายขึ้นมาเอง เรารู้ได้เพราะโค้ดนั้นผ่านการตรวจโดยที่ปรึกษากฎหมายซึ่งเป็นมนุษย์แล้ว เขาบอกว่านี่คือโมเดลล้ำหน้าที่สุดที่ใช้งานได้ในตอนนี้ ผมใช้ generative AI เยอะมากในการช่วยเขียนโค้ด แต่ต่อให้มองระยะกลาง เครื่องมือแบบนี้ก็ยังเอามาพึ่งพาเพื่อสร้าง ผลิตภัณฑ์การเงินที่ต้องปฏิบัติตามข้อกำกับ จริง ๆ ไม่ได้ นั่นบ้าชัด ๆ หลายบริษัท FinTech ใช้เอเจนต์เพื่อเร่งความเร็วก็จริง แต่ถ้าเอาไปใช้ปล่อยผลิตภัณฑ์โดยไม่มีมนุษย์ขุดตรวจจริงจัง ก็เท่ากับรับความเสี่ยงมหาศาล
ก่อนยุค LLM บริษัทส่วนใหญ่ยังมีที่ให้วิศวกรเก่งมากกับวิศวกรระดับธรรมดาทำงานร่วมกันได้ หลังยุค LLM จะเหลือรอดได้แค่วิศวกร “ระดับท็อป” เท่านั้น เพราะไม่ต้องการวิศวกรระดับธรรมดาอีกต่อไปแล้ว ด้วยธรรมชาติของ HN วิศวกรส่วนใหญ่ที่มาอ่านข้อความนี้คงคิดว่าตัวเองอยู่ในกลุ่มบนสุด 10–5% ของบริษัท/เมือง/ประเทศ และเลยคิดว่าตัวเองไม่ใช่วิศวกร “ระดับธรรมดา” ที่จะได้รับผลกระทบจากการนำ LLM มาใช้ แต่ในเชิงสถิติแล้ว น่าจะคิดผิด สุดท้ายมันคือเรื่องอีโก้ คุณน่าจะไม่ใช่ร็อกสตาร์ และสุดท้าย LLM ก็อาจมาแย่งงานคุณได้ ตามเคย ผู้ชนะมีแค่บริษัทกับผู้บริหาร ส่วนพวกเราส่วนใหญ่อยู่ปลายสุดของโซ่ ก็เลยต้องเป็นฝ่ายรับเคราะห์
ในกรณีของผม นักพัฒนาบางส่วนทำ vibe coding และไม่ได้เข้าใจทั้งข้อกำหนดหรือโค้ดของตัวเองอย่างลึกพอ เลยต้องวนแก้หลายรอบ จะบอกว่านี่เป็นปัญหาของมนุษย์ก็ได้ แต่ผลสุทธิที่ผมเห็นคือ กรณีซับซ้อนแบบนี้ สิ่งที่เคยเป็น “เวลาเขียน PR ค่อนข้างนาน + เวลารีวิวค่อนข้างนาน” กลายเป็น “เวลาเขียน PR สั้นมาก + เวลารีวิวยาวขึ้น” ผมไม่แน่ใจว่ามันได้ประโยชน์จริงหรือเปล่า บางครั้งถึงโค้ดจะถูกต้องในเชิงฟังก์ชัน แต่ก็เยิ่นเย้อเพราะมีฟังก์ชันกลางมากเกินไป และน่าจะส่งผลต่อการรีวิวครั้งต่อ ๆ ไป
ผมก็มีความกังวลแบบเดียวกัน แต่ก็มักถูกปัดตกหรือเลี่ยงตอบด้วยแนวว่า “ความเร็วในการส่งมอบและ ROI คุ้มค่าอยู่แล้ว ไม่ต้องกังวล”
โดยส่วนตัว บริษัท FinTech ทุกแห่งที่ผมเจอต่างก็มีอะไรทำนอง บัญชี AI สำหรับนักพัฒนามาตั้งแต่ปีที่แล้ว แม้แต่ที่อย่าง Jane Street ก็มีพนักงานเขียนบล็อกบอกว่าคนส่วนใหญ่ทำหน้าที่คุมเอเจนต์กันแล้ว คุณคิดว่าบริษัทของคุณจะต้านกระแสนี้ได้นานแค่ไหน?
ฉันเห็นคอมเมนต์แนวว่า “ตราบใดที่ AI ยังทำ X ได้ไม่แม่นยำ 80~100% อาชีพของเราก็ยังปลอดภัย” เยอะมาก
ไม่อยากให้ฟังดูมองโลกในแง่ร้ายเกินไป แต่โมเดลกำลังพัฒนาขึ้นอย่างรวดเร็ว ถ้าเมื่อราว 3 ปีก่อนมีใครอธิบายสภาพตอนนี้ว่า “โมเดลสามารถสร้างแอป MVP ทั้งตัวได้ภายในประมาณ 30 นาทีด้วยพรอมป์เดียว” มันคงฟังดูเหมือนนิยายวิทยาศาสตร์ อุปสรรคที่โมเดลกำลังเจออยู่ตอนนี้ เช่น การลดอัตราหลอน การรับประกันการปฏิบัติตามข้อกำหนด และการดูแลโค้ดเบสให้สะอาด ไม่ได้ดูเหมือนเป็นปัญหาที่จะแก้ไม่ได้ไปอีกไกล การดึงข้อมูลเฉพาะทางก็ทำได้บางส่วนแล้วผ่าน MCP server/RAG หลายตัว ฉันกังวลกับอนาคตของวิศวกรซอฟต์แวร์ ถ้าข้อบกพร่องเหล่านี้ถูกแก้ได้ อาชีพนี้จะไปอยู่ตรงไหน? กลายเป็นบทบาทที่คอยมอบหมายงานให้โมเดล AI งั้นหรือ? น่าเสียดายที่สิ่งนี้ไม่ได้ต้องใช้ความเชี่ยวชาญหลายปี จึงเป็นดาบสองคม ตรวจทานผลลัพธ์จาก AI งั้นหรือ? ก็แค่สั่งให้อธิบายแต่ละบรรทัดที่ไม่เข้าใจได้ เหมือนที่นักคำนวณมนุษย์ถูกแทนที่ด้วยคอมพิวเตอร์ดิจิทัล ฉันคิดว่าเราจะได้เห็น ระลอกการเลย์ออฟ ที่ใหญ่กว่านี้อีก การคำนวณคณิตศาสตร์ซับซ้อนในหัวอาจเป็นความท้าทายที่สนุก แต่ก็ช้ากว่าคอมพิวเตอร์มากและผิดพลาดได้มากกว่า เช่นเดียวกัน การเขียนโค้ดด้วยมืออาจถูกมองว่าเป็น “ความท้าทาย” ที่สนุก และ AI จะถูกมองเป็น เครื่องคิดเลขยุคใหม่
https://youtu.be/5eqRuVp65eY?si=3fLT6S5q2OIUcu6r
หลายอย่างจะยังคงดีขึ้นอย่างมากต่อไป แต่ถ้ามองประวัติศาสตร์ยุคใหม่ของความปั่นป่วนฉับพลันที่เทคโนโลยีก่อขึ้น จะเห็นรูปแบบที่เกิดซ้ำ เหมือนหิมะถล่มหรือน้ำป่าหลาก การเปลี่ยนแปลงฉับพลันแบบนี้มักเริ่มจากจุดทะลุสำคัญหนึ่งอย่างขึ้นไปในเทคโนโลยีใดเทคโนโลยีหนึ่ง ช่วงแรกความเร็วของการเปลี่ยนแปลงจะสูงและรุนแรง แต่จะค่อย ๆ ช้าลงเมื่อเก็บเกี่ยวผลไม้ที่อยู่ต่ำหมดแล้ว และเริ่มเจออุปสรรคกับแรงเสียดทานใหม่ ๆ ในพื้นที่ใหม่ ช่วงต้นของระยะนี้ การเอาอัตราการเปลี่ยนแปลงที่ผิดปกติในช่วงล่าสุดไปลากเส้นต่อในอนาคตมักทำนายได้ไม่ดี การพุ่งขึ้นอย่างสุดโต่งแบบฉับพลันมักมีแนวโน้มกลับเข้าสู่เส้นแนวโน้มระยะยาว ความปั่นป่วนจาก LLM ตอนนี้อาจมองได้ว่าเกิดจากงานวิจัยหลังปี 2010 ที่มาสะสมกันจนเกิด งานวิจัยทรานส์ฟอร์เมอร์ ในปี 2017 และกระตุ้นงานวิจัยรอบข้างอย่างรวดเร็ว ถ้าอย่างนั้น ตอนนี้เราอาจอยู่ช่วงกลางหรือช่วงปลายของเฟสการพุ่งขึ้นอย่างรุนแรงของ LLM ก็ได้ ความเร็วของการค้นพบที่เป็นรากฐานและกว้างขวางซึ่งยกระดับแอปพลิเคชัน LLM ทั้งหมดนั้นช้าลงอย่างชัดเจนแล้ว และการค้นพบสำคัญล่าสุดจำนวนมากอยู่ในด้านการขยายไปสู่โดเมนเฉพาะ การเพิ่มประสิทธิภาพ การจูน และการทำเป็นผลิตภัณฑ์ ไม่ได้หมายความว่าพรุ่งนี้จะไม่มีจุดทะลุระดับทรานส์ฟอร์เมอร์อีก แต่ในทางประวัติศาสตร์แล้ว หงส์ดำ ไม่ค่อยมาเป็นฝูง
ลูกค้าจะไม่ซื้อเครื่องมือซอฟต์แวร์เหมือนทุกวันนี้ แต่จะสร้างซอฟต์แวร์ที่ต้องการทั้งหมดขึ้นมาใช้ภายในเอง หรือให้ที่ปรึกษา prompt engineering สร้างให้ โลกอาจต่างไปมาก
หรือจะมีบริษัทผู้ก่อตั้งคนเดียวอยู่ทั่วโลกสัก 700 บริษัท แล้วที่เหลือทั้งหมดทำงานไม่ได้? จะกลายเป็น Matrix เหรอ?
ผลิตภาพไม่ได้เพิ่มขึ้นมากขนาดนั้นเลยนับตั้งแต่ Claude 3.5 ออกมา ฉันเข้าถึง LLM ทุกตัวได้แบบไม่จำกัด แต่ส่วนใหญ่ก็ห่วย และต้องเสียเวลาสร้างมากกว่าที่ประหยัดได้ คนที่ได้ประโยชน์จากเครื่องมือนี้คือพวกที่ปั๊ม งานคุณภาพต่ำ ออกมาได้เร็วเท่านั้น ถ้าคุณไม่เห็นด้วย คุณก็เป็นคนแบบนั้นเหมือนกัน
เส้นทางอาชีพของฉันคล้ายกับของผู้เขียนอย่างน่าประหลาดใจ ที่แปลกคือส่วนที่ผู้เขียนมองว่าเป็นเสาหลักต้นแรกที่พังทลาย ตอนนี้กลับดูแข็งแรงที่สุด
LLM ล้มเหลวซ้ำ ๆ กับความเฉพาะทางของธุรกิจเรา เช่น กฎหมายภาษีท้องถิ่น รายละเอียดของกระบวนการบัญชี และลักษณะเฉพาะของการทำ implementation ของระบบ ledger ของเรา มันยอดเยี่ยมมากกับการรีแฟกเตอร์ การแปลงข้ามภาษา และการตามหาบั๊กในโค้ดเดิม แต่พอเป็นการทำซ้ำและขยายในโดเมนของเรา ก็จะมีจุดที่ผิดแบบละเอียดอ่อนอยู่เสมอ อาจเป็นเพราะบริษัทที่ฉันทำงานมามักตั้งใจทำงานในพื้นที่ที่ซับซ้อนเพื่อสร้างคูเมืองทางธุรกิจ เป็นบริษัทที่อยู่รอดได้เพราะไม่มีหนังสือให้คัดลอกแบบ และความรู้เชิงปฏิบัติก็ยังอยู่ภายในองค์กร อีกอย่าง ถ้าเป็น FinTech ที่ผู้จัดการแนะนำให้ใช้ AI ทำเอกสารออกแบบให้เร็วขึ้น ก็ดูประมาทเกินไปสำหรับธุรกิจที่ต้องจัดการกับเงิน โดยเฉพาะเมื่อมีธุรกรรมขนาดเล็กจำนวนมหาศาล เพราะมันง่ายมากที่จะจัดสรรผิดพลาดเป็นหลักล้าน บั๊กแบบนี้รับมือยากจริง ๆ การแก้ logic เป็นแค่ขั้นแรก หลังจากนั้นยังต้องแก้ข้อมูลที่คำนวณผิดในฐานข้อมูลแบบ immutable จัดการกระบวนการตามกฎระเบียบ และสื่อสารกับลูกค้า การแก้ไขเหล่านี้กลายเป็นกับดักที่ฟีเจอร์ใหม่และระบบ observability ต้องคำนึงถึง เช่น “จำไว้ว่าความผิดปกติในข้อมูลวันที่ 2 กุมภาพันธ์เกิดจากเหตุการณ์ X”
ฉันกำลังสร้างผลิตภัณฑ์หลายตัวที่อิงกับการจำลองทางกายภาพ ซึ่งตั้งอยู่บนหลักการปฐมฐานล้วน ๆ แต่ถ้าปล่อยให้มันทำโดยไม่มีการวิจัย การคิด และการตรวจสอบเชิงรุก มันจะสร้างโค้ดคำนวณที่ช้ากว่าเดิมเป็นร้อยหลัก พร้อมทั้งใส่เส้นทางทดแทนและทางลัดที่เหลวไหล จนสุดท้ายได้การคำนวณที่ไร้ประโยชน์ เรื่องแบบนี้เกิดขึ้นประมาณ 95% ของเวลา การกำกับดูแลสำคัญมาก และการคิดเชิงสถาปัตยกรรมยัง outsource ไม่ได้ สิ่งที่ outsource ได้มีแค่การลงมือทำ
แน่นอนว่า senior software engineer มักเป็นผู้เชี่ยวชาญเรื่องเหล่านี้ด้วย แต่ไม่ใช่ข้อบังคับ ตามธรรมเนียมเดิม การที่วิศวกรทำงานได้ราว 90% โดยไม่ต้องถามผู้เชี่ยวชาญฝั่งธุรกิจนั้นมีประโยชน์ต่อการผลิตงานแบบไร้แรงเสียดทาน แต่ใจความของต้นฉบับก็คือ “ธรรมเนียม” นั้นจบลงแล้ว ในโลกใหม่ งานของวิศวกรอาวุโสไม่ใช่การมีความเชี่ยวชาญโดเมนนั้นด้วยตัวเอง แต่คือทำให้เอเจนต์มีหรือได้มาซึ่งความเชี่ยวชาญนั้น และทำให้มั่นใจได้ว่าสิ่งนั้นถูกต้องอย่างตรวจสอบได้ วิศวกรอาวุโสที่ยึดติดกับความเชี่ยวชาญเชิงโดเมนธุรกิจระดับสูงว่าเป็นสิ่งคุ้มกันตนเอง จะไปเจอทางตันในไม่ช้าไม่ต่างจากจูเนียร์ที่ยังไม่ปรับตัว
มันมีคลังคำศัพท์ลึกมากจนฟังดูเหมือนรู้มากกว่าที่รู้จริง มันเก่งมากในการเขียนโค้ดและดีบั๊ก error ที่มองเห็นได้ แต่ครึ่งหนึ่งก็ต้องยกความดีความชอบให้กับ อุปกรณ์ทดสอบ
แกนหลักคือป้อนเอกสารให้ LLM แล้วให้มันถามคำถามจำนวนมากเพื่อคลี่คลายความกำกวมและความเป็นไปได้ที่จะเข้าใจผิด แนะนำให้ลองดู Skills มันช่วยได้จริง ๆ https://www.youtube.com/watch?v=6BB6exR8Zd8
เราแก้ปัญหาได้ด้วยไฟล์ claude.md/agents.md ที่จัดระเบียบไว้อย่างดี และยังทำ supermemory.ai ไว้ด้วย เพื่อให้การตัดสินใจใหม่ ๆ ถูกเรียกคืนให้ AI agent ได้เสมอทุกครั้งที่เริ่มเซสชันใหม่
ผมนึกถึงคำพูดอันลือลั่นของ Steve Jobs ที่ว่า “ไอเดียราคาถูก” อยู่เสมอ
การลงมือทำคือทั้งหมด และถ้า LLM ระดับแนวหน้าช่วยแก้เรื่องการลงมือทำได้ ตอนนี้ไอเดียก็จะกลายเป็นประตูสู่ความอุดมสมบูรณ์ แต่ความอุดมสมบูรณ์เองก็ไม่ได้รับประกันว่าจะมี “แรงยึดเหนี่ยว” เสมอไป สิ่งที่มักถูกมองข้ามคือ ความตั้งใจ ของมนุษย์ที่จะอยู่กับสิ่งนั้นต่อไป และความใส่ใจจริงจังต่อมัน หลายคนไม่ได้ใส่ใจมากพอ หรือไม่ต้องการมากพอที่จะสร้าง บำรุงรักษา และเป็นเจ้าของบางสิ่ง V1 อาจปล่อยได้เร็วขึ้น แต่จะขัดเกลามันต่อไปเรื่อยๆ ได้ไหม ตัวอย่างที่ดีคือเครื่องมือทำเพลงด้วย AI อย่าง Suno ตอนนี้มันสร้างผลลัพธ์ที่ค่อนข้างดีได้ หลายคนมีโลกเล็กๆ ของตัวเองไว้เล่นอยู่พักหนึ่ง แล้วก็เบื่อและจากไปอย่างรวดเร็ว เหลือเพียงผู้สร้างผลงานจำนวนมากไม่กี่คนที่เปลี่ยนมันให้กลายเป็นสภาพแวดล้อมแบบ “งานจริง” ขนาดและต้นทุนของการมอบหมายงานกับการลงมือทำอาจเปลี่ยนไปแล้ว แต่ยังมีปัจจัยให้ต้องคิดอีกมาก
ต่อให้เป็นคนที่มีความรู้ทางดนตรีจำกัด ผมก็ยังรู้สึกแบบนั้น ดังนั้นนักดนตรีก็น่าจะวิจารณ์หนักกว่านี้ ช่วงสองสามครั้งแรกมันน่าประทับใจ และเมโลดีก็ติดหู เมื่อก่อนมันมีอะไรแปลกๆ ในพื้นหลัง แต่ตอนนี้ส่วนใหญ่แก้ไปแล้ว อย่างไรก็ตาม พอผ่านไปหลายสิบเพลง มันจะเริ่มฟังคล้ายๆ กันตลอด ทุกเพลงดูทั่วไปไปหมด เพลงไม่ได้เล่าเรื่องอะไร และให้ความรู้สึกเหมือนเพลงประกอบโฆษณาบริษัท ผมลองเขียนพรอมป์ต์ให้แม่นขึ้นก็ไม่ค่อยช่วย และรายละเอียดที่ทำให้เพลงน่าสนใจส่วนใหญ่ก็ถูกมองข้ามไป ผลลัพธ์ที่น่าสนใจที่สุดกลับเกิดตอนที่ทำให้มันหลุดวงโคจรเหมือนเกิดบั๊ก ผมเคยขอให้มันผสมสองแนวเพลงที่ต่างกันมาก แล้วได้ผลลัพธ์ที่ให้ความรู้สึกไม่สบายใจแบบที่จำไม่ได้ว่าเคยได้ยินมาก่อน แต่ถ้าจะทำต่อยอด มันก็ยากเสมอ และพยายามจะกลับไปหาผลลัพธ์แบบทั่วไปอีก ทั้งยังไม่สนใจคำสั่งรายละเอียด Suno รีมิกซ์ได้ มันคล้ายกับโค้ด LLM เก่งมากอยู่แล้วในเรื่อง การพอร์ต สิ่งที่ทำงานอยู่แล้วให้ไปทำงานในภาษาอื่น แต่ถ้ามีแค่ไอเดีย มันจะพังในส่วนที่ต้องมีความเป็นต้นฉบับ ถ้าจะทำให้ LLM นำไอเดียไปทำได้ถูกต้อง คุณต้องให้คำแนะนำมากเกินไป จนกลายเป็นว่าต้องสู้กับความกำกวมของภาษาธรรมชาติ และแทบไม่ต่างจากการเขียนโค้ดเอง
ถ้าคุณผลักมันมากพอ และมีระบบที่ทำให้ได้โค้ดที่ใช้งานได้จริง คุณอาจแก้เรื่องการลงมือทำได้ แต่สิ่งนั้นแหละคือ วิศวกรรม ตอนนี้ในสภาพปกติพื้นฐาน มันยังห่างไกลมากจากการแทนที่วิศวกรรม บางทีอีก 3 ปีอาจเป็นไปได้ เพราะมันพัฒนาเร็วมาก แต่วันนี้คุณยังพูดว่า “ช่วยสร้าง Rust compiler ที่ดีกว่านี้ให้หน่อย” แล้วเอนหลังรอรับผลลัพธ์ไม่ได้
เพลงพวกนั้นเป็นเพลงที่ผมชอบ และพอฟังได้ในเพลย์ลิสต์ของตัวเอง แต่ในอัลกอริทึมของ Suno มันไม่ได้รับการตอบรับมากนัก ผมก็ไม่ได้โปรโมตมันมากในที่อื่น และตอนที่ลองโพสต์ก็ได้แค่ไลก์ไม่กี่อัน ผมไม่ได้ผิดหวัง เพราะผมทำเพลงเพื่อตัวเอง และการแชร์เป็นเพียงผลข้างเคียง ข้อสรุปที่ผมได้จากเรื่องนี้คือ ยังต้องทำอีกมากถ้าจะให้คนสนใจและสนุกกับสิ่งที่ผมทำ คุณต้องทำการตลาด ต้องเอามันไปให้คนเห็น ต้องทำให้คนสนใจ และผมยังมั่นใจว่าต้องเชื่อมมันเข้ากับวิดีโอ เรื่องราว บุคลิก หรือบรรยากาศบางอย่าง เพื่อให้คนมีเหตุผลที่จะชอบมัน ถ้าจะทำให้มัน “ติด” คุณต้องทำทั้งหมดนั้นซ้ำๆ กับผู้ชมกลุ่มเดิม และทำให้พวกเขาคุ้นเคยกับมัน นั่นจึงต้องอาศัย ความต่อเนื่อง และคุณต้องใส่ใจกับสิ่งที่พยายามจะขายอย่างจริงใจ ก่อนที่คนอื่นจะติดกับมัน ผมต้องติดกับมันก่อน
https://en.wikipedia.org/wiki/Sturgeon%27s_law
กฎของ Sturgeon กล่าวว่า “90% ของทุกสิ่งคือขยะ” คำกล่าวนี้มาจาก Theodore Sturgeon นักเขียนและนักวิจารณ์นิยายวิทยาศาสตร์ชาวอเมริกัน ซึ่งเสนอขึ้นเพื่อปกป้องคุณค่าของงานแนวนี้ Sturgeon มองว่าไม่ว่าสาขาไหน ผลงานส่วนใหญ่ก็มักมีคุณภาพต่ำ ดังนั้นนิยายวิทยาศาสตร์จึงไม่ได้ด้อยกว่าสาขาอื่นเป็นพิเศษ
จากความเข้าใจของผม มันถูกใช้เหมือนเครื่องมือสร้างงานแบบครั้งเดียวจบ ผมไม่ค่อยรู้เรื่องดนตรี แต่สำหรับศิลปิน ผมคิดว่าน่าจะต้องมีขั้นตอนกลาง การแยกแทร็ก การปรับแต่งเครื่องดนตรี และองค์ประกอบอื่นๆ อีกหลายอย่างที่ผมไม่รู้ ถ้าไม่มีสิ่งพวกนี้ ก็คงยากที่จะใช้กับงานระดับมืออาชีพ
ผมไม่ได้เห็นด้วยกับบทความนี้ทั้งหมด vibe coder ไม่มีทางออกแบบ พัฒนา และลงมือสร้างระบบที่มีความซับซ้อนระดับปานกลางได้โดยไม่ทำทุกอย่างพัง
ส่วนสำคัญมากของการใช้แอปพลิเคชันอย่าง Claude ให้ได้ดี คือความเข้าใจเชิงแนวคิดและประสบการณ์เกี่ยวกับแนวคิดด้านวิทยาการคอมพิวเตอร์ ซึ่งเป็นสิ่งที่ vibe coder ไม่มีทางมี ถ้ามี ก็คงไม่ใช่ vibe coder ไปแล้ว
"ไม่รู้ว่าควรทำอะไร" ก็แค่โต้คลื่นไปกับมัน
ตอนที่เว็บไซต์/เว็บแอปเป็นคลื่นลูกหนึ่ง ฉันก็โต้คลื่นนั้นมาแล้ว ฉันเข้าวงการซอฟต์แวร์ก่อนยุคอินเทอร์เน็ต และเปลี่ยนม้ากลางศึกมาตลอด ไม่มีคำว่าสายเกินไปสำหรับการเรียนรู้เทคโนโลยีใหม่ คลื่นลูกใหม่สร้างงานและแรงงานแบบใหม่ขึ้นมา แค่เป็นหนึ่งในนั้น ขี่สัตว์ร้ายตัวนี้ให้ได้ แล้วฝึกใช้เครื่องมือให้ชำนาญ เกมเดิมแค่กลับมาอีกครั้ง
ถ้ามีทักษะที่เป็นที่ต้องการอย่างสม่ำเสมอ มันคือ ความสามารถในการจัดโครงสร้างสิ่งต่างๆ ในหัว ไม่ว่าจะเป็นงานใหม่ กระบวนการใหม่ หรือผู้คนใหม่ๆ ฉันทำงานเป็นช่างเครื่องต้นแบบ และได้เข้าใจรวมถึงพัฒนาความสามารถนี้ให้กลายเป็นเครื่องมือที่คมมาก สำหรับคนที่ไม่คุ้นเคย ช่างเครื่องต้นแบบคือคนที่ทำทุกอย่างที่จำเป็นเพื่อสร้างชิ้นส่วนยากๆ ภายใต้ตารางเวลาสั้นๆ ทุกสัปดาห์ จัดการได้ทั้งโลหะ พลาสติก หรืออะไรก็แล้วแต่ เราเลยชำนาญในการทำความคุ้นเคยกับกระบวนการ เครื่องจักร และวัสดุอย่างรวดเร็ว ทำแบบนั้นไปสักพัก คุณจะซึมซับข้อมูลใหม่ได้เร็วมาก และเข้าใจงานได้เร็วและแม่นยำกว่าคนส่วนใหญ่ ทุกคนเริ่มได้ แค่มีความอยากรู้อยากเห็นและลงมือสร้างอะไรบางอย่าง แล้วก็สร้างต่อไป แชร์สิ่งที่คุณสร้าง และสร้างสิ่งที่คนอื่นต้องการ
ในยุค 90 และ 00 ก็มีคลื่นแบบ “การเขียนโปรแกรมเชิงวัตถุจะเปลี่ยนทุกอย่าง” มาก่อน มันเป็นแนวว่าของที่เคยทำสำเร็จมาแล้วหลายร้อยครั้ง ตอนนี้จะทำมันแบบเชิงวัตถุ เขียนโค้ดเกี่ยวกับเครื่องบินอยู่เหรอ? ก็แค่ซื้อออบเจ็กต์เครื่องบินสารพัดนึกที่ทำทุกอย่างเกี่ยวกับเครื่องบินได้ นี่คือเรื่องที่ฉันเคยได้ยินจริงๆ ในมหาวิทยาลัย แล้วการเขียนเชิงวัตถุก็ไม่ใช่คำตอบของทุกอย่างงั้นเหรอ? งั้นลอง code generation สิ Ruby on Rails ไง สร้างเว็บไซต์ได้ใน 2 วินาที code generation มีอยู่เต็มไปหมด แล้วมันก็ไหลไปในทิศทางแปลกๆ ก่อนจะมาถึง TDD ฉันเคยเห็นบทสนทนาจริงที่พูดกันว่าถ้าไม่ทำ TDD ก็เป็นวิศวกรที่แย่ถึงขั้นควรจับเข้าคุก ไม่สิ ไม่ใช่ TDD แต่ BDD ต่างหากคือคำตอบ Lean, ไม่สิ Agile, ไม่สิ agile ตัวพิมพ์เล็ก แต่ตอนแรกมันคืออย่างนั้น, ไม่สิ Scrum, ไม่สิ XML เดี๋ยวก่อน นั่นมันสิบปีก่อน, JSON, แล้วสุดท้ายก็ SAFe และตอนนี้ก็ “เห็นแชตบอตตัวนี้หรือยัง?” ทุกวัฏจักรมีสิ่งดีๆ ติดมาด้วย ถ้าคุณใส่ใจพอ แต่มันก็มาพร้อมการโฆษณาเกินจริงและความกังวลมากมายเช่นกัน แค่ทดลองและเรียนรู้ สิ่งหนึ่งที่สำหรับฉันไม่เคยเปลี่ยนคือ แทบทุกคนยอมตายเสียดีกว่าจะคิดอย่างรอบคอบถึงผลลัพธ์ของวันที่ความฝันของตัวเองเป็นจริง ตราบใดที่สิ่งนี้ยังเป็นจริง ผู้คนก็จะยังยอมจ่ายเงินให้ใครสักคนมาขี่ มังกรแห่งกระแสโอ้อวด แทนตัวเองต่อไป
กระแสสายพานผลิตผลงานคุณภาพต่ำทั้งโรงงาน หรือไม่ก็สาย “AI native” มันเป็นแบบนี้: “ว้าว ฉันหว่านล้อมแชตบอตให้สร้างสิ่งที่ฉันไม่เข้าใจเลยได้ด้วย ฉันนี่ทำงานเก่งจริง!” มันเหมือนรางวัลปลอบใจสำหรับการสร้างของ บางสิ่งอย่างอื่นเป็นคนสร้าง แต่ฉันกลับรับเครดิตทั้งที่แทบไม่เข้าใจมันด้วยซ้ำ ความพยายามของฉันไม่ก่อผลทบต้น ไม่มีบทเรียนให้เรียนรู้ ไม่มีความเข้าใจสะสม ไม่มีอินไซต์ที่จะนำไปสู่นวัตกรรมในอนาคต ไม่มีความแตกต่างอะไรเลย มีแต่ตะโกนใส่ความว่างเปล่าจนมึนงง แล้วรอให้สล็อตแมชชีนคายของผสมคุณภาพต่ำที่ “ดูดีพอใช้” ออกมา จากนั้นวันถัดไปก็ทำซ้ำอีก ถ้านี่คือเกม ฉันขอไม่เล่น คนอื่นจะสนุกกับมันก็ยินดีด้วย แต่การคิดว่านี่มีความชำนาญอะไรอยู่ด้วยนั้นเป็นภาพลวงตา เงื่อนไขเดียวที่จะ “ประสบความสำเร็จ” กับเครื่องมือนี้ได้คือเลิกใส่ใจแล้วก็ยอมแพ้
เคยโพสต์อันนี้มาก่อนแล้ว แต่ก็คุ้มค่าที่จะโพสต์อีกครั้ง
ฉันทำงาน DevOps ในบริษัทที่ใช้ LLM อย่างจริงจังมาก ลำดับคร่าวๆ เป็นแบบนี้: ลองให้ LLM ทำ “หลายอย่าง”, ให้ทำมากขึ้น, รันหลายเอเจนต์, กลับมาที่เอเจนต์เดี่ยวอีกครั้งแต่ให้มันสร้างเครื่องมือ, แล้วค่อยไปสู่ เครื่องมือแบบกำหนดผลลัพธ์แน่นอน ที่ทั้งคนและ LLM ใช้ได้ เหตุผลคือแบบนี้ ในทั้งการดีพลอยและการทดสอบ เครื่องมือแบบกำหนดผลลัพธ์แน่นอนให้คำตอบแบบไบนารีและทำซ้ำได้ ถ้าเกิดเหตุขัดข้อง ก็กลับไปใช้เครื่องมือที่มนุษย์รันเองได้เสมอ มันเร็วกว่า สคริปต์ง่ายๆ ใช้เวลาไม่ถึง 30 วินาที แต่ “การเพ้อเจ้อที่ฟังดูน่าเชื่อ” ดูเหมือนจะกินเวลา 2–3 นาทีเสมอ ท้ายที่สุดก็ย้อนกลับมาที่บทความนี้ https://spawn-queue.acm.org/doi/10.1145/3194653.3197520 นั่นคือ “ทำรายการงาน เขียนสคริปต์สำหรับแต่ละงาน นำสคริปต์มาประกอบเป็นฟังก์ชัน แล้วฟังก์ชันนั้นก็กลายเป็นระบบ” และขอเสริมว่า ถ้าปล่อยให้ LLM ทำตามใจ มันก็ยินดีจะเขียนโค้ดให้ คุณสามารถเพิ่มการทดสอบเพื่อยืนยันว่าการทดสอบทำงานได้ แบบเดียวกับที่เราเคยทำกับโค้ดของคนมาก่อน คุณก็ยังอ่านโค้ดได้ และเมื่ออ่านโค้ด คุณจะพบว่าบางครั้งมันสร้างโค้ดที่ทำงานได้แต่ก็ทำเรื่องบ้าบอสุดๆ ไปพร้อมกัน แน่นอนว่าคนก็ทำแบบนั้นได้เหมือนกัน แต่นั่นเป็นอีกเรื่องหนึ่ง สุดท้ายคุณก็ยังต้องตรวจสอบอยู่ดีว่าระบบที่สร้างขึ้นมานั้นสมเหตุสมผลหรือไม่ พูดให้สั้นกว่านั้นคือ การเขียนโค้ดอาจตายแล้ว แต่ซอฟต์แวร์เอนจิเนียริงยังมีชีวิตและวิ่งฉิวอยู่
คุณจะให้ LLM ขนาดใหญ่ทำทุกอย่างก็ได้ มันทำได้ และคนก็ทำกันจริง แต่ทั้งแพงมากและใช้เวลานานกว่า ถ้าเปลี่ยนมาใช้ AI สร้างเครื่องมือเพื่อจัดการงานในกระบวนการให้ได้มากที่สุดแบบกำหนดผลลัพธ์แน่นอน แล้วให้ AI ใช้เครื่องมือเหล่านั้น ระบบจะทำงานได้เร็วกว่าและถูกกว่ามาก แถมสุดท้ายคุณยังอาจเลิกใช้คลาวด์ AI ราคาแพง แล้วไปรันบน โมเดลโลคัล ขนาดเล็ก/กลางแทนได้อีกด้วย
ถ้าภาพอนาคตของผู้เขียนถูกต้อง วิศวกรซอฟต์แวร์ที่เก่งจริงก็ยังปลอดภัยอยู่
ความรู้โดเมนเรียนรู้ได้เร็วกว่าการรู้วิธีนำหลักวิศวกรรมที่ดีไปใช้อย่างถูกต้องมาก วิศวกรที่มีจุดแข็งหลักเป็นความรู้โดเมนอาจไม่ได้โดดเด่นด้านวิศวกรรมตัวมันเองนัก ถึงอย่างนั้นก็ยังหางานในส่วนอื่นของอุตสาหกรรมที่ต้องใช้ ความรู้โดเมน ที่สั่งสมมาได้
วิศวกรซอฟต์แวร์เก่ง ๆ จำนวนมากที่หยิ่งยโสว่าความรู้โดเมนเป็นของที่หยิบเอาได้ง่าย เคยทำ ระบบ ERP พังมานับไม่ถ้วนแล้ว งานส่วนมหาศาลของ IT ก็คือการเอากฎทางธุรกิจใส่ลงไปในระบบแบบตรงตัวนี่เอง
กระนั้นฉันก็ยังเห็นและยังรีวิวโค้ดของนักพัฒนาซอฟต์แวร์ “ผู้เชี่ยวชาญ” ที่ไม่ทำตามแนวปฏิบัติวิศวกรรมซอฟต์แวร์ที่ดีอยู่ดี คำพูดที่ว่าวิศวกรที่มีจุดแข็งหลักเป็นความรู้โดเมนอาจไม่ได้เก่งด้านวิศวกรรมนั้น ใช้กับวิศวกรที่ไม่มีความรู้โดเมนด้วยเหมือนกัน อย่างน้อยจากประสบการณ์ของฉันนะ หรือบางทีเราอาจโชคร้ายก็ได้
เพราะความรู้โดเมนที่มีค่าคือความรู้ของวันนี้และพรุ่งนี้ ไม่ใช่ของเมื่อวาน ในสาขาที่ความรู้โดเมนสำคัญ มันพันเกี่ยวกับวิศวกรรมอย่างลึกซึ้ง คุณคงไม่มอบหมายให้ Jeff Dean ไปพัฒนา Unreal Engine ตั้งแต่ศูนย์หรอก ถึงอย่างนั้นก็ยังมีหลักวิศวกรรมซอฟต์แวร์อีกมากที่ผู้เชี่ยวชาญด้านโดเมนยังไม่ได้ซึมซับอย่างสมบูรณ์หรือปฏิบัติได้ดีพอ และตราบใดที่ความรู้โดเมนยังมีค่า สภาพนี้ก็จะยังคงอยู่ เพราะวิศวกรรมซอฟต์แวร์เองก็เป็นอีก โดเมน หนึ่งเหมือนกัน
วิธีวิทยา ปรับปรุงได้เร็วกว่าการได้มาซึ่งความเชี่ยวชาญมาก อย่างแรกเป็นเรื่องของแนวทาง จึงบังคับใช้และเร่งให้ดีขึ้นได้เร็ว อย่างหลังขึ้นกับนิสัยการเรียนรู้ ความสามารถ และเวลาที่แต่ละคนมีในช่วงนั้น ซึ่งบังคับเกินกว่าการสนับสนุนอย่างสมเหตุสมผลไม่ได้ อีกทั้งมันยังเป็นสิ่งที่ค่อย ๆ สั่งสมในตัวเอง ทำให้ช่วงต้นของเส้นโค้งการเรียนรู้ชันกว่ามาก
ฉันใช้ Claude Code กับ Opus 4.7 อยู่ และปัญหาไม่ใช่ว่ามันสร้างโค้ดผิด แต่คือมันมีแนวโน้มจะเขียนเยอะเกินไป
การคิดถึงฟีเจอร์หนึ่งอย่างเฉพาะเจาะจงแล้วใส่มันลงในโค้ดในแบบที่เหมาะที่สุดยังคงมีคุณค่า Claude มักจะเลือกชั้นใดชั้นหนึ่งของสแตก เช่น ชั้นการแสดงผล แล้วอัดมันเข้าไปตรงนั้น พออีกไม่กี่สัปดาห์ต่อมาข้อมูลเดียวกันนั้นต้องใช้ในที่อื่นอีก Claude ก็ไม่สามารถนำโค้ดในชั้นบริการกลับมาใช้ซ้ำได้ และทำอะไรคล้าย ๆ “การย้ายปลูก” แทน ถ้ามนุษย์ไม่คอยระวัง ปริมาณโค้ดจะเพิ่มเป็นสองเท่าและตรรกะก็จะซ้ำซ้อน ดูไม่น่าเป็นไปได้ว่าเครื่องมือ AI แบบ Claude จะเก่งเรื่องนี้ขึ้นมากในเร็ว ๆ นี้ ที่ทำงานของฉันก็เริ่มมีแรงกดดันให้ลดการใช้ Opus 4.7 เพื่อประหยัดค่าใช้จ่ายแล้ว มีคนเสนอด้วยซ้ำว่าให้ใช้โมเดลเล็กกว่าสำหรับ “การแก้บั๊กง่าย ๆ” บางครั้งก็คงได้ แต่ในทางปฏิบัติเราจะรู้ล่วงหน้าได้บ่อยแค่ไหนว่านี่เป็นการแก้บั๊กง่าย ๆ? ถ้าต้นทุนสูงขึ้น ความสนใจที่จะใช้เครื่องมือนี้เขียน “โค้ดทั้งหมด” ก็น่าจะลดลง ถ้าผู้คนย้ายไปใช้โมเดลที่ถูกกว่าและได้ผลน้อยกว่า แรงกดดันที่จะไม่ต้องรีวิวโค้ดนั้นก็น่าจะหายไปด้วย สุดท้ายจะลงเอยตรงไหนคงต้องรอดู แต่บางทีมันอาจไม่ได้เปลี่ยนไปอย่างรุนแรงเท่าที่ผู้เขียนกลัวก็ได้
แค่บอก AI ให้ลดจำนวนบรรทัดโค้ด production ลงครึ่งหนึ่ง และดูว่ามีไลบรารีอื่นที่นำกลับมาใช้ได้หรือไม่ ก็ได้ผลน่าประหลาดใจแล้ว ดูเหมือนว่าจะสร้างบอตรีแฟกเตอร์ที่คอยหาโค้ดซ้ำแล้วดึงออกมาได้ด้วย ตอนนี้ยังไม่ได้มีมาให้โดยปริยาย แต่ก็ไม่ได้ชัดเจนว่ามันทำไม่ได้
แต่คำถามที่ยังเปิดอยู่คือ โค้ดที่มากเกินไปนั้นเป็นปัญหาจริงหรือไม่ เครื่องมือพวกนี้กลายเป็นส่วนหนึ่งของชีวิตไปแล้ว ถ้ามันช่วยแก้ปัญหาหรือดีบักได้เร็วขึ้น และทำให้ซอฟต์แวร์มีบั๊กน้อยลง งั้นมันอาจไม่ใช่โค้ดมากเกินไป แต่อาจเป็นจำนวนบรรทัดโค้ดที่พอดีก็ได้
fooBar()กับfooBarExtended()อยู่สองตัวตัวหลังมีพารามิเตอร์และความสามารถเพิ่มเติมที่จำเป็นกับปัญหาปัจจุบันอยู่แล้ว แต่ Claude กลับพยายามเพิ่มพารามิเตอร์ขยายแบบเดียวกันเข้าไปในฟังก์ชันตัวแรกเรื่อย ๆ แทนที่จะเรียกใช้ฟังก์ชันนั้น หลังจากฉันบอกว่าอย่าทำแบบนั้น มันก็ยังกลับมาเสนอแบบเดิมอีกในภายหลัง และบางทีก็น่าหงุดหงิดจริง ๆ
ไม่ว่าจะมองอนาคตของอุตสาหกรรมอย่างไร ฉันคิดว่าคงยากที่จะหาความสำเร็จทางอาชีพจาก งานไม้เชิงช่างฝีมือ ได้มากกว่าซอฟต์แวร์เชิงช่างฝีมือ
เคยมีคนบอกให้ฉันลองขายเฟอร์นิเจอร์ที่ฉันทำ คำตอบของฉันก็เหมือนเดิมเสมอ ฉันเคยพลาดเปลี่ยนงานอดิเรกเป็นอาชีพมาแล้วครั้งหนึ่ง และไม่คิดจะพลาดแบบนั้นอีก อย่างน้อยซอฟต์แวร์ตอนนี้ก็ยังจ่ายดีอยู่มาก
มีคนที่ทำงานกับฉันคนหนึ่งทำพวกดาดฟ้า สวน คาราวาน โรงเก็บของ รั้ว อะไรทำนองนี้ และเขาทำเงินได้ดีมาก แน่นอน เพื่อความยุติธรรมต้องบอกว่าเขาเก่งมากจริง ๆ
วงกบประตูผุ ฉันเลยจ่ายช่างไม้ไป 4,000 ดอลลาร์เพื่อทำของทดแทน ถ้าจะเปลี่ยนประตูทั้งบานก็น่าจะทะลุ 25,000 ดอลลาร์ได้ไม่ยาก ถ้าคุณย้ายไปอยู่ย่านประวัติศาสตร์หลักที่มีประตูแกะมือเยอะ ๆ ก็อาจหาเงินได้พอตัว
แต่สัดส่วนของตลาดที่อยากจ่ายเงินให้ซอฟต์แวร์ทำมือคือ 0% พอดี
ไม่ใช่งานไม้ แต่เป็นเกษตรกรรมต่างหาก ต้องหาที่ดินแล้วปลูกอาหารกินเอง การไม่เข้าร่วมในระบบเศรษฐกิจเลยคือหนทางรอดทางเดียว