21 คะแนน โดย GN⁺ 2025-06-03 | 4 ความคิดเห็น | แชร์ทาง WhatsApp
  • LLM ซึ่งเป็นเครื่องมือ การเขียนโปรแกรมที่ขับเคลื่อนด้วย AI ได้กลายเป็นสิ่งจำเป็นในงานพัฒนาซอฟต์แวร์ไปแล้ว
  • คนรู้จักจำนวนมากยังเชื่อว่า AI เป็นแค่กระแสชั่วคราว แต่ผู้เขียนย้ำว่าอย่างน้อยในงานพัฒนา ถึงเวลาแล้วที่จะต้องเปลี่ยนความคิด
  • Coding agent ช่วยทำงานซ้ำ ๆ และน่าเบื่อโดยอัตโนมัติ ทำให้นักพัฒนามุ่งไปที่งานที่มีความหมายมากกว่าได้
  • แม้จะมีข้อถกเถียงเรื่อง คุณภาพ ความเป็นเจ้าของ และการรองรับของเครื่องมือ สำหรับโค้ดที่ AI สร้างขึ้น แต่ส่วนใหญ่ก็เป็นเพียงปัญหาแบบเดียวกับที่มีอยู่แล้วในสภาพแวดล้อมการพัฒนาเดิม
  • ท่าทีลังเลต่อการนำ LLM มาใช้ไม่ใช่สิ่งที่ถูกต้อง และยังบ่งชี้ว่ากำลังมี การเปลี่ยนแปลงทางเทคโนโลยีที่สำคัญยิ่งกว่า รออยู่ข้างหน้า

บทนำ: AI การเขียนโปรแกรม และความสงสัย

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

เอเจนต์ LLM และรูปแบบการใช้งานสมัยใหม่

ปรับความเข้าใจให้ตรงกัน: LLM ในอดีต vs. เอเจนต์ในปัจจุบัน

  • ต่างจากช่วง 6 เดือนถึง 2 ปีก่อนที่แค่ใช้งาน ChatGPT หรือ Copilot แบบพื้นฐาน ตอนนี้ระบบ LLM agent ที่พัฒนาไปมากแล้ว กำลังแพร่หลาย
  • นักพัฒนายุคนี้ปล่อยให้เอเจนต์สำรวจและแก้ไข codebase ได้อย่างอิสระ และใช้สิ่งนี้เพื่อทำให้การสร้างไฟล์ คอมไพล์ ทดสอบ และทำซ้ำเป็นแบบอัตโนมัติ
    • รองรับการส่งโค้ดทรีและโค้ดจากแหล่งภายนอก การดึงข้อมูลด้วยเครื่องมือ Unix การทำงานร่วมกับ Git และการรันเครื่องมือพัฒนาต่าง ๆ
  • ตรรกะการจัดการโค้ดจริง ๆ นั้นเป็นเพียง system code ที่เรียบง่าย
  • การคัดลอกวางโค้ดจาก ChatGPT แบบเมื่อก่อน เท่ากับยัง ไม่ได้สัมผัสการเปลี่ยนแปลงที่แท้จริง

ผลเชิงบวกของ LLM

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

ข้อโต้แย้งต่อคำกล่าวที่ว่า “เราไม่เข้าใจโค้ดที่ LLM สร้าง”

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

มุมมองต่อ “ปัญหา hallucination ของ AI”

  • LLM agent สามารถ lint โค้ด คอมไพล์ และรันเทสต์ เพื่อแก้ข้อมูลผิดและสร้างความน่าเชื่อถือได้
  • ปัญหา hallucination นั้นในหลายสภาพแวดล้อม ถูกแก้ไปได้พอสมควรแล้ว
  • การใช้งานให้มีประสิทธิภาพต้องอาศัย ความเชื่อใจในกระบวนการอัตโนมัติ มากกว่าการเฝ้าดูแบบละเอียดทุกขั้น

คำวิจารณ์ที่ว่า “โค้ด AI ฝีมือต่ำ”

  • ค่าใช้บริการ LLM ถูกกว่าเงินเดือนเด็กฝึกงาน (เช่น Cursor.ai เดือนละ $20)
  • นักพัฒนาระดับอาวุโสมีหน้าที่เพิ่มประสิทธิภาพการทำงานของ ทั้งเด็กฝึกงานที่ยังไม่เก่งหรือโค้ดจาก LLM
  • ความสามารถในการใช้ coding agent, tooling และการออกแบบ prompt ก็เป็น อีกมิติหนึ่งของความชำนาญทางเทคนิคแบบใหม่
  • ตอนนี้ยังมีความสับสนว่า “ใครควรแบ่งงานอะไรทำ” แต่โดยพื้นฐานแล้วนักพัฒนาคือผู้รับผิดชอบ ทิศทาง การตรวจสอบ และการตัดสินใจ

