Agentic Workflow 5 ขั้น — Explore · Plan · Code · Evaluate · Commit

Next.js     16.3.5 (Turbopack)   # npx next --version → Next.js v16.3.5
react       19.2.8
typescript  5.9.3
eslint      9.39.5
tailwindcss 4.3.3
node        v24.14.0
git         2.51.0

Agentic workflow คืออะไร

สไลด์หน้า 12 นิยามไว้ประโยคเดียว:

แปลเป็นภาษาคน: ให้ AI ทำงานหลายขั้นต่อกันเองได้ — ไม่ใช่ถามหนึ่งคำ ตอบหนึ่งก้อน แล้วคุณเอาไปก็อปวางเอง
แต่เป็น AI ที่คิด (reasoning) · วางแผน (planning) · หยิบเครื่องมือมาใช้เอง (tool use — เปิดไฟล์ · ค้นโค้ด · รันคำสั่งใน terminal) แล้วปรับตัวตามผลที่ได้ (dynamically — รันแล้ว error ก็อ่าน error แล้วแก้ต่อ)

สไลด์หน้าเดียวกันวาดขั้นตอนนั้นไว้เป็น 5 กล่องเรียงกัน เริ่มจากคำขอของผู้ใช้ (ตัวอย่างในสไลด์คือ "Add dark mode to the app") แล้วมีเส้นประย้อนกลับจากขั้นที่ 4:

เส้นล่างสุดคือหัวใจของทั้งบท — Evaluate ไม่ผ่าน ห้ามเดินหน้าไป Commit ต้องย้อนกลับไปแก้ แล้วตรวจใหม่ทั้งชุด วนจนกว่าจะผ่าน

ภาพในสไลด์หน้า 12 มีหัวเรื่องว่า “AGENTIC WORKFLOW by Claude Code” พร้อมคำโปรยว่า “Claude Code works like an agent that understands your goal, thinks, acts, and delivers production-ready changes.” — Claude Code ทำงานเหมือน agent ที่เข้าใจเป้าหมาย คิด ลงมือ แล้วส่งงานที่พร้อมใช้จริง · แต่ละกล่องมีคำสรุปสั้น ๆ ใต้ชื่อขั้น (ถอดตามจริง):

