วิธียกระดับความสามารถด้านการเขียนโปรแกรมด้วย AI

• อยากใช้เครื่องมือเขียนโค้ดด้วย AI เพื่อลดงานแปลงที่เดิมคนต้องใช้เวลา 1–2 ชั่วโมง ให้เหลือเพียงระดับการรีวิว 15–20 นาที
• แต่ตอนนี้คุณภาพโค้ดที่ AI สร้างยังไม่ถึง 90% ของโค้ดที่เขียนเอง จึงดูเหมือนยังไม่ช่วยได้จริงในทางปฏิบัติ
• จึงอยากรู้ว่าควรใช้ AI อย่างไร เพื่อเพิ่มทั้งประสิทธิภาพการทำงานและคุณภาพโค้ดไปพร้อมกัน

รวมเคล็ดลับใช้งานจริงเพื่อเพิ่มทั้งประสิทธิภาพและคุณภาพของการเขียนโปรแกรมด้วย AI

1. ทุ่ม AI ให้กับงานที่ทำซ้ำได้เท่านั้น

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

2. ก่อนเขียนโค้ดต้องทำแผนก่อนเสมอ

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

3. ซอยหน่วยงานให้เล็กมากที่สุด

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

4. อย่าสะสมคอนเท็กซ์มากเกินไป ให้รีเซ็ตบ่อย ๆ

• ยิ่งบทสนทนายาว การทำตามกฎและคุณภาพจะยิ่งตกลงอย่างรวดเร็ว
• หนึ่งเซสชันควรจัดการเพียงงานเดียว
• ถ้าทิศทางเปลี่ยน ให้เริ่มใหม่ในเซสชันใหม่
• งานระยะยาวให้เก็บสถานะไว้ในเอกสาร (plan.md เป็นต้น) แล้วป้อนกลับเข้าไปใหม่

5. เอกสารกฎควรสั้นและเป็นเชิงกลไก

• CLAUDE.md / AGENTS.md ควรรักษาไว้ในช่วง 500~1000 โทเค็น
• แทนที่จะเขียนแนวทางเชิงประกาศกว้าง ๆ ให้เน้น กฎที่เฉพาะเจาะจงและตรวจสอบได้
• บันทึกเฉพาะสิ่งที่พลาดบ่อยให้เหลือน้อยที่สุด
• ที่เหลือให้บังคับด้วยโค้ดและการตรวจสอบอัตโนมัติ

6. ใช้การทดสอบ ลินเตอร์ และบิลด์ เป็นลูปฟีดแบ็ก

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

7. อย่าแก้ระหว่างรัน ให้แก้แผนแล้วรันใหม่

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

8. สอนสไตล์ด้วยตัวอย่าง

• คำสั่งนามธรรมอย่าง “เขียนโค้ดดี ๆ” แทบไม่ได้ผล
• ให้ตัวอย่าง Before / After ไปพร้อมกัน
• แยกตัวอย่างที่ดีและไม่ดีให้ชัดเจน
• ขยายกฎโดยยึดตัวอย่างเป็นศูนย์กลาง

9. อย่าละทิ้งความเข้าใจ และกำหนดขอบเขตความรับผิดชอบให้ชัด

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

10. ตรวจสอบก่อนว่างานนี้เหมาะกับ AI หรือไม่

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

11. เริ่มจากความคาดหวังแบบ “ดีขึ้น 10%”

• อย่าคาดหวัง 10x ตั้งแต่แรก
• กลยุทธ์ที่ค่อย ๆ สะสมการปรับปรุงเล็ก ๆ จะมีประสิทธิภาพมากกว่าในระยะยาว
• หัวใจสำคัญคืออย่าละทิ้งการออกแบบและมาตรฐานด้านคุณภาพ

[GN⁺]

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

