ยุคที่เขียนโค้ดทุกบรรทัดมันจบแล้ว

สิ่งที่คุณจะได้จากบทนี้:

1. เห็น 30% ที่ AI ยังทำให้ไม่ได้ และเข้าใจว่าทำไมมันถึงเป็นงานของคุณ
2. รู้จัก craft ใหม่ 5 อย่างที่ย้ายงานจากใช้แรงมือไปเป็นใช้สมอง
3. ตัดสินใจได้ว่างานไหนควร vibe งานไหนต้อง engineer ด้วยหลักประเมินขอบเขตความเสียหายเมื่อพัง
4. เข้าใจกฎข้อเดียวที่สรุปวินัยการใช้ AI ทั้งหมดจบในประโยคเดียว
5. เห็นภาพ Finance Tracker ที่จะสร้างด้วยกันตลอด 10 บท

---

1.1 30% ที่ AI ยังทำให้ไม่ได้

เช้าวันจันทร์ ticket "เพิ่ม auth ให้ admin panel" เด้งเข้ามาใน Jira

ถ้าเป็นปี 2020 งานแบบนี้กินเวลาอย่างน้อย 3 วัน ต้องออกแบบ schema, เขียน middleware, ทำระบบแฮช password, ทำ refresh token, เพิ่ม endpoint reset password แล้วปิดท้ายด้วยการเขียน test กับ doc

แต่ในปี 2026 คุณแค่เปิด Claude Code พิมพ์ spec ไปสามบรรทัด พอถึงบ่ายโมงครึ่ง PR ก็มารอ review บนจอแล้ว โค้ดสะอาด test ผ่านทุกเคส ลอง deploy ขึ้น staging ก็รันได้ไม่มีสะดุด ทุกอย่างดูเหมือนเสร็จเรียบร้อยแล้ว

แต่มันยังไม่เสร็จครับ มันแค่ดูเหมือนเสร็จเท่านั้น

ขึ้น production ไปสัปดาห์ถัดมา สองทุ่มตรง alert เด้งเข้ามาว่า endpoint /api/auth/login โดน brute force 40,000 request ต่อนาทีจาก IP เดียว สาเหตุคือ endpoint นี้ไม่มี rate limit ซึ่ง AI ไม่ได้ใส่ให้ตอนเขียน ไม่ใช่เพราะมันโง่ แต่เป็นเพราะคุณไม่ได้ระบุไว้ใน spec ตั้งแต่แรก

อีกเคสที่เจอบ่อยคือ migration ที่รันบน staging เสร็จในเวลา 200ms แต่พอย้ายไปรันบน production ที่มีข้อมูลอยู่ 50 ล้าน record กลับ lock table นานถึง 3 นาทีเต็ม ส่งผลให้ user ทุกคน checkout ไม่ได้ในช่วงนั้น ข้อมูลไม่ได้หายไปไหน แต่ความเชื่อมั่นของ user หายไปเยอะกว่าที่คิด

อีกเคสที่ยากกว่านั้นคือ race condition ที่เกิดระหว่าง 2 endpoint ซึ่งเขียนแยกกันคนละ session คนละ prompt ตอนทดสอบทีละตัวก็ทำงานได้สมบูรณ์ดี แต่พอถูกเรียกพร้อมกันในชีวิตจริง record ที่ควรมีแถวเดียวกลับมีถึงสามแถว สาเหตุคือ AI ไม่เห็นว่า endpoint อีกตัวก็เขียน table เดียวกันอยู่

ทั้งสามเคสนี้ไม่ได้เกิดขึ้นเพราะ AI โง่ ตรงกันข้ามเลย เพราะทุก function ที่เขียนออกมาล้วนถูกต้องในตัวของมันเอง สิ่งที่ AI ขาดไปคือภาพของระบบรวม มันไม่รู้ว่า product นี้มี user กี่คน ไม่รู้ว่า user จ่ายเงินตอนไหน ไม่รู้ว่าทีม ops ถนัดเครื่องมือตัวใด ไม่รู้ว่า legacy service เขียนด้วยภาษาอะไร และที่สำคัญที่สุดคือไม่รู้ว่าเมื่อเกิดปัญหาตอนตี 3 คนที่ต้องตื่นมาแก้คือใคร

AI ช่วยปิด 70% แรกของ feature ให้คุณได้ภายใน 30 นาที แต่อีก 30% ที่เหลือนั่นต่างหากที่เป็นเส้นแบ่งระหว่างโค้ดที่แค่รันได้ กับ product ที่อยู่บน production ได้จริง

30% ที่ว่านี้เองคือเรื่องที่เล่มนี้จะเล่า ไม่ใช่เพื่อให้คุณกลัว AI แต่เพื่อให้คุณใช้มันได้อย่างมั่นใจ และ ship ขึ้น production ได้โดยไม่ต้องลุ้น

งาน dev ในปี 2026 ไม่ได้หายไปไหน แค่ย้ายจากมือไปอยู่ที่สมองเท่านั้น

• จากที่เคยพิมพ์โค้ดให้เร็ว ก็กลายเป็นเขียน spec ให้คม
• จากที่เคยอ่าน Stack Overflow หา snippet ก็กลายเป็น review architecture diff ระดับลึก
• จากที่เคยนั่ง debug syntax error ก็กลายเป็นการ curate context ให้ AI จำบริบทของโปรเจคได้ข้ามวัน

