ดูเหมือนผมจะเริ่มหมดไฟกับ LLM

• ระหว่างงานและโปรเจกต์ส่วนตัว ผมใช้ Claude Code, Codex, ChatGPT และ Gemini ทุกวัน จนเวลาในการอ่านข้อความที่ AI สร้างเพิ่มขึ้นมากเมื่อเทียบกับหลายปีก่อน
• เวิร์กโฟลว์การพัฒนาเปลี่ยนจากการออกแบบและลงมือเขียนเองโดยตรง มาเป็น อธิบายการออกแบบ → ให้ LLM รีวิวโค้ด → แล้วค่อยแก้เอง ทำให้ทำงานในโดเมนที่ไม่คุ้นเคยได้ง่ายขึ้น
• โปรเจกต์ปัจจุบันก็เน้นเฟรมเวิร์กสำหรับ การสร้างโค้ดแบบไม่กำกับดูแลในวงกว้าง และการตรวจทานผลลัพธ์ของเอเจนต์ Qwen จึงเป็นโครงสร้างงานที่ต้องอ่านคอนเทนต์จาก LLM อยู่ตลอด
• หลังใช้งานต่อเนื่องราว 1 ปี ช่วงไม่กี่เดือนมานี้รูปแบบซ้ำๆ อย่าง การตั้งสมมติฐานผิด, อาการหลอน, ประโยคสั้นที่ฟันธง และอีโมจิที่มากเกินไป เริ่มสะสมจนเป็นภาระ
• ประเด็นที่ทำให้ล้าจริงๆ ไม่ใช่ตัว LLM เอง แต่คือการที่สไตล์เดิมและความผิดพลาดแบบเดิมถูกทำซ้ำอยู่เรื่อยๆ แม้จะมีฟีเจอร์ personalization ก็ยังควบคุมสไตล์ของคอนเทนต์ AI ที่คนอื่นสร้างไม่ได้

---

LLM ที่แทรกซึมลึกเข้าไปในเวิร์กโฟลว์การพัฒนา

• ผู้เขียนมองว่าปริมาณการใช้ LLM ของตัวเอง ถ้าวัดในหมู่นักพัฒนาตอนนี้ก็น่าจะอยู่ระดับเฉลี่ย และวิธีใช้งานก็ยังค่อนข้างพื้นฐาน
  • ทำทีละงาน และที่บริษัทใช้ Claude Code ส่วนที่บ้านตอนนี้คุยกับ Codex
  • แม้จะให้แอสซิสแทนต์เขียนโค้ดให้ ก็ยังอ่านผลลัพธ์อย่างละเอียด ทำความเข้าใจ แล้วแก้เอง
  • ยังไม่ได้ไปถึงขั้นใช้งาน autonomous agent หรือ agent orchestration อย่างลึกซึ้ง
• วิธีทำงานเปลี่ยนจากการเน้นออกแบบและเขียนโค้ดเอง มาเป็นการอธิบายการออกแบบให้ LLM ฟัง ตรวจทานโค้ดที่ LLM สร้าง แล้วกลับมาเขียนโค้ดต่อ
  • ระหว่างทางก็ได้เจอกับแนวทางที่ก่อนหน้านี้อาจยังไม่เคยนึกถึงหรือไม่เคยรู้
  • ทำงานในพื้นที่ที่ไม่ได้มีความรู้ลึกได้อย่างสบายใจขึ้น
• โปรเจกต์หลักตอนนี้คือการวางเฟรมเวิร์กสำหรับ การสร้างโค้ดแบบไม่กำกับดูแลในวงกว้าง ภายในโค้ดเบส
  • เวลาที่ไม่ได้ใช้ Claude สร้างเครื่องมือ ก็จะไปตรวจผลลัพธ์จาก Qwen ซึ่งเป็นเอเจนต์แบบไม่กำกับดูแล
  • ไม่ว่าจะกรณีไหน ก็ลงเอยด้วยการต้องอ่านคอนเทนต์ที่ LLM สร้างอย่างต่อเนื่อง
• เวลาหาข้อมูล ถ้าไม่รู้จักเว็บที่ต้องการอยู่แล้ว ก็มักจะถาม ChatGPT หรืออ่านภาพรวมจาก Gemini
  • ถ้าคำตอบจาก LLM ผิด ก็ต้องกลับไปไล่ค้นผ่านเบราว์ซิงอีกครั้ง
  • เมื่อผลการค้นหาเต็มไปด้วยบทความที่ AI สร้างแบบไม่มีประโยชน์ ผู้เขียนก็มองว่าคำตอบจาก LLM สำหรับคำถามทั่วๆ ไปก็ถือว่าใช้ได้ดีพอ

ความเหนื่อยล้าจากสไตล์เดิมและความผิดพลาดแบบเดิม

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

[amebahead]

ผมเองก็เคยทรมานกับสมมติฐานเท็จที่ LLM ตอบออกมา อาการหลอน ข้อความสั้น ๆ ที่ฟันธงเกินไป และแพตเทิร์นการใช้อีโมจิมากเกินพอดี
เลยสร้าง ELI5 Rule ขึ้นมาแล้วนำไปใช้ จนหลุดพ้นจากความทรมานนั้นได้ :)

https://github.com/amebahead/explain-like-iam-five-rules

[GN⁺]

ความเห็นจาก Hacker News

