อย่าปล่อยให้ตัวเองถูกกระแสต่อต้าน AI พัดพาไป

• ช่วงหลังมานี้ โมเดลภาษาขนาดใหญ่ (LLM) พัฒนาไปมากจนสามารถ ทำโปรเจ็กต์ขนาดกลางให้เสร็จได้แทบจะลำพัง และทำให้ วิธีการเขียนโปรแกรมกำลังเปลี่ยนไปอย่างถึงราก
• ความจำเป็นของ การลงมือเขียนโค้ดด้วยตัวเอง กำลังลดลง และทักษะที่สำคัญกว่ากำลังย้ายไปอยู่ที่ ความสามารถในการคิดว่าจะสร้างอะไร และจะอธิบายมันอย่างไร
• Antirez ผู้ก่อตั้ง Redis ใช้ Claude Code ทำงาน 4 อย่างภายในเวลาไม่กี่ชั่วโมง ได้แก่ เพิ่มการรองรับ UTF-8, แก้บั๊กใน Redis test, สร้างไลบรารี C สำหรับ BERT embedding และจำลองโครงสร้างภายในของ Redis Streams
• AI กำลังผลักดัน การทำให้การพัฒนาซอฟต์แวร์เป็นประชาธิปไตยมากขึ้น ทำให้ทีมขนาดเล็กก็สามารถแข่งขันกับบริษัทยักษ์ใหญ่ได้
• อย่างไรก็ตาม ยังจำเป็นต้องมีการรับมือทางสังคมต่อ ความเสี่ยงจากการรวมศูนย์ของเทคโนโลยี AI และปัญหาการลดลงของงาน พร้อมกับไม่เมินเฉยต่อ AI แต่ควรใช้งานมันอย่างจริงจัง

---

การเปลี่ยนแปลงของการเขียนโปรแกรมและบทบาทของ LLM

• LLM รุ่นล่าสุดสามารถทำโปรเจ็กต์ขนาดกลางได้เกือบอย่างอิสระ หากได้รับคำใบ้ที่เพียงพอ
  • ความสำเร็จขึ้นอยู่กับประเภทของงานเขียนโปรแกรมและความสามารถในการอธิบายปัญหาให้ชัดเจน
  • ยิ่งเป็นงานอย่าง system programming ที่ สามารถอธิบายเป็นข้อความได้ ก็ยิ่งมีประสิทธิภาพสูง
• ในโปรเจ็กต์ส่วนใหญ่ การเขียนโค้ดด้วยตัวเองเป็นเรื่องที่ไม่มีประสิทธิภาพ และตอนนี้การเข้าใจว่าจะสร้างอะไรและจะสร้างอย่างไรสำคัญกว่า
• ผู้เขียน Antirez ใช้ AI ทำงาน 4 อย่างต่อไปนี้
  • เพิ่มการรองรับ UTF-8 ให้กับ ไลบรารี linenoise และสร้าง test framework บนพื้นฐานของ emulation terminal
    • งานที่ก่อนหน้านี้เคยยอมแพ้ไปเพราะมองว่าไม่คุ้มกับต้นทุนในการทดสอบ สามารถทำได้จริงด้วย AI
  • แก้ปัญหาความล้มเหลวเป็นครั้งคราวใน Redis test ที่เกี่ยวข้องกับ timing และ TCP deadlock
    — Claude Code วิเคราะห์สถานะของโปรเซสและแก้บั๊กได้
  • สร้าง ไลบรารี C ล้วนสำหรับรัน inference ของโมเดล embedding ตระกูล BERT ภายใน 5 นาที
    • ช้ากว่า PyTorch 15% แต่ให้ผลลัพธ์เหมือนกัน ขนาดโค้ดราว 700 บรรทัด
    • รวมเครื่องมือ Python สำหรับแปลงโมเดล GTE-small
  • ทำงานเปลี่ยนโครงสร้างภายในของ Redis Streams ขึ้นมาใหม่จากเอกสารออกแบบเพียงอย่างเดียว
    • หากไม่รวมเวลาตรวจทานและอนุมัติให้รัน ใช้เวลาราว 20 นาทีเท่านั้น
• จากประสบการณ์เหล่านี้ เขายืนยันว่า AI กำลังเปลี่ยนแก่นแท้ของการเขียนโปรแกรม

AI กับความสัมพันธ์กับนักพัฒนา

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

