ทำไมถึงยังผลักดัน AI แบบเอเจนต์ ทั้งที่โมเดลยังทำตามคำสั่งง่าย ๆ ได้ไม่ดีพอ

 (forum.cursor.com)
4 คะแนน โดย GN⁺ 2025-10-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในความเป็นจริงที่โมเดล AI สำหรับเขียนโค้ดยัง ทำตามคำสั่งเดี่ยวได้ไม่อย่างน่าเชื่อถือ ก็ยังมีความคาดหวังเกินจริงต่อการเขียนโค้ดแบบเอเจนต์ที่ทำงานอัตโนมัติอยู่เบื้องหลัง
  • ผู้เขียนพบปัญหาว่าแม้จะให้ ฟังก์ชัน Golang ขนาดราว 100 บรรทัด เป็นโค้ดอ้างอิงแล้ว ทั้ง GPT-5 และ Gemini Pro ก็ยังตกหล่นบางตรรกะหรือพลาดการอัปเดตบางส่วน
  • การให้ระบบแบบเอเจนต์ จัดการ 50 ไฟล์และหลายฟังก์ชันโดยอัตโนมัติ ยังเป็นเรื่องไม่สมจริงในระดับเทคโนโลยีปัจจุบัน และอาจเสี่ยงทำให้เสียเวลากับการดีบักมากขึ้น
  • เสียงตอบรับจากชุมชนแบ่งออกเป็นสองฝั่ง คือมองว่ายังพอใช้ได้ในวงจำกัดหากมี การพรอมป์ตอย่างเป็นระบบ การทำเอกสาร และการตรวจสอบทีละขั้น กับอีกฝั่งที่มองว่าเอเจนต์ยังไม่พร้อมใช้งานจริง
  • ปัจจุบัน LLM ยังเป็น ระบบฐานความรู้มากกว่าความฉลาด ดังนั้นแนวทางที่เป็นจริงกว่าคือการใช้งานแบบเป็น “เครื่องมือ” โดยให้นักพัฒนาใส่บริบทเองและตรวจสอบทีละขั้น

ประเด็นปัญหาที่ผู้เขียนต้นฉบับตั้งคำถาม

  • กรณีคำสั่งง่าย ๆ ยังล้มเหลว: ให้ฟังก์ชัน Golang 100 บรรทัดเป็นข้อมูลอ้างอิง แล้วขอให้อัปเดตอีกฟังก์ชันหนึ่งให้มีโครงสร้างแบบเดียวกัน แต่ทั้ง GPT-5 และ Gemini Pro ก็ยังตกหล่นบางตรรกะหรือพลาดบางจุดที่ต้องอัปเดต
  • ความไม่สมจริงของการเขียนโค้ดแบบเอเจนต์: ในเมื่อแม้แต่ฟังก์ชันเดียวก็ยังจัดการได้ไม่ดี การปล่อยให้ระบบแบบเอเจนต์ไปแก้หลายฟังก์ชันข้าม 50 ไฟล์อย่างอัตโนมัติก็ยิ่งน่ากังวลว่าจะสร้างปัญหามากกว่าเดิม
  • คำถามเรื่องการอัปเดตไฟล์ 6000 บรรทัด: ขอความเห็นจากชุมชนว่าควรแก้ไฟล์ขนาดราว 6000 บรรทัดอย่างปลอดภัยอย่างไร เช่น กรณีอัปเดตเวอร์ชัน Stripe

กรณีใช้งานเชิงบวกและวิธีการ

แนวทางทำเอกสารและสร้างดัชนีอย่างเป็นระบบ

  • ใช้ไฟล์อ้างอิงแบบ Markdown: เก็บข้อมูลอ้างอิงไว้ในไฟล์ .md แล้วสั่งให้ AI อ่าน จะช่วยเพิ่มความสม่ำเสมอและความแม่นยำ
    • ตัวอย่างพรอมป์ต: "อ้างอิงไฟล์ goLang_Update_reference.md ที่แนบมา สรุปจุดสำคัญของฟังก์ชัน update และใช้สิ่งนี้เป็นฐานในการร่างการอัปเดตซอฟต์แวร์"
  • สร้างดัชนีในเครื่อง: สำหรับไฟล์ขนาดใหญ่ (6000 บรรทัดขึ้นไป) ให้สแกนเป็นช่วงละ 1000 บรรทัดเพื่อสร้างดัชนีที่มีชื่อฟังก์ชันและตำแหน่งบรรทัดอ้างอิง
    • เวลาทำงานฝั่งฟรอนต์เอนด์อาจแยกใช้ดัชนีเฉพาะส่วน เช่น fr.index.md

การจัดการเอเจนต์และโครงสร้างงาน

  • ทำเอเจนต์ให้เชี่ยวชาญเฉพาะด้าน: แยกบทบาทเป็น design (architect), code exploration (codeseeker), coder เป็นต้น และให้ไฟล์กฎ .md ที่เหมาะกับแต่ละบทบาท
  • แนวทาง vertical slice: แบ่งงานเป็นฟีเจอร์ย่อยที่ทำจบได้ภายในไม่เกิน 100,000 โทเค็น
    • หากเกิน 100,000 โทเค็น โอกาสที่เอเจนต์จะทำงานผิดพลาดจะเพิ่มสูงมาก
  • บังคับให้บันทึกงานเป็นเอกสาร: กำหนดให้อัปเดต docs/TASKS.md, docs/WORKLOG.md, docs/DECISIONS.md เสมอ เพื่อรักษาความต่อเนื่องของงาน

