เวิร์กโฟลว์การสร้างโค้ดด้วย LLM ของฉัน

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

  "ตอนนี้มันทำงานได้ดี แต่ในอีก 2 สัปดาห์มันอาจใช้ไม่ได้แล้ว หรืออาจทำงานได้ดีขึ้นเป็นสองเท่า"

• การพัฒนามีอยู่ 2 แบบ
  • Greenfield code: เริ่มโปรเจ็กต์ใหม่
  • Legacy modern code: ปรับปรุงหรือขยาย codebase ที่มีอยู่แล้ว

Greenfield: เริ่มใหม่จากศูนย์

• เป็นกระบวนการที่เหมาะกับสถานการณ์แบบ “เริ่มตั้งแต่ต้น”
• ลำดับงานคือระดมความคิด ทำเอกสาร วางแผนเป็นขั้นเล็ก ๆ แล้วใช้เครื่องมือสร้างโค้ดมาลงมือทำจริง
• Step 1: ทำให้ไอเดียชัดเจน
  • อธิบายไอเดียให้ LLM อย่าง ChatGPT ฟัง พร้อมชวนให้มันถามกลับทีละข้อ เพื่อกลั่นเป็นสเปกที่ชัดเจน
  • ตอนท้ายจะจัดเป็นเอกสารรายละเอียด spec.md ที่ส่งต่อให้นักพัฒนาได้
  • ถ้าจำเป็น ก็ใช้เครื่องมืออย่าง Deep Research เพื่อหาข้อมูลสนับสนุนไอเดียนั้นได้ด้วย
• Step 2: วางแผน
  • จากสเปก ให้โมเดลที่เก่งด้าน “ความเข้าใจและการให้เหตุผล” สร้าง blueprint แบบละเอียดเป็นขั้น ๆ
  • จะใช้แนว TDD หรือไม่ก็ได้ แต่ให้แตกงานเป็นหน่วยเล็ก ๆ ในแต่ละขั้นและเรียงลำดับไว้
  • กระบวนการนี้จะได้ไฟล์ prompt_plan.md และ todo.md
    • prompt_plan.md ใช้สำหรับออกแบบพรอมป์ต์ที่ต้องใช้ในการสร้างโค้ด ส่วน todo.md มีเช็กลิสต์งาน
  • การวางแผนแบบนี้มักใช้เวลาแค่ราว 15 นาที และยังกลับมาอ้างอิงทีหลังได้ง่าย
• Step 3: ลงมือทำ
  • ใช้เครื่องมือช่วยเขียนหรือสร้างโค้ดจริงอย่าง Aider, Cursor, Claude ฯลฯ
  • ตัวอย่างหลัก ๆ คือ Claude และ Aider
  • วิธีแบบ Claude
    • ตั้งค่าโครงสร้างโปรเจ็กต์ล่วงหน้าไว้ก่อน (เช่น boilerplate) แล้วค่อยป้อนพรอมป์ต์ทีละขั้นให้ Claude
    • นำโค้ดที่ได้มา copy & paste ลง IDE แล้วรันทดสอบ
    • ถ้ามีปัญหา ก็ใช้เครื่องมืออย่าง repomix ส่ง codebase ปัจจุบันให้ Claude เพื่อดีบัก
    • เวิร์กโฟลว์
      • ตั้งค่า repo (boilerplate, uv init, cargo init, etc)
      • วางพรอมป์ต์ลงใน Claude
      • copy & paste จาก claude.ai ไปยัง IDE
      • รันโค้ด รันทดสอบ ฯลฯ
      • …
      • ถ้าใช้ได้ ก็ไปพรอมป์ต์ถัดไป
      • ถ้าใช้ไม่ได้ ให้ใช้ Repomix ส่ง codebase ไปให้ Claude ดีบัก
      • ทำซ้ำแบบนี้ไปเรื่อย ๆ (rinse repeat)
  • วิธีแบบ Aider
    • ใน Aider ก็ป้อนไฟล์ prompt_plan.md ตามลำดับเพื่อทำงานเช่นกัน
    • มันช่วยรันทดสอบอัตโนมัติ หรือช่วยค้นหาและแก้ข้อผิดพลาดได้
    • หากจำเป็น ก็แก้ปัญหาผ่านการดีบักแบบโต้ตอบได้
      • ตั้งค่า repo (boilerplate, uv init, cargo init, etc)
      • รัน Aider
      • วางพรอมป์ต์ลงใน Aider
      • ดู Aider เต้น ♪┏(・o･)┛♪
      • Aider สามารถรันทดสอบ หรือรันแอปเพื่อตรวจสอบได้
      • ถ้าใช้ได้ ก็ไปพรอมป์ต์ถัดไป
      • ถ้าใช้ไม่ได้ ก็คุยถามตอบกับ Aider แล้วแก้ไป
      • ทำซ้ำแบบนี้ไปเรื่อย ๆ (rinse repeat)