ทักษะใหม่เหล่านี้ไม่ได้ผูกกับจำนวนปีประสบการณ์ แต่ผูกกับวินัยและความใส่ใจล้วนๆ

dev ที่ทำงานมาแค่ 2 ปีแต่ฝึก review มาตลอด อาจ ship production ได้มั่นคงกว่า dev 10 ปีที่ปฏิเสธไม่ยอมใช้เครื่องมือใหม่

และในทางกลับกัน senior ที่ปรับตัวได้ก็อาจ productive กว่าเดิมหลายเท่าได้ในปีเดียว เพราะ mental model ที่สะสมมาตั้งแต่ยุคไม่มี AI ยิ่งทำงานได้ดีขึ้นเมื่อมีเครื่องมือที่เร็วกว่าเดิมเข้ามาช่วย

ทุกวันนี้ AI coding tool กลายเป็นเครื่องมือที่ dev แทบทุกคนใช้กันหมดแล้ว แต่พอลองสังเกตผลลัพธ์ของแต่ละคน กลับเห็นว่า dev แบ่งออกเป็นสองกลุ่มที่ต่างกันอย่างชัดเจน

กลุ่มแรก ship feature ได้วันละ 3 ถึง 5 ตัวโดยไม่รู้สึกเหนื่อย สามารถ review AI diff ได้รวดเร็ว จับ bug ได้ตั้งแต่ตอนอยู่ใน PR

ใช้เวลาช่วงเช้าไปกับการเขียน prompt ช่วงบ่ายไปกับการ review และช่วงเย็นไปกับการปรับ CLAUDE.md เพื่อให้การทำงานร่วมกับ AI ในวันพรุ่งนี้ดีกว่าวันนี้

กลุ่มที่สองใช้ AI ตัวเดียวกัน ใช้ tool ชุดเดียวกัน แต่กลับรู้สึกล้นงานยิ่งกว่าตอนที่ยังไม่มี AI เสียอีก เพราะ AI เขียน code มาเร็วเกินกว่าที่จะ review ได้ทัน ทำให้ bug หลุดไป production บ่อยกว่าเคย เวลาส่วนใหญ่หมดไปกับการดับไฟมากกว่าการสร้างของใหม่ และสุดท้ายก็เริ่มสงสัยว่า AI ช่วยเขา หรือทำให้แย่ลงกันแน่

---

1.2 Craft ใหม่ที่ย้ายมาอยู่ที่สมอง

Craft ใหม่ที่ว่านี้ไม่ได้เริ่มจากการตั้งคำถามว่า AI ทำอะไรไม่ได้ แต่เริ่มจากการยอมรับก่อนว่ามันทำอะไรได้บ้าง

Claude Code ไม่ได้แค่เติมโค้ดบรรทัดถัดไปให้เหมือน autocomplete ทั่วไป แต่มันวางแผนได้ทั้ง flow ของ feature ตั้งแต่ออกแบบ database schema, เขียน API ครบทุก layer, ต่อ external service ไปจนถึงวาง infrastructure และ deploy ขึ้น production ได้จริง

ทั้งหมดนี้เริ่มจาก prompt เดียวในตอนเช้า และจบได้ในตอนเย็น งานที่เคยต้องใช้เวลาหลายสัปดาห์กว่าจะ implement ทุก layer เสร็จ ตอนนี้ทำจบได้ภายในบ่ายวันเดียว

คำถามต่อมาก็คือ แล้ว dev ยังมีงานทำไหม

คำตอบคือ งานมากกว่าเดิมอีกครับ เพราะสิ่งที่ AI ทำแทนไม่ได้นั้น ไม่ใช่ "การเขียน code" แต่เป็น "การตัดสินใจ" ต่างๆ ที่เกี่ยวข้องกับ code นั่นต่างหาก

Trade-off decisions AI วาง architecture ได้สวย แต่มันไม่รู้ว่า user ของคุณทน latency ได้กี่ ms ไม่รู้ว่าคุณยอมจ่ายค่า server ได้เดือนละเท่าไหร่ และไม่รู้ว่า product จะต้อง scale ถึงกี่คนในอีกสองปีข้างหน้า คำถามแบบนี้มีแต่คุณเท่านั้นที่ตอบได้

Edge case priority AI เขียน test ครอบคลุมได้ทุกเคส แต่มันไม่รู้ว่าเคสไหนสำคัญจริงสำหรับ business เคสไหนที่เกิดปีละครั้งปล่อยผ่านได้ และเคสไหนที่หากพังแม้แค่ครั้งเดียว user ก็หายหมด

Integration context AI ไม่รู้ว่าทีม ops ของคุณถนัด Kubernetes หรือ Docker Compose ไม่รู้ว่า legacy service ที่ต้อง integrate ด้วยนั้น เขียนขึ้นจาก PHP 5.6 และไม่รู้ว่าทีม data ต้องได้ payload ในรูปแบบไหน

Ownership เมื่อ product ล่มตอนตี 3 AI ไม่ใช่คนที่ถูกปลุกมาแก้ แต่คุณต่างหาก

ภาพรวมของวันทำงานก็เลยเปลี่ยนเป็นแบบนี้

งานไม่ได้ลดลง แค่ย้ายจากมือไปที่สมอง และสมองก็ไม่ได้ว่างลงเลย เพราะต้องคิดเร็วกว่าเดิม ตัดสินใจถี่กว่าเดิม และ review ลึกกว่าเดิม