การใช้ Plan Mode และ Ask Mode

  • Plan Mode: ตรวจดูทั้งโปรเจกต์ วางแผนตามคำขอ แล้วค่อยดำเนินการทีละขั้น
  • Ask Mode: ใช้สำหรับค้นถามโค้ดเบส สำรวจไอเดีย หรือเทียบทางเลือก และมีประโยชน์ในฐานะเครื่องมือแทน Google/StackOverflow

แนวทางเขียน unit test ก่อน

  • การพัฒนาแบบอิงการทดสอบ: เขียน unit test ก่อนสร้างฟังก์ชัน แล้วให้ AI สร้างโค้ดซ้ำจนกว่าจะผ่านการทดสอบ
    • จะเพิ่มโอกาสได้โค้ดที่ถูกต้องตามหน้าที่อย่างมาก และหลังจากนั้นค่อยปรับแต่งหรือจัดระเบียบเพิ่มเติม

มุมมองเชิงสงสัยและการตระหนักถึงข้อจำกัด

ข้อจำกัดเชิงปฏิบัติของเอเจนต์

  • การปล่อยทำงานโดยไม่มีการกำกับเป็นเรื่องเสี่ยงมาก: ในระดับเทคโนโลยีตอนนี้ การโยนงานให้แล้วปล่อยทำอัตโนมัติอยู่เบื้องหลังมีโอกาสล้มเหลวสูง
  • มีโอกาสแต่งข้อมูลหรือมั่วคำตอบ: โมเดลมีแนวโน้มสร้าง hallucination มากกว่าจะสำเร็จจริง และในกรณีแย่ที่สุดอาจทำลายโค้ดเดิมได้
  • ความซ้ำซ้อนของ Planning Mode: แค่ขอให้โมเดลพื้นฐานวางแผนละเอียดก็อาจเพียงพอแล้ว โดย Planning Mode ไม่ได้เพิ่มความสามารถใหม่อย่างมีนัยสำคัญ

ข้อจำกัดเชิงธรรมชาติของ LLM

  • เป็นการทำนาย ไม่ใช่การให้เหตุผล: โมเดลทำงานโดยทำนายคำถัดไปโดยไม่ตรวจสอบผลลัพธ์ จึงยังเชื่อถือไม่ได้จนกว่าจะมี grounding, memory และ feedback ที่ดีขึ้น
  • ฐานความรู้ที่ไร้ความฉลาด: LLM คือฐานความรู้ขั้นสูงที่ไม่มีความฉลาดจริง ๆ นักพัฒนาจึงต้องใส่ความฉลาดเอง (BYOI: Bring Your Own Intelligence) และให้บริบทด้วยตัวเอง
  • หน่วยความจำไม่พอ: โมเดลไม่มีหน่วยความจำแท้จริง และพึ่งพาเพียง context กับ context cache ดังนั้นเมื่อเริ่มแชตใหม่ บริบทก็จะถูกรีเซ็ตทุกครั้ง

อคติด้านภาษาและข้อมูล

  • Golang เสียเปรียบในเชิงเปรียบเทียบ: Golang มีโค้ดสาธารณะให้นำไปเรียนรู้น้อยกว่า Python หรือ JavaScript ทำให้โมเดลมีแพตเทิร์นและธรรมเนียมปฏิบัติให้เรียนรู้น้อยกว่า
    • นี่เป็นปัจจัยเชิงโครงสร้างที่ทำให้การแก้ไขหรือแปลงโค้ดให้สม่ำเสมอทำได้ยากขึ้น

คู่มือเชิงปฏิบัติเพื่อใช้งานให้สำเร็จ

การพรอมป์ตและการให้บริบท

  • สั่งให้ชัดและละเอียด: ใช้ไวยากรณ์และเครื่องหมายวรรคตอนให้ถูกต้อง และใช้คำสั่งที่ชัดเจนแทนถ้อยคำกำกวม
  • อ้างอิงทุกไฟล์ที่เกี่ยวข้องอย่างชัดเจน: หากไม่ระบุไฟล์ทั้งหมดที่เอเจนต์ต้องใช้ โอกาสเกิด spaghetti code จะสูงขึ้น
  • ตั้งค่าไฟล์กฎ: กำหนดกฎทั้งระดับเวิร์กสเปซและระดับโปรเจกต์เพื่อช่วยให้สร้างโค้ดได้สม่ำเสมอ
  • ใช้ @Docs: ใช้ความสามารถอ้างอิงเอกสารเพื่อป้อนความรู้สำคัญที่เอเจนต์ต้องใช้ (แต่บางเวอร์ชันยังทำงานไม่เสถียร)

ขอบเขตงานและการตรวจสอบ

  • แบ่งเป็นหน่วยเล็ก: แยกงานเป็นหน่วยเล็กที่สุดที่ทำได้ในครั้งเดียว แล้วตรวจสอบแต่ละขั้นก่อนค่อยไปขั้นถัดไป
  • ทบทวนแบบเรียลไทม์: ตรวจโค้ดที่สร้างขึ้นทั้งหมดแบบทันที และขอให้แก้ไขทันทีเพื่อป้องกัน spaghetti code
  • สำรองข้อมูลและใช้ version control: สร้างแบ็กอัปทุกขั้น และใช้ระบบควบคุมเวอร์ชันอย่าง GitHub
  • รันทดสอบ: ใช้ pytest --testmon -q เพื่อรันทดสอบเฉพาะส่วนที่ได้รับผลกระทบแบบเพิ่มทีละส่วน และรันทดสอบทั้งหมดก่อนจบงาน

