Jason McCreary เป็นคนทำ Laravel Shift บริการอัปเกรดโปรเจกต์ Laravel อัตโนมัติ และเขียนหนังสือ BaseCode เรื่องการเขียนโค้ดให้อ่านง่าย คนที่เขียนหนังสือเรื่องหน้าตาของโค้ดออกมาบอกว่าเลิกสนใจหน้าตาของโค้ดแล้ว จึงน่าฟังว่าเขาคิดยังไง
ขั้นแรก ให้ AI ทำแค่งานน่าเบื่อ
ช่วงปลายปี 2568 เขาใช้ AI แค่กับงานที่ไม่อยากทำเอง เริ่มจากถามแล้ว copy โค้ดชิ้นเล็ก ๆ มาวางเอง ต่อมาจึงยอมให้ AI แก้ไฟล์ในโปรเจกต์ตรง ๆ โดยเริ่มจาก git ที่สะอาดทุกครั้ง ถ้า AI ทำพังก็ย้อนกลับได้ทันที
ขั้นนี้เขายังอ่านทุกบรรทัด และโค้ดส่วนที่สำคัญยังเขียนเอง
ขั้นที่สอง เขียน test เองแล้วให้ AI ทำให้ผ่าน
ต้นปี 2569 เขากลับด้านงาน เขียน test เองก่อน test ทางที่ทำงานปกติหนึ่งตัว กับ test กรณีขอบอีกหลายตัว แล้วสั่งให้ AI เขียนโค้ดให้ test ผ่านทั้งหมด
test ทำหน้าที่เป็นรั้ว AI จะเขียนโค้ดหน้าตายังไงก็ได้ แต่ต้องอยู่ในขอบที่ test กำหนด ขั้นนี้เป็นจุดที่เขาเริ่มไว้ใจผลงานของ AI ได้โดยไม่ต้องคุมทุกบรรทัด
ขั้นที่สาม ให้ AI เขียนเกือบทั้งหมด แต่พยายามให้เขียนเหมือนตัวเอง
ฤดูใบไม้ผลิ AI เขียนทั้งโค้ดและ test แบบ TDD เขาอ่านแค่ test ทำงานบน feature branch และรีวิว PR ก่อน merge
ช่วงนี้เขาเสียเวลาไปกับการให้ AI เขียนให้เหมือนเขา แก้โค้ดที่ AI เขียนให้เป็นสไตล์ตัวเอง เพิ่มกฎลงใน AGENTS.md จนสุดท้ายทำ skill จากหลักใน BaseCode ไว้สั่ง /basecode ตอนจบแต่ละ session ที่ใช้ AGENTS.md กับ skill แบบนี้เป็นแนวเดียวกับที่ Laravel Boost ช่วยตั้งให้
พอมองย้อนกลับไป เขาบอกว่าขั้นนี้ "a lot of effort for very little value" เพราะสิ่งที่ทำจริง ๆ คือสอนให้ AI เขียนเหมือนคนคนเดียว ไม่ได้ทำให้งานดีขึ้น
ขั้นที่สี่ เลิกรีวิวโค้ด
หน้าร้อนปี 2569 เขาเลิกอ่านโค้ด และเลิกสนใจว่าโค้ดจะหน้าตาเหมือนที่ตัวเองเขียนไหม ที่น่าสนใจคือรั้วไม่ได้เปลี่ยนเลย เพราะรั้วเป็นสิ่งที่ทำให้ไว้ใจได้มาตั้งแต่ต้น ไม่ใช่การอ่านโค้ด
สองโปรเจกต์ที่เขาทำแบบนี้โดยไม่เปิด IDE เลยคือ Double ไลบรารี mock ของ PHP และ PHPUnit TIA ที่ทำเสร็จบนเที่ยวบินสี่ชั่วโมงกลับจาก Laracon US ใครที่ใช้ Pest อยู่คงคุ้นกับแนวคิด TIA ที่รันเฉพาะ test ที่โค้ดเปลี่ยนไปกระทบ ซึ่งมาในPest 5
รั้วที่เขาใช้แทนการอ่านโค้ด
- test ทั้งทางปกติและกรณีขอบ ซึ่งเขาเขียนอยู่แล้วก่อนมี AI
- static analysis และ CI pipeline ที่ทุก PR ต้องผ่าน
- agent อีกตัวที่คอยหาช่องโหว่ ในโค้ดและในความครอบคลุมของ test เขาเรียกว่า adversarial agent
- ประสบการณ์ไล่บั๊กของตัวเอง ที่ยังต้องใช้เมื่อมีอะไรพัง
เขายกแนวของ Uncle Bob (Robert C. Martin) ที่ไม่อ่านโค้ดของ agent เหมือนกัน แต่ล้อม agent ไว้ด้วยข้อจำกัดเข้ม ๆ ทั้ง unit test, test แบบ Gherkin, ขั้นตอน QA, ค่าวัดคุณภาพโค้ด, mutation testing และ coverage
คนที่รีวิวทุกบรรทัดกลายเป็นคอขวด
ประเด็นที่เขาย้ำคือ ถ้าให้ AI เขียนโค้ดแต่เรายังรีวิวทุกบรรทัด เราจะเป็นคอขวดเหมือนหัวหน้าทีมที่ต้องตรวจทุกอย่างก่อนปล่อย ปัญหานี้มีมาก่อน AI ด้วยซ้ำ หัวหน้าที่ไม่ยอมปล่อยงานให้ลูกทีมก็เจอแบบเดียวกัน
ความเชี่ยวชาญของเขาจึงย้ายจากการพิมพ์โค้ด ไปเป็นการกำกับ AI และออกแบบรั้วให้รัดพอ เขาเปรียบว่าตัวเองจาก software engineer กลายเป็น software foreman และบอกว่าตอนนี้รู้สึกสบายใจกับบทบาทนั้นแล้ว
เทียบกับที่เราทำอยู่
ที่ภัทรชัย อาร์ทิซาน เราให้ AI agent ช่วยเขียนโค้ดและ test มาสักพักแล้ว แนวที่ใช้ใกล้กับขั้นที่สามของเขา ข้อตกลงของแต่ละโปรเจกต์อยู่ใน AGENTS.md และ .ai/rules ที่ commit เข้า repo วิธีทำงานซ้ำ ๆ อยู่ใน skill และทุก push ต้องผ่าน test, Pint, Rector และ CI ก่อน deploy ส่วนการออกแบบ การตัดสินใจ และความรับผิดชอบยังอยู่ที่เรา
บทความของ McCreary ชวนให้ถามต่อว่ากฎที่เราเขียนไว้ใน .ai/rules ข้อไหนช่วยให้งานถูกต้องจริง และข้อไหนเป็นแค่สไตล์ที่เราอยากให้ AI เขียนเหมือนเรา ข้อแบบหลังคือส่วนที่เขาบอกว่าได้ผลน้อยที่สุด
