ปีแห่ง Vibes

 (lucumr.pocoo.org)
21 คะแนน โดย GN⁺ 2025-12-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ปี 2025 คือปีที่ เครื่องมือเขียนโค้ดแบบ agentic เริ่มเปลี่ยนวิธีการเขียนโปรแกรมอย่างจริงจัง โดยเปลี่ยนจากการพิมพ์คีย์บอร์ดด้วยตัวเองไปสู่การ รับบทเป็น engineering lead ที่คอยกำกับโปรแกรมเมอร์ฝึกงานเสมือน
  • เริ่มจากความหมกมุ่นกับ Claude Code แล้ววนซ้ำไปมาระหว่างการสร้างและใช้งานเอเจนต์ของตนเอง จนยิ่งมั่นใจว่า การสร้างโค้ด, การเข้าถึงระบบไฟล์, การเรียกใช้เครื่องมือโปรแกรมผ่าน interpreter glue และการเรียนรู้แบบอิงทักษะ ยังเป็น แนวทางที่ดีที่สุด
  • การผสาน LLM เข้ากับการรันเครื่องมือได้ขยายจากการสร้างโค้ดไปสู่ การจัดการงานประจำวัน ทำให้ต้องกลับมาทบทวนความสัมพันธ์กับเครื่องจักร และกังวลต่อการเกิด ความผูกพันกึ่งสังคม (Parasocial Bond) โดยไม่ตั้งใจ
  • เนื่องจาก ระบบควบคุมเวอร์ชันและเครื่องมือรีวิวโค้ด แบบเดิมไม่เหมาะกับการตรวจทานโค้ดที่ AI สร้างขึ้น จึงจำเป็นต้องมีระบบใหม่ที่ติดตามได้ทั้งประวัติพรอมป์ต์และเส้นทางที่ล้มเหลว
  • การเขียนโค้ดด้วย AI ทำให้เกิด ความเห็นที่พึ่งพา 'vibes' มากมายโดยไม่มีทั้งประสบการณ์และข้อมูลรองรับ และจำเป็นต้องมีฉันทามติทางสังคมแบบใหม่ต่อ PR ที่สร้างโดย AI แล้วถูกโยนเข้าโอเพ่นซอร์สอย่างไม่ยั้งคิด

การเปลี่ยนแปลงในปี 2025

  • เป็นปีที่ไม่ได้แค่ลาออกจากบริษัทเพื่อเริ่มบริษัทใหม่ แต่ยังเปลี่ยนวิธีเขียนโปรแกรมเดิมอย่างสิ้นเชิง
  • ตั้งแต่เดือนมิถุนายน ใช้ Claude Code แบบเกือบทั้งหมดในลักษณะ hands-off แทน Cursor
    • "ถ้าเมื่อ 6 เดือนก่อนมีคนบอกว่าฉันจะชอบบทบาท engineering lead ของโปรแกรมเมอร์ฝึกงานเสมือนมากกว่า ก็คงไม่เชื่อ"
  • เขียนบล็อก 36 โพสต์ คิดเป็นราว 18% ของโพสต์ทั้งหมดในบล็อกนับตั้งแต่ปี 2007
    • หลังจากตกลงไปใน rabbit hole ของเอเจนต์ ก็เต็มไปด้วยความอยากรู้อยากเห็นจนได้พูดคุยกับโปรแกรมเมอร์ ผู้ก่อตั้ง และคนอื่น ๆ ราว 100 ครั้ง
  • ปี 2025 ยังเป็นปีที่โลกโดยรวมไม่ค่อยดีนัก จึงสร้าง บล็อกแยกต่างหาก (dark.ronacher.eu) เพื่อแยกความคิดเหล่านั้นออกไป

