ใช้ AI เพื่อเขียนโค้ดที่ดีกว่าให้ช้าลง

 (nolanlawson.com)
43 คะแนน โดย GN⁺ 2026-05-26 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • การเขียนโค้ดด้วย AI ไม่ได้ใช้ได้แค่กับการสร้างโค้ดคุณภาพต่ำจำนวนมากอย่างรวดเร็วเท่านั้น แต่ยังใช้ตรวจทาน PR อย่างลึกซึ้งเพื่อค่อย ๆ สร้างโค้ดคุณภาพสูงได้ด้วย
  • เอเจนต์ LLM เก่งเรื่อง การตรวจจับบั๊ก ในโค้ดเบส แต่ความยากจริงอยู่ที่การจัดลำดับความสำคัญและการตรวจสอบสิ่งที่พบ
  • Claude skill ที่ใช้หลายโมเดลร่วมกัน จะใช้ Claude sub-agent, Codex และ Cursor Bugbot เพื่อตรวจ PR แล้วจัดทำรายงานสุดท้ายที่ลดการแจ้งผิดพลาดลง
  • ลำดับการทำงานคือแก้ปัญหาระดับ critical/high แบบวนซ้ำ ข้ามรายการที่ได้ไม่คุ้มกับต้นทุน และถ้ามีปัญหาร้ายแรงมากเกินไปก็จะยกเลิก PR นั้น
  • วิธีนี้ให้ความสำคัญกับ สุขภาพของโค้ดเบส มากกว่าความเร็ว และช่วยเสริมการเขียนโปรแกรมอย่างรอบคอบที่เข้าใจทั้งโหมดความล้มเหลวและบั๊กเดิมที่มีอยู่

วิธีใช้ AI เขียนโค้ดแบบช้าลง

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

การตรวจสอบและการจัดลำดับสำคัญสำคัญกว่าการหาบั๊ก

  • Mythos แสดงให้เห็นว่าเอเจนต์ LLM สามารถ หาบั๊กในโค้ดเบสได้เก่งมาก
  • ใน กรณีอื่น ก็พบว่าโมเดลที่ไม่ใช่ Mythos สามารถหาบั๊กจำนวนมากได้ในโค้ดเบสที่ยังไม่ได้ตรวจทาน
  • โมเดลสาธารณะรุ่นใหม่ของ Anthropic และ OpenAI แม้จะมีความต่างกันในด้านการตรวจจับบั๊กละเอียดอ่อนและการหลีกเลี่ยงการแจ้งผิดพลาด แต่ก็สามารถหาบั๊กได้มากพอ
  • ความยากที่แท้จริงไม่ได้อยู่ที่การพบบั๊ก แต่อยู่ที่ การจัดลำดับความสำคัญ และ การตรวจสอบ

Claude skill สำหรับตรวจ PR ด้วยหลายโมเดล

  • แนวทาง AI code review ที่ให้หลายโมเดลมาเปรียบเทียบและถกเถียงกัน มุ่งเน้นว่าการเพิ่มโมเดลที่แตกต่างกันเข้าไปมากขึ้นจะช่วยลดโอกาสเกิดอาการหลอนหรือการรายงานบั๊กผิดพลาดได้
  • Claude skill ที่ใช้อยู่จะรัน Claude sub-agent, Codex และ Cursor Bugbot เพื่อตรวจทาน PR
  • เครื่องมือแต่ละตัวจะจัดระดับบั๊กใน PR เป็น critical/high/medium/low แล้วนำผลมาสรุปรวมเป็นรายงานสุดท้ายที่ตัดการแจ้งผิดพลาดออก
  • ขอบเขตของคำว่า “บั๊ก” สามารถขยายให้กว้างตามเกณฑ์ของโปรเจกต์ได้
    • การละเมิดหลักการ KISS และ DRY
    • การเขียน HTML/JSX ที่เข้าถึงได้
    • การใช้ดัชนีที่เหมาะสมกับ SQL query หรือไม่
    • เกณฑ์คุณภาพอื่น ๆ เฉพาะของโปรเจกต์