• ยังไม่ถึงขั้นหมดไฟ แต่ LLM ทำให้เหนื่อยล้าจริง ๆ เพราะแรงกดดันที่มันสร้างขึ้น ไม่มีใครบังคับตรง ๆ ว่าต้องเพิ่มปริมาณงาน แต่ในทุกช่วงเวลาจะมีบางอย่างที่ “clanker” ของฉันหรือ “clanker” ของคนอื่นทำทิ้งไว้ และมันอยู่ในสภาพที่ฉันสามารถเข้าไปช่วยปลดคอขวดได้
  ก่อนยุค LLM ก็รู้สึกตามงานแทบไม่ทันอยู่แล้ว แต่ตอนนี้เหมือนงานที่รอคิวอยู่เพิ่มขึ้นตลอดเวลาราว ๆ 10 เท่า และถ้าทุกคน “เพิ่มประสิทธิภาพ” แล้วป้อนงานให้ AI แบบขนานได้เร็วขึ้น มันก็อาจเพิ่มอีก 10 เท่าได้เหมือนกัน การต้องยืนเป็นคอขวดของทุกอย่างอยู่ตลอดมันเหนื่อยมาก
  การทำโปรเจกต์ย่อยเล็ก ๆ และทำไอเดียให้เป็นจริงยังคงสนุก แต่ก็เริ่มตระหนักว่า LLM ไปหล่อเลี้ยงวิธีคิดที่ไม่ดีต่อสุขภาพแบบ “พัก = เสียเวลา” มากขึ้น และรู้สึกว่าต้องรีบแก้ความคิดนี้
  ข้อบ่นหลักของบทความนี้ก็น่าจะคล้ายกับสมัยระบบอัตโนมัติในโรงงาน จากเดิมที่เป็นงานฝีมือหลากหลายแบบที่ต้องใช้ทักษะ กลายเป็นการนั่งอยู่จุดเดียวบนสายการประกอบและทำท่าเดิมซ้ำทั้งวัน เช่นเดียวกัน LLM เอาส่วนที่สร้างสรรค์และมีความเปลี่ยนแปลงไป เหลือไว้แค่งาน ปั๊มตรา QA แบบซ้ำ ๆ บางทีเราอาจกลับไปหาวิธีบรรเทาปัญหาแบบที่เคยใช้กันในตอนนั้นได้

  • คำขอให้ช่วยตรวจเอกสารที่ LLM สร้างขึ้นมีเยอะเกินไป ทั้งเอกสารวางแผน เอกสารสำหรับผู้ใช้ปลายทาง เอกสารโปรเจกต์ เอกสารแผนธุรกิจ อะไรพวกนั้น
    ไม่นานมานี้เพื่อนร่วมทีมส่งไฟล์ zip ที่มี เอกสารที่สร้างโดย LLM ราว 30 ชิ้น มาให้ แล้วขอให้รีวิวทันที ซึ่งหลายชิ้นก็ซ้ำไปซ้ำมาหรือมีเนื้อหาที่แต่งขึ้น/หลอนแบบไม่มีปี่มีขลุ่ย ความเร็วในการสร้างมันเร็วกว่าความเร็วในการรีวิวมาก
    เมื่อก่อนผู้จัดการโครงการต้องใช้เวลาส่วนใหญ่ของวันเพื่อทำเอกสารวางแผน แต่ตอนนี้ทำได้ในไม่กี่นาทีแล้วโยนมาให้รีวิวได้เลย เลยยิ่งเหนื่อย
  • ทำให้นึกถึงฉากโรงงานใน Modern Times ของ Charlie Chaplin ความรู้สึกของผู้เขียนสุดท้ายแล้วคือ มนุษย์ต้องปรับตัวให้ทันความเร็วของเครื่องจักร ไม่ใช่กลับกัน
    “เซนทอร์กลับด้าน” ไม่ใช่เรื่องใหม่ ถามขบวนการแรงงานในศตวรรษก่อนดูก็ได้
  • เหตุผลหนึ่งที่ LLM ทำให้เหนื่อยคือมันทำให้เราคิดว่า ขอเพิ่มอีกแค่หนึ่ง prompt เพื่อให้ UI เข้าที่อีกนิด ส่วนใหญ่ผลลัพธ์มักจะเกือบตรงแต่ยังไม่พอดี แล้วการตามแก้ตรงนั้นก็กินเวลาอีก 5~10 นาที ผลคือทำงานนานขึ้นมาก
    น่าจะยิ่งเป็นแบบนั้นสำหรับคนที่เป็นวิศวกรซอฟต์แวร์เพราะชอบสร้างผลิตภัณฑ์มากกว่าการใช้งานซอฟต์แวร์ที่ซับซ้อน ความรู้สึกของการได้สร้างอะไรขึ้นมาเป็นแรงจูงใจ และอยากให้ฟีเจอร์ออกมาสมบูรณ์ครบถ้วน แต่ในงาน UI การไปจาก 95% ถึง 100% ใช้เวลานานมาก
    เพราะงั้นน่าเสียดายที่ตอนนี้ชั่วโมงทำงานยาวขึ้นมาก
  • มันให้ความรู้สึกประมาณว่า “เคยนึกว่าถ้ามีเครื่องล้างจานจะได้เอาเวลาไปโฟกัสกับงานสร้างสรรค์ แต่กลายเป็นว่ามีเครื่องมาทำงานของฉันแทน แล้วสุดท้าย เหลือให้ฉันทำแค่ล้างจาน”
  • ฉันเจอแรงกดดันอีกแบบหนึ่ง บริษัทก็ยังคงบังคับให้ทุกคนใช้ LLM และถึงขั้นมี ตารางจัดอันดับโทเค็น วัดเวลาใช้งาน และเอาไปรวมในประเมินผลงาน
    เลยต้องหยุดงานที่มีประสิทธิผลจริง ๆ แล้วแบ่งเวลาส่วนหนึ่งไป “ทำ AI เพื่อโชว์ปริมาณการใช้โทเค็น” ปริมาณงานก็เท่าเดิมหรือมากขึ้น แต่เวลาทำงานจริงกลับลดลงอีก N% เพราะต้องคอยบูชาเทพ AI

