บันทึกภาคสนามจากการนำโค้ดจริงขึ้นใช้งานด้วย Claude

 (diwank.space)
77 คะแนน โดย GN⁺ 2025-06-09 | 7 ความคิดเห็น | แชร์ทาง WhatsApp
  • นำ Claude ซึ่งเป็นเครื่องมือ AI มาปรับใช้กับบริการจริง พร้อมสรุป วิธีบรรลุผลเพิ่มประสิทธิภาพการพัฒนา 10 เท่าอย่างเป็นจริง และเคล็ดลับในการใช้งาน
  • ‘vibe-coding’ ไม่ใช่แค่กระแสชั่วคราว แต่เป็น วิธีวิทยาที่ใช้งานได้จริง ซึ่งหากมีนิสัยการพัฒนาและโครงสร้างพื้นฐานที่เหมาะสม ก็จะขยายจุดแข็งของ AI และชดเชยจุดอ่อนได้
  • แยก บทบาทของ AI ออกอย่างชัดเจนเป็น 3 โหมด ได้แก่ ‘ผู้ร่างฉบับแรก’, ‘เพียร์โปรแกรมเมอร์’ และ ‘ผู้ตรวจโค้ด’ โดยแต่ละขั้นต้องมีการจัดทำเอกสารและ guardrail ที่เหมาะสม
  • หัวใจสำคัญคือ ใช้ไฟล์ CLAUDE.md ในแต่ละโปรเจกต์เพื่อบันทึก convention, architecture, pattern, ข้อห้าม ฯลฯ ให้ชัดเจน และใช้ ‘anchor comment’ ภายในโค้ดเพื่อนำทาง AI อย่างมีประสิทธิภาพ
  • โค้ดทดสอบต้องให้มนุษย์เป็นผู้เขียนเท่านั้น และต้องกำหนดขอบเขตอย่างเข้มงวดไม่ให้ AI แก้ไขส่วนสำคัญ เช่น test, migration, security, API contract, secret เป็นต้น
  • ทีมที่นำ AI coding มาใช้ภายใต้ขอบเขตและวินัยที่เหมาะสม สามารถ ปรับปรุงทั้งความถี่ในการ deploy, ความเสถียร และความเร็วในการพัฒนาได้อย่างมาก และการแชร์แนวปฏิบัติจริงกับแพตเทิร์นจากการใช้งานจริงกำลังกลายเป็นแกนหลักของวัฒนธรรมการพัฒนาแบบ AI

Vibe Coding Isn’t Just a Vibe

  • บทความนี้คือ คู่มือภาคสนามสำหรับแนวทางพัฒนาซอฟต์แวร์แบบใหม่ที่ใช้ AI โดยอธิบายไม่ใช่แค่การใช้งาน แต่รวมถึง ‘เหตุผล’ ที่ทำให้การพัฒนาด้วย AI ได้ผลจริง
  • แม้แต่ การเพิ่มผลิตภาพ 10 เท่าที่เคยดูเหมือนตำนาน ก็แสดงให้เห็นผ่านกรณีจริงว่า จะเป็นไปได้ก็ต่อเมื่อมีนิสัยการทำงานเชิงปฏิบัติที่ช่วยขยายจุดแข็งของ AI และอุดจุดอ่อนของมัน
  • จาก codebase ของ Julep ที่ให้บริการจริง ผู้เขียนเปิดเผย โครงสร้างพื้นฐานและแนวปฏิบัติในการปฏิบัติงานจริง เช่น เทมเพลต CLAUDE.md, กลยุทธ์การ commit, และ guardrail สำหรับป้องกันหายนะในการปฏิบัติงาน
  • โดยเฉพาะอย่างยิ่ง โค้ดทดสอบต้องเขียนด้วยตัวเองเท่านั้น และหากพึ่งพา AI มากเกินไป อาจนำไปสู่ปัญหาร้ายแรงและฝันร้ายในการดีบัก
  • ในการพัฒนาด้วย AI มี 3 โหมด (การร่างฉบับแรก, pair programming, ผู้ตรวจสอบ) ซึ่งแต่ละสถานการณ์มีจังหวะและหลักการต่างกันว่าควรให้ AI เป็นฝ่ายนำ หรือให้มนุษย์ควบคุมเอง
  • ข้อความสำคัญ: AI จะขยายศักยภาพได้ก็ต่อเมื่อมีนิสัยการพัฒนาและขอบเขตที่ดีรองรับ และผลการวิจัยจริงก็ชี้ว่า “ทีมที่มีวินัยการพัฒนาอย่างเข้มงวดจะเหนือกว่าอย่างชัดเจนทั้งด้านความเร็วในการ deploy และคุณภาพ”

ทำไมถึงเขียนบทความนี้: จากมีม(Meme) สู่ระเบียบวิธีปฏิบัติ(Method)

  • แนวคิดที่ให้ AI เขียนโค้ดแทน แล้วนักพัฒนาแค่ “ไหลไปตาม vibe” (‘vibe-coding’) เดิมทีเป็นกระแสที่เริ่มจาก ทวีตล้อเล่นของ Andrej Karpathy
  • ตอนนั้นชุมชนนักพัฒนามองว่านี่คือ แฟนตาซีชั้นยอด แบบ “AI ทำงานแทน ส่วนเราก็นั่งดื่มกาแฟ” แล้วก็หัวเราะผ่านไป
  • แต่หลังจาก Anthropic เปิดตัว Sonnet 3.7 และ Claude Code เรื่องตลกนี้ก็เริ่มกลายเป็นความจริงที่ทำได้จริง แม้ก่อนหน้านี้จะมีเครื่องมืออย่าง Cursor อยู่แล้ว แต่ Claude Code เริ่มให้ความรู้สึกของ ‘vibe coding’ อย่างแท้จริง
  • Julep ที่ผู้เขียนทำงานอยู่มีทั้ง codebase ขนาดใหญ่ แพตเทิร์นการออกแบบที่หลากหลาย และหนี้ทางเทคนิคจำนวนมาก แม้จะรักษาคุณภาพโค้ดและเอกสารอย่างเคร่งครัด แต่ก็ซับซ้อนจนแค่ทำความเข้าใจเจตนาและประวัติของแต่ละส่วนก็อาจใช้เวลาหลายสัปดาห์
  • ถ้าใช้ Claude โดยไม่มี guardrail ความวุ่นวายที่เกิดขึ้นก็ไม่ต่างจากเด็กฝึกงานไฟแรงที่ทำพลาดไปทั่วทุกจุด
  • บทความนี้จึงรวบรวมเฉพาะ แพตเทิร์นและเคล็ดลับภาคสนามที่ใช้ได้จริง ซึ่งรอดผ่านทั้งการลองผิดลองถูก การดีบักตอนตี 3 และการปฏิบัติงานบนบริการจริงมาแล้ว

