เหตุผลที่ผมตัดสินใจลดการใช้ LLM

 (zed.dev)
20 คะแนน โดย GN⁺ 2025-07-03 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Alberto Fortin วิศวกรซอฟต์แวร์ที่มีประสบการณ์ 15 ปี เคยคาดหวังสูงกับการ นำ LLM (Large Language Model) มาใช้ แต่ใน สภาพแวดล้อมโปรดักชัน จริงกลับพบข้อจำกัดหลายอย่าง
  • ระหว่างการสร้างโครงสร้างพื้นฐานขึ้นใหม่ด้วย Go และ ClickHouse เขาได้สัมผัสทั้ง ด้านจริงและภาพลวงของ AI และรู้สึกว่าแม้โมเดลจะพัฒนาขึ้น แต่ก็ยัง แก้ปัญหาแกนหลักได้ไม่ดีพอ
  • เขาชี้ให้เห็นว่ามี ภาพฝันเรื่องการเพิ่มผลิตภาพ อยู่มาก แต่ในความเป็นจริงกลับมี บั๊กและปัญหาที่ไม่คาดคิด เพิ่มขึ้น
  • เขาเน้นบทเรียนว่าให้มอง LLM เป็น ผู้ช่วย (assistant) และ การออกแบบกับการตัดสินใจสำคัญ นักพัฒนายังต้องทำเอง
  • "AI นั้นน่าปฏิวัติ แต่ยังไม่สมบูรณ์ จึงยังต้องมี การใช้งานอย่างสมดุลและการมองความเป็นจริงอย่างเยือกเย็น"

ประสบการณ์และการทบทวนเรื่อง LLM ของ Alberto Fortin

  • Alberto Fortin วิศวกรซอฟต์แวร์ ผู้มีประสบการณ์ 15 ปี ได้นำ LLM มาใช้กับงานพัฒนาอย่างจริงจังด้วยความคาดหวังสูง
  • ระหว่างการสร้างโครงสร้างพื้นฐานขึ้นใหม่ด้วย Go และ ClickHouse เขาเจอทั้งความท้าทายและข้อจำกัดหลายอย่าง จนเขียนบล็อกโพสต์ว่าด้วยช่องว่างระหว่าง AI กับการพัฒนาซอฟต์แวร์จริง
  • ต่อมาเขายังได้วิเคราะห์เพิ่มเติมเพื่อตรวจสอบว่าโมเดลรุ่นใหม่อย่าง Claude Opus 4 แก้ปัญหาเหล่านี้ได้หรือไม่
  • ประสบการณ์ของ Alberto มอบทั้ง บทเรียนเชิงปฏิบัติ ให้กับวิศวกรที่กำลังพิจารณานำ LLM ไปใช้ในงานจริง รวมถึงมุมมองที่สมจริงว่าตรงไหนเครื่องมือมีคุณค่า และตรงไหนคือขีดจำกัดของมัน

คำพูดสำคัญของ Alberto เกี่ยวกับประสบการณ์ใช้ LLM

> "ผมแปลกใจมากที่ปัญหาไม่ได้มีแค่การทำงานผิดพลาดหรือฟีเจอร์ใช้ไม่ได้ ในฐานะนักพัฒนาที่ต้องดูแลโค้ดนี้ต่อไปอีกหลายปี โค้ดต้อง สะอาดพอ"

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

> "เมื่อส่งเอาต์พุตข้อผิดพลาดให้ LLM มันก็จะให้คำตอบใหม่กลับมา แต่ก็มักทำให้บางอย่างซับซ้อนขึ้น หรือ ทำส่วนอื่นพัง บ่อยมาก"

การตระหนักถึงความคาดหวังที่มากเกินไปต่อ LLM

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

> "มันทำให้เรารู้สึกว่า ผลิตภาพในการพัฒนา อาจเพิ่มขึ้นได้ถึง 10 เท่า แต่ในความจริง เรามักตั้งความคาดหวังแบบนั้นเร็วเกินไป"

การนิยามบทบาทและความคาดหวังใหม่

> "ความแตกต่างที่ใหญ่ที่สุดคือการเปลี่ยนมุมมองต่อบทบาท ผมคือ สถาปนิกและนักพัฒนาระดับซีเนียร์ ส่วน LLM เป็นเพียงผู้ช่วยของผม ผมเป็นคนวางแผน และ LLM รับบทสนับสนุน"