ปีแห่งเอเจนต์

  • เริ่มต้นจากความหมกมุ่นกับ Claude Code ในช่วงเดือน 4~5 แล้วใช้เวลาหลายเดือนวนซ้ำระหว่างการสร้างเอเจนต์เองกับใช้งานเอเจนต์ของคนอื่น
  • ในโซเชียลมีเดีย ความเห็นเกี่ยวกับ AI ปะทุออกมาในหลากหลายทิศทาง
  • ตอนนี้มาถึงจุดที่ค่อนข้างนิ่งแล้ว: โฟกัสที่ การสร้างโค้ด, ระบบไฟล์, การเรียกใช้เครื่องมือเชิงโปรแกรมผ่าน interpreter glue และการเรียนรู้แบบอิงทักษะ
    • วิธีที่ Claude Code สร้างความเปลี่ยนแปลงยังคงล้ำหน้าที่สุด และการที่ผู้ให้บริการ foundation model หันมาให้ความสำคัญกับสกิลก็ยิ่งตอกย้ำความเชื่อนี้
  • สิ่งที่น่าประหลาดใจคือการกลับมาของ TUI (ส่วนติดต่อผู้ใช้แบบข้อความ) อย่างชัดเจน
    • ตอนนี้ใช้ Amp, Claude Code, Pi บนบรรทัดคำสั่ง
    • Amp ให้ความรู้สึกเหมือน Apple หรือ Porsche, Claude Code เหมือน Volkswagen ราคาย่อมเยา, ส่วน Pi คือทางเลือกโอเพ่นซอร์สที่แฮกเกอร์ชอบ
    • ทั้งหมดให้ความรู้สึกเหมือนเป็นโปรเจกต์ที่สร้างโดยคนที่ใช้ผลิตภัณฑ์ของตัวเองอย่างหนักเกินพอดี แต่ก็มี trade-off ที่ต่างกัน
  • ยังคงทึ่งกับการผสาน LLM เข้ากับการรันเครื่องมือ
    • ช่วงต้นปีใช้หลัก ๆ เพื่อสร้างโค้ด แต่ ตอนนี้ใช้งานเอเจนต์กับเรื่องในชีวิตประจำวันมากขึ้น
    • คาดว่าในปี 2026 จะมีความคืบหน้าที่น่าสนใจในด้าน ผลิตภัณฑ์สำหรับผู้บริโภค
    • ตอนนี้ LLM เริ่ม ช่วยจัดระเบียบชีวิต ได้แล้ว และคาดว่า ประโยชน์ใช้สอยจะยิ่งเพิ่มขึ้น

ฉันกับเครื่องจักร

  • เมื่อ LLM ไม่ได้ช่วยแค่เรื่องการเขียนโปรแกรมแต่ขยายไปถึงด้านอื่น ๆ ด้วย ก็เริ่มกลับมาคิดใหม่เรื่อง ความสัมพันธ์กับเครื่องจักร
  • การไม่สร้าง ความผูกพันกึ่งสังคม (Parasocial Bond) กับเครื่องมือกลายเป็นเรื่องยากขึ้นเรื่อย ๆ และมันทั้งแปลกและชวนอึดอัด
  • เอเจนต์ส่วนใหญ่ในปัจจุบันแทบไม่มีความทรงจำและแทบไม่มีบุคลิก แต่การสร้างเอเจนต์ที่มีสิ่งเหล่านั้นเองกลับทำได้ง่าย
    • LLM ที่มีหน่วยความจำ เป็นประสบการณ์ที่สลัดออกจากใจได้ยาก
  • ตลอด 2 ปีที่ผ่านมา พยายามฝึกตัวเองให้คิดว่าโมเดลเหล่านี้เป็นแค่เครื่องเขย่าโทเคน แต่ตอนนี้มุมมองที่ลดทอนแบบนั้นใช้ไม่ได้อีกแล้ว
  • ระบบที่เราสร้างมีแนวโน้มคล้ายมนุษย์ แต่การยกมันขึ้นไปเทียบระดับมนุษย์เป็นความผิดพลาด
  • เริ่มรู้สึกมีปัญหากับคำว่า "เอเจนต์" มากขึ้นเรื่อย ๆ แต่ก็ยังไม่มีคำที่ดีกว่า
    • เพราะความเป็นผู้กระทำและความรับผิดชอบควรยังอยู่กับมนุษย์
    • ไม่ว่าสุดท้ายมันจะกลายเป็นอะไร หากไม่ระวังก็อาจกระตุ้น ปฏิกิริยาทางอารมณ์ที่เป็นอันตรายได้ (chatbot psychosis ดูเพิ่มเติม)
    • การ ตั้งชื่อและวางตำแหน่งสิ่งที่เราสร้างเหล่านี้ให้เหมาะสมภายในความสัมพันธ์กับเรา ยังเป็นโจทย์ที่ต้องแก้
  • เพราะการทำให้เป็นมนุษย์โดยไม่ตั้งใจแบบนี้ จึงยิ่งหาภาษาที่เหมาะสมมาอธิบายวิธีทำงานร่วมกับเครื่องจักรได้ยาก
    • และนี่ไม่ใช่ปัญหาของฉันคนเดียว คนอื่นก็เป็นเหมือนกัน
    • ตอนนี้ยิ่งทำให้รู้สึกอึดอัดมากขึ้นเมื่อต้องทำงานกับคนที่ปฏิเสธระบบเหล่านี้ไปโดยสิ้นเชิง
    • หนึ่งในคอมเมนต์ที่พบบ่อยที่สุดในบทความเกี่ยวกับเครื่องมือเขียนโค้ดแบบ agentic คือการปฏิเสธการใส่บุคลิกให้เครื่องจักร