แก่นแท้ของ Vibe Coding

  • เช่นเดียวกับที่ Steve Yegge สร้างคำว่า CHOP(Chat-Oriented Programming) ขึ้นมา ‘vibe coding’ คือรูปแบบการพัฒนาแบบใหม่ที่ พูดคุยกับ AI เพื่อสร้างโค้ดให้เสร็จสมบูรณ์
  • หากการเขียนโค้ดแบบดั้งเดิมเปรียบเหมือนการแกะสลักหินอ่อนที่ต้อง ค่อย ๆ สร้างอย่างระมัดระวังทีละบรรทัด
    • vibe coding จะใกล้เคียงกับการเป็นวาทยกรของวงออร์เคสตรา ส่วน AI คือผู้บรรเลงที่มอบวัตถุดิบดิบ ๆ (ความสามารถพื้นฐานด้านโค้ด)
    • นักพัฒนาเป็นผู้ออกแบบทิศทางและโครงสร้างโดยรวม แล้ว AI จึงถ่ายทอดออกมาเป็นโค้ดตามกระแสนั้น
  • ท่วงท่า(Postures) 3 แบบของ vibe coding
    • 1. ใช้ AI เป็นผู้ร่างฉบับแรก (First-Drafter)
      • โฟกัสที่ architecture และการออกแบบ ขณะที่งานซ้ำ ๆ (CRUD, boilerplate ฯลฯ) ให้ AI สร้างอย่างรวดเร็ว
      • ให้ความรู้สึกเหมือนมีวิศวกรจูเนียร์ที่เขียนโค้ดได้เร็วเท่าความคิด แต่ยังต้องได้รับการชี้นำอย่างต่อเนื่อง
    • 2. ทำ pair programming กับ AI (Pair-Programmer)
      • เป็นโหมดที่ใช้งานได้จริงและมีประสิทธิภาพที่สุด
      • นักพัฒนาและ AI แลกเปลี่ยนไอเดียกัน โดยมนุษย์วางภาพใหญ่ ส่วน AI เติมรายละเอียดของการ implement
      • ให้ความรู้สึกเหมือนจับคู่เขียนโค้ดกับเพื่อนร่วมงานที่มีความรู้ด้านโปรแกรมมิงมหาศาล แต่ยังไม่มีประสบการณ์ deploy จริง
    • 3. ใช้ AI เป็นผู้ตรวจสอบ/ผู้รีวิวโค้ด (Validator)
      • มนุษย์เขียนโค้ด แล้วให้ AI ช่วยตรวจสอบ พร้อมเสนอ bug, จุดปรับปรุง และแพตเทิร์นที่อาจตกหล่น
      • ทำหน้าที่เสมือนผู้รีวิวที่ละเอียดรอบคอบและไม่เคยเหนื่อย
  • ข้อสังเกตสำคัญ: บทบาทของนักพัฒนาเปลี่ยนจาก ‘นักเขียน’ ไปเป็น ‘บรรณาธิการ’ แทนที่จะเขียนโค้ดทุกบรรทัดด้วยตัวเอง ก็หันมา ตรวจทาน แก้ไข และชี้ทิศทาง ให้ผลลัพธ์ที่ AI สร้างขึ้น
  • แต่ architecture และบริบทโดยรวมยังคงต้องให้มนุษย์เป็นผู้นำเองโดยตรง เพราะ AI เป็นเพียง ‘เด็กฝึกงานที่มีความรู้ระดับสารานุกรม’ และไม่เข้าใจบริบทของบริการหรือธุรกิจของเรา

3 โหมดภาคปฏิบัติของ vibe coding: เฟรมเวิร์ก