การทำโมดูลและโครงสร้างโค้ด

  • แยกไฟล์ 6000 บรรทัด: ไฟล์เดียว 6000 บรรทัดไม่เป็นโมดูลและเสียเปรียบในการให้บริบท จึงควรแยกเป็น 12 ไฟล์ขนาดราว 500 บรรทัดจะมีประสิทธิภาพกว่า
  • เน้น vertical slice: พัฒนาเป็นหน่วยฟังก์ชันเล็ก ๆ ที่รันใช้งานได้ครบตั้งแต่ต้นทางถึงปลายทาง

การเลือกโมเดลและการคุมต้นทุน

  • พิจารณา Claude Sonnet 4.5 ก่อน: มีความสม่ำเสมอและความแม่นยำสูงกว่า GPT หรือ Gemini จึงอาจคุ้มค่ากับต้นทุนที่เพิ่มขึ้น
  • ระวังการใช้โทเค็น: การวางแผนขนาดใหญ่ใช้โทเค็นมาก ดังนั้นการแบ่งทำเป็นขั้นเล็ก ๆ ตอนลงมือจริงจะคุ้มค่ากว่า

กรณีใช้งานเฉพาะทาง

การสร้างสคริปต์ใช้ครั้งเดียว

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

การสร้างแอปตั้งแต่ต้น

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

สรุปความเห็นจากชุมชน

ประสบการณ์เชิงบวก (เพิ่มผลิตภาพ 3–5 เท่า)

  • เว็บไซต์ Next.js: สร้างเว็บไซต์ที่ใช้งานได้จริงและพร้อมดีพลอยตั้งแต่ศูนย์ได้ภายในไม่กี่นาที
  • การทำฟีเจอร์ซับซ้อน: เพิ่มฟีเจอร์ threads ให้แอปแชตได้ใน 3–4 นาที (งานที่ปกติคาดว่าใช้ 3 วัน)
  • เมื่อใช้แนวทางอย่างเป็นระบบ: หากรวมกฎที่ชัดเจน บริบทที่เพียงพอ และการตรวจสอบทีละขั้น ก็มีโอกาสสำเร็จอย่างสม่ำเสมอ

