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

 (nolanlawson.com)
8 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง 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 ให้ทรงพลังยิ่งขึ้น

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

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

 
GN⁺ 4 시간 전
ความเห็นจาก 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
      และบทความนี้ก็วิจารณ์แบบนั้นเหมือนกัน