AI ไม่ควรมาแทนที่การคิด แต่ควรยกระดับมัน

 (koshyjohn.com)
26 คะแนน โดย GN⁺ 23 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ยิ่งสร้าง ผลงานที่ดูน่าเชื่อถือ ได้เร็วเท่าไร ก็ยิ่งเสี่ยงต่อการทำซ้ำโดยไม่เข้าใจได้ง่ายขึ้น และหากข้ามการฝึกที่ช่วยพัฒนาวิจารณญาณ ศักยภาพระยะยาว ก็จะอ่อนแอลง
  • ในรูปแบบงานที่คุ้นเคย A.I. ช่วยได้มาก แต่เมื่อเจอกับปัญหาที่ไม่คุ้นเคย เงื่อนไขที่กำกวม ข้อมูลที่ไม่สมบูรณ์ หรือข้อจำกัดที่ขัดแย้งกัน การเลียนแบบแบบผิวเผิน จะพังลงได้ง่าย และทักษะที่แท้จริงจะถูกเปิดเผย
  • วิศวกรที่แข็งแกร่งจะมอบหมาย งานเชิงกลไก เช่น boilerplate, สรุปความ, test scaffolding, และการเร่งการค้นคว้า แต่ยังคง เป็นเจ้าของโดยตรง ในการนิยามปัญหา การทบทวน การเลือก และการตัดทิ้ง
  • มูลค่าสูงของวิศวกรรมซอฟต์แวร์ไม่ได้อยู่ที่การผลิตโค้ด แต่คือ วิจารณญาณ ความสามารถในการมองเห็นข้อจำกัดที่ซ่อนอยู่ รู้ว่ากำลังแก้ปัญหาผิดข้อ และเปลี่ยนข้อถกเถียงที่กำกวมให้เป็น trade-off ที่ชัดเจน กำลังยิ่งสำคัญขึ้น
  • โดยเฉพาะในช่วงต้นอาชีพและการบริหารองค์กร การมีเกณฑ์เพื่อรักษา ความเข้าใจที่แท้จริง ยิ่งสำคัญ และยิ่งแยกได้ชัดว่าอะไรควรมอบหมาย อะไรควรทำเอง A.I. ก็ยิ่งเป็นเครื่องมือที่เพิ่มคุณค่าของมนุษย์ได้

รูปแบบความล้มเหลวที่เกิดขึ้นเมื่อจ้างคิดแทน

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

  • อุปมาเรื่องการลอกคำตอบข้อสอบ

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

  • อุปมาเรื่องเครื่องคิดเลข

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

  • อุปมาเรื่องรถยนต์ขับเคลื่อนอัตโนมัติ

    • ระบบขับเคลื่อนอัตโนมัติช่วยลดความเหนื่อยล้าและจัดการสถานการณ์ทั่วไปได้ แต่หากพึ่งพามันก่อนจะเข้าใจการขับรถ คุณก็จะใกล้เคียงกับ ผู้โดยสารที่มีสิทธิ์จับพวงมาลัย มากกว่า
    • ในสถานการณ์นอกมาตรฐาน เช่น ทัศนวิสัยไม่ดี ถนนซับซ้อน รถคันอื่นที่คาดเดาไม่ได้ ระบบล้มเหลว หรืออันตรายฉับพลัน ทักษะจริงจะถูกเปิดเผย
    • A.I. ก็เช่นกัน แม้จะแข็งแกร่งกับรูปแบบทั่วไปและโครงสร้างที่คุ้นเคย แต่งานวิศวกรรมมักหลุดออกจากกรอบนี้เสมอด้วยการเปลี่ยนแปลงของข้อกำหนด บั๊กที่ละเอียดอ่อน ความเป็นเจ้าของที่ไม่ชัดเจน เป้าหมายสถาปัตยกรรมที่แข่งขันกัน ข้อมูลที่ไม่ครบ ความเสียดทานในองค์กร และ trade-off ที่ไม่มีคำตอบสมบูรณ์

