- คำกล่าวอ้างว่า AI จะเพิ่มผลิตภาพของวิศวกรได้ 10–100 เท่า นั้นไม่สมจริง
- เมื่อลองใช้เครื่องมือเขียนโค้ดด้วย AI อย่างจริงจัง จะพบว่า การเพิ่มประสิทธิภาพมีขอบเขตจำกัด และการพุ่งขึ้นของผลิตภาพจะเกิดขึ้นชั่วคราวเฉพาะกับงานที่ซ้ำ ๆ และเรียบง่ายเท่านั้น
- คอขวดของการพัฒนาซอฟต์แวร์ (เช่น code review, การทำงานร่วมกัน, การวางแผน) ไม่สามารถแก้ได้ด้วย AI และเป็นไปไม่ได้ที่จะทำให้งานทั้งหมดเร็วขึ้น 10 เท่า
- มายาคติของวิศวกร 10 เท่า เกิดจากแรงจูงใจหลายแบบ เช่น การบิดเบือนตัวเลข ผู้มีส่วนได้ส่วนเสียในอุตสาหกรรม หรือการกระตุ้นความกังวลภายในองค์กร
- การรักษาวิธีการพัฒนาและความสนุกในแบบของตัวเองไว้ จะนำไปสู่ผลลัพธ์ที่ดีกว่าในระยะยาว และสร้างวัฒนธรรมองค์กรที่ดีต่อสุขภาพมากกว่า
ความกังขาต่อมายาคติวิศวกร AI 10 เท่า
ความกังวลเรื่องผลิตภาพและประสบการณ์ใช้งานเครื่องมือ AI จริง
- ใน LinkedIn, Twitter และที่อื่น ๆ มีการเผยแพร่แนวคิดว่า AI จะเพิ่มผลิตภาพของวิศวกรได้ 10–100 เท่า ทำให้นักพัฒนาจำนวนมากรู้สึก กังวลว่าจะตามไม่ทัน
- ผู้เขียนเองก็ได้นำเอเจนต์สร้างโค้ดด้วย AI (Claude Code, Cursor, Roo Code, Zed ฯลฯ) ไปใช้จริงหลากหลายรูปแบบ แต่พบว่าแม้จะ สะดวกกับงานง่าย ๆ ที่ทำซ้ำ ก็ไม่ได้สร้าง การเปลี่ยนแปลงขั้นพื้นฐาน ในงานจริงที่ซับซ้อน
- ใน JavaScript (โดยเฉพาะ React) สามารถเขียนโค้ดซ้ำ ๆ แบบ boilerplate ได้เร็ว
- แต่สำหรับมาตรฐานเฉพาะของ codebase ภายในหรือไลบรารีแปลกเฉพาะทาง AI มักตามไม่ทัน
- ภาษาหรือเครื่องมืออย่าง Terraform นั้น AI ไม่ค่อยคุ้นเคย จึงให้ผลลัพธ์ด้อยลง
- ปัญหา hallucination อาจทำให้มันสร้างไลบรารีที่ไม่มีอยู่จริง และถึงขั้นก่อให้เกิด ช่องโหว่ด้านความปลอดภัย
- ความสามารถของ AI ในการเข้าใจบริบทยังมีข้อจำกัด ยิ่ง codebase จริงมีความซับซ้อนมาก ก็ยิ่งเกิด การพรอมป์ซ้ำ ความผิดพลาด และการเสียเวลา
- สุดท้ายแล้ว ผู้เขียนจึงใช้ AI กับสคริปต์ขนาดเล็กหรืองานที่ไม่สำคัญต่อแกนหลัก และยังคงจัดการงานที่ซับซ้อนหรือสำคัญด้วยตัวเอง
ปัญหาของการวัดผลิตภาพในการพัฒนาซอฟต์แวร์เป็นตัวเลข
- คำกล่าวอ้างว่าผลิตภาพจะเพิ่มขึ้น 10–100 เท่า ด้วย AI เป็นตัวเลขที่ห่างไกลจากความจริง
- ผลิตภาพ 10x, 100x ไม่ได้หมายถึงเพียงจำนวนบรรทัดโค้ด แต่หมายถึงว่า งานที่ใช้เวลา 3 เดือน (รวมทั้งการพัฒนาทั้งหมด, code review, QA ฯลฯ) ต้องเสร็จภายใน 1.5 สัปดาห์
- การพัฒนาซอฟต์แวร์มีคอขวดหลากหลาย เช่น การวางแผน การประเมิน story point การแก้บั๊ก code review การรอ deploy การทดสอบ และ QA
- ทุกขั้นตอนเหล่านี้ต้อง เร็วขึ้น 10 เท่าในสัดส่วนเดียวกัน จึงจะไปถึงเป้าหมายได้
- ในความเป็นจริง เวลาที่ใช้กับการเขียนโค้ดเองมีไม่มาก และเวลาจำนวนมากถูกใช้ไปกับ ความเข้าใจ การออกแบบ การตรวจทาน และการสื่อสาร
- ในทางปฏิบัติ code review, การทำงานร่วมกัน, การสื่อสาร, QA ฯลฯ ไม่สามารถย่นเวลาได้ด้วย AI
- คอขวดของงานวิศวกรรมจริง ๆ อยู่ที่ คน กระบวนการ และการสื่อสาร
- LLM (โมเดลภาษาขนาดใหญ่) ช่วยลดเวลาในการพิมพ์บนคีย์บอร์ดได้ แต่เวลาในการดูแลคุณภาพโค้ด การทดสอบ และการรีวิวยังคงต้องใช้เหมือนเดิม
- แม้ AI จะช่วยเพิ่มความเร็วในการเขียนโค้ดได้ชั่วคราว แต่ด้วยอัตราความผิดพลาดที่เพิ่มขึ้น มาตรฐานโค้ดที่ไม่เพียงพอ และการต้องพรอมป์ใหม่ จึง ไม่ส่งผลชี้ขาดต่อการเพิ่มผลิตภาพโดยรวม
- ผลิตภาพ 10 เท่าเป็นเป้าหมายที่ในทางปฏิบัติ แทบเป็นไปไม่ได้
ความจริงและข้อจำกัดของวิศวกร 10 เท่า
- สำหรับการมีอยู่ของ "วิศวกร 10 เท่า" ผู้เขียนมองว่าเป็นไปได้แบบ ชั่วคราวและมีข้อจำกัด
- เหตุผลใหญ่ที่สุดคือความสามารถในการ ป้องกันงานที่ไม่จำเป็น (เช่น ป้องกันการพัฒนาที่ไม่จำเป็นตั้งแต่ขั้นวางแผน ปรับปรุงประสบการณ์การพัฒนา ทำเอกสาร ฯลฯ) ซึ่งสะสมขึ้นมาได้
- แต่ไม่ใช่ว่าวิศวกรทุกคนจะเจอสถานการณ์แบบนี้อยู่เสมอ
- วิศวกรที่โดดเด่นมาก อาจป้องกันงานที่ไม่จำเป็น หรือยกระดับประสิทธิภาพทั้งองค์กรผ่านการปรับปรุงระบบได้ แต่ในทางปฏิบัติ แทบไม่มีกรณีที่สร้างผลงานได้มากกว่า 10 เท่าอย่างสม่ำเสมอ
- เครื่องมือเขียนโค้ดด้วย AI ไม่ได้ช่วยมากนักในการป้องกันงานที่ไม่จำเป็น
- ตรงกันข้าม บางครั้งคำแนะนำของ AI อาจทำให้ ลงมือสร้างเกินความจำเป็น หรือเสนอ architecture ที่ผิดพลาด
- การเขียนโค้ดได้เร็ว ไม่ได้แปลว่าเป็นวิศวกรที่ดีกว่าเสมอไป
ฉากหลังและแรงจูงใจของมายาคติ 10x AI
คำกล่าวอ้างเรื่อง "ผลิตภาพเพิ่มขึ้น 10 เท่า" ส่วนใหญ่มาจากปัจจัยต่อไปนี้
- วิศวกรที่มีเจตนาดีแต่ประเมินผิดพลาด
- การใช้เครื่องมือ AI อาจทำให้เกิดประสบการณ์ ประสิทธิภาพพุ่งสูงแบบฉับพลัน ในช่วงสั้น ๆ (เช่น เขียนกฎ custom ของ ESLint อัตโนมัติ)
- แต่เมื่อทำงานประเภทนี้ซ้ำไปเรื่อย ๆ ความต่างด้านผลิตภาพจะลดลงอย่างรวดเร็ว
- ความตื่นเต้นทางเทคนิคหรือการปรับตัวเข้ากับสภาพแวดล้อมใหม่ อาจทำให้ช่วงแรกเกิดภาพลวงตาว่ามีประสิทธิภาพสูงเกินจริง
- แรงจูงใจและผู้มีส่วนได้ส่วนเสีย
- ผู้ก่อตั้ง AI startup นักลงทุน ฯลฯ มัก อ้างตัวเลขเกินจริงเพื่อความสำเร็จทางธุรกิจ
- วิศวกรหรือผู้บริหารเองก็อาจพูดถึงผลิตภาพที่เกินจริงเพื่อ ให้สอดคล้องกับความคาดหวังภายในองค์กร
- เจตนาร้าย
- ผู้บริหารบางคนเผยแพร่คำกล่าวเกินจริงด้วย เจตนาจะสร้างความกังวลให้วิศวกร เพื่อป้องกันความปั่นป่วนภายในองค์กร เช่น การย้ายงานหรือการขอขึ้นเงินเดือน
- ความกลัวว่า AI จะทำให้ทุกคนถูกแทนที่ได้ง่าย เป็นสิ่งที่ถูกวนกลับมาซ้ำเป็นระยะ (คล้ายกับข้อถกเถียงเรื่อง coding bootcamp ในอดีต)
ผลลัพธ์ของ AI ในโอเพนซอร์สและโปรเจกต์จริง
- กรณีศึกษาจริงเกี่ยวกับการเพิ่มผลิตภาพด้วย AI ส่วนใหญ่มี ช่องว่างระหว่างผู้เขียนกับวิศวกรที่อ้างว่าผลิตภาพดีขึ้น
- ตัวอย่างการใช้เครื่องมือ AI ที่พิสูจน์โดยวิศวกรจริงโดยตรง มักแสดงภาพที่ สมจริงและไม่โอ้อวด
- ผลลัพธ์ของการใช้ AI ในโปรเจกต์โอเพนซอร์สจำนวนมาก มักออกมาเป็น ต่ำกว่าความคาดหวัง หรือถึงขั้นล้มเหลว
- ใน เดโมสาธารณะหรือกรณีของวิศวกรจริง AI อาจดูเหมือนเวทมนตร์ได้เป็นครั้งคราว แต่โดยมากแล้วก็ไม่ได้ต่างจาก "เครื่องสร้างข้อความ" แบบเดิมมากนัก
คุณค่าที่สำคัญกว่าคำว่า "ผลิตภาพ" - รักษาสไตล์การพัฒนาในแบบของตัวเอง
- แม้การใช้ AI จะช่วยให้เขียนโค้ดได้เร็วขึ้นในบางครั้ง แต่ผู้เขียนยังคงให้ความสำคัญกับ ความสนุกของการเขียนโค้ด มากกว่า
- หาก ไม่ชอบหรือไม่รู้สึกสนุกกับการเขียนโค้ดด้วย AI ก็ไม่เป็นไรที่จะยอมแลกกับผลิตภาพบางส่วน
- แม้จะต้องยอมรับความไม่มีประสิทธิภาพอยู่บ้าง การทำงานด้วย วิธีที่เหมาะกับตัวเอง ก็สร้างผลลัพธ์ที่ดีและดีต่อสุขภาพในระยะยาวมากกว่า
- เมื่อทำงานอย่างมีความสุข ก็จะมี ความสามารถในการแก้ปัญหา การออกแบบ และการทำงานร่วมกับเพื่อนร่วมงาน ที่ดีกว่า
- ความสนุกและภาวะจดจ่อมีความสำคัญต่อผลิตภาพระยะยาวและคุณภาพโค้ดมากกว่า และหากฝืนไล่ตามแต่ผลิตภาพอย่างเดียว ความเสี่ยงต่อภาวะหมดไฟก็จะสูงขึ้น
- ในทางกลับกัน หาก การเขียนโค้ดด้วย AI สนุกและช่วยได้จริง ก็สามารถนำมาใช้เชิงรุกได้
คำแนะนำเพื่อวัฒนธรรมองค์กรที่ดีต่อสุขภาพ
- เมื่อนำเครื่องมือ AI เข้ามาใช้ การสร้างความคาดหวังที่ไม่สมจริงและความกังวลให้วิศวกรทุกคน เป็นสิ่งที่เป็นโทษต่อผลิตภาพขององค์กร
- การหมกมุ่นกับการเร่งผลิตภาพให้สูงสุด จะนำไปสู่ คุณภาพที่ลดลง codebase ที่เสื่อมลง และความสูญเสียระยะยาว
- การให้ความเป็นอิสระและความไว้วางใจแก่วิศวกรอย่างเพียงพอ และให้ การใช้ AI เป็นทางเลือกตามวิธีที่แต่ละคนเห็นว่าเหมาะสม เป็นแนวทางที่พึงประสงค์
- ในระดับองค์กร ควรเปิดโอกาสให้ใช้ AI ได้ แต่ บรรยากาศที่รับประกันความเป็นอิสระ เป็นสิ่งสำคัญ
- หาก LLM หรือความก้าวหน้าด้าน AI coding สามารถให้ผลิตภาพเพิ่มขึ้น 10 เท่าได้จริง นักพัฒนาก็จะค้นหาและนำมาใช้กันเองตามธรรมชาติ
บทสรุป
- การปฏิวัติวิศวกร 10 เท่าจาก AI นั้นใกล้เคียงกับการเป็นมายาคติ และไม่ได้มีสูตรลับที่พลาดไปในโลกความจริง
- ความเชื่อมั่นในทักษะและวิธีการของตัวเอง คือสิ่งสำคัญที่สุด
- SNS (โดยเฉพาะ LinkedIn, Twitter) มักขยายมายาคติที่เกินจริง ดังนั้นจะเมินเฉยไปก็ได้
10 ความคิดเห็น
มีคนที่ตีความ 10x ว่าหมายถึง 10 เท่าจริงๆ ด้วยเหรอ ผมนึกว่าเป็นคำพูดเกินจริงเพื่อการตลาด/PR ตัวเองอยู่แล้ว แต่พอมีคนเอาจริงเอาจังกับมันก็ทำเอางงเหมือนกัน
แม้จะไม่ถึงขั้น 10x แต่ก็มีองค์กรไม่น้อยที่มีความเชื่ออย่างจริงจังกับแนวคิดแบบ Nx อยู่ พวกเขาคาดหวังว่าจะทดแทนต้นทุนแรงงานด้วยค่าใช้จ่ายด้าน AI และสร้างผลงานได้มากกว่านั้น…
ที่ว่าเป็นความเข้าใจผิดลอยๆ แบบไร้เหตุผลก็ไม่ใช่ เพราะถ้า PM อยากลองทำอะไรอย่าง PoC ง่ายๆ หรือเครื่องมือสำหรับงานซ้ำๆ มันก็ทำออกมาได้อย่างรวดเร็วจริงๆ
ดังนั้นถามว่ามีนักพัฒนาที่เชื่อเรื่องนี้ไหม… ผมคิดว่าบรรยากาศในอุตสาหกรรมตอนนี้แพร่หลายมากพอที่จะทำให้คนรู้สึกกังวลได้เต็มที่ ขึ้นอยู่กับสถานการณ์ที่แต่ละคนเผชิญอยู่
ผมคิดว่าการถกเถียงกันอย่างจริงจังแบบนี้เป็นสิ่งจำเป็น อย่างน้อยก็เพื่อการสื่อสารกับคนที่ไม่ได้อยู่สายพัฒนาและกับหัวหน้าองค์กร
ไม่ได้ปฏิเสธอยู่แล้วว่าสิ่งเหล่านี้ช่วยเพิ่มผลิตภาพได้ แน่นอนว่า (ในระดับของ AI ณ เวลาปัจจุบัน) ผมคิดว่าคำว่า 10x นั้นฟังไม่สมเหตุสมผลอยู่แล้ว แต่เพราะเนื้อหาของโพสต์ต้นฉบับคือการตั้งใจพูดว่า “เพิ่มได้ไม่ถึง 10 เท่า” เลยรู้สึกแปลกใจมากจึงเขียนคอมเมนต์นี้ขึ้นมา เพียงแต่ก็ดูเหมือนว่าการใช้ถ้อยคำของผมจะไม่ค่อยดีนัก
ผมคิดว่าตามที่คุณบอกว่าเรื่องประสิทธิภาพของ AI เป็นคำพูดเกินจริงเพื่อการตลาด/การโปรโมตตัวเอง บทความนั้นเองก็น่าจะมีการพูดเกินจริงอยู่บ้างเล็กน้อยเช่นกัน。
ดังนั้น ประเด็นที่ว่าเคยมีคนตีความ 10x ว่าคือ 10 เท่าจริง ๆ ด้วยหรือ ดูจะให้ความรู้สึกเหมือนจับผิดคำพูด จึงอาจเป็นสาเหตุที่ทำให้หลายคนรู้สึกไม่พอใจก็ได้ครับ
ดูเหมือนว่าคุณจะตอบคอมเมนต์โดยไม่ได้อ่านต้นฉบับนะครับ เพราะในต้นฉบับไม่ได้จริงจังขนาดนั้นเลย...
ส่วนที่ผู้เขียนบอกว่า DataTube.tv ซึ่งเป็นบริการค้นหาไอเดียวิดีโอไวรัลบน YouTube ที่ตนพัฒนาขึ้น มีการใช้งานมากกว่า Viewtrap "หลายสิบเท่า" ก็คงเป็นคำพูดเกินจริงเพื่อการตลาด/โปรโมตตัวเองตามปกติใช่ไหมครับ?
ไม่แน่ใจว่าเพราะเป็นโลกออนไลน์หรือปกติคุณก็เป็นแบบนี้อยู่แล้ว แต่คอมเมนต์ส่วนใหญ่เขียนออกมาในมุมมองเชิงวิจารณ์ อยากให้ลองมองด้วยมุมมองที่เปิดกว้างกว่านี้อีกนิดนะครับ
ผมคิดว่าถ้ามีทั้งกระแสอวย AI เกินจริง ก็ย่อมมีด้านตรงข้ามด้วย เลยไม่ได้มีความเห็นอะไรกับเนื้อหาหลักมากนัก...
คอมเมนต์นี้อย่างกับ โอ้โห; น่ากลัวเลยนะที่ถึงขั้นไปค้นโพสต์เก่า ๆ แล้วกลับมาคอมเมนต์ใหม่ เพิ่งสมัครวันนี้เองแท้ ๆ
พอเห็นว่าคุณมาแสดงความคิดเห็น ผมลองย้อนดูประวัติของตัวเองแล้วก็รู้สึกว่าไม่น่าจะมีคอมเมนต์ไหนที่น่าอายเลยสักอัน การมองด้วยสายตาเชิงวิพากษ์นี่เป็นปัญหาเหรอครับ? หรือว่าต้องไม่แสดงความคิดเห็นอะไรเลยแบบคุณ ถึงจะใช้ชีวิตได้ดี...
หือ? ก็ถึงขั้นแปลงตัวเลข 10 เท่าเป็นจำนวนเดือนไว้แล้วนะ... ถ้าคุณรู้สึกขัดใจกับสำนวนที่ว่าเคร่งเครียดเกินไป ก็พอเข้าใจได้ แต่คำว่า "หลายสิบเท่า" ของ Datatube เป็นตัวเลขเชิงปริมาณนะ เอาเถอะ ถึงยังไงตอนนี้ก็ไม่ได้ดำเนินการอยู่แล้ว...
ความเห็นจาก Hacker News
ผมไม่เข้าใจว่าทำไมมีแค่วงการวิศวกรรมซอฟต์แวร์ที่หมกมุ่นกับมายาคติเรื่อง "ผลิตภาพ 10 เท่า (10x)" ขนาดนี้ ในวิศวกรรมเครื่องกล ไฟฟ้า โยธา หรือเคมี แทบไม่มีแนวคิดแบบนี้
วิศวกรที่ยอดเยี่ยมคือคนที่ลดความเสี่ยงและออกแบบระบบได้ภายใต้ข้อจำกัดที่หลากหลาย
การออกแบบคือกระบวนการทำความเข้าใจโดเมนผ่านโมเดล และมองให้ออกว่าขอบเขตที่โมเดลใช้ได้จริงกับข้อจำกัดของมันอยู่ตรงไหน
ไม่มีอะไรที่เรียกว่า "10x" มีแต่การรับผิดชอบต่อระบบที่ดีเท่านั้น
ถ้ามีวิศวกรซอฟต์แวร์แบบ "10x" จริง ก็น่าจะเป็นคนที่ป้องกันเหตุการณ์อย่างข้อมูลรั่วไหลได้ และผมอยากเห็นเหตุการณ์แบบนั้นลดลง 10 เท่ามากกว่า
ผมเองก็เห็นด้วยกับบทความนี้หลายส่วน
ผมเป็นแฟนตัวยงของการพัฒนาด้วยเครื่องมือ AI แต่คำกล่าวอ้างเรื่องผลิตภาพ 10x ไม่ค่อยน่าเชื่อ
LLM ทำให้งานบางอย่างอย่างการพิมพ์โค้ดเร็วขึ้น 2~5 เท่าจริง แต่ก็เป็นแค่ส่วนหนึ่งของงานทั้งหมด
ในความเป็นจริง วิศวกรจำนวนมากน่าจะเห็นว่างานบางประเภทเร็วขึ้น 20~50% แต่ก็เห็นด้วยว่านั่นไม่ได้แปลว่าผลิตภาพรวมจะเพิ่ม 20% หรือพุ่งเป็น 10x
แน่นอนว่าคนที่ใช้ AI เก่งจริงอาจรู้สึกว่าผลิตภาพเพิ่มมากกว่า 0.2x แต่เพราะความซับซ้อนโดยเนื้อแท้ของการพัฒนาซอฟต์แวร์ 10x จึงแทบไม่สมจริงสำหรับคนส่วนใหญ่
เวลาใช้ AI ผมต้องคอยเฝ้าอยู่ข้าง ๆ ตลอด เลยไม่ค่อยรู้สึกว่ามันมีประสิทธิภาพสูง
บางครั้งข้อเสนอของ copilot ก็ตรงกับที่ผมคิดเป๊ะจนทึ่ง แต่โดยรวมแล้วมันไม่ได้เหมือนนักพัฒนาจูเนียร์ฝีมือดีเท่าไร กลับให้ความรู้สึกเหมือน "ซีเนียร์ที่เมาอยู่" มากกว่าว่าพูดไม่ค่อยฟัง
โค้ดที่สร้างมาครึ่งหนึ่งคอมไพล์ยังไม่ผ่าน และถึงคอมไพล์ผ่านก็ใช่ว่าจะทำงานถูกต้อง
จากประสบการณ์ของผม AI ไม่ได้เพิ่มผลิตภาพแบบมหาศาลในงานสร้างของใหม่ (creation) แต่ช่วยมากในเรื่องการสำรวจ (discovery), การเรียนรู้, การแก้จุดที่ตัน, และการเขียนโค้ดซ้ำ ๆ
แต่การเปลี่ยนแปลงที่แท้จริงเกิดกับโปรเจกต์ข้างมากกว่า
เมื่อก่อนผมเหนื่อยเกินกว่าจะลงเวลากับงานเสริมได้ แต่ตอนนี้ถึงจะยังไม่ใช่โค้ดที่สมบูรณ์แบบ ก็สามารถทำไอเดียให้เป็นจริงได้เร็วขึ้นและใช้พลังใจน้อยลง
ทักษะด้าน AI engineering ก็ทดลองได้อย่างอิสระโดยไม่ต้องมีข้อจำกัดเรื่องเดดไลน์ ความเป็นส่วนตัว หรือเครื่องมือ
แม้แต่คนที่ถูกเรียกว่า "วิศวกร 10x" เอง ก็น่าจะมองว่าผลิตภาพที่ AI เพิ่มให้นั้นมีไม่มาก
นักพัฒนาที่เก่งที่สุดเท่าที่ผมรู้จักมีความสามารถหลักสองอย่าง: ความจำมหาศาลจนจำรายละเอียดของทุกภาษา/ไลบรารีได้ และความคิดสร้างสรรค์กับทักษะแก้ปัญหาระดับปาฏิหาริย์
สิ่งที่น่าทึ่งคือถึงจะไม่รู้สูตรหรือทฤษฎี ก็ยังไปถึงวิธีแก้ที่แปลกใหม่ สะอาด และเหมาะกับปัญหานั้นที่สุดได้
ถ้าจับคู่เขียนโปรแกรมกับ AI เพื่อไปให้ถึงวิธีแก้แบบเดียวกัน AI ต้องลองผิดลองถูกไม่รู้จบ และกลับกลายเป็นว่าทำให้มนุษย์อัจฉริยะช้าลง
แต่เพราะสเปกตรัมความสามารถกว้างมาก สำหรับผมเอง AI ก็ทำให้เกิดการเพิ่มผลิตภาพ 10 เท่าได้จริง
ผมไม่ได้เรียนสายซอฟต์แวร์ และเป็นพวกเพอร์เฟ็กชันนิสต์จนพัฒนาช้ามาก แต่ AI ช่วยให้ผมลองทำเวอร์ชันแรกที่แย่ ๆ ได้เร็ว จึงมีประโยชน์มากกับการทำให้ไอเดียเกิดขึ้นจริง
ผมก็สนับสนุนผู้ช่วย AI สำหรับการพัฒนา และคิดว่าบางสถานการณ์อาจมีความเร็วเพิ่ม 2~10 เท่าได้จริง
แต่คำว่า "ผลิตภาพ 10x" ส่วนใหญ่มักถูกใช้เกินจริงในความหมายว่ากระบวนการพัฒนาทั้งหมดตั้งแต่ต้นจนจบเร็วขึ้น 10 เท่า
ตามความเป็นจริง หลายส่วนของกระบวนการพัฒนาทั้งหมดที่ไม่ใช่การเขียนโค้ด ไม่ได้เร็วขึ้น 10 เท่า
ถึงอย่างนั้น ในสภาพแวดล้อมที่เล็กมากหรือทำงานคนเดียว ก็ข้ามขั้นตอนจุกจิกได้เยอะ เลยเกิดความเร็วที่เพิ่มขึ้นอย่างมีนัยสำคัญจริง
ในบริบทนี้จึงกลายเป็นยุคที่ทีมเล็กและนักพัฒนาเดี่ยวมีความสามารถในการแข่งขันขึ้นมาอย่างกะทันหัน
ขอบคุณคอมเมนต์ของ Simon
คอมเมนต์นี้แหละที่ให้ความรู้สึกว่าได้อ่านบทความจริง ๆ
ผมยอมรับว่าในบางงานที่เฉพาะทางกับภาษา หรือเครื่องมือใดเครื่องมือหนึ่ง ผลิตภาพเพิ่มขึ้น 2 เท่ากำลังเกิดขึ้นจริง
ผมฝันเรื่องการทำให้การพัฒนาซอฟต์แวร์เป็นอัตโนมัติมาหลายสิบปี และรู้สึกว่า LLM มาทำให้ฝันนั้นเป็นจริงในวิธีที่ต่างออกไปโดยสิ้นเชิง
เครื่องมืออย่าง CASE, UML, IDE ในอดีตเคยสัญญาว่าจะ "ทำให้เราโฟกัสกับตรรกะจริง ๆ ได้" แต่ LLM แค่สร้างโค้ดที่รันได้ทันทีจากภาษาธรรมชาติ
นักพัฒนาจำนวนมากจึงกังวลว่าพิธีผ่านด่านแบบเดิมกำลังพังลง และตัวเองจะถูกทิ้งไว้ข้างหลังในโลกใหม่ (อาการ imposter syndrome)
ตอนนี้เราจึงต้องย้อนถามอีกครั้งว่าซอฟต์แวร์เอ็นจิเนียริงคืออะไรกันแน่
LLM คือรูปแบบสุดท้ายของ CASE tool ยุคก่อน แต่ทั้งหมดนี้เกิดขึ้นเร็วเกินไป สับสน และสั่นสะเทือนมาก
แม้แต่คนที่ไม่รู้ "ภาษาศักดิ์สิทธิ์" ของวิศวกรซอฟต์แวร์ก็เริ่มมีพลัง และทำให้วิศวกรจำนวนมากต้องถามตัวเองในระดับพื้นฐานว่า "ตอนนี้ฉันกำลังทำอะไรกันแน่?"
ตอนนี้ผมเพิ่งเข้าใจแล้วว่าศิลปินรู้สึกอย่างไรตอนเห็น stable diffusion
โค้ดที่ AI สร้างสุดท้ายแล้วมักผิด บั๊กเยอะ และเต็มไปด้วยธรรมเนียมประหลาด ๆ หรือของที่ไม่จำเป็น
การแก้ปัญหาพวกนี้ทั้งหมดกลับใช้เวลาพอ ๆ กับการทำเอง
ต่อให้ลองหลายโมเดลหรือขัดเกลาพรอมต์ ก็ยังรู้สึกว่าโค้ดคุณภาพสูงที่ผมต้องการจริง ๆ ยังเอื้อมไม่ถึง
เหมือนกับ stable diffusion ที่คนไม่ใส่ใจอาจไม่รู้ว่ามีอะไรแปลกอยู่ คนที่ไม่ชำนาญเรื่อง AI code ก็อาจไม่รู้ว่ามันมีปัญหา
ไม่นานมานี้ผมเห็นโค้ดที่เพื่อนร่วมงานเขียนแล้วรู้สึกแปลก ๆ พอไปดูจริง ๆ ก็พบว่าใช้ debugger ก็ไม่ได้และเต็มไปด้วยปัญหา เพื่อนร่วมงานยอมรับว่า "ก็แค่เขียนไปตามความรู้สึก"
เวลามองโลกช่วงนี้ ผมรู้สึกว่าทุนกำลังทำลายแรงงานอย่างต่อเนื่อง
ค่าจ้างต่ำ สภาพการทำงานแย่ การเฝ้าระวัง แรงกดดันจากตัวชี้วัด บริษัทไร้จริยธรรม สัญญาระยะสั้น — ความเป็นจริงที่แรงงานส่วนใหญ่เผชิญกำลังเลวร้ายลงเรื่อย ๆ
ที่ผ่านมาเราถูกปกป้องมากเกินไปจนไม่ค่อยสัมผัสความจริงนี้ แต่ตอนนี้พวกเราก็เริ่มต้องเผชิญอนาคตที่ไม่มั่นคงเหมือนกัน
ในที่สุด "วิศวกรรมซอฟต์แวร์" ก็จะกลายเป็นงานคอยแก้ vibe (ความรู้สึก)
หลายอาชีพถูกซอฟต์แวร์แทนที่ได้ แต่ก็มีความจริงอยู่ว่าผู้จัดการมักไม่อยากจ้าง SWE ถ้ายังพิสูจน์คุณค่าที่ตรวจสอบได้ไม่ได้
พอมี AI ผู้จัดการก็จะผลิตโค้ดจำนวนมากที่ตัวเองไม่เข้าใจ และอีก 3 ปีต่อมาเมื่อมันพังหมด ก็จะเรียก SWE กลับมาแก้
สุดท้ายอาจยิ่งเกิดงานยาก/มูลค่าสูงสำหรับการแก้ "ปัญหาที่ AI แก้ไม่ได้" มากขึ้นด้วยซ้ำ
LLM สร้างโค้ดได้เลยโดยไม่ต้องมีโมเดลหรือไดอะแกรมอย่างเป็นทางการ
แต่ผมกลับอยากให้ AI สร้างงานออกแบบทางการหรือไดอะแกรมพวกนี้ให้มากกว่า
เพราะเครื่องมือแบบนั้นช่วยให้เข้าใจโค้ดและทำให้งานออกแบบชัดเจนขึ้น
ผมอยากให้ AI ช่วยได้ถึงระดับนี้ด้วย
คอขวดของการพัฒนาซอฟต์แวร์ไม่ใช่ความเร็วในการพิมพ์หรือการสร้าง แต่เป็นการตรวจสอบและความเข้าใจ
ต่อให้ LLM ทำงานได้สมบูรณ์แบบโดยไม่มีเรื่องเพ้อเจ้อ (hallucination) นักพัฒนาที่มีความรับผิดชอบก็ยังต้องตรวจโค้ดทีละส่วนอยู่ดี
เพราะมนุษย์ไม่ได้เข้าใจโค้ดได้เร็วขึ้น 10 เท่า ในทางปฏิบัติจึงอาจต้องใช้เวลานานกว่าเดิมเพื่อไล่ดูโค้ดที่สร้างอัตโนมัติและถอดความตั้งใจที่ซ่อนอยู่
คำว่า "ผลิตภาพ 10x" จะใช้ได้ก็ต่อเมื่อส่งผลลัพธ์ออกไปทั้งอย่างนั้นโดยไม่ตรวจโค้ด หรือใช้กับโค้ดง่ายมาก ๆ ที่ข้อผิดพลาดไม่สำคัญเท่านั้น
สำหรับซอฟต์แวร์ production ที่ความผิดพลาดเท่ากับหายนะจริง ๆ คอขวดยังคือขีดความสามารถในการรับรู้ของมนุษย์ และ LLM ก็เพียงย้ายภาระจากการเขียนไปเป็นการตรวจ จนสุดท้ายอาจติดลบต่อผลิตภาพโดยรวมด้วยซ้ำ
การถกเถียงนี้ทำให้รู้สึกว่านักพัฒนาโดยเฉลี่ยกำลังเปิดเผยระดับผลิตภาพของตัวเอง
ถ้าเข้าใจเทคโนโลยีของโปรเจกต์และแบ่งงานได้ดี ก็สามารถคาดเดาความซับซ้อนของโค้ดล่วงหน้าและมอบงานให้ AI เป็นหน่วยที่เหมาะสมได้
AI ไม่ใช่เวทมนตร์ และมันมีเพดานของความซับซ้อนที่พอจะเขียนได้
ถ้าเข้าใจทั้งขีดจำกัดนั้นและเทคโนโลยีของโปรเจกต์ที่ตัวเองทำดีพอ ก็สามารถแยกคอมโพเนนต์ให้อยู่ต่ำกว่าขีดจำกัดนั้นแล้วสั่ง AI ได้
วิธีนี้ใช้ได้ผลดีทีเดียว
นี่แทบจะเป็นการพูดซ้ำความหมายเดิม
ถ้าทำให้คำสั่งง่ายพอจน AI ทำงานได้ดี มันก็ย่อมทำงานได้ดีอยู่แล้ว
แต่ในความเป็นจริง เราต้องป้อนคำสั่งให้ AI แบบละเอียดจนเกินไป และถึงอย่างนั้นก็ยังต้องตรวจผลลัพธ์ซ้ำอย่างเข้มงวดเพราะเชื่อถือไม่ได้
บางทีแค่การย่อยงานเล็ก ๆ แล้วอธิบายให้ AI ฟัง ก็อาจยุ่งยากกว่าการเขียนโค้ดเองเสียอีก
ถ้า AI โชคดีตอบถูกตั้งแต่ครั้งแรกก็มีประสิทธิภาพอยู่ แต่ความจริงคือมักต้องแก้วนไปแก้วนมา หรือสุดท้ายก็ต้องกลับมาทำใหม่ทั้งหมด เสียทั้งเวลาและแรง
โค้ดที่ AI จัดรูปมาสวยเป็นระเบียบ แต่จริง ๆ แล้วผิด มักเป็นสิ่งที่อันตรายมาก
ส่วนที่ยากและกินเวลาจริง ๆ คือการออกแบบส่วนที่ซับซ้อน
ส่วนเล็กน้อยแค่ป้อนข้อมูลก็พอ แต่ส่วนที่ซับซ้อนต่างหากคือสิ่งที่ใช้เวลาจริง
ข้างใต้คอมเมนต์นี้เหมือนมีนัยว่า "คิดว่าตัวเองเก่งกว่าค่าเฉลี่ยใช่ไหม?"
มันอาจตรงกันข้ามก็ได้
นักพัฒนาที่ฝีมือไม่ดีต่างหากที่ยื่น auto PR แบบไร้ความหมาย แล้วตื่นเต้นกับผลลัพธ์ที่ AI ทำให้ ขณะที่นักพัฒนาที่มาตรฐานสูงอาจไม่รู้สึกทึ่งกับมันเลย
ในทางปฏิบัติ ถ้าไม่ได้ร่วมงานด้วยตัวเอง ก็แยกไม่ออกว่าใครน่าเชื่อถือจริง ผมจึงขอวางตัวเป็นกลาง
ทั้ง AI และมนุษย์ต่างก็มีขีดจำกัด
สุดท้ายสิ่งที่ต้องมีคือการบริหารโปรเจกต์แบบน่าเบื่อแต่จำเป็น
ถ้ามี requirement, การออกแบบ และข้อมูลที่เพียงพอ พร้อมแตกงานเป็นหน่วยเล็ก ๆ ก็อาจสั่ง AI ว่า "ไปทำ GitHub issue #42 ให้หน่อย" แล้วนั่งดูทีวีรอได้
แต่ถ้าบอกว่า "ช่วยสร้าง facebook ให้หน่อย" มันก็ย่อมพังตั้งแต่ต้น
อีกด้านหนึ่งที่ AI ช่วยมากคือการหาบั๊ก
ผมทำงานด้านการจำลองเชิงตัวเลขเป็นหลัก และเคยติดปัญหาอยู่หลายวันเพราะสมการสเกลเพี้ยนจากวงเล็บหายไปไม่กี่ตัว พออธิบายไฟล์กับอาการให้ chatgpt ฟัง มันก็หาเหตุได้อย่างรวดเร็ว
บางครั้ง AI ทำหน้าที่ชี้จุดที่ผมมองข้ามไปได้อย่างชัดเจน
มันไม่ได้สร้างนักพัฒนา 10x แต่ถ้าใช้เป็นก็ให้ผลเชิงบวกมหาศาลได้จริง
ผมก็คล้ายกัน
ให้ AI สร้างโค้ดยังเฉย ๆ แต่เรื่องดีบักนี่คือการกระโดดด้านผลิตภาพจริง ๆ
มันเหมือน "rubber duck" ที่ฉลาดมาก
(ในมุมมองนักพัฒนาเป็นงานอดิเรก) LLM ทำให้การพัฒนาง่ายขึ้นมากในตอนดึก ๆ ที่สมองไม่ค่อยทำงานแล้ว
ผมเองก็ประหยัดเวลาไปนับไม่ถ้วนเพราะ AI
สำหรับผมมันอยู่ตรงกลางระหว่าง 10 เท่ากับอนันต์อะไรประมาณนั้น
ผมไม่คิดว่าตัวเองเป็นวิศวกร 10x
เหตุผลที่ผมทำงานได้มีประสิทธิภาพกว่าคนอื่นในบริษัท คือผมออกแบบระบบและไม่ทำตาม ticket ที่คลุมเครือในเชิงธุรกิจแบบตรงตัว
เหตุที่ AI ลดความซับซ้อนให้เพื่อนร่วมงานของผมไม่ได้ ก็เพราะมันเปลี่ยนนิสัยที่ชอบทำทุกอย่างให้ซับซ้อนตั้งแต่ต้นไม่ได้
AI ไม่ได้แก้ปัญหานี้ให้ด้วย
เงินเดือนผมที่บริษัทไม่ได้มากกว่าเพื่อนร่วมงาน 2 เท่า ก็เลยคิดแบบนั้น
การเอาเครื่องมือ AI เข้ามาก็ไม่ได้เปลี่ยนความจริงนี้
บทความนี้ตั้งมาตรฐาน "10x" ที่สูงเกินจริงก่อน แล้วค่อยบันทึกความพยายามส่วนตัวของผู้เขียนที่จะข้ามมันไป
เพราะแบบนั้นผมเลยคิดว่าผู้เขียนแบ่งคนสนับสนุน AI ออกเป็นสามกลุ่ม: คนที่เข้าใจผิด คนที่ขายของ และผู้จัดการแย่ ๆ ที่เล่นกับความกังวลของคนอื่น
ส่วนตัวผมมองว่าการบ่นเรื่อง "hallucination" เป็นสัญญาณอย่างหนึ่ง
ผมคิดว่าการพูดถึง hallucination จำเป็นมาก
การถกเถียงเรื่อง LLM ตอนนี้สุดโต่งเกินไปมาก (ฝั่งหนึ่งบอกว่าไร้ประโยชน์โดยสิ้นเชิง อีกฝั่งบอกว่าจะมาแทนนักพัฒนา)
ตัวอย่างเช่น Claude 4 Sonnet เคยตอบผิดว่าข้อมูลเกี่ยวกับการคอมไพล์ของ clang ใน Godbolt นั้น Godbolt เป็นฝ่ายผิด
ถึงอย่างนั้น โดยรวมทั้งเซสชันนั้นก็ช่วยผมได้มาก ดังนั้นแค่ต้องจำไว้ว่าควรวิจารณ์ผลลัพธ์อยู่เสมอ
Hallucination มีอยู่จริง และเราต้องระวังผลลัพธ์ตลอดเวลา
ขอบคุณที่มาแสดงความคิดเห็น และบทความเกี่ยวกับ AI ที่คุณเขียนก็ช่วยให้ผมรับมือกับ imposter syndrome ได้มาก
ในบทความนั้น ผมจัดหมวดเฉพาะคนที่อ้างว่า "สำเร็จแบบ 10x ติด ๆ กัน" เท่านั้น ไม่ได้เหมารวมคนสนับสนุน AI ทุกคน
ผมสงสัยว่าคุณเจอวิธีที่ทำให้ไม่มี hallucination เลยหรือยัง
โดยเฉพาะพวก Terraform นั้น LLM ยังชอบสร้างพร็อพเพอร์ตีที่ไม่มีอยู่จริง และใน JS ถ้าใช้ไลบรารีที่ไม่ค่อยมีคนใช้ก็ยังมักหลงผิดอยู่ดี
ถ้าการบ่นเรื่อง "hallucination" เป็นสัญญาณ ความคิดแบบนั้นก็เป็นสัญญาณเหมือนกัน…
(คำโต้แย้งสั้น ๆ)
มาตรฐาน 10x นี้เป็นการตลาดเกินจริงที่ใช้กันทั้งอุตสาหกรรม
ตัวอย่าง: คำกล่าวอ้าง 10x ของ Sam Altman
โฆษณาผลิตภาพของ Cursor AI
นักพัฒนา 10x ที่เสริมพลังด้วย AI
สมมติว่าคนที่ทำเว็บแอปไม่เป็น ต้องใช้เวลา 6 สัปดาห์ เรียนวันละ 4 ชั่วโมง (120 ชั่วโมง) กว่าจะทำได้สักตัว
แต่ถ้าใช้ AI อย่าง Claude code แล้วทำเว็บแอปเดียวกันได้ในสุดสัปดาห์สองวัน (12 ชั่วโมง) แบบนี้ผลิตภาพก็เพิ่มขึ้น 10 เท่า
นี่ใกล้เคียงกับสิ่งที่เกิดขึ้นจริงกับผม
เมื่อก่อนผมขาดแรงจูงใจหรือพลังงานเลยทำไม่ได้ แต่ตอนนี้เพราะ AI ผมทำสิ่งนั้นให้เสร็จในสุดสัปดาห์ได้
แต่วิธีแรกมีองค์ประกอบของการเรียนรู้ ซึ่งอาจช่วยได้เวลาต้องกลับมาเปลี่ยนอะไรในครั้งต่อไป
ที่จริงถ้าสั่ง AI อย่าง Claude Code ให้ scaffold เว็บแอปที่ไม่ใช่ React มันมักเละมาก
คนที่ไม่มีประสบการณ์ทำแอปคงไม่ได้สร้างแอปคุณภาพดีให้เสร็จง่าย ๆ ในสุดสัปดาห์เดียว
แค่ผู้ใช้คนแรกล็อกอิน แอปก็อาจพังทันที
ถ้ามองระยะยาว ผมคิดว่าเลขคณิตแบบนั้นไม่สมเหตุสมผล
ตอนแรกอาจทำแอปได้เร็วด้วย LLM แต่ความสามารถในการบำรุงรักษาจะค่อย ๆ แย่ลง และสุดท้ายก็ถึงจุดที่ระบบซับซ้อนเกินกว่าจะใส่ไว้ใน "context window" แล้วจัดการได้
ผลลัพธ์สุดท้ายคือผลิตภาพอาจเข้าใกล้ 0 ด้วยซ้ำ
นั่นเท่ากับเอาสมองและประสบการณ์การเรียนรู้ไปจ้างข้างนอกทั้งหมด จึงมีแอปก็จริง แต่แทบไม่มีการเติบโตหรือการเรียนรู้อะไรเกิดขึ้น
คุณคิดจะ deploy มันเลยหรือ?
ในความเป็นจริงมันไม่ใช่สิ่งที่เทียบกันได้ตรง ๆ
แม้แต่ผลลัพธ์ของนักพัฒนา 1x ยังวัดยาก และการเอาไปคูณยิ่งไร้ความหมายกว่าเดิม
ผมรู้สึกว่า AI เพิ่ม "ผลิตภาพของ side quest" ได้มาก
สิ่งที่ก่อนหน้านี้ขี้เกียจทำแล้วผลัดมาตลอด (ทำ mockup, เขียนเทสต์, แยกไลบรารี, ทำเอกสาร ฯลฯ) เหมาะกับ AI มาก
ถึงมันจะไม่ได้ย่นเวลาสร้างฟีเจอร์โดยตรง แต่ถ้านับรวมงานประกอบพวกนี้ ผลลัพธ์สุดท้ายก็เข้าใกล้ความสมบูรณ์มากขึ้นอีกนิด
ผมหวังว่างานประกอบเหล่านี้จะช่วยลดเวลาหาบั๊กในอนาคตได้
(ประสบการณ์ส่วนตัว)
นี่เป็นเรื่องเฉพาะเคสของผม แต่ที่บริษัทเรา โค้ดทดสอบที่ทำด้วย LLM มักผูกติดกับ implementation code มากเกินไป
มีการใช้แพตเทิร์นอย่าง test spy มากเกินควร
ผลคือมีเทสต์กำกวมจำนวนมากที่ตรวจแค่รายละเอียดภายใน implementation แทนที่จะดูพฤติกรรมจากมุมผู้ใช้
เทสต์พังบ่อยเกินไปเวลามีการเปลี่ยน implementation จนสุดท้ายเทสต์กลายเป็นภาระมากกว่าผลิตภาพ
เรื่องนี้ไม่ใช่ปัญหาของ LLM อย่างเดียว แต่เป็นการที่นักพัฒนาซึ่งเดิมก็เขียนเทสต์ไม่ดีอยู่แล้ว ถูก LLM ทำให้ปัญหายิ่งหนักขึ้น
สำหรับนักพัฒนาที่ขาดประสบการณ์กับ TDD และโค้ดทดสอบที่ออกแบบมาดี LLM จะยิ่งขยาย anti-pattern แบบนี้
ผมชอบคำว่า "ผลิตภาพของ side quest"
AI ไม่ได้ให้ความรู้สึกแบบ "death by a thousand cuts" แต่เหมือน "ชีวิตใหม่ที่ประกอบจากพลาสเตอร์พันแผลนับพันชิ้น"
เห็นด้วยกับแนวคิด "side quest"
ที่จริงความเปลี่ยนแปลงใหญ่สำหรับผมคือ ได้สร้างเครื่องมือหรือฟีเจอร์ที่เดิมถ้าไม่มี AI ผมก็คงไม่ทำเลย
มันไม่ใช่แค่ประหยัดเวลา 2 สัปดาห์ แต่เป็นการทำให้เกิดผลลัพธ์ที่เดิมไม่มีอยู่เลย
ความคาดหวังต่อ LLM สูงเกินความเป็นจริง แต่ในหลายสถานการณ์มันมีประโยชน์มากจริง ๆ
ถ้ามองในระดับ "zoom level" ยิ่งแยกงานจากแบบหยาบ ๆ อย่าง "vibe coding" ลงมาเป็นขั้น ๆ จนถึงระดับ "ช่วยเขียนฟังก์ชันนี้ให้หน่อย" ผลลัพธ์ก็ยิ่งดีขึ้นมาก
นอกจากการสร้างโค้ดแล้ว มันยังมีประสิทธิภาพกับงานอื่น เช่น การเรียนรู้เทคโนโลยีใหม่
ถ้าบทบาทของผมมีประชุมเยอะหรือเป็นงานผู้จัดการมากขึ้น ประโยชน์จาก LLM ก็จะลดลง
ต่อไปผมคิดว่า LLM น่าจะถูกนำไปใช้กับ workflow ของ PR, การจัดระเบียบ commit, การเรียงลำดับใหม่ เป็นต้นด้วย
พูดตามตรง แค่ใช้มันเพื่อโต้แย้งพวกวิศวกรที่เอาแต่พูดบ่อย ๆ ว่า 'ไม่ได้' หรือ 'เป็นไปไม่ได้ที่จะทำให้เกิดขึ้นจริง' ก็น่าจะให้ผลแบบ X10 ได้แล้วล่ะ
เพราะผมเห็นภาพที่พอปฏิบัติต่อคนที่ไม่ใช่นักพัฒนาเหมือนเป็นพวกไม่รู้อะไร ก็จะพูดว่าเป็นไปไม่ได้ไว้ก่อนแบบนั้นอยู่บ่อย ๆ.