Craft ใหม่ของ dev ยุคนี้มีทั้งหมด 5 อย่าง

1. Spec design อธิบาย feature ให้ AI เข้าใจจน output ถูกตั้งแต่ครั้งแรก ไม่ต้องมาแก้รอบสอง
2. Context curation AI จะเขียนได้ดีแค่ไหน ขึ้นอยู่กับ context ที่คุณป้อนให้ ทั้ง rule ใน CLAUDE.md และ example code ในโปรเจค
3. Architecture review เมื่อ AI เสนอ architecture มา คุณตัดสินว่าใช่หรือไม่ใช่ ต้อง trade-off อะไร และควรเปลี่ยนตรงไหน
4. Integration เชื่อม code ที่ AI สร้างเข้ากับ legacy system, production constraint และ team convention ที่มีอยู่เดิม
5. Guardrail ทั้ง security, permission, rate limit, error boundary ทุกอย่างที่ AI มักลืม คุณต้องเป็นคนคุม

Craft ทั้ง 5 นี้ต้องการคนที่เขียน code เป็น แต่ใช้เวลาไปกับการคิดมากกว่าการพิมพ์ ทั้งหมดเป็นทักษะที่สะสมมาจากการลงมือทำจริงและฝึกซ้ำ ไม่ใช่สิ่งที่ AI จะ replace ได้ในเร็ววันนี้

ต่อให้ Claude วาง code ให้ได้ครบทั้ง feature คุณก็ยังคงเป็นคนเดียวที่ตัดสินใจว่าจะ trade-off อะไรเพื่อให้ product ออกมาใช้งานได้จริง นี่คือ ownership ของคุณ และต่อให้ model รุ่นถัดไปจะเก่งขึ้นอีก 10 เท่า มันก็ยังเป็นของคุณอยู่ดี

---

1.3 หนังสือเล่มนี้จะพาไปดูอะไร

คำถามต่อมาที่หลายคนน่าจะสงสัยคือ "แล้วจะฝึก craft ทั้ง 5 นี้ได้จากไหน" เล่มนี้ไม่ใช่ tutorial ที่ copy-paste ตามได้จบในบ่ายเดียว เพราะแต่ละโปรเจคมี context ต่างกัน จะใช้สูตรเดียวครอบจักรวาลไม่ได้ เล่มนี้จึงเป็น field guide ที่จะพาคุณสร้างแอปจนขึ้น production ไปด้วยกันจริงๆ ตลอด 10 บท

ทุก pattern ในเล่มไม่ได้มาจากทฤษฎี แต่มาจากการลงมือ build โปรเจค production ด้วย Claude Code ตลอด 12 เดือน ตั้งแต่ scaffold แรกจนถึงวันที่ user เข้ามาใช้งานจริง

ระหว่างทางก็เจอ mistake มาเยอะมาก บางครั้ง code ที่ AI เขียนออกมาต้องลบทิ้งยกชุด บางครั้ง prompt ผิดพลาดเสียเวลาไปทั้งวัน และบางครั้งก็ไว้ใจ AI มากเกินไปจนเจอ bug โผล่ใน production อีกสองสัปดาห์ให้หลัง

สิ่งที่คุณจะได้อ่านในเล่มนี้คือ pattern ที่ผ่านการลองผิดลองถูกมาแล้วทั้งหมด ไม่ใช่ทฤษฎีบนกระดาษที่ยังไม่เคยได้ลงมือใช้

แอปที่จะสร้างด้วยกันชื่อ Finance Tracker เป็นแอปจัดการการเงินส่วนตัวผ่าน LINE ที่มี AI ช่วย categorize รายการให้อัตโนมัติ รายละเอียดของแอปอยู่ใน section 1.8 แต่ที่อยากบอกไว้ก่อนคือแอปนี้ครอบคลุมทุกมิติของงาน dev ยุคนี้ ตั้งแต่ frontend dashboard, backend API, database schema, external integration และ AI integration ไปจนถึงการ deploy ขึ้น production ได้จริง

อะไรที่คุณจะเลิกทำ

• เขียน CRUD boilerplate ด้วยมือทีละ endpoint
• เขียน test ทีละบรรทัดจนครบ happy path
• Debug syntax error ที่ลืม semicolon หรือ bracket ไม่ปิด
• Google Stack Overflow เพื่อหา snippet เล็กๆ
• เขียน Dockerfile จากศูนย์ทุกครั้ง

อะไรที่คุณจะเริ่มทำ

• เขียน spec ที่คมจน AI ตีความไม่ผิดตั้งแต่ prompt แรก
• Curate CLAUDE.md ให้ AI "จำ" convention ของโปรเจคได้ข้ามวัน
• Review diff ระดับ architecture ไม่ใช่ระดับ syntax
• คุยกับ AI เรื่อง trade-off แล้วเถียงชนะด้วยเหตุผล
• ตัดสินใจเรื่อง business, security, cost ที่ AI แตะไม่ได้

ลองมองภาพรวมของลิสต์สองฝั่งด้านบนอีกครั้ง จะเห็นว่า 80% ของสิ่งที่ dev ใช้เวลาสะสมมาหลายปีถูกย้ายไปอยู่ในมือ AI หมดแล้ว ในทางกลับกัน สิ่งที่ทำให้ product ใช้งานได้จริงกลับย้ายมาอยู่ที่ spec และ context ที่คุณป้อนให้ AI เสียเกือบทั้งหมด