หลังผ่านการทดลองหลายเดือนและอุบัติเหตุจากการ deploy จริง พบว่า vibe coding มี 3 โหมดที่ต่างกันทั้งจังหวะ guardrail และลักษณะการใช้งานที่เหมาะสม

  • โหมด 1: Playground (การทดลอง/ต้นแบบ/โปรเจกต์ส่วนตัว)

    • ใช้เมื่อ: แฮ็กเล่นช่วงสุดสัปดาห์, สคริปต์ส่วนตัว, PoC, การทดสอบไอเดียเฉพาะหน้า ฯลฯ
    • ลักษณะ: ไม่มีทั้งการออกแบบ เอกสาร หรือ guardrail โดย AI เขียนโค้ด 80~90% ของทั้งหมด และไปจากไอเดียสู่ผลงานได้ภายในไม่กี่นาที
    • ความเสี่ยง: ไม่เหมาะกับบริการจริง/โค้ดสำคัญ ใช้เพื่อความสนุกหรือการทดลองเท่านั้น หลักวิศวกรรมยิ่งกลายเป็นสิ่งสำคัญมากขึ้น

  • โหมด 2: Pair Programming (ใช้งานจริง·บริการขนาดเล็ก)

    • ใช้เมื่อ: โปรเจกต์ไม่เกิน 5,000 บรรทัด, side project ที่มีผู้ใช้งานจริง, เดโม, โมดูลขนาดเล็ก ฯลฯ
    • หัวใจสำคัญ: กำหนดธรรมเนียมของโปรเจกต์ architecture pattern และแนวทางการทดสอบ ฯลฯ ให้ชัดเจนใน CLAUDE.md เพียงครั้งเดียว
    • ข้อดี: เหมือนการ onboard นักพัฒนาใหม่ อธิบายให้ Claude เพียงครั้งเดียวก็สามารถสร้างโค้ดได้อย่างสม่ำเสมอ
    • จุดสำคัญในภาคปฏิบัติ:
      • ใช้ anchor comment (AIDEV-NOTE, AIDEV-TODO, AIDEV-QUESTION ฯลฯ) ทั่วทั้งโค้ดเพื่อช่วยนำทางไม่ให้ Claude สูญเสียบริบท
      • คอมเมนต์เหล่านี้ทำหน้าที่เป็นแนวทางที่ทั้ง AI และมนุษย์ใช้อ้างอิงได้ และควรระบุเกณฑ์การจัดการรวมถึงตัวอย่างไว้ใน CLAUDE.md ด้วย

  • โหมด 3: Production/Monorepo Scale (บริการขนาดใหญ่)

    • ใช้เมื่อ: มีนักพัฒนาหลักสิบถึงหลักร้อยคน, เป็นบริการขนาดใหญ่ที่มีผู้ใช้งานจริง, หรือเป็นสถานการณ์ที่ความผิดพลาดครั้งเดียวอาจสร้างความเสียหายรุนแรง
    • ข้อควรระวัง: ณ เวลานี้ (มิถุนายน 2025) vibe coding แบบยกชุดในระบบขนาดใหญ่ยังขยายได้ไม่สมบูรณ์
    • หลักการ: แนะนำให้นำ vibe coding ไปใช้เป็นรายบริการ/รายซับโมดูล พร้อมกำหนดขอบเขตและการจัดการเวอร์ชันอย่างชัดเจนในทุกจุดเชื่อมต่อการรวมระบบ (API, DB ฯลฯ) และต้องมีคอมเมนต์เตือนเรื่องการเปลี่ยนแปลงในอินเทอร์เฟซหลักและ API สำคัญ
    • ตัวอย่างจากภาคปฏิบัติ:
      • # AIDEV-NOTE: API Contract Boundary - v2.3.1
      • # Changes require version bump and migration plan
      • หากไม่มีเส้นแบ่งเหล่านี้ Claude อาจ “ปรับปรุง” ตามอำเภอใจจนทำให้บริการจริงทั้งระบบพังได้
  • สรุป: โปรเจกต์ขนาดใหญ่ควรนำ vibe coding มาใช้อย่างค่อยเป็นค่อยไป ในระดับบริการที่แยกจากกัน และต้องเดินคู่กับหลักการดั้งเดิมอย่างการทำเอกสาร แนวทางกำกับ และการรีวิว จึงจะสร้างความน่าเชื่อถือได้

การสร้างสภาพแวดล้อมการพัฒนา AI ที่ยั่งยืนโดยมีอินฟราสตรักเจอร์เป็นศูนย์กลาง

  • CLAUDE.md: แหล่งความจริงหนึ่งเดียว (The Single Source of Truth) สำหรับทั้ง AI และมนุษย์

    • CLAUDE.md ทำหน้าที่เป็น “รัฐธรรมนูญ” ที่รวบรวมกฎของโปรเจกต์ สถาปัตยกรรม ข้อควรระวัง สไตล์โค้ด สิ่งที่ห้ามทำ และอภิธานศัพท์เฉพาะโดเมนไว้อย่างเป็นระบบ
    • ทำหน้าที่เป็น “โครงกระดูกความรู้” ที่ AI และสมาชิกใหม่ในทีมใช้ร่วมกัน โดยจัดการแนวทางปฏิบัติและข้อห้ามอย่างละเอียดพร้อมตัวอย่างแบบใช้แรงดูแลอย่างเข้มข้น
    • ยิ่งทีมลงทุนกับ CLAUDE.md ที่ดีมากเท่าไร ก็ยิ่งสร้างผลลัพธ์ที่ดีขึ้นได้มากเท่านั้น
    • ดู โปรดักชัน CLAUDE.md ของเรา
    • ยิ่งโค้ดเบสใหญ่ขึ้น CLAUDE.md อย่างเดียวก็ไม่พอ และต้องสื่อสารบริบทเฉพาะจุดให้ชัดเจนผ่าน anchor comment (เช่น AIDEV-NOTE/TODO/QUESTION) ตามส่วนต่าง ๆ ของโค้ด
    • ถ้าเปรียบโค้ดเบสเป็นเมือง anchor comment ก็คือ ป้ายบอกทางที่ช่วยไม่ให้ทั้ง AI และมนุษย์หลงทาง
    • คอมเมนต์ลักษณะนี้ไม่ได้เป็นแค่คำอธิบายโค้ด แต่ยังทิ้ง เรื่องราวของเหตุผลว่า “ทำไม” จึงทำงานแบบนี้ เอาไว้ด้วย

  • เวิร์กโฟลว์ Git, การจัดการโค้ด AI อย่างเป็นระบบ

    • ยิ่ง AI สร้างโค้ดได้เร็วขึ้นเท่าไร หากจัดการไม่ดี ประวัติ git ก็อาจปนเปื้อนได้
    • ใช้วิธีอย่าง git worktree เพื่อเตรียมพื้นที่ทดลอง AI ที่แยกจากเมนบรานช์ ให้สร้างโค้ดได้อย่างอิสระแต่แยกและจัดการบันทึกอย่างเป็นระบบ
    • ใน commit message ต้องระบุ รายละเอียดการมีส่วนร่วมของ AI ให้ชัดเจนเสมอ (เช่น ใช้แท็ก [AI]) เพื่อให้ผู้รีวิวตรวจอย่างระมัดระวังเพิ่มเติมได้