วิธีที่วิศวกรชั้นยอดใช้ A.I.

  • วิศวกรที่เก่งไม่ได้ใช้ A.I. น้อยกว่า แต่ ใช้มันอย่างเชิงรุก มากกว่า โดยไม่ยกการคิดของตนให้มัน
  • พวกเขายินดีมอบหมาย งานเชิงกลไก เช่น การเขียน boilerplate การสรุปเอกสาร การสร้าง test scaffolding การเสนอแนวทาง refactoring การสำรวจความเป็นไปได้ของความล้มเหลว การเร่งการค้นคว้า และการบีบอัดงานซ้ำๆ
  • แต่ในขณะเดียวกันก็สร้างคำถามที่เฉียบคมขึ้น นิยาม ปัญหาที่แท้จริง ไม่ใช่แค่คำขอตรงหน้า และให้ความสำคัญกับ ความชัดเจนและความกระชับ มากกว่าถ้อยคำลื่นไหลที่ไม่มีเนื้อหา
  • พวกเขาไม่ได้หยุดอยู่แค่การนำความรู้เดิมในระบบมาจัดเรียงใหม่ แต่สร้าง ความรู้ใหม่ที่มีมูลค่าสูง ขึ้นมา
  • และนำเวลาที่ประหยัดได้กลับไปลงทุนกับการคิดและการตัดสินใจในระดับที่สูงขึ้น

แหล่งกำเนิดมูลค่าที่แท้จริง

  • เรามักมองว่าวิศวกรรมซอฟต์แวร์เท่ากับ การผลิตโค้ด มาเป็นเวลานาน แต่คุณค่าสูงสุดไม่ได้อยู่ตรงนั้น
  • หากแก่นของงานมีแค่การเขียนโค้ดที่ถูกต้องตามไวยากรณ์ A.I. ก็คงเข้ามาแทนส่วนใหญ่ของงานได้โดยตรง แต่แก่นจริงอยู่ที่ วิจารณญาณ
  • วิศวกรที่มีคุณค่าจะมองเห็น ข้อจำกัดที่ซ่อนอยู่ ก่อนจะกลายเป็นปัญหา รู้ตัวว่าทีมกำลังแก้โจทย์ผิด เปลี่ยนข้อถกเถียงที่คลุมเครือให้เป็น trade-off ที่ชัดเจน มองเห็น abstraction ที่ขาดหายไป และไม่ได้ debug แค่โค้ด แต่ debug ความเป็นจริง
  • A.I. สามารถช่วยสนับสนุนงานเหล่านี้ได้ แต่ยังไม่สามารถรับช่วงแทนได้
  • ต่อจากนี้ วิศวกรที่สร้างมูลค่าได้มากกว่าจะใกล้เคียงกับคนที่สร้าง หลักการออกแบบ ความเข้าใจโดเมน รูปแบบ บริบท และกรอบการตัดสินใจ ที่ทำให้ A.I. มีประโยชน์มากขึ้น
  • ในสภาพแวดล้อมแบบนี้ แทนที่วิศวกรจะถูก A.I. แทนที่ พวกเขาจะทำงานอยู่ เหนือชั้นของผลลัพธ์ดิบ และมี leverage มากขึ้น

ความเสี่ยงที่มากกว่าสำหรับวิศวกรช่วงต้นอาชีพ

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

ไม่มีทางลัดสู่วิจารณญาณ

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

เส้นแบ่งและนัยต่อระดับองค์กร

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