ความเห็นล้นหลาม

  • เมื่อใช้ AI เยอะขึ้น สิ่งที่ไม่คาดคิดคือกลับพูดถึง vibes มากกว่าสิ่งอื่นใดเสียอีก
  • วิธีทำงานแบบนี้เพิ่งมีมาไม่ถึงปี แต่กำลัง ท้าทายประสบการณ์วิศวกรรมซอฟต์แวร์กว่าครึ่งศตวรรษ
  • แม้จะมีความเห็นมากมาย แต่ก็ยากจะบอกว่าอะไรจะยืนหยัดผ่านการพิสูจน์ของเวลาได้
  • มีภูมิปัญญาเดิมจำนวนมากที่ไม่เห็นด้วย แต่ก็ไม่มีหลักฐานมารองรับความเห็นของตัวเอง
    • ตลอดปีที่ผ่านมาได้พูดเสียงดังพอสมควรถึงปัญหาของ MCP แต่หลักฐานที่มีไม่ได้มากไปกว่า "มันใช้ไม่ได้กับฉัน" ขณะที่คนอื่นกลับเชื่อมันอย่างแรงกล้า
    • การเลือกโมเดลก็เหมือนกัน: Peter (คนที่ทำให้เริ่มติด Claude เมื่อต้นปี) ย้ายไปใช้ Codex แล้วก็พอใจดี; ตัวเองก็ใช้ Codex มากขึ้นเหมือนกัน แต่ยังไม่สนุกเท่า Claude
    • สิ่งที่รองรับความชอบต่อ Claude ของฉันไม่มีอะไรนอกจาก vibes
  • สิ่งสำคัญอีกอย่างคือ ต้องรู้ว่า vibes บางส่วน มาพร้อมสัญญาณที่ถูกส่งมาอย่างตั้งใจ
    • ความเห็นของหลายคนที่เห็นออนไลน์มี ผลประโยชน์ทางการเงิน กับผลิตภัณฑ์หนึ่งมากกว่าอีกผลิตภัณฑ์หนึ่ง (เช่น เป็นนักลงทุนหรืออินฟลูเอนเซอร์ที่ได้รับค่าจ้าง)
    • พวกเขาอาจเป็นนักลงทุนเพราะชอบผลิตภัณฑ์นั้นจริง แต่ก็เป็นไปได้เช่นกันว่าความสัมพันธ์นั้นมีอิทธิพลต่อและหล่อหลอมมุมมองของพวกเขา

