ผู้ใช้กำลังหงุดหงิดอย่างเห็นได้ชัด

 (pscanf.com)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ความล้มเหลวของ coding agent ทำให้รู้สึกหงุดหงิดยิ่งกว่าความผิดพลาดของเครื่องมือทั่วไป เพราะ UX แบบสนทนาสร้างความรู้สึกเหมือนกำลังทำงานกับคน
  • แม้เอเจนต์จะตอบว่าเป็น ผู้ช่วย AI ที่ไม่มีอารมณ์ แต่ด้วยน้ำเสียงเป็นมิตร การชมเชย และการโต้แย้งอย่างนุ่มนวล ทำให้มัน ดูเหมือนเพื่อนร่วมงาน
  • เมื่อความผิดพลาดเดิมเกิดซ้ำ แม้จะมีทั้งคำขอโทษ การอัปเดตหน่วยความจำ และคำสัญญาว่า “จะไม่ทำแบบนั้นอีก” ก็อาจยังไม่สามารถหลุดพ้นจาก เส้นทางเชิงความน่าจะเป็น ได้
  • กับเพื่อนร่วมงานที่เป็นมนุษย์ คนเรามักยับยั้งการแสดงความโกรธ แต่กับ เอเจนต์กลับระบายอารมณ์ได้เต็มที่ ทำให้ความคับข้องใจไม่ถูกคลี่คลายและยิ่งชัดเจนขึ้น
  • ทางแก้อาจเป็นการลดท่าทีที่ดูเหมือนมนุษย์ และใช้น้ำเสียงที่ เป็นเชิงคลินิกและเป็นหุ่นยนต์มากขึ้น แต่ตัวอินเทอร์เฟซแบบสนทนาเองก็ยังทำงานได้ดีในหลายด้าน

ความคับข้องใจที่ UX แบบสนทนาสร้างขึ้น

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

