เพิ่งอ่านบทความของ Nick Bevers ที่กลัวว่านักพัฒนาจะเหลือแค่กดลูกศรกับ Enter ตามที่ AI เสนอ ผมอ่านแล้วสะดุ้งนิดหน่อย เพราะงานส่วนใหญ่ของผมตอนนี้ agent ก็เขียนเอง เลยลองนับจากประวัติ session ของตัวเองว่าเป็นอย่างที่เขากลัวหรือเปล่า
ผมเลือกตัวเลือกแรกบ่อยขึ้นทุกเดือน
ก่อนเริ่มงาน agent จะถามคำถามพร้อมตัวเลือก และวางข้อที่แนะนำไว้ข้อแรก ถ้าเห็นด้วยก็แค่กด Enter ผมนับคำถามแบบเลือกข้อเดียวทั้งหมดราว 2,900 ข้อ จากทุกโปรเจกต์
| เดือน (2569) | เลือกข้อแรก | เลือกข้ออื่น | พิมพ์เอง |
|---|---|---|---|
| สิงหาคม | 61% | 21% | 19% |
| กันยายน | 68% | 13% | 19% |
| ตุลาคม | 83% | 4% | 13% |
ถ้าหยุดอ่านตรงนี้ ก็เหมือน Nick พูดถูกทุกอย่าง แถมตัวเลขยังขึ้นในเกือบทุกโปรเจกต์ใหญ่ ไม่ได้มาจากโปรเจกต์เดียว
ตัวเลขชุดเดียวกันไม่ได้บอกว่าผมคิดน้อยลง
ผมเลยดูต่ออีกสองอย่าง อย่างแรกคือเวลาที่ใช้ตอบ การเลือกข้อแรกใช้เวลากลางราวหนึ่งนาทีมาตลอด ไม่ได้สั้นลงตามเดือน และมีแค่ราว 10% ที่ตอบภายใน 10 วินาที อย่างที่สองคือการกลับมาล้มคำตอบในข้อความถัดไป ซึ่งมีไม่ถึง 1% ของครั้งที่เลือกข้อแรก
สองตัวเลขนี้ยังพิสูจน์ไม่ได้ว่าคำตอบถูก หนึ่งนาทีนั้นผมอาจทำอย่างอื่นอยู่ด้วย และการนับคำว่า "เอาใหม่" ก็จับได้แค่ข้อความที่ตามมาทันที แต่ก็พอบอกได้ว่าไม่ได้เป็นภาพคนกด Enter รัว ๆ
คำอธิบายที่ตรงกับความรู้สึกของผมมากกว่าคือ คำถามเปลี่ยนไปเอง และงานของผมขยับขึ้นไปอยู่ที่อื่น ตัวเลขอีกชุดในช่วงเดียวกันก็ไปทางเดียวกัน
| เดือน (2569) | เครื่องมือที่ agent ใช้ต่อหนึ่งข้อความของผม | session ที่ agent เปิดต่อให้ |
|---|---|---|
| สิงหาคม | 21 ครั้ง | 4% |
| กันยายน | 28 ครั้ง | 29% |
| ตุลาคม | 40 ครั้ง | 39% |
หนึ่งข้อความของผมพา agent ไปได้ไกลขึ้นเกือบเท่าตัว ส่วนคำสั่งเปิดงานที่ผมพิมพ์เองก็ยาวขึ้นจากราว 200 เป็นราว 330 ตัวอักษร ผมบอกเป้าหมายและขอบเขตมากขึ้น แล้วให้ agent แบ่งงานเอง
งานของผมย้ายไปอยู่ตอนวางภาพใหญ่กับตอนลองของจริง
agent ทำช่วงกลาง ส่วนการ์ดสีเหลืองคือจุดที่ต้องใช้คนตัดสิน
เริ่มจากดูหน้าตารวมก่อน ฟีเจอร์ที่มีหลายหน้าจอ ผมให้ agent ทำหน้า design ให้เลือกตั้งแต่ก่อนเขียนจริง การเห็น flow ทั้งเส้นทำให้ถามคำถามที่ตอบเป็นข้อ ๆ ไม่ได้ เช่น หน้านี้ควรมีอยู่ไหม หรือคนใช้งานจะมาถึงตรงนี้จากไหน
ทำชิ้นแรกให้เล็กพอจะใช้งานได้ แล้วดูของจริงก่อนค่อยคุยต่อ ตัวอย่างใกล้ตัวคือหน้าสถิติในหลังบ้านของเว็บนี้ ที่ดูว่าคนอ่านอะไรตามประเภทและรูปแบบโพสต์ ผมดู design ก่อน ได้หน้าแรกขึ้นใช้ภายในราวครึ่งชั่วโมง แล้วอีกครึ่งชั่วโมงถัดมาก็ปรับปุ่ม เพิ่มตัวกรอง และเพิ่มเวลาอ่านรวม ตัวกรองพวกนี้ไม่ได้อยู่ในแผนตอนแรก เห็นข้อมูลจริงแล้วจึงรู้ว่าอยากได้
ตรวจกับข้อมูลจริง test บอกได้ว่าโค้ดทำตามที่สั่ง แต่บอกไม่ได้ว่าที่สั่งไปถูกไหม ผมจึงให้ agent อ่านฐานข้อมูล production แบบอ่านอย่างเดียวได้ แล้วเปิดหน้าจอลองเอง คอมเมนต์ที่มีค่าที่สุดของผมมักเกิดตรงนี้ เช่น "ตรงนี้ไม่เอา badge" หรือ "ไม่เอา ดูยากไป เป็นคนละคอลัมน์ดีแล้ว" เรื่องพวกนี้ไม่มีทางอยู่ในตัวเลือกที่ agent เสนอตอนเริ่มงาน
คำตัดสินเก่าเขียนไว้ใน skill agent จึงถามน้อยลง
ทุกครั้งที่ผมตัดสินเรื่องที่จะเกิดซ้ำ ผมให้ agent เขียนลง skill ทันที อย่างพอบอก "ไม่เอา badge" ซ้ำอยู่หลายหน้า ก็กลายเป็นกฎว่าสถานะปกติแสดงเป็นข้อความสีเทา ส่วน badge เก็บไว้ให้เรื่องที่ควรสะดุดตา เช่น ลาหรือไม่ผ่าน อีกตัวอย่างคือ test ในโปรเจกต์ของผมไม่ใช้ RefreshDatabase เพราะผมปิด migrate:fresh ไว้ทุก environment รอบต่อไป agent ก็ไม่ต้องถาม หรือถามพร้อมคำตอบที่ถูกอยู่ข้อแรกแล้ว ผมเดาว่านี่เป็นเหตุผลส่วนใหญ่ที่ตัวเลขเลือกข้อแรกขึ้น ตัดสินครั้งเดียวแล้วใช้ได้หลายรอบ
แต่ skill ก็เก่าเร็ว เพราะเครื่องมือกับตัว agent เปลี่ยนตลอด ผมจึงกลับมาทบทวนอยู่เรื่อย ๆ repo ของ skill แก้มาแล้วกว่า 300 ครั้ง เฉพาะเดือนตุลาคมมี 84 ครั้ง ตัวอย่างเห็นชัดคือ skill เรื่อง design ที่เริ่มจากทำ mockup ขยับมาเป็นหน้าจอที่ลองกดตาม flow ได้ และตอนนี้ผมตอบด้วยการเขียนโน้ตหรือวาดลงบนหน้าจอได้เลย ส่วน skill หรือกฎที่หมดหน้าที่ก็ลบทิ้ง อย่างกฎให้ agent ตอบเป็นภาษาอังกฤษ ที่เลิกจำเป็นตั้งแต่แอปแสดงภาษาไทยได้
การทบทวนรอบนี้ก็เป็นงานที่ agent ทำแทนไม่ได้ทั้งหมด agent ช่วยหาว่าอะไรเก่าได้ แต่ถ้าถามว่าวิธีทำงานแบบไหนเหมาะกับเราตอนนี้ คนที่ตอบได้ก็ยังเป็นคนที่ใช้งานอยู่
งานที่ย้อนยากยังควรหยุดคิดนานกว่า
Nick แบ่งนักพัฒนาเป็นคนที่ชอบสร้างให้เสร็จ กับคนที่อยากเข้าใจว่าของทำงานยังไง ผมว่าคนคนเดียวเป็นได้ทั้งสองแบบ ขึ้นกับว่างานนั้นย้อนกลับยากแค่ไหน
| ถ้างานเป็นแบบนี้ | ผมทำแบบนี้ |
|---|---|
| หน้าตา ข้อความ หรือฟีเจอร์ที่ลบทิ้งได้ | รับตามที่แนะนำ แล้วไปตัดสินตอนเห็นของจริง |
| โครงข้อมูล สิทธิ์ผู้ใช้ หรือเงิน | อ่านคำถามให้ละเอียด ถามกลับ หรือขอดูตัวอย่างก่อน |
| ข้อมูลบน production หรือสิ่งที่ส่งถึงคนอื่น | อนุมัติเองทุกครั้ง |
ตัวเลขข้างบนยังแยกตามตารางนี้ไม่ได้ และตัวผมเองก็ไม่ได้ทำตามนี้ทุกครั้ง แต่คำตอบแบบพิมพ์เองที่เหลืออยู่ มักเป็นเรื่องที่ตัวเลือกไม่ครอบคลุม เช่น "ข้อแรก แล้วเช็กด้วยว่าบันทึกจริงเฉพาะที่ติ๊ก" หรือ "ยังไม่ชัวร์ ขอดูตัวอย่าง UI ก่อน" ส่วนนี้ผมตั้งใจจะไม่ให้หายไป
คำว่าภาพใหญ่เป็นข้ออ้างได้ง่ายมาก
ส่วนที่ Nick กลัวยังเกิดกับผมได้ ถ้าบอกว่าตัวเองมองภาพใหญ่ แต่ไม่เคยเปิดหน้าจอ ไม่เคยดูข้อมูล และอธิบายไม่ได้ว่าข้อมูลไหลไปทางไหน นั่นก็คือกด Enter เฉย ๆ ผมจึงลองถามตัวเองสามข้อแทนการดูว่าพิมพ์โค้ดเองกี่บรรทัด
- ฟีเจอร์ล่าสุดที่ส่งไป เปิดลองเองหรือดูข้อมูลจริงหรือยัง
- ถ้า agent เสนอทางที่ผิด เรามีภาพในหัวพอจะรู้ตัวไหม
- skill หรือกฎที่เขียนไว้ ยังตรงกับวิธีที่เราทำงานตอนนี้อยู่ไหม
ถ้าใช้ Claude Code อยู่ ประวัติ session เก็บเป็นไฟล์อยู่ใน ~/.claude/projects ลองให้ agent นับให้ก็ได้ว่าเราตอบตัวเลือกแรกกี่เปอร์เซ็นต์ และเปลี่ยนไปยังไงตามเดือน ตัวเลขอย่างเดียวไม่ได้บอกว่าดีหรือแย่ แต่ทำให้ถามตัวเองได้ตรงกว่าความรู้สึกครับ