> "หลังจาก สูญเสียความไว้วางใจ ผมก็ไม่มอบหมายฟีเจอร์สำคัญให้มันอีก ใช้มันแค่ในงานหน่วยเล็ก ๆ อย่างรีแฟกเตอร์ริง"

> "ผมเริ่มแก้บั๊กด้วยตัวเอง เมื่อคุณเข้าใจโค้ดเบสอย่างถ่องแท้ การแก้ปัญหาด้วยตัวเองจะ เร็วและมีประสิทธิภาพกว่ามาก"

มุมมองที่เปลี่ยนไปต่อ LLM และคำแนะนำ

> "ในฐานะนักพัฒนาระดับซีเนียร์ ผมยอมรับกับตัวเองว่าการนำ LLM มาใช้แล้วไม่เข้ามือ ไม่ได้หมายความว่า ผมขาดความสามารถ หัวใจสำคัญคือรักษาวิธีทำงานเดิมไว้ และใช้ AI ในบทบาทเสริม"

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

> "การปฏิวัติของ AI น่าทึ่งมาก แต่ตอนนี้เรายังต้องการ ความคาดหวังที่สมดุลและสมจริง"

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
GN⁺ 2025-07-03
ความคิดเห็นบน Hacker News

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

    • คิดว่าสรุปนี้จับประเด็นสำคัญได้ตรงจริงๆ LLM ช่วยเพิ่มความเร็วในการพัฒนาอย่างมาก แต่เพราะฉันไม่ได้เข้าใจโค้ดทั้งหมดอย่างถ่องแท้ เวลามีปัญหาเลยยากที่จะรู้ว่าเกิดที่ส่วนไหนและเมื่อไร สุดท้ายก็เหมือนนักพัฒนาคนใหม่ที่เพิ่งเข้ามาทำความคุ้นเคยกับโปรเจกต์ของตัวเอง เลยต้องคอมมิตโค้ดบ่อยๆ และให้ LLM อธิบายโค้ดซ้ำเป็นระยะๆ ซึ่งหลายครั้งในกระบวนการนี้ LLM ก็ช่วยเจอบั๊กของตัวเองได้ด้วย งานที่ขอบเขตแคบอย่าง data analysis มักควบคุมได้ดีและเดินได้เร็ว ตรงกันข้าม ถ้าไม่มีทักษะและวินัยในการใช้ LLM กับ codebase ขนาดใหญ่ ก็มีโอกาสเละได้ง่ายมาก การเขียนพรอมป์ต์ การจัดการคอนเท็กซ์ การคุมจังหวะความเร็ว การจัดระเบียบงาน และการรีวิวผลลัพธ์จาก LLM อย่างแม่นยำ ล้วนเป็นทักษะสำคัญที่ต้องมีในการใช้งาน LLM แต่ตอนนี้ยังไม่มีใครสอนเรื่องพวกนี้อย่างเป็นระบบ ทุกคนเลยต้องเรียนรู้ด้วยการลองผิดลองถูก ถึงอย่างนั้น พอได้ลองแล้วก็กลับไปทำแบบเดิมยาก เพราะงานน่าเบื่อหรืองานซ้ำๆ สามารถโยนให้ LLM ทำได้ อีกอย่างฉันทำงานพัฒนามาเกิน 20 ปีแล้ว ความอดทนก็ไม่เหมือนเดิม และถ้ามีไอเดียที่ยังไม่รู้จะลงมืออย่างไร ให้ LLM ช่วยก็ทำงานได้มีประสิทธิภาพขึ้นมาก

    • ชอบแนวคิดที่มองการเขียนโปรแกรมเป็นกระบวนการ "สร้างทฤษฎี" ดู Programming as Theory Building ไม่ได้ต่อต้านการใช้ AI เอง เพียงแต่ไม่เห็นด้วยกับท่าทีที่ปัดความรับผิดชอบต่อผลลัพธ์ของโค้ดที่สร้างขึ้นมา เวลาใช้เครื่องมืออย่าง grep ผลลัพธ์ที่ได้จากการใช้เครื่องมือก็ยังต้องรับผิดชอบและจัดการอย่างจริงจังจึงจะมีความหมาย โค้ดที่ถูกสร้างขึ้นมายิ่งต้องเป็นแบบนั้น และไม่ใช่เรื่องที่จะจบได้ด้วยการแปะ disclaimer

    • เห็นด้วยกับความเหนื่อยล้าจากบทความเกี่ยวกับ AI ประเด็นนี้เป็นเรื่องที่คนเห็นต่างกันจริง แต่ก็มีตัวอย่างที่เปิดเผยโค้ดของตัวเองอยู่เหมือนกัน Armin Ronacher ผู้สร้าง Flask/Jinja2/Sentry ได้ลง วิดีโอเวิร์กโฟลว์ และ แนะนำ AI library ที่ทำเอง บน YouTube ส่วนฉันเองก็ทำโอเพนซอร์สโปรเจกต์ประมาณ 50%~80% ด้วย AI ดู cijene-api

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

    • รู้สึกว่าไม่ได้ต่างจากการทำงานกับ codebase ใหญ่ๆ ที่มีนักพัฒนามากกว่า 25 คนทำพร้อมกันเท่าไร ในองค์กรของฉันมีวิศวกร 160 คนดูแลฝั่ง frontend กับ middle tier ต้องคุ้ยโค้ดที่ไม่มีความเป็นเจ้าของอยู่ตลอด และ git blame ก็ชอบโผล่ชื่อผู้รับเหมาภายนอกจากเมื่อ 3 ปีก่อนเป็นประจำ LLM ดูเหมาะกับงานเล็ก ไม่ค่อยเหมาะกับงานขนาดกลาง แต่กลับใช้ได้ดีอีกครั้งเมื่ออยู่ในโปรเจกต์ใหญ่ในฐานะโมดูลย่อย

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

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

  • เพราะ LLM นักพัฒนาหลายคนดูเหมือนจะลืมบทเรียนสำคัญจาก "Simple Made Easy" ไปแล้ว โค้ดที่ LLM สร้างเก่งมากในการผลิต "Ball of Mud" คือโค้ดเละเทะซับซ้อนที่รีแฟกเตอร์หรือดูแลรักษายาก พลังที่แท้จริงคือการแตกปัญหาซับซ้อนออกเป็นชิ้นเล็กๆ ให้แต่ละคอมโพเนนต์ทำงานอย่างเรียบง่าย แล้วให้การโต้ตอบกันของคอมโพเนนต์เหล่านั้นก่อให้เกิดความซับซ้อนที่ต้องการ ถ้าแต่ละคอมโพเนนต์เรียบง่าย ก็จะเข้าใจ ดีบัก และคาดการณ์ประสิทธิภาพได้ง่ายขึ้น ถ้าวันหนึ่ง LLM ทำตามหลักนี้ได้ดีจริง ตอนนั้นอาจไม่ต้องการนักพัฒนาอีกต่อไปจริงๆ ก็ได้

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

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

    • ถ้า LLM สมบูรณ์แบบจริง จะไม่ต้องมีนักพัฒนาแล้วหรือเปล่า ลองคิดดูแล้วไม่น่ามีใครอยากได้เครื่องจักรที่คอย "ผลิตซอฟต์แวร์" ตลอด 24/7 แบบนั้น สุดท้ายก็ยังต้องมีคนที่คอยแตกปัญหา และค้นหาว่าซอฟต์แวร์ที่จำเป็นจริงๆ คืออะไรแล้วสร้างมันขึ้นมา ซึ่งทุกวันนี้เราก็เรียกคนเหล่านั้นว่านักพัฒนาซอฟต์แวร์นั่นเอง

  • ท้ายที่สุดฉันก็ได้ข้อสรุปคล้ายกัน LLM ไม่ค่อยเหมาะกับการเติม codebase ทั้งก้อนแบบ autocomplete เพราะมันทำให้แบบจำลองในหัวว่าตรงไหนทำอะไรหายไป การใช้ LLM แบบ StackOverflow ส่วนตัว เพื่ออธิบายคีย์เวิร์ด สรุปแนวคิดที่ยังไม่คุ้น หรือช่วยชี้ทิศทาง แล้วให้การลงมือทำและการตัดสินใจจริงเป็นหน้าที่ของตัวเอง กลับมีประสิทธิภาพกว่ามาก

    • ฉันก็ใช้แบบเดียวกัน แต่ cursor มักพยายามเสนอการแก้โค้ดอย่างตื๊อมาก เลยอยากรู้ว่ามีเคล็ดลับอย่างไรให้มัน introspect อย่างเดียวโดยไม่แตะเนื้อหาใน codebase

    • ของฉันต่างออกไป ถ้าฉันรีวิวโค้ดที่ LLM เสนอมาอย่างละเอียดเสมอ ก็ยังพอมองเห็นได้ค่อนข้างชัดว่าอะไรอยู่ตรงไหนและโต้ตอบกันอย่างไร

  • ฉันเองก็ลดความถี่ในการใช้ลงมากเหมือนกัน เพราะคำตอบของ LLM ผิดบ่อยพอสมควร ช่วงนี้เลยถามแค่ว่า "ควรไปดูคู่มือหรือเอกสารไหน" แล้วเนื้อหาจริงค่อยไปตรวจเอง วิธีนี้ช่วยฝึกความสามารถในการหาแหล่งข้อมูล และลดการพึ่งพา search engine กับ LLM ลงได้ LLM เป็นแค่เครื่องมือ และความแม่นยำก็ยังไม่สูงนัก

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

  • ข้อจำกัดของ LLM ชัดเจนมาก มันทรงพลังมากก็จริง แต่ยังยากที่จะกระโดดเชิงสร้างสรรค์แบบมนุษย์ได้ ตัวอย่างเช่น เมื่อถามว่า "บน Android bind พอร์ตต่ำกว่า 1000 ไม่ได้ แล้วถ้าจะรันเว็บเซิร์ฟเวอร์ต้องทำอย่างไร" ทั้ง Claude และ Gemini ต่างเสนอคำตอบสามแบบที่ดูสมเหตุสมผลทั่วไปเท่านั้น: 1) reverse proxy 2) root เครื่อง 3) เปลี่ยนไปใช้พอร์ตที่สูงขึ้น แต่คำตอบที่ฉันต้องการจริงๆ คือ HTTPS RR record (ดูเพิ่มเติม) ทั้งคู่รู้จักสเปกนี้ แต่เอามาใช้กับสถานการณ์นี้ไม่เป็น ฉันต้องเติมบริบทเองจึงจะไปถึงคำตอบได้

    • จริงๆ ก็ไม่แปลกที่ LLM จะแนะนำสิ่งนี้ไม่ได้ เพราะจะไปคาดหวังให้มันเสนอสเปกใหม่มากที่แม้แต่ Chrome ยังไม่รองรับอย่างเป็นทางการก็คงยาก และฉันเองก็คงนึกไม่ถึงเหมือนกัน

    • ข้อมูลนี้ฉันก็จดไว้เหมือนกัน ช่วงหลังพอได้คุยกับ LLM จริงจัง รู้สึกว่าถ้าปฏิบัติกับมันคล้ายเวลาคุยกับคนและมีความผ่อนปรนบ้าง ความเครียดจะลดลง เช่น เวลาใช้ cursor เขียนโค้ดแล้วบอกมันว่า "ตรงนี้ตกหล่น" ฉันก็คิดได้ว่าถ้าเป็นฉันเองอาจพลาดแบบเดียวกันก็ได้ ฉันเคยใช้ LLM เป็นคู่สนทนาใน "ชมรมหนังสือ" กับ "ชมรมภาพยนตร์" ให้ช่วยถกภาพยนตร์สองเรื่อง แม้มันจะพลาดเรื่องสถานการณ์ของตัวละครบ้าง แต่ถ้าไม่ต้องคาดหวังความถูกต้อง 100% และให้ความผ่อนปรนเหมือนเวลาคุยกับคน บทสนทนาก็ลื่นไหลขึ้นมาก เวลาคุยกับ AI ก็ควรเข้าหาในเชิงบวกเหมือนกัน

    • เคยได้ยิน SRV record แต่รู้สึกว่าแทบไม่มีใครใช้ ส่วน HTTPS RR นี่เพิ่งเคยรู้จัก และดูเหมือนสถานะการรองรับจริงจะดีกว่า SRV ด้วย

    • นี่เป็นปัญหาคลาสสิกของ LLM แบบที่ว่า "พอผู้ใช้พูดคำตอบออกมาเอง มันถึงค่อยเพิ่มเข้ามาในรายการทางแก้"

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

  • ฉันใช้ ChatGPT Enterprise บ่อยมาก และเมื่อเวลาผ่านไปก็ได้เรียนรู้อะไรบางอย่าง ไม่ควรยัดโค้ดจำนวนมากเข้าไปพร้อมกัน แต่ควรแยกเป็นฟังก์ชันอิสระหรือคลาสเล็กๆ จะได้ผลดีกว่า หากเป็นการขอให้สร้างหรือเติมโค้ด ประมาณ 10% แก้ได้ด้วยคำสั่งเพิ่มเติมแต่คุณภาพจะลดลง และอีกราว 25% ต่อให้อธิบายอย่างไรก็ไม่ช่วยให้คุณภาพดีขึ้น แบบนี้ควรตัดใจมองข้ามแล้วแก้เอง แต่ในทางกลับกัน มันใช้รีวิวโค้ดใหม่ได้ค่อนข้างดี ความเห็นประมาณครึ่งหนึ่งใช้ไม่ได้ บางส่วนก็คลุมเครือ แต่บางครั้งก็ชี้บั๊กหรือปัญหาสำคัญจริงๆ ให้เห็นได้ อย่าใส่หลายหน้าเข้าไปพร้อมกัน ควรแบ่งเป็นส่วนๆ HLSL shader หรือ SIMD ซึ่งเป็นโดเมนเฉพาะทางมาก มักแทบไม่ได้คำตอบเพราะข้อมูลฝึกมีไม่พอ โดยรวมแล้วมันช่วยให้คุณภาพโค้ดดีขึ้น เพราะการย่อยโค้ดเป็นหน่วยเล็กๆ เพื่อตรวจสอบ ทำให้สถาปัตยกรรมถูกแบ่งเป็นฟังก์ชัน/คลาส/โมดูลอย่างชัดเจน และคุณภาพโดยรวมก็ดีขึ้น

    • เริ่มใช้ AI ในงาน code review แล้วสะดวกมาก มันช่วยได้มากในขอบเขตเล็กๆ อย่างระดับฟังก์ชัน โดยเฉพาะงานน่าเบื่ออย่างการเขียน unit test คุณภาพของ AI coding assistant ดีขึ้นมากจริงๆ ในช่วง 1 ปีที่ผ่านมา ถ้าใครเคยลองนานแล้วแล้วผิดหวัง ฉันคิดว่าน่าจะคุ้มที่จะลองใหม่อีกครั้ง

  • สำหรับการพัฒนาซอฟต์แวร์ระยะยาว การใช้ LLM เป็น "เครื่องสร้าง boilerplate ขั้นสูง" น่าจะน่าสนใจที่สุด งานครั้งเดียวที่ไม่ต้องดูแลต่อมันทำได้ดีอยู่แล้ว แต่แม้แต่ในการพัฒนาระยะยาว มันก็มีประโยชน์มากกับโค้ดซ้ำๆ ที่ยากจะนามธรรมให้สวย เช่น test code ตอนแรกฉันต่อต้านอยู่บ้าง แต่ตอนนี้พอใจมาก ส่วนที่น่าเบื่อและซ้ำซากถูกเปลี่ยนเป็นเกมใหม่ที่สนุกอย่าง "ปรับพรอมป์ต์ให้ดีขึ้น" และ productivity ก็เพิ่มขึ้นมาก การเขียนพรอมป์ต์กับรีวิวโค้ดใช้เวลาน้อยกว่าการทำงานซ้ำๆ แบบเดิมมาก ทำให้เหลือแต่ส่วนที่น่าสนใจและต้องใช้สมองจริงๆ

  • ท้ายที่สุดก็เริ่มรู้สึกว่า LLM ไม่ได้เป็นแค่เรื่องการเขียนโค้ด แต่คล้ายกับ "ไดเอตสุดฮิต" ในงานหลายประเภท ทุกคนล้วนอยากได้ทางออกที่เร็วและง่าย แต่สุดท้ายก็ไม่มีทางลัด ความสะดวกย่อมมากับ trade-off และสักวันทุกคนก็ต้องยอมรับความจริงข้อนี้