ความเข้าใจคือคอขวดใหม่
(geoffreylitt.com)- ในสถานการณ์ที่โค้ดที่เอเจนต์เขียนกองพะเนินอยู่รอบตัวมนุษย์อย่างต่อเนื่อง ปัจจัยที่จำกัดความเร็วในการพัฒนาไม่ได้อยู่ที่ความสามารถในการสร้างโค้ดอีกต่อไป แต่ย้ายไปอยู่ที่ ความเร็วในการทำความเข้าใจของมนุษย์ ที่ต้องตามระบบให้ทันและคิดการเปลี่ยนแปลงถัดไปได้
- เป้าหมายของการทำความเข้าใจโค้ดไม่ได้หยุดอยู่แค่การ ตรวจสอบ เพื่ออนุมัติหรือปฏิเสธผลลัพธ์ แต่คือการเสนอไอเดียถัดไปและ มีส่วนร่วมในกระบวนการสร้างสรรค์ ภายในลูปการทำงานต่อเนื่องหลายรอบของเอเจนต์
- แทนที่จะอ่าน raw code diff ก่อน หากได้อ่าน เอกสารอธิบายโค้ด ที่รวมความรู้พื้นฐาน/เป้าหมายของการเปลี่ยนแปลง/แผนภาพแบบโต้ตอบ/ความต่างของโค้ดแบบบรรยายไว้ด้วยกันก่อน ก็จะเข้าใจโครงสร้างและเจตนาของการเปลี่ยนแปลงได้เร็วกว่า
- ไมโครเวิลด์ ที่มีควิซในเอกสารอธิบายและให้ผู้ใช้ลองควบคุมกระบวนการทำงานได้เอง จะไม่ปล่อยให้เอเจนต์ตัดสินแทนทั้งหมด แต่ทำให้มนุษย์ได้สัมผัสการเปลี่ยนสถานะของระบบและการทำงานภายในด้วยตนเอง
- หากใช้ AI ไม่ใช่เพียงเป็นเครื่องมืออัตโนมัติที่เอาคนออกจากลูป แต่ใช้สร้างเครื่องมือเพื่อความเข้าใจและการจำลอง มนุษย์และทีมก็จะสามารถ มีส่วนร่วมในลูปได้ลึกยิ่งขึ้น เสียด้วยซ้ำ
มนุษย์ที่ตามความเร็วการสร้างโค้ดไม่ทัน
- ราวกับมี กองโค้ด ที่เอเจนต์เขียนไว้สูงขึ้นเรื่อย ๆ รอบตัวคนคนหนึ่ง ปริมาณโค้ดที่ถูกสร้างเพิ่มขึ้น แต่ความเร็วที่มนุษย์จะทำความเข้าใจกลับไม่ได้เพิ่มขึ้นในสัดส่วนเดียวกัน
- หากยังอ่านทุก code diff ทีละบรรทัด ก็ยากจะตาม ความเร็วในการทำงานของเอเจนต์ ให้ทัน
- การทำความเข้าใจโค้ดไม่ได้มีแค่การดู raw code diff เท่านั้น แต่ยังมีวิธีอื่นอีก เช่น
- เอกสารอธิบายโค้ด ที่สอนทั้งระบบและสิ่งที่เปลี่ยนไป
- ควิซ ที่ตรวจว่ามีความเข้าใจจริงหรือไม่
- ไมโครเวิลด์ ที่ให้ลองควบคุมการทำงานภายในด้วยตัวเอง
- พื้นที่ร่วมกัน ที่ช่วยให้ทั้งทีมสร้าง mental model เดียวกัน
ความเข้าใจไม่ได้มีไว้เพื่อตรวจสอบ แต่มีไว้เพื่อการมีส่วนร่วม
- เมื่อถามว่าทำไมมนุษย์จึงต้องเข้าใจโค้ด คำตอบที่ได้ยินบ่อยคือเพื่อ ตรวจสอบ งานของเอเจนต์
- ตรวจว่าเป็นไปตาม สเปก หรือไม่
- ตัดสินว่า โครงสร้าง เหมาะสมหรือไม่
- และสุดท้ายเลือก อนุมัติ/ปฏิเสธ
- ในสไลด์นำเสนอ มักอธิบายสิ่งนี้เป็นการตัดสินแบบสองทาง คือ ยกนิ้วขึ้นหรือคว่ำนิ้วลง
- หากมองว่าหน้าที่ของมนุษย์มีแค่การตรวจสอบ ความเข้าใจก็จะถูกย่อให้เหลือเพียงกระบวนการตัดสินว่า ผ่านหรือไม่ผ่าน สำหรับผลลัพธ์
- แต่เอเจนต์เองก็กำลังพัฒนาความสามารถในการ ตรวจสอบตัวเอง อย่างต่อเนื่อง ทั้งรันผลลัพธ์ ตรวจสอบ และหาข้อผิดพลาดได้ด้วยตัวเอง
- ยิ่งเอเจนต์ทำงานด้านการตรวจสอบได้ดีขึ้น คำถามก็ยิ่งกลายเป็นว่า มนุษย์จะยังเหลือบทบาทตรงไหน
- ทางเลือกคือ มีส่วนร่วมผ่านความเข้าใจ
- มนุษย์ต้องรู้ว่าเอเจนต์กำลังทำอะไร จึงจะยังเป็น สมาชิกเชิงรุกของกระบวนการสร้างสรรค์ ได้
- เมื่อเข้าใจระบบแล้ว ก็ไม่ใช่แค่ประเมินผลลัพธ์ปัจจุบัน แต่ยังคิดต่อได้ว่า ขั้นต่อไปควรเปลี่ยนอะไร
โปรเจ็กต์ไม่ใช่ลูปเดียว แต่เป็นลูปจำนวนมาก
- โปรเจ็กต์จริงไม่ใช่ ลูปเดียว ที่สั่งเอเจนต์ครั้งเดียวแล้วรอรับผล
- แต่มันคือ ลูปการทำซ้ำจำนวนมาก ที่เชื่อมต่อกัน ตั้งแต่การตั้งเป้าหมาย/ลงมือทำ/ตรวจสอบ/แก้ไข/ขยายต่อ
- ในแต่ละรอบ ระดับ ความเข้าใจระบบ ที่มนุษย์มีจะเป็นตัวกำหนดคุณภาพและขอบเขตของไอเดียถัดไป
- ต้องมีแนวคิดและโครงสร้างอยู่ในหัวมากพอ จึงจะรับมือกับคำถามอย่างลื่นไหลได้ เช่น
- ควร เพิ่มหรือลบ อะไร
- ควร เปลี่ยนโครงสร้าง ส่วนไหน
- มี ความเป็นไปได้ใหม่ อะไรเกิดขึ้นจาก implementation ปัจจุบัน
- หากความเข้าใจไม่พอ มนุษย์อาจตอบสนองต่อผลลัพธ์ที่เอเจนต์สร้างว่า “ดูเหมือนจะโอเคคร่าว ๆ” ได้ แต่จะ ยากที่จะเป็นผู้นำทิศทางของโปรเจ็กต์
หนี้ทางความคิดที่สะสมจากการผัดวันประกันพรุ่งเรื่องความเข้าใจ
- หากยังรับผลลัพธ์จากเอเจนต์ไปเรื่อย ๆ โดยไม่เข้าใจระบบ ก็อาจ เดินหน้าได้เร็วในระยะสั้น
- แต่เหมือนกับที่ technical debt เพิ่มต้นทุนการเปลี่ยนแปลงในภายหลัง งานที่ข้ามขั้นตอนความเข้าใจไปจะทิ้ง หนี้ทางความคิด (cognitive debt) เอาไว้
- เมื่อหนี้ทางความคิดสะสม คนที่ร่วมทำโปรเจ็กต์ก็จะ เริ่มหลงภาพรวมของระบบ
- ยากจะเข้าใจ ว่าทำไมโค้ดถึงมีโครงสร้างแบบปัจจุบัน
- ยากจะตัดสิน ว่าควรเชื่อม requirement ใหม่เข้าตรงไหน
- ยากจะถกเถียง ถึงความเหมาะสมของการเปลี่ยนแปลงถัดไปที่เอเจนต์เสนอ
- ปัญหาในยุค AI ไม่ใช่การที่โค้ดไม่ถูกสร้าง แต่คือการที่มนุษย์ ไม่มีกรอบความคิดเกี่ยวกับระบบที่ถูกสร้างขึ้นมากพอ
นำวิธีการสอนมาปรับใช้กับการทำความเข้าใจโค้ด
- ปัญหาการสร้างความเข้าใจของมนุษย์ในสภาพแวดล้อมการทำงานแบบ AI ที่เปลี่ยนเร็ว มีความคล้ายกับ ปัญหาที่วงการการศึกษารับมือมานาน
- การสร้างความเข้าใจจริงไม่ได้เกิดจากการส่งต่อข้อเท็จจริงใหม่ ๆ อย่างเดียว แต่ต้องให้ทั้ง ความรู้พื้นฐาน/สัญชาตญาณ/การฝึก/ฟีดแบ็ก ไปพร้อมกัน
- การทำความเข้าใจโค้ดก็สามารถใช้วิธีที่พัฒนามาจากการศึกษาได้เช่นกัน
- ให้ พื้นหลังและสัญชาตญาณ ก่อนลงรายละเอียด implementation
- หลังอ่านแล้วให้ นึกย้อนและตอบคำถาม
- สร้าง สภาพแวดล้อม ที่ให้ลองควบคุมกฎนามธรรมด้วยตัวเอง
- ทำให้ผู้คนแบ่งปัน แนวคิดและคำศัพท์ ชุดเดียวกัน
/explain-diff ที่สอนสิ่งที่เปลี่ยนไป
- /explain-diff คือสกิลที่ทำให้เอเจนต์เปลี่ยนสิ่งที่แก้ไขไปเป็น เอกสารอธิบายแบบมีโครงสร้าง
- สามารถส่งออกเป็นหน้า HTML/Markdown/Notion ได้ และเอกสารบน Notion ก็ใช้เป็น ผลลัพธ์แบบร่วมมือกันทำงาน ที่สมาชิกทีมคอมเมนต์และถกเถียงร่วมกันได้
- มันไม่ได้สร้างแค่รายการการเปลี่ยนโค้ดแบบธรรมดา แต่สร้าง เอกสารอธิบาย ที่ออกแบบมาเพื่อให้มนุษย์เรียนรู้การเปลี่ยนแปลงนั้น
- ในตัวอย่างการเปลี่ยนมุมมองของหน้าจอเกม เอกสารจะไม่รีบแสดงโค้ดทันที แต่เข้าหาตามลำดับนี้
- อธิบาย วิธีเรนเดอร์ของเกมเอนจินเดิม ก่อน
- เสนอ เป้าหมายของการเปลี่ยนแปลง ว่า “ทำให้สวนแบบ 2D ดูมีมิติด้วยเทคนิคการวาดภาพ”
- อธิบายว่า isometric projection คืออะไร เพื่อให้เข้าใจหลักการมองเห็นของการเปลี่ยนแปลง
- จากนั้นค่อยไปยัง โค้ด implementation จริง
สอนจากความรู้พื้นฐานก่อน
- คำอธิบายที่ดีไม่ได้เริ่มจาก “อะไรเปลี่ยนไป” แต่เริ่มจาก “ก่อนจะเปลี่ยน เดิมมีอะไรอยู่”
- หากไม่รู้ระบบพิกัดและโครงสร้างการเรนเดอร์ของเกมเอนจินเดิม ต่อให้อ่านโค้ด perspective ใหม่ ก็ ยากจะเข้าใจเหตุผลของการเปลี่ยนแปลง
- เอกสารอธิบายจึงช่วยเติม โครงสร้างของระบบเดิม ก่อน เพื่อให้คนที่ไม่ได้มีพื้นหลังเดียวกับเอเจนต์สามารถเข้าร่วมบทสนทนาได้
- นี่ไม่ใช่แค่การสรุป แต่เป็นกระบวนการพามนุษย์ กลับเข้าสู่บริบทของโปรเจ็กต์ปัจจุบัน
สร้างสัญชาตญาณก่อนรายละเอียด implementation
- หากอธิบายแก่นของการเปลี่ยนแปลงเป็นประโยคเดียวก่อนดูโค้ด ก็จะรู้ว่ารายละเอียด implementation กำลังมุ่งไปสู่ เป้าหมายอะไร
- ในกรณีที่ทำให้สวนดูมีมิติ เอกสารไม่ได้เริ่มจากสูตรของ isometric projection แต่เริ่มจาก เป้าหมายด้านภาพ ว่าจะทำให้ภาพ 2D ดูเหมือน 3D
- เมื่อเข้าใจพื้นหลังและเป้าหมายแล้ว ค่อยอ่านชิ้นส่วนโค้ด ก็จะเชื่อมโยงได้ง่ายขึ้นว่าการคำนวณและการแปลงแต่ละส่วนมี บทบาท อย่างไรในผลลัพธ์ทั้งหมด
- จุดประสงค์คือทำให้มนุษย์ไม่ใช่ผู้อ่านโค้ดแบบรับอย่างเดียว แต่เป็น ผู้มีส่วนร่วมอย่างเท่าเทียมที่เข้าใจเจตนาของการเปลี่ยนแปลง
สัมผัสการเปลี่ยนแปลงของพิกัดผ่านแผนภาพแบบโต้ตอบ
- แทนที่จะมีแค่ภาพนิ่ง เอกสารใช้ แผนภาพแบบโต้ตอบ ที่ให้ลากก้อนหินบนสวนได้โดยตรง
- เมื่อย้ายก้อนหิน ตำแหน่งบนหน้าจอและพิกัดภายในจะเปลี่ยนไปพร้อมกัน ทำให้เห็น การแปลงพิกัดของ isometric projection
- เมื่อเทียบกับการอ่านแค่สูตรหรือโค้ด การได้ลองควบคุมความสัมพันธ์ระหว่าง input และ output ด้วยตัวเองช่วยให้ สร้างสัญชาตญาณ ได้ดีกว่า
- สามารถฝัง HTML แบบโต้ตอบในหน้า Notion เพื่อให้เอกสารอธิบายโค้ดเองกลายเป็น สภาพแวดล้อมรันขนาดเล็ก ได้
- AI จึงไม่ใช่แค่เขียนคำอธิบาย แต่ยังสร้าง เครื่องมือสำหรับการมองเห็นและการทดลอง ที่จำเป็นต่อความเข้าใจได้ด้วย
เปลี่ยน raw code diff ให้เป็น diff แบบบรรยาย
- code diff แบบทั่วไปจะเรียงไฟล์ที่เปลี่ยนตาม ลำดับชื่อไฟล์
- ไม่อธิบาย ความสัมพันธ์ ระหว่างไฟล์
- ไม่บอก จุดประสงค์ ของการเปลี่ยนแปลง
- ไม่แนะนำว่า ควรอ่านตามลำดับใด
- literate diff จะจัดเรียงการเปลี่ยนแปลงใหม่ให้เหมือนลำดับการเล่าเรื่อง
- บอก เป้าหมาย ของการเปลี่ยนแปลงก่อน
- อธิบาย ไฟล์และฟังก์ชัน ตามลำดับที่เหมาะกับการทำความเข้าใจ
- แทรกเฉพาะ ชิ้นส่วนโค้ด ที่จำเป็นไว้ระหว่างคำอธิบาย
- แสดงความสัมพันธ์ระหว่าง บริบทรอบข้าง กับ ตัวเลือกในการ implementation ไปพร้อมกัน
- หาก raw code diff คือการกองวัตถุดิบไว้ตรง ๆ literate diff ก็ใกล้เคียงกับการ เรียบเรียงกระบวนการเปลี่ยนแปลงให้เป็นเรื่องเล่า
- เมื่ออ่านคำอธิบายก่อนแล้วค่อยตรวจ raw code diff ก็จะรู้ว่าโค้ดแต่ละส่วนมีไว้ทำไม ทำให้ รีวิวได้เร็วขึ้น
อ่านเอกสารที่ AI สร้างบนกระดาษ
- เอกสารอธิบายที่เสร็จแล้วสามารถใช้เหมือน แพ็กเก็ตอธิบายโค้ด ชุดหนึ่งได้
- แม้ยังคงอ่าน raw code diff อยู่ แต่จะ อ่านเอกสารอธิบายก่อนเสมอ
- เวลาต้องการสมาธิ ก็อาจพิมพ์เอกสารออกมาแล้วไปนั่ง อ่านบนกระดาษในคาเฟ่
- จึงเกิดความย้อนแย้งที่กิจกรรมเชิงโต้ตอบอย่างการเขียนโปรแกรมร่วมกับ AI กลับแปลงเป็น รายงานกระดาษแบบนิ่ง ที่ช่วยให้จดจ่อได้ลึกขึ้น
- แก่นสำคัญไม่ใช่การใช้อินเทอร์เฟซที่ใหม่ที่สุด แต่คือการ แปลงข้อมูลให้อยู่ในรูปแบบที่มนุษย์เข้าใจได้ดีจริง ๆ
ความรู้สึกว่าได้อ่าน กับความเข้าใจจริงนั้นต่างกัน
- ต่อให้จัดเอกสารอธิบายไว้อย่างดี การ อ่านเพียงอย่างเดียวก็ไม่ได้รับประกันความเข้าใจ
- มนุษย์มัก หลงคิดได้ง่าย ว่าเข้าใจหรือจำเนื้อหาได้แล้ว เพียงเพราะสายตาไล่อ่านประโยคผ่านไป
- ผู้เขียนนำไอเดียมาจาก “books don't work” ของ Andy Matuschak และ Quantum Country ของ Andy Matuschak/Michael Nielsen
- Quantum Country แทรก ควิซทบทวนแบบ spaced repetition ลงในเนื้อหา เพื่อให้ผู้อ่านต้องนึกคำตอบขึ้นมาเอง
- วิธีเดียวกันนี้จึงถูกนำมาใช้กับเอกสารอธิบายโค้ด โดยวาง คำถามโต้ตอบ 5 ข้อ เกี่ยวกับสิ่งที่เปลี่ยนแปลงไว้ตอนท้าย
ควิซคืออุปกรณ์ควบคุมความเร็วของลูป AI
- มีกฎว่า ก่อนส่งโค้ดให้คนอื่น ต้อง ผ่านควิซในเอกสารอธิบาย ก่อน
- เมื่อตรวจโค้ดที่คนอื่นเขียน ก็ใช้ เกณฑ์เดียวกัน เช่นกัน
- ควิซไม่ได้เป็นฟีเจอร์เสริมเพื่อประเมินความรู้ แต่เป็น อุปกรณ์ควบคุมความเร็ว
- เมื่อทำงานกับ AI ลูปของการ implement/แก้ไข/generate ใหม่ มัก วิ่งเร็วกว่าความเข้าใจของมนุษย์ ได้ง่าย
- ควิซจะบังคับให้เกิดคำถามถัดไปในแต่ละรอบโดยอัตโนมัติ เช่น
- อธิบายได้ไหมว่า อะไรเปลี่ยนไปจริง ๆ
- เข้าใจไหมว่าทำไมถึงใช้ โครงสร้างแบบนี้
- รู้หรือไม่ว่ามี ข้อจำกัด อะไรที่จะส่งผลต่อการเปลี่ยนแปลงครั้งถัดไป
- หากผ่านไม่ได้ ก็ต้องชะลอความเร็วของงานและเติมความเข้าใจให้พอ ทำให้มนุษย์ยังคงเป็น ผู้มีส่วนร่วมเชิงสร้างสรรค์ ได้
ไมโครเวิลด์จาก Mathland ของ Seymour Papert
- วิธีที่สองคือ ไมโครเวิลด์ ซึ่งต่อยอดมาจากแนวคิดของนักการศึกษา Seymour Papert
- Papert มองว่า เช่นเดียวกับการเรียนภาษาฝรั่งเศสที่ต้องใช้ชีวิตในฝรั่งเศส หากอยากเรียนคณิตศาสตร์ก็ต้องอยู่ใน Mathland ที่คณิตศาสตร์ทำงานอย่างเป็นธรรมชาติ
- เด็กจะไม่ได้แค่ฟังคำอธิบายแบบรับฝ่ายเดียว แต่ได้สำรวจสภาพแวดล้อมตามความสงสัยใคร่รู้ และ ซึมซับแนวคิดทางคณิตศาสตร์อย่างเป็นธรรมชาติ
- เมื่อนำแนวคิดนี้มาใช้กับโค้ด ก็ไม่ใช่แค่ส่งมอบเอกสารอธิบายระบบ แต่สร้างสภาพแวดล้อมให้มนุษย์เข้าไป สัมผัสการทำงานด้วยตัวเองจากภายใน
- ไมโครเวิลด์คือ โลกขนาดเล็ก ที่ออกแบบให้สังเกตหลักการเฉพาะและการเปลี่ยนสถานะได้ง่าย แทนที่จะเปิดเผยทั้ง production system จริงทั้งหมดตรง ๆ
สำรวจ Prolog interpreter ตามแกนเวลา
- ตอนพัฒนา Prolog interpreter นั้น ยากที่จะเข้าใจอย่างเป็นสัญชาตญาณ ว่าภายในกำลังเกิดอะไรขึ้น
- จึงสร้าง ดีบักเกอร์เฉพาะทาง ร่วมกับเอเจนต์ เพื่อสำรวจกระบวนการทำงานทีละขั้น
- ในดีบักเกอร์นี้สามารถตรวจดูสิ่งต่อไปนี้ได้โดยตรง
- เลื่อนเวลา execution ไปข้างหน้าหรือย้อนกลับ
- ดูค่า ที่อยู่บนสแตกปัจจุบัน
- ตรวจสอบ ว่าในแต่ละขั้นมีการประเมินกฎข้อใด
- จดโน้ต ไว้ตรงจังหวะที่กฎบางข้อถูกนำไปใช้อย่างถูกต้อง
- แทนที่จะดูแค่ผลลัพธ์สุดท้าย มนุษย์สามารถ ติดตามด้วยตัวเอง ได้ว่าการทำงานของภาษาตรรกะคลี่ไปตามเวลาอย่างไร
- แม้จะให้เอเจนต์ดีบักแทนจนแก้ปัญหาได้ แต่ความเข้าใจเกี่ยวกับ โครงสร้างการทำงาน จะเกิดขึ้นก็ต่อเมื่อมนุษย์ได้ลองควบคุมดีบักเกอร์เอง
ความต่างระหว่างให้เอเจนต์ดีบักแทน กับให้เอเจนต์สร้างเครื่องมือเพื่อความเข้าใจ
- “เอเจนต์หาปัญหาและแก้ให้” กับ “เอเจนต์สร้างเครื่องมือให้มนุษย์ใช้สำรวจปัญหา” ให้ ผลลัพธ์คนละแบบ
- แบบแรกให้ผลลัพธ์ได้เร็ว แต่ ความเข้าใจของมนุษย์ต่อกระบวนการภายใน อาจแทบไม่เพิ่มขึ้น
- แบบหลังให้ กระบวนการสำรวจ ที่มนุษย์ได้ดูสถานะการทำงาน ตั้งสมมติฐาน และตรวจสอบผลด้วยตัวเอง
- จึงสามารถมอบงานเขียนโค้ดบางส่วนให้เอเจนต์ได้ ขณะเดียวกันก็ยังให้มนุษย์เป็นผู้ทำ การคิดและการสำรวจที่สำคัญ ด้วยตัวเอง
- นี่คือการขยายบทบาทของเอเจนต์จากผู้ให้คำตอบ ไปสู่ ผู้สร้างสภาพแวดล้อมเพื่อความเข้าใจ
ทำเว็บมิเกรชันให้เหมือนเกม
- ตอนย้ายเว็บไซต์ส่วนตัวจากเฟรมเวิร์กหนึ่งไปอีกเฟรมเวิร์กหนึ่ง Claude ได้เขียน สคริปต์อัตโนมัติ ให้
- แต่เพราะยังไม่คุ้นกับเฟรมเวิร์กใหม่ ต่อให้อ่านสคริปต์แล้วก็ยากจะประเมินได้เกินกว่า “ดูคร่าว ๆ แล้วน่าจะถูก”
- เพื่อแก้ปัญหานี้ จึงขอให้ Claude สร้าง ศูนย์บัญชาการในรูปแบบวิดีโอเกม ที่ทำงานย้ายระบบนั้นโดยตรง
- ในศูนย์บัญชาการนี้สามารถดูขั้นตอนต่อไปนี้แบบภาพได้
- กดปุ่มเพื่อ รันขั้นตอนมิเกรชันทีละขั้น
- แสดงเว็บไซต์เดิมและเว็บไซต์ใหม่ เคียงกันคนละด้านของหน้าจอ
- ดูการเปลี่ยนแปลง ของเว็บไซต์ใหม่ในแต่ละขั้น
- สังเกต ว่า file tree เปลี่ยนไปตามลำดับอย่างไร
- แทนที่จะรันการแปลงทั้งหมดทีเดียว ผู้ใช้จะได้ สัมผัสด้วยตัวเอง ว่าเว็บไซต์ใหม่ค่อย ๆ มีชีวิตขึ้นมาทีละขั้นอย่างไร
- จึงได้ความเข้าใจใกล้เคียงกับการย้ายทุกไฟล์ด้วยมือ แต่มีทั้งงานที่ต้องทำและสภาพแวดล้อมสำหรับสังเกต เตรียมไว้ล่วงหน้า ทำให้ไปได้ เร็วกว่าอย่างมาก
สร้างโค้ดเพื่อทำความเข้าใจโค้ด
- โค้ดที่เอเจนต์เขียนได้ไม่ได้จำกัดแค่ฟีเจอร์ของผลิตภัณฑ์หรือสคริปต์อัตโนมัติ
- มันยังสร้าง เครื่องมือชั่วคราว สำหรับช่วยให้มนุษย์เข้าใจโค้ดอื่นได้ด้วย เช่น
- เครื่องมือแสดงภาพการทำงาน
- ดีบักเกอร์แบบทีละขั้น
- หน้าจอเปรียบเทียบซ้าย-ขวา
- ตัวแสดงการเปลี่ยนแปลงของ file tree
- คำอธิบายแนวคิดแบบโต้ตอบ
- ศูนย์บัญชาการ ที่แบ่งงานออกเป็นขั้นเล็ก ๆ
- ต่อให้เครื่องมือเหล่านี้ไม่ใช่ product code ที่ต้องดูแลระยะยาว ก็ยัง มีคุณค่ามากพอ
- เมื่อ AI ลดต้นทุนของการสร้างโค้ดลง สภาพแวดล้อมการเรียนรู้แบบใช้ครั้งเดียว ที่สร้างขึ้นเฉพาะสำหรับคนหนึ่งคนและงานหนึ่งงาน ก็เริ่มเป็นสิ่งที่ทำได้จริง
ในทีมต้องเข้าใจร่วมกัน
- การที่แต่ละคนเข้าใจระบบได้เองนั้น ยังไม่พอสำหรับการทำงานเป็นทีม
- สมาชิกทีมต้องมี mental model ร่วมกัน จึงจะใช้คำสั้น ๆ แล้วนึกถึงโครงสร้างและการทำงานชุดเดียวกันได้
- หากมีคำศัพท์และภาพร่วมกัน ก็จะแลกเปลี่ยนไอเดียแบบฉับพลันและ พัฒนาทิศทางใหม่ร่วมกัน ได้ง่ายขึ้น
- ในทางกลับกัน หากแต่ละคนทำงานอย่างโดดเดี่ยวกับเอเจนต์ของตัวเอง ก็จะเกิดปัญหา เช่น
- ใช้คำเดียวกันแต่หมายถึง คนละอย่าง
- ไม่สามารถแบ่งปัน สมมติฐานของแผนทางเทคนิค ได้
- แม้รวมผลลัพธ์เข้าด้วยกันได้ แต่ ความเข้าใจไม่ได้ถูกรวมตามไปด้วย
- การใช้ AI ในทีมจึงไม่ใช่แค่เรื่องเพิ่มผลิตภาพของแต่ละคน แต่คือการ สร้างความเข้าใจร่วมกันของทั้งทีม
ทิ้งงานของเอเจนต์และมนุษย์ไว้ในพื้นที่ร่วมกันเดียวกัน
- ใน Notion สามารถ รันเอเจนต์ Claude และ Cursor ภายในหน้าเอกสาร ได้
- แผนทางเทคนิคที่เอเจนต์เขียนจึงถูกสร้างขึ้นมาเป็น หน้าเอกสารที่ทำงานร่วมกันได้ โดยพื้นฐาน
- สมาชิกทีมสามารถตรวจแผนที่เอเจนต์สร้างได้ตรงนั้นเลย โดยไม่ต้องคัดลอกไปยังช่องทางอื่นแยกต่างหาก
- คอมเมนต์ ในประโยคที่ต้องการ
- ตั้งคำถาม กับตัวเลือกในการ implementation
- แก้ไขแผน ร่วมกัน
- ทิ้งทั้งการถกเถียงของทีมและผลลัพธ์จากเอเจนต์ไว้ใน บริบทเดียวกัน
- แทนที่เอเจนต์จะทำงานอยู่ในไซโลส่วนตัวของแต่ละคน มนุษย์และเอเจนต์จึงได้ คิดโดยมีเอกสารร่วมเป็นศูนย์กลาง
- พื้นที่ร่วมกันนี้ไม่ใช่แค่ที่เก็บผลลัพธ์ แต่คือ สถานที่ที่ทีมใช้สร้าง mental model ร่วมกัน
จุดประสงค์ของคอมพิวเตอร์คือการเสริมพลังมาตั้งแต่แรก
- ปัญหาเรื่องคำอธิบาย/ควิซ/ไมโครเวิลด์เพื่อทำความเข้าใจโค้ด ไม่ได้จำกัดอยู่แค่การเขียนโปรแกรม
- มนุษย์ต้องการความรู้ไม่ใช่แค่เพื่อใช้ตรวจผลลัพธ์ แต่เพื่อเข้าใจว่าโลกทำงานอย่างไร และเพื่อมีส่วนร่วมกับการเปลี่ยนแปลงนั้น
- Alan Kay เคยวาดภาพคอมพิวเตอร์ไว้เมื่อราว 50 ปีก่อนว่าเป็น สื่อการศึกษาแบบใหม่ ที่ดีกว่าหนังสือ
- ในภาพยุคนั้นมีเด็ก ๆ มองอุปกรณ์คล้ายแท็บเล็ต แต่ไม่ได้กำลังนั่งดูวิดีโอแบบรับอย่างเดียว
- พวกเขากำลังควบคุม การจำลองฟิสิกส์แบบโต้ตอบ
- เล่นเกมพร้อมกับ แก้โค้ดโดยตรง
- และ ดูผล ว่าโค้ดที่แก้แล้วเปลี่ยนการเคลื่อนไหวทางกายภาพอย่างไร
- คอมพิวเตอร์จึงอาจเป็นสื่อแบบไดนามิก ที่ให้เราขยับ เปลี่ยน และทำความเข้าใจแนวคิดซับซ้อนได้ ไม่ใช่แค่เครื่องส่งข้อมูลแบบนิ่ง
ไม่ใช่แค่อัตโนมัติ แต่คือการมีส่วนร่วมที่ลึกกว่าเดิม
- ผู้เขียนสรุปประเด็นนี้ด้วย มีม ที่นักบินอวกาศคนหนึ่งมองโลกแล้วถามว่า “จุดประสงค์ของคอมพิวเตอร์คือการสร้างการจำลองแบบไดนามิกเพื่อทำความเข้าใจแนวคิดซับซ้อนงั้นหรือ” และนักบินอวกาศด้านหลังก็ตอบว่า “ก็เป็นแบบนั้นมาตลอด”
- หากมองว่าจุดประสงค์ของคอมพิวเตอร์และ AI มีไว้แค่เอางานของมนุษย์ออกไป มนุษย์ก็อาจถูก ผลักออกไปนอกระบบ
- แต่ถ้าใช้ AI เพื่อสร้างคำอธิบาย/การจำลอง/ไมโครเวิลด์/พื้นที่ร่วมกัน มนุษย์ก็จะ เข้าใจแนวคิดได้มากขึ้นและลึกขึ้น
- เมื่อ AI ลดต้นทุนของการสร้างการจำลองลง เราก็จะสามารถสร้าง สภาพแวดล้อมเฉพาะทางตามต้องการ เพื่อเรียนรู้แนวคิดหนึ่ง ๆ ได้ทุกเมื่อ
- เป้าหมายจึงไม่ใช่แค่เอามนุษย์ออกจากลูป แต่คือทำให้มนุษย์ เข้าไปอยู่ในลูปได้ลึกกว่าเดิม
บทความที่เกี่ยวข้อง
- Enough AI copilots! We need AI HUDs - อินเทอร์เฟซ AI ที่ก้าวเลยจากโคไพลอต ไปสู่การขยายความสามารถทางความคิดของมนุษย์อย่างตรงจุดยิ่งขึ้น
- AI-generated tools can make programming more fun - กรณีศึกษาที่ใช้ AI สร้าง UI ดีบักเกอร์แบบเฉพาะทางเพื่อให้มนุษย์ ทำโปรแกรมด้วยตัวเองได้ดีขึ้น
- Code like a surgeon - แนวทางที่มอบหมายงานซ้ำซ้อนจุกจิกออกไป แล้วให้มนุษย์ โฟกัสกับงานแกนหลัก
2 ความคิดเห็น
หากต้องการขจัดคอขวดออกไปอย่างสิ้นเชิง
เพราะโครงสร้างการรับรู้และความจำของมนุษย์แบ่งออกเป็นความจำระยะสั้นและความจำระยะยาว ต่อให้พยายามเพิ่มความเร็วในการเขียนโค้ดของ AI ด้วยวิธีแบบนี้แค่ไหน ผมก็อยากบอกว่าการที่มนุษย์คอยตรวจสอบเป็นระยะ ๆ และสะสมความจำระยะสั้นนั้นมีประสิทธิภาพที่สุดต่อหนี้ทางการรับรู้