การดูเหมือนมีประสิทธิภาพในที่ทำงาน
(nooneshappy.com)- Generative AI ทำให้เกิด การสร้างข้ามโดเมน ได้ คือคนที่ไม่ได้รับการฝึกสามารถสร้างผลงานของอีกสายวิชาชีพหนึ่งได้ และทำให้มือใหม่ดูเหมือนเพิ่มผลิตภาพได้ทั้งที่ไม่มีวิจารณญาณพอจะตรวจทานผลลัพธ์
- ในที่ทำงาน ผลลัพธ์อย่างโค้ด ระบบข้อมูล และเอกสารที่ภายนอกดูเหมือนความคืบหน้ามีเพิ่มขึ้น แต่ผู้ใช้กลับอธิบายวิธีการทำงานจริงไม่ได้ หรือผิดพลาดตั้งแต่ สคีมาและเป้าหมาย ตั้งต้น
- AI ตัดความสัมพันธ์ที่คุณภาพของผลงานเคยสะท้อนความสามารถของผู้สร้าง ก่อให้เกิด การแยกขาดระหว่างผลงานกับความสามารถ และทำให้ผู้ใช้ใกล้เคียงกับการเป็นเพียงท่อส่งผลลัพธ์ต่อโดยไม่สามารถประเมินมันได้
- เอกสารและอัปเดตภายในมีต้นทุนการสร้างต่ำลงจึงยาวขึ้น แต่ต้นทุนการอ่านไม่ลดลง ทำให้หา สัญญาณ ได้ยากกว่าเดิมในองค์กร และกลายเป็น AI slop รูปแบบใหม่ที่ถูกสร้างโดยคนที่ได้รับเงินเดือน
- Generative AI เหมาะกับงานอย่างร่างแรก ตัวอย่าง สรุปความ brainstorm และการตรวจแก้ ที่มนุษย์ยังเป็นผู้ตัดสินขั้นสุดท้ายและรับ feedback ได้รวดเร็ว ขณะที่ความสามารถในการส่งมอบงานที่เชื่อถือได้ยังคงเป็นความได้เปรียบในการแข่งขันของบริษัท
ปัญหาของผลงานจาก AI ที่ดูเหมือนผลิตภาพในการทำงาน
- Generative AI สามารถสร้าง ผลลัพธ์ที่ดูเหมือนผลงานระดับมืออาชีพแม้ไม่มีความเชี่ยวชาญ และความล้มเหลวมีอยู่สองรูปแบบ
- มือใหม่ในสาขาหนึ่งสร้างผลลัพธ์ที่ดูเร็วกว่า หรือดูซับซ้อนกว่าวิจารณญาณที่ตนมี
- คนที่ไม่เคยได้รับการฝึกในสาขานั้น สร้างผลงานของอีกสายวิชาชีพหนึ่ง
- งานวิจัยก่อนหน้านี้มักวัดรูปแบบแรกเป็นหลัก แต่สิ่งที่อันตรายกว่าคือ การสร้างข้ามโดเมน ที่คนซึ่งไม่ได้รับการฝึกสร้างผลงานของอีกสาขาหนึ่งขึ้นมา
- ในช่องทางสาธารณะ มีกรณีที่เพื่อนร่วมงานคัดลอกคำตอบที่ดูเหมือนมาจาก Claude มาวางตรง ๆ และทำเหมือนเข้าใจเทคโนโลยีที่จริง ๆ แล้วตนไม่เข้าใจ
- ในสถานการณ์แบบนี้ คู่สนทนาไม่ได้อยู่ปลายอีกฝั่งของบทสนทนาจริง ๆ แต่ทำหน้าที่คล้ายผู้ส่งต่อผลลัพธ์จากโมเดล
การสร้างข้ามโดเมน
- เกิดกรณีที่คนเขียนโค้ดไม่เป็นกลับสร้างซอฟต์แวร์ และคนที่ไม่เคยออกแบบระบบข้อมูลกลับออกแบบระบบข้อมูล
- ส่วนใหญ่ไม่ได้ถูกปล่อยใช้งานจริง แต่ถูกแชร์ภายในอย่างตื่นเต้น หรือถูกใช้อย่างเงียบ ๆ และบางครั้งก็ไปถึงมือลูกค้า
- ตอนนี้มีคนทำงานจริงบางรายที่ใช้เครื่องมือแบบ agentic ทำงานซับซ้อนได้ดี แต่พบได้น้อย และมักอยู่ในงานสร้างโค้ด
- ความสามารถด้าน AI ระดับบุคคลเพิ่มขึ้น แต่ในสถานที่ทำงานยังขยายผลได้ไม่ดี
- เพื่อนร่วมงานคนหนึ่งที่ไม่ได้อยู่ในสายวิศวกรรม ใช้เวลาสองเดือนช่วงต้นปีนี้สร้างระบบที่ควรถูกออกแบบโดยคนที่ผ่านการฝึกด้าน data architecture อย่างเป็นทางการ
- ตามเกณฑ์ประเมินการใช้เครื่องมือ AI ในปัจจุบัน เขาใช้เครื่องมือได้ดี และสร้างโค้ด เอกสาร และผลงานที่ภายนอกดูเหมือนความคืบหน้าได้จำนวนมาก
- แต่เมื่อถูกถาม เขากลับอธิบายวิธีการทำงานจริงไม่ได้
- สคีมาและเป้าหมายผิดมาตั้งแต่วันแรก และเป็นความผิดพลาดระดับที่คนมีประสบการณ์สองปีในสายนี้ก็ควรสังเกตได้
- หลายคนรู้เรื่องนี้ และเรื่องไปถึงระดับ V.P. แล้ว แต่ผู้จัดการไม่อยากสั่นคลอนสิ่งที่ได้ลงทุนไปกับภาพลักษณ์ของแรงส่งนั้นแล้ว
- เครื่องมือนี้ไม่ได้ทำให้เขาเป็นเพื่อนร่วมงานที่แย่ลง แต่ทำให้เขา เลียนแบบงานในสาขาที่ตนไม่ได้รับการฝึกได้อย่างแนบเนียน อยู่หลายเดือน
- แรงจูงใจในองค์กรเอนเอียงไปทางการปล่อยให้การเลียนแบบนั้นดำเนินต่อ
- มันอาจเป็นความล้มเหลวด้านการบริหารจัดการ แต่ความตั้งใจของฝ่ายบริหารที่จะยอมรับ AI ก็ทำให้พร้อมรับความเสี่ยงนี้
- ถ้าโมเดลประเมินผลงานอย่างซื่อสัตย์ ปัญหานี้อาจบรรเทาได้ แต่ความจริงไม่ใช่เช่นนั้น
- งานวิจัยของ Stanford โดย Cheng และคณะ Sycophantic AI decreases prosocial intentions and promotes dependence ยืนยันว่าโมเดลชั้นนำมีแนวโน้มคล้อยตามมากกว่ามนุษย์ราว 50% และมักเห็นด้วยกับผู้ใช้แม้ไม่มีเหตุผลรองรับ
- ตาม Seven Myths About AI and Productivity: What the Evidence Really Says ของ Berkeley CMR แม้แต่ผู้ใช้ที่มีทักษะในการใช้ AI ก็มักประเมินผลงานของตนสูงเกินจริง
- ตาม Generative AI at Work ของ NBER Generative AI เพิ่มผลิตภาพของเจ้าหน้าที่ support มือใหม่ได้ราวหนึ่งในสาม แต่แทบไม่ช่วยผู้เชี่ยวชาญ
- งาน Navigating the Jagged Technological Frontier ของ Harvard Business School ก็ยืนยันรูปแบบเดียวกันในงานที่ปรึกษา
- ผลคือ มือใหม่อาจเพิ่มผลิตภาพส่วนบุคคลในพื้นที่นอกเหนือความเชี่ยวชาญของตนได้ แต่ยังไม่มีความสามารถพอจะตรวจว่าผลงานนั้นถูกต้องหรือไม่
ปัญหาท่อส่ง
- ปรากฏการณ์นี้เริ่มถูกเรียกว่า การแยกขาดระหว่างผลงานกับความสามารถ (output-competence decoupling) มากขึ้นเรื่อย ๆ
- ในอดีต คุณภาพของผลงานมักเป็นสัญญาณที่สะท้อนความสามารถของผู้ผลิต
- งานเขียนของมือใหม่ก็อ่านแล้วรู้ว่าเป็นมือใหม่ และโค้ดของมือใหม่ก็ล้มเหลวในแบบของมือใหม่
- AI ตัดความสัมพันธ์นี้ออก ทำให้มือใหม่สร้างผลงานที่ไม่เผยว่าตัวเองยังเป็นมือใหม่ได้
- ความสามารถที่ผลงานสะท้อนไม่ใช่ความสามารถของผู้ใช้ แต่เป็นความสามารถของระบบ
- ผู้ใช้ส่งต่อผลลัพธ์ให้ผู้รับได้ แต่ใกล้เคียงกับการเป็น ท่อส่ง ที่ไม่สามารถประเมินระหว่างทางได้
- ความสามารถในการสร้างผลงานกับความสามารถในการตัดสินแยกจากกันมาแต่เดิม แต่กระบวนการลงมือทำงานจริงเคยช่วยหล่อเลี้ยงวิจารณญาณ
- ความสามารถข้อแรกในการสร้างผลงาน ถูกย้ายไปอยู่กับเครื่องจักรเป็นส่วนใหญ่แล้ว
- ความสามารถข้อที่สองในการตัดสินยังคงอยู่กับมนุษย์ แต่คนที่พยายามเรียนรู้หรือใช้มันกลับลดลง
- ในอดีต การวิจารณ์สถาปัตยกรรมมาจากคนที่ผ่านการศึกษา หรือเคยสร้างและทำระบบล้มเหลวด้วยตัวเองมาหลายครั้ง
- ตอนนี้คำวิจารณ์แบบนั้นกลับออกมาจากโมเดลที่ไม่มีความทรงจำฝังลึกจากการสร้างหรือทำให้มันพังจริง
- ความช้าไม่ใช่เพียงต้นทุนที่ติดมากับการทำงานจริง แต่เป็นกระบวนการที่ทำให้งานดีขึ้น คนเก่งขึ้น และบริษัทสามารถรับปากคุณภาพบางอย่างกับลูกค้าได้
- ระบบแบบ agentic รุ่นปัจจุบันถูกออกแบบบนสมมติฐานว่ามนุษย์คือคอขวด
- สมมติว่าถ้ายิ่งลดความล่าช้าจากการที่มนุษย์ต้องอ่านล่วงหน้าและตัดสินสิ่งที่จะเกิดขึ้น วงรอบก็จะยิ่งเร็วและสะอาดขึ้น
- ในหลายกรณีความจริงตรงกันข้าม เพราะมนุษย์ในวงรอบไม่ใช่เศษซากจากอดีต แต่เป็นองค์ประกอบเดียวที่มีส่วนได้ส่วนเสียกับผลลัพธ์
- การเอามนุษย์ออกจาก human-in-the-loop (HITL) ไม่ใช่การเพิ่มประสิทธิภาพ แต่คือการทิ้งกลไกเดียวที่ระบบใช้ตรวจจับความผิดพลาดของตัวเองได้
AI slop ภายในองค์กร
- เอกสารงานกำลังยาวขึ้นอย่างรวดเร็ว
- เอกสาร requirement ที่เคยมีหน้าเดียว กลายเป็น 12 หน้า
- อัปเดตสถานะที่เคยมีสามประโยค กลายเป็นเอกสาร bullet ที่สรุปซ้ำจากสรุปอีกชั้น
- retrospective, รายงาน incident, design memo, kick-off deck และผลงานทุกอย่างที่ยืดยาวได้ ต่างก็ยาวขึ้น
- ต้นทุนการผลิตลดลงเกือบเป็นศูนย์ แต่ต้นทุนการอ่านไม่ได้ลดลง แถมยังสูงขึ้น
- ผู้อ่านต้องกรองบริบทที่ถูกสังเคราะห์ขึ้น เพื่อหาว่าเดิมทีเอกสารต้องการจะสื่ออะไร
- การเลือกทำเอกสารให้ยาวขึ้นของแต่ละคนดูสมเหตุสมผล และได้รับรางวัลแยกกันเป็นรายบุคคล
- ตาม Beyond the Steeper Curve: AI-Mediated Metacognitive Decoupling ผู้อ่านมีความมั่นใจต่อคำอธิบายที่ยาวกว่าซึ่งสร้างโดย AI มากขึ้น แม้จะไม่เกี่ยวกับความถูกต้องของคำอธิบายก็ตาม
- ผลลัพธ์คือ การหาสัญญาณในที่ทำงานยากกว่าเดิม
- checkpoint ถูกซ่อนไว้ในกองเอกสาร และผู้คนก็จมอยู่กับงานเอกสารแม้ตั้งใจจะทำให้ “กระชับ” จริง ๆ
- นี่คือ slop รูปแบบใหม่ที่มีต้นทุนสูงกว่า AI slop ที่แพร่ในตลาดสาธารณะ
- เพราะคนที่สร้างมันได้รับเงินเดือน
- งานที่เคยสอนวิจารณญาณถูกย้ายให้เครื่องมือทำ และบทบาทระดับเริ่มต้นที่เคยเกิดการเรียนรู้นั้นก็ลดลง เพราะเครื่องมือสามารถทำงานแทนได้
- ในหลายออฟฟิศ มีการเคลื่อนไหวมาก แต่ผลลัพธ์จริงที่การเคลื่อนไหวแบบเดิมเคยสร้างกลับน้อยลง
- การถกเถียงสาธารณะมักเน้นที่ AI slop ที่ไหลสู่ตลาดเปิด และงาน Generative AI and the market for creative content ของ University of Florida ก็พูดถึงกระแสนั้น
- แต่พลวัตแบบเดียวกันกำลังเกิดขึ้นภายในองค์กรด้วย
- เวลาถูกใช้ไปกับงานที่ไม่จำเป็นต้องใช้ AI, ผลลัพธ์ที่ไม่มีใครอ่าน, และกระบวนการที่เกิดขึ้นเพียงเพราะเครื่องมือทำมันได้ในต้นทุนต่ำ
- การคลี่สิ่งที่เมื่อก่อนแทบไม่ต้องพูด หรือถือเป็นเรื่องปกติอยู่แล้ว ออกมาเป็น deck เกิดขึ้นบ่อยขึ้น
วิธีรับมือ
- วินัยที่จำเป็นในสภาพแวดล้อมนี้กลับใกล้เคียงกับวิธีเดิม ๆ
- ใช้เครื่องมือเฉพาะในจุดที่สามารถตรวจสอบผลลัพธ์ที่มันสร้างได้อย่างแม่นยำเท่านั้น
- อย่าขอให้โมเดลช่วยยืนยันความถูกต้อง
- เครื่องมือจะเห็นด้วยกับทุกคน และการเห็นด้วยที่ไม่มีต้นทุนฝั่งผู้เห็นด้วยย่อมไม่มีคุณค่า
- งานที่ Generative AI เหมาะคือ งานที่ feedback เร็ว, ถูกประมาณ ๆ ก็พอ, และมนุษย์ยังเป็นผู้ตัดสินขั้นสุดท้าย
- ร่างบันทึกเบื้องต้น
- การสร้างตัวอย่าง
- การสรุปเอกสารที่ผู้อ่านสามารถตรวจสอบย้อนกลับได้หากต้องการ
- Generative AI Guidance ของ University of Illinois และ Ten simple rules for optimal and careful use of generative AI in science ของ PLOS Computational Biology แนะนำการใช้งานดังนี้
-
การระดมความคิด
-
การตรวจแก้
-
การจัดโครงสร้างความคิดของตนใหม่
-
การตรวจจับรูปแบบในข้อมูลที่ตนเข้าใจอยู่แล้ว
-
- ในการใช้งานที่แนะนำทั้งหมด มนุษย์เป็นผู้ให้วิจารณญาณ และเครื่องมือเป็นผู้ให้ throughput
- นี่เป็นจุดยืนที่เข้มกว่าการมีมนุษย์อยู่ในวงรอบแบบธรรมดา
- เครื่องมือควรอยู่นอกตัวงาน และมีส่วนร่วมเฉพาะเมื่อถูกเชิญเท่านั้น นอกนั้นควรเงียบไว้
- นี่สวนทางกับทิศทางที่ระบบแบบ agentic จำนวนมากกำลังมุ่งไป
- สำหรับบริษัท ความสามารถในการส่งมอบงานที่เชื่อถือได้ยังคงเป็นความได้เปรียบในการแข่งขัน
- ยิ่งคู่แข่งเปลี่ยนตัวเองให้เป็น pipeline ผลิตคอนเทนต์และหวังว่าลูกค้าจะไม่สังเกตเห็น มูลค่าของงานที่เชื่อถือได้ก็ยิ่งสูงขึ้น
- ปัญหาเริ่มปรากฏขึ้นบนผิวน้ำแล้ว
- Deloitte คืนค่าธรรมเนียมบางส่วนจากค่าจ้าง 440,000 ดอลลาร์ จากกรณีรายงานภาครัฐที่มี AI hallucination ปะปน
- ปัญหาถัดไปอาจเป็นระบบปฏิบัติการที่สร้างบนสเปกปลอมที่ AI แต่งขึ้น หรืออาจเป็นวิศวกรอาวุโสที่เพิ่งตระหนักว่าในปีที่ผ่านมา ตนเพียงตรวจรับงานในนามสำหรับสิ่งที่ตัวเองตรวจได้ไม่จริง
- บริษัทที่ทำงานได้อย่างถูกต้องจะอยู่ในตำแหน่งที่ตั้งราคางานนั้นได้
- บริษัทที่คว้านตัวเองจนกลวงจะได้รู้ว่าสิ่งที่ลูกค้าเคยยอมจ่ายเงินให้ ก็คือส่วนที่บริษัทเอาทิ้งไปนั่นเอง
- การเข้าใจผิดและใช้ AI ผิดวิธีในที่ทำงานกำลังแพร่หลาย
- ความเชี่ยวชาญถูกกดดันให้ส่งมอบเร็วขึ้น สร้างให้มากขึ้น ผสานเครื่องมือให้ลึกขึ้น และอย่าไปขัดเพื่อนร่วมงานที่ “ทำงานให้เสร็จ”
- ผลงานถูกกองพอกขึ้น แต่งานจริงไม่ได้สะสมตาม
- และที่ปลายอีกด้านของผลงานนั้น ลูกค้าอาจเปิดสิ่งที่ส่งมอบ อ่านรายการสรุป แล้วเลือกที่จะตรวจสอบด้วยตัวเอง
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ประเด็นเรื่อง งานเอกสารที่ยืดยาวเกินจำเป็น แบบที่เอกสาร requirement จากเดิมหน้าเดียวกลายเป็นสิบสองหน้านี่โดนใจมาก
มันทำให้นึกถึงตอนที่ต้องจงใจเขียนยืดเพื่อให้ถึงขั้นต่ำ 1000 คำในเรียงความสมัยมัธยม และตอนนี้การจัดรูปแบบแบบมืออาชีพ ความยาว และประโยคที่ชัดเจน ก็ไม่ได้เป็นสัญญาณของความใส่ใจและคุณภาพอีกต่อไปแล้ว
เพราะงั้น คอขวดของการเพิ่มผลิตภาพ ตอนนี้น่าจะยังเป็นคนที่ยังใส่ใจพอจะอ่านตรวจเองอยู่
ทุกวันนี้แม้แต่ เอกสารสเปก ยาว 10–30 หน้า ที่เต็มไปด้วยฟอร์แมตกับภาพ ASCII ก็มีโอกาสสูงมากที่จะเป็นแค่ไอเดียที่พูดส่ง ๆ ออกมา ดังนั้นต้องปรับตัวให้ชินกับการตีความมันแบบนั้น
ผู้จัดการคงเอาสิ่งที่ผมส่งไปให้แชตบอตหรือเอเจนต์ช่วยสรุปและประเมิน แต่ผมกลับส่งสรุปที่ทำเองตรง ๆ ไม่ได้
มันเลยเหมือนว่าข้อความของผมก็ต้องมี AI checker เหมือนระบบ ATS ตรวจเรซูเม่ และสุดท้ายก็จะกลายเป็น AI เขียนข้อความให้ AI อีกตัว parse ต่อ เป็นการสิ้นเปลืองพลังงานมหาศาล
ถ้ามีกติกา โครงสร้าง มาตรฐาน หรือขั้นตอนที่ตกลงร่วมกันไว้เพื่อการสื่อสารที่มีประสิทธิภาพกว่านี้ก็คงดี
เป็นผลผลิตของงานเขียนที่ยืดทุกอย่างให้ยาวเพื่อจะขึ้นอันดับบนผลการค้นหา
คนที่ส่งของแบบนั้นมาก็ไม่ได้ตามตรวจอะไรอยู่แล้ว เพราะงั้นปัญหามักหายไปเอง
สถานการณ์ที่บรรยายไว้นี่คล้ายประสบการณ์ผมมาก
บริษัทเรามีผู้จัดการหลายคนที่ไม่ได้เขียนโค้ดมาหลายปีแล้ว และสถาปนิกที่จ้างมาเมื่อ 18 เดือนก่อนก็ออกแบบทุกอย่างด้วย AI
สำหรับ senior developer มันชัดเจนมากว่าทุกอย่าง overengineered หนักมาก แต่เพราะเขาใช้ศัพท์ถูกหมด สำหรับผู้บริหารระดับบนเขาเลยดูมีความสามารถกว่าผู้จัดการอาวุโสคนอื่น และถ้ามีคนทักก็จะโต้กลับแบบโจมตีตัวบุคคล
ผ่านไปราว 6 เดือน คนหลายคนลาออก คนที่เหลือก็ทุ่มให้ AI เต็มตัว และตลอด 12 เดือนที่ผ่านมาเรากำลังสร้าง agentic workflow เพื่ออุดช่องว่างที่คนเก่ง ๆ ทิ้งไว้
ผลก็คือใน 18 เดือนที่ผ่านมาไม่มีอะไรที่มีคุณค่าออกสู่ตลาดเลย และหลังจากเผาค่า cloud computing ไปมหาศาลกับโซลูชันที่ออกแบบผิด ตอนนี้ก็กำลังลดต้นทุนด้วยการ freeze การจ้างงาน
ถ้าความคุ้มค่าทางเศรษฐกิจเปลี่ยนไปมาก มันก็แทบเหมือนการเอาเขื่อนออก ทำให้ส่วนที่เหลือของระบบรับแรงกดดันมากขึ้นมาก
ถ้าผู้นำองค์กรไม่เห็นผลข้างเคียงและความเสี่ยงที่อาจเกิดขึ้น ก็อาจเจ็บหนักได้
ทั้งที่เทคโนโลยีนี้ถูกขายว่าเป็นการพัฒนาแบบครอบจักรวาล แต่ผมคิดว่าเรากำลังจะเห็นบริษัทแนวนี้เพิ่มขึ้นแล้วพังกันไป
บริษัทที่รอดจะเผยแพร่วิธีฝึกม้าพยศตัวนี้ และในอุดมคติเราคงได้เรียนรู้อะไรบางอย่างในอนาคต
แต่ความคลั่งไคล้แบบไร้เดียงสาตอนนี้น่าตกใจมาก และคงจะมี กันยายนอันไม่มีที่สิ้นสุด ของผู้คนที่ตื่นเต้นเกินเหตุกับความสามารถ vibe coding ที่เพิ่งได้มาไหลเข้ามาอีกพักใหญ่
ที่ทำงานก่อนหน้านี้สองแห่ง ตอนนั้น vibe coding ยังไม่ค่อยใช้งานได้จริงด้วยซ้ำ แต่บางคนก็หมกมุ่นกับการใช้ LLM ทำให้ทุกอย่างบวมกว่าเดิมมาก จนแทบเป็นไปไม่ได้ที่จะได้คำตอบแบบใช่/ไม่ใช่กับคำถามใด ๆ
คำถามหนึ่งบรรทัดใน Slack ที่ใช้เวลาอ่าน 20 วินาที กลับได้คำตอบเป็นบทความเบลอ ๆ สองหน้าแบบไม่มีข้อสรุป และคำถามต่อเนื่องก็ยิ่งเสียเวลามากขึ้น
ที่ทำงานล่าสุด ผมเห็น PM ค่อย ๆ กลายเป็น vibe manager ของพวก vibe coder
เขาแทรกเข้ามาในบทสนทนาทางเทคนิค แล้วใช้ AI ชี้ทิศทางทุกขั้นตอน พอเราค้านก็กลายเป็นว่าต้องไปเถียงกับผลลัพธ์ที่ AI แปลให้คนที่ไม่เข้าใจหัวข้อเลย มันทรมานมาก
หลังจากนั้นก็ไม่เปิดให้คัดค้านอีก และกดดันว่าพวกเรากำลังถูก AI คุกคามงาน
ต่อมาก็บังคับให้ทุกคนทำ vibe coding และเฝ้าดูปริมาณการใช้ด้วย ขณะที่ PM คนนั้นเล่นทั้งบท PM, engineer และ architect ไปพร้อมกัน จนสร้าง ticket หลายใบสำหรับงานเดียวกันแต่ requirement ต่างกันสุดขั้ว
สุดท้ายคนหนึ่งในทีมก็ vibe code แบบหนึ่ง อีกคนก็ทำอีกแบบหนึ่ง
การเห็นทีมเล็ก 20 คนที่เคยทำกำไรเกือบ 100 ล้านดอลลาร์ต่อปี ถูกทำลายด้วยงานไร้ประโยชน์และไร้ความหมายมันทรมานมาก จนผมลาออกในที่สุด
ผมพยายามไม่ให้ตัวเองกลายเป็นคนมองโลกในแง่ร้ายกับการเปลี่ยนแปลงของวงการซอฟต์แวร์แบบนี้ แต่มันยากจริง ๆ
ผู้จัดการใช้ Claude ทั้งที่เข้าใจโดเมนไม่ครบ แล้วเอา คำแนะนำและข้อเสนอแบบผู้เชี่ยวชาญ ออกมาเสนอ ขณะที่คนที่ไม่ใช่สายเทคนิคในบริษัทหลายคนก็สร้างเครื่องมือซอฟต์แวร์ภายในที่จะปล่อยใช้ทั้งองค์กร หวังเอาเดโมพวกนี้ไปแลกการยอมรับและรางวัล
ผู้บริหารก็ตามคาด ประทับใจกับ proof of concept แบบนั้นและอนุมัติ
เพื่อนร่วมงานที่ขยันออกนอกหน้าบางคนทำเดโมให้ดูเหมือนผู้เชี่ยวชาญทั้งที่ไม่เข้าใจแก่นอะไรเลย และฝ่ายผู้นำก็รับเอาไป
ผมไม่รู้จะอธิบายปัญหานี้ยังไงมานานแล้ว แต่โพสต์นี้ชี้ได้ตรงมาก
แน่นอนว่าถ้ามี AI มันก็ช่วยให้สร้างได้น้อยลงอีก
ฟังดูเป็นสภาพแวดล้อมที่เป็นพิษสุด ๆ
ทีมที่สร้างซอฟต์แวร์คุณภาพดีด้วย LLM ได้อย่างมีผลิตภาพสูงสุด น่าจะใช้มันในลักษณะแบบนี้เป็นหลัก
intelligent autocomplete คือการใช้ LLM แบบดั้งเดิมที่ให้มันสร้างโค้ดโดยยังคงบริบทของโค้ดที่นักพัฒนากำลังทำอยู่ ทำให้มันเป็นเหมือนส่วนต่อของกระบวนการคิด ไม่ใช่การเอาความคิดไปจ้าง LLM ทำแทน
ในการ brainstorm มันช่วยขยายแนวคิด ไอเดีย และทิศทางที่ยังคลุมเครือออกไปในทางใหม่ ๆ เพื่อกระตุ้นความคิดสร้างสรรค์ได้
ในการแก้ปัญหา มันค่อนข้างมีประโยชน์กับการ debug เรื่องอย่าง package conflict, exception แปลก ๆ แบบสุ่ม, หรือ bug report และช่วยพาไปหาต้นตอได้เวลาที่ไม่มีเพื่อนร่วมงานนั่งข้าง ๆ
ใน code review มันจับบางอย่างที่คนพลาดได้บ้าง จึงคล้ายขั้น lint ที่ฉลาดขึ้นมากกว่า แต่ไม่ใช่การแทนที่ code review โดยคน
ใน proof of concept มันช่วยสร้างแนวทางหลายแบบสำหรับปัญหา เพื่อใช้เป็นแรงบันดาลใจให้วิธีแก้ที่ถูกสร้างอย่างรอบคอบกว่า
การใช้แบบนี้ช่วยเร่งความเร็วการพัฒนา โดยยังคงความรับผิดชอบที่นักพัฒนาต้องรู้ว่ากำลังสร้างอะไรและเพราะอะไร
ในทางกลับกัน ทีมที่ ทุ่มให้ agentic coding แบบสุดตัว ดูมีโอกาสสูงที่จะพังทั้งผลิตภัณฑ์และทีมโดยไม่ตั้งใจในระยะยาว
หลายครั้งล่าสุดที่ถามไป ผลลัพธ์ดูน่าเชื่อแบบสมบูรณ์แบบแต่ผิดหมด และบางทีก็ไม่ตรงประเด็นด้วยซ้ำ
ใน code review นั้น false positive มีมากท่วมท้น และผมก็ไม่ค่อยเห็นเหตุผลว่ามันจะดีขึ้นได้ยังไง
ถึงอย่างนั้นมันก็ยังอาจมีโอกาสช่วยได้ในทิศทางนี้
ส่วนตัวผมปิดมันไปเมื่อประมาณปีก่อนแล้วกลับไปใช้ autocomplete แบบเดิมของ JetBrains IDE
จากประสบการณ์ผม AI เดาได้ตรงกับที่ต้องการจริง ๆ ไม่ถึง 1%, มีประโยชน์ประมาณ 10%, ที่เหลือก็ผิดหรือกวนใจ
ความสามารถมาตรฐานของ IDE ที่ช่วยค้นหาหรือไล่ดู method, variable และอื่น ๆ ได้เร็ว กลับมีประโยชน์ต่อการแปลงความคิดเป็นโค้ดมากกว่าเยอะ
ทีมเราก็ลองใช้เครื่องมืออยู่บ้าง แต่สิ่งที่มันชี้ส่วนใหญ่ตื้นมากหรือไม่ใช่ปัญหาเลย
พอรีวิวโค้ดของสมาชิกทีมที่ฝีมือยังอ่อน มันกลับพลาดปัญหาที่ลึกกว่า ขณะที่ reviewer ที่เป็นคนจับได้ว่ามีการแก้ผิดกับปัญหาที่จริง ๆ ควรแก้ด้วยวิธีที่ดีกว่า
ผู้จัดการกลับใช้ผลนั้นเป็นหลักฐานยืนยันอคติของตัวเองว่าเราไม่รู้ว่ากำลังทำอะไร
เขาเอาผลลัพธ์จากเครื่องมือรีวิวโค้ดที่เต็มไปด้วยอีโมจิมาแปะในคอมเมนต์ PR แล้วพอเราแก้เรื่องจุกจิกก็โพสต์ว่า “code review รอบ 2”
ขวัญกำลังใจตกฮวบ และบางคนในทีมก็เลิกรีวิวไปเลยแล้วกด approve PR เฉย ๆ
ถ้าใช้เพื่อตรวจโค้ดตัวเองก็โอเค แต่ไม่ควรกลายเป็นข้อบังคับของกระบวนการ
จุดประสงค์ดั้งเดิมของ code review คือการลงทุนเวลาเพื่อช่วยกันพัฒนาให้ดีขึ้น และถ้าเอาสิ่งนั้นไปจ้างเครื่องทำ สัญญาทางสังคม ภายในทีมก็พัง
เมื่อ 2 ปีก่อนก็พูดกันว่าเป็นแค่ autocomplete บริสุทธิ์กับ Google ที่ดีขึ้น
คนที่มอง AI ในแง่ร้ายยังคงทำนายพลาดทุกปี แต่ก็ทำเหมือนไม่เคยพูดไว้ว่าระดับความสามารถที่ AI ทำได้ตอนนี้ไม่มีทางเกิดขึ้น
ด้วยเหตุผลบางอย่าง ซอฟต์แวร์เอนจิเนียริงดูจะเป็นสาขาที่เรื่องแบบนี้เกิดขึ้นได้ง่ายเป็นพิเศษ
วิศวกรซอฟต์แวร์จำนวนมากไม่เคยทำ engineering จริง ๆ ตลอดทั้งอาชีพ และในบริษัทใหญ่ยิ่งเป็นแบบนั้น
พวกเขาเข้าไปเป็นฟันเฟืองเล็ก ๆ ในเครื่องจักรใหญ่ เรียนรู้ภาษา configuration ที่ใครบางคนสร้างไว้เพื่อเอาไปเลื่อนตำแหน่ง จัดระเบียบและ refactor configuration นั้น แล้ว “แก้” ผลลัพธ์จาก internal framework อีกตัวด้วยการหมุนปุ่ม config ไปมา ผ่านไป 5 ปีก็ยังทำอยู่แบบเดิม
ในอุตสาหกรรมนี้ยังมี ตำแหน่งกึ่งวิศวกรรม อยู่มาก
มีทั้งคนที่ชอบทำงานกับคนจนเลิกเขียนโค้ด หรือคนที่หลงใหลงานด้านผลิตภัณฑ์กับงานของผู้ใช้ ซึ่งไปเติมเต็มตำแหน่ง .*M ในบริษัทใหญ่และเล็ก
ในบริษัทใหญ่ รถไฟเคลื่อนช้ามาก กว่า commit จะไปถึง production ก็กินเวลาหลายเดือน และ 6 เดือนก็ถือว่าปกติ
ระบบใหญ่และสำคัญหลายตัวนั้น โค้ดจากเอเจนต์ยังไปไม่ถึง production ด้วยซ้ำ
ดังนั้น AI จึงมาแทนงานบางตำแหน่งที่มีแต่เปลือก คนที่อยู่รายรอบโค้ดก็พลันสนุกกับ vibe coding และในบริษัทที่ขยับตัวช้า ผลลัพธ์ก็ยังไม่ระเบิด
ภายนอกเลยดูเหมือน บูมด้านผลิตภาพ
พออ่านประโยคที่ว่า “คนที่เขียนโค้ดไม่เป็นกำลังสร้างซอฟต์แวร์ และคนที่ไม่เคยออกแบบระบบข้อมูลกำลังออกแบบระบบข้อมูล” ก็ทำให้นึกถึง “วิธีปล่อยโปรเจกต์ในบริษัทเทคโนโลยีขนาดใหญ่”
โดยเฉพาะส่วนที่ว่า “การเปิดตัวเป็นโครงสร้างทางสังคมภายในบริษัท กล่าวอย่างเจาะจงคือ เมื่อคนสำคัญในบริษัทเชื่อว่าโปรเจกต์เปิดตัวแล้ว มันก็ถือว่าเปิดตัวแล้ว”
https://news.ycombinator.com/item?id=42111031
เป็นบทความที่ดี และยังทำให้เกิดการถกเถียงที่น่าสนใจว่าการ รักษาภาพลักษณ์ภายนอก และสิ่งที่คนมองเห็นนั้นสำคัญเสมอ และหลายครั้งก็สำคัญกว่าที่เราคิดมาก
ช่วงแรก ๆ ของการนำ AI เข้ามาใช้ในที่ทำงาน ผมสังเกตว่ามีเพื่อนร่วมงานบางคนใช้เทคโนโลยีนี้เพื่อแสดง ความกระตือรือร้นเกินพอดี
ทุกสัปดาห์จะมี TOD ใหม่ ไอเดีย refactor ใหม่ วิธีเอา algorithm ใหม่วาว ๆ มาแก้ปัญหาเก่า ๆ
ตอนนี้ปรากฏการณ์นี้หนักขึ้นเป็นสองเท่า เพราะการพยายามดูแอ็กทีฟมากขึ้นไปรวมกับความกลัวว่าจะถูก AI เลิกจ้าง จนคนเริ่มสร้างวิธีแก้ก่อนที่ปัญหาจะถูกนิยามชัดเจนด้วยซ้ำ
อย่างเช่นผมได้รับมอบหมายให้ศึกษาปัญหาด้าน architecture บางอย่างทั้งบริษัท และคิดว่าถ้าเสนอวิธีแก้ที่แข็งแรงน่าจะได้รับการยอมรับ แต่สายไปแล้ว
เพราะเด็กฝึกงานหาวิธีแก้ได้ก่อนและเขียน TOD ไว้แล้ว ตอนนี้ผมเลยเหนื่อยเกินกว่าจะไปแข่ง
เมื่อวานผมใช้เวลาส่วนใหญ่ไปกับการลบและแทนที่โค้ดที่ LLM สร้าง
โดยรวมแล้วความช่วยเหลือจาก LLM ก็ดี แต่รอบนี้มันสร้าง โค้ด thread บ้าคลั่งออกมาเต็มไปหมด และทำให้แอปเริ่ม crash เป็นครั้งแรกในรอบหลายปี
แอปของผมไม่ crash
มันอาจมีปัญหาอื่นได้เยอะ แต่ crash ไม่ใช่หนึ่งในนั้น และผมก็จุกจิกกับเรื่องนี้มาก
จากกฎประสบการณ์ของผม แทบไม่มีเหตุผลเลยที่จะ dispatch ไป thread ใหม่
หลายครั้งผมก็ปล่อยให้ OS SDK ทำแบบนั้นและเคารพการตัดสินใจนั้น แต่แทบไม่มีกรณีที่การ spawn worker thread เองจะคุ้มกับความเจ็บปวดในการ debug
มันอาจไม่จริงกับทุกประเภทของแอปพลิเคชัน แต่กับแอปที่ผมทำมันจริง
LLM ชอบ thread และคงเป็นเพราะโค้ดฝึกจำนวนมากมาจากพวกคนเห่อเทคโนโลยีใหม่ที่โพสต์อะไรแวววาวไว้เต็มไปหมด
สุดท้ายพอผมคว้านเอาโค้ดหน้าจอออกแล้วใส่โค้ดที่เขียนเองเข้าไป ประสิทธิภาพก็ดีขึ้นอย่างชัดเจนและอาการ crash ก็หาย
บทเรียนคือ ผู้ซื้อพึงระวัง
ผมอินกับช่วงที่พูดว่าลังเลว่าจะคุยกับคนที่เห็นได้ชัดว่าก๊อปจากโมเดลมาทั้งดุ้นดีไหม
ผมเองก็เคยสนุกเล็ก ๆ กับการตอบคนพวกนั้นกลับแบบเดียวกัน
คือเอา output จาก AI ของเขาไปแปะใส่ AI ของผม แล้วก็เอาคำตอบจาก AI ของผมกลับไปแปะอีกที
กลายเป็นมนุษย์สองคนทำตัวเหมือนเครื่องจักร เพื่อให้เครื่องจักรสองตัว คอสเพลย์ เป็นมนุษย์ที่กำลังสื่อสารกัน
มันอลังการมาก
ผมถามง่าย ๆ ถึงทิศทางแบบ senior ของผมว่าทำไมสำหรับ proof of concept ระหว่างเพื่อน เราควรปล่อยขึ้น Vercel เร็ว ๆ มากกว่าจะ overengineer ด้วย AWS แต่เขากลับส่ง แผนภาพมั่วซั่วจาก AI มาให้
เขาติดกรอบมากเกินไปว่าพี่ชายใช้ AWS และตัวเองก็อยากมีสายอาชีพทางนั้น เลยเอาความคิดไปจ้าง AI ทำแทนที่จะคิดเองว่าทำไมแนวทางนั้นถึงเหมาะกับ proof of concept ของเพื่อน
เขาถามว่าผมได้อ่านไหม ผมเลยตอบว่าใช้ AI ช่วยสรุปอ่านแล้ว แต่ไม่ได้ตอบมัน จากนั้นบทสนทนาก็จบอย่างรวดเร็ว
การบอกว่า “มันไม่ช่วยผู้เชี่ยวชาญ” นี่ค่อนข้างมองสั้นไปหน่อย
ต่อให้เก่งแค่ไหน ทุกคนก็ยังมีด้านที่อ่อน หรือด้านน่าเบื่อที่สามารถทำให้เป็นอัตโนมัติได้
สำหรับผม สิ่งที่เคยเป็นอุปสรรคต่ออาชีพในอดีตคือการจัดระเบียบงานจำนวนมากพร้อมกัน การสื่อสารการเปลี่ยนแปลงอย่างมีประสิทธิภาพไปทั่วทั้งองค์กร และการจัดการเอกสารกับ ticket ในที่อย่าง Jira
ตอนนี้สิ่งเหล่านั้นไม่ใช่เรื่องให้กังวลอีกต่อไปแล้ว และ ประสิทธิภาพที่เพิ่มขึ้น ในส่วนนั้นมหาศาลมาก
ในงานแกนหลักที่ผมเก่ง มันไม่ได้ช่วยมากไปกว่าพิมพ์ให้เร็วขึ้นมากนัก แต่แค่นั้นก็ดีมากแล้ว
ถ้าให้ทำสิ่งที่ผมไม่ถนัด มันมักทำได้ดีกว่าผม หรืออย่างน้อยก็พาไปสู่การตัดสินใจที่มีข้อมูลมากกว่าของผม
ผมเห็นด้วยกับประโยคที่ว่า “อย่าขอให้โมเดลช่วยยืนยันอะไร เครื่องมือจะเห็นด้วยกับทุกคน”
ถ้าผมพูดลอย ๆ ว่ามีอะไรบางอย่างผิด LLM ก็จะหาทางหาข้อบกพร่องให้จนได้ แม้แต่ในโค้ดที่ผมรู้ว่าโอเค
ปัญหาคือ LLM มักตีความตรงตัวเกินไป
ต่อให้สั่งให้วางแผน LLM ก็ยังไม่เคยประสบความสำเร็จในการ ออกแบบระบบทั้งระบบอย่างอัตโนมัติ
ถ้าให้ LLM สร้างโค้ดแล้วถามยืนยันหลายแบบ มันก็หาปัญหาที่มีอยู่จริงเจอได้บ่อยเหมือนกัน