• ผลลัพธ์
  • ด้วยวิธีนี้ สามารถลองทำโปรเจ็กต์หลายแบบ เช่น script, แอป Expo, Rust CLI ได้ในเวลาสั้น ๆ
  • ถ้ามีโปรเจ็กต์เล็กหรือใหญ่ที่ผัดวันไว้ แนะนำให้ลองดูสักครั้ง
  • ข้อดีคือได้ลองของเร็วไปพร้อมกับเรียนรู้ภาษาและเทคโนโลยีใหม่ ๆ

Non-greenfield : งานแบบค่อย ๆ ปรับและทำซ้ำบนโค้ดเดิม

• เป็นวิธีที่ใช้เมื่อจะเพิ่มงานเล็ก ๆ เข้าไปใน codebase ที่มีอยู่แล้วแบบต่อเนื่อง
• แทนที่จะมีแผนใหญ่ทั้งก้อน จะเป็นการส่งคำขอเฉพาะเจาะจงและรับผลลัพธ์กลับมาเป็นงานแต่ละชิ้น
• เก็บ context ให้พร้อม
  • ใช้เครื่องมืออย่าง repomix เพื่อสรุป codebase แล้วส่งให้ LLM ได้
  • ใช้ mise เป็นต้น เพื่อจัดการการตั้งค่าที่ทำซ้ำบ่อย ๆ และเก็บผลสรุปไว้ในไฟล์ output.txt
  • ถ้า codebase ใหญ่มาก ก็ปรับให้สรุปเฉพาะส่วนที่ต้องใช้ได้
• ตัวอย่างเวิร์กโฟลว์
  • ใช้คำสั่งอย่าง mise run LLM:generate_missing_tests เพื่อให้ LLM หาให้ว่าส่วนไหนยังขาดการทดสอบ
  • นำข้อเสนอแนะนั้น (issue) ไปใช้กับ Claude หรือ Aider แล้วทดสอบผลลัพธ์อีกครั้ง
  • จากนั้นก็ปรับปรุง codebase เดิมแบบค่อยเป็นค่อยไป

ตัวอย่างพรอมป์ต์สำคัญ

• Code review
  “ช่วยรีวิวโค้ดอย่างละเอียดในฐานะนักพัฒนาอาวุโส ใส่เลขบรรทัดและบริบทให้ครบ อย่ารีวิวแบบผิวเผิน แต่ให้ลงลึกจริง ๆ”
  “You are a senior developer. Your job is to do a thorough code review of this code. You should write it up and output markdown. Include line numbers, and contextual info. Your code review will be passed to another teammate, so be thorough. Think deeply before writing the code review. Review every part, and don't hallucinate.“
• GitHub Issue generation
  “ช่วยตรวจโค้ดในฐานะนักพัฒนาอาวุโส แล้วเขียนประเด็นสำคัญออกมาในรูปแบบ Github issue”
  “You are a senior developer. Your job is to review this code, and write out the top issues that you see with the code. It could be bugs, design choices, or code cleanliness issues. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues will be given to a developer to executed on, so they should be in a format that is compatible with github issues“
• Missing tests
  “ช่วยตรวจโค้ดในฐานะนักพัฒนาอาวุโส แล้วระบุการทดสอบที่ขาดหายหรือการทดสอบที่ควรมีให้ชัดเจน”
  “You are a senior developer. Your job is to review this code, and write out a list of missing test cases, and code tests that should exist. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues will be given to a developer to executed on, so they should be in a format that is compatible with github issues“

สกี ᨒ↟ 𖠰ᨒ↟ 𖠰

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

ฉันเหงามาก (｡•́︿•̀｡)

• เวิร์กโฟลว์ที่ใช้ LLM เป็นหลักส่วนใหญ่ตอนนี้เหมาะกับโหมด “ทำคนเดียว”
• ถ้าจะเขียนโค้ดร่วมกันเป็นทีม ปัญหาเรื่อง conflict หรือ merge จะซับซ้อนขึ้น
• หวังว่าจะได้เห็นสภาพแวดล้อมการทำงานร่วมกันแบบ “multiplayer” ที่หลายคนใช้ LLM พร้อมกันได้พัฒนาไปมากกว่านี้

เวลา

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

Haterade ╭∩╮( •̀_•́ )╭∩╮

