บันทึกเส้นทางการปรับตัวสู่ Agentic Coding

วันนี้อยากมาเล่า กับ มาบันทึกเอาไว้อ่านเองด้วยว่า ผมค่อยๆ เริ่มใช้ AI มายังไง ตั้งแต่เริ่มใช้ mattpocock/skill จนอยู่ตัว จนไปต่ออีกรอบ

Step 1: Start with Grill

ใช้ /grill-with-docs เป็นหลัก แล้วก็ให้มันเขียน spec เอาไว้ใน repo เลย จะได้ตรวจย้อนกลับได้ด้วยว่ามันเขียนอะไรไปบ้าง มันแก้ spec อะไรบ้าง เราแก้อะไรบ้าง แล้วก็ค่อยๆ สั่ง AI ทำตาม Spec ที่เขียนไว้ทีละอัน

ตอนนั้นก็จะเหนื่อยหน่อย แต่สบายใจสุด และคุมเข้มได้มากๆ

Step 2: To Issue

ใช้ /grill-with-docs เหมือนเดิม แต่ครั้งนี้เริ่มใช้ /to-issue เพื่อแตกงาน โดยเน้นแตกแบบ vertical เพื่อให้เรายังเข้าไปทดสอบแบบ manual ได้อยู่ และสามารถสังเกตเห็นความผิดพลาดต่างๆ ได้ทัน

ตอนนี้ /to-issue จะเปลี่ยนเป็น /to-ticket แล้วนะครับ

พอได้เริ่มใช้ /to-issue ชีวิตก็ดีขึ้นมากๆ เพราะนอกจากเราจะเห็นสิ่งที่ AI จะทำจาก grill spec แล้ว ตอนที่ให้มันบอกงานย่อยๆ มันเราก็จะตรวจมันได้อีกทีนึง ทำให้แก้หลายๆ อย่างไรทันก่อนทีี่มันจะเริ่มทำงาน แต่ในขณะเดียวกันก็ต้องมีสติมากๆ เพราะพอมันทำถูกหลายๆ ครั้งติดๆ กัน เราก็จะเริ่มตายใจ 😓

ผมจะอยู่่ขั้นนี้เป็นหลายเดือนครับ ด้วยความที่ยังไม่ไว้ใจ AI แล้วก็ไม่รู้สึกว่าต้องทำอะไรให้ดีขึ้น

คำสั่งที่ใช้ประจำ ณ ตอนนั้นก็จะมี Pattern ชัดเจน เริ่มจาก grill with docs ก็จะใส่งานลงไปแบบเฉพาะมากๆ แทบจะเขียนเห็นหน้าๆ ไว้บน obsedian ก่อน แล้ว copy มาใส่ ไม่ก็เขียนเป็นไฟล์ไว้เลย จากนั้นก็เอามาวางใน prompt แล้วสั่ง grill-with-docs

<สิ่งที่เราอยากให้มันทำ แบบ Specific มากๆๆๆๆ เอาให้ชัดที่สุด มีประเด็นอะไรใส่หมด>

/grill-with-docs

เมื่อ grill เสร็จผมจะสั่ง /to-spec แบบนี้

/to-spec เขียน spec ใน folder ai-plan ของ project นี้

ในกรณีที่รู้สึกว่างานใหญ่เกินกว่าจะทำจบในทีเดียว ก็จะสั่ง /to-issue เป็น pattern นี้

/to-issue เขียน issue ใน folder ai-plan ของ project นี้

ตอนนั้นที่ให้มันเขียนลงไฟล์เพราะไม่อยากให้มันไปเปิด issue บน github แล้วก็ไม่อยากให้มันไปเขียนใน /tmp เพราะเอาออกมาตรวจได้ยาก ที่สำคัญคืออยาก commit เข้า repo ไปเลย จะได้เห็นได้ว่ามันจะแก้อย่างไร แล้วถ้าเราย้ายเครื่อง ไฟล์ spec และ issue จะได้ตามไปด้วย โดยเฉพาะตอนที่มันแตกออกมาหลาย issue ที่ต้องเก็บไว้ทำนานๆ

Step 3: Handoff and Prototype

ใช้ /handoff และ /prototype ในระหว่างนี้เริ่มรู้แล้วว่า ถ้าเรายื้อ context ไปมากกว่า 50% ตัว AI มันจะโง่ลง ก็พอดีกับที่ไปรู้จัก handoff ก็เลยส่งต่อเยอะเลย นอกจากนั้นก็เริ่มรู้ว่าหา idea prototype กับ AI มันดีมากๆ หลายอย่างก็คิดไม่ถึง การทำร่วมกันช่วยได้มากๆ

ถ้าใช้ prototype ต้องมีพื้นฐาน UX แน่นๆ หน่อย เพราะที่ AI แนะนำมหลายครั้งมันดูเหมือนดี แต่ใช้ยาก หรือไม่ก็ Information Architecture ไม่ถูกต้อง ถ้าเราเข้าใจเราจะบอกได้ว่าจะเอาอะไรไว้ และจะไม่เอาอะไร

ตอนใช้ handoff ตอนนั้นใช้เวลาจะเปลี่ยนไปทำ issue ถัดไป แทนที่จะเริิ่มใหม่เลย ก็จะสั่ง handoff เอา เช่น

/handoff ไปทำ issue ถัดไป @<filename>