ด้วยเหตุนี้ ทักษะสำคัญที่สุดของ dev ในปี 2026 จึงไม่ใช่การพิมพ์ code ให้เร็ว แต่เป็นการอธิบายสิ่งที่ต้องการให้ AI เข้าใจได้ชัดตั้งแต่ prompt แรก

เล่มนี้แบ่งเป็น 5 ภาค 10 บท แต่ละบทมี workshop ที่ต่อจากบทก่อนหน้า พออ่านจบคุณจะได้แอปที่ live อยู่บน internet จริง รับ message จาก LINE ได้ และมี AI ช่วย categorize รายการให้อัตโนมัติ

---

1.4 พื้นฐาน Dev ยังสำคัญ (มากขึ้นด้วย)

ช่วงนี้เห็นคนพูดกันในอินเทอร์เน็ตบ่อยว่า "ไม่ต้องเรียน dev แล้ว AI ทำให้หมด" ซึ่งจริงแค่ครึ่งเดียวเท่านั้น ถ้าคุณแค่อยากสร้าง prototype ไว้ใช้เอง หรือเขียน script จัดไฟล์ในเครื่อง การข้ามพื้นฐานไปเลยก็ทำได้สบาย แต่ถ้าตั้งใจจะ ship ออกไปให้คนอื่นใช้จริง เรื่องจะเปลี่ยนไปทันที

เคสที่คุณอาจได้ยินมาแล้ว

เดือนกรกฎาคม 2025 Jason Lemkin ผู้ก่อตั้ง SaaStr ซึ่งเป็น conference ใหญ่ที่สุดในวงการ SaaS ได้ทดลอง vibecoding กับ Replit AI agent ต่อเนื่อง 12 วัน พอถึงวันที่ 9 AI agent ก็รัน destructive command ลบฐานข้อมูล production ทิ้งทั้งหมด ทำให้ข้อมูล executive 1,206 คน และ company 1,196 แห่ง หายเรียบไปในครั้งเดียว

ที่แย่ยิ่งกว่านั้นคือ AI ยังสร้างข้อมูลปลอมขึ้นมากว่า 4,000 records มาแทนที่ข้อมูลเดิม แล้วยังบอก Lemkin อีกว่า rollback ทำไม่ได้ ทั้งที่ความจริงทำได้

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

ทำไม AI ยังต้องการคนคุม

AI เขียน code เก่งขึ้นทุกเดือน แต่มีสองจุดที่มันยังทำแทนไม่ได้

มันไม่เข้าใจระบบรวม Addy Osmani จาก Google อธิบายว่า AI ทำงานผ่านสิ่งที่เรียกว่า "local pattern recognition" คือมันเห็นแค่ context ตรงหน้าเท่านั้น ผลคือมันอาจเขียน function ที่สมบูรณ์ในตัวของมันเอง แต่กลับทำให้ระบบพังลงได้ เพราะมันไม่รู้ว่ายังมีอีก 5 จุดในโปรเจคที่ depend กับ function ตัวเดิมอยู่

มันไม่รู้ว่าอะไรสำคัญจริง code ที่ผ่าน test ทุกเคสไม่ได้แปลว่าพร้อมใช้จริงเสมอไป เพราะถ้า test case ไม่ครอบคลุม edge case ที่สำคัญของ product ถึง code จะผ่าน test ก็ยังพังใน production อยู่ดี

ตัวเลขจาก CodeRabbit เดือนธันวาคม 2025 ยืนยันเรื่องนี้ โดยพบว่า AI-generated code มี major issues มากกว่า code ที่คนเขียนเอง 1.7 เท่า และมี security vulnerability มากกว่าถึง 2.74 เท่า ไม่ใช่เพราะ AI โง่ แต่เพราะ AI ไม่รู้ว่า input ตัวไหนต้อง sanitize เป็นพิเศษสำหรับ domain ของคุณ

แล้วต้องมีพื้นฐานอะไรบ้าง

ข่าวดีคือคุณไม่ต้องเป็น senior 10 ปีก็ vibecoding ได้ ขอแค่มีสิ่งเหล่านี้

• ใช้ terminal หรือ command line ได้ในระดับ cd, ls, git พื้นฐาน
• เข้าใจ HTTP request/response รู้จัก GET, POST และ status code 200/400/500
• อ่าน JavaScript หรือ TypeScript รู้เรื่อง เขียนเองไม่ได้ทั้งหมดก็ไม่เป็นไร แต่ต้องอ่านแล้วเข้าใจ
• เข้าใจ concept ของ database ระดับ table, relation, query และ index
• ใช้ git ได้ระดับ commit, branch, merge และ rebase เบื้องต้น
• Debug ได้ อ่าน error message แล้วเดาทิศของปัญหาออก

ถ้ามีครบทั้งหมดนี้ คุณก็พร้อมลุย vibecoding ได้เลย ที่เหลือเราจะค่อยๆ เรียนรู้กันในบทถัดๆ ไป

ถ้าคุณอ่าน code ที่ AI เขียนมาไม่รู้เรื่อง นั่นไม่ได้ช่วยประหยัดเวลา แต่คือการปล่อยให้ AI ตัดสินใจแทนคุณ ทั้งที่ AI ไม่รู้ว่าอะไรสำคัญจริงสำหรับ product ของคุณ ผลคือ technical debt จะค่อยๆ สะสม แล้ววันหนึ่งก็จะระเบิดใน production ในจังหวะที่คุณไม่ทันตั้งตัว