เวิร์กโฟลว์จริงและเกณฑ์การตัดสินใจ

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

  • ลำดับการจัดการทั่วไป

    • ให้เอเจนต์แก้ปัญหาระดับ critical และ high แต่ให้มนุษย์เป็นผู้ชี้แนะแนวทางแก้ที่เหมาะสม
    • ทำซ้ำจนกว่าจะไม่เหลือ critical/high
    • ข้ามปัญหาระดับ high/medium ที่ประโยชน์ไม่คุ้มต้นทุนการแก้
    • กรณีตัวอย่างคือการต้องเขียนโค้ด 100 บรรทัดเพื่อแก้ edge case ที่แคบมาก
    • ถ้ามีปัญหาระดับ critical มากเกินไปจนมองว่าแนวทางโดยรวมผิด ก็จะยกเลิก PR นั้น

โฟกัสที่สุขภาพของโค้ดเบสมากกว่าประสิทธิภาพการผลิต

  • เทคนิคนี้ไม่ได้ทำให้ความเร็วในการพัฒนาเพิ่มขึ้นเสมอไป
  • ในกระบวนการรีวิวอาจพบบั๊กเดิมที่มีอยู่ ก่อนหน้าการทำ PR ซึ่งนำไปสู่การเขียน unit test และการแก้ข้อบกพร่องที่ละเอียดอ่อน
  • มันแทบจะอยู่คนละฝั่งกับการพัฒนาแนว “เพิ่มผลิตภาพ 10 เท่า” ที่มักนึกถึงเมื่อพูดถึง “vibe coding”
  • ในสถาปัตยกรรมที่ซับซ้อน โหมดความล้มเหลว อาจน่าสนใจกว่าเส้นทางทำงานปกติ และการทำความเข้าใจพร้อมแก้จุดที่ล้มเหลวนั้นอาจเป็นวิธีเรียนรู้โค้ดเบสได้
  • มีประโยชน์ทั้งต่อการปรับปรุงสุขภาพของโค้ดเบสโดยรวม และการเรียนรู้มุมที่ไม่ค่อยมีใครรู้จักของระบบ