หรือตอนที่จะไปทำ prototype ก็จะจตชื่อ session ปัจจุบันเอาไว้ แล้วสั่ง handoff ออกไปทำ prototype อีก session นึง เช่น

/handoff ไปทำ prototype สำหรับ <รายละเอียดคร่าวๆ ของหน้า หรือ api ที่เราต้องการจะทำ>

ให้เขียน handoff ไว้ที่ folder ai-handoff ของ project นี้

จากนั้นก็เปิด session ใหม่ แล้วสั่งให้มันสร้าง prototype ตามที่เราวางแผนไว้ เช่น

@<handoff file>

/prototype <รายละเอียดเต็มของหน้า หรือ ใส่ไฟล์รายละเอียดของหน้า ที่เราเขียนไว้แล้ว>

และจุดเปลี่ยนไปสู่ Step 4 ก็เริ่มแถวๆ นี้ อยู่แถวๆ นี้คือตอนนั้นทุกอย่างบริหารจัดการผ่าน local file หมดเลย เขียนทุกอย่างไว้เป็น local file อ้างอิงได้ง่าย รู้สึกคุมได้เต็มที่ (เขียนลง repo ด้วย ทำให้เวลา PR ทีนึงจะน่ากลัวเพราะดูเหมือนสร้างบรรทัดจำนวนมาก)

นอกจาก skill ของ matt ก็จะมีอีกสองสามตัวที่ใช้ร่วมกันอยู่ครับ

/caveman ใช้สำหรับให้มันพูดน้อยๆ ประหยัด token

/ponytail full ใช้สำหรับตอนที่ให้มันหาทางทำน้อยๆ อะไรมีอยู่แล้วก็ให้ใช้อันนั้นก่อน หรือใช้ท่าง่ายๆ ของมนุษย์ ก่อนจะไปใช้ท่างานของ AI

/impeccable ใช้จัดการ UI ให้เรียบร้อยสวยงาน โดยเฉพาะการเก็บ Accessibility, Empty Page, Error เล็กๆ น้อยๆ

Step 4: Github Issue

เริ่มบริหารจัดการผ่าน Github มากขึ้น แทนที่เราจะเขียน Spec ลง local โดยช่วงแรกก็ยัง copy prd ไปใส่ issue เอง, PR เอง จนรู้สึกเหมือนเป็นลูกน้อง AI 😂

ตอนนี้เริ่มปรับตัว (เริ่มไว้ใจมันมากขึ้น) ก็เริ่มให้ AI สร้าง issue ให้ ผ่านทาง /to-spec หลังจาก grill เสร็จแล้ว แต่ยังทำ PR เอง เพราะยังอยากให้ตัว Issue กับ Branch และ PR มันเชื่อมกันบน Github อยู่ (และยังไม่ไว้ใจมันขนาดนั้น)

การทำงานของ Step 4 จะเหมือน Step 5 เลยครับ แค่เราทำแบบ Manual ตรวจมันทุกขั้นตอน แล้ว Step 5 จะให้ AI ทำเองหมดเลย

Step 5: Agentic Coding

Use github to store PRD and Tickets

วางแผนเรื่อง Agentic Code ซะที หลังจากเริ่มใช้ /way-finder ครั้งแรก ก็พบว่าถ้าจะใช้ตัวนี้มาบริหารบน local file น่าจะวุ่นวายมาก เลยไปอ่านวิธีจัดการ document ต่างๆ ผ่านทาง Issue ให้หมด ทั้งของที่กำลัง grill และของที่ grill เสร็จแล้ว ใช้ issue เป็นเหมือน todo list ไปเลย

ก็พบว่าใช้ได้ดี และเมื่อแผนทุกอย่างอยู่บน Issue แล้ว และมีการบอกไว้ชัดเจนว่าตัวไหนมี dependency กับตัวไหนบ้าง เราก็มั่นใจมากขึ้น

ก็เปิด Session นึงทำตัวเป็น manager (ผมใช้ Codex) แล้วให้มันค่อยๆ จัดการ Issue ด้วยตัวเอง โดยใช้ Practice ที่ทำมาแล้วตั้งแต่

Verify the previous PR
Create one fresh Local Codex task
Read the issue
Implement (/implement, /tdd, /ponytail, /caveman, /code-review)
Commit, Push, PR

รอผมมา Merge (ยังไม่ไว้ใจมัน)

Next Step: Worktree

คือแทนที่จะทำไปทีละ Issue จะลองใช้ worktree เพื่อทำงานแบบคู่ขนานดู (แต่ก็ยังติดว่ามันต้องไปใช้ db ตัวเดียวกัน ก็มีหลายท่า ตั้งแต่ใช้ schema หรือไม่ก็ให้มันเปิด docker ขึ้นมาทำไปซะเลย)

กับอีกข้อคือไม่แน่ใจว่าทำไมทำแบบข้อ 5 แล้วมันเปลือง token มากกว่าปกติทั้งๆ ที่ก็ทำเหมือนเดิม ต้องลองหาว่ามันไปเปลืองตอนไหน 🤔

วงการ AI Coding มีท่าต่างๆ เยอะมากๆ ลองกันไม่ทันเลยครับ ใครใช้ท่าไหนอยู่ หรือมีบทความดีๆ ฝากแนะนำด้วยนะครับ 🙇‍♂️