• จากประสบการณ์ของฉัน สาเหตุของภาวะหมดไฟมีใหญ่ ๆ 3 ข้อ อย่างแรกคือ multitasking ซึ่งหนักที่สุด ต้องสลับไปมาระหว่างหน้าต่าง agent 3~5 ตัวที่ทำงานคนละอย่างอยู่บ่อย ๆ และแต่ละรอบก็ใช้เวลาหลายนาที ทำให้เหนื่อยล้ามาก
  ก่อนยุค coding agent นักพัฒนาส่วนใหญ่น่าจะยังมีโอกาสได้จดจ่อกับสิ่งเดียวต่อเนื่องเกิน 2 ชั่วโมง แต่ตอนนี้แม้ coding agent จะขยายความกว้างของ tech stack ที่รับมือได้ ทว่ามันไม่ได้เพิ่มแบนด์วิดท์สำหรับการทำงานเชิงลึก
  อย่างที่สอง agent เก่งเรื่องทำให้ระบบรันไปได้โดยไม่ชนกัน แต่ไม่ได้แปลว่าจะเขียนโค้ดได้ถูกต้องเสมอไป ซึ่งต่างจากผู้เชี่ยวชาญที่เป็นมนุษย์และมีพื้นฐานแน่นพอสมควร
  อย่างที่สาม ฉันหงุดหงิดเวลารีวิวกอง PR คุณภาพต่ำที่ AI สร้างขึ้น สมาธิเป็นทรัพยากรที่มีจำกัด ฉันไม่อยากเอาพลังงานไปเทกับงานของคนอื่นมากนัก แต่ถ้าไม่ใส่ใจมากพอ โค้ด AI ที่ขาดความรับผิดชอบและถูกสร้างขึ้นโดยไม่มีการคิดเชิงออกแบบอย่างรอบคอบแบบที่ผู้เขียนมนุษย์ควรมี ก็จะทำให้ทั้งโปรเจกต์พังเร็วมาก การทำงานกับคนที่ขาดความรอบคอบก็เหนื่อยอยู่แล้ว แต่ในยุค coding agent พวกเขาสร้างขยะได้มากขึ้น 10 เท่า เลยเจ็บปวดขึ้น 10 เท่า และมันเป็นปัญหาเรื่อง วัฒนธรรมทีม ที่บังคับกันง่าย ๆ ไม่ได้

  • เห็นด้วย ตอนนี้เลยพยายามจำกัดตัวเองอย่างจริงจังให้ใช้แค่ workflow ของ agent 1~2 แบบ พร้อมกันเท่านั้น มากกว่านั้นรับไม่ไหว แต่ก็หลงกับดักการเปิด agent เพื่อ “แก้จุดเล็ก ๆ แค่นี้เอง” ได้ง่ายเกินไป