---

1.5 เหมาะกับงานไหน ไม่เหมาะกับงานไหน

ไม่ใช่ทุกงานจะต้องการ review ในระดับเดียวกัน

Addy Osmani เป็นผู้เขียนหนังสือ "Beyond Vibe Coding" ของ O'Reilly และเป็น Engineering Lead ที่ Google เขาแบ่งการใช้ AI เขียน code ออกเป็นสอง mode โดยทั้งสอง mode ใช้ tool ตัวเดียวกัน แต่มี discipline คนละแบบ

Vibe Coding สร้างเร็ว review น้อย ใช้กับงานที่พังแล้วไม่เจ็บ

AI-Assisted Engineering สร้างเร็วเหมือนกัน แต่มี design, review และ testing เข้มงวดเหมือน code ที่คุณเขียนเอง

แนวคิด "30% ที่ AI ยังทำให้ไม่ได้" ที่ปรากฏใน section 1.1 นั้น จริงๆ แล้วคือแนวคิดเดียวกับที่ Osmani เรียกว่า "The 70% Problem" ซึ่งมาจากการที่เขาสัมภาษณ์ CTO จำนวน 18 คน และพบว่ามีถึง 16 คนที่เคยเจอ production disaster จาก AI code ที่ ship ออกไปโดยไม่ review

ประเด็นคือ AI ช่วยทำให้ 70% แรกของงานเร็วขึ้นได้แบบมหาศาล แต่อีก 30% ที่เป็นเส้นแบ่งระหว่าง "โค้ดที่ทำงานได้" กับ "โค้ดที่ผ่าน production ได้จริง" ก็ยังเป็นงานของ dev อยู่ดี

หลักตัดสินใจ: Blast radius (ขอบเขตความเสียหายเมื่อพัง)

Blast radius เป็นคำจากวงการ SRE หมายถึงถ้า code นี้พัง มันจะสร้างความเสียหายแผ่ออกไปวงกว้างแค่ไหน ยิ่งวงกว้าง ยิ่งต้องใช้ mode ที่เข้มขึ้น

ลองถามตัวเอง 3 ข้อก่อนเลือก mode

1. ถ้า code นี้พังตอนตี 3 คุณต้องตื่นมาแก้ไหม
2. Bug ใน code นี้ทำให้ user เสียเงิน เสียข้อมูล หรือเสีย trust ไหม
3. Code นี้ต้อง maintain ต่อไปอีกกี่ปี

ถ้าตอบ "ใช่" แม้เพียงข้อเดียว คุณอยู่ใน engineer mode

Vibe zone ship เร็ว review เบา

• MVP, prototype, hackathon demo
• Internal tool ที่มีคนใช้ 5 ถึง 10 คน
• CRUD, boilerplate, scaffold ของ feature ใหม่
• UI component ที่ไม่ handle money หรือ PII (ข้อมูลส่วนบุคคล)
• Test, docs, migration script
• Throwaway script หรือ one-off analysis

Engineer zone ship เร็วเหมือนกัน แต่ review เข้ม

• Code ที่เกี่ยวกับเงิน เช่น payment, billing, invoice, refund
• Authentication, authorization, session, permission
• Business logic ที่มีหลาย edge case
• Database migration ที่กลับไม่ได้
• Performance-critical hot path
• Code ที่ regulated เช่น medical, finance, legal, healthcare

จุดที่ต้องเข้าใจคือ ที่เล่ามาทั้งหมดนี้ไม่ได้หมายความว่า "ห้ามใช้ AI กับงาน critical" แต่หมายความว่า "ถ้าใช้ AI กับงาน critical ต้อง review ให้เข้มขึ้น" เหมือนกับ PR ทุกตัวที่จะ merge เข้า main ก็ต้องผ่าน code review อยู่แล้ว ไม่ต่างกันเลย

Finance Tracker ที่จะสร้างในเล่มนี้เองก็อยู่ก้ำกึ่งตรงกลางของสอง mode บางส่วนสามารถ vibe ได้ เช่น dashboard, chart และ UI form แต่บางส่วนต้อง engineer อย่างจริงจัง เช่น การ verify signature ของ LINE webhook, การบันทึกรายจ่าย และส่วน AI analysis ที่ต้องรัน prompt ของคุณบน user จริง

ในเล่มนี้จะชี้ให้เห็นทุกครั้งเมื่อถึงจังหวะที่ต้องสลับ mode

---

1.6 เส้นแบ่งของ Simon Willison

ในวงการ AI-assisted coding มีคนเขียนเรื่องนี้ไว้ลึกซึ้งหลายคน แต่คนที่เขียนได้คมที่สุดคงหนีไม่พ้น Simon Willison

Willison เป็น co-creator ของ Django มาตั้งแต่ปี 2005 และเป็นคนที่บัญญัติคำว่า "prompt injection" ขึ้นในปี 2022 ซึ่งกลายเป็นคำศัพท์มาตรฐานของวงการ AI security ในปัจจุบัน เขาเขียน blog เรื่อง LLM ทุกสัปดาห์มาตั้งแต่ก่อนที่คำว่า vibecoding จะถือกำเนิดขึ้นเสียอีก อ่านแล้วได้ความรู้เหมือนอ่าน docs ที่เขียนโดยคนที่ใช้งานจริงทุกวัน

Willison แบ่ง AI-assisted coding ออกเป็นสองแบบที่ชัดเจน