วิธีปฏิบัติสำหรับ vibe coding แบบช้าลง

  • ถ้าเป็นนักพัฒนาที่ใช้เอเจนต์สร้าง PR ยาวหลายร้อยบรรทัดทั้งที่ตัวเองยังไม่เข้าใจทั้งหมด ลองเปลี่ยนมาใช้แนวทางที่ช้าลงได้
  • สามารถถามเอเจนต์ได้ว่า PR นี้ทำงานอย่างไร และมันอาจล้มเหลวตรงไหนบ้าง
  • หากจำเป็น อาจให้มันเขียนเอกสาร Markdown ที่มี Mermaid charts รวมอยู่ด้วย
  • สามารถใช้ skill /grill-me ของ Matt Pocock ได้จนกว่าจะเข้าใจ PR ตั้งแต่ต้นจนจบ
  • “ผลิตภาพ” ที่วัดจากจำนวนบรรทัดโค้ดอาจไม่ได้เพิ่มขึ้น และอาจใช้โทเค็นไปมากก่อนจะสรุปว่าแผนแรกเริ่มนั้นผิด
  • วิธีนี้ใกล้เคียงกับการยกระดับ การเขียนโปรแกรมอย่างรอบคอบ เป็นระบบ และหมกมุ่นกับคุณภาพ ที่ตั้งเป้าไว้ตั้งแต่ก่อนยุค LLM ให้ทรงพลังยิ่งขึ้น

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

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

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

  • พอทำงานกับ AI มันก็ไม่ใช่กระบวนการครั้งเดียวแบบง่าย ๆ อีกต่อไป แต่กลายเป็น ลูปรีวิวไป-กลับที่ยาวนาน
    ฟีเจอร์ขนาดกลางที่คร่อมหลายส่วนจะเริ่มจากให้ AI วางแบบการพัฒนาและทบทวนรายละเอียดก่อน แล้วค่อยให้ Claude 4.7 Max ซึ่งช้าแต่ให้ผลลัพธ์ดีเป็นคนลงมือทำ
    หลังจากนั้นก็รีวิวสิ่งที่ทำออกมา แล้วให้ Codex GPT 5.5 xhigh fast รีวิวซ้ำอีกที ซึ่งแทบจะหาจุดขอบเขตได้เสมอ ส่วนการแก้ไขให้ Claude ทำ เพราะ Codex เก่งเรื่องหาบั๊กและรีวิว แต่โค้ดมักจะ overengineer หรือปนทางลัด ขณะที่ Claude เขียนโค้ดได้ตรงไปตรงมาและดูแลง่ายกว่า
    จากนั้นก็ให้ Claude/Codex อินสแตนซ์ใหม่ตรวจ staged changes ซ้ำอีกครั้ง นำฟีดแบ็กมาปรับใช้ แล้วค่อยเขียนเทสต์เพิ่ม แม้จะยังเร็วกว่าเขียนเองด้วยมือ แต่เวลาส่วนใหญ่กลับหมดไปกับการรีวิวและจัดการ edge case และสุดท้ายฟีเจอร์ v1 ก็ให้ความรู้สึกเหมือน งานระดับ v3 ที่ผ่านการวนซ้ำมาหลายรอบแล้ว

    • ช่วงที่คุยกับ AI เรื่องปัญหาจนแทบเบื่อก่อนเริ่มลงมือ implement นี่เข้าทางผมมาก
      มันให้ความรู้สึกว่าทำงานได้มีประสิทธิภาพ ผลลัพธ์จาก AI ก็ดี และโดยมากผมก็ยังเข้าใจโค้ดที่ออกมาอยู่ การได้เถียงกับหุ่นยนต์ทั้งวันเรื่องการออกแบบและสถาปัตยกรรม ทำให้รู้สึกว่านี่แหละคือจุดที่การปฏิวัติ AI ทำให้ผมเป็นวิศวกรที่ดีขึ้น
    • เห็นด้วยแบบนั้นเป๊ะ คนจำนวนมากเกินไปให้ AI จัดการงานซับซ้อนแบบ จบในครั้งเดียว แล้วก็ยังแปลกใจที่มันทำตัวเหมือนจูเนียร์ที่โดนสั่งงานแบบรีบ ๆ
      วิธีของผมคือวนรอบ research/planning/test planning 5 รอบ และผมจะเข้าไปอยู่ในลูปทุกครั้งที่มีการตัดสินใจสำคัญ เริ่มจากภาพใหญ่แล้วค่อยไล่ลงรายละเอียด โดยแค่ช่วงวางแผนก็อาจกินเวลา 2–3 วันของผม ส่วนเอเจนต์ที่ลงมือ implement (Opus 4.7) ก็ใช้เวลาหลายชั่วโมง
      การพัฒนาจะแบ่งเป็นหลายสเตจ/หลายคอมมิต และทุกสเตจจะมีลูปแก้ไขจาก code review ปิดท้ายด้วย deep code review ที่อาจกินเวลาอีก 1–2 ชั่วโมง และพอเปิด PR แล้ว Gemini ก็จะมารีวิว จากนั้นผมก็อ่านแล้วแก้ตามนั้น
      โปรเจกต์ยังคงใช้เวลาหลายวันหรือหลายสัปดาห์เหมือนเดิม แต่ก็ยัง เร็วกว่า ทำคนเดียวทั้งหมด 5 เท่า
      เพิ่มเติม: skill นั้นอยู่ที่ https://github.com/scosman/vibe-crafting
    • เวลาผมเขียนโค้ดด้วย AI โฟลว์ก็คล้ายกันมาก แต่ถึงทำได้ดีก็มักใช้เวลาใกล้เคียงกับการเขียนเองอยู่ดี
      บางกรณีก็ทิ้งสิ่งที่ AI ทำไปเลยแล้วลงมือเอง ผมมองว่านี่เป็นทักษะที่คนต้องเรียนรู้ คือถึงจุดหนึ่งต้อง รู้ว่าเมื่อไรควรตัดขาด โดยเฉพาะเวลาเห็นเพื่อนร่วมงานยังเถียงกับ LLM ไม่เลิกเพื่อพยายามให้มันทำอะไรบางอย่าง ทั้งที่เป็นแค่การแก้ไขง่าย ๆ
    • ผมใช้แนวทางคล้ายกัน แต่จะตั้ง สถาปัตยกรรม/สัญญาระดับบน/สตับแบบทำมือ ขั้นพื้นฐานไว้ก่อน เพื่อให้มันสอดคล้องกับระบบอื่นอย่างคงเส้นคงวาและอ่านง่าย
    • แล้วถ้า Anthropic ล่มขึ้นมา ก็แค่นั่งดื่มกาแฟรอเหรอ?
      การคอยดูแล AI ตลอดเวลาเพื่อแลกกับความเร็วที่เพิ่มขึ้นนิดหน่อย มันไม่ได้ทำให้ ความรู้และการควบคุม ว่า AI ทำอะไรลงไปลดลงหรอกหรือ

  • บทความที่ให้ LLM มาวิจารณ์ code review ของกันและกัน[1], เครื่องมือ magpie[2], และบทความล่าสุดของ Cloudflare เรื่องสแตก code review[3] ค่อนข้างโน้มน้าวได้มาก
    ผมยังสงสัยใน AI อยู่ แต่เหตุผลไม่ใช่เรื่อง “มันใช้ได้ไหม” เท่ากับ “มันดีต่อโลกไหม” งานรีวิวแบบนี้ดูเป็นหนึ่งในไม่กี่กรณีที่ไม่ค่อยให้ความรู้สึกเหมือนเอาการคิดไปจ้างคนนอกหรือทำให้ทักษะแรงงานถดถอย มันไม่ได้ส่งสัญญาณเตือนแบบเดียวกับการให้ AI เขียนโค้ด หรือให้ AI ไปแก้ปัญหาที่ AI เองเป็นคนเจอ แน่นอนว่าปัญหาสิ่งแวดล้อมและข้อกังวลทางจริยธรรมอื่น ๆ ก็ยังคงมีอยู่อย่างมาก
    ช่วงหลังมานี้ผมประทับใจกับ คุณภาพของ AI code review แต่ประสบการณ์การต้องโต้ตอบกับ AI reviewer 3 ตัวแยกกันบน GitHub PR นั้นแย่มาก อยากได้รอบรีวิวที่เน้นทำงานแบบ local มากกว่าและเข้าใจ jj/rebase
    บริบท: แบ็กเอนด์ PHP/Laravel ขนาดค่อนข้างใหญ่ และฟรอนต์เอนด์ Vue
    [1]: https://milvus.io/blog/ai-code-review-gets-better-when-model...
    [2]: https://github.com/liliu-z/magpie
    [3]: https://blog.cloudflare.com/ai-code-review/

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

    • ถ้า AI เขียนโค้ดแย่ ก็ต้อง เปลี่ยน AI สิ ตอนนี้ AI ระดับสูงไม่ควรสร้างโค้ดแย่แล้ว

  • บทความนี้ไม่ได้พูดถึงการใช้ AI เขียนโค้ด แต่พูดถึงแค่ code review
    ปัญหาที่ผมเจอใน agentic coding คือระหว่างเขียนโปรแกรม เราต้องตัดสินใจเชิงสถาปัตยกรรมจุกจิกเล็ก ๆ น้อย ๆ เป็นจำนวนมาก แทบไม่มีกรณีไหนที่มีสเปกสมบูรณ์ตั้งแต่ต้น และเรามักสร้างสเปกไปพร้อมกับการเขียน
    พอใช้ Claude Code หรือ Codex กระบวนการนั้นก็หายไป Claude Code มีแรงผลักดันอยากไปให้ถึงเป้าหมายมากเกินไป จนประสบการณ์การเขียนโค้ดร่วมกับมันเหมือนฝันเพ้อจากไข้ สุดท้ายเลยไม่ค่อยมั่นใจทั้งเรื่อง edge case และเรื่องว่ามันสอดคล้องกับเป้าหมายด้านสถาปัตยกรรม/การออกแบบของโปรเจกต์แค่ไหน
    ยิ่งไปกว่านั้น ผมเองก็สนุกกับการเขียนโปรแกรม การทำ reverse engineering และอื่น ๆ แม้ LLM จะช่วยแก้ปัญหาหรือส่งมอบฟีเจอร์ได้ แต่มันก็ให้ความรู้สึกเหมือนแย่งความสนุกนั้นไป ผมพยายามหาโฟลว์ที่ตัวเองจะใช้อย่างมั่นใจได้อยู่ แต่ก็กลัวว่าสุดท้ายโฟลว์นั้นจะกลายเป็นแค่การแชต การค้นหา และบทบาท rubber duck ให้กับความคิดของผมเท่านั้น

  • ในทางกลับกัน บางบริษัทกำลังผลักดันแนวคิดที่ว่าควรทำให้ ไปป์ไลน์เอเจนต์ประเมินตนเอง ที่ใส่ฟีดแบ็กจากมนุษย์เข้าไปในลูปมีความแข็งแกร่ง จนเอเจนต์สามารถเขียนโค้ดโปรดักชันได้เกือบทั้งหมด
    CEO ของ Creao บอกว่าเมื่อเดือนมกราคมปีนี้ บริษัทรีอาร์คิเทคระบบโปรดักชันทั้งหมดใหม่ภายใน 2 สัปดาห์ และยังอ้างว่าเอเจนต์พัฒนาฟีเจอร์ได้มากเกินไปและเร็วเกินไป จนต้องรอให้ฝั่งพัฒนาธุรกิจตามให้ทัน
    เลยสงสัยว่าจะประเมินอย่างไรระหว่างทางเลือกที่ใช้ AI เพื่อเพิ่มผลลัพธ์ 100 เท่า กับทางเลือกที่ใช้ AI เพื่อพัฒนาทักษะของตัวเอง
    ขณะเดียวกัน การเพิ่มผลิตภาพด้วย AI ก็เป็นเรื่องจริง ตัวอย่างเช่น องค์กรวิศวกรรมแห่งหนึ่งของ Snowflake บรรลุ OKR ทั้งหมดของไตรมาสแรกได้ก่อนกำหนดเป็นครั้งแรกในประวัติศาสตร์บริษัท ปกติแค่ทำ OKR ตามแผนได้ 70% ก็ถือว่าทำผลงานได้แล้ว เลยนึกภาพออกเลยว่าวิศวกรที่เห็นผลแบบนี้จะรู้สึกกดดันแค่ไหน

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

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

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

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

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

    • boilerplate กลายเป็นสิ่งที่เลือกมีหรือไม่มีได้ หรือถูกสร้างให้อัตโนมัติได้ ถ้ามีไลบรารีหรือเฟรมเวิร์กที่ดี
      การได้ ผลลัพธ์ที่กำหนดแน่นอน จาก django-admin startproject, npm init, meteor create ดีกว่าการโยนพรอมป์ตให้ LLM แล้วไม่รู้ว่าจะได้อะไรกลับมาเยอะ
      ในระบบนิเวศเว็บที่เติบโตเต็มที่ boilerplate ถูกลดให้เหลือน้อยที่สุด ตอนนี้พอโยนงานนี้ให้ LLM แล้ว ก็เลยกังวลว่าความพยายามของนักพัฒนาที่จะสร้าง CLI แบบ startproject และค่าเริ่มต้นดี ๆ จะลดลงหรือไม่

  • ชอบมาก ฉันเองก็ใช้แนวทาง ralph-loop คล้ายกัน
    เริ่มจากแผนที่อนุมัติแล้ว ส่งต่อให้ตัวประสานงาน แล้วถ้าทำให้ง่ายขึ้นก็คือจัดการผ่าน 2 เซสชันคือ build กับ review โดยแต่ละเซสชันใช้คนละโมเดล

  • สิ่งที่เป็นอุปสรรคสำหรับฉันในการใช้โค้ดดิงเอเจนต์ คือมันต้องพึ่งพา บริการภายนอกแบบเสียเงิน
    มีโมเดลโลคัลที่ดีพอสำหรับใช้เขียนโค้ดไหม?

    • ณ เดือนนี้ คนพูดถึง Qwen3.6 (27B หรือ 35B-A3B) กับ Gemma 4 กันบ่อย
      อันนี้อาจช่วยได้ด้วย: https://hnup.date/hn-sota
      โมเดล Qwen เป็นโมเดลที่ฉันใช้ประจำวันในสัปดาห์นี้
 