ข้อถกเถียงว่า “AI ทำงานกับ Rust ได้ไม่ดี”

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

ความประณีตเชิงช่างกับการเขียนโปรแกรมในงานจริง

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

การยอมรับความธรรมดาของโค้ด AI (“mediocrity”)

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

ความเห็นต่อมุมมองที่ว่า “ยังอีกไกลกว่าจะถึง AGI”

  • ผู้เขียนไม่ได้สนใจข้อถกเถียงเรื่อง AGI มากนัก และมองว่า สิ่งสำคัญคือมันใช้งานได้จริงหรือไม่
  • สมรรถนะในโลกจริงและการเพิ่มผลิตภาพคือเกณฑ์ตัดสินในตอนนี้

ข้อถกเถียงเรื่องการแทนที่งาน

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

ประเด็นลอกเลียน/ลิขสิทธิ์

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

การใช้ LLM ล่าสุดและความเร็วของการเปลี่ยนแปลง

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

บทสรุป: การเปลี่ยนแปลงทางเทคโนโลยี และการก้าวข้ามความสงสัย

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

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

 
qpolsa95 2025-06-05

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

 
kimjoin2 2025-06-04

ไม่ว่าจะเป็นคนที่ศรัทธา AI หรือคนที่กังขา AI ถ้าสุดโต่งก็ทำให้อยากตีตัวออกห่างทั้งนั้น

 
forgotdonkey456 2025-06-05

