• คำกล่าวอ้างว่า 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) มักขยายมายาคติที่เกินจริง ดังนั้นจะเมินเฉยไปก็ได้

ยังไม่มีความคิดเห็น

ยังไม่มีความคิดเห็น