• ผมคือ Boris จากทีม Claude Code ขอแชร์ทิปส์เล็กน้อย

  1. ถ้ามีส่วนที่ Claude มักทำผิดหรือไม่เข้าใจ ก็ควรจดไว้ใน CLAUDE.md เพราะ Claude จะอ่านไฟล์นี้อัตโนมัติ
  2. ควรใช้ โหมด Plan (Shift+Tab สองครั้ง) อย่างจริงจัง วางแผนก่อนแล้วค่อยให้ลงมือทำ จะได้ผลลัพธ์ที่ดีกว่าสำหรับงานยาก ๆ ประมาณ 2–3 เท่า
  3. ควรให้วิธีตรวจสอบงานไว้ด้วย ตัวอย่างเช่นใน Svelte สามารถใช้เซิร์ฟเวอร์ Puppeteer MCP เพื่อให้มันตรวจผลลัพธ์ในเบราว์เซอร์ได้
  4. แนะนำให้ใช้โมเดล Opus 4.5 รู้สึกได้ชัดว่าอัปเกรดขึ้นมาอีกขั้นจาก Sonnet 4.5
     หวังว่าจะเป็นประโยชน์
  • ผมเองก็ได้ ประสิทธิภาพการทำงานเพิ่มขึ้นมาก จากโหมด Plan แต่ในเวอร์ชันล่าสุดมี บั๊ก ที่ทำให้โหมด Plan อ้างอิงแผนแรกของเซสชันซ้ำอยู่ตลอด จนเวิร์กโฟลว์พัง เลยสงสัยว่าหรือผมใช้งานผิดปกติไปเอง
  • หลังจากแก้ทางให้ Claude ระหว่างทำงานแล้ว ควรรัน พรอมป์ต์ self-reflection ด้วย กระบวนการนี้จะสะท้อนสิ่งที่สรุปกันด้วยมือกลับเข้า CLAUDE.md ให้อัตโนมัติ
  • เห็นด้วยกับคำแนะนำข้างต้น โดยเฉพาะ feedback loop ในข้อ (3) ที่เป็นหัวใจสำคัญ ต้องทำให้โมเดลแก้เองแล้วตรวจผลลัพธ์เองได้ การให้มันเขียนล็อกไฟล์ไว้ หรือให้วาง แผน pseudocode ก่อน ก็ช่วยให้แก้ปัญหาซับซ้อนได้เร็ว
  • Opus 4.5 เป็น ตัวเปลี่ยนเกม จริง ๆ ช่วยได้มากตอนรีแฟกเตอร์โปรเจกต์ React เก่า ๆ ถ้าเขียนพรอมป์ต์ให้ละเอียดและตั้งค่า CLAUDE.md ดี ๆ จะเห็นผลมาก
  • CLAUDE.md ดูเหมือนจะทำงานดีแค่ราว 4–5 ครั้ง จากนั้นก็ ลืมคำสั่ง เช่น ต่อให้บอกให้เรียกชื่อว่า “Mr. bcherny” ก็ลืมอย่างรวดเร็ว
  • ถ้าเทียบกับ Google Jules แล้ว Claude Code ให้ความรู้สึก เหมือนนักพัฒนามืออาชีพมากกว่า แต่ Claude Code Web ยังไม่มีฟีเจอร์โปรเจกต์ ผมเลยได้รับคำตอบให้ใช้ไฟล์ .clinerules แทน และอยากรู้ว่ามันต่างจาก CLAUDE.md อย่างไร
  • ฟีเจอร์ที่มีประโยชน์อย่างหนึ่งใน CLAUDE.md คือ @import ถ้าใส่ @ นำหน้าชื่อไฟล์ ก็สามารถบังคับให้รวมเข้า context ได้ แต่ถ้าใช้เยอะเกินไปก็ไม่มีประสิทธิภาพ

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

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

• ควรใส่ เงื่อนไขลูป (loop condition) ลงในพรอมป์ต์ด้วย เช่น “ให้ทำซ้ำจนกว่า yarn test จะผ่าน”
  เพราะท้ายที่สุด LLM ก็คือ เอเจนต์ที่คอยเรียกใช้เครื่องมือซ้ำ ๆ จึงควรปฏิบัติกับมันแบบนั้น
  อ้างอิง: Prompting the Agent Loop

• ขอแนะนำ การตั้งค่า nori-profiles ที่ผมทำ
  หลังจากทดลองมา 4 เดือน ประสิทธิภาพของ Claude Code ดีขึ้นอย่างเห็นได้ชัด
  บทความที่เกี่ยวข้อง: Averaging 10 PRs a Day with Claude

  • อยากรู้ว่าถ้าเทียบกับ skills ของ Claude Code แล้ว ต่างกันอย่างไร

• ที่บริษัทผมดูแลโค้ดเบส Golang ขนาดใหญ่ ลองใช้หลายเครื่องมือทั้ง Cursor, Claude Code, Gemini CLI ฯลฯ แต่ส่วนใหญ่ รับมือปริมาณโค้ดไม่ไหว
  แต่ aider ควบคุมได้ง่ายกว่ามากและแม่นยำสูง ถึงจะต้องเพิ่มไฟล์ด้วยมือ แต่แทบจะแม่น 100%
  ถ้าใช้คู่กับ Claude Sonnet รุ่นล่าสุดหรือ Gemini 2.5 Pro จะให้ความแม่นยำดีที่สุด

  • ข้อดีของ aider คือ ไม่ได้เป็นเอเจนต์เต็มรูปแบบ จึงสามารถจัดการ context ด้วยมือได้ และไม่ค่อยเกิดการแก้ไฟล์ผิด ประหยัดโทเคนและได้เปรียบด้านความเร็วด้วย

• เวลาทำงานด้วย Cursor ผมจะให้มันรีแฟกเตอร์หนึ่ง route ก่อนเพื่อ สร้างไฟล์กฎ แล้วหลังจากนั้น route อื่น ๆ แค่สั่งว่า “refactor” ก็พอ

  • อย่ากลัวพรอมป์ต์ยาว ๆ เพราะนี่แหละคือ context engineering ตัวประวัติการสนทนาจะช่วยทำให้ context สมบูรณ์ขึ้นเอง
    ควรระวังปริมาณ context ที่เหลืออยู่เสมอ และถ้าจำเป็นก็ควร clear context ให้เร็ว