• พออ่านเอาต์พุตของ Opus ติดต่อกันหลายชั่วโมง ก็เริ่มรู้สึกเหมือน ป่วยทางกายเล็กน้อย ขึ้นมาจริง ๆ ข้อความนี้โดนใจมาก
  ฉันเริ่มบ่นเรื่องนี้กับทีมแล้ว อย่างน้อยก็ควรใส่ style guide ส่วนตัวไว้ในกฎของเอเจนต์ เพื่อกำจัดการใช้ em dash, สำนวนแบบ “ไม่ใช่ X แต่เป็น Y”, วิธีลากคำขยายยาว ๆ ไว้หน้าคำนาม, การใช้คำว่า “land” ในความหมายว่าเสร็จสมบูรณ์ ฯลฯ หวังว่านี่จะเป็นแค่ช่วงหนึ่งของ LLM ที่ยังไม่โตเต็มที่

  • บอตทุกตัวมีแพตเทิร์นการใช้วลี คำ หรือเครื่องหมายวรรคตอนบางอย่างซ้ำมากเกินไป ตัวอย่างเช่นช่วงนี้ชอบใช้คำว่า gate มากผิดปกติ
    ในฐานะมนุษย์ เรารู้ว่า gate คือ “ประตู” ที่อาจเปิดหรือปิดก็ได้ ล็อกหรือไม่ล็อกก็ได้ และทางด้านหลังมันอาจมีทางที่ผ่านได้หรือไม่ได้ก็ได้ แค่รู้ว่ามี gate อยู่ ไม่ได้แปลว่ารู้ว่ามันเปิดหรือปิด
    แต่ในภาษาสไตล์บอต คำว่า gate กลับหมายถึงสิ่งกีดขวางแข็งแรงที่ผ่านไปไม่ได้เท่านั้น ใช้เหมือนเป็นรั้ว กำแพง หรือแม้แต่คูน้ำลาวา
    ทั้งที่ gate เดิมทีเป็นสิ่งที่ออกแบบมาให้ผ่านได้ แต่บอตกลับใช้คำเดียวกันกับอุปสรรคที่ตั้งใจให้ผ่านไม่ได้ ถ้าวัดจากประสบการณ์การใช้งาน gate ในโลกจริงมาหลายสิบปี นี่คือการใช้ผิด ปกติเจอ gate ปิดอยู่ก็แค่เปิดแล้วเดินผ่านไป
    ต่อให้สั่งบอตว่าอย่าใช้คำนั้น มันก็ยังเมินบ้างเป็นบางครั้ง วันนี้แค่บังเอิญเป็นคำว่า gate เมื่อวานเป็นอีกคำหนึ่ง และพรุ่งนี้ก็คงเป็นอีกคำที่ต่างออกไปโดยสิ้นเชิง
    แพตเทิร์นโดยรวมคือ ศัพท์เทคนิคเกรดต่ำที่ซ้ำซากและน่ารำคาญ ซึ่งแต่แรกก็ใช้ไม่ตรงอยู่แล้ว
  • ฉันก็เป็นเหมือนกัน อ่านของพวกนี้มากเกินไปแล้วรู้สึกเหมือนโดน ความเสียหายทางจิตใจ
    แทนที่จะเป็นอย่างคำอธิบายแบบ “ก็แค่อังกฤษสไตล์ไนจีเรียของคนรับจ้างชั่วคราว” ดูเหมือนโมเดลกำลังสร้างภาษาถิ่นของตัวเองที่สั้นจัดและถูกทำให้เป็นแบบแผนเกินไปภายใต้แรงกดดันจาก reinforcement learning มากกว่า มันยิ่งให้ความรู้สึกเหมือนกำลังเขียนเป็นโค้ดขึ้นเรื่อย ๆ แต่โค้ดในที่นี้ไม่ใช่คอมพิวเตอร์โค้ด คำเหล่านี้ไม่ได้มีความหมายตรงกับที่มันหมายถึงสำหรับคนเป๊ะ ๆ
  • วันนี้ฉันเพิ่งพยายามอธิบายความรู้สึกนี้อยู่เลย ยังเรียบเรียงเป็นคำพูดได้ไม่แม่นนัก แต่รู้สึกเหมือนป่วยทางกายเล็กน้อยจริง ๆ คล้าย โรคกลัวรู แบบอ่อน ๆ
  • arc land ฝังอยู่ในสมองฉันเพราะ Phabricator เลยรู้ดีว่าคำนี้มีมาก่อน LLM แต่ถึงอย่างนั้นมันก็น่ารำคาญจนแทบบ้า
    ความสั่นไหวทางภาษาพวกนี้ย้อนกลับไม่ได้ ต่อให้กรองอินพุตจาก LLM ได้ 100% ผู้คนเองก็กำลังถูกฝึกให้พูดคำว่า “land” บ่อยขึ้นอยู่ดี
  • ในงานเขียน น้ำเสียง สำคัญมาก ถ้าทุกคนเขียนด้วย Opus แล้วไม่แก้ไขเพิ่ม ไม่ว่าใครเขียนก็จะฟังเหมือนเสียงเดียวกันหมด

• ตอนนี้ฉันกำลังทำโปรเจกต์กับคนที่ใช้แต่ LLM อย่างเดียว แล้วมันทั้งเหนื่อยและบั่นทอนจิตใจ
  เวลาฉันให้ฟีดแบ็กอะไรไป คำตอบก็มีแค่ว่า “จะลองไปบอก Claude ดู” คนคนนั้นไม่เข้าใจด้วยซ้ำว่าระบบโดยรวมทำงานยังไง และโค้ดส่วนใหญ่ก็สะท้อนเรื่องนั้น
  ไม่กี่วันก่อนเขายังไม่รู้เลยว่าจะตั้งค่า local environment และ environment variables ยังไง เลยฮาร์ดโค้ด โหมดเดโม ใส่เข้าไป ฉันก็งงเหมือนกันว่าทำไม Claude ไม่รู้เรื่องนี้ แต่อาจเป็นปัญหาที่พรอมป์ตก็ได้
  ฉันพยายามจำกัดการใช้ LLM และถึงจะใช้ก็ใช้เฉพาะงานที่เฉพาะเจาะจงมาก ๆ สำหรับฉัน วิธีนั้นเท่านั้นที่ได้ผล
  พูดตรง ๆ ฉันไม่เข้าใจว่าบริษัทต่าง ๆ จะดันการสร้างโค้ดด้วย AI กันหนักขนาดนี้ได้ยังไง แม้แต่ในโปรเจกต์เล็ก ๆ ความเข้าใจตัวโปรเจกต์ก็ตามไม่ทันอย่างรวดเร็ว

  • ฉันจำได้ว่าแม้ก่อนยุค AI ก็เคยทำงานกับคนแบบนี้ มันน่าหงุดหงิดก็จริง แต่เพราะพวกเขาเข้าใจสิ่งที่ตัวเองกำลังทำไม่ดีพอ เลยสร้างโค้ดที่ดีอย่างมีประสิทธิภาพไม่ได้ ทำให้มีปัญหาเรื่อง productivity และโดยมากปัญหาก็คลี่คลายไปเอง
    แต่ตอนนี้การเขียนโค้ดด้วย LLM กลับ ส่งเสริมคนที่ไม่มีความอยากรู้อยากเห็น และลงโทษคนที่คิดลึก ทำให้คนแบบนี้อยู่รอดได้ดีขึ้น
  • ฉันก็เหมือนกัน ใช้แค่งานที่เฉพาะมาก ๆ เมื่อกี้เพิ่งคุยกับ Claude Code ไป 2 ชั่วโมง เพื่อจะแก้โค้ดแค่ 5 บรรทัด ที่เปลี่ยนความหมายอย่างมาก
    ในขณะที่เพื่อนฉันใช้เงินวันละ 10,000 ดอลลาร์ไปกับ agent tokens เพื่อพยายามสร้างอะไรบางอย่าง เขาเป็นคนฉลาดมากและเคยเป็นนักพัฒนามาก่อน ดังนั้นมันไม่ใช่อาการเพ้อจาก AI ง่าย ๆ แน่
    ฉันยังพยายามทำความเข้าใจมันอยู่ แน่นอนว่าฉันไม่มีเงิน 10,000 ดอลลาร์แบบนั้น
  • โค้ดที่ LLM สร้างมัก ซับซ้อนเกินจำเป็นและแน่นทึบ