Vibe coding คือ "building software with an LLM without reviewing the code it writes" หรือการสร้างซอฟต์แวร์ร่วมกับ AI โดยไม่ review code ซึ่งใช้ได้กับของเล่นหรือ throwaway project เท่านั้น

Responsible AI-assisted programming คือการให้ AI เขียน code แต่คุณ review ทุกบรรทัด ทำ test อย่างละเอียด และอธิบายได้ว่า code ทำอะไร

สิ่งที่ทำให้ Willison ต่างจากคนอื่นคือ เขามีกฎเพียงข้อเดียวที่ตัดทุกเรื่องให้จบ

"I won't commit any code to my repository if I couldn't explain exactly what it does to somebody else"

ห้าม commit code ใดๆ เข้า repo ถ้าอธิบายให้คนอื่นฟังไม่ได้ว่ามันทำอะไร

— Simon Willison

กฎข้อนี้ฟังดูเรียบง่าย แต่ถ้ายึดถือจริง มันจะเปลี่ยนวิธีใช้ AI ทันที เพราะมันจะบังคับให้คุณ

• อ่าน diff ทุกครั้ง ไม่กด accept ไปเรื่อยๆ
• ถามกลับเมื่อ code ทำสิ่งที่คุณไม่เข้าใจ
• Refactor ให้อ่านง่ายขึ้น ถ้า AI เขียนซับซ้อนเกินจำเป็น
• ไม่ merge ต่อให้ test ผ่าน ถ้ายังอธิบายไม่ได้

Spectrum ของ AI-assisted coding

ลองวาดเส้นการใช้ AI ออกมาเป็น spectrum ดู

ซ้ายสุดคือ Pure vibe ปล่อย AI เขียนเต็มที่ ไม่อ่าน code เลย เหมาะกับ throwaway เท่านั้น

ขวาสุดคือ Manual only เขียนเองทุกบรรทัด ไม่ใช้ AI เลย ช้าแต่ own ทุกบรรทัด

ตรงกลางคือ Responsible AI-assisted AI เขียน คุณ review คุณเข้าใจ และคุณ own

หนังสือเล่มนี้สอนให้คุณยืนที่ช่วง responsible เป็นหลัก แล้วเลื่อนไปทางซ้ายเมื่อเจองาน blast radius ต่ำเพื่อความเร็ว และเลื่อนไปทางขวาเมื่อเจองาน blast radius สูงเพื่อความปลอดภัย ไม่ว่าจะอยู่จุดไหนของ spectrum กฎของ Willison ก็ยังใช้ได้ในทุกกรณี ถ้าอธิบายไม่ได้ อย่า commit

---

1.7 ทำไมเล่มนี้เลือก Claude Code

ถ้าคุณใช้ Cursor, Windsurf, Copilot Agent Mode, Bolt, Lovable หรือ Replit AI อยู่แล้วและรู้สึกว่าเวิร์ค คำถามแรกที่ควรถามคือ "แล้วเปลี่ยนมาทำไม"

คำตอบตรงๆ คือไม่จำเป็นต้องเปลี่ยน เพราะ concept ทั้งหมดในเล่ม ไม่ว่าจะเป็น CLAUDE.md pattern, spec design, context curation ไปจนถึง MCP และ subagent สามารถนำไปใช้กับ tool ตัวไหนก็ได้

เล่มนี้ไม่ได้ตั้งใจจะขาย Claude Code ให้คุณ เหตุผลที่เลือก Claude Code มาเป็น tool หลักของเล่ม เป็นเรื่องของ workflow จริงที่ใช้งานมา มากกว่าจะเป็นการ benchmark ทางเทคนิค

จากการสลับใช้ GPT, Gemini, DeepSeek และ Claude ในงานจริงหลายโปรเจคตลอด 12 เดือนที่ผ่านมา ข้อสรุปที่ได้ตรงกันทุกครั้งคือ Claude แม่นที่สุดในงาน coding ระดับ production เพราะเข้าใจ codebase ขนาดใหญ่ได้ลึก และคิด trade-off ระหว่าง design option ต่างๆ ได้ชัดเจนกว่าตัวอื่น

benchmark ทั่วไปสับเปลี่ยนอันดับกันทุกไตรมาสจนยากจะใช้อ้างอิง แต่ถ้าต้องเลือก coding model เพียงตัวเดียวไปใช้ทั้งปี ณ เวลาที่เขียนเล่มนี้ คำตอบก็ยังคงเป็น Claude อยู่

อีกจุดที่สำคัญไม่แพ้กันคือ Claude Code รันจาก terminal เหมือนกับที่คุณใช้ git, vim และ docker อยู่แล้วทุกวัน ไม่ต้องเปลี่ยน editor ไม่ต้องติดตั้ง IDE พิเศษ จะ ssh ขึ้น server แล้วเปิดใช้ก็ได้ทันที จะใช้ใน terminal ของ VS Code ก็ได้ หรือใน tmux ก็ได้เช่นกัน

ข้อดีที่คนมักมองข้ามคือ การที่มันรันบน terminal หมายความว่าคุณสามารถ pipe output, redirect และต่อกับ unix tool ตัวอื่นได้ทุกอย่าง ซึ่งตรงกับ workflow เดิมของ dev สาย CLI โดยที่ไม่ต้องเรียนรู้อะไรใหม่เลย