เครื่องมือที่ดูเหมือนคนแต่ไม่รับผิดชอบ

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

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

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

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Hacker News

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

    • บริษัท AI หลายแห่งก็ฝึกและปล่อย โมเดลเฉพาะงาน กันอยู่แล้ว
      ผมใช้ Mistral เป็นหลัก โดย Codestral คุยสนทนาได้แย่มาก แต่เก่งที่สุดเรื่อง “autocomplete แบบมหัศจรรย์” และก็ทำงานประเภทพรอมป์ต์ครั้งเดียว+สร้างจากบริบท เช่น เขียน commit log ได้ดี Document.AI ใช้แบบสนทนาแทบไม่ได้เลย แต่ถ้าเอาไปแทน OCR หรือเอาไปต่อกับ pipeline สำหรับทำ semantic indexing ของเอกสารก็ค่อนข้างดี
      เพราะงั้นสิ่งที่ขาดจึงดูเหมือนจะเป็นอินเทอร์เฟซมากกว่าตัวโมเดล เช่น ถ้ามี zsh/bash fork หรือ wrapper ที่ต่อกับโมเดลซึ่งฝึกมาสำหรับการโต้ตอบบน command line ก็น่าจะดี แทนที่จะพิมพ์ git commit --fixup=... ก็พูดว่า “ช่วย fixup commit ที่แก้ชื่อเต็มทั้งหมดให้หน่อย” หรือ “ใช้ ffmpeg แปลง some.mov เป็น mp4 แบบไม่มีเสียง แต่คงคุณภาพกับอัตราส่วนเดิมไว้” แล้วมันแปลงเป็นคำสั่งให้ดู จากนั้นค่อยตั้งว่าอนุญาต/ปฏิเสธ/allowlist/blocklist แล้วจึงรัน
      งานอย่างการแปลภาษา ร่างอีเมล หรืออ่านเอกสารก็ควรทำงานเป็นปุ่ม ปุ่มลัด หรือ tab completion ไม่ใช่การสนทนาเหมือนกัน บริษัทที่แก้เรื่องนี้ได้ดีใน IDE น่าจะชนะในการแข่ง เครื่องมือเขียนโค้ด AI และที่ Zed แสดงปุ่ม “git conflict found, resolve with AI” แม้จะยังเปิดเธรดสนทนาขึ้นมา แต่ก็ดูเป็นก้าวที่ไปในทิศทางที่ถูกต้อง
    • ผมเคยใช้ autocomplete ของ Copilot แค่กับ C# แต่มันไม่ใช่แค่สู้ IntelliSense ไม่ได้ มันยังแย่กว่าอัลกอริทึม autocomplete พื้นฐานที่สุดเท่าที่นึกออกอีก เลยปิดทิ้งภายในวันเดียว
    • เราสร้างเครื่องมือแบบไม่ใช้การสนทนามาแล้ว แต่พูดตรง ๆ ว่าขายยาก เพราะคนส่วนใหญ่นึกถึง อินเทอร์เฟซแบบสนทนา เป็นค่าเริ่มต้น และฐานลูกค้าก็จำกัดอยู่แค่คนที่เจอปัญหาจริง ๆ ดูเหมือนว่าคนส่วนใหญ่ตอนนี้ยังไม่ได้รู้สึกไม่สะดวกมากพอที่จะไม่ยอมประนีประนอมด้วยการคุยกับมัน
    • แชตบอตเป็นเพียงทางแก้ชั่วคราวที่เอามาแปะบน ประสบการณ์ผู้ใช้ ที่พังอยู่ ผมพยายามอธิบายเรื่องนี้ในบริษัทอยู่พักหนึ่ง แต่ทุกคนกำลังเคลิ้มไปกับกระแส UX ที่ดีต้องใช้การคิดลึกและความสร้างสรรค์ แต่การเอาแชตบอตมาแปะเพิ่มไม่ได้ต้องใช้สิ่งนั้น
    • เอาจริง ๆ แล้วน่าลอง vibe coding ดูสักครั้ง ตอนนี้มันคนละระดับกับช่วงที่คำนี้เพิ่งเกิดใหม่ ๆ และดีขึ้นมาก
      ผมทำงานได้เยอะมากโดยใช้แค่เอเจนต์กับรีวิว PR บนเว็บโดยไม่ต้องเปิด editor และจะเปิด code . แค่เป็นครั้งคราวเวลา必要 ลองฝึกกับโปรเจกต์ส่วนตัวสบาย ๆ แบบเล่นเกมดู พอเวลาผ่านไปมันจะหงุดหงิดน้อยลง คล้ายกับการหัดเล่นสกีหรือโบว์ลิ่ง

  • การด่าโมเดลช่วยให้มันคิดใหม่และแก้ความผิดพลาดได้จริงค่อนข้างบ่อย Codex, Claude, Qwen และ Gemma/Gemini ก็คล้าย ๆ กันหมด
    ไม่แน่ใจว่ามันตีความว่าเป็นสัญญาณว่า “ต้องตั้งใจและเข้มงวดกว่านี้” หรือว่าผู้ให้บริการตรวจจับความหงุดหงิดของผู้ใช้แล้วเปลี่ยนไปใช้โมเดลที่ฉลาดกว่า แต่เวลาเจอความผิดพลาดเดิมซ้ำ ๆ แล้วด่ามัน มันมักหลุดออกจากอาการตันและกลับเข้าสู่ทางที่ถูกต้องได้ หรือไม่ก็คงเป็นแค่ การระบายอารมณ์

    • งานวิจัยนี้ทำให้นึกถึงเรื่องนั้น: https://arxiv.org/pdf/2510.04950
      มันแสดงให้เห็นว่า “ความหยาบคาย” หรือ “ความหยาบคายอย่างมาก” เพิ่มความแม่นยำของผลลัพธ์ได้ ฟังดูน่าสงสัยแต่ก็น่าอ่านดี โดยเฉพาะพรอมป์ต์ในตาราง 1 ด้านบนของหน้า 3 ที่ยอดเยี่ยมมาก และเดาว่าพวกเขาคงลองพรอมป์ต์อื่นที่ไม่ได้ใส่ไว้ในงานด้วย
    • ผมไม่อยากสร้างนิสัยที่อาจลามไปสู่ปฏิสัมพันธ์ที่ไม่ใช่กับ LLM
    • ผมก็รู้สึกคล้ายกัน ไม่มั่นใจว่ามันช่วยจริงไหม แต่แทบทุกวันจะมีกรณีที่ Opus แก้ไม่ได้เลยถ้าพูดอธิบายดี ๆ พอผมด่าเข้าไปกลับแก้ได้เฉย
      เมื่อวาน Opus ยืนกรานว่าเป็นปัญหาที่ API เพราะบอกว่าฟิลด์บางตัวไม่มี ทั้งที่ผมก็โชว์ JSON กับล็อกให้ดูแล้ว แต่มันก็ยังพูดซ้ำว่า “คงเป็นปัญหาชั่วคราว” ผมหงุดหงิดเลยด่าไปประโยคหนึ่งแบบจัดเต็ม ปรากฏว่าวิธีแก้ถัดมาถูกต้อง ทั้งที่ก่อนหน้านั้นมันตอบผิดแนวเดิมประมาณ 10 ครั้ง กรณีแบบนี้ค่อย ๆ น้อยลงก็จริง แต่ก็ยังเป็นสถานการณ์ที่จริง ๆ แล้วผมน่าจะลงมือทำเอง และก่อนจะเริ่มก็ไม่รู้ด้วยว่าโมเดลจะดันทุรังยึดสาเหตุผิด ๆ ไปได้นานแค่ไหน ผมไปถึงคำตอบหลังพรอมป์ต์ประมาณ 11 ครั้งใน /clear Opus 4.7 xhigh ที่มีบริบท 1 ล้านโทเค็น
    • ตั้งแต่มีซอร์สโค้ดรั่วที่เผยให้เห็นว่ามีการใช้คำด่าเป็นตัวกระตุ้นพฤติกรรมบางอย่าง พอเห็นอาการ reasoning ไม่พอหรือหลอน ผมเลยตั้งใจด่ามันเลย แถมยัง grep ย้อนหลังได้ง่ายขึ้นด้วยเวลาจะวิเคราะห์ว่ามันเกิดบ่อยแค่ไหน
    • มันแทบจะเป็น แนวทางแบบ Linus Torvalds เลย อาจเป็นสิ่งที่ควรเรียนรู้จากวงการ FOSS ก็ได้

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

  • มีบทความก่อนหน้านี้ที่พูดถึงผลกระทบทางจิตวิทยาและสังคมของประเด็นนี้อย่างลึกขึ้น: https://medium.com/@livestock.dev/we-were-promised-liberatio...

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

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

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

    • ปัญหาเรื่อง “สร้างวิธีแก้ให้เข้ากับข้อสรุปของตัวเอง” ฉันแก้ด้วย วิศวกรรมคอนเท็กซ์ ที่เข้มงวด หัวใจสำคัญคือ skill, MCP และเหนือสิ่งอื่นใดคือการสลับ context window
      ตัวอย่างเช่น ใน TDD ถ้าให้โมเดลเดียวกันเขียนทั้งเทสต์และโค้ด มันแทบจะเลือกวิธีแก้ไว้ก่อนเสมอ แล้วค่อยฝืนเขียนเทสต์ให้เข้ากับมัน เพราะงั้นฉันจึงสั่งให้ใช้ซับเอเจนต์ แต่เครื่องมือที่ช่วยให้เห็นว่ามีคอนเท็กซ์อะไรถูกส่งต่อระหว่างเอเจนต์กับซับเอเจนต์นั้นมีน้อยเกินไป
      วิธีที่ได้ผลดีคือให้หนึ่งเธรดเขียนเทสต์อย่างเดียว มันอ่านโค้ดไม่ได้ หรืออ่านได้แค่ไดเรกทอรีเทสต์หรือบางส่วนเท่านั้น จากนั้นอีกเธรดในคอนเท็กซ์ใหม่จะรันเทสต์เพื่อยืนยันว่ามันล้มเหลว และเมื่อเทสต์ผ่านก็ให้หยุด implementation ทันที พร้อมห้ามแก้เทสต์ อีกคอนเท็กซ์ใหม่หนึ่งก็ให้รีแฟกเตอร์ตาม skill สำหรับรีแฟกเตอร์แบบเข้มงวด งานเยอะมาก และน่าขันที่ skill ที่เอเจนต์เขียนขึ้นมาก็ค่อนข้างแย่เลยต้องแก้มือเยอะ แต่ผลตอบแทนก็คุ้มหวังได้

  • ฉันคิดว่าปัญหา UX อยู่ที่อื่น ผู้ใช้จำนวนมากอาจไม่รู้ว่า context window ของเอเจนต์มีข้อจำกัด และมีการบีบอัดอย่างชาญฉลาดเกิดขึ้นตลอดเวลาเพื่อให้มันดูเหมือนไม่สิ้นสุด แต่ความหมายของมันคือเอเจนต์จำเป็นต้องลืมบางส่วนแน่นอน
    ผลก็คือผู้ใช้จะใช้ coding session หรือ chat session เดิมซ้ำไปเรื่อย ๆ ทั้งที่ถ้าเป็นงานที่ไม่เกี่ยวกัน การเริ่มใหม่จะดีกว่า

    • ฉันไม่คิดว่านี่เป็นปัญหาเรื่องคอนเท็กซ์ Claude Opus 4.7 มีคอนเท็กซ์ใหญ่กว่าก่อนมาก แต่จากประสบการณ์ของฉัน การทำตามคำสั่งกลับแย่ที่สุด และแม้แต่พรอมป์ต์ตั้งค่าความชอบเล็ก ๆ ก็ยังถูกเมินแบบหมดจดตั้งแต่ข้อความแรกหรือข้อความที่สองด้วยซ้ำ ต่อให้ข้อความยาวไม่กี่ตัวอักษรก็ยังเป็นแบบนั้น ดังนั้นฉันคิดว่านี่เป็น ปัญหาการฝึก ล้วน ๆ
    • ไม่น่าคิดว่าผู้เขียนจะไม่เข้าใจเรื่องระดับนั้นจนดูเป็นคนง่าย ๆ
      ปกติฉันทำงานกับเซสชันต่ำกว่า 300k โทเคน ใช้ Opus 4.7 xhigh และดูเหมือนว่าจะมีรูรั่วใน world model หรือมีบางส่วนที่ถูก condition ไว้แรงมาก ซึ่งจะทะลุออกมาได้ไม่ว่าคุณจะเขียนกฎใน system prompt ให้หนักแน่นและชัดเจนแค่ไหน แม้จะเป็นเซสชันใหม่ พอชนจุดแบบนั้นก็จะเข้าสู่วงจรที่หลุดออกมายาก และการด่าช่วยได้เล็กน้อย
    • ผู้เขียนและผู้อ่านในเธรดนี้น่าจะเข้าใจ ข้อจำกัดของ context window อยู่แล้ว แต่ก็ยังน่าหงุดหงิดอยู่ดี

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

    • นี่เป็นหนึ่งในสิ่งที่ฉันตระหนักอีกครั้งชัดเจนที่สุดจากการดูเพื่อนร่วมงานเรียนรู้การเขียนโค้ดแบบ “agentic” หลายคนจะพังลงไปเป็นระดับ “ก็แก้มาเลยสิ” หรือ “ทำไมมันพัง” แทบจะทันที
      ถึงแม้เอเจนต์จะถูกฝึกให้รับมือกับไวยากรณ์ที่ไม่ชัดเจนหรือกำกวม รวมถึงโครงสร้างที่แย่ได้ดีขึ้น แต่ถ้าพูดเป็นภาษาอังกฤษที่ชัดเจน มีโครงสร้าง และให้บริบทของงานครบพอ คุณภาพจะแตกต่างอย่างเห็นได้ชัด สำหรับฉันมันเป็นธรรมชาติเพราะชอบการเขียนและการอธิบาย แต่สำหรับบางคนมันดูแทบเหมือนกำแพงที่ข้ามไม่ได้ ฉันคิดว่า ทักษะการสื่อสารและการเขียน แบบนี้จะเป็นปัจจัยสำคัญที่แบ่งคนที่มีและไม่มีแต้มต่อ ระหว่างการเปลี่ยนผ่านของ “วิศวกรรม” ซอฟต์แวร์
    • ในฐานะผู้เขียน ฉันเห็นด้วยอย่างยิ่งว่าถ้าอยากได้ผลลัพธ์ที่ดีต้องสื่อสารให้ดี แต่ถึงจะสื่อสารได้สมบูรณ์แบบ ก็ไม่ได้รับประกันว่า LLM จะทำตามคำสั่งหรือตามที่ฉันจินตนาการไว้ ความน่าหงุดหงิดมักเกิดขึ้นตรงที่ฉันพูดชัดมากแล้ว แต่เอเจนต์ก็ยังไปอีกทาง
      อีกอย่าง คุณค่าบางส่วนของ coding agent คือเราไม่จำเป็นต้องแจกแจงทุกอย่างให้สมบูรณ์แบบ ถ้าต้องให้รายละเอียด implementation ทั้งหมดกับ LLM ก็เขียนโค้ดเองไปเลยดีกว่า แน่นอนว่าไม่ได้คาดหวังระดับ “ช่วยสร้างแอปเจ๋ง ๆ ที่ทำเงินให้หน่อย” แต่ก็หวังว่าจะมี ความฉลาด ระดับหนึ่งในการหาเศษชิ้นส่วนที่หายไป
    • LLM เป็นเครื่องมือ ไม่ใช่ปัญหาความล้มเหลวในการสื่อสาร มันคล้ายกับการบอกว่าการต้องเขียนทางเลี่ยง null pointer เป็นความล้มเหลวในการสื่อสารระหว่างฉันกับซอฟต์แวร์
    • ให้แม่นกว่านั้น มันคือปัญหาเรื่องการส่งต่อบริบทภายนอกอย่างมีประสิทธิภาพ สี่อย่างที่ทำให้คนใช้ AI ได้ไม่ดีคือพิมพ์ช้า ใช้คำแบบ “นั้น/นี่/อันนี้” ที่สั้นและกำกวมเกินไป ชอบสมมติว่าคู่สนทนาแชร์โลกความจริงและบริบทในหัวของตัวเองอยู่แล้ว และมีอุปสรรคทางจิตใจในการมอบหมายงานแม้กับคนที่มีความสามารถก็ตาม

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

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

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

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