• เหนื่อยมากจริงๆ ตั้งแต่เริ่มทำงานกับ LLM ผลงานของการเป็นนักพัฒนาเดี่ยวก็เพิ่มขึ้นได้ง่ายๆ ถึง 20 เท่า ตอนนี้ยังปิดงานโปรเจกต์ลูกค้าที่เมื่อก่อนถ้าทำคนเดียวคงทะเยอทะยานเกินไปได้แล้ว
  ฟีเจอร์ที่แต่ก่อนจะค้างอยู่ในช่วงวางแผนเป็นเดือนๆ หรือยาวกว่านั้น ก็กำลังถูกใส่เข้าไปใน codebase เก่า คุณภาพโดยรวมก็ดีขึ้นมาก test coverage ก็ครบถ้วนขึ้น และพูดตรงๆ ว่าดีขึ้นจริง
  โปรเจกต์ส่วนตัวก็ทำได้เร็วมากเช่นกัน บทบาทมันสลับกันไปแล้ว โดยผมปฏิบัติกับเอเจนต์เหมือนผมเป็นลูกค้า และเอเจนต์เป็นตัวผมเอง แน่นอนว่าผมเป็นลูกค้าที่มีความเทคนิคมากกว่า คอยกำหนดทิศทางสถาปัตยกรรมอยู่ ทุกวันผมใช้งานแอปและเครื่องมือที่เอเจนต์ทำให้ และยังยกเลิกการสมัคร SaaS ได้เพราะมีเครื่องมือที่ทำเอง
  พอดูการเรียกใช้เครื่องมือแล้วก็รู้สึกว่าควรรู้จักเครื่องมือ command line หลักๆ ให้ดีขึ้น เลยวางแผนเรียนตามให้ทันวันละนิด และยังกลับไปดู config เก่าๆ ที่เคยใส่ไว้ตอนเริ่มใช้ vim กับ tmux แบบไม่ค่อยรู้อะไรเลยด้วย
  ในทางทฤษฎีอาจรักษาระดับผลิตภาพไว้เท่าเดิมแล้วไปอ่านหนังสือเพิ่มก็ได้ แต่ดูเป็นไปไม่ได้ ตรงข้ามกับคำสัญญาที่ว่า “งานจะน้อยลง” ความจริงกลับให้ความรู้สึกเหมือนอยู่ใน ช่วงเปลี่ยนผ่านครั้งใหญ่ ที่ทั้งผลิตภาพและความคาดหวังพุ่งสูงขึ้น และการปฏิวัติอุตสาหกรรมก็ดูเป็นอุปมาได้เหมาะดี
  ความคาดหวังที่สูงขึ้นเกิดขึ้นทั้งในเรื่องเล็กและเรื่องใหญ่ เอเจนต์ขัดเกลาการนำเสนอข้อมูลได้ดีมาก จนตอนนี้การส่งรายงานที่สะอาดตาและกระแทกสายตา ซึ่งแต่ก่อนต้องใช้เวลาพอสมควร กลายเป็นเรื่องปกติไปแล้ว
  แต่ก็ยังเหนื่อยอยู่ ผมกำลังเร่งสุดตัวเพื่อสะสางงานให้ได้มากที่สุดก่อนที่ช่องทางสมัครสมาชิกของ Fable จะเปลี่ยนไปเป็น API อย่างเดียว ผมยังไม่เข้าใจเลยว่าคนอื่นใช้โทเคนกันเยอะขนาดนั้นได้ยังไง ทั้งที่ผมแทบไม่ได้นอนและโยนโค้ดให้ Fable ให้มากที่สุดเท่าที่ทำได้ ก็ยังแทบไม่แตะเพดานของแพลน 20x max เลย
  ผมบอกตัวเองมาตลอดว่าพอลดระดับลงแล้วจะชะลอความเร็ว แต่ตอนนี้มันขยายไปถึงวันที่ 12 แล้ว แถมหน้าต่างก็รีเซ็ต ทำให้มีเวลาเพิ่มอีกสองสามวันในการเคลียร์ backlog รู้สึกเหมือนต้องปล่อยให้หุ่นยนต์ทำงานกันทั้งคืน เพื่อที่ตอนตื่นเช้ามาจะได้มีอะไรให้รีวิวทันที การสั่งเอเจนต์ผ่านมือถือเองก็ยังรู้สึกแปลกๆ อยู่

  • การปฏิวัติอุตสาหกรรมทำให้ชีวิตโดยรวมดีขึ้นในวงกว้าง แต่สำหรับ ช่างทอผ้าแบบตั้งกี่ ที่เคยทำงานด้วยมืออยู่บ้าน แล้วต้องย้ายเข้าโรงงานเพื่อผลิตให้มากขึ้นพร้อมทำงานหนักทั้งวัน มันไม่ได้ทำให้ชีวิตดีขึ้นเลย
    จากมุมคนนอก ฟังดูคล้ายพ่อของผมที่เคยเป็นช่างเครื่องในโรงโม่ งานของเขาส่วนใหญ่คือเฝ้าดูเครื่องจักรทำงาน แล้วค่อยซ่อมเมื่อมันเสีย ซึ่ง 90% ของเวลาก็ทำงานได้ปกติ
    ถ้าเปลี่ยนจากการลงมือทำเองมาเป็นคอยเฝ้าเครื่องจักร มันอาจดูน่าเบื่อมากจริงๆ และจากมุมนั้นผมก็เข้าใจแรงต้าน AI ที่มีอยู่ที่นี่ได้
  • ผมมีเพื่อนคนหนึ่งที่เรียกตัวเองว่า พวกติด LLM และเขาก็พูดแทบจะเหมือนกันทุกอย่าง คำถามที่อยากถามแต่ไม่เคยถามตรงๆ คือ ถ้ามันทำให้หมดไฟได้ขนาดนั้น ทำไมถึงยังรู้สึกว่าต้องปั่นโปรเจกต์ส่วนตัวออกมาเยอะขนาดนี้ต่อไป?
    ทุกคนน่าจะเห็นตรงกันได้ว่าการต้องรีวิวโค้ดที่ AI สร้างขึ้นกองโตในงานมันชวนล้ามาก แล้วทำไมถึงอยากขยายสภาพที่น่าหงุดหงิดนั้นให้กินเวลาทั้งวันด้วยก็ไม่รู้
  • นี่เป็น สัญญาณของการเสพติด แบบคลาสสิก
  • ถ้าตัวเลือกมีเท่านี้ก็ดูแปลกดี คือจะบีบคั้นผลิตภาพที่เมื่อก่อนคุณไม่เคยรู้ด้วยซ้ำว่ามีอยู่ให้หยดสุดท้ายออกมา น่าจะได้เงินเท่าเดิมแต่หมดไฟเร็วขึ้น และต้องเถียงกับเครื่องโง่ๆ ที่ไม่ทั้งเหนื่อยไม่ทั้งท้อและไม่มีความสุขกับการเขียนโค้ด แถมยังไปไม่ถึงเป้าหมายอยู่เสมอนิดหน่อย
    หรือจะเขียนโค้ดด้วยมือต่อไป คิดหน้ากระดานไวท์บอร์ดเวลามันซับซ้อน แล้วค่อยๆ หมดไฟในจังหวะที่เป็นมนุษย์มากกว่า เหมือนที่ software engineering ทำกันมาตลอดกว่า 50 ปี
    ผมไม่เข้าใจว่าทำไมมันถึงกลายเป็นตัวเลือกแบบนี้ เอาจริงๆ คือคุณยังพอมี self-respect อยู่บ้างไหม? เดาได้เลยว่าจะมีข้ออ้างว่า “แต่หัวหน้าคาดหวังให้ใช้ AI” คนส่วนใหญ่น่าจะยังไม่เคยเจอ burnout แบบจริงๆ ถ้ามันมาเมื่อไรจะเจ็บปวดมหาศาล อย่าทำตัวเองให้เป็นเครื่องจักร มนุษย์ไม่ใช่เครื่องจักร