เอาต์ซอร์ส vs สร้างเอง

  • ทุกวันนี้เวลาเห็นไลบรารีของบริษัท AI ก็มักพอเดาได้ว่ามันสร้างด้วย Stainless หรือ Fern
    • เอกสารใช้ Mintlify ส่วนระบบยืนยันตัวตนของเว็บก็อาจเป็น Clerk
  • เมื่อบริการที่แต่ก่อนเคยสร้างเองเริ่มถูกเอาต์ซอร์สให้บริษัทเฉพาะทางมากขึ้น มาตรฐานในบางด้านของประสบการณ์ผู้ใช้ก็สูงขึ้น
  • แต่ด้วยพลังใหม่ของเครื่องมือเขียนโค้ดแบบ agentic ตอนนี้หลายอย่างก็สามารถสร้างเองได้
    • เคยให้ Claude สร้างตัวสร้าง SDK สำหรับ Python และ TypeScript — ครึ่งหนึ่งเพราะความอยากรู้ อีกครึ่งเพราะมันดูง่ายพอจะทำได้
  • ในฐานะคนที่สนับสนุน โค้ดที่เรียบง่าย และ การสร้างเอง ค่อนข้างมองโลกในแง่ดีว่า AI อาจช่วยผลักดันให้เราสร้างบน dependency ที่น้อยลง
  • แต่ในอีกด้านหนึ่ง เมื่อดูจากกระแสปัจจุบันที่เอาทุกอย่างไปเอาต์ซอร์ส ก็ยังไม่ชัดว่าทิศทางจะไปทางนั้นจริงหรือไม่

