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

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

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

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

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

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

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

    • เครื่องคิดเลขเป็นเครื่องมือที่ดีที่ช่วยประหยัดเวลา แต่หากพึ่งมันโดยไม่มี ความรู้สึกต่อจำนวน ก็จะตรวจไม่ได้เลยว่าผลลัพธ์นั้นสมเหตุสมผลหรือไม่
    • วิศวกรที่มีพื้นฐานจะสามารถตรวจทานผลลัพธ์จาก 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 มากขึ้นจากการทำงาน เหนือกว่าระดับ raw output

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

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

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

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

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

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

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

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

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

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

 
GN⁺ 2 일 전
ความเห็นจาก 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 แบบเต็มตัว ก็ทำไป เพราะต้นทุนของหนี้เทคนิคที่ตามมาจากสิ่งนั้นไม่ใช่ฉันที่ต้องจ่าย