เหตุใดจึงส่งผลต่อสุขภาพขององค์กรมากกว่า

  • การบริหารวิศวกรรมก็จะต้องยืนอยู่บนเส้นแบ่งเดียวกัน คือแยกให้ออกระหว่าง การใช้เพื่อเร่งความเข้าใจ กับ การใช้เพื่อเลียนแบบความเข้าใจ
  • ภาวะผู้นำที่แข็งแกร่งต้องแยกให้ออกระหว่างผลงานที่ลื่นไหลสวยงามกับ วิจารณญาณที่แท้จริง เพราะหากให้รางวัลแค่ความเร็ว ความลื่นไหล หรือการนำเสนอ ก็จะพลาดสัญญาณของความลึกทางเทคนิค
  • หากงานที่ความเข้าใจต่ำแต่ความลื่นไหลสูงแพร่กระจายออกไป ไม่ใช่แค่คุณภาพของผลผลิตรายบุคคลที่จะลดลง แต่ สภาพแวดล้อมทางความรู้ ขององค์กรเองก็จะอ่อนแอลง
    • การรีวิวจะอ่อนแอลง
    • การถกเถียงด้านการออกแบบจะตื้นขึ้น
    • เอกสารจะลื่นไหลขึ้นแต่มีประโยชน์น้อยลง
    • เมื่อเวลาผ่านไป องค์กรจะสูญเสียพลังในการสร้างความชัดเจนและการตัดสินใจเชิงเทคนิคที่ตนเองพึ่งพา
  • เพราะฉะนั้น ประเด็นสำคัญจึงไม่ใช่แค่การนำเครื่องมือ A.I. มาใช้ แต่คือการรักษา เงื่อนไขที่ทำให้การคิดจริง การเรียนรู้จริง และความเป็นช่างฝีมือยังคงอยู่รอด
  • ตั้งแต่ขั้นตอนการจ้างงาน ก็จำเป็นต้องมีวิธีแยกแยะ ความเข้าใจที่แท้จริง ไม่ใช่แค่ความลื่นไหลภายนอก
    • การสัมภาษณ์ควรทดสอบ กระบวนการให้เหตุผล มากกว่าคำตอบที่ polished แล้ว
    • การประเมินควรให้รางวัลกับ ความชัดเจน ความลึก วิจารณญาณที่ดี และการมีส่วนร่วมทางเทคนิคที่ยั่งยืน มากกว่าปริมาณผลลัพธ์
  • เรื่องนี้ยังส่งผลมากต่อการออกแบบทีมและวัฒนธรรมด้วย
    • ต้องไม่ปล่อยให้วิศวกรที่แข็งแกร่งใช้เวลามากเกินไปกับการตามเก็บ งานที่ดูน่าเชื่อถือแต่ตื้นเขิน ที่สร้างโดยคนที่จ้างการคิดออกไป
    • หากป้องกันสิ่งนี้ไม่ได้ คนที่ผลงานสูงจะถูกใช้เป็นตัวขยายให้กับทุกคนยกเว้นตัวเอง และสุดท้ายจะนำไปสู่ ความหงุดหงิด มาตรฐานที่ลดลง และการจากไป ได้ง่าย
  • ท้ายที่สุด คุณภาพขององค์กรในยุค A.I. จะขึ้นอยู่กับว่าภาวะผู้นำยังคงแยกออกได้หรือไม่ระหว่าง leverage กับ dependency, การเร่งกับการเลียนแบบ, และ ความสามารถจริงกับผลลัพธ์ที่ดูน่าเชื่อถือ

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

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

 
GN⁺ 23 일 전
ความเห็นจาก Hacker News

  • ยิ่งอ่านข้อถกเถียงนี้ซ้ำก็ยิ่งรู้สึกว่า ความประณีตของถ้อยคำ ดีขึ้นเรื่อย ๆ แต่ก็ยังไปไม่ถึงขั้นเป็น คติพจน์
    ถ้าจะให้กลายเป็นประโยคแบบ "the medium is the message", "you ship your org chart", "9 mothers can't make a baby in a month" ที่สั้นไม่กี่คำแต่แทงใจคนจำนวนมากได้ ต้องใช้เวลาหลายปีถึงหลายสิบปีในการขัดเกลาความหมายออกมา
    และพวกเรายังไม่รู้ด้วยซ้ำว่าจะจัดการการก่อรูปของความหมายด้วย RL อย่างไร ดังนั้น AI จึงมาแทนสิ่งนั้นไม่ได้

    • "can't make 9 babies in a month"

      ของเดิมที่ถูกคือ "9 women can't make a baby in one month"

    • เรียนรู้จากการลงมือทำเอง คำนี้ดูเข้าใกล้ความเป็นคติพจน์มากกว่า

    • Intelligence amplification, not artificial intelligence ก็ดูใช้ได้
      ย่อได้เป็น IA, not AI และถ้าแปลเป็นสเปนจะกลายเป็น "AI, no IA" ซึ่งยิ่งขำดี

    • รสนิยม และ วิจารณญาณ เป็นสิ่งที่ AI ให้กำเนิดแทนไม่ได้

    • the medium is the message

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

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

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

  • มีวิศวกรมากมายที่ทำงานไม่ได้หากไม่มี IDE สมัยใหม่ ภาษาโปรแกรมที่มีการจัดการหน่วยความจำ หรือไลบรารีจาก GitHub กับ package manager
    เพราะงั้นสำหรับฉัน การพึ่งพา AI ก็ไม่ได้รู้สึกต่างอย่างมีแก่นสารนัก
    ความหมายของคำว่า Engineer เองก็อาจเปลี่ยนได้ และในความเป็นจริงก็มี "web developer" ที่ใช้แค่ Webflow หรือ WordPress อยู่แล้ว

    • คำว่า Engineer เปลี่ยนไปมากแล้วจริง ๆ
      ถ้าใช้คำนิยามแบบเคร่งครัด คนในสาย Software Engineering ที่เป็น วิศวกรมืออาชีพที่มีใบอนุญาต จริง ๆ แทบไม่มีเลย และบางประเทศก็มีทั้งคุณสมบัติและตำแหน่งกำกับไว้
    • ต้องแยกให้ออกว่า ทำไม่ได้จริง หรือแค่ ไม่ทำ
      ช่วงต้นอาชีพ ถ้ามีเวลาพอ ก็คงทำได้แทบทุกอย่าง แต่ตอนนี้มีหลายอย่างที่ถึงจะทำได้ก็ไม่ทำ เพราะมันไม่น่าสนุกแล้ว
    • ความต่างใหญ่จริง ๆ คือเรายังไม่รู้ ต้นทุนสุดท้าย
      ไม่รู้ว่า AI จะมีต้นทุนระดับค่าสมาชิก Slack ระดับต้นทุนพนักงานหนึ่งคน หรือบริการอาจหายไปจนต้องจ้างคนที่มีสิทธิ์เข้าถึง AI แยกต่างหาก
    • อย่างน้อยตอนนี้ การ รันแบบโลคัล ยังไม่ใช่เรื่องจริงจังสำหรับคนส่วนใหญ่
      เพราะงั้นการพึ่ง AI จึงค่อนข้างต่างจากการพึ่ง IDE ที่อาจเป็นเครื่องมือโลคัลหรือโอเพนซอร์สได้
    • ประโยคว่า "แล้วคุณเป็นวิศวกรอะไรกันแน่" ทำให้นึกถึงฉากแว่นกันแดดแดงสดของ Jesse Plemons ขึ้นมา

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

  • วิธีใช้ AI ตอนนี้ให้ความรู้สึกเหนื่อยกว่าการ เขียนโปรแกรมตลอด 20 ปีที่ผ่านมา
    โดยเฉพาะกระบวนการโยนปัญหาเข้าไป ประเมินข้อเสนอ เลือกทิศทางที่ถูก คัดข้อเสนอแปลก ๆ ทิ้ง แล้วขัดต่อจนเกือบจะถูกนั้นชวนให้ล้ามาก
    หลังจากนั้นมันก็ไปเขียนโค้ดต่ออีก 1~5 ชั่วโมง และให้ผลลัพธ์ที่ถ้าฉันทำเอง อย่างน้อยก็คงใช้เวลา 2~3 สัปดาห์
    แต่พอทำงานเชิงวางแผนแบบนี้สัก 5 ชั่วโมงก็หมดแรงไปเลย และมันเป็นความเหนื่อยที่ต่างจากการเขียนโปรแกรมล้วน ๆ
    เหมือนจะได้เรียนรู้อะไรอยู่บ้าง แต่พูดตามตรงก็รู้สึกว่าใกล้เคียง งานผู้จัดการ มากกว่า

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

  • แต่แรกก็มีวิศวกรจำนวนมากที่คิดไม่เก่งอยู่แล้ว และ AI ก็ไม่ได้เปลี่ยนข้อเท็จจริงนั้น

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

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

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

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

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

  • สำหรับซอฟต์แวร์ ข้อดีที่ใหญ่ที่สุดของ AI คือ มันทำให้สร้างโค้ดได้เร็วขึ้น
    ข้อเสียที่ใหญ่ที่สุดคือ มันยั่วยวนให้เราอยากสร้างให้เร็วขึ้นแบบมหาศาล

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