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

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

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

งานเดินหน้าเร็วมาก แต่ตอบไม่ได้ว่าโค้ดเปลี่ยนอะไรไปบ้าง

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

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

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

ประเด็นนี้ตรงกับมุมมองที่เราเคยเขียนถึงไว้ใน โค้ดที่ AI เขียนออกมาเร็วกว่าที่คนตรวจทัน

เหมือนกลับมาอยู่บ้านที่รก หลังไปนอนโรงแรมมาครึ่งปี

การกลับมาเขียนโค้ดด้วยมือค่อนข้างจำเจ ซึ่งเขาก็เล่าออกมาตรงๆ แต่ก็บอกว่าให้ความรู้สึกน่าพอใจมากเช่นกัน

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

เขาเปรียบเทียบสิ่งที่ได้รับกลับมาไว้อย่างน่าสนใจว่า เหมือนการได้กลับเข้าบ้านตัวเองที่รกไปหน่อย หลังจากไปนอนโรงแรมมาครึ่งปี

บ้านมันรกไปหน่อย งานยังมีให้ทำอีกเยอะ แต่ที่นี่คือบ้านของเรา เรารู้ว่าอะไรอยู่ตรงไหน

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

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

กลับไปอ่านโค้ดเก่าของตัวเอง แล้วพบว่ายังไม่ลืมวิธีเขียน

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

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

ประเด็นน่าสนใจในช่องคอมเมนต์

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

เราเคยเขียนถึงคำถามทำนองนี้มาแล้วในตอน มีบริษัทไหนเลิกใช้ AI แล้วกลับไปเขียนโค้ดเองบ้าง

วางรากฐานด้วยมือก่อน แล้วค่อยให้ AI ต่อยอด

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

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

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

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

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

ฝั่งที่ไม่คิดกลับไปเขียนงานซ้ำซากด้วยมืออีกแล้ว

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

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

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

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

ปัญหาอาจไม่ได้อยู่ที่การเขียนโค้ดด้วยมือ แต่อยู่ที่ว่าเรามองระบบอย่างไร

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

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

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

คำถามสำคัญที่กระทู้นี้ยังไม่มีคำตอบ

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

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

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

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

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

สี่แนวทางที่นำไปปรับใช้ได้จริง

การแลกเปลี่ยนในกระทู้นี้ไม่ได้ให้ข้อสรุปเพียงหนึ่งเดียว แต่มีแนวทางและข้อคิดที่เป็นประโยชน์หลายข้อ:

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

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

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

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

สิ่งที่กระทู้นี้ไม่ได้ตัดสินแทนคุณ

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

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

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

---

ที่มา: กระทู้ I'm going back to coding by hand จาก Hacker News