• ผมไม่ได้หมดไฟ แต่ทำงานคล้ายกับคนเขียนโพสต์ ผมยังสร้าง workflow ที่รีวิวโค้ดที่ LLM สร้างได้เร็วกว่าเขียนเองไม่ได้เลย
  ทางออกจาก dilemma นี้จริงๆ มีแค่สองทาง คือเชื่อของที่สร้างมาแบบไม่ลืมหูลืมตา หรือไม่ก็สร้างชุด unit test ที่ใหญ่ผิดปกติเพื่อตรวจสอบทุกสถานการณ์ที่เป็นไปได้
  เพราะงั้น business logic ผมจะเขียนเอง และปล่อยให้ LLM จัดการส่วนอื่นๆ อีกมาก โดย boilerplate ก็อยู่ในกลุ่มหลังด้วย

  • นั่นแหละคือสิ่งที่ควรต้องการ ต้องมีการทดสอบที่ครอบคลุมกว่ามากในทุกระดับ จนถึงขั้นที่ไม่สมเหตุสมผลหากให้มนุษย์สร้างหรือดูแลเอง รวมทั้ง unit, functional, end-to-end test แบบครบวงจร และมากกว่านั้น
    adversarial testing คือวิธีที่ดีที่สุดในการคุม AI ให้อยู่ในร่องในรอย และทำให้ diff ที่ต้องอ่านสะอาดและง่าย จะใช้แบบ TDD ที่ว่า “เขียนเทสต์ที่แสดงบั๊กนี้” หรือแบบหลังบ้านที่ว่า “พิสูจน์ด้วยเทสต์ใหม่ว่าแพตช์นี้ผิด” ก็ได้ทั้งนั้น
    วิธีที่ดีกว่าคือใช้ภาษาที่ type แข็งแรงกว่าเพื่อปิดให้แน่น แต่เทสต์นั้นเขียนได้กับทุกภาษา พื้นฐาน TDD และแนวคิด “เขียนเทสต์ให้หมด” ให้ความรู้สึกเหมือนเป็นสูตรลับเวลาใช้ AI ทำงาน
  • ผมก็แค่อ่านโค้ดอย่างระมัดระวัง มันง่ายมากที่จะไหลไปกับการรับผลลัพธ์ที่ได้มาเลยเพื่อเร่งความเร็ว แต่ การอ่านโค้ด สำคัญมาก
    พวกเทสต์ เทมเพลต UI บางส่วน หรือพวกงานตกแต่ง ผมจะไล่ดูคร่าวๆ เพื่อประหยัดเวลา แต่โค้ดส่วนใหญ่ที่จะเข้าไปอยู่ในระบบ backend ยังไงก็ต้องอ่าน
  • ถ้าคุณรีวิวมันได้ไม่เร็วกว่าการเขียนโค้ดเอง ก็ ควรเขียนเอง
  • สำหรับคนที่มีความรู้สึกคล้ายกัน อาจสงสัยว่าตัวเองมีความบกพร่องทางจิตอะไรหรือเปล่า ถึงได้ดื่ม Kool-Aid หวานๆ แล้วใช้ขยะที่สร้างขึ้นมาเฉยๆ แบบคนอื่นไม่ได้ เหมือนมีนิสัยบิดเบี้ยวบางอย่างที่ทำให้กลายเป็นคนดื้อที่คอยทำลายบรรยากาศสนุกของทุกคน
    ส่วนตัวผม คนที่ตื่นเต้นกับมนตร์ของ LLM มากที่สุดคือคนที่เดิมเขียนโค้ดไม่เก่ง เพราะตอนนี้อย่างน้อยก็สามารถหยิบอะไรสักอย่างที่ใช้งานได้ออกมาได้ แม้มันจะไม่ใช่โค้ดที่ดีที่สุด พอทำโค้ดที่รันได้ พวกเขาก็คิดว่ามันจะทำให้ทุกคนเก่งขึ้น แต่พวกเขาไม่รู้ด้วยซ้ำว่าขยะนั้นดูแลรักษาได้ไหม หรือจริงๆ แล้วมันเป็นขยะตั้งแต่แรกหรือเปล่า

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

  • ทุกวันนี้ฉันก็รู้สึกแบบเดียวกันกับเครื่องมือ AI สำหรับผู้บริโภค Gemini และ ChatGPT ช่วงหลังแย่มาก ตอนนี้ไว้ใจให้มันค้นหาและคิดต่อเนื่องหลายเทิร์นไม่ได้แล้ว
    เมื่อก่อนมันอยู่ในโหมดคิดได้นานเกิน 7 นาทีได้ เช่น ถ้าบอกว่า “ช่วยหาที่มาของข้ออ้างนี้หน่อย” มันจะค้นหา วิเคราะห์ และปรับคำค้นเอง เดี๋ยวนี้ต่อให้ใช้โหมด “Pro” แล้วกดแค่ไหนก็ทำให้มันทำงานเกิน 30 วินาทีไม่ได้ และสุดท้ายก็ได้แต่คำตอบกว้าง ๆ
  • มันจริงขนาดนั้นเหรอ? หรืออาจจะแค่ผ่านช่วง “ว้าว โคตรสุด” แรก ๆ ไปแล้ว แล้วความคาดหวังก็มาเจอกับความเป็นจริง
  • นี่ดูเหมือน การแก้ประวัติศาสตร์ย้อนหลัง แบบสุดโต่งจนตลก
    โมเมนต์ของ Opus 4.5 ก็เพิ่งเมื่อพฤศจิกายนที่ผ่านมาเอง ตอนนั้น agentic coding และเครื่องมือ coding CLI ส่วนใหญ่กลายเป็นตัวเลือกชั้นหนึ่งอย่างแท้จริง มันคือการเปลี่ยนกระบวนทัศน์ครั้งใหญ่ GPT-5 ก็ยังไม่ออก และคนส่วนใหญ่ยังใช้ 4o กันอยู่ ของที่มีให้ตอนนี้สำหรับงานเขียนโค้ดนั้นเหนือกว่า 4o มาก
  • ฉันไม่อินนะ ความคาดหวังของฉันอาจสูงขึ้นก็จริง แต่ถ้าเทียบสิ่งที่ฉันสร้างด้วยเอเจนต์เมื่อปีก่อนกับตอนนี้ มันคือ คนละโลก เลย

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

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

  • ถ้าจะเล่าอีกด้านหนึ่ง แรงกดดันให้ผลิตงานมากขึ้นในที่ทำงานมันมีจริง แต่ถ้านอกงานแล้ว นี่มันดีมาก อุปสรรคเรื่องการค้นคว้าและเวลาที่เคยขวางไม่ให้เริ่มโปรเจกต์ส่วนตัวลดลงไปเยอะ เลยทำโปรเจกต์ได้มากกว่าเมื่อก่อนมาก
    ช่วงนี้ฉันอินน้ำอัดลมมาก จนกำลังทำ เครื่องอัดคาร์บอเนตต่อเนื่อง เอง เป็นบิลด์ทั้งชุดที่มีตั้งแต่แหล่งจ่ายน้ำไปจนถึงก๊อก รวมปั๊ม แรงดัน ระดับน้ำ และพัดลมระบายความร้อนที่ควบคุมด้วย ESP32
    มันช่วยหาจุดพลาดในตะกร้าสินค้าให้เยอะมาก เช่น ฝั่งโฮมบริวมักใช้ท่อ 8mm แต่ระบบกรองน้ำใช้ 9.5mm อะไรทำนองนั้น ฉันปรับมันจากปั๊มเปิดปิดธรรมดากับสวิตช์ลูกลอย ไปจนแทบกลายเป็นระบบ PLC แบบเต็มตัว ได้การวนซ้ำจำนวนมากจากการคุยกับ “คนที่มีประสบการณ์มากกว่า” พออะไหล่มาถึง ฉันน่าจะประกอบเสร็จและรันซอฟต์แวร์ได้ภายในชั่วโมงเดียว
    มันไม่ได้เงิน แต่สนุกมาก
  • ฉันเริ่มเขียนโปรแกรมก็แค่อยากสร้างอะไรบางอย่าง การเขียนโค้ดเป็นแค่เครื่องมือไปสู่เป้าหมาย อย่าไปยึดติดกับ “ทำอย่างไร” มากเกินไป ลองคิดเรื่อง ทำไมถึงทำ และจะสร้างอะไร ให้มากขึ้นน่าจะดีกว่า
  • ถ้าคุณกำลังสร้างโปรดักต์ที่ใช้ LLM ส่วนที่น่าหงุดหงิดคือพอถึงจุดหนึ่ง มันจะหมดคันโยกให้ดึงเพื่อแก้ปัญหา
    สิ่งที่ดีที่สุดที่ทำได้เพื่อกันเอาต์พุตไม่พึงประสงค์ก็คือซ้อนแฮ็กทับแฮ็ก แต่สุดท้ายถ้า LLM ตัดสินใจว่าไม่อยากทำตามคำสั่ง ก็แทบไม่เหลืออะไรให้ทำนอกจากใส่ *IMPORTANT* เพิ่ม แล้วหวังว่าโมเดลรุ่นถัดไปจะช่วยแก้ให้
    ประสบการณ์นี้ใกล้เคียงกับการทำงานกับ external API ที่ควบคุมไม่ได้และไม่ได้ทำงานตามเอกสารอย่างมาก ซึ่งนั่นก็เป็นส่วนที่น่าหงุดหงิดที่สุดของการเขียนโปรแกรมมาแต่ไหนแต่ไร อย่างน้อยเมื่อก่อนเรายัง reverse engineer การทำงานจริงเพื่อหลบบั๊กได้ แต่ตอนนี้ “ขอบเขต” นั้นเปลี่ยนแบบสุ่มทุกวัน จนทำแบบนั้นไม่ได้อีกแล้ว
  • พวกที่พูดว่า “ฉันไม่สนหรอกว่าทำไมเครื่องคิดเลขในฝรั่งเศสใช้ไม่ได้ แค่ได้เงินก็แก้” ดูเหมือนจะถูกความก้าวหน้าทางเทคโนโลยีทำให้กลายเป็นฝ่ายที่มีเหตุผลขึ้นมา ซึ่งพูดตรง ๆ ว่าฉันรู้สึกขมขื่น
  • งานบัญชีจำเป็นมากเพราะเรื่องกฎหมายกับ compliance ต้องใช้ด่วนเลย ถ้าเข้าร่วมวันนี้ได้ก็ยิ่งดี