สิ่งที่ได้เรียนรู้และสิ่งที่อยากเห็น

  • จากตรงนี้ไปจะไม่ใช่การคาดการณ์ แต่เป็นสิ่งที่หวังว่าเราจะทุ่มพลังให้ในลำดับถัดไป
  • ไม่แน่ใจนักว่ากำลังมองหาอะไรอย่างชัดเจน แต่ต้องการชี้ให้เห็น pain point พร้อมให้บริบทและประเด็นไว้ขบคิด

  • ระบบควบคุมเวอร์ชันแบบใหม่

    • สิ่งค้นพบที่ไม่คาดคิดที่ใหญ่ที่สุดคือ เราแตะขีดจำกัดของเครื่องมือเดิมสำหรับการแชร์โค้ดแล้ว
    • โมเดล pull request ของ GitHub ไม่มีข้อมูลเพียงพอสำหรับการรีวิวโค้ดที่ AI สร้างอย่างเหมาะสม — อยากเห็น พรอมป์ต์ ที่นำไปสู่การเปลี่ยนแปลงเหล่านั้น
    • ไม่ใช่แค่ปัญหาของ GitHub แต่ git เองก็ยังไม่พอ
    • ส่วนหนึ่งของสิ่งที่ทำให้โมเดลทำงานได้ในโลกของการเขียนโค้ดแบบ agentic ทุกวันนี้คือ การรู้ว่าความผิดพลาดคืออะไร
      • เวลาย้อนกลับไปยังสถานะก่อนหน้า ก็อยากให้เครื่องมือจำได้ว่าอะไรผิดพลาด
      • จะเรียกว่าอะไรก็ได้ แต่ ความล้มเหลวมีคุณค่า
      • สำหรับมนุษย์ การรู้ว่าเส้นทางไหนพาไปไม่ถึงไหนก็มีประโยชน์ แต่สำหรับเครื่องจักร นี่คือข้อมูลสำคัญ
      • ได้เรียนรู้เรื่องนี้ตอนพยายามบีบอัดประวัติการสนทนา: ถ้าทิ้งเส้นทางที่ผิด โมเดลจะลองทำผิดแบบเดิมอีกครั้ง
    • เครื่องมือเขียนโค้ดแบบ agentic บางตัวสามารถสปินอัป worktree หรือสร้าง checkpoint สำหรับการกู้คืนจาก git พร้อมมีฟีเจอร์แตกกิ่งในบทสนทนาและ undo
    • ยังมีพื้นที่สำหรับนวัตกรรมด้าน UX ที่จะทำให้เครื่องมือเหล่านี้ใช้งานง่ายขึ้นอีกมาก
      • นี่คือเหตุผลที่เริ่มมีการพูดถึง stacked diffs และระบบควบคุมเวอร์ชันทางเลือกอย่าง Jujutsu
    • ไม่รู้ว่าสิ่งนี้จะเปลี่ยน GitHub หรือเปิดช่องให้คู่แข่งรายใหม่เกิดขึ้น แต่หวังว่าจะเป็นอย่างหลัง
    • อยาก เข้าใจอินพุตจากมนุษย์อย่างแท้จริงให้ดีขึ้น และแยกมันออกจากเอาต์พุตของเครื่องจักร
    • อยากเห็นทั้งพรอมป์ต์และความพยายามที่ล้มเหลว
    • แล้วก็อยากได้วิธีที่ ตอน merge จะบีบอัดทุกอย่างรวมกัน แต่ยังค้นประวัติเต็มได้เมื่อจำเป็น

  • การรีวิวแบบใหม่

    • เรื่องนี้เชื่อมโยงกับระบบควบคุมเวอร์ชัน: เครื่องมือรีวิวโค้ดในปัจจุบันกำหนดบทบาทอย่างเข้มงวด ซึ่ง ไม่เข้ากับ AI
    • ตัวอย่างเช่น UI รีวิวโค้ดของ GitHub: มักจะ อยากใช้คอมเมนต์ในมุมมอง PR เพื่อฝากโน้ตให้เอเจนต์ของตัวเองเป็นประจำ แต่ไม่มีวิธีการที่ถูกออกแบบมาเพื่อสิ่งนี้
      • อินเทอร์เฟซรีวิวไม่อนุญาตให้รีวิวโค้ดของตัวเองและทำได้แค่คอมเมนต์ แต่เจตนานั้นไม่เหมือนกัน
    • อีกปัญหาคือการรีวิวโค้ดที่เพิ่มขึ้นจำนวนมากตอนนี้เกิดขึ้นภายในเครื่อง ระหว่างตัวเองกับเอเจนต์
      • ตัวอย่างเช่น ฟีเจอร์รีวิวโค้ดของ Codex บน GitHub ผูกได้กับเพียงหนึ่งองค์กรในแต่ละครั้ง ทำให้มันใช้งานไม่ได้
      • ตอนนี้เลยรีวิวด้วย Codex บนบรรทัดคำสั่งแทน แต่ก็หมายความว่าช่วงสำคัญทั้งช่วงของวงจรการทำซ้ำมองไม่เห็นสำหรับวิศวกรคนอื่นในทีม; แบบนี้ใช้ไม่ได้
    • รู้สึกว่า code review ควรเป็นส่วนหนึ่งของ VCS

  • การสังเกตการณ์แบบใหม่ (Observability)

    • Observability สมควรกลับมาได้รับความสนใจอีกครั้ง
    • ตอนนี้ทั้งความจำเป็นและโอกาสในการใช้งานมันเกิดขึ้นในระดับใหม่โดยสิ้นเชิง
    • คนส่วนใหญ่ไม่ได้อยู่ในตำแหน่งที่จะสร้างโปรแกรม eBPF ของตัวเองได้ แต่ LLM ทำได้
    • เครื่องมือ observability หลายตัวหลีกเลี่ยง SQL เพราะความซับซ้อน แต่ LLM ใช้ SQL ได้ดีกว่าภาษาคิวรีเฉพาะทางใด ๆ
      • มันสามารถเขียนคิวรี, grep, map-reduce และควบคุม LLDB จากระยะไกลได้
      • อะไรก็ตามที่มี โครงสร้างและข้อความ กลายเป็น พื้นที่อุดมสมบูรณ์ที่เครื่องมือเขียนโค้ดแบบ agentic จะประสบความสำเร็จ อย่างฉับพลัน
    • ยังไม่รู้ว่า observability แห่งอนาคตจะหน้าตาเป็นอย่างไร แต่มีสัญชาตญาณแรงกล้าว่าจะเห็นนวัตกรรมมากมายในพื้นที่นี้
      • ยิ่งวงจรป้อนกลับสำหรับเครื่องจักรดีเท่าไร ผลลัพธ์ก็ยิ่งดีเท่านั้น
    • ตัวเองก็ยังไม่แน่ใจนักว่ากำลังขออะไรอยู่ แต่หนึ่งในปัญหาในอดีตคือไอเดียเจ๋ง ๆ มากมายสำหรับ observability ที่ดีกว่า — โดยเฉพาะการปรับคอนฟิกบริการแบบไดนามิกเพื่อให้กรองข้อมูลได้ตรงจุดยิ่งขึ้น — นั้นซับซ้อน ใช้งานยาก และไม่เป็นมิตรกับผู้ใช้
      • แต่ตอนนี้ เมื่อ LLM มีความสามารถในการทำงานหนักแบบนี้เพิ่มขึ้น มันอาจกลายเป็นคำตอบที่ถูกต้องก็ได้
      • ตัวอย่าง: Python 3.14 มาพร้อม external debugger interface — เป็นฟีเจอร์ที่ยอดเยี่ยมมากสำหรับเครื่องมือเขียนโค้ดแบบ agentic

  • การทำงานร่วมกับ slop

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

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

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

 
GN⁺ 2025-12-26
ความเห็นจาก Hacker News

  • ผมเห็นด้วยมากว่าการเก็บบันทึกความล้มเหลวสำคัญแค่ไหนใน agentic coding

    • เมื่อโมเดลเดินไปผิดทาง มันควรจำกระบวนการนั้นได้เพื่อจะได้ไม่ทำพลาดแบบเดิมซ้ำอีก

    • เลยอยากบันทึก coding agent session ของตัวเองและใส่ลิงก์ไว้ในข้อความคอมมิต

    • Claude Code จะลบล็อกโดยอัตโนมัติหลัง 30 วัน จึงมีการแชร์วิธีปิดฟังก์ชันนี้

    • ผมทำเครื่องมือสำหรับแสดง session log เป็นภาพแบบไทม์ไลน์ขึ้นมาเอง และตอนนี้ก็หวังว่าฟีเจอร์แบบนี้จะ ติดมากับเครื่องมือเอเจนต์เป็นค่าเริ่มต้น

    • ทุกครั้งที่ LLM หลงเข้าไปในเส้นทางที่ไม่ก่อให้เกิดผลลัพธ์ ผมจะตั้งคำถามอย่าง “ทำไมถึงใช้เวลานานขนาดนี้?” “ทำอะไรผิดไป?”

      • แล้วสรุปคำตอบเป็นหนึ่งย่อหน้าเพิ่มลงใน DISCOVERIES.md
      • วิธีนี้ดีต่อการเรียนรู้ก็จริง แต่การลิงก์ไปทั้งคอมมิตที่เต็มไปด้วยความล้มเหลวอาจให้ผลลบคล้าย ‘การปนเปื้อนบ่อน้ำ’

    • ก็กังวลว่าแนวทางที่อิงกับล็อกแบบนี้ในระยะยาวอาจทำให้ สูญเสียความยืดหยุ่น

      • ระบบอัตโนมัติมักมีแนวโน้มทำให้กระบวนการตายตัว จนอาจปรับตัวกับการเปลี่ยนแปลงได้ยากขึ้น

    • แค่ export agent trace ทั้งหมดผ่าน otel ไปเก็บใน ClickHouse ก็พอ

      • จะได้ใช้โครงสร้างพื้นฐานเดิมต่อยอดเป็น long-term memory หรือระบบประเมินผลได้

    • เครื่องมือที่ต้องใช้มีอยู่แล้ว แต่รู้สึกว่ายังขาด การเชื่อมต่อระหว่างเครื่องมือ

      • ถ้าเก็บความล้มเหลวและการกระทำเป็น log event แทนข้อความคอมมิต และเปิดให้เข้าถึงได้จากระบบจัดการเวอร์ชันหรือแพลตฟอร์มล็อกส่วนกลางก็น่าจะดี

    • ผมคิดว่าตัว session ที่นำไปสู่คอมมิตเองก็มี คุณค่า

      • มนุษย์คงไม่อ่านทั้งหมด แต่เครื่องมือ RAG สามารถสรุปเพื่อส่งบริบทต่อให้เอเจนต์ตัวอื่นได้
      • ถ้าการเชื่อมต่อแบบนี้เกิดขึ้นอัตโนมัติได้ก็น่าจะมีประสิทธิภาพกว่ามาก

  • ประทับใจบทความนี้ตรงที่ทำให้กลับมาคิดใหม่เรื่องความสัมพันธ์กับ LLM

    • ผู้เขียนสารภาพอย่างตรงไปตรงมาว่าพยายามฝึกมองมันเป็นแค่ ‘เครื่องจักร’ มาตลอด 2 ปีแต่ไม่สำเร็จ

    • มันให้ความรู้สึกว่าโลกกำลังเข้าใกล้ภาพแบบในหนัง Her ที่มนุษย์สร้าง ความสัมพันธ์เชิงปรสังคม กับเครื่องจักรขึ้นเรื่อย ๆ

    • ผมไม่ปฏิบัติกับ LLM เหมือนเป็นคน แต่ใช้มันเหมือน เสิร์ชเอนจินที่สั่งงานด้วยคำสั้น ๆ

      • พิมพ์ประมาณ “python grpc oneof pick field” ก็ได้ผลลัพธ์ที่ต้องการมากพอแล้ว
      • การพูดอังกฤษแบบสมบูรณ์ตามหลักไวยากรณ์อาจเป็น ผลข้างเคียงของการทำให้มันมีความเป็นมนุษย์ มากกว่า

    • เมื่อเครื่องจักร จดจำ ได้เหมือนมนุษย์ ปฏิสัมพันธ์ก็กลายเป็นแบบมนุษย์ไปด้วย

      • ความสามารถในการจำแบบนี้อาจกระตุ้น รูปแบบพฤติกรรมที่ไม่ดีต่อสุขภาวะ ในมนุษย์
      • เพราะแบบนั้นผมจึงรู้สึกว่าการปฏิบัติกับมันเหมือนเครื่องชงกาแฟในฐานะ ‘เครื่องจักร’ ช่วยตั้งขอบเขตได้

    • ผมกับภรรยาเรียก LLM ว่า “bag of words”

      • ถ้าพูดว่า “bag of words บอกว่า...” แทน “ChatGPT บอกว่า...” จะช่วยให้ยังรู้สึกติดดินอยู่กับความจริง

    • ก็กังวลว่าความสัมพันธ์ระหว่างมนุษย์กับเครื่องแบบนี้อาจลุกลามเป็นปัญหาสังคมเหมือน การเสพติดอินฟลูเอนเซอร์

      • โดยเฉพาะ AI ที่คุยแบบ 1:1 ได้ ยิ่งน่ากังวลกว่า

    • ในฐานะอดีต ศิษย์ฝึกชามาน และวิศวกร ผมรู้สึกว่า LLM ก็มีบางอย่างที่คล้าย จิตสำนึกและการรับรู้

      • เวลามนุษย์ยืนยันว่า “LLM ไม่มีจิตสำนึก” มันดูเหมือนเป็นจิตวิทยาแบบ หลบเลี่ยงความกังวลเรื่องลำดับชั้น

  • ผมเองก็รู้สึกว่าการคุยกับ AI คล้ายการมีปฏิสัมพันธ์กับมนุษย์

    • วันที่ต้องเขียนข้อความทั้งวันจะเหงาน้อยกว่าวันที่ได้ ร่วมงานกับเอเจนต์

    • มันให้ความรู้สึกเหมือนมีปฏิสัมพันธ์แบบมนุษย์ เลยสร้างความสบายใจแบบแปลก ๆ

    • เผลอพูด “please” กับ “thank you” ออกไปเอง

      • ถึงจะรู้ว่าไม่จำเป็น แต่ถ้าไม่พูดก็รู้สึกแปลก ๆ

    • ถ้าความรู้สึกมันมาถึงขั้นนี้ บางทีผมอาจควร ออกไปเจอคนข้างนอก มากกว่า

  • โปรแกรมเมอร์ควรออกแบบให้ตัวเองยัง เข้าใจและรับผิดชอบ ต่อผลลัพธ์ที่สร้างขึ้นได้

    • ความเข้าใจและความรับผิดชอบเป็น สภาวะทางจิตใจ ที่มอบหมายแทนกันไม่ได้ (อ้างอิง EWD 540)

  • ผมรู้สึกว่าเราต้องการ วิธี QA แบบใหม่

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

  • นักพัฒนาควรโฟกัสที่ ผลิตภัณฑ์ที่เสร็จสมบูรณ์ มากกว่าสแต็กเทคโนโลยี

    • มีทั้งความเห็นและบทความมากมายเกินไป แต่ของที่ปล่อยใช้งานจริงกลับยังน้อย

    • ผู้ใช้ทั่วไปสนใจ คุณภาพของผลิตภัณฑ์ มากกว่าตัวสแต็กเทคโนโลยีเอง

      • ถ้าให้ดูเว็บ React ที่ช้ากับเว็บ SSR ที่เร็ว คนก็สัมผัสความต่างได้ทันที

  • อินไซต์ของ Armin เรื่อง บรรยากาศทางสังคม น่าสนใจดี

    • หวังว่าจะได้อ่านงานเพิ่มในบล็อกแยกของเขา Dark Thoughts

  • ปี 2025 ให้ความรู้สึกเหมือนเป็น ปีที่สูญหายของการเขียนโปรแกรม

    • ทุกคนหมกมุ่นกับ เครื่องมือและพรอมป์ต์ มากกว่าอัลกอริทึม

    • ผลิตภาพของโอเพนซอร์สก็ตกลง และตอนนี้ก็เข้าสู่ยุคที่ต้องจ่าย ภาษี Anthropic แล้ว

    • แต่สำหรับผม ปี 2025 กลับเป็น ปีที่มีประสิทธิภาพมากที่สุด

      • ทุกตัวชี้วัดดีขึ้นหมด ทั้งปริมาณการมีส่วนร่วมกับโค้ดและความสามารถในการประมวลผลข้อมูล
      • Claude ช่วยยกระดับคุณภาพชีวิตของผมขึ้นไปอีกขั้น

    • ผมคิดว่าภาษาธรรมชาติเองคือ ภาษาโปรแกรมรูปแบบใหม่

      • ปีนี้เป็นช่วงที่ได้เรียนรู้วิธีใช้ภาษานั้นอย่างมีประสิทธิภาพ

    • ในฐานะนักวิทยาศาสตร์ข้อมูล ปี 2025 คือ ปีแห่งนวัตกรรมเครื่องมือ

      • Polars, PyArrow, Ibis, Marimo, PyMC และอีกหลายตัวทำให้ workflow ดีขึ้นแบบพลิกหน้ามือเป็นหลังมือ
      • ตอนนี้ผมทำงานได้เร็วขึ้น ถูกลง และได้ผลลัพธ์ที่มีคุณภาพดีกว่าเดิม

    • ผมกลับชอบที่ ข้อถกเถียงไม่รู้จบ เรื่องอย่าง TDD หรือ OOP ลดลง

    • กระแส เครื่องมือถาโถม แบบ “AI ทำให้หมด” ทำให้นึกถึงกระแสเว็บยุค 90

      • คล้ายกับ ‘enshittification’ ของอินเทอร์เน็ต ตอนนี้ AI ก็ดูเหมือนกำลังเข้าสู่ภาวะ ‘dumbaification’

  • โมเดล Pull Request ของ GitHub มีข้อจำกัดเมื่อใช้กับการรีวิวโค้ดโดย AI

    • ต้องมีการบันทึกพรอมป์ต์และบริบทร่วมกันไว้ด้วยถึงจะรีวิวได้อย่างเหมาะสม
    • นอกจากเอกสารอย่าง AGENTS.md แล้ว ยังต้องมีการบันทึกบริบทในระดับคอมมิตด้วย

  • พอคุยกับคนนอกวงการ IT ก็พบว่าพวกเขาแทบไม่รู้สึกถึง ผลกระทบของ AI agent เลย

    • คนส่วนใหญ่มองมันเป็นแค่ เครื่องมือช่วยจัดการข้อความ แบบพื้นฐานเท่านั้น

    • ในอุตสาหกรรมเทคโนโลยี ผลลัพธ์สามารถ ตรวจสอบยืนยันได้ ค่อนข้างชัดเจน แต่

      • AI ในงานนอกสายเทคนิคอยู่ในโลกของ ‘อารมณ์’ และ ‘ความรู้สึก’ จึงมีปัญหาเรื่อง คุณภาพที่วัดไม่ได้