ทุกครั้งที่เห็นคนตะโกนว่า "ภาวะเอกฐานกำลังมา" ก็ชวนให้เหนื่อยใจจริง ๆ

 
GN⁺ 2025-06-03
ความคิดเห็นจาก Hacker News
  • ถ้าคุณเคยลองให้ LLM เขียนโค้ดเมื่อ 6 เดือนก่อนแล้วล้มเหลว นั่นก็อาจหมายความว่าคุณไม่ได้ใช้มันแบบเดียวกับที่นักพัฒนาส่วนใหญ่ที่ใช้งาน LLM อย่างจริงจังทำกัน แต่ฉันเองก็ยังคงรู้สึกกังขาต่อเสียงที่บอกว่าเทคโนโลยีนี้ปฏิวัติวงการมาโดยตลอด เมื่อ 6 เดือนก่อนก็มีคำพูดว่าถ้าไม่ใช้ LLM รุ่นล่าสุดก็ถือว่าล้าสมัย หรือใช้งานไม่เป็น แต่สุดท้ายบรรยากาศตอนนี้ก็เหมือนทุกคนยอมรับว่า LLM รุ่นก่อน ๆ มันไม่ค่อยดีจริง ๆ มันเหมือนปรากฏการณ์ "เด็กเลี้ยงแกะ AI" ที่มีแต่ข้อแก้ตัวซ้ำ ๆ รอบนี้ก็บอกอีกว่าผลิตภาพในการทำงานเพิ่มขึ้นแบบก้าวกระโดด แต่ก็ยังสงสัยว่ามีหลักฐานอะไรที่ทำให้เชื่อได้ว่าคราวนี้เป็นเรื่องจริง และคาดว่าอีก 6 เดือนข้างหน้า คนก็คงจะพูดอีกว่า LLM ที่ใช้อยู่ตอนนี้ก็ไม่ได้ดีนัก

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

    • ถ้าคุณขอความช่วยเหลือจากมนุษย์คนหนึ่งทุก ๆ 6 เดือน ตั้งแต่อายุ 0 ถึง 30 ปี คุณจะเริ่มทึ่งเมื่อไร คำตอบอาจต่างกันตามคนและตามงาน แต่เมื่อเวลาผ่านไปก็ย่อมมีคนมากขึ้นเรื่อย ๆ ที่ทึ่งกับความสามารถนั้น ความก้าวหน้าของ LLM ก็เหมือนเฝ้าดูเด็กคนหนึ่งเติบโต ฉันเองก็ไม่เคยใช้ LLM มาก่อน แต่หลังจาก o3 และ Gemini 2.5 Pro ก็ใช้ตลอด ถ้าคุณได้ลองโมเดลล่าสุดด้วยตัวเองแล้วและยังไม่ทึ่ง ฉันมั่นใจว่าภายใน 3 ปีคุณจะต้องทึ่งแน่

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

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

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

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

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

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

    • จากประสบการณ์ของฉัน LLM ใกล้เคียงกับ pair programmer และสำหรับมือใหม่ก็เหมือนวิศวกรอาวุโส มันไม่ได้ช่วยแค่เรื่องโค้ด แต่ยังอธิบายหลักการและกระบวนการได้ดีมากในฐานะติวเตอร์ สำหรับ senior มันก็มีประโยชน์หลายอย่าง ทั้ง code review, brainstorming ไอเดีย, จัดการ boilerplate ฯลฯ ในมุมผู้เชี่ยวชาญ เราสามารถโฟกัสกับงานยาก 10% แล้วมอบงานง่ายที่เหลือให้ LLM ทำ จึงประหยัดเวลาได้ ถ้ามือใหม่ไม่สนใจหรือไม่อยากรู้อะไรเลย แค่ลอกโค้ดมาใช้ นั่นก็เป็นปัญหาของนักพัฒนาเอง แต่สำหรับคนที่อยากเรียนรู้จริง ๆ LLM คือทรัพยากรการเรียนรู้ระดับสุดยอด ในแง่นั้นนี่อาจเป็นยุคที่ดีที่สุดสำหรับมือใหม่

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

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

  • มีคนเล่าว่าเพิ่งลองใช้ Claude 4 agent กับกรณีหลากหลาย ทั้ง codebase ภาษา C ขนาดใหญ่ (ฟีเจอร์ใหม่, bug fix), โปรเจกต์ Rust เล็ก ๆ, ฟรอนต์เอนด์ขนาดเล็ก, ฟรอนต์เอนด์ใหม่ที่มีเอกสาร API พื้นฐาน ฯลฯ และล้มเหลวหมดทุกกรณี ทั้งรับ diff ผิด ส่งอาร์กิวเมนต์ผิดให้เครื่องมือ ล้มเหลวกับฟังก์ชันพื้นฐาน รีแฟกเตอร์มั่วเป็นร้อยบรรทัด ทิ้ง refactor ที่ทำไม่เสร็จไว้จน codebase เละเทะ แม้แต่กับเฟรมเวิร์ก JS ที่มีข้อมูลเยอะอย่าง Svelte หรือ solidJS ผลก็ยังแย่ เลยไม่เข้าใจว่าจุดแข็งจริงของเอเจนต์ที่หลายคนชมหนัก ๆ คืออะไร หรือจริง ๆ เป็นแค่การตลาดเกินจริง

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

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

    • มีคนบอกว่าบทความเกี่ยวกับเอเจนต์หลายชิ้นดูเหมือน advertorial เงินในตลาด AI ไหลเข้ามามหาศาล เลยยิ่งไว้ใจน้อยลงเมื่อคิดถึงตัวอย่างการตลาดในอดีต ตัวเองก็ลองผลิตภัณฑ์เอเจนต์หลายตัวแล้ว แต่การพัฒนาที่ใช้งานได้จริงมีน้อย ใน HN เองกลับมีคนมองโลกแง่ร้ายเรื่อง AI เยอะ พอมีการถกเถียงมากก็ยิ่งเกิดบรรยากาศว่า ถ้ามีปัญหาก็คงเป็นความผิดของผู้ใช้ มีผู้ใช้คนหนึ่งถึงกับบอกว่า "ต้องจ่ายให้ AI เดือนละ 1,000 ดอลลาร์จริง ๆ ถึงจะสัมผัสศักยภาพได้" ซึ่งฟังดูมีกลิ่นโฆษณา

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

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

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

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

    • มีคนทึ่งว่านี่เป็นยุคที่น่าอัศจรรย์จริง ๆ ถึงขั้นสัปดาห์ละ 1~2 ครั้งยังรู้สึกประหลาดใจกับความจริงของมัน

    • มีคนเคยเป็นแฟน Star Trek: The Next Generation และจำได้ว่าเคยทึ่งกับความต่างระหว่างคอมพิวเตอร์ของยาน Enterprise กับ Data คอมพิวเตอร์ของ Enterprise ทำสิ่งคล้าย AI ทุกวันนี้ได้ เช่น จัดระเบียบความรู้ สรุปข้อมูล และทำงานต่าง ๆ ส่วน Data เป็นหุ่นยนต์ที่มีความสามารถเฉพาะตัว ข้อจำกัดของ Data ในเรื่องอารมณ์ขัน ศิลปะ และด้านอารมณ์ของมนุษย์ ก็คล้ายกับ AI art ทุกวันนี้ ความทรงจำถึงรายละเอียดการตั้งค่าและการดำเนินเรื่องช่วงต้นของซีรีส์ยังผุดขึ้นมา

    • ฉันเข้ามาในวงการนี้เพราะอยากสั่งเครื่องจักรอย่างชัดเจนเพื่อให้ได้ผลลัพธ์ตรงตามต้องการ Dijkstra เคยเน้นมานานแล้วถึงความกำกวมของภาษามนุษย์ และความสำคัญของ "ภาษารูปแบบ" ที่เกิดขึ้นมาเพื่อเอาชนะมัน สุดท้ายในปี 2025 เรากลับเข้าสู่ยุคที่ต้องเถียงกับคอมพิวเตอร์และคอยแก้ถ้อยคำใน "prompt engineering / vibe coding" อย่างประชดประชัน พร้อมแนะนำว่า EWD667: The Humble Programmer น่าอ่าน

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

    • มีคนมองว่านี่คือการพูดกันคนละมุมมาโดยตลอด เดิมทีก็มีเส้นแบ่งต้นทุนระหว่างงานที่ลงมือทำได้จริง (งานที่คุ้มค่ากับแรง) กับงานที่ถูกทิ้งค้างใน backlog อยู่แล้ว เครื่องมือ AI ลดต้นทุนขั้นต่ำตรงนั้นลง ทำให้มีงานอีกมากที่พอจะลองทำได้ ดังนั้นฝั่งที่บอกว่า "ผลิตภาพเพิ่ม 5 เท่า" จึงเน้นว่าปริมาณโค้ดที่จัดการได้เพิ่มขึ้น ส่วนฝั่งที่กังขามองว่าคุณค่าทางธุรกิจที่เป็นแก่นแท้ไม่ได้เปลี่ยนมาก พร้อมแนะนำให้อ่าน ปริศนาผลิตภาพของ AI

    • มีคนถามกลับว่าจริง ๆ อยากเห็นหลักฐานแบบไหน ต้องการพิสูจน์ความสามารถไร้ขีดจำกัด หรือแค่พิสูจน์ว่ามันมีประโยชน์ในโลกจริงกันแน่ พร้อมย้ำว่าแทบไม่มีใครอ้างว่ามันเก่งสารพัดแบบสมบูรณ์ และมันจะมีประโยชน์เมื่อใช้โดยคนที่เข้าใจทั้งข้อจำกัดและจุดแข็งของมันอย่างถูกต้อง โดยยกตัวอย่างประวัติ commit ล่าสุดของ cloudflare/workers-oauth-provider ว่าอย่างน้อยคงพอยอมรับได้ไหมว่ามัน "มีประโยชน์บ้าง"

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

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

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

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

    • โปรแกรมเมอร์มักเข้าใจกฎหมาย โดยเฉพาะ common law แบบอเมริกัน ได้ไม่ดีนัก ประเพณีกฎหมายถูกเขียนขึ้นบนสมมติฐานว่ามนุษย์จะตีความอย่างมีเหตุผลมาเป็นเวลานาน และถึงเครื่องมือ AI จะถูกออกแบบให้กระจายหรือหลีกเลี่ยงความรับผิด แต่สุดท้ายกฎหมายก็จะหาคนที่ต้องรับผิดมาลงโทษจนได้ หลังยุคบูมของ AI ความเป็นจริงน่าจะเป็น 1) บริษัทและรัฐพยายามกระจายความรับผิด 2) เกิดเหตุผลข้างเคียง เช่น อุบัติเหตุรถยนต์ อัลกอริทึมเลือกปฏิบัติ ข้อมูลรั่วไหล 3) ศาลโยนความรับผิดกลับมาที่มนุษย์และลงโทษหรือปรับ 4) บริษัทอื่นเห็นความเสี่ยงแล้วจำกัด AI มากขึ้น ในกระแสแบบนี้ เครื่องมือ AI น่าจะอยู่รอดได้ก็เฉพาะในขอบเขตของความรับผิดชอบของมนุษย์

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

  • มีคนบอกว่าความท้าทายอย่าง Konwinski Prize ที่จะมอบเงิน 1 ล้านดอลลาร์ถ้าโอเพนซอร์ส LLM แก้ novel Github issue ได้เกิน 90% นั้นน่าสนใจ ดู การแข่งขัน Konwinski Prize ได้ ปัจจุบันแม้แต่โมเดลที่ดีที่สุดก็ยังได้เพียง 0.09 ไม่ใช่ 0.9 จึงมองว่ายังห่างไกลจากการใช้งานจริงมาก แม้โอเพนซอร์สอาจด้อยกว่าของเชิงพาณิชย์เล็กน้อย แต่การที่ LLM จะเขียนโค้ดได้อย่างอิสระจริง ๆ ยังแทบเป็นไปไม่ได้ มันผลิตขยะออกมามากก็จริง แต่ก็ยังมีประโยชน์ในแง่ที่จำเป็นต้องมีการประเมินและการจัดการ

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

    • คนที่ปกป้องการพัฒนาโดยใช้ AI ดูเหมือนจะชอบ code review มากกว่าการเขียนโค้ดเอง สุดท้ายก็เป็นเรื่องรสนิยมส่วนตัว แต่สำหรับฉันมันเป็นงานที่ทรมานในตัวเอง

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

    • Claude, Gemini และตัวอื่น ๆ เร็วกว่าที่ฉันจะเขียนเองมาก และต่อให้ต้องดูซ้ำมากกว่าสองรอบ เวลาก็ยังน้อยกว่าที่เขียนเองอยู่ดี

    • เมื่อก่อนเราใช้โค้ดกับงานจุกจิกแบบ "โกนขนจามรี" ตอนนี้กลับกลายเป็นต้องมานั่งรีวิวการโกนจามรีแบบขอไปทีแทน

    • โดยรวมแล้วการใช้พลังงานและการปล่อยคาร์บอนมากขึ้นเป็นสิ่งหลีกเลี่ยงไม่ได้

  • มีการพูดถึง machine translation และ speech recognition คนหนึ่งซึ่งเกือบพิการทางการได้ยินบอกว่าใช้เทคโนโลยีนี้ทั้งวัน เมื่อก่อนดูซีรีส์ยุค 80 โดยไม่มีซับไม่ได้เลย แต่ตอนนี้ใช้ LLM อย่าง Whisper เพื่อดึงซับจากวิดีโอได้ และรู้สึกเหมือนปาฏิหาริย์ที่สิ่งซึ่งเคยเป็นได้แค่จินตนาการกลายเป็นจริง

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

    • หลายปีที่ผ่านมาเคยลองระบบรู้จำเสียงหลายแบบ เช่น Dragon มันน่าทึ่งก็จริงแต่ใช้งานจริงไม่สะดวก การผสม Whisper กับ LLM เป็นครั้งแรกที่ให้ประโยชน์ใช้งานจริง แม้ยังไม่สมบูรณ์ แต่การต้องมาแก้เองลดลงเหลือหนึ่งในสิบ สำหรับโน้ตส่วนตัวตอนนี้สะดวกจนแทบไม่ตรวจทานแล้ว

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

    • ฉันเองก็รู้สึกว่าความก้าวหน้าล่าสุดกำลังทำให้คำสัญญาแบบ SF ที่เคยเห็นตอนเด็กเป็นจริง ไม่กี่วันก่อนอยู่ในเมืองที่ไม่คุ้นเคย ฉันถ่ายรูปเมนูร้านอาหาร ดึงลายมือภาษาจีนออกมา แปลเป็นอังกฤษทันที แล้วเรียนวิธีออกเสียงเมนูที่ต้องการเพื่อสั่งอาหารได้เลย มั่นใจว่าเมื่อ 2 ปีก่อนยังทำแบบนี้ไม่ได้

    • มีคนมองว่าการแปลคือกรณีใช้งานที่สมบูรณ์แบบของ LLM มันสะท้อนทั้งแนวคิดทางสังคม บริบททางวัฒนธรรม ป๊อปคัลเจอร์ และ reference หายาก ได้ครบถ้วน อีกทั้งยังแปลออกมาได้หลายเวอร์ชันให้เข้ากับภาษาและวัฒนธรรมต่าง ๆ และเชื่อว่ามันก้าวล้ำกว่าการแปลแบบดั้งเดิมไปไกลแล้ว