คำถามเดียวในห้องถามตอบ Ask HN บน Hacker News เว็บบอร์ดของคนสายเทคโนโลยีทั่วโลก ดึงคนเข้ามาตอบเกือบ 90 คอมเมนต์ คำถามนั้นสั้นมาก คือมีบริษัทไหนบ้างที่เลิกให้ AI เขียนโค้ด แล้วถอยกลับไปให้คนเขียนเองทั้งหมด

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

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

รื้อใหม่แล้วรกอีกรอบ

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

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

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

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

ใช้ AI แค่ตรวจ ไม่ให้เขียน

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

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

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

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

มีบริษัทไหนแบน compiler บ้าง

อีกฝั่งไม่ได้ตอบคำถาม แต่ถามกลับสามข้อ

• มีบริษัทไหนแบนโปรแกรมช่วยเขียนโค้ดที่มีตัวเติมคำและตัวจับผิดในตัว แล้วกลับไปพิมพ์โค้ดในไฟล์เปล่าๆ บ้าง
• มีบริษัทไหนแบน compiler ตัวแปลงโค้ดที่คนเขียนให้เป็นภาษาที่เครื่องรันได้ แล้วกลับไปเขียนภาษาเครื่องเองบ้าง
• มีบริษัทไหนแบน Stack Overflow เว็บถามตอบปัญหาโค้ดที่คนเขียนโค้ดทั่วโลกเข้าไปหาคำตอบ แล้วกลับไปงมเองทุกข้อบ้าง

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

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

ผ่านมาสี่ปี หลักฐานยังมีน้อย

มุมมองอีกด้านหนึ่งมาจากบล็อก Why I remain a skeptic ของ Joshua Barretto นักพัฒนาที่เลือกไม่ใช้ LLM กับงานที่เขาให้ความสำคัญจริงๆ เลยสักชิ้น

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

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

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

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

ทั้งหมดนี้เป็นจุดยืนของคนคนเดียวที่เลือกไม่ใช้มาตั้งแต่ต้น ไม่ใช่ผลสำรวจของวงการ น้ำหนักของมันอยู่ที่คำถามเรื่องการวัดผล มากกว่าอยู่ที่ข้อสรุปว่าใครควรใช้หรือไม่ควรใช้

งานไหนคุมเอง งานไหนปล่อยได้

สองฝั่งในเธรดเถียงกันว่าจะใช้ทั้งหมดหรือไม่เอาเลย แต่พอฟังเสียงที่เล่าจากงานจริง เส้นแบ่งกลับไม่ได้อยู่ที่ตัวเครื่องมือ มันอยู่ที่ว่างานชิ้นนั้นพังแล้วเกิดอะไรขึ้น

งานที่คนในเธรดเลือกคุมเอง

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

งานที่ปล่อยให้ AI ทำแล้วยังไม่มีใครในเธรดเสียดาย

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

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

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

สัญญาณว่าเริ่มคุมไม่อยู่

เรื่องเล่าในเธรดมีรูปแบบที่ซ้ำกันอยู่สามอย่าง และทั้งสามอย่างสังเกตได้ก่อนที่ความเสียหายจะโผล่ออกมาเป็นบั๊ก

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

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

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

---

ที่มา:

• กระทู้ Ask HN: Do you know of any company that went back to hand-written code? จาก Hacker News
• บทความ Why I remain a skeptic จาก blog.jsbarretto.com