Claude Code ยังทำงานเป็น agent เต็มตัว ไม่ใช่แค่ autocomplete ที่คอยเติม code ให้ทีละบรรทัด มันทำได้ทั้งอ่านไฟล์, แก้ไฟล์, สร้างไฟล์, รัน command, ทำ git commit และ git push, ต่อเข้า MCP server, ต่อ external service รวมถึงปิดงานครบทั้ง feature จาก prompt เดียวได้ สั่งให้ทำงานไว้แล้วเดินไปซื้อกาแฟ กลับมาก็เจอ PR รอ review ได้จริง

ecosystem รอบๆ ก็ครบถ้วน และแต่ละตัวก็ตอบโจทย์ปัญหาจริงของ dev ซึ่งจะค่อยๆ เจาะลึกตลอดทั้งเล่ม

• CLAUDE.md สอน AI ให้จำโปรเจคของคุณได้ข้าม session (บท 4)
• Commands + Skills ย่อ workflow ที่ทำซ้ำให้เป็น shortcut (บท 4 และ 10)
• MCP มาตรฐานสำหรับเชื่อม external tool เช่น database, GitHub, LINE (บท 7)
• Subagents + Agent Teams แบ่งงานใหญ่ให้ agent หลายตัวทำพร้อมกัน (บท 8)
• Hooks รัน script อัตโนมัติก่อนหรือหลัง action ของ AI (บท 10)
• Plugins แบ่งปัน workflow ที่คุณสร้างขึ้นกับทีม (บท 10)

รวมๆ กันแล้วมันจึงไม่ใช่ "AI ที่เขียน code ได้" แต่เป็น development platform ที่ปรับแต่งให้เข้ากับทีมและโปรเจคได้

3 Models ของ Claude

เลือกให้เหมาะกับงาน

ในเล่มนี้จะใช้ Sonnet เป็นหลัก เพราะเป็น sweet spot ระหว่าง "เก่งพอ" กับ "ใช้คล่อง" และจะสลับเป็น Opus เมื่อต้องทำงานซับซ้อนหรือออกแบบ architecture

Claude Code เข้าใช้งานได้หลาย platform ไม่ว่าจะเป็น terminal, extension ของ VS Code และ JetBrains, desktop app, web ที่ claude.ai/code หรือจะสั่งงานจากมือถือผ่าน mobile app ก็ได้ แต่ในเล่มนี้จะโฟกัสที่ terminal เป็นหลัก เพราะเป็นแบบที่ใช้ feature ได้ครบที่สุด

---

1.8 แอปที่เราจะสร้างด้วยกัน

แอปที่จะสร้างด้วยกันชื่อ Personal Finance Tracker เป็นแอปจัดการการเงินส่วนตัวผ่าน LINE ที่ build ด้วย Claude Code ตั้งแต่คำสั่ง pnpm create ในบรรทัดแรก ไปจนถึง docker compose up -d บน production

เหตุผลที่เลือกแอปนี้แทน todo list คือหนังสือสอน programming ส่วนใหญ่มักให้สร้าง project ที่ใช้ครั้งเดียวแล้วทิ้งหลังอ่านจบ ซึ่งน่าเสียดายตรงที่ทักษะที่เพิ่งฝึกมาไม่ได้ติดมือไปเป็นของใช้จริง แต่แอปนี้คุณจะได้ใช้จริงทุกวันหลังอ่านจบ และที่สำคัญกว่านั้นคือมันครอบคลุมทุก skill ของ dev ยุคนี้

• Frontend dashboard + chart + form สำหรับฝึก prompt สร้าง UI
• Backend REST API + auth + cron job สำหรับฝึกให้ AI ออกแบบ layer logic
• Database schema design + migration + query สำหรับฝึก data modeling ผ่าน AI
• External API LINE Messaging สำหรับฝึกอ่าน 3rd party doc แล้วสั่ง AI integrate
• AI integration Claude API ช่วย categorize รายการอัตโนมัติ สำหรับฝึกสร้าง AI-powered feature ใน product
• DevOps Docker + VPS + Cloudflare Tunnel สำหรับฝึก deploy production จริง

และนี่คือสิ่งที่แอปจะทำได้เมื่อสร้างเสร็จ

บันทึกรายรับรายจ่ายผ่าน LINE

แค่พิมพ์ใน LINE ที่ใช้อยู่ประจำ ไม่ต้องเปิดแอปอื่นให้ยุ่งยาก ลองพิมพ์ "กาแฟ 65" ดู ระบบจะ parse ให้เองและตอบกลับมาว่า "บันทึกแล้ว: กาแฟ 65 บาท (อาหาร)"

รายรับก็เช่นเดียวกัน ลองพิมพ์ "เงินเดือน 45,000" ระบบจะแยกเป็นรายรับให้โดยอัตโนมัติ หรือจะพิมพ์ "สรุป" เพื่อดูยอดวันนี้ พิมพ์ "เดือนนี้" เพื่อดูยอดทั้งเดือน หรือพิมพ์ "ยกเลิก" เพื่อลบรายการล่าสุดก็ได้ ทุกอย่างเกิดขึ้นในบทสนทนาเดียว ไม่ต้องจำ form ไม่ต้องเปิด UI ให้เสียเวลา

Dashboard ภาพรวมการเงิน

