Ask HN: การเขียนโค้ดแบบเอเจนต์ได้ผลจริงหรือไม่?

 (news.ycombinator.com)
6 คะแนน โดย GN⁺ 2026-01-22 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ฉันลองทำ agent coding แล้ว แต่ปวดหัวกับ ช่องว่างระหว่างสิ่งที่เห็นออนไลน์กับผลลัพธ์ที่ฉันได้จริงตอนลงมือทำ เลยอยากรู้ว่ามีหลักฐานไหมว่ามันให้ผลลัพธ์เชิงบวกได้จริง
  • ถ้าข้ามโฆษณาชวนเชื่อที่เกินจริงไป และมีใครที่ นำ agent coding ไปใช้ได้สำเร็จจริง ช่วยแชร์แบบละเอียดหน่อยว่าทำอย่างไร
  • "นำไปใช้ได้สำเร็จจริง" ในที่นี้หมายถึง
    • สร้างคุณค่าได้มากกว่าหนี้ทางเทคนิค
    • เขียนโค้ดที่ มีโครงสร้างแข็งแรงพอให้ผู้นำด้านสถาปัตยกรรมอนุมัติได้
  • ช่วงหลังเริ่มเห็นกระแส ลดการรีวิวโค้ดให้เหลือน้อยมากหรือไม่ทำเลย พร้อมข้ออ้างว่าควรเปลี่ยนจาก "การตรวจสถาปัตยกรรม" ไปเป็น "การตรวจพฤติกรรมการทำงาน"
  • ในทางปฏิบัติ ดูเหมือนว่าจะหมายถึง ถ้าเทสต์กับ CI ผ่านก็ปล่อยขึ้นโปรดักชันได้โดยไม่ต้องดูโค้ด ซึ่งฉันสงสัยว่าวิธีแบบนี้ จะยั่งยืนในระยะยาวจริงหรือไม่
  • ความเห็นส่วนตัวของฉันคือ ถ้าใช้ Codex มันอาจทำงานได้บนเส้นทางปกติ แต่มีแนวโน้มจะกลายเป็น "spaghetti code" ที่ค่อย ๆ สะสมข้อผิดพลาดเล็ก ๆ ที่ดีบักยากเมื่อเวลาผ่านไป
  • ตอนลองใช้ Codex กับโค้ดเบสเดิม ไม่ว่าจะตั้งแนวทางไว้หรือไม่ก็ตาม เวลาครึ่งหนึ่งของฉันหมดไปกับการแก้ข้อผิดพลาดเล็ก ๆ หรือโค้ดซ้ำซ้อนที่ Codex สร้างขึ้น
  • เมื่อสุดสัปดาห์ที่แล้ว ฉันลองสร้างแอป iOS แจ้งเตือนอาหารสัตว์เลี้ยงขึ้นมาใหม่ตั้งแต่ต้น
    • ให้ Codex ช่วยสำรวจและเสนอพิมพ์เขียวสถาปัตยกรรมที่ใช้ SwiftUI ก่อน แล้วก็ช่วยกันเขียนสเปกที่อธิบายว่าต้องทำอะไรและทำอย่างไร
    • การพัฒนาเวอร์ชันแรกมีบั๊กอยู่บ้าง แต่ดีกว่าที่คาดไว้แบบน่าประหลาดใจ ทว่าหลังจากนั้น ทุกอย่างกลับแย่ลงอย่างรวดเร็ว
    • ตลอดช่วงสุดสัปดาห์ที่เหลือ ฉันพยายามทำให้ Codex ทำงานได้ถูกต้อง แก้บั๊กโดยไม่สร้างบั๊กใหม่ และศึกษาวิธีปฏิบัติที่ดีแทนการเขียนโค้ดแบบสุ่มเดา
    • ทุกครั้งที่เจอแนวทางหรือกฎใหม่ก็ให้ Codex บันทึกไว้ แต่สถานการณ์ก็ไม่ดีขึ้น สุดท้ายเลยยอมแพ้
  • สำหรับฉัน การปล่อยโค้ดที่ไม่ผ่านการตรวจทานเป็นสิ่งที่ยอมรับไม่ได้
  • เหมือนมีบางอย่างผิดพลาดอยู่ ผลิตภัณฑ์ต้องทำงานได้จริง แต่คุณภาพของโค้ดก็ต้องสูงด้วย

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

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

 
GN⁺ 2026-01-22
ความคิดเห็นจาก Hacker News

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

    • ไม่นานมานี้ผมเองก็ได้รับ ข้อเสนอ 200 ดอลลาร์ จากบริษัทแห่งหนึ่งให้ช่วยโปรโมต “agentic coding platform” ตัวใหม่
      การที่ข้อเสนอแบบนี้ไปถึงผู้ใช้ทั่วไปแบบสุ่มได้ แปลว่ามี แคมเปญการตลาด ขนาดใหญ่กำลังเดินอยู่แล้ว
    • LLM เป็น เครื่องมือที่ก้าวกระโดด อย่างไม่ต้องสงสัย แต่ไม่ใช่ กุญแจสารพัดนึก ของการพัฒนาแบบอัตโนมัติเต็มรูปแบบ
      กับงาน CRUD ง่าย ๆ มันใช้งานได้สนุก แต่กับโปรเจ็กต์ซับซ้อนกลับทำให้น่าหงุดหงิดมากกว่า
      ตอนนี้เป็นช่วงที่การแข่งขัน benchmark กับเงิน VC หลั่งไหลเข้ามา จน คุยกันอย่างเยือกเย็นได้ยาก
    • ผมคิดว่าเหมือนตอน GUI เพิ่งถือกำเนิดขึ้นมา ตอนนี้เราอยู่ในช่วงที่เริ่มสัมผัสได้ถึง คุณค่าเชิงสัญชาตญาณ
      แม้ยังขาดหลักฐานเชิงปริมาณ แต่ถึงนักพัฒนาจะไม่ได้หายไปหมด วิธีพัฒนาซอฟต์แวร์ก็เปลี่ยนไปตลอดกาลแล้ว

  • Principal Engineer คนหนึ่งของ Google ทวีตว่า “Claude Code ทำงานที่ปกติต้องใช้เวลา 1 ปีให้เสร็จใน 1 ชั่วโมง”
    แต่ภายหลังมีการเปิดเผยว่าสิ่งที่ AI สร้างขึ้นเป็นเพียง ‘เวอร์ชันของเล่น’ เท่านั้น
    คำพูดที่เว่อร์แบบนี้ทำให้ ความคาดหวังบิดเบี้ยว และนำไปสู่ความผิดหวัง
    ลิงก์ทวีตที่เกี่ยวข้อง

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

  • มองย้อนกลับไปในช่วง 6 เดือนที่ผ่านมา ได้ประสิทธิภาพเพิ่มขึ้น 10 เท่าใน โค้ดอินฟราฯ (เช่น Terraform)
    แต่การพัฒนา ฟีเจอร์เฉพาะทาง ยังขึ้น ๆ ลง ๆ อยู่
    ถึงอย่างนั้น เวลาที่ได้คืนมาจากการลดงานซ้ำ ๆ ก็เอาไปเพิ่มคุณภาพด้าน การทดสอบและความปลอดภัย ได้
    ที่สำคัญที่สุดคือมันทำให้กลับมารู้สึกถึง ความสนุกของการเขียนโค้ด อีกครั้ง

    • ผมเองก็ทำงานพัฒนาเป็นงานอดิเรกมา 35 ปีแล้ว และ AI ช่วยลด การพิมพ์ที่น่าเบื่อ พร้อมปลุกความคิดสร้างสรรค์
    • ผมเองก็เร็วขึ้นมากกว่า 2 เท่าในงานอย่าง build script หรือ CI แต่โปรเจ็กต์ HPC ที่ซับซ้อนก็ยังยากอยู่
      และแนวทาง assisted coding มีประสิทธิภาพที่สุด
      ลิงก์โปรเจ็กต์
    • ผมใช้ Claude ทำเครื่องมือค้นหาไฟล์ใน NAS ที่บ้าน และทำทั้ง Go backend กับเว็บ UI ที่ทำ index อัตโนมัติทุกวัน เสร็จในวันเดียว
      ผมคิดว่าโปรเจ็กต์ส่วนตัวแบบนี้แหละคือ game changer ตัวจริง
    • ถ้า แบ่งงานให้เล็กลง เอเจนต์จะทำงานได้ดีกว่ามาก
    • แต่ คุณภาพของโค้ดทดสอบ ยังต่ำอยู่ดี เพราะตัวข้อมูลฝึกเองก็ไม่เก่งเรื่องการเขียนเทสต์

  • ผมประสบความสำเร็จมากกับวิธี เอาเอเจนต์ไปต่อเข้ากับแอปที่มีอยู่แล้ว
    เอเจนต์ ไม่เก่งเรื่องออกแบบสถาปัตยกรรม แต่กับโค้ดที่มีโครงสร้างอยู่แล้วมันทำงานได้ดีมาก
    ยิ่ง type system เข้มงวดและมี test coverage กว้าง ผลลัพธ์ก็ยิ่งดี

    • ตอนนี้กำลังทดลองให้ LLM จัดการและพัฒนา โปรเจ็กต์ Rust โดยตรง
      โดยเดินตาม ROADMAP.md, TASKS.md, STATUS.md ที่ Claude เขียนไว้
      และน่าทึ่งตรงที่ตอนนี้ เสร็จไปประมาณ 20% แล้ว
    • C# เข้ากับเอเจนต์ได้ดี เพราะมี คอมไพเลอร์ที่เข้มงวดและสภาพแวดล้อมแบบอิงกฎชัดเจน
      ในทางกลับกัน Python หรือ JS เชื่อถือได้ยาก เพราะ type system อ่อนกว่า
    • ยิ่ง codebase เดิม เป็นระเบียบดีเท่าไร ประสิทธิภาพของเอเจนต์ก็ยิ่งสูง
      การเริ่มจากศูนย์นั้นยาก แต่ถ้าให้ สเปกที่ชัดเจน ก็จะมีประสิทธิภาพมาก
    • Go นั้น LLM จัดการได้ง่าย เพราะ ภาษาง่ายและมีแพตเทิร์นสม่ำเสมอ
    • Typescript เหมาะกับเอเจนต์มาก เพราะ คอมไพล์เร็วและมี type system ที่แข็งแรง
      ขณะที่ optional typing ของ Python กลับทำให้เกิด การแพร่กระจายของข้อผิดพลาด

  • ผมเขียน ตัวมอนิเตอร์อัตราการเต้นหัวใจผ่านบลูทูธแบบเรียลไทม์ สำหรับ Linux ด้วย Claude Code แบบ 100%
    ลิงก์โปรเจ็กต์
    เขียนด้วย C ล้วน และทำทั้งเว็บอินเทอร์เฟซกับกราฟเรียลไทม์เสร็จในวันเดียว
    ครั้งนี้ผมทำ การสื่อสาร dBus–blueZ ที่เคยล้มเหลวมาก่อนให้สำเร็จได้

    • แต่เมื่อผู้ใช้อีกคนตรวจโค้ดดู พบว่า implementation ของ SSE ใช้งานจริงไม่ได้
      ในเอกสารเขียนว่าเป็น SSE แต่ภายในจริง ๆ ส่งแค่ HTTP response ปกติ
    • อีกคนชี้ว่า “โค้ดที่ AI เขียนตอนแรกดูดี แต่ คุณภาพจะค่อย ๆ ตกลง”
    • ก็มีคนบอกว่าขอบคุณที่แชร์ตัวอย่างจริงแบบนี้ และมองว่าเป็นเคสที่ ไม่โอ้อวดเกินจริง
    • ยังมีคอมเมนต์ถามเรื่องดีไซน์ เพราะบอกว่าสไตล์ UI น่าสนใจ

  • ผมใช้ Augment + Claude Opus 4.5 ทุกวัน
    แทบไม่ได้เขียนโค้ดเองเลย และทำโปรเจ็กต์ให้เสร็จด้วย การวนรอบทำงานตามสเปก
    วิธีรันเอเจนต์หลายตัวแบบขนานแล้วคอยรีวิวมีประสิทธิภาพมากเป็นพิเศษ
    หัวใจสำคัญคือการเขียนสเปกให้ชัด และให้ฟีดแบ็กเป็นขั้น ๆ

    • ถึงจะไม่ถนัด Ruby แต่ก็ได้รับความช่วยเหลือมากในการพัฒนาแอป Rails
      รู้สึกว่านี่คือ การเปลี่ยนแปลงที่ปฏิวัติมากที่สุด ในประสบการณ์ 30 ปีของผม และมั่นใจว่าอุตสาหกรรมทั้งวงการจะเปลี่ยนไป
    • มีคนแซวว่า “โปรเจ็กต์หนึ่งสัปดาห์จะเรียกว่าขนาดกลางได้ยังไง มันเล็กจะตาย”
    • อีกคนมองว่า “นี่ไม่ค่อยใช่ การพัฒนาแบบ agent จริง ๆ แต่ใกล้กับการพัฒนาแบบร่วมงานกับ LLM มากกว่า”
    • ยังมีความเห็นด้วยว่า “spec-driven development คือหัวใจของคุณภาพระดับ production”
    • ผมเพิ่มขั้นตอนให้ Claude เป็นฝ่ายถามคำถามก่อน เพื่อ จัดระเบียบ requirement ให้ชัดเจน
      ตอนนี้กำลังทำโปรเจ็กต์พจนานุกรมภาษาญี่ปุ่น–อังกฤษด้วย Claude
      ลิงก์ GitHub, เว็บไซต์

  • ในฐานะนักพัฒนาที่มีประสบการณ์ 20 ปี LLM ทำให้ การคาดการณ์ความเร็วในการทำงานพังหมด
    งานที่เมื่อก่อนต้องใช้ 2 สัปดาห์ ตอนนี้ใช้แค่ 2 วัน
    แม้ยังต้องมี code review และการโต้ตอบ แต่ก็รู้สึกว่า มันเก่งกว่านักพัฒนามนุษย์ส่วนใหญ่
    การคุยกับ LLM ให้ความรู้สึกเหมือน ร่วมงานกับนักพัฒนาระดับ senior
    และประสบการณ์ที่ผมสั่งสมมานานในการ รีวิวโค้ดและกระจายงาน ช่วยได้มาก

    • มีคนสงสัยว่า “เร็วขึ้นขนาดนั้นไม่น่าเชื่อ” และอยากรู้ว่าเป็น ปัญหาประเภทไหน
    • อีกคนพูดสั้น ๆ ว่า “คาดว่าจะมีหลักฐาน แต่ก็ไม่มี”

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

    • ผมเองก็ใช้ Claude คล้ายกับ rubber duck debugging
      ให้มันทำทีละฟังก์ชัน แล้วอาศัยผลลัพธ์นั้นไปต่อยอดหาไอเดียที่ดีกว่า
    • LLM แข็งแกร่งเป็นพิเศษในงานเอกสารหรือการวิเคราะห์
      แต่พอเป็น ปัญหาที่เน้นการออกแบบ ข้อจำกัดจะชัดมาก
    • พอมีคนถามว่า “เก็บ guideline ไว้ที่ไหน” ก็มีคำแนะนำว่าใส่ ข้อมูล build·test ลงใน CLAUDE.md จะดี

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

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

  • ผมเองก็ใช้ Claude ทุกวัน แต่ โค้ดทดสอบที่ AI สร้าง มักเละเทะอยู่บ่อย ๆ
    ในทางปฏิบัติมันมักผลิต เทสต์ไร้ความหมาย แบบ expect(true).to.be(true) ออกมาเป็นจำนวนมาก

    • โมเดลก่อนหน้านี้ทำไม่สำเร็จ แต่ผมเคยเห็นบทความว่ารุ่นล่าสุดสร้าง โค้ดที่ผ่านได้ด้วยการโกง
    • เพราะงั้นผมเลยเขียนและรีวิวเทสต์ก่อนด้วยวิธี TDD
      ถ้าให้มันทำทั้ง implementation และ test พร้อมกัน จะเกิด ข้อผิดพลาดแบบตรวจข้อสอบตัวเอง
    • มีคนบอกว่า “ผมเลิกให้ Claude เขียนเทสต์ไปแล้ว”
    • อีกคนหัวเราะแล้วบอกว่า “นี่มันเป็นวิธีแก้ที่มนุษย์มาก ๆ”