GN⁺ 2026-05-26
ความเห็นจาก Lobste.rs

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

  • ฉันค่อนข้างประสบความสำเร็จเวลาใช้ LLM เป็น คู่หูทำสไปก์ที่รู้ API หรือเป็น เครื่องมือรีแฟกเตอร์เชิงกล โดยเฉพาะในภาษาที่มี type แข็งแรง มันดีสำหรับการเขียนเทสต์ด้วย แต่ต้องมีกระบวนการหลายชั้นเพื่อยืนยันว่าเทสต์เหล่านั้นมีพลังบังคับจริง
    mutation testing ช่วยได้มากพอสมควร และอย่างที่บทความต้นทางเสนอไว้ การทบทวนหลายรอบก็จำเป็นเช่นกัน
    เมื่อก่อนฉันมอง LLM ในแง่ลบกว่านี้มาก และพอมาย้อนดูแล้วก็ลบแบบไม่สมเหตุสมผลด้วยซ้ำ แต่ส่วนใหญ่เป็นเพราะซอฟต์แวร์คุณภาพต่ำที่ LLM ปล่อยออกมาไม่หยุด
    พอลองลงไปใช้จริงก็พบว่าควรปฏิบัติกับมันเหมือนเครื่องมือทำต้นแบบแบบกระดาษแข็งและนักพิมพ์ที่เร็วขึ้นมาก เช่น ถ้าบอกว่า “หาแพตเทิร์นนี้ในทุก theorem ของโปรเจกต์ Lean นี้ แล้วเปลี่ยนเป็นอีกแพตเทิร์นหนึ่ง ถ้าตรงไหนทำไม่ได้ให้มาร์กไว้และส่งรายการที่เหลือมา” มันจะช่วยแก้ theorem กว่า 100 รายการเป็นชุด ๆ ได้ ภายในเวลาที่ฉันยังใช้ vim, sed, awk กับวิธีแก้ขัดลองครั้งแรกหรือครั้งที่สองไม่เสร็จเลย
    Lean เหมาะมากเป็นพิเศษ เพราะด้วยคุณสมบัติของภาษาและลักษณะงานที่ฉันทำ ช่องว่างระหว่าง “คอมไพล์ผ่าน” กับ “ใช้งานได้จริง” แคบมาก และใน Rust ก็ให้ความรู้สึกคล้ายกันถ้ามี test suite ที่ดีพร้อม mutation testing
    ฉันคิดว่าศักยภาพระยะยาวของเครื่องมือพวกนี้ไม่ใช่ “กดปุ่มแล้วได้ผลิตภัณฑ์ออกมา” แต่เป็นการที่วิศวกรที่ดีรับมันเข้ามาใช้ แล้วเอาพลังงานไปทุ่มกับเรื่องสำคัญ พร้อมมอบงานจุกจิกจำนวนมากที่เคยต้องทำเองให้เครื่องจัดการ

    • ตอนแรกฉันก็มอง LLM ในแง่ลบมากเหมือนกัน แต่ตอนนี้คิดว่ามันพัฒนาจนถึงระดับที่ช่วยได้มากกว่ารบกวนแล้ว
      ตัวอย่างนี้น่าสนใจ เพราะเมื่อก่อนตอนทำงานในทีม JavaScript framework ฉันเคยเขียน codemod เองเพื่อจัดการงานอย่างการอัปเกรดหรือ migration มันเป็นงานทรหดในการแก้ AST
      ถ้าเป็นทุกวันนี้ ฉันคิดว่าน่าจะโยนให้ LLM ทำได้ถึงราว ๆ 90%

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

    • ก็จริง แต่ฉันกลับรู้สึกว่า workflow แบบนี้ช่วยเพิ่ม ทักษะการรีวิวโค้ด ของฉันด้วยซ้ำ เพราะต้องคอยตัดสินว่า “บั๊ก” นั้นเกิดขึ้นได้จริงหรือเป็นแค่เชิงทฤษฎี และคุ้มค่าที่จะแก้ไหม หรือควรย้ายไป PR ถัดไป
      ถ้าเป็นบั๊กซับซ้อน ฉันมักจะคิดต่อเองจนสุด เพราะ 1) ยังมี hallucination ปนมาอยู่ และ 2) ยังไงการเข้าใจระบบแบบ end-to-end ก็มีคุณค่าในตัวมันเอง

  • พูดแบบเมตาหน่อย ฉันไม่เข้าใจธงที่ติดอยู่กับโพสต์นี้เลย บอกว่าหลุดประเด็น 1 อัน สแปม 3 อัน ฟังดูแปลกมาก
    โพสต์บนสุดของหน้าแรกก็เป็นเรื่องการใช้ LLM เหมือนกัน และเป็นโพสต์เกี่ยวกับการเขียนทั่วไป ซึ่งดูเกี่ยวกับหัวข้อน้อยกว่าโพสต์นี้ที่โฟกัสเรื่องการเขียนโค้ดเสียอีก แต่เหมือนไม่มีธงอะไรเลย

    • น่าจะถูกมองว่าเป็น การโปรโมตตัวเอง เลยโดนปักธงสแปม

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

    • ฉันไม่เห็นกระแสต่อต้าน AI แบบเหมารวมตรงนี้นะ ช่วยลิงก์ตัวอย่างได้ไหม?
      ที่ฉันเห็นคือการวิจารณ์การเปลี่ยนแปลงแบบเอา LLM ไปแก้โค้ดทีเดียวหลายล้านบรรทัดแล้ว deploy โดยไม่มีการรีวิวจากมนุษย์ อย่างกรณีเธรดเรื่องการพอร์ต Bun จาก Zig ไป Rust
      และบทความนี้ก็วิจารณ์แบบนั้นเหมือนกัน