เปิด browser ขึ้นมาก็จะเห็นสรุปรายรับ-รายจ่ายของเดือน, pie chart แยกตามหมวดทั้งฝั่งรายรับและรายจ่าย, bar chart รายวัน และรายการ transactions ล่าสุดในหน้าเดียว มี month picker ให้เลือกย้อนดูเดือนเก่าได้ ส่วนหน้า Transactions ก็ filter ตามหมวด ช่วงวันที่ และประเภท (รายรับ/รายจ่าย) ได้ตามต้องการ

ตั้งงบรายเดือน

หน้า Budget จะรวบหมวดทั้งหมดของเดือนนั้นไว้ให้ พร้อมปุ่ม "+ ตั้งงบ" ให้กดตั้งเป็นรายหมวดได้ตามต้องการ เมื่อตั้งแล้วระบบจะคำนวณยอดใช้จ่ายของเดือนนั้นเทียบกับงบให้เป็น progress bar อัตโนมัติ

AI ช่วย categorize ให้อัตโนมัติ

ตอนพิมพ์ "กาแฟ 65" หรือ "ค่าทางด่วน 80" ใน LINE ระบบไม่ได้ใช้ keyword mapping ที่ต้องมานั่ง maintain เอง แต่ส่งให้ Claude API ตัดสินใจว่ารายการนี้ควรเข้าหมวดไหน คำใหม่ๆ ที่ไม่เคยเห็นก็จัดได้ทันที โดยที่เราไม่ต้องแก้ code

Deploy บน VPS ของตัวเอง

Vercel, Netlify และ Railway เป็นตัวเลือกที่ดีมากถ้าอยาก ship ให้เร็วโดยไม่ต้องคิดเรื่อง infrastructure เลย และเป็นตัวเลือกที่ทีม product ส่วนใหญ่ก็เลือกใช้ แต่สำหรับ solo dev หรือโปรเจคส่วนตัวที่อยาก control cost ในระยะยาว VPS เป็นทางเลือกที่เหมาะกว่า เพราะ Hetzner CPX22 อยู่ที่ประมาณ $5 ถึง $13 ต่อเดือนแบบคงที่ ในขณะที่ managed platform จะคิดเงินตาม bandwidth หรือ function invocation ซึ่ง scale ตาม traffic

เล่มนี้จึงเลือกใช้ Hetzner VPS ร่วมกับ Cloudflare Tunnel ที่ได้ HTTPS และ DDoS protection แบบฟรีๆ บวกกับ Docker Compose ด้วยสองเหตุผลหลัก เหตุผลแรกคือ cost ที่คำนวณได้แน่นอน เหตุผลที่สองคือได้เห็นทุก layer ด้วยตัวเอง ตั้งแต่ระดับ OS ไปจนถึง HTTPS handshake ซึ่งเป็นความรู้ที่ติดตัวไปตลอด ไม่ว่าจะย้าย platform กี่ครั้งก็ยังใช้ได้อยู่ดี

Tech stack

• Frontend Vite + React + Tailwind
• Backend NestJS
• Database PostgreSQL + Prisma
• External API LINE Messaging API + Claude API
• Infrastructure Hetzner VPS + Cloudflare Tunnel + Docker Compose
• Repo pnpm monorepo (frontend + backend + shared types)

ทุกบรรทัดของแอปนี้สร้างด้วย Claude Code ตั้งแต่ prompt แรกจนถึงตอนขึ้น production เล่มนี้จะเล่าทั้ง prompt ทุกตัวที่ใช้, mistake ทุกครั้งที่เจอ, และ review ทุกครั้งที่พบจุดเสีย เพื่อให้คุณเห็นกระบวนการของจริง ไม่ใช่แค่ output ที่สำเร็จแล้วเท่านั้น

---

1.9 สรุป

งาน dev ในยุค AI ย้ายจากมือไปที่สมอง และ craft ใหม่ที่เข้ามาแทนที่ก็น่าสนใจไม่แพ้ craft เก่า ถ้าลงลึกกับมันจริงๆ

บทนี้ได้วางกรอบที่จะใช้ตลอดเล่มไว้ 4 เรื่อง

• 30% ที่ AI ยังทำให้ไม่ได้ คืองานของคุณ AI จบ 70% แรกได้ใน 30 นาที แต่ 30% ที่เหลือคือเส้นแบ่งระหว่างโค้ดที่แค่รันได้ กับ product ที่อยู่บน production ได้จริง
• งาน dev ย้ายจากมือไปที่สมอง ผ่าน craft ใหม่ 5 อย่าง ได้แก่ spec design, context curation, architecture review, integration และ guardrail
• Blast radius ตัดสินระหว่าง vibe กับ engineer ถามตัวเอง 3 คำถามก่อนเลือก mode ถ้าตอบ "ใช่" แม้เพียงข้อเดียว คุณอยู่ใน engineer zone ต้อง review เข้ม
• ถ้าอธิบายไม่ได้ อย่า commit กฎของ Simon Willison ที่ตัดทุกเรื่องจบในประโยคเดียว

ถ้าคุณยึด 4 ข้อนี้เอาไว้ การใช้ AI ของคุณจะไม่ใช่ vibe แบบเจ็บตัว แต่จะเป็น vibe แบบที่คุมได้

บทถัดไปจะพาคุณก้าวจาก idea ไปสู่ architecture จริง โดยจะไปดูว่า Finance Tracker ประกอบด้วย 6 layer อะไรบ้าง ทำไมถึงเลือก stack ชุดนี้แทนตัวอื่น และ Claude Code จะช่วยคุณสร้างขึ้นมาตั้งแต่ prompt แรกจนถึง production ได้อย่างไร