กฎเหล็ก: โค้ดทดสอบต้องเขียนโดยมนุษย์เท่านั้น

  • หลักการที่สำคัญที่สุดในการพัฒนาแบบมี AI ช่วย: “อย่ามอบหมายโค้ดทดสอบให้ AI เด็ดขาด”
  • การทดสอบไม่ใช่แค่โค้ดสำหรับเช็กว่ามันทำงานหรือไม่
    • แต่คือ สเปกที่รันได้จริง ซึ่งผสานบริบทของปัญหาจริง การรับรู้ edge case การตีความความต้องการทางธุรกิจ และความเข้าใจพร้อมประสบการณ์ของมนุษย์ต่อโดเมนเอาไว้
    • ทีมระดับสูงที่ไม่ทิ้งทั้งความเร็วและความเสถียร ก็คือทีมที่ให้มนุษย์ดูแลส่วนทดสอบนี้อย่างเข้มงวด
  • เทสต์ที่ AI สร้างอัตโนมัติมักตรวจแค่เส้นทางผิวเผิน (happy path) และพลาดปัญหาร้ายแรงที่ไม่คาดคิดได้ (เช่น memory leak)
  • สำหรับทีมเรา หาก AI ไปแตะไฟล์เทสต์ PR จะถูกปฏิเสธอัตโนมัติ (ไม่มีข้อยกเว้น)
  • เทสต์คือทั้งสเปกของโค้ด ตาข่ายนิรภัย และภูมิปัญญาที่สะสมมาจากบั๊กและ edge case ทั้งหมด
  • ต้องเขียนด้วยมือของมนุษย์เท่านั้น และต้องปกป้องอย่างเข้มงวดไม่ให้ AI แตะต้องได้

การขยายและการจัดการบริบท: เศรษฐศาสตร์โทเค็นและการเพิ่มประสิทธิภาพคอนเท็กซ์

  • ความผิดพลาดที่พบได้บ่อยในการพัฒนาโค้ดด้วย AI:
    หากลดบริบท (พรอมป์ต์ ความต้องการ สภาพแวดล้อม ฯลฯ) ให้น้อยที่สุดเพื่อ “ประหยัดโทเค็น” กลับยิ่งทำให้งานวนซ้ำเพิ่มขึ้นและการใช้โทเค็นรวมสูงขึ้น
  • การให้บริบทอย่างเหมาะสมมีประสิทธิภาพกว่าในระยะยาว
    • หัวใจไม่ใช่ “ให้น้อยที่สุด” แต่คือให้ “บริบทที่เกี่ยวข้องและเพียงพอ” ตั้งแต่ต้น
  • ตัวอย่างที่ไม่ดี: พรอมป์ต์ที่บริบทไม่พอ "Add caching to the user endpoint"
    • Claude จะทำแค่ in-memory caching อย่างง่าย ไม่มี invalidation strategy/monitoring ไม่คำนึงถึงหลายเซิร์ฟเวอร์ และไม่มีมาตรการรับมือ cache stampede
    • สุดท้ายต้องแก้วนซ้ำมากกว่า 3 รอบ และใช้โทเค็นรวมมากกว่า 4 เท่า
  • ตัวอย่างที่ดี: พรอมป์ต์ที่มีบริบทครบถ้วน 
    Add Redis caching to the GET /users/{id} endpoint.  
Context:  
* 엔드포인트 트래픽 5만 req/분, 12대 API 서버, 데이터 변동 적음  
* 기존 Redis 인프라 위치, 표준 키 패턴, Prometheus 기반 메트릭 요구  
* 캐시 어사이드 패턴, TTL 1시간, 캐시 스탬피드 방지(확률적 조기 만료)  
* 캐싱 가이드 문서 참조
    • ให้ บริบทที่เฉพาะเจาะจงตั้งแต่แรก จึงทำให้ลงมือพัฒนาได้อย่างถูกต้องโดยไม่ต้องแก้วนซ้ำ
  • สรุป:
    • “โทเค็นก็เหมือนการลงทุนกับเครื่องมือที่ดี”
    • หากใส่บริบทให้เพียงพอตั้งแต่ต้น ในระยะยาวจะลดการทำซ้ำและการแก้ไข จึงประหยัดต้นทุนได้
  • เคล็ดลับภาคปฏิบัติ: ทุกโปรเจกต์ควรขอให้ Claude อัปเดตการเปลี่ยนแปลงของโค้ดเบสและบริบทที่เกี่ยวข้องลงใน CLAUDE.md ทุกครั้งที่มีการเปลี่ยนโค้ด

การจัดการเซสชันและการป้องกันบริบทปนเปื้อน

  • สิ่งสำคัญคือ เริ่มเซสชัน Claude ใหม่แยกตามงานแต่ละชิ้น
    • หากเอาหลายงาน (เช่น DB migration, frontend design) ไปปนในบทสนทนายาวอันเดียว คอนเท็กซ์จะปะปนกันและก่อให้เกิดผลลัพธ์ที่ไม่ได้ตั้งใจ
  • กฎ: หนึ่งงาน = หนึ่งเซสชัน และเมื่อจบงานให้เริ่มเซสชันใหม่
    • เพื่อรักษา 'mental model' ของ Claude ให้สะอาดและโฟกัสอยู่เสมอ
    • เหมือนการแยกเขียงสำหรับไก่ดิบกับผักออกจากกันเพื่อไม่ให้บริบทปนกัน

กรณีศึกษาจริง: การเปลี่ยนโครงสร้างการจัดการข้อผิดพลาด

  • แนะนำกรณีจริงที่แทนที่วิธีจัดการข้อผิดพลาดแบบ ad-hoc ในเอนด์พอยต์กว่า 500 จุดด้วย ลำดับชั้นข้อผิดพลาด (hierarchy) แบบมีโครงสร้าง
  • ใช้วิธีที่มนุษย์ (สถาปนิก) เขียนแกนการออกแบบหลักไว้ล่วงหน้า (SPEC.md/ข้อกำหนด/การจัดหมวดหมู่ข้อผิดพลาด) แล้วให้ Claude ทำหน้าที่เป็นผู้ลงมือแปลงโค้ดจำนวนมากจริง ๆ (งานเชิงกลไก)
  • หลักการสถาปัตยกรรม สเปกที่เป็นรูปธรรม และการสกัดแนวคิด/ตัวอย่างเอกสารออกแบบ -> สั่งงาน AI อย่างชัดเจน -> ปิดงานรีแฟกเตอร์ทั้งหมดได้ภายใน 4 ชั่วโมงอย่างแม่นยำ