การทำให้เทคโนโลยี AI เป็นประชาธิปไตยและความกังวลเรื่องการรวมศูนย์

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

ผลกระทบทางสังคมและการรับมือ

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

คำแนะนำถึงนักพัฒนา

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

[m00nlygreat]

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

[flaxinger]

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

[GN⁺]

ความคิดเห็นจาก Hacker News

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

  • สำหรับผม การเขียนโค้ดด้วย LLM ทำให้เข้าสู่ภาวะflowไม่ได้เลย กระบวนการนั่งรอโทเคนออกมาแล้วคอยตรวจแก้เหนื่อยเกินไป ความสนุกจากการพ่นโค้ดออกมาด้วยตัวเองแล้วจมดิ่งกับงานหายไป
  • พอได้ยินเรื่อง “โปรแกรมเมอร์ที่ชอบการพิมพ์ตัวอักษรด้วยมือตัวเอง” ก็ทำให้นึกถึงเกร็ดในหนังสือของ Richard Hamming เกี่ยวกับ Symbolic Assembly Program(SAP) สมัยก่อนการใช้งานแอสเซมบลีเคยเป็นสัญลักษณ์ของ ‘โปรแกรมเมอร์ตัวจริง’ และการใช้เครื่องมืออัตโนมัติถูกมองว่าเป็น ‘พฤติกรรมของคนขี้ขลาด’
  • ตอนแรกกะจะทำเว็บคนอื่นพัง แต่สุดท้ายกลับค้นพบความสุขจากการสร้างสรรค์ ฟังดูเป็นตัวอย่างที่ยอดเยี่ยมของการที่เจตนาไม่ดีนำไปสู่ผลลัพธ์ที่ดี
  • ในฟีดของผม เสียง ‘สรรเสริญ AI’ มากกว่า ‘วิจารณ์ AI’ ถึง 5 ต่อ 1 มุมมองแบบสายกลางอย่างของ antirez หรือ simonw หาได้ยาก และจุดยืนที่หัวก้าวหน้าจริง ๆ คือฝั่งที่เชื่อว่า “AI เป็นเครื่องมือที่ให้ผลประโยชน์สุทธิแบบค่อยเป็นค่อยไปแต่ชัดเจนกับคนบางกลุ่ม”
  • ปัญหาไม่ใช่การสร้างโค้ด แต่คือการบำรุงรักษา หากคอมมิตโค้ดที่ AI สร้างมาแบบตรง ๆ ภายหลังคนจะเป็นคนแก้เอง หรือจะหวังให้ AI ช่วยแก้บั๊ก? สุดท้ายคำถามคือใครจะเป็นคนมาเก็บกวาด(clean-up)

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

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