• แค่ใส่ style guide สั้น ๆ ไว้ใน CLAUDE.md หรือ AGENTS.md หรือเขียนตรง ๆ ว่า “ห้ามใช้อีโมจิ” ใช้เวลาแค่ 5 วินาที แล้วเอาต์พุตจาก LLM จะทนอ่านได้ขึ้นมาก style guide ง่าย ๆ ที่ใส่คำและวลีต้องห้ามไว้ก็ช่วยได้เหมือนกัน
  แน่นอนว่ามันไม่ได้แก้สมมติฐานที่ผิด อันนั้นยังต้องจับด้วยการอ่านละเอียดและคิดเชิงวิพากษ์แบบวิธีเดิม

  • เห็นด้วยสุด ๆ! ให้ฉันเขียนไฟล์ markdown พวกนั้นแทนไหม?
  • เผื่อเป็นข้อมูล เวลาใช้ ChatGPT เป็น pair programmer คุยแลกไอเดียด้านออกแบบ ขอให้เขียนโค้ด implementation หรือเสนอการ refactor มันไม่ใช้อีโมจิเลย
    แต่พอให้ช่วยวิเคราะห์ข้อมูลหรือทำโมเดล อีโมจิกลับโผล่มาทั่วไปหมด
    พอนึกถึงสิ่งที่เห็นบน GitHub ตลอดประมาณ 1 ปีที่ผ่านมา ฉันคงไม่มีวันปล่อยให้ LLM เขียน README หรือเอกสารของโปรเจกต์แบบไม่มีคนคุมเด็ดขาด