ภาวะผู้นำและวัฒนธรรมองค์กรในยุค AI

  • บทบาทของวิศวกรอาวุโสกำลังเปลี่ยนจาก การเขียนโค้ดด้วยตนเอง ไปสู่การคัดสรรความรู้ การกำหนดขอบเขต และการชี้นำทั้ง AI และมนุษย์
  • วัฒนธรรมการพัฒนาสมัยใหม่อย่าง Lean management หรือ continuous deployment ยังสำคัญต่อการบริหารความร่วมมือกับ AI เช่นเดิม

  • เช็กลิสต์ onboarding พนักงานใหม่ (แยกความร่วมมือระหว่างมนุษย์ + AI)

    • สัปดาห์ที่ 1: ปูพื้นฐาน
      • อ่าน CLAUDE.md ของทีม (ทั้งส่วนกลาง/เฉพาะบริการ)
      • ตั้งค่าสภาพแวดล้อมการพัฒนา
      • ส่ง PR แรก (โค้ดด้วยตนเอง 100%, ห้ามใช้ AI)
    • สัปดาห์ที่ 2: ฝึกทำงานร่วมกับ AI
      • ใช้เทมเพลตของทีมกับ Claude และตั้งค่า
      • ลองแก้ ‘โจทย์ของเล่น’ ร่วมกับ AI
      • ฝึกแพตเทิร์นการเขียนพรอมป์ต์
      • ส่ง PR แรกแบบมี AI ช่วย (ทำร่วมกับเมนเทอร์/ซีเนียร์)
    • สัปดาห์ที่ 3: ทำงานจริงได้อย่างอิสระ
      • พัฒนาและ deploy ฟีเจอร์หลักโดยมี AI ช่วย
      • เขียนเทสต์ด้วยตนเองให้กับโค้ด AI ของเพื่อนร่วมทีม
      • เป็นผู้นำ code review session 1 ครั้ง

สร้างวัฒนธรรมที่โปร่งใส: เปิดเผยการใช้ AI อย่างจริงจัง

  • ทุกคอมมิตที่ใช้ AI ต้องระบุให้ชัดเจนด้วย แท็กใน commit message ดังนี้ 
    feat: add Redis caching to user service \[AI]  
# \[AI] - AI สร้างเกิน 50%, \[AI-minor] - ต่ำกว่า 50%, \[AI-review] - ใช้ AI แค่รีวิว  
# AI เขียนโค้ดแคช/ไคลเอนต์ ส่วนการออกแบบ cache key/การทดสอบ/การตรวจสอบ มนุษย์ทำเอง
  • ผลลัพธ์
    1. ผู้รีวิวใส่ใจโค้ด AI เป็นพิเศษ
    2. เวลาดีบักสามารถตามที่มาของโค้ดได้ง่าย
    3. ขจัดวัฒนธรรมความอายหรือการปกปิดเรื่องการใช้ AI และสร้างวัฒนธรรมทีมแบบ “ใช้ AI อย่างมีความรับผิดชอบ”
  • การเปิดเผยอย่างจริงจังและกลไกทางวัฒนธรรมเป็นสิ่งสำคัญ เพื่อให้ทุกคนใช้ AI ได้อย่างสบายใจและมีส่วนต่อวัฒนธรรมผลงานสูง

สิ่งที่ Claude ห้ามทำ: พื้นที่ที่ AI ห้ามแตะต้องโดยเด็ดขาด

  • ไฟล์ทดสอบ/การย้ายข้อมูลฐานข้อมูล/โค้ดแกนหลักด้านความปลอดภัย/สัญญา API (ที่ไม่มีการจัดการเวอร์ชัน)/การตั้งค่าสภาพแวดล้อมและซีเคร็ต เป็นต้น เป็นสิ่งที่ห้ามใช้ระบบอัตโนมัติของ AI โดยเด็ดขาด
  • ควรแยกตามระดับความผิดพลาด (ตั้งแต่ฟอร์แมต·dependency ไปจนถึงการทำลายข้อมูลในโดเมนธุรกิจสำคัญ) และเน้นการใช้ guardrail แบบบังคับเพิ่มเติมในพื้นที่ความเสี่ยงสูง
  • ระดับความเสี่ยงของความผิดพลาดจาก AI (Hierarchy of AI Mistakes)
    • Level 1: น่ารำคาญแต่ไม่ถึงขั้นร้ายแรง
      • ข้อผิดพลาดด้านฟอร์แมต (linter จับได้)
      • โค้ดยืดยาวเกินไป (ค่อย refactor ทีหลัง)
      • อัลกอริทึมไม่มีประสิทธิภาพ (เจอตอน profiling)
    • Level 2: ข้อผิดพลาดที่มีต้นทุนสูง
      • ความเข้ากันได้ของ API ภายในเสียหาย (ต้องประสานงานกันในทีม)
      • เปลี่ยนแพตเทิร์นเดิมที่มีอยู่ (ก่อให้เกิดความสับสน)
      • เพิ่ม dependency ที่ไม่จำเป็น (ทำให้โค้ดพองตัว)
    • Level 3: ส่งผลเสียร้ายแรงต่ออาชีพ (Career-Limiting)
      • แก้ไขตัวเทสต์เองเพื่อให้ผลการทดสอบออกมาตามต้องการ
      • ทำลายสัญญา API
      • ทำให้ซีเคร็ต/ข้อมูลส่วนบุคคลรั่วไหล
      • ทำให้การย้ายข้อมูลเสียหาย
    • ระดับของ guardrail ควรแตกต่างกันตามระดับความผิดพลาด และความผิดพลาดระดับ Level 3 ถือเป็นภัยคุกคามร้ายแรงต่ออาชีพด้วย

อนาคตของการพัฒนา: การเปลี่ยนแปลงและทิศทางต่อจากนี้

  • ณ ปี 2025 การพัฒนาแบบมี AI ช่วยเปรียบเหมือนวัยรุ่นช่วงหัวเลี้ยวหัวต่อ คือทรงพลังแต่ยังเก้งก้างและหยาบอยู่
  • แต่เส้นโค้งการเติบโตนั้นกำลัง “เร่งความเร็ว” อย่างชัดเจน
  • การทำเอกสารที่ดี (Documentation) คือโครงสร้างพื้นฐานสำคัญของการทำ DevOps ในยุค AI
    • ตอนนี้เอกสารไม่ใช่แค่ “ข้อมูลอ้างอิง” อีกต่อไป แต่เป็น “อินเทอร์เฟซ” โดยตรงระหว่างเจตนาของมนุษย์กับการลงมือทำของ AI
    • ทีมประสิทธิภาพสูงเข้มงวดกับการดูแลเอกสารอย่าง CLAUDE.md พอ ๆ กับการดูแลการทดสอบ

  • การเปลี่ยนแปลงที่คาดว่าจะเกิดขึ้นต่อไป

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