• ผมไม่ค่อยเข้าใจคำพูดที่ว่า “ถ้าไม่ขึ้นรถไฟ AI ก็จะตกขบวน” ตอนนี้มันยังไม่ได้ช่วยงานผมมากนัก เลยคิดว่ารอจนกว่าเครื่องมือจะดีพอแล้วค่อยเริ่มก็ยังไม่สาย

  • ก็สงสัยว่าเป็นงานแบบไหนถึงไม่ได้ประโยชน์จาก AI ไม่ว่าจะค้นข้อมูล API ทบทวนการออกแบบ business logic หรือ code review ก็ตาม ขอบเขตการใช้งาน AI กว้างมาก Antirez เองก็ใช้ AI หา bug ในโค้ด Redis
  • ความคิดที่ว่า “ใช้เวลาไม่กี่สัปดาห์ก็ไล่ทัน” เป็นความเข้าใจผิด ผมใช้ LLM เขียนโค้ดแทบทุกวันตั้งแต่ ChatGPT ออก และการสร้างสัญชาตญาณ(intuition) ต้องใช้เวลาหลายเดือนหรือหลายปี ถ้าไม่เริ่มตอนนี้ก็เสี่ยงจะตามไม่ทัน
  • ผมเองเมื่อก่อนก็ชิล ๆ แต่ตอนนี้รู้สึกว่าการรีบกระโดดเข้าหาการเปลี่ยนแปลงคือทางที่ฉลาด เครื่องมือช่วงนี้ต่างจากเมื่อ 3 ปีก่อนแบบสิ้นเชิง และยังมีแนวคิดอย่าง multi-agent orchestration โผล่มาอีก
  • ในทางกลับกัน ตอนนี้เครื่องมือและเวิร์กโฟลว์ยังเปลี่ยนตลอด เลยไม่ค่อยกังวลเรื่อง ‘ตามไม่ทัน’ มากนัก จนกว่าทุกอย่างจะนิ่ง การเข้าใจภาพใหญ่ไว้ก็น่าจะฉลาดกว่า ไม่จำเป็นต้องไปยึดติดกับเทคโนโลยีที่อาจหายไปเร็วแบบ Graffiti ของ Palm Pilot
  • การบอกให้คนไปชินกับเครื่องมือ AI ดูเหมือนตกอยู่ในกับดักของ horizon effect เทคโนโลยียังจะเปลี่ยนต่อไป และสิ่งที่จำเป็นจริง ๆ คือทักษะการสื่อสาร คนที่อธิบายแก่นของโปรเจกต์ได้เร็วและชัดเจนจะได้เปรียบมากขึ้น

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

  • ช่วงปลายยุค 2000 ก็เคยมีคนพูดว่า “ไม่มีใครยอมจ่ายเงินบนอินเทอร์เน็ตหรอก” การที่บริษัทพร้อมจ่ายเงินหลายแสนดอลลาร์ให้วิศวกร แต่กลับยอมจ่ายแค่ไม่กี่ร้อยดอลลาร์ให้เครื่องมือ AI มันไม่สมดุล
  • ชื่อบทความบล็อกก็เป็นแค่การล้อเลียนกระแส AIแบบขำ ๆ
  • ตอนที่มีการซื้อกิจการ YouTube, Instagram, WhatsApp ก็เคยมีคนบอกว่า “ผลาญเงิน” แต่ตอนนี้กลับถูกมองว่าเป็นการตัดสินใจที่ยอดเยี่ยม
  • แต่ใน HN ก็ยังมีเสียงบ่นแนว “LLM เป็นเครื่องผลิตขยะไร้ประโยชน์” อยู่มาก แม้จะน้อยลงกว่า 6 เดือนก่อน แต่ก็ยังมีอยู่

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

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

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

  • มีกรณีที่มีคนคัดลอกและวางชุดทดสอบมากกว่า 8,000 รายการจนสร้าง HTML parser ที่สมบูรณ์ได้ ถ้ามีคำใบ้ระดับนั้นก็เป็นไปได้
  • คำว่า “โปรเจกต์ใหญ่” เองก็กำกวมมาก พื้นที่ที่มี GitHub repo จำนวนมหาศาลอยู่แล้วกับพื้นที่ที่ยังไม่เคยมีใครสำรวจนั้นต่างกันโดยสิ้นเชิง
  • ถ้าสิ่งนี้ใช้ได้ผลเฉพาะกับคนที่มีประสบการณ์เกิน 10 ปี งั้นมันก็ฟังดูเหมือนข้อโต้แย้งฝั่งต่อต้าน AIเสียมากกว่า เพราะหัวใจของคำสัญญาเรื่อง AI คือใคร ๆ ก็ใช้ได้ง่าย
  • ผมก็เห็นแบบนั้น LLM เป็นแค่ตัวคูณผลิตภาพเท่านั้น ผลลัพธ์ขึ้นกับคุณภาพของอินพุต ถ้านำทางด้วยสเปกเทคนิคที่เฉพาะเจาะจง มันก็ทำงานได้เหมือนเวทมนตร์

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

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

• อย่าหลงไปกับการมั่นใจใน AI เกินจริงแบบ “Look ma, no hands”
  ถ้าเป็นการจับคู่กันระหว่าง Antirez + LLM + CFO ก็อาจสร้างบริษัท Redis มูลค่าหลายร้อยล้านดอลลาร์ได้ แต่เป็นเพราะเขาเข้าใจ Redis อย่างสมบูรณ์
  ถ้าเป็น codebase ที่ไม่คุ้นเคยอย่าง Postgres ก็คงยากจะทำผลงานแบบเดียวกันได้ และนักพัฒนาส่วนใหญ่ก็ทำงานอยู่ในสภาพแวดล้อมที่ไม่คุ้นเคยแบบนั้น
  สุดท้ายคุณค่าที่แท้จริงของ LLM อยู่ที่ผู้เชี่ยวชาญโดเมน และหากองค์กรอยากใช้ AI ให้ได้ผลจริง ก็จำเป็นต้องลงทุนกับการฝึกอบรมและการเรียนรู้ของพนักงาน

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

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

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

[parkindani]

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

[dbs0829]

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