- เครื่องมือ AI ส่วนใหญ่ในปัจจุบัน ยังไม่สะท้อนกระบวนการเรียนรู้ที่ยึดมนุษย์เป็นศูนย์กลาง (การดึงความจำ การลงมือทำ และการทำซ้ำร่วมกัน) — ซึ่งท้ายที่สุดคือการออกแบบแบบ ย้อนศร ที่บ่อนทำลายวงจรการเติบโตของทั้งมนุษย์และ AI
- มนุษย์เรียนรู้จาก 'กระบวนการ (process)' ไม่ใช่แค่ความรู้ และสร้างนวัตกรรมผ่านการทำซ้ำแบบร่วมกันและสะสมต่อเนื่อง แต่เครื่องมือ AI ส่วนใหญ่กลับอยู่ในรูปแบบ "คลิกปุ่ม→AI จัดการให้เอง" ซึ่ง ตัดวงจรการดึงความจำและการเรียนรู้เชิงรุกของมนุษย์ออกไป
- เครื่องมือ AI ที่พึงประสงค์ควร กระตุ้นการมีส่วนร่วมเชิงรุกและการดึงความจำของมนุษย์ในขั้นตอน “อธิบาย→สาธิต→ชี้แนะ→เสริมพลัง (Explain, Demonstrate, Guide, Enhance)” และควรมุ่งเป้าไปที่ 'การขยายศักยภาพ' ไม่ใช่การทำงานอัตโนมัติ
- ตัวอย่าง: ใน เครื่องมือสังเกตการณ์/กู้คืนระบบ AI ไม่ควรลงมือแก้ไขทันที แต่ควรมีบทบาทในการ อธิบายกระบวนการ แนะนำการกระทำ ช่วยชี้แนวทางแก้ปัญหา และเสนอแนวทางปรับปรุงภายหลัง เพื่อ ส่งเสริมการคิดและการเรียนรู้ของมนุษย์ในทุกขั้นตอน
- หาก รูปแบบที่ยึดมนุษย์เป็นศูนย์กลาง นี้หยั่งรากได้ ก็จะเกิด วงจรป้อนกลับเชิงบวก ที่ การเติบโตขององค์ความรู้ส่วนรวมและคุณภาพของ AI แข็งแรงขึ้นไปพร้อมกัน และอาจนำไปสู่นวัตกรรมในภาพรวมของเครื่องมือระบบทั้งหมด
บทนำ: ปัญหาเชิงแก่นของการเรียนรู้ของมนุษย์และ AI tooling
- เครื่องมือ AI ถูกสร้างขึ้นในทิศทางที่ไม่สนับสนุนการทำงานร่วมกันและการเรียนรู้ของมนุษย์ แต่กลับ ไร้ประสิทธิภาพและย้อนศร
- เครื่องมือถูกออกแบบมาในลักษณะที่ไม่ใช่การเสริมความสามารถของมนุษย์ แต่กลับ บั่นทอนการคิดเชิงวิพากษ์และการแก้ปัญหา
- สถานการณ์นี้ได้ก่อให้เกิด ผลเสียที่มองเห็นได้ชัดเจน แล้ว และจำเป็นต้องเปลี่ยนไปสู่แนวทางที่มีประสิทธิภาพมากกว่า
ข้อจำกัดของเครื่องมือ AI ปัจจุบัน: การพัฒนาแบบย้อนศร
- ปัจจุบัน เครื่องมือ AI ส่วนใหญ่ ดำเนินตามรูปแบบต่อไปนี้
- คลิกปุ่ม AI → ได้ผลลัพธ์ทันทีราวกับเวทมนตร์
- แสดงข้อมูลและข้อเสนอแนะจาก AI
- ใช้พรอมป์ต์ง่าย ๆ แล้วรันอัตโนมัติ
- วิธีนี้ละเลยวงจรการเรียนรู้หลักอย่าง การนิยามปัญหา การจดจำ การดึงความจำ การเรียนรู้กระบวนการ การถ่ายทอดความรู้ และการปรับปรุงแบบวนซ้ำ ของมนุษย์
- AI พยายามเข้ามาแทนที่ข้อได้เปรียบหลักของมนุษย์ ทั้งที่ตัว AI เองก็อ่อนแอในด้านนั้น
- ผลลัพธ์คือ ความสามารถในการคิดและแก้ปัญหาของมนุษย์ถดถอย → ไม่สามารถสร้างข้อมูลคุณภาพสูงได้ (จึงขัดขวางพัฒนาการของ AI ด้วย) → ก่อเป็น วงจรอุบาทว์
มนุษย์เรียนรู้อย่างไร?
- ตามทฤษฎี Retrieval Practice มนุษย์ไม่ได้เรียนรู้จากการรับข้อมูลเข้าไปเฉย ๆ แต่เรียนรู้ผ่าน การดึงความจำเชิงรุก
- ไม่ใช่การท่องจำอย่างเดียว แต่เป็น กระบวนการ “ดึง” ข้อมูลออกมาจากสมองด้วยตนเอง ที่ทำให้เกิด ผลการเรียนรู้ที่แท้จริง
- แก่นที่สำคัญที่สุดของการเรียนรู้คือ การได้มาซึ่งกระบวนการ มากกว่าตัวความรู้เอง
- เช่น เวลาหัดทำขนมปัง การเรียนรู้ ขั้นตอนการทำเค้ก (กระบวนการ) มีประสิทธิภาพกว่าการท่องจำวัตถุดิบ
- ด้วยเหตุนี้ การออกแบบที่ เน้นกระบวนการเชิงปฏิบัติ จึงเหมาะกับเครื่องมือสำหรับการทำงานร่วมกันมากกว่า
หลักการของนวัตกรรมและการเติบโตร่วมกัน
- แก่นของนวัตกรรม ไม่ได้มาจากบุคคลที่สร้างเทคโนโลยีใหม่เพียงลำพัง แต่เกิดจาก การสะสมร่วมกันของการปรับปรุงเล็ก ๆ แบบวนซ้ำ
— ไม่ใช่การสร้างสรรค์อันอัจฉริยะของคนไม่กี่คน แต่เป็นกระบวนการที่หลายคนช่วยกัน “ต่อยอดและปรับปรุง” บนองค์ความรู้เดิม
- มนุษย์ถูกปรับให้เหมาะกับ การเลียนแบบ การทำซ้ำ และการดัดแปลงจากกรณีเดิม มากกว่าการสร้างนวัตกรรมแบบโดดเดี่ยว
- ทฤษฎีการเรียนรู้แบบกลุ่มบนฐานสมอง แสดงให้เห็นว่านวัตกรรมแบบรวมหมู่นี้เหมาะกับธรรมชาติของมนุษย์อย่างยิ่ง
- ไม่ควรแยกการแก้ปัญหาออกจากนวัตกรรม แต่ควรมองว่า ความสามารถในการแก้ปัญหา การถ่ายทอดความรู้ และการเรียนรู้ร่วมกัน คือพลังขับเคลื่อนของนวัตกรรม
- หัวใจสำคัญคือ การเรียนรู้ที่เน้นกระบวนการ ความพยายามในระดับที่เหมาะสม การทำซ้ำและเสริมแรงร่วมกัน และ AI ที่ช่วยหนุนมนุษย์
- เครื่องมือ AI ควรเป็น ‘ผู้ช่วยการคิด’ ของมนุษย์ ไม่ใช่สิ่งที่ตัดสินใจและเข้ามาแทนที่ด้วยตัวเอง
การออกแบบปฏิสัมพันธ์กับ AI ที่ถูกต้อง
- AI อาจเปรียบได้กับ 'ผู้สอนที่ขี้ลืม' มากกว่าจะเป็น เพื่อนร่วมงานหรืออินเทิร์น
- เป้าหมายของ AI คือการช่วยให้ผู้ใช้ เรียนรู้ได้ด้วยตัวเอง และเรียนรู้ว่าจะต้องเรียนรู้อย่างไร
- ควรออกแบบไปในทิศทางที่เสริมกระบวนการเรียนรู้ที่มีประสิทธิภาพ (EDGE: Explain, Demonstrate, Guide, Enhance)
- อธิบาย (Explain): แนะนำกระบวนการ ชี้ขั้นตอนที่ขาดหาย ฯลฯ (ไม่ใช่แค่ “กดปุ่มนี้”)
- เสนอขั้นตอนที่ตกหล่น
- จัดทำและอธิบายคู่มือกระบวนการ
- เน้นกระบวนการที่มนุษย์ ต้องนึกและลงมือทำเอง
- ตัวอย่างที่ไม่ดี: ให้ปุ่ม 'รัน' ทันที, tooltip แจ้งข้อผิดพลาด ฯลฯ ที่ ละเลยกระบวนการดึงความจำ
- สาธิต (Demonstrate): การแปลงคิวรี การสาธิต UI บทเรียนเชิงโต้ตอบ ฯลฯ โดยเน้น การชวนให้มีส่วนร่วม ไม่ใช่ “รันอัตโนมัติ” โดยตรง
- แปลงคิวรีภาษาธรรมชาติเป็นไวยากรณ์คิวรีของระบบ
- ช่วยนำทาง UI (พาไปยังหน้าที่เกี่ยวข้องทันทีเมื่อมีการร้องขอ)
- มอบ เดโมสั้น 15 วินาทีและทิวทอเรียลแบบอินเทอร์แอ็กทีฟ
- ควรหลีกเลี่ยง 'รันอัตโนมัติ': ทำให้ความน่าเชื่อถือลดลง ปรับละเอียดไม่ได้ และทำให้ศักยภาพมนุษย์ลดลง
- AI ควรใช้ข้อมูลเพิ่มเติมและบันทึกการดึงความจำของมนุษย์ (เช่น pairing, mentoring) เป็นวัตถุดิบในการเรียนรู้ด้วย
- ชี้แนะ (Guide): การชวนตั้งคำถาม การอภิปรายจุดที่มีปัญหา การวางแผนการกระทำ ฯลฯ แบบ ถาม-ตรวจสอบเชิงโสเครติส
- หากผู้ใช้ให้แผนมาแล้ว ให้เสนอแนะขั้นตอนถัดไปและแนวทางดำเนินการ
- แนะนำเอกสารที่จำเป็น ผู้รับผิดชอบโค้ด และข้อมูลที่เกี่ยวข้อง
- สนับสนุนโมเดลการสังเกต/การเรียนรู้ และการบันทึก
- ตรวจสอบคำตอบ ตรวจสอบข้อมูลไขว้ และยืนยันความชัดเจน
- ตัวอย่างที่ไม่ดี: สนับสนุนโดยไม่ชวนคิดคำตอบ, ให้ข้อมูลมากเกินไปโดยไม่ได้ร้องขอ, วางท่าทีแบบผู้มีอำนาจ, เปิดช่องให้ใช้ปุ่ม 'ดำเนินการต่อ' ของผู้ใช้อย่างพร่ำเพรื่อ
- ควรช่วยเหลือโดยไม่รบกวน การวนซ้ำของการให้เหตุผลอย่างสมเหตุสมผล ของมนุษย์
- เสริมพลัง (Enhance): เสนอการปรับปรุงหลังการลงมือทำ เรียนรู้รูปแบบการทำซ้ำ เปลี่ยนบันทึกจากงานจริงให้เป็น postmortem ฯลฯ เพื่อสร้าง จังหวะการเรียนรู้เล็ก ๆ อย่างต่อเนื่อง
- เสนอ การปรับปรุงแบบค่อยเป็นค่อยไป ทันทีหลังหรือระหว่างการลงมือทำ
- แสดง คีย์ลัด/ฟีเจอร์เพิ่มเติม แบบไดนามิกสำหรับงานที่ทำซ้ำ
- เสนอการปรับปรุงที่ตัวกระบวนการเอง: ปรับปรุง infrastructure pipeline, แก้ไขการแจ้งเตือน, แนะนำให้ปรับปรุงการวัดผลเมื่อใช้ intuition เป็นต้น
- ส่งเสริมการเรียนรู้ระดับจุลภาคผ่านการบันทึกหลังเหตุการณ์ (โน้ต→เปลี่ยนเป็นสื่อการเรียนรู้) และการสังเกต
- รักษาศูนย์กลางการให้เหตุผลของมนุษย์ไว้ และสอดแทรก พรอมป์ต์เพื่อเสริมการดึงความจำ อย่างเป็นธรรมชาติ แทนการปรับให้เหมาะที่สุดแบบอัตโนมัติ
- โดยเฉพาะในทุกขั้นตอน ควรทำให้โครงสร้างที่ มนุษย์ต้องดึงความจำ เลือก และลงมือทำเอง แข็งแรง และให้ AI มุ่งทำหน้าที่ขยายสิ่งนั้น
- อธิบายตัวอย่างปฏิสัมพันธ์ AI ที่ดีและ anti-pattern ในแต่ละขั้น โดยอ้างอิงจากกรณีใช้งานจริง (การจัดการเหตุการณ์และเครื่องมือสังเกตการณ์)
หลักการโดยรวม
- เสริมการเรียนรู้ของมนุษย์อย่างต่อเนื่อง
- ส่งเสริมการทำงานเป็นทีม : การร่วมมือและการแบ่งปันข้อมูลแบบหมู่คณะ
- แทนการทำงานอัตโนมัติแบบ “ช่องว่าง→คำตอบที่ถูกต้อง” ให้ เร่งการมีส่วนร่วมและการลงมือทำในกระบวนการ (แต่ไม่แทนที่โดยตรงด้วยระบบอัตโนมัติ)
- หลีกเลี่ยงการได้ผลลัพธ์ทันทีจาก “ความว่างเปล่า”
- ไม่ใช่ “ใช้งานง่ายแบบไม่ต้องออกแรง” แต่เป็น เครื่องมือที่ต้องการความพยายามและการมีส่วนร่วมในระดับเหมาะสม
- สนับสนุนให้ การเรียนรู้และประสบการณ์ของทีมสะท้อนอยู่ในผลลัพธ์
ตัวอย่างที่ดีเมื่อนำไปใช้กับการเขียนโค้ด: การออกแบบแบบ 'เดินหน้า' ไม่ใช่ 'ย้อนศร'
- แทนที่จะใช้ AI สร้างโค้ดทันที
- เขียนเอกสารร่าง → วาดสถาปัตยกรรม → วางแผนการทดสอบ → เขียนโค้ดทดสอบ → เขียน stub code → สร้างโค้ด
- หลังตรวจสอบโค้ดแล้ว ให้ย้อนกระบวนการทั้งหมดเพื่อ จัดระเบียบการทดสอบ เอกสาร และสถาปัตยกรรมใหม่
- ในแต่ละขั้นตอนให้ความสำคัญกับ คำถามและการตรวจสอบ (การเสริมการดึงความจำ) และไม่ควรถามแค่ใช่/ไม่ใช่ในสถานะที่ยังตรวจสอบไม่ได้
- แนวทางการพัฒนาที่อิงการดึงความจำ จะสร้างข้อมูลการเรียนรู้/การทดสอบคุณภาพสูง และช่วยเสริมการเรียนรู้ของ AI ด้วย
ความเป็นไปได้ในการขยายสู่สายงานข้ามฟังก์ชัน (ไม่ใช่นักพัฒนา เช่น ฝ่ายสนับสนุนลูกค้า)
- ตัวอย่าง: ในสถานการณ์ที่การปฏิบัติการหยุดชะงักจากเหตุขัดข้อง ทีมสนับสนุนลูกค้า สามารถสื่อสารกับทีมพัฒนาผ่าน AI ได้
- AI จัดทำร่างแรกให้ และทีมพัฒนาช่วยตรวจสอบเพื่อเพิ่มความถูกต้อง
- ทำให้การไหลของข้อมูลแบบเรียลไทม์ระหว่างหลายองค์กร เช่น ทีมซัพพอร์ตและทีมพัฒนา เป็นไปได้ พร้อมลดภาระจากการสลับบริบท
- ผู้เชี่ยวชาญหลักไม่ถูกรบกวนมากเกินไป แต่ยัง สื่อสารตอบโต้กันได้อย่างราบรื่น เมื่อจำเป็น
- AI สามารถแปลงคำอธิบายเชิงเทคนิคตามบริบทจากทีมพัฒนาให้เป็นข้อความอธิบายที่คนทั่วไปเข้าใจได้ง่าย
- หากโครงสร้างเช่นนี้เกิดขึ้นได้จริง ก็จะเพิ่มประสิทธิภาพการเรียนรู้ร่วมกันและการทำงานร่วมกันทั้งภายในและภายนอกองค์กรได้สูงสุด
- มีศักยภาพที่จะพัฒนาเป็นเครื่องมือ รองรับ/บูรณาการหลายชั้น ได้
บทสรุป
- เครื่องมือ AI ในปัจจุบันถูกพัฒนาในลักษณะ ย้อนศรที่ทำให้ความสามารถในการเรียนรู้แบบทำซ้ำร่วมกันและการแก้ปัญหาของมนุษย์อ่อนแอลง
- จำเป็นต้องเปลี่ยนไปเน้น การเสริมการทำงานร่วมกันและการสนับสนุนกระบวนการที่มนุษย์เป็นผู้นำ
- เมื่อนั้นเองจึงจะเกิดวงจรเชิงบวกที่มนุษย์และ AI เติบโตเสริมพลังซึ่งกันและกัน ได้
- ในการออกแบบเครื่องมือ อย่าลืมว่า มนุษย์ไม่ได้เป็นเพียง 'อยู่ในลูป' แต่ตัวมนุษย์เองคือลูปนั้น
- ถึงเวลาแล้วที่เครื่องมือระบบต้องการ นวัตกรรมที่ยึดมนุษย์เป็นศูนย์กลาง
- เครื่องมือ AI แบบร่วมมือ เน้นกระบวนการ และเสริมพลัง คือกุญแจสู่นวัตกรรม
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
บทความนี้มีส่วนที่ชวนสับสนอยู่ เหมือน Weakly จะหมายถึงเอเจนต์เขียนโค้ดที่ทำงานเชิงรับมากขึ้นและคอยให้คำแนะนำเป็นหลัก คล้ายแนวทางที่ antirez บอกว่าชอบในปี 2025 แต่จริง ๆ แล้วกลับพูดถึงเอเจนต์ที่มีบทบาทในการสืบสวนและแก้ปัญหาในระบบปฏิบัติการจริง ข้อเสนอของ Weakly คือให้เอเจนต์เป็นเหมือน Clippy ที่คอยแนะนำอย่างเดียวและให้มนุษย์เป็นคนถือพวงมาลัยเอง แต่ผมไม่ค่อยเห็นว่าการให้คนต้องไปไล่ดู log หา anomaly และตั้งสมมติฐานเองนั้นมีคุณค่าอย่างไร เช่นเดียวกับที่คอมพิวเตอร์เล่นหมากรุกได้ดีกว่า AI ก็เป็นเครื่องมือที่เก่งกว่ามนุษย์โดยพื้นฐานสำหรับงานแบบนี้ Weakly ดูเหมือนจะขีดเส้นแบ่งชัดเจนระหว่างคำแนะนำกับการลงมือทำจริง แต่ผมไม่คิดว่าเส้นนั้นถูกต้อง แน่นอนว่ามีบางพื้นที่ที่เรายังปล่อยให้ AI ทำงานอัตโนมัติเต็มที่ไม่ได้ (เช่น รัน Terraform apply) แต่ในอีกหลายพื้นที่ก็ไม่มีเหตุผลที่จะต้องห้าม จุดประสงค์ของการแก้ incident สุดท้ายก็คือการแก้เหตุขัดข้องให้ได้
ตอนนี้ยังไม่มีเครื่องมือ AI ตัวไหนที่แก้ incident ได้อย่างน่าพอใจจริง ๆ ยังมีเรื่องความรับผิดชอบ และไม่ว่าอย่างไรก็ต้องมีมนุษย์เข้ามาเกี่ยวข้องเพื่อให้มั่นใจว่าการปฏิบัติการนั้นถูกต้อง
ปัญหาแก่นจริง ๆ คือจะให้สิทธิ์เข้าถึงสภาพแวดล้อม production จริงกับ AI หรือไม่ จากกรณีล่าสุดที่ AI ลบฐานข้อมูลทั้งที่มีคำสั่งว่า “ห้ามทำ” (เพราะ AI ไม่ได้ตีความคำสั่งปฏิเสธอย่าง
notได้ถูกต้องเสมอไป) ก็เห็นได้ว่ามีข้อกังวลด้านความปลอดภัยจริงจังผมสงสัยว่าเราจะให้ autonomy กับเอเจนต์ได้มากแค่ไหน ถ้าทำตามแนวปฏิบัติ DevOps ที่ดี การเปลี่ยนแปลงส่วนใหญ่ก็ควรเข้าสู่ production หลังผ่านการ commit โค้ดและ promote ผ่านหลาย environment แล้ว ไม่ใช่แค่ application code แต่รวมถึง infrastructure ด้วย ในสถานการณ์แบบนี้ผมเลยสงสัยว่าระหว่างการรับมือ incident เราจะยอมให้เอเจนต์ลงมืออัตโนมัติได้ถึงตรงไหน
ผมคิดว่าการลงมือ debug เองก็ยังมีคุณค่าอยู่ระดับหนึ่ง โดยเฉพาะถ้าเป้าหมายคือการยกระดับทักษะการเขียนโปรแกรมของตัวเอง จะเห็นชัดมาก ถ้าเทียบกับหมากรุก แม้ AI อย่าง Leela หรือ Stockfish จะวิเคราะห์ได้เร็วและลึกกว่ามาก แต่การพัฒนาฝีมือจริง ๆ มาจากประสบการณ์ที่เราวิเคราะห์ตำแหน่งด้วยตัวเอง นักหมากรุกอาชีพก็ยังฝึก tactical motifs ซ้ำ ๆ เพื่อฝึกสมองอยู่เสมอ ผมเองก็ไม่แน่ใจว่าการทำงานร่วมกับ AI จะช่วยให้เรียนรู้ได้เร็วกว่าหรือจะเรียนได้ดีกว่าแบบอิสระ และก็ยังเห็นต่างกันด้วยว่าทักษะแบบนี้จะยังมีความหมายต่อไปหรือไม่
ในการถกเรื่อง anomaly detection และ incident management จุดสำคัญอย่างหนึ่งคือปัญหาแต่ละแบบไม่เหมือนกัน และหลายปัญหาก็ทำ automation ได้ระดับหนึ่ง เส้นแบ่งสำคัญคือเมื่อไรควรส่งปัญหาให้ตัวประมวลผลเชิงรับรู้อย่าง AI จัดการ และเมื่อไรวิศวกรมนุษย์ควรเข้าแทรกแซงเอง AI เก่งเรื่องตรวจหารูปแบบขนาดใหญ่ แต่ไม่ได้แปลว่าจะตัดสินได้ถูกเสมอว่ารูปแบบนั้นมีความหมายจริงหรือไม่ แน่นอนว่ามนุษย์เองก็ไม่ได้อุดช่องว่างนี้ได้เสมอไป
ถ้ามองจากมุมของเครื่องมือ/ผลิตภัณฑ์ AI ผมคิดว่าอนาคตควรไปทาง "Intelligent Workspaces" มากกว่าจะเป็นแค่แชตบอต
ลิงก์ที่เกี่ยวข้อง
โดยพื้นฐานแล้ว สิ่งสำคัญคือสภาพแวดล้อม/แพลตฟอร์มที่ผสานความสามารถ AI เข้าไว้แนบแน่น ขณะเดียวกันก็ให้การตั้งค่า คันโยก และอำนาจควบคุมทั้งหมดอยู่กับมนุษย์ นี่เป็นงานที่ยากกว่าการ fork VSCode แบบง่าย ๆ มาก
แชตบอตสร้างได้ง่ายกว่า Intelligent Workspace มาก และ AI ก็ทำงานได้ดีแม้ไม่มีปฏิสัมพันธ์กับมนุษย์ ผมอยากเห็นวิธีใช้ AI ผ่านอินเทอร์เฟซแบบอื่นที่ไม่ใช่แชตเพิ่มขึ้นอีก
ช่วงนี้ผมทำโปรเจ็กต์ด้วย Claude Code และคิดว่าคงดีมากถ้า instance ของผมคุยและร่วมมือกับ instance ของนักพัฒนาคนอื่นได้ ทุกวันนี้แก้
CLAUDE.mdเพื่อดูแลเอกสารได้ แต่ถ้าใน CC มีฟีเจอร์ collaboration สำหรับทีมมาให้ในตัวก็คงยอดเยี่ยมมาก ถ้าใครมีข้อเสนอแนะดี ๆ ก็อยากให้แชร์ผมคิดว่าบทความนี้แสดงให้เห็นดีว่าทำไมนวัตกรรมจึงมักมาจากคนนอกวง ผู้เขียนมีกลิ่นของผู้จัดการวิศวกรรมหรือวิศวกรอาวุโสจากองค์กรใหญ่ชัดมาก จนผมรู้สึกว่าไม่ค่อยตรงกับประสบการณ์ของตัวเอง ถ้าสไตล์แบบนี้กลายเป็นแม่แบบของ AI tooling ก็กลัวว่า AI จะหยุดนิ่งอยู่กับสมมติฐานเฉพาะแบบหนึ่งเกี่ยวกับ workflow ของมนุษย์ ผมทำ R&D ด้านแอปพลิเคชัน ML เพื่อช่วยผู้เชี่ยวชาญโดเมนที่ไม่ใช่โปรแกรมเมอร์มา 15 ปี และค่อนข้างมองต่างจากหลักการของผู้เขียน การที่มุมมองต่างกันได้มากขนาดนี้แปลว่าพื้นที่การออกแบบยังใหญ่มาก และยังเร็วเกินไปที่จะสรุปว่ามีวิธีที่ถูกต้องเพียงแบบเดียว ตอนนี้ยังไม่มีใครรู้ว่า AI tooling จะเดินไปทางไหน
สิ่งที่ผมกังวลเสมอเกี่ยวกับ AI coding คือมันทำให้รักษาฝีมือไว้ได้ยากขึ้น การพิมพ์โค้ดเองโดยตรง (รวมถึง boilerplate) เป็นการฝึกแบบ Mr. Miyagi ทาสีรั้วจริง ๆ การฝึกซ้ำลักษณะนี้ทำให้แพตเทิร์นต่าง ๆ ฝังลึกในหัว และช่วยมากเวลาเราต้องตัดสินใจเชิงออกแบบในระดับที่สูงขึ้น
เทคโนโลยีในอดีต (เช่น การเขียน การพิมพ์) อาจทำให้ลายมือหรือวาทศิลป์ถดถอยลง แต่กลับขยายความสามารถในการคิดแทน แนวคิด “Bicycle-for-the-mind” ของ Steve Jobs เป็นตัวอย่างที่ดี เพียงแต่เมื่อเอาเหตุผลนี้มาใช้กับ AI ก็มีความต่างตรงที่เทคโนโลยีก่อนหน้าแก้คอขวดเรื่องการกระจายข้อมูล แต่ AI กลับพุ่งเป้าไปที่กระบวนการสร้างสรรค์โดยตรง ผมคิดว่าการใช้ AI กับงานสร้างสรรค์จะดีได้ก็ต่อเมื่อมันไม่ไปขัดขวางการพัฒนาความคิดสร้างสรรค์ของผมเอง และมนุษย์เราก็มีข้อจำกัดทั้งในเรื่อง self-control และ self-awareness
ผมมักนึกปัญหาและจินตนาการ "โค้ด" อยู่ในหัวตอนกลางคืนหรือเวลาอาบน้ำ ถ้าโครงสร้างของภาษาไม่ได้ฝังแน่นอยู่ในหัว คงทำ mental coding แบบนั้นได้ยาก
ในชีวิตประจำวันก็มีตัวอย่างคล้ายกัน:
สมัยก่อนเราเคยบัดกรีทรานซิสเตอร์กันด้วยมือ แต่ตอนนี้เทคโนโลยีก้าวหน้าไปมากจนการจะย้อนกลับไปทำเองแบบนั้นกลายเป็นภาระ ผมยังคงขยายและหดจุดโฟกัสทางความคิดสลับไปมาอยู่แบบนี้ และก็ยังคิดถึงการลงมือเขียนโค้ดเองอยู่เหมือนกัน ทุกวันนี้ผมก็ยังเขียนโค้ดเยอะอยู่
“Every augmentation is an amputation(การเสริมทุกอย่างย่อมตัดบางอย่างออก)” - Marshall McLuhan
เพราะแบบนี้ผมถึงชอบ Deep Research มาก มันเริ่มจากการตั้งคำถามเสมอ และบังคับให้ผมกำหนดให้ชัดขึ้นด้วยตัวเองว่าจริง ๆ แล้วอยากเรียนรู้อะไร ผมรู้สึกว่าแค่การเปลี่ยน UX เล็กน้อยก็สร้างความต่างใหญ่ได้มาก ทั้งในแง่ช่วยให้ผู้ใช้บริการเรียนรู้ และในทางกลับกันก็อาจทำให้คนพึ่งเครื่องมือแบบไม่ใช้วิจารณญาณ
แต่คุณเคยพิจารณาคำถามนั้นอย่างจริงจังไหม Deep Research มีประโยชน์ในบางครั้ง แต่บางที “คำถาม” นั้นก็ให้ความรู้สึกเหมือนถูกเติมเข้ามาเพื่อให้ดูดีเฉย ๆ หลายครั้งมันถามซ้ำในจุดที่ผมเขียนไว้อย่างชัดเจนและตั้งใจอยู่แล้ว และดูเหมือนไม่ได้ช่วยกระบวนการค้นหาจริงมากนัก
ในฐานะ technical writer ผมกลับไม่ค่อยใช้ Deep Research เพราะมันรบกวนงานผมมากกว่า กระบวนการวิจัย จดบันทึก และสรุปเองนี่แหละคือหัวใจที่ช่วยให้ผมเข้าใจหัวข้อนั้นอย่างลึกซึ้ง ตัวเอกสารที่ได้เป็นเพียงผลลัพธ์ปลายทางเท่านั้น ถ้า AI มาทำแทน ผมอาจได้โน้ตกลับมา แต่ไม่ได้ความเข้าใจในระดับเดียวกัน การอ่านเอกสารที่ AI เขียนให้ไม่สามารถแทนที่ประสบการณ์ตรงได้
ผมคิดว่าบทความนี้สับสนกับประเด็นหลักของการนำ AI มาใช้ เป้าหมายของ AI ไม่ใช่เพื่อทำให้มนุษย์ฉลาดขึ้น แต่เพื่อกำจัดงานซ้ำ ๆ ที่ความคิดสร้างสรรค์ของมนุษย์ไม่ได้รับผลตอบแทนอย่างมีนัยสำคัญ และยกระดับผลิตภาพของกระบวนการโดยรวม
จากประสบการณ์ของผม วิธีใช้ AI ตอนเขียนโค้ดให้ได้ผลที่สุดมีดังนี้:
regexโหดเกินไป)ไม่นานมานี้ผมช่วยคุณพ่อเตรียมสไลด์นำเสนอ คุณพ่อมีข้อมูลครบ แต่ไม่ใช่นักออกแบบ เลยลำบากเรื่องทำสไลด์ให้ดูดี ผมลองใช้แอปสร้างสไลด์ด้วย AI หลายตัว แม้มันจะดูเท่ แต่สุดท้ายกลับไม่ช่วยในสิ่งที่ผู้ใช้ต้องการจริง ๆ คือการ “ปรับดีไซน์ให้ดีขึ้น” สุดท้ายผมสรุปว่าทำมือให้สวยขึ้นเองยังดีกว่ามาก
ผมเห็นด้วยเต็มที่ว่า workflow แบบ “เริ่มจากสถาปัตยกรรมและการออกแบบการทดสอบ แล้วค่อยนำไปใช้กับโค้ดจริง” มีประสิทธิภาพกว่า 100% แค่เปลี่ยนนิสัยการทำงานก็ทำได้แล้ว แม้ไม่มีเครื่องมือเฉพาะทางก็ตาม (แน่นอนว่าถ้ามีเครื่องมือเฉพาะหรือ standard prompt ก็จะยิ่งดี)
docker-composeและงานที่ต้องทำจริง ๆ มีประมาณนี้:มนุษย์เป็นสิ่งมีชีวิตที่เชี่ยวชาญมากกับการทำซ้ำแบบสะสมผล (continuous improvement) นี่แหละจึงเป็นเหตุผลว่าทำไมการ brainstorm ถึงได้ผลดีเป็นพิเศษเมื่อทำเป็นกลุ่ม ใน cognitive psychology มีทฤษฎีว่าด้วย “วัฒนธรรม” ของการเรียนรู้และนวัตกรรมแบบสะสมร่วมกันอยู่ด้วย เราชอบพูดกันว่า “ยืนอยู่บนไหล่ของยักษ์” ซึ่งไม่ใช่แค่คำพูดสวย ๆ แต่มันคือวิธีที่มนุษย์ทำงานจริง ความคิดสร้างสรรค์ในที่สุดแล้วก็คือการค้นหา และเป็นการค้นหาเชิงสังคมด้วย มันไม่ได้เติบโตอยู่แค่ในสมองภายใน แต่เกิดจากปฏิสัมพันธ์ระหว่างสมองกับสภาพแวดล้อม รวมถึงชั้นทางสังคมและวัฒนธรรม เพราะอย่างนี้ผมจึงไม่ค่อยสนใจว่า LLM “เข้าใจ” จริงไหม แค่ค้นหา สร้างไอเดีย และตรวจสอบได้จริง สำหรับผมก็พอแล้ว อีกทั้งผมคิดว่าตัวการค้นหาเองสำคัญกว่าพื้นฐานรองรับ (substrate) เสียอีก แม้พื้นฐานที่ต่างกันอาจเข้าถึงพื้นที่ค้นหาที่ต่างกันก็ตาม