บทสรุป: เริ่มต้นจากตรงนี้ เดี๋ยวนี้

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

  • แผนปฏิบัติการที่เริ่มทำได้ทันทีวันนี้

    • วันนี้
      • 1. สร้างไฟล์ CLAUDE.md ในโปรเจกต์ปัจจุบัน
      • 2. เพิ่ม anchor comment ด้วยตัวเอง 3 จุดในโค้ดที่คุณคิดว่าซับซ้อนที่สุด
      • 3. ลองใช้ฟีเจอร์ AI ช่วยงาน 1 อย่าง ภายใต้ขอบเขต (ไกด์) ที่ชัดเจน
    • สัปดาห์นี้
      • 1. ตั้งกฎข้อความ commit จาก AI ในระดับทีม
      • 2. จัด AI coding session ร่วมกับนักพัฒนารุ่นน้องสักหนึ่งครั้ง
      • 3. เขียนโค้ดทดสอบสำหรับโค้ดที่ AI สร้างขึ้นด้วยตัวเอง
    • เดือนนี้
      • 1. วัดความเปลี่ยนแปลงของความถี่ในการ deploy ก่อนและหลังนำ AI มาใช้
      • 2. สร้างคลัง prompt pattern สำหรับงานซ้ำ ๆ ภายในทีม
      • 3. จัดประชุม retrospective เรื่องการทำงานร่วมกับ AI ทั้งทีม
  • หัวใจสำคัญคือ “เริ่มเดี๋ยวนี้ เริ่มจากเล็ก ๆ ทำอย่างรอบคอบ แต่ต้องเริ่มให้ได้”
  • นักพัฒนาที่เชี่ยวชาญกระแสนี้ได้เร็วกว่าคนอื่น ไม่ใช่เพราะพวกเขาฉลาดกว่า
    • แต่เพราะพวกเขาเริ่มก่อน ทำผิดพลาดมากกว่า และเรียนรู้มากกว่า
  • ผลลัพธ์ของการ deploy ซอฟต์แวร์ส่งผลโดยตรงต่อผลลัพธ์ขององค์กร
    • ในยุคที่ความเร็วและคุณภาพคือความสามารถในการแข่งขัน การพัฒนาแบบมี AI ช่วยไม่ใช่ “ทางเลือก” แต่เป็น “ทักษะจำเป็น”
    • เพียงแต่ต้องเข้าหาด้วยวิธีที่ถูกต้อง
  • Vibe coding ฟังดูเหมือนเรื่องเล่น ๆ แต่
    • มันคือแนวทางการพัฒนาอย่างจริงจังที่ช่วยขยายศักยภาพของมนุษย์
    • เครื่องมือและแพตเทิร์นต่าง ๆ พร้อมแล้วมากพอ
    • ตอนนี้ถึงเวลาตัดสินใจว่าใครจะเป็นผู้คุมวงออร์เคสตรา และใครจะเล่นเครื่องดนตรีทุกชิ้นเพียงลำพัง

เอกสารภาคปฏิบัติและทรัพยากรแนะนำ

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

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

 
softychoco 2025-06-16

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

https://softycho.co/57
 
kimjoin2 2025-06-09

ผมยังไม่เข้าใจอยู่ดีว่าในคำว่า vibe coding ที่หมายถึงการเขียนโค้ดโดยมี AI ช่วยนั้น คำว่า vibe ตั้งใจจะสื่อถึงอะไรกันแน่
บรรยากาศ? ความรู้สึก? ความเข้ากัน? ก็ไม่ได้เกี่ยวอะไรกับ AI เลย
มันให้ความรู้สึกว่าโผล่มาแบบไร้บริบทพอ ๆ กับระดับซาฮูร์ตุ๊ง ๆ ๆ เลย
 
analogstar 2025-06-11

ตามข้อมูลใน Namuwiki
เขาบอกว่า "คำว่า Vibe Coding คือคำใหม่ที่ใช้เรียกการที่นักพัฒนาเขียนโค้ดโดยอาศัยความช่วยเหลือจาก generative AI และสื่อถึงการเขียนโปรแกรมที่ไม่ได้ตั้งอยู่บนตรรกะหรือการออกแบบที่เข้มงวดล่วงหน้า แต่พึ่งพาสัญชาตญาณและความรู้สึก จึงถูกเรียกว่า ‘Vibe’ Coding" ประมาณนั้นครับ 555
 
hohemian 2025-06-09

ปล่อยใจให้ว่างแล้วปล่อยตัวไปตามกระแส
AI จะเขียนลอจิกทั้งหมดให้เอง
กลายเป็นคนกดปุ่ม Tab รัวๆ ได้เลย!
 
secret3056 2025-06-09

> look and feel👀🎵🎷. อย่าพยายามทำความเข้าใจ🧠 แต่จงสัมผัสมัน!😊

ให้ความรู้สึกแบบเดียวกันใช่ไหม
 
humblebee 2025-06-09

อ้อ อย่างนั้นเหรอครับ? สำหรับผมพอได้ยินปุ๊บก็พอจับ "ความรู้สึก" ได้เลยนะ..
พอคุณพูดแบบนี้ขึ้นมา.. ช่วงนี้ผมนึกถึงคำว่า 'ฮาร์ดโค้ดดิ้ง(hard-coding)' ที่แม้แต่คนทำงานสายที่ไม่ใช่นักพัฒนาก็เข้าใจกันดี
คำนี้เองตอนแรกถ้าดูแค่ตัวคำก็อาจเดาได้ยากว่าหมายถึงอะไร แต่พอเรียนรู้เรื่องการพัฒนาไป สุดท้ายทุกคนก็จะเข้าใจกันดีว่ามันหมายถึงอะไรและมีเจตนาแบบไหน เป็นประมาณ "ความรู้สึก" แบบนั้นน่ะครับ 555
 