• มุมมองที่ปฏิบัติต่อเอเจนต์ เหมือนเพื่อนร่วมทีม เป็นเรื่องสำคัญ ต้องสังเกตจุดแข็งจุดอ่อนของกันและกัน แล้วปรับวิธีทำงานร่วมกัน
  ผมจะโฟกัสพลังของเอเจนต์ไปที่ปัญหาที่ตรวจสอบได้ หรือโค้ดสำหรับการทดลอง
  แม้จะไม่คุ้นกับ Svelte แต่คิดว่าน่าจะดีถ้าใช้ การทดสอบแบบ disposable สไตล์ TDD เพื่อชี้นำการเขียนใหม่
  บางครั้ง การทิ้งบริบทที่ผิดพลาดก่อนหน้าแล้ว เริ่มใหม่ใน workspace ใหม่ ก็เป็นทางเลือกที่ดีที่สุด

  • ถ้าได้ช่วยแชร์สรุปของข้อความเรื่อง “สไตล์การรับรู้และการทำงานเป็นทีม” นั้นก็น่าจะดี

• ผมมอง LLM เป็น เครื่องมือค้นหา (searcher) ถ้าถามให้เล็กและเฉพาะเจาะจง มันก็จะค้นได้ง่ายขึ้น และยิ่งไกลจากข้อมูลฝึกมากเท่าไร โอกาสผิดพลาดก็ยิ่งสูง

  1. เปิดโปรเจกต์ใน Zed
  2. เชื่อมกับ Gemini CLI, Qwen code หรือ Claude อย่างใดอย่างหนึ่ง
  3. ขอให้แก้ไฟล์แล้วทดสอบ
  4. ถ้าไม่ได้ผลก็ลองกับ Grok หรือ Gemini 3 Chat
  5. ถ้ายังไม่ได้อีกก็แก้เองด้วยมือ
     สำหรับโปรเจกต์ใหม่ พรอมป์ต์แบบ one-shot อย่างเดียวก็มักจะพอ
  • แต่พรอมป์ต์ที่สั้นเกินไปก็ทำให้เกิดปัญหา ข้อมูลกำหนดไม่พอ (underspecification) ได้ ลดแค่ต้นทุนการคำนวณ แต่เสียเปรียบเรื่องคุณภาพ

• ชุดเครื่องมือ Claude Code ที่ผมใช้บ่อยคือ superpowers

  1. เริ่มจากเซสชันระดมความคิดเพื่ออธิบายฟีเจอร์
  2. Claude จะเขียน เอกสารออกแบบและแผนการพัฒนา แล้วบันทึกลงดิสก์
  3. เปิดหน้าต่าง Claude ใหม่ แล้วใช้คำสั่ง Execute Plan เพื่อให้ทำทีละขั้นพร้อมคอมมิต
  4. ทุก ๆ สามขั้นจะให้มันรีวิวตัวเองเพื่อเพิ่มคุณภาพโค้ด
     ใช้มาสองสัปดาห์แล้ว แทบไม่เคยล้มเหลวเลย

• หลักการเขียนโปรแกรมด้วย AI ของผมเรียบง่ายมาก

  1. ทำให้เสร็จในครั้งเดียว (one-shot) มักล้มเหลว
  2. แบ่งงานออกเป็นหน่วยที่ตรวจสอบได้
  3. สรุปแผนทั้งหมดไว้ในไฟล์ Markdown
  4. แต่ละขั้นให้ทำในเซสชันใหม่ ตรวจทานแล้วค่อยคอมมิต
     แก่นสำคัญคือ “Less is more” ยิ่ง context window สดใหม่เท่าไรก็ยิ่งดี และช่วงประมาณ 500–750 คำถือว่าเหมาะที่สุด ทุกขั้นต้องตรวจสอบได้

• สำหรับงานที่เกี่ยวกับ Java นั้น Claude มัก เปลี่ยนทิศทางไปมาอย่างต่อเนื่องหรือเสนอสิ่งที่ขัดแย้งกัน ผมรู้สึกว่า ChatGPT ดีกว่ามาก

  • ถ้าให้ คำสั่งที่เฉพาะเจาะจงกว่าเดิม ในพรอมป์ต์ อาจช่วยให้ดีขึ้นได้
  • อยากทราบว่าเคยลองใช้ Claude Code เวอร์ชัน นั้นหรือยัง

• ถ้าอยากได้ “Idiomatic code” ก่อนอื่นต้องนิยามสไตล์ที่ตัวเองต้องการให้ละเอียด แยกตัวอย่างที่ดี/ไม่ดีเป็นชิ้นเล็ก ๆ แล้วใส่ทั้งหมดนี้เข้าไปในโหมด Plan ของ Opus 4.5 เพื่อให้มันวางแผนก่อนแล้วค่อยทำ ถ้ายังไม่สมบูรณ์ในครั้งเดียว ก็แก้เอกสารแผนแล้วลองใหม่ ถ้าพยายามสอนละเอียดแบบดูแลนักพัฒนาจูเนียร์ กลับจะยิ่งไม่มีประสิทธิภาพ

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