แถวล่างของภาพชื่อ WHY THIS WORKS สรุปว่าทำไมห้าขั้นนี้ได้ผล: Context First (Understand deeply before changing anything) · Planned Execution (Reduce mistakes by thinking ahead) · Iterative Improvement (Continuously refine until it's right) · Quality Focused (Evaluation ensures reliability and maintainability) · Transparent & Reviewable (Clear plan, clean diff, meaningful commits)
และปิดท้ายว่า “Explore → Plan → Code → Eval → Commit — Claude Code follows this agentic workflow to ship better software, faster.”

ขั้น 1 · Explore — เก็บบริบทก่อนแตะอะไร

สไลด์หน้า 14 มีสามข้อ (ถอดตามจริง):

• “Like a researcher, gather context before touching anything.” — ทำตัวเป็นนักวิจัย เก็บบริบทก่อนแตะอะไรทั้งนั้น
• “Read the relevant files, search the codebase, understand existing patterns, conventions, and dependencies.” — อ่านไฟล์ที่เกี่ยว ค้นทั้งโปรเจกต์ ทำความเข้าใจแพตเทิร์น ธรรมเนียมการเขียน และของที่พึ่งพากันอยู่
• “The goal is a mental model of what exists and how it works, not writing code yet.” — เป้าหมายคือภาพในหัวว่ามีอะไรอยู่แล้วและมันทำงานยังไง ยังไม่ใช่การเขียนโค้ด

diagram หน้า 12 แตกเป็นรายการงานย่อย: Read README and docs · Explore project structure · Search for relevant files and code · Understand existing patterns and conventions · Review tests and configs · เป้าหมาย: Build a mental model of the project.

ลองกับงานจริง: “เพิ่มปุ่มสีเขียวสำหรับสถานะสำเร็จ”

ก่อนแก้อะไร ผมเปิดโปรเจกต์ดูสี่คำถาม — Button อยู่ไหน · variant ที่มีอยู่แล้วเขียนแบบไหน · สีมาจากไหน · มีใครใช้ Button อยู่แล้วบ้าง (จะได้รู้ว่าแก้แล้วกระทบใคร):

$ ls components/ui
badge.tsx
button.tsx
card.tsx
skeleton.tsx

$ grep -n "variant" components/ui/button.tsx
8:    variants: {
9:      variant: {
36:      variant: "default",
44:  variant = "default",
51:      className={cn(buttonVariants({ variant, size, className }))}

$ grep -n "destructive" app/globals.css
29:  --color-destructive: var(--destructive);
66:  --destructive: oklch(0.577 0.245 27.325);
101:  --destructive: oklch(0.704 0.191 22.216);

$ grep -rn "components/ui/button" app components; echo "rc=$?"
rc=1

สี่บรรทัดคำสั่งนี้ให้ภาพในหัวครบพอจะวางแผนได้:

• variant ของ Button เป็นรายการใน cva(...) — มี default · outline · secondary · ghost · destructive · link แต่ละตัวคือสตริง class ของ Tailwind · แปลว่าเพิ่ม variant = เพิ่มหนึ่งบรรทัดในรายการนี้
• สีไม่ได้เขียนตรง ๆ เช่น bg-red-600 แต่ใช้ชื่อสี (token) อย่าง bg-destructive ซึ่งไปโยงกับตัวแปร CSS ใน app/globals.css สองชุด — บรรทัด 66 สำหรับโหมดสว่าง · บรรทัด 101 สำหรับโหมดมืด · นี่คือ convention ของโปรเจกต์ ถ้าเราเขียน bg-green-600 ตรง ๆ โค้ดก็ทำงาน แต่จะผิดธรรมเนียม และโหมดมืดจะไม่เปลี่ยนสีตาม
• rc=1 ของ grep แปลว่าไม่เจอเลย — ยังไม่มีไฟล์ไหน import Button · เพิ่ม variant ใหม่จึงไม่มีทางทำหน้าเดิมพัง

และอีกสองไฟล์ที่ควรเปิดในขั้นนี้เสมอ: package.json (สคริปต์ที่มีคือ dev · build · start · lint — ไม่มี test ขั้น Evaluate จึงต้องพึ่ง type-check · lint · build) และ AGENTS.md ที่ create-next-app รุ่นนี้สร้างมาให้ ซึ่งเขียนเตือน agent ไว้ตรง ๆ ว่า “This is NOT the Next.js you know” ให้ไปอ่านเอกสารใน node_modules/next/dist/docs/ ก่อนเขียนโค้ด — ไฟล์นี้มีไว้ให้ agent อ่านในขั้น Explore โดยเฉพาะ

# คำขอตัวอย่างในสไลด์หน้า 12
"Add dark mode to the app"

# ถ้า agent ข้าม Explore แล้วเริ่มเขียนโค้ดทันที ...

$ grep -n "dark" app/globals.css
5:@custom-variant dark (&:is(.dark *));
86:.dark {

$ grep -c "dark:" components/ui/button.tsx
4

$ grep -rn "next-themes" package.json; echo "rc=$?"
rc=1

ขั้น 2 · Plan — ตัดสินใจก่อนลงมือ และให้คนรีวิวได้

สไลด์หน้า 15 (ถอดตามจริง):

• “Decide the approach before implementing.” — เลือกวิธีให้ได้ก่อนลงมือ
• “Break the task into steps, identify which files change, and anticipate edge cases and trade-offs.” — แตกงานเป็นขั้น · ระบุว่าไฟล์ไหนจะเปลี่ยน · คาดการณ์ edge case และสิ่งที่ต้องแลก
• “A good plan is reviewable by someone who can catch a bad direction before written code.” — แผนที่ดีคือแผนที่คนอื่นอ่านแล้วจับได้ว่าไปผิดทาง ตั้งแต่ก่อนมีโค้ดสักบรรทัด

diagram หน้า 12: Identify what needs to be changed · Determine affected files and dependencies · Consider edge cases and impacts · Create a step-by-step implementation plan · เป้าหมาย: Have a clear, safe plan before writing code.

นี่คือแผนที่ผมเขียนจริงก่อนแตะโค้ด (เขียนเอง ไม่ใช่ output ของ AI):

สังเกตว่าแผนนี้สั้นพอให้คนอ่านจบในหนึ่งนาที และมีจุดที่ reviewer แย้งได้จริง — เช่น senior อาจบอกว่า “ไม่ต้องทำโหมดมืดตอนนี้ ทีมยังไม่เปิดใช้” ซึ่งจะตัดงานไปครึ่งหนึ่ง ตั้งแต่ก่อนมีโค้ด — นี่คือความหมายของ reviewable ในสไลด์

ขั้น 3 · Code — ทำตามแผน ไม่ด้นสด

สไลด์หน้า 16 (ถอดตามจริง):

• “Execute the plan” — ลงมือตามแผน
• “Edits by following the conventions found during explore step” — แก้โค้ดตามธรรมเนียมที่เจอตอน Explore
• “Implement what was planned rather than improvising a new scope mid-stream.” — ทำสิ่งที่วางแผนไว้ ไม่ด้นขอบเขตงานใหม่ขึ้นมากลางทาง

diagram หน้า 12: Write or edit code · Create / update components or files · Run tests and linters · Fix issues and iterate · Refactor if needed · เป้าหมาย: Working code that implements the plan.

นี่คือ diff จริงของสองไฟล์หลัก (ไฟล์ที่สาม globals.css เพิ่ม token 6 บรรทัดตามแผน):

$ git diff components/ui/button.tsx app/page.tsx
diff --git a/app/page.tsx b/app/page.tsx
index c887311..6d5057b 100644
--- a/app/page.tsx
+++ b/app/page.tsx
@@ -1,4 +1,5 @@
 import Image from "next/image";
+import { Button } from "@/components/ui/button";

 export default function Home() {
   return (
@@ -54,6 +55,7 @@ export default function Home() {
             />
             Deploy Now
           </a>
+          <Button variant="success">บันทึกแล้ว</Button>
           <a
             className="flex h-12 w-full items-center ... md:w-[158px]"
             href="https://nextjs.org/docs?utm_source=create-next-app&..."
diff --git a/components/ui/button.tsx b/components/ui/button.tsx
index 997e0c7..e4aebd8 100644
--- a/components/ui/button.tsx
+++ b/components/ui/button.tsx
@@ -16,6 +16,7 @@ const buttonVariants = cva(
           "hover:bg-muted hover:text-foreground aria-expanded:bg-muted ...",
         destructive:
           "bg-destructive/10 text-destructive hover:bg-destructive/20 ...",
+        success: "bg-success text-success-foreground hover:bg-success/80",
         link: "text-primary underline-offset-4 hover:underline",
       },
       size: {

(บรรทัดบริบทที่เป็นสตริง class ยาว ๆ สี่บรรทัด ผมตัดกลางบรรทัดเป็น ... ให้พอดีจอ · บรรทัดที่ขึ้นต้นด้วย + ไม่ได้ตัดสักตัวอักษร)

บรรทัดที่เพิ่มจริงมีแค่ 9 บรรทัด ใน 3 ไฟล์ ตรงกับแผน · สิ่งที่ไม่ได้ทำก็สำคัญพอกัน: หน้า page.tsx ของ create-next-app ยังมีข้อความ “To get started, edit the page.tsx file” อยู่ ชวนให้ลบทิ้งมาก — แต่มันไม่อยู่ในแผน ถ้าลบในรอบนี้ diff จะบวมเป็นหลายสิบบรรทัด แล้วคนรีวิวจะหาบรรทัดสำคัญไม่เจอ
เจอของที่อยากแก้ระหว่างทาง → จดไว้เป็นงานถัดไป ไม่ใช่ยัดเข้ามาในงานนี้

ขั้น 4 · Evaluate — ตรวจว่าถูกจริง ไม่ใช่ดูเหมือนถูก

สไลด์หน้า 17 (ถอดตามจริง):

• “Verify the work is CORRECT — Run tests, lint, type-check, execute the code, and review the diff.”
• “If FAILURES here should be loop back to Code”

diagram หน้า 12: Run tests · Check linting / types · Validate requirements · Review edge cases · Ensure no regressions · Assess quality · เป้าหมาย: High-quality, reliable changes.

รอบที่ 1 — ไม่ผ่าน

ในรอบแรกผมจงใจพิมพ์ผิด variant="sucess" (ขาด c ตัวหนึ่ง) เพื่อดูว่าเครื่องมือแต่ละตัวจับได้ไหม (diff ในขั้น Code ข้างบนคือฉบับหลังแก้ในรอบที่ 2 แล้ว · รอบนี้ต่างกันแค่ตัวอักษรนั้นตัวเดียว) — ผลจริง:

$ npx tsc --noEmit; echo "rc=$?"
app/layout.tsx(20,50): error TS2304: Cannot find name 'LayoutProps'.
app/page.tsx(58,19): error TS2820: Type '"sucess"' is not assignable to type '"link" | "default" | "outline" | "secondary" | "ghost" | "destructive" | "success" | null | undefined'. Did you mean '"success"'?
rc=2

$ npx eslint .; echo "rc=$?"
rc=0

สองเรื่องในผลนี้ที่ต้องหยุดอ่าน:

• eslint ผ่าน (rc=0) ทั้งที่โค้ดผิด — linter ดู “สไตล์และแพตเทิร์นอันตราย” ไม่ได้ตรวจ type · ถ้าตรวจแค่ lint แล้วเชื่อ คุณจะ commit ตัวพิมพ์ผิดนี้ไปเลย นี่คือเหตุผลที่สไลด์ใส่ lint กับ type-check แยกกันเป็นสองอย่าง
• error บรรทัดแรก (LayoutProps) ไม่ได้มาจากที่เราแก้ — LayoutProps เป็น type ที่ Next.js สร้างให้ไว้ในโฟลเดอร์ .next/types/ ตอนรัน next dev / next build · โปรเจกต์ที่เพิ่ง clone มาและยังไม่เคยรันจะยังไม่มีโฟลเดอร์นี้ · สร้างได้โดยไม่ต้อง build ทั้งโปรเจกต์:

$ npx next typegen
Generating route types...
✓ Types generated successfully

$ npx tsc --noEmit; echo "rc=$?"
app/page.tsx(58,19): error TS2820: Type '"sucess"' is not assignable to type '"link" | "default" | "outline" | "secondary" | "ghost" | "destructive" | "success" | null | undefined'. Did you mean '"success"'?
rc=2

ตอนนี้เหลือ error ที่เป็นของเราจริง ๆ ตัวเดียว — และ TypeScript บอกคำตอบมาให้เลย (Did you mean '"success"'?) เพราะ cva สร้าง type ของ variant จากรายการที่เราเขียนใน button.tsx · ลองดูว่า next build พูดว่าอะไร:

$ npx next build
▲ Next.js 16.3.5 (Turbopack)
✓ Running next.config.ts took 12ms

  Creating an optimized production build ...
✓ Compiled successfully in 3.0s
  Running TypeScript ...
app/page.tsx(58,19): error TS2820: Type '"sucess"' is not assignable to type '"link" | "default" | "outline" | "secondary" | "ghost" | "destructive" | "success" | null | undefined'. Did you mean '"success"'?
Failed to type check.

สังเกตบรรทัด ✓ Compiled successfully ที่ขึ้นเครื่องหมายถูกก่อนจะพังตอน Running TypeScript — ใครอ่านแค่สองบรรทัดแรกแล้วหันไปทำอย่างอื่น จะเข้าใจผิดว่าผ่าน · อ่านจนบรรทัดสุดท้ายเสมอ หรือดู exit code

ผลรวมรอบที่ 1: ไม่ผ่าน → ย้อนกลับไป Code (ตามสไลด์หน้า 17) · กรณีนี้แผนไม่ได้ผิด แค่พิมพ์ผิด จึงไม่ต้องย้อนไปไกลถึง Plan

รอบที่ 2 — แก้แล้ว ตรวจใหม่ทั้งชุด

แก้ sucess → success แล้วรันทุกตัวใหม่ (ไม่ใช่รันแค่ตัวที่เคยพัง):

$ npx tsc --noEmit; echo "rc=$?"
rc=0

$ npx eslint .; echo "rc=$?"
rc=0

$ npx next build
▲ Next.js 16.3.5 (Turbopack)
✓ Running next.config.ts took 16ms

  Creating an optimized production build ...
✓ Compiled successfully in 1043ms
  Running TypeScript ...
  Finished TypeScript in 1078ms ...
  Collecting page data using 5 workers ...
  Generating static pages using 5 workers (0/4) ...
  Generating static pages using 5 workers (1/4)
  Generating static pages using 5 workers (2/4)
  Generating static pages using 5 workers (3/4)
✓ Generating static pages using 5 workers (4/4) in 377ms
  Finalizing page optimization ...

Route (app)
┌ ○ /
└ ○ /_not-found


○  (Static)  prerendered as static content

เครื่องมือผ่านหมด แต่สไลด์บอกให้ “execute the code” ด้วย — เปิด npx next dev -p 387 แล้วดู HTML ที่หน้าเว็บส่งออกมาจริง:

$ curl -s http://localhost:387/ | grep -o '<button[^>]*>บันทึกแล้ว</button>'
<button type="button" tabindex="0" data-slot="button" class="group/button inline-flex ... (ตัดคลาสพื้นฐานยาว ๆ ตรงกลางออก) ... bg-success text-success-foreground hover:bg-success/80 h-8 gap-1.5 px-2.5 has-data-[icon=inline-end]:pr-2 has-data-[icon=inline-start]:pl-2">บันทึกแล้ว</button>

$ grep -rho '\.bg-success[^{]*{[^}]*}' .next/static
.bg-success{background-color:var(--success)}

บรรทัดแรกยืนยันว่าปุ่มได้ class bg-success จริง · บรรทัดที่สองยืนยันว่า Tailwind สร้าง CSS ของ class นี้ออกมาจริง และมันชี้ไปที่ token --success ที่เราเพิ่ม — ถ้าลืมเพิ่ม token ใน globals.css class จะอยู่บนปุ่มแต่ปุ่มไม่มีสี และ tsc / eslint / build ไม่มีตัวไหนฟ้องเลย — ผมลองจริงแล้ว โดยคืน globals.css เป็นฉบับก่อนแก้ (ไม่มี token) แต่คง button.tsx ไว้:

$ npx tsc --noEmit; echo "tsc rc=$?"
tsc rc=0
$ npx eslint .; echo "eslint rc=$?"
eslint rc=0
$ npx next build > b.log 2>&1; echo "build rc=$?"
build rc=0
$ grep -rho '\.bg-success[^{]*{[^}]*}' .next/static; echo "grep rc=$?"
grep rc=1

ผ่านครบสามด่าน แต่ CSS ของ bg-success ไม่ถูกสร้างเลย (grep rc=1 = ไม่เจอ) — นี่คือเหตุผลที่สไลด์ใส่ “execute the code” ไว้ในรายการ ไม่ใช่แค่ lint กับ type-check

ขั้นสุดท้ายของ Evaluate: ย้อนดูโจทย์ตั้งต้น (คำเตือนหน้า 17) — โจทย์คือ “ปุ่มสีเขียวสำหรับสถานะสำเร็จ” · มี variant success ✓ · ใช้ token ตามแผน ✓ · ทำงานทั้งโหมดสว่างและมืด ✓ · ไม่แตะ variant เดิม ✓ · diff 9 บรรทัดใน 3 ไฟล์ตามแผน ✓ → ผ่าน ไป Commit ได้

เชื่อมกับตอนเขียน Go

คุณทำขั้น Evaluate มาตลอด 9 วันแล้ว แค่ชื่อเครื่องมือเปลี่ยน:

ขั้น 5 · Commit — บันทึกงาน หลังตรวจผ่านเท่านั้น

สไลด์หน้า 18 (ถอดตามจริง):

• “Write a clear commit message describing the change, and record the work.” — เขียนข้อความ commit ที่ชัด บอกว่าเปลี่ยนอะไร แล้วบันทึกงานไว้

diagram หน้า 12: Review the changes (diff) · Write a meaningful commit message · Commit the changes · (Optional) Open a Pull Request · Summarize what was done · เป้าหมาย: A clean commit ready for review and merge.

$ git diff --stat
 app/globals.css          | 6 ++++++
 app/page.tsx             | 2 ++
 components/ui/button.tsx | 1 +
 3 files changed, 9 insertions(+)

$ git add app/globals.css app/page.tsx components/ui/button.tsx
$ git commit -m "feat(button): add success variant" -m "- add --success / --success-foreground tokens (light + dark) in globals.css
- add success variant to buttonVariants, same shape as default
- use <Button variant=\"success\"> on home page

checked: tsc --noEmit, eslint ., next build"
[main a09e653] feat(button): add success variant
 3 files changed, 9 insertions(+)

$ git log --oneline -3
a09e653 feat(button): add success variant
2b21702 base
3f8a92e Initial commit from Create Next App

(เลข commit อย่าง a09e653 คำนวณจากเนื้อหา + ชื่อคน + เวลาที่ commit — ทำแบบเดียวกันเป๊ะในเครื่องคุณจะได้เลขอื่น ไม่ใช่เรื่องผิด)

สามอย่างที่ทำให้ commit นี้ “clean” ตามสไลด์:

• git diff --stat ก่อน add — ตัวเลข 3 ไฟล์ 9 บรรทัดตรงกับแผน ถ้าเห็นไฟล์ที่ไม่อยู่ในแผนโผล่มา (เช่น package-lock.json เปลี่ยนทั้งที่ไม่ได้ลงแพ็กเกจ) ให้หยุดถามก่อน
• git add ระบุชื่อไฟล์ ไม่ใช่ git add . — คุมได้ว่า commit มีแค่สิ่งที่ตั้งใจ
• ข้อความสองชั้น: บรรทัดแรกสั้น บอกอะไร (อ่านใน git log --oneline รู้เรื่อง) · ย่อหน้าล่างบอกรายละเอียดและตรวจด้วยอะไร — ตรงกับ “Summarize what was done” ในสไลด์

# ต่อจากเฉลยภารกิจท้ายบท (ที่หน้าแรกมี <Badge variant="success"> แล้ว)
# แยก branch ไปลองข้าม Evaluate — จงใจพิมพ์ badge variant ผิดเป็น "sucess"
# แล้ว commit ทันทีโดยไม่รัน tsc ก่อน
$ git commit -am "feat: use success badge"

[skip-eval abe7082] feat: use success badge
 1 file changed, 1 insertion(+), 1 deletion(-)

$ npx tsc --noEmit; echo "rc=$?"
app/page.tsx(60,18): error TS2820: Type '"sucess"' is not assignable to type '"link" | "default" | "outline" | "secondary" | "ghost" | "destructive" | "success" | null | undefined'. Did you mean '"success"'?
rc=2

ข้ามขั้นนี้แล้วเกิดอะไร

ตารางสรุปจากตัวอย่างในบทนี้ — ทุกช่องมาจากสิ่งที่เห็นจริงข้างบน:

ภารกิจ — เดินครบ 5 ขั้นด้วยตัวเอง

$ grep -rn "components/ui/badge" app components; echo "rc=$?"
rc=1

        success:
          "bg-success/10 text-success dark:bg-success/20 [a]:hover:bg-success/20",

$ git grep -n "success" -- app components
app/globals.css:30:  --color-success: var(--success);
app/globals.css:31:  --color-success-foreground: var(--success-foreground);
app/globals.css:69:  --success: oklch(0.527 0.154 150.069);
app/globals.css:70:  --success-foreground: oklch(0.985 0 0);
app/globals.css:106:  --success: oklch(0.723 0.219 149.579);
app/globals.css:107:  --success-foreground: oklch(0.205 0 0);
app/page.tsx:59:          <Button variant="success">บันทึกแล้ว</Button>
app/page.tsx:60:          <Badge variant="success">ชำระแล้ว</Badge>
components/ui/badge.tsx:16:        success:
components/ui/badge.tsx:17:          "bg-success/10 text-success dark:bg-success/20 [a]:hover:bg-success/20",
components/ui/button.tsx:19:        success: "bg-success text-success-foreground hover:bg-success/80",

$ npx tsc --noEmit; echo "rc=$?"
rc=0

$ npx eslint .; echo "rc=$?"
rc=0

$ npx next build
... (ส่วนต้นเหมือนรอบก่อน)
Route (app)
┌ ○ /
└ ○ /_not-found


○  (Static)  prerendered as static content

$ git diff --stat
 app/page.tsx            | 2 ++
 components/ui/badge.tsx | 2 ++
 2 files changed, 4 insertions(+)

$ git commit -am "feat(badge): add success variant using --success token"
[main fc006e0] feat(badge): add success variant using --success token
 2 files changed, 4 insertions(+)

ลองตอบดู

ถามกลับได้เลย

ถ้าคุณลองให้ Claude Code ทำงานแล้วบอกไม่ได้ว่ามันอยู่ขั้นไหน — เอาสิ่งที่มันพิมพ์ออกมาทั้งก้อนมาคุยได้ เราจะไล่ด้วยกันว่าตรงไหนคือ Explore ตรงไหนมันข้าม Plan ไป และมันรันตรวจครบชุดจริงหรือแค่บอกว่าตรวจแล้ว
หรือถ้า tsc ฟ้อง error ที่ไม่ได้มาจากโค้ดที่คุณแก้ (แบบ LayoutProps ในบทนี้) ก็เอาข้อความมาได้เลย

อ้างอิง

• Claude Code — Best practices — อ่านหัวข้อ Explore first, then plan, then code (4 ขั้น Explore · Plan · Implement · Commit พร้อม prompt ตัวอย่างของแต่ละขั้น และกล่องที่บอกว่าเมื่อไหร่ควรข้ามการวางแผน) · แล้วอ่าน Give Claude a way to verify its work ซึ่งอธิบายว่าทำไม agent ต้องมีคำสั่งตรวจที่ให้ผลผ่าน/ไม่ผ่าน — ตรงกับขั้น Evaluate ของสไลด์ (สังเกตว่าเอกสารทางการรวมการตรวจไว้ในขั้น Implement ส่วนสไลด์แยกออกมาเป็นขั้นของตัวเอง)
• Claude Code — Common workflows — อ่านหัวข้อ Plan before editing สำหรับวิธีเปิด plan mode และ Understand new codebases สำหรับตัวอย่างคำถามที่ใช้ในขั้น Explore
• Anthropic — Building effective agents — อ่านหัวข้อ What are agents? เทียบกับนิยามในสไลด์หน้า 12 และ Workflow: Evaluator-optimizer ซึ่งคือลูป “ทำ → ประเมิน → แก้” แบบเดียวกับเส้น Evaluate→Code
• Next.js — next CLI — อ่านส่วนของคำสั่ง next typegen ที่ใช้แก้ error LayoutProps ในบทนี้ และ next build ที่รัน type-check ให้ในตัว