ประสบการณ์เชิงลบ (ตอนนี้ยังไม่พร้อมใช้จริง)

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

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

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

 
GN⁺ 2025-10-15
ความคิดเห็นจาก Hacker News
  • จากที่ลองใช้เอง ฉันรู้สึกว่า LLM ส่วนใหญ่ทำตามคำสั่งของฉันได้ดีพอสมควร แน่นอนว่าต้องมีพรอมป์ต์ที่เกลามาอย่างดีและมีการวางแผนล่วงหน้า แต่ถ้าจับทางสามอย่างนี้ได้ coding agent พวกนี้ก็ช่วยทำงานได้คล่องมาก บางครั้งก็พลาดประมาณ 1 ครั้งจาก 10 ครั้ง แต่ถึงอย่างนั้นก็หยุดเร็วแล้วสั่งใหม่เพื่อกลับเข้าทางได้ไว ฉันแปลกใจที่ใน HN มีคนจำนวนมากยังสงสัยในประสิทธิผลของมัน แน่นอนว่ามีเรื่องให้กังวลทั้งต้นทุน การเปลี่ยนแปลงด้านอาชีพ ฯลฯ แต่การที่เห็นคนตั้งข้อสงสัยต่อประโยชน์ใช้สอยของ coding agent บ่อย ๆ ก็ยังน่าแปลกใจอยู่ดี
    • อยากเห็นวิดีโอหรือกรณีใช้งานจริงที่ระบบ agent หรือ LLM สร้างคุณค่าได้มากกว่าการค้นหาด้วย Google หรือ stack overflow จริง ๆ
    • ถ้าอธิบายสถานะปัจจุบัน ผลลัพธ์ที่ต้องการ และวิธีดำเนินการให้ครบถ้วน ก็สามารถวางแผนร่วมกับ agent ปรับแต่ง แล้วนำไปปฏิบัติได้ แบบนี้แล้วระดับเทคโนโลยีปัจจุบันก็น่าประทับใจทีเดียว จะหวังให้มันทำเรื่องซับซ้อนจากประโยคเดียวคงเกินจริง มันคล้ายกับการมอบหมายงานเทคนิคให้เด็กฝึกงานเก่ง ๆ ที่ยังไม่มีประสบการณ์ทำงานจริง ซึ่งต้องใช้ทั้งเวลาและความพยายาม เพียงแต่ AI agent ทำงานได้เร็วกว่ามนุษย์ฝึกงานมาก
    • คำว่า “ส่วนใหญ่ใช้ได้” แทบแปลว่ามันไม่มีตัวชี้วัดความน่าเชื่อถือจริง ๆ เลย
    • เมื่อกี้ตอนพาหมาไปเดินเล่น ฉันให้ Codex(gpt-5-high) แปลงแอป Python เป็น Go ได้ในครั้งเดียว ลองทดสอบผลลัพธ์แล้วใช้งานได้ดี ชอบตรงที่ตอนนี้ deploy เป็น single binary ได้โดยไม่ต้องมี virtual environment ไม่แน่ใจเหมือนกันว่าคำสั่งที่ให้มันง่ายมากหรือเปล่า
    • สำหรับฉัน มาตรฐานแบบ “ส่วนใหญ่ใช้ได้” ยังไม่พอ ปัญหาที่หนักกว่าการไม่ทำตามคำสั่งคือมันไม่ยอมรับว่าตัวเองผิด และกลับยืนยันคำตอบผิด ๆ ต่อไป ถ้าฉันให้ทำอะไรที่ซับซ้อนระดับกลาง ๆ หรือให้วิเคราะห์ error มันก็มักยึดติดกับข้อสรุปที่ผิดบ่อยพอสมควร หลายครั้งกว่าจะเจอทางออกก็ต้องรอให้ฉันชี้ปัญหาเองเสียก่อน งานโค้ดง่าย ๆ หรือพวก boilerplate มันทำได้ดีมาก และถ้าให้ feedback สักหน่อยก็เคยช่วยสร้างไลบรารีใหม่ได้ด้วย แต่เพราะมันพลาดบ่อย ฉันเลยไม่อยากฝากงานที่ซับซ้อนกว่านี้ ถึงอย่างนั้นเวลาไปต่อไม่ถูก ฉันก็ยังใช้มันระดมไอเดียอยู่ เพราะถึงจะผิด แต่มันช่วยเรื่องแรงจูงใจได้
  • เวลาประสบการณ์ของนักพัฒนากับ LLM ต่างกันมากอย่างน่าประหลาด สิ่งที่เราควรถามกันจริง ๆ คือ “ทำไมประสบการณ์ถึงต่างกันขนาดนี้?” คำอธิบายแบบ “เพราะคุณใช้ไม่เป็น” นั้นง่ายที่สุด แต่ในฐานะคนทำระบบ AI ฉันก็ยังแปลกใจที่มีผู้ใช้จำนวนมากคาดหวังผลลัพธ์ ทั้งที่พิมพ์แค่ “แก้ให้หน่อย”, “ทำรายงานให้หน่อย” โดยไม่มีคำสั่งที่ซับซ้อนเลย ขณะเดียวกันก็มีกระแส hype จากผู้บริหารแนว “AI ทำได้ทุกอย่าง” ซึ่งโยงกับมูลค่าบริษัทและราคาหุ้นด้วย ดูเหมือนคนทั่วไปก็ยังมอง AI ว่าเป็น “ปัญญาประดิษฐ์จริง ๆ” ทั้งที่ความจริงคำกล่าวว่า LLM ทำตามคำสั่งง่าย ๆ ไม่ได้เลยนั้นไม่น่าเชื่อถือ ประเด็นสำคัญกว่าคือมันยังทำงานที่ซับซ้อนไม่ได้ดีอยู่ดี
    • อีกทฤษฎีหนึ่งของฉันคือ แต่ละคนมีสเปกอยู่ในหัว แล้วเขียนมันออกมาแบบไม่ค่อยเป็นระเบียบพร้อมคาดหวังให้ LLM ไป implement ซึ่งผลลัพธ์จริงก็มักคลาดจากสเปกนั้นเสมอ นักพัฒนาบางคนอาจปรับสเปกในหัวทีหลังหรือยอมรับความต่างเล็กน้อยได้ แต่บางคนจะผิดหวังเพราะ LLM ทำไม่ตรงกับแผนในหัว มันคล้าย ๆ กับ “ความทรงจำปลอม” ทางจิตวิทยา บางคนยืดหยุ่นและประนีประนอมมากกว่า ขณะที่บางคนยึดติดแข็งกว่า ฉันเองก็สลับเจอสองแบบนี้เหมือนกัน
    • ตอนนี้ฉันอยากเห็น screencast บทความยาว หรืออะไรก็ได้ที่แสดงขั้นตอนครบจริง ๆ ของคนที่สร้างฟีเจอร์ที่ไม่ใช่งานง่าย ๆ ได้สำเร็จ AI influencer ส่วนใหญ่มักโชว์การใช้ AI ทำเครื่องมือ AI อีกที หรือไม่ก็เดโม CRUD กับ hello world เท่านั้น แม้แต่นักพัฒนารุ่นเก๋าที่บอกว่าโค้ดเกินครึ่งของ codebase มาจาก AI สุดท้ายก็ยอมรับว่าแทบทั้งหมดถูกทิ้งไป ใช้แค่อ้างอิงบางส่วน เรื่องเล่าแบบ “พรอมป์ต์เดียว → แอปเสร็จสมบูรณ์” ก็มักเปลี่ยนเป็น “มีประโยชน์ตอนต้องการแรงบันดาลใจจากหน้าจอว่าง ๆ” อย่างรวดเร็ว อยากให้มีการแชร์อย่างโปร่งใสมากขึ้นว่าคนทำงานจริงใช้มันอย่างไร
    • จริง ๆ แล้วคำว่า “นักพัฒนา” เป็นหมวดที่กว้างมากจนแทบไม่มีความหมายกับการถกเถียงนี้ สำหรับการต่อโค้ดชิ้นเล็ก ๆ แบบ CRUD ที่คนส่วนใหญ่ทำกัน LLM ค่อนข้างทำได้ดีทีเดียว
    • แต่ละคนก็ทำงานคนละแบบบน codebase คนละชนิด รายละเอียดสำคัญนี้แทบไม่ถูกพูดถึงเลย ยิ่งใช้บ่อย ความคาดหวังก็ยิ่งสูงขึ้น และจะสัมผัสข้อจำกัดได้เร็วขึ้น ใช้เป็นครั้งคราวมันดูน่าประทับใจ แต่ถ้าใช้ทั้งวัน สุดท้ายความผิดหวังก็สะสม มีหลายอย่างที่คิดว่า “ระดับนี้มันควรทำได้สิ” แต่สุดท้ายก็ต้องมานั่งแก้อีก
    • ฉันมั่นใจว่าไม่ใช่ผลลัพธ์ต่างกัน แต่เป็นเพราะแต่ละคนมีความคาดหวังไม่เท่ากัน SVP ฝ่าย IT ของบริษัทฉันเป็นสายสรรเสริญ AI มาก ช่วงนี้ฉันกำลังทำโปรเจกต์ PHP legacy ที่เขาเคยสร้างไว้ แล้วก็พบว่ามาตรฐานคุณภาพโค้ดที่เขาพอใจนั้นต่ำมาก ฉันเองก็ใช้ LLM ทุกวัน แต่ต้องแก้ผลลัพธ์ตลอด กล่าวคือ ยิ่งมาตรฐานคุณภาพโค้ดต่ำ ก็ยิ่งพอใจกับผลงานของ LLM มากขึ้น
  • ในฟอรัมของ cursor จะมีแต่คนพูดว่า “คุณใช้ผิดเอง” แต่สิ่งที่ฉันสงสัยจริง ๆ คือเรื่องความน่าเชื่อถือ กระบวนการ และการใช้จริงในงานประจำวัน แม้แต่ที่นี่ก็ยังรู้สึกว่าแทบไม่เห็นใครใช้มันในระดับใหญ่จริง ๆ พวกเราเองก็ใช้ AI กันเป็นเหมือน “เพื่อนร่วมงานที่ไม่ค่อยฉลาด” และใช้แบบทดลองมากกว่ากับ side project ที่มีข้อจำกัดน้อย agent ดูเหมือนจะเป็นแค่ hype เสียมากกว่า (หรือไม่ก็มีประโยชน์เฉพาะทางมาก ๆ)
    • ที่ OP ได้ผลลัพธ์ไม่ดีเป็นเพราะใช้ Cursor Cursor ตัด context ของบทสนทนาอย่างโหดมากเพื่อลดต้นทุน ต่างจากผู้ให้บริการโมเดลโดยตรง มันต้องจ่ายค่าใช้ LLM ในราคา retail จึงเสียเปรียบด้านราคา Cursor ไม่ได้เปิดเผยอย่างโปร่งใสว่ามันตัด context ไปมากแค่ไหน และจากประสบการณ์ของฉันมันตัดอย่างรุนแรงจริง ๆ จนต้องเรียกไฟล์เดิมกลับมาให้มันดูซ้ำ ๆ เพื่อให้มันเข้าใจว่าอะไรเป็นอะไร คำแนะนำของฉันคือเลิกเสียเวลากับ Cursor ได้แล้ว โค้ดที่ Cursor สร้างทิ้งไว้มีแต่หนี้ทางเทคนิค เปลี่ยนมาใช้ Codex กับ Claude แล้วฉันพอใจกว่ามาก
    • อยากรู้ว่าคุณหวังให้มันดีขึ้นแบบไหนกันแน่ โพสต์ต้นฉบับไม่มีตัวอย่าง พรอมป์ต์ หรือวิธีการที่เฉพาะเจาะจงเลย มีแค่แนว ๆ “ฉันเขียนพรอมป์ต์เก่งนะ” ซึ่งแบบนี้ทั้งประเมินและให้คำแนะนำก็ยาก เข้าใจได้ถ้าคุณจะสงสัย workflow แบบ agentic ตั้งแต่ต้น แต่ก็เหมือนยังไม่ได้เปิดโอกาสให้คนอื่นโต้แย้งอย่างจริงจัง ฉันเองก็ทำงานร่วมกับ agent มาหลายเดือนแล้ว และยังคงเรียนรู้อยู่ว่าอะไรเวิร์กอะไรพัง จากประสบการณ์ของฉัน:
      • orchestration ด้วยเฟรมเวิร์กอย่าง agent-os เป็นสิ่งจำเป็น
      • การหาสมดุลระหว่างการกำกับกับความอิสระเป็นเรื่องสำคัญ
      • การวางแผนล่วงหน้าสำคัญมาก โดยเฉพาะกับโค้ด legacy
      • ตัวอย่างของฉัน: ในระบบ legacy มันชนขีดจำกัด context window ตลอด และพอฉันสรุป context ข้อมูลสำคัญก็มักหายไป ทำให้มันทำพลาดแบบเดิมซ้ำ ๆ
      • วิธีที่ได้ผล: จัดโครงปัญหาให้ชัด บันทึกสิ่งที่ค้นพบ/เรียนรู้ไว้ละเอียดทีละข้อ และแยกเป็น sub-agent ที่เฉพาะมาก ๆ (เพื่อให้ควบคุม context window ได้) หลังจากนั้น agent ถึงเริ่มช่วยงานสำรวจโค้ด legacy ได้จริง
    • ฉันเคยให้ agent ช่วยเจอ production bug หลายตัวที่ฉันหาไม่พบมาก่อน (เป็นบั๊กที่ไม่คุ้นและฉันไม่มีเวลาทุ่มให้มากพอ) แน่นอนว่ามีบั๊กอีกเยอะที่มันหาไม่เจอ แต่เมื่อเทียบกับการให้วิศวกรซอฟต์แวร์ใช้เวลาหนึ่งชั่วโมงมานั่งหา ต้นทุนมันแทบจะฟรี และถ้าบางครั้งมันใช้ได้ผล แค่นั้นก็คุ้มจะลองแล้ว
    • โพสต์ที่มีตัวอย่างจริงและเฉพาะเจาะจงจะมีความหมายมากกว่า และน่าจะได้คำตอบที่ดีกว่าด้วย ข้อมูลที่แสดงปัญหาจริงในงานประจำและขั้นตอนที่ LLM ล้มเหลวน่าจะมีประโยชน์กว่า
    • มูลค่าทางธุรกิจจริง ๆ มันเล็กกว่าที่คนคิดไว้มากจนน่าหงุดหงิด แน่นอนว่าในงาน boilerplate หรืองานในโดเมนที่คุ้นเคย มันอาจทำได้ดีกว่ามนุษย์ด้วยซ้ำ แต่ปัญหาอื่น ๆ นอกเหนือจากนั้น (การพึ่งพา Big Tech, ข้อมูลปนเปื้อน, ข้อมูลที่ตรวจสอบไม่ได้, ความคิดสร้างสรรค์ลดลง, ความเป็นต้นฉบับพังทลาย, ความไม่รู้ของพวกคลั่ง AI, การใช้พลังงาน, การเอาผลงานมนุษย์ไปใช้โดยพลการ ฯลฯ) มันใหญ่เกินไป ฉันเลยแปลกใจที่ยังมีคนเชื่อว่าสิ่งนี้ให้ผลสุทธิบวกต่อมนุษยชาติ
  • ในปี 2025 การตลาดทำได้แนบเนียนมากตามฟอรัมทุกแห่งอย่าง Reddit, LinkedIn ฯลฯ จนแบรนด์แทรกซึมเข้าไปในบทสนทนาได้หมด CEO, “นักคิด” ด้าน AI, VC ต่างโปรโมต LLM ราวกับเป็นเวทมนตร์ และพยายามขายภาพว่า v0, Lovable ฯลฯ คือคลื่นนวัตกรรมลูกต่อไป คำตอบจากฝั่งผู้นำก็แทบเหมือนกันหมด (วิดีโอที่เกี่ยวข้อง) แต่ในความเป็นจริง ต่อให้ทำ CLAUDE.md หรือ cursorrules มากแค่ไหนก็แทบไม่ช่วย สุดท้าย LLM ต้องทำตามคำสั่งให้ได้ แต่ที่เกิดขึ้นจริงกลับเหมือนสุ่ม มันแทบไม่ยอมทำตามแม้แต่กฎง่าย ๆ มาก ๆ เลยทำให้ฉันรู้สึกว่าคนที่โพสต์ในฟอรัม Cursor ดูเหมือนมือสมัครเล่นกันหมด และที่สำคัญ งานเขียนโค้ดใหม่ ๆ นั้น LLM ทำได้แย่มาก มันชอบตั้งสมมติฐานว่ามีไลบรารีที่ไม่มีอยู่จริง แล้วก็ผลิตตัวอักษรไร้ประโยชน์ออกมา ฉันใช้มันแทบจะเหมือน speech-to-text เท่านั้น แต่ LLM กลับจับ edge case, best practice ที่ฉันไม่รู้ หรือเรื่อง syntax ได้ดีกว่าฉัน
    • [1] ผลลัพธ์จาก search, Perplexity ฯลฯ ส่วนใหญ่ก็เป็นก้อนการตลาดที่ทีมการตลาดโปรยเอาไว้ทั้งนั้น
    • เห็นด้วยเต็มที่กับคำพูดที่ว่า LLM แย่มากกับงานเขียนโค้ดใหม่ ๆ โมเดล SOTA ปัจจุบันอาจสร้าง boilerplate หรือโครงสร้างง่าย ๆ ได้ดีในเฟรมเวิร์กที่มีชื่อเสียงมากและมีรูปแบบคงที่ชัดเจน (เช่น MVC ฯลฯ) จุดที่มันโดดเด่นจริง ๆ คือภารกิจแบบไล่อ่านข้อมูลจำนวนมากเพื่อค้นหาบางอย่าง เช่น ใน codebase, log, stack trace ฯลฯ แต่การตลาดที่บอกว่า “agent จะสร้าง codebase ทั้งหมดได้” สำหรับตอนนี้ฉันคิดว่ายังไม่ใช่เรื่องจริง
    • ประสบการณ์ของฉันกลับตรงกันข้ามสุด ๆ ในช่วงสัปดาห์ที่ผ่านมา Claude Code แก้ปัญหาคอมไพเลอร์ที่ฉันดูแลอยู่ได้แทบจะด้วยตัวเอง แม้จะมีบางครั้งที่น่าหงุดหงิด แต่มันก็แก้ทั้งปัญหา code generation แบบละเอียดอ่อนและบั๊กใน parser ได้อย่างต่อเนื่อง และส่วนที่ฉันต้องเข้าไปยุ่งก็มักเป็นเรื่องข้อจำกัดของเครื่องมือมากกว่า เช่น การจัดการ compaction มันยังอุตส่าห์ implement วิธีการที่ปกติต้องไปเปิดหนังสือดู และเมื่อรันจริงก็ยืนยันได้ว่าใช้ได้ผล อาจจะไม่ได้ “ปฏิวัติ” หรือใหม่แบบแท้จริงนัก แต่เอาเข้าจริงโค้ดแทบทั้งหมดก็ไม่ได้ใหม่อะไรอยู่แล้ว จากประสบการณ์ของฉัน ถ้าให้คำสั่งตามแนวทางที่จัดโครงสร้างมาดี มันมักทำตามได้ดีมาก ไม่ใช่แค่เขียนอะไรโยน ๆ ไว้ใน CLAUDE.md แล้วจะได้ผล หัวใจสำคัญคือการชี้นำกระบวนการอย่างละเอียด วิธีทำงานของฉันแบ่งเป็น 1) คู่มือดีบักรายโปรเจกต์ 2) ทำ acceptance criteria ให้ชัด 3) รันเทสต์บ่อย ๆ และให้มันบันทึกการเปลี่ยนแปลงเล็ก ๆ เป็นไฟล์ทีละหน่วย แบบนี้ฉันสามารถปล่อยให้ Claude ทำงานอัตโนมัติหลายชั่วโมงได้แทบไม่ต้องเฝ้า (แค่คอยพิมพ์ “continue” หรือใช้ /compact เป็นครั้งคราว) มันไม่ได้ให้โค้ดสมบูรณ์แบบทุกครั้ง แต่ฉันเองก็ไม่ได้เหมือนกัน ถึงอย่างนั้นโดยรวมมันนำไปสู่การเปลี่ยนแปลงเชิงบวก และลดแรงที่ฉันต้องใช้ลงมาก ฉันยังไม่แนะนำให้ใช้ bootstrap ในสถานะที่ออกแบบไม่ครบถ้วน แต่บางครั้งมันก็ทำได้อยู่ดี (แค่ต้อง review ล่วงหน้า) ทุกวันนี้ฉันถึงขั้นคิดจะปล่อยให้ Claude ทำงานแก้ปัญหาอัตโนมัติแบบไม่หยุดเป็นเวลาหลายวัน
    • น่าสนใจมากที่ประสบการณ์ของแต่ละคนกับ LLM ต่างกันได้ขนาดนี้ สำหรับฉัน codex-cli ทำให้รู้สึกว่าผลิตภาพเพิ่มขึ้น 5 เท่า มันรับมือได้สบายทั้งการแปลง source ที่มีโครงสร้างแปลกมากพร้อม internal SVG execution trace ไปเป็นฟอร์แมตกราฟ JSON แบบ custom หรือการดึงเอกสารอย่างแม่นยำจาก codebase Python/C++ ที่ซับซ้อน (รวมถึงเคอร์เนล RISCV ระดับล่าง) ฉันอยากรู้จริง ๆ ว่าอะไรเป็นสาเหตุให้เครื่องมือเดียวกันให้ผลลัพธ์ต่างกันได้ขนาดนี้
    • เวลาเขียนโค้ดกับ Claude มันให้ความรู้สึกเหมือนเล่นสล็อต บางครั้งก็ได้สิ่งที่ต้องการเป๊ะ ๆ แต่บ่อยกว่านั้นคือไม่ใช่หรือหลุดไปไกลมาก ห้ามปล่อยให้วิ่งเองแบบไร้คนเฝ้าเด็ดขาด
    • สำหรับฉัน คุณค่าที่สม่ำเสมอที่สุดของ LLM คือมันจับความผิดพลาดเล็ก ๆ น้อย ๆ ตัวอย่างที่ดีที่สุด หรือ syntax โค้ดที่มนุษย์มักพลาดได้ดีมาก ดังนั้นใช้มันเป็น reviewer ของ PR แบบฟังหูไว้หูก็ถือว่าโอเค
  • บริษัทของเราใช้แนวทาง classic XP เวลาเพิ่มฟีเจอร์ใหม่ให้แอป brownfield เราจะแยกเป็น sub-agent เกือบ 8 ตัว เช่น red-test-writer, minimal-green-implementer, refactorer ฯลฯ ตอนนี้แค่พิมพ์กับ Claude Code ว่า “ช่วยสร้างฟีเจอร์ X ด้วยกระบวนการ TDD นี้” ผ่านไป 30 นาที ก็ได้โค้ดที่ดีกว่ามาก มี test coverage 90% และอยู่ในสภาพพร้อมรับเข้าได้ทันที แม้จะอิงจากประสบการณ์หลายปีด้าน XP, pair programming, TDD แต่ตลอดเวลากว่าหนึ่งปีที่ผ่านมา โค้ดโปรดักชันของเรา 95% ถูกเขียนโดย AI (รวมถึงฟีเจอร์ซับซ้อนที่ไม่ใช่งานง่าย ๆ ด้วย) ไม่มีเคล็ดลับลับอะไรเป็นพิเศษ มันแค่ใช้ได้ผลดีมากสำหรับเรา
  • ความเห็นที่นี่ต่างกันมาก ถ้าแต่ละคนไม่บอกว่าตัวเองล้มเหลวกับอะไร หรือใช้มันกับงานแบบไหน ก็แทบเป็นไปไม่ได้ที่จะถกกันอย่างมีคุณภาพ ถ้าไม่พูดถึงหมวดหมู่เฉพาะที่ LLM สำเร็จ/ล้มเหลว การสนทนาทั้งหมดก็ไม่เกินเสียงรบกวน
    • เวลาอภิปรายควรระบุให้ละเอียดทั้งภาษา/เฟรมเวิร์ก, โดเมนของปัญหา, ระดับ SRE, LLM (โมเดล/เวอร์ชัน), agentic harness (claude code, codex, copilot ฯลฯ), กรณีที่ล้มเหลว/สำเร็จ รวมถึงระดับความชำนาญในการใช้ LLM ของผู้ใช้ด้วย อีกทั้งเงื่อนไขยังต่างกันได้อีก เช่น วิศวกรทำ codebase เดียวมา 10 ปี หรือสลับหลายโปรเจกต์, เป็นงานพัฒนาใหม่ (Greenfield) หรือ maintenance, เป็นงานวิจัยนวัตกรรมหรือ CRUD เป็นต้น
  • ในมุมมองนักวิทยาศาสตร์ มักมีงานที่ต้องทำ boilerplate ซ้ำ ๆ แบบต่างกันเล็กน้อยในแต่ละ dataset ซึ่ง coding agent ช่วยตรงนี้ได้มากพอสมควร โดยเฉพาะเวลาย้ำตัวโต ๆ ตั้งห้าครั้งว่า “ห้ามสร้างข้อมูลขึ้นมาเองเด็ดขาด ห้ามใช้ np.random” แล้ว Claude ยังเมินเฉย จุดนี้ชวนงงอย่างไม่น่าเชื่อ ตอนมันเวิร์กก็คือยอดเยี่ยม แต่พอไม่เวิร์ก มันกลับไม่มีสัญญาณความล้มเหลวอะไรเลย จากมุมการตลาด LLM ฉันยังจินตนาการถึง agent แบบ ‘PIPA(Performance Improvement Plan Agent)’ ที่คอยตามเฝ้า coding agent แบบเรียลไทม์ว่าทำงานถูกต้องไหม PIPA จะคอยตรวจผลงานของ coding agent เพื่อให้ HR หรือผู้บริหารบริหาร “พนักงาน AI” (agent) ได้ อนาคตอาจไปทางนั้นก็ได้
    • พอมีคนบอกว่า “อย่าคิดถึงช้างใส่กระโปรงทูทูสีชมพู!” คุณก็นึกขึ้นมาทันทีไม่ใช่หรือ? ถ้าเป็นนักวิทยาศาสตร์ก็น่าจะรู้ว่าธรรมชาติของ LLM คือเข้าใจประโยคปฏิเสธได้ไม่ดี LLM เรียนรู้ระดับโทเคน ดังนั้นถึงจะบอกว่า “NO ELEPHANTS” คำว่า ‘ช้าง’ ก็ยังคงอยู่ในบริบท มันจึงกลับถูกชี้นำไปทางคำนั้นมากกว่า การใช้คำสั่งเชิงบวกจะได้ผลดีกว่า
    • แค่นึกภาพ PIPA ก็หลอนแล้ว
  • หัวใจคือการใช้พรอมป์ต์ (เช่น ข้อความ error ที่ดี) เพื่อให้โมเดลหาบริบทที่เหมาะสมได้เอง และถ้าแบ่งงานเป็นชิ้นเล็กและสม่ำเสมอมากพอ ก็จะส่งต่อผลการทดสอบแบบเป็นรอบ/เป็นขั้นไปยังบริบทของงานถัดไปได้ 50% ของปัญหาเข้ากับวิธีนี้ และอีก 50% นั้น LLM loop อาจยุ่งยากน้อยกว่าการทำ automation แบบดั้งเดิม แต่ในกลุ่มนั้นก็มีครึ่งหนึ่งที่ไม่น่าคุ้มค่ากับการลงทุน สุดท้ายถ้ามีเคส “12.5%” อันมหัศจรรย์อยู่จริง แนวทาง agent แบบ constrained น่าจะเหมาะที่สุด
    • ถ้าเอากระบวนการนั้นมาไลฟ์สดบน YouTube หรือที่อื่น (ไม่ใช่ tutorial แต่เป็น live coding ธรรมชาติ) ก็น่าจะแชร์อินไซต์ได้ดี
  • เกือบ 30 ปีก่อน ตอนที่ฉันเริ่มต้นกับ AI เคยมีคนพูดแบบนี้ว่า เมื่อได้ยินคำว่า “intelligent agent(เอเจนต์อัจฉริยะ)” ให้คิดว่ามันคือ “มดที่ฝึกได้”
    • อยากฟังรายละเอียดเพิ่ม
  • สำหรับฉัน ปัญหาใหญ่ที่สุดคือประสิทธิภาพของเครื่องมือ AI เหวี่ยงขึ้นลงมากตามชนิดงาน และคาดเดาได้ยากว่าจะพังตรงไหน ทำให้เสียเวลา พอใช้ไปมากขึ้นก็คิดว่าทักษะการเขียนพรอมป์ต์น่าจะดีขึ้น แต่ก็ยังน่าหงุดหงิดอยู่ดี อย่างไรก็ตาม ก็มีบางส่วนที่ agent และ AI ทับซ้อนกับประโยชน์ใช้งานจริง เช่น การสร้าง boilerplate ให้โปรเจกต์ใหม่อัตโนมัติ เป็นต้น ในกรณีแบบนั้น ‘agent mode’ จะสะดวกกว่า ตอนนี้ประสบการณ์ใช้งานจริงของฉันยังไม่มากนัก
    • ยิ่งมันทำงานได้ดี ความคาดหวังก็ยิ่งสูงขึ้น และขอบเขตการใช้งานก็ยิ่งกว้างขึ้น แต่พอชนข้อจำกัดเข้าเมื่อไร ความผิดหวังก็กลับแรงกว่าตอนเริ่มต้นเสียอีก