• เพื่อนหลายคนมีท่าทีประมาณ “LLM บ้าบอนี่ โคตรไร้ประโยชน์” และฉันก็ไม่ได้ใส่ใจกับมุมมองแบบนั้นมากนัก
• แน่นอนว่าฉันก็ไม่ได้เห็นด้วยกับจุดยืนนั้น แต่การตั้งข้อสงสัยก็ยังเป็นสิ่งจำเป็น
• มีเหตุผลมากมายที่จะไม่ชอบ AI และสิ่งที่ฉันกังวลที่สุดคือการใช้พลังงานกับผลกระทบต่อสิ่งแวดล้อม
• แต่ถึงอย่างนั้น… “โค้ดต้องไหลไป” ก็แบบนั้นแหละ… เฮ้อ
• ถ้าอยากรู้มากขึ้นแต่ไม่ได้อยากกลายเป็นโปรแกรมเมอร์ไซบอร์ก คำแนะนำของฉันคือ “ไม่ต้องเปลี่ยนความเห็นหรอก แต่อ่าน ‘Co-Intelligence: Living and Working with AI’ ของ Ethan Mollick ดู”
  • หนังสือเล่มนี้อธิบายข้อดีของ LLM ได้ดี โดยไม่โอ้อวดแบบเทคโน-อนาธิปไตยทุนนิยม
  • สำหรับฉัน มันช่วยได้มาก และฉันก็คุยได้ลึกขึ้นมากกับเพื่อนที่อ่านหนังสือเล่มนี้เหมือนกัน
  • แนะนำมาก

[devs5]

หนังสือ ‘Co-Intelligence: Living and Working with AI' ของ Ethan Mollick
ดูเหมือนมีกำหนดตีพิมพ์ในเดือนมีนาคมภายใต้ชื่อ 'Dual Brain'

[kipsong133]

มี Repomix ด้วยสินะ ก่อนหน้านี้ฉันคัดลอกแล้ววางเองทุกครั้งเลย.. ฮือ

[chugue85]

ขอบคุณครับ!

[ahwjdekf]

แม้แต่คำด่าที่นักพัฒนาคนอื่นพูด LLM จะช่วยรับแทนให้ด้วยไหม?

[aer0700]

ตอนนี้ผมยังใช้ LLM แค่ประมาณเป็น Google ที่พัฒนากว่าเดิมกับ Stack Overflow เวอร์ชันที่เป็นมิตรอยู่เลย คงต้องลองคิดดูว่ายังมีวิธีใช้ให้คุ้มกว่านี้ไหม
สำหรับผม การคิดว่าจะสร้างอย่างไรสำคัญก็จริง แต่การชวน AI คิดไปด้วยว่าทำไมมันถึงทำงานได้ก็น่าจะสำคัญเหมือนกัน เวลาไปค้นหาเอกสารเทคนิคเก่า ๆ หรือพวกมาตรฐานต่าง ๆ LLM มีประโยชน์มากครับ

[GN⁺]

ความคิดเห็นบน Hacker News

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

• ในการทำงานร่วมกับ LLM การสร้างบริบทผ่านการตั้งคำถามเป็นสิ่งสำคัญ วิธีนี้มีประสิทธิภาพกว่าการพยายามสร้างบริบทขึ้นมาโดยตรง

• ช่วงนี้กำลังลองทำ mob programming ร่วมกับ LLM โดยให้ LLM ตัวหนึ่งรับหน้าที่ลงมือพัฒนา และอีกตัวหนึ่งช่วยวิจารณ์และเสนอแนวทางปรับปรุง

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

• อยากฟังประสบการณ์จากคนที่เริ่มต้นด้วย Cursor chat แล้วพัฒนาไปเป็นเวิร์กโฟลว์ที่ดีกว่า ว่าการลงทุนเวลาไปกับการวางแผนคุ้มค่าหรือไม่ อาการหลอนลดลงไหม และโดยรวมแล้วช่วยประหยัดเวลาได้จริงหรือเปล่า

• บทความนี้อธิบายวิธีใช้ LLM อย่างถูกต้อง หลายคนยังขาดการฝึกฝนในการสื่อสารกับ language model อย่างมีประสิทธิภาพ ผู้เขียนเชี่ยวชาญการสื่อสารกับ LLM แล้ว และเวิร์กโฟลว์นี้ช่วยเพิ่มประสิทธิภาพได้สูงสุด

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

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

• โปรแกรมเมอร์มือใหม่จำนวนมากมักลืมส่วนของการกำหนดสเปกและแผนการดำเนินงาน หากต้องการใช้ LLM ให้สำเร็จ ก็ต้องทำให้มันช่วยสร้างสเปกและแผนการดำเนินงานด้วย

• ไม่เข้าใจความคาดหวังที่มีต่อ Claude จากคำถามเกี่ยวกับ Apache Spark พบอาการหลอนเกิดขึ้นมาก อยากเข้าใจว่าอะไรทำให้ Claude ดีกว่าโมเดลอื่น

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