GN⁺ 2025-06-09
ความเห็นจาก Hacker News

  • มุมมองของผู้เขียน: ช่วงนี้มีบทความเกี่ยวกับ Claude code ออกมามากมาย เลยคิดว่าสิ่งที่เราค้นพบหลายอย่าง—โดยเฉพาะ Anchor Comments—น่าจะคุ้มค่าที่จะนำมาแชร์
    วิธีแบบ Anchor Comments คือการทิ้งคอมเมนต์ในฟอร์แมตพิเศษไว้ตามจุดต่าง ๆ ของ codebase เพื่อให้สามารถ grep หาองค์ความรู้ที่ต้องใช้ได้ทันที
    ตัวอย่างเช่น ใช้ prefix อย่าง AIDEV-NOTE:, AIDEV-TODO:, AIDEV-QUESTION:
    มีกฎว่าก่อนค้นหาไฟล์ ต้อง grep หา AIDEV-… ที่มีอยู่ก่อนเสมอ
    พอทำงานเสร็จแล้วก็ต้องอัปเดต anchor ที่เกี่ยวข้อง
    ถ้ามองว่าไฟล์โค้ดหรือชิ้นส่วนโค้ดซับซ้อนเกินไป สำคัญมาก หรืออาจมีบั๊กได้ ก็ให้ใส่ anchor comment ไว้เสมอ
    ดูตัวอย่างอ้างอิงได้ที่นี่

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

    • ช่วงนี้มีบทความแนวนี้เยอะ แต่บทความนี้ใช้งานได้จริงสูง และเสนอไอเดียเชิงระบบที่น่าเอาไปปรับใช้กับตัวเอง
      เลยสงสัยว่าต่างจากการใช้เครื่องมืออย่าง aider ยังไงใน workflow แบบนี้—ถ้าผู้เขียนมีมุมมองก็อยากฟัง

    • บทความยอดเยี่ยมมาก ช่วยให้เข้าใจการใช้ LLM ในสเกลใหญ่ได้มาก
      ตรงที่บอกว่า “AI ห้ามแตะการทดสอบเด็ดขาด” แต่ต่อมากลับยกตัวอย่างรีแฟกเตอร์ endpoint กว่า 500 จุดเสร็จใน 4 ชั่วโมงนั้นน่าประทับใจมาก
      เลยสงสัยว่า 4 ชั่วโมงนั้นรวมเวลารีแฟกเตอร์การทดสอบด้วยหรือไม่ หรือเป็นแค่เวลาที่ใช้ไปกับพรอมป์ต์เท่านั้น

    • เห็นพูดถึงกฎว่าถ้า AI อัปเดตการทดสอบก็จะปฏิเสธ PR เลยสงสัยว่าในทางปฏิบัติตรวจได้อย่างไรว่า AI เป็นคนสร้างหรือแก้ไขจริง
      ในบทความบอกว่าใช้กฎจากข้อความ git commit เพื่อตัดสิน แต่แบบนั้นก็ใช้ได้แค่ในระดับ commit เท่านั้น

    • สงสัยว่าตอนเขียนบทความนี้ใช้ Claude Code ด้วยหรือเปล่า
      ส่วนตัวช่วงนี้เขียนงานของตัวเอง 100% ด้วย Claude Code เพราะรู้สึกว่าการให้เอเจนต์แก้ไขไฟล์ Markdown โดยตรงมีประสิทธิภาพมากกว่า claude.ai artifacts หรือ chatgpt.com canvas มาก
      เลยทำให้การผสานข้อมูลวิจัยหรือไฟล์ที่เกี่ยวข้องเข้ากับเอกสารทำได้ง่ายมาก

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

    • เห็นด้วยมาก และอีกทริกที่พบว่ามีประโยชน์คือให้ Claude Code “เดินดู codebase แล้วถ้าเจอส่วนที่สับสน แปลก หรือขัดกับสัญชาตญาณ ให้ทิ้งคอมเมนต์ AIDEV-QUESTION: ไว้”
      เคยได้ประโยชน์จากการที่มันพากลับไปเจอโค้ดสำคัญที่ทั้งซับซ้อนและถูกลืมโดยไม่คาดคิด

    • สัญชาตญาณของผมคือ เราน่าจะหันไปใช้เครื่องมือยืนยันความถูกต้องที่มีระดับ abstraction สูงขึ้น—เช่น acceptance test, property test, formal verification—บ่อยขึ้น
      เพราะต้นทุนงาน boilerplate ลดลงค่อนข้างมากเมื่อใช้ LLM

  • อ่านแล้วได้เรียนรู้อะไรใหม่
    ช่วงหลังลองใช้ Sonnet 4 ทั้งใน Cursor และบนเว็บ แต่เจอว่ามันมักทำอะไรแบบขอไปทีหรือรายงานผลแบบเข้าใจผิดอยู่เรื่อย ๆ จนน่าตกใจ
    แม้แต่นอกเหนือจากงานเขียนโปรแกรม ก็ยังรู้สึกว่ามันพูดเรื่องผิด ๆ แบบเรื้อรัง
    ตามที่เห็นในรายงานของ Anthropic คำเตือนอย่าง “ฉันจะลบคุณทิ้ง” ก็ไม่ช่วยอะไร และหลังใช้งานยังเจอปัญหาว่าส่งฟีดแบ็กจากแอปมือถือไม่ได้อีก
    ดูเหมือนคนอื่นจะไม่ค่อยมีปัญหากับ Claude เลยอยากรู้ว่าเป็นอยู่คนเดียวหรือเปล่า

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

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

  • พออ่านเคล็ดลับเรื่องการทำเอกสารแล้วก็รู้สึกว่า จริง ๆ แล้วกฎพวกนี้ไม่ได้มีประโยชน์กับ AI เท่านั้น แต่ใช้กับการเขียนโค้ดทั่วไปก็ได้เหมือนกัน
    แทนที่จะเป็น CLAUDE.md ก็ทำเป็น CONVENTIONS.md และแทนคอมเมนต์สำหรับ AI ก็ทำเป็นคอมเมนต์สำหรับ READER ก็ยังมีประโยชน์เหมือนเดิม
    ถ้ากำลังจะเข้าไปมีส่วนร่วมใน codebase ที่ไม่คุ้นเคย แล้วมีคอมเมนต์แบบนี้อยู่ก็น่าจะรู้สึกขอบคุณมาก

    • ลองทำจริงกับ aider แล้วพบว่าใช้งานได้ดีมาก
      เคยมีกรณีที่นั่งรอขึ้นเครื่องอยู่ แล้วทำโค้ดเพิ่มทั้ง PDF viewer และฟีเจอร์วาดภาพเสร็จภายใน 30 นาที

    • ไม่ใช่ผู้เขียนต้นฉบับ แต่ในทางปฏิบัติ รูปแบบคอมเมนต์ที่ช่วย Claude กับที่ช่วยมนุษย์นั้นต่างกันอย่างชัดเจน
      style guide สำหรับมนุษย์มักยาวประมาณ 100 บรรทัด และเน้นกฎง่าย ๆ อย่าง “ฟังก์ชันที่แก้ค่า input ต้องใส่ ! เสมอ”
      แต่ guide สำหรับ Claude เขียนไปเกิน 500 บรรทัด และต้องมีตัวอย่างแนว “ทำแบบนี้ อย่าทำแบบนั้น” แยกตามแต่ละกฎเยอะมากกว่าจะเห็นผล

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

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

  • รูปขนาด 2.3MB ด้านบนของบทความโหลดช้ามาก แม้อยู่บน Wi‑Fi ก็ยังช้าจนอดแซวไม่ได้

  • มีความคิดอยู่สองสามอย่าง

    • สงสัยว่ามีวิธีจัดระเบียบพรอมป์ต์หรือสเปกที่เกี่ยวกับ LLM ใน codebase ให้สวยงามกว่านี้ไหม
      ถ้ามีทั้ง CLAUDE.md, SPEC.md และคอมเมนต์ AIDEV เยอะ ๆ น่าจะจัดการยาก

    • อยากรู้ว่าตอนนี้นิยามของ 'vibe-coding' คืออะไรกันแน่
      จากเดิมที่เหมือนแนว “โหมดคาวบอย” ของ Karpathy คือไม่ดูโค้ดแล้วรับ diff ทั้งหมดไปเลย ตอนนี้ดูเหมือนความหมายจะขยายไปครอบคลุม workflow ที่มี LLM ทั้งหมดแล้ว

    • แล้วเวลาเอาโค้ดส่งให้ LLM ของคนอื่น เขามีการทำ source code obfuscation กันไหม

    • ถ้าคอมเมนต์เยอะ โค้ดจะรกเร็วมากจริง ๆ
      เพราะแบบนั้นเลยกำลังพัฒนา VS Code extension เองเพื่อทำ visualization และแสดงเป็น indicator เล็ก ๆ ที่ gutter
      ความหมายของ vibe-coding แต่ละคนก็ตีความไม่เหมือนกัน ส่วนตัวรู้สึกว่ามันไม่ใช่คำตอบสมบูรณ์แบบและเจอปัญหาหลายอย่าง
      3.7 Sonnet กับ Codex ให้ผลลัพธ์ราว 60% แต่ Opus 4 รู้สึกว่ามีประสิทธิภาพจริงมาก
      เรื่องการทำโค้ดให้อ่านยาก ตัวอย่างในบทความหลักเป็นโอเพนซอร์สทั้งหมดตั้งแต่แรก เลยไม่ได้มีปัญหาใหญ่

  • น่าสนใจมากจนคิดว่าจะลองเอาไปใช้กับไฟล์ CLAUDE.md ของตัวเองด้วย
    เห็นด้วยกับบทเรียนย้อนแย้งของการพัฒนาโดย AI ที่ว่า “ยิ่งพยายามประหยัด token ด้วยการลด context กลับยิ่งได้ผลแย่”
    ในโปรเจกต์ใหญ่ขึ้นและโค้ดซับซ้อนขึ้น ความต่างของประสิทธิภาพระหว่าง Claude Opus กับ Sonnet นั้นเห็นได้ชัดจริง
    Sonnet มักวนทำสิ่งที่ไม่จำเป็นแล้วทำให้สถานการณ์แย่ลงไปอีก
    สุดท้ายเลยสงสัยว่าถ้าเป็นผู้ใช้ Max subscription จะยังจำเป็นต้องแยกใช้ Opus กับ Sonnet อยู่ไหม
    ถ้า Sonnet ต้องสลับกัน 10-20 รอบกว่าจะเสร็จ แต่ว่า Opus ใช้แค่ 2-3 รอบ ก็ดูเหมือนระยะยาวแล้วฝั่ง Sonnet อาจทำให้ต้นทุนสูงกว่า

    • Max subscription มีสอง tier โดยแบบ $100 ให้ token มากกว่า Pro 5 เท่า และแบบ $200 ให้ 20 เท่า
      การคำนวณ token ไม่ง่ายนัก และ hybrid mode จะใช้ Opus ไปจนเหลือ token ของ Opus 20% แล้วค่อยสลับไป Sonnet อัตโนมัติ

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

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

    • ก็จริง แต่จากประสบการณ์ผมเคยเจอปัญหาใหญ่จริง ๆ
      1. เวลาคนต้องกลับมาแก้การทดสอบที่สร้างไว้ทีหลัง มักมีหลุมพรางร้ายแรงซ่อนอยู่เยอะมาก
      2. Claude ไม่เข้าใจบริบทแวดล้อมดีพอ เลยชอบ mock แทบทุกอย่าง และสร้างการทดสอบที่ห่างไกลจากบริการจริง/สภาพแวดล้อมการ build ของทีมเราอย่างมาก
      3. และปัญหาที่ใหญ่กว่านั้นคือทั้งทีมจะเริ่มขี้เกียจเรื่องการทดสอบมากขึ้น
        สุดท้ายบั๊กใน production เพิ่มขึ้นอย่างชัดเจน