10 กติกาก่อนให้ AI เขียนโค้ดในโปรเจกต์จริง

การให้ AI เขียนโค้ดในโปรเจกต์ทดลองกับโปรเจกต์ที่มีผู้ใช้จริงต่างกันมาก โปรเจกต์ทดลองพังก็แค่ลบทิ้ง แต่โปรเจกต์จริงพังหมายถึงข้อมูลลูกค้าหาย ระบบล่ม หรือ API key รั่วไปถึงคนอื่น บทความนี้รวบรวม 10 กติกาที่ควรตั้งไว้ก่อนเปิดให้ AI แตะโค้ดในโปรเจกต์จริง แต่ละข้อมีเหตุผลและวิธีปฏิบัติที่ทำได้ทันที ทั้งสำหรับนักพัฒนาคนเดียวและทีมที่ใช้ PHP/Yii2 หรือ stack อื่น ๆ

กติกา 1–3: คุมพื้นที่ทำงานด้วย Git

1. ทำงานบน branch แยกเสมอ

เหตุผล: AI อาจแก้หลายไฟล์ในครั้งเดียว ถ้าทำบน main โดยตรง การแยกงานที่ดีออกจากงานที่เสียจะยากมาก branch แยกทำให้เราทิ้งทั้งก้อนได้ถ้าผลไม่ดี

git switch -c ai/order-export-csv
# ให้ AI ทำงาน...
# ถ้าไม่ดี ทิ้งได้ทั้ง branch
git switch main
git branch -D ai/order-export-csv

2. Commit บ่อย ทุกครั้งที่ได้ผลที่ใช้ได้

เหตุผล: การทำงานกับ AI เป็นวงจรลองผิดลองถูก บ่อยครั้งที่รอบที่ 5 ทำให้สิ่งที่ใช้ได้ในรอบที่ 3 พัง ถ้า commit ไว้ทุกจุดที่ผ่าน เราย้อนกลับได้ในคำสั่งเดียว แทนที่จะต้องขอให้ AI "แก้กลับให้เหมือนเดิม" ซึ่งมักไม่เหมือนเดิมจริง

3. อ่านทุก diff ก่อนรับ

เหตุผล: AI มักแก้เกินที่ขอ เช่น ขอให้แก้ bug หนึ่งจุด แต่เปลี่ยนชื่อตัวแปร ลบ comment หรือ "ปรับปรุง" ฟังก์ชันข้างเคียงไปด้วย สิ่งเหล่านี้มองไม่เห็นถ้าไม่ดู diff

git diff --stat        # ดูก่อนว่าแตะกี่ไฟล์
git diff               # อ่านรายละเอียด
git add -p             # เลือกรับทีละส่วน

ถ้า --stat แสดงไฟล์ที่ไม่เกี่ยวกับงาน ให้หยุดและถามว่าทำไมต้องแก้ไฟล์นั้น

กติกา 4–5: ห้ามแตะ secret และ production

4. ไม่ให้ AI เห็นหรือแก้ secret

เหตุผล: ทุกอย่างที่อยู่ใน prompt หรือในไฟล์ที่ agent อ่านได้ ถือว่าถูกส่งออกไปยังผู้ให้บริการ AI แล้ว นอกจากนี้ AI ยังชอบ "ช่วย" โดยการฝังค่า key ลงในโค้ดตรง ๆ เพื่อให้รันผ่าน

• เก็บ secret ใน environment variable หรือไฟล์ .env ที่อยู่ใน .gitignore
• ตั้งค่าเครื่องมือ AI ให้ไม่อ่านไฟล์ .env, config/*-local.php หรือไฟล์ key ถ้าเครื่องมือรองรับ
• เวลาแปะ error log ให้ AI ดู ตรวจก่อนว่าไม่มี token, password หรือ connection string ติดไปด้วย

// โค้ดที่ต้องการ: อ่านจาก environment ไม่ฝังในโค้ด
'components' => [
    'db' => [
        'class' => \yii\db\Connection::class,
        'dsn' => getenv('DB_DSN'),
        'username' => getenv('DB_USER'),
        'password' => getenv('DB_PASSWORD'),
        'charset' => 'utf8',
    ],
],

5. ไม่ให้ AI เข้าถึง production

เหตุผล: AI agent ที่รันคำสั่งได้อาจตัดสินใจรัน migration, ลบตาราง หรือ restart service เพื่อ "แก้ปัญหา" ความผิดพลาดบน production ย้อนกลับยากและกระทบผู้ใช้จริง ให้ AI ทำงานกับฐานข้อมูล local หรือ staging ที่ใช้ข้อมูลจำลองเท่านั้น และไม่เก็บ credential ของ production ไว้บนเครื่องที่ agent ทำงาน

กติกา 6–7: จำกัดขอบเขตและคำสั่ง

6. ให้งานทีละเรื่อง ขอบเขตชัด

เหตุผล: prompt อย่าง "ปรับปรุงระบบสมาชิกให้ดีขึ้น" ทำให้ AI แก้กว้างจนตรวจไม่ไหว งานที่ดีควรระบุไฟล์ ฟังก์ชัน และสิ่งที่ห้ามเปลี่ยน

7. อนุมัติคำสั่งที่มีผลกระทบด้วยตัวเอง

เหตุผล: agent หลายตัวถามก่อนรันคำสั่ง อย่ากดอนุญาตทุกอย่างเพื่อความสะดวก โดยเฉพาะคำสั่งกลุ่มนี้

• ลบไฟล์หรือโฟลเดอร์ (rm -rf)
• git push, git reset --hard, git push --force
• migration และคำสั่ง SQL ที่ DROP, DELETE, UPDATE แบบไม่มีเงื่อนไข
• ติดตั้งแพ็กเกจใหม่ (composer require, npm install)
• คำสั่งที่ส่งข้อมูลออกนอกเครื่อง เช่น curl ไปยัง URL ที่ไม่รู้จัก

คำสั่งอ่านอย่างเดียว เช่น ls, git status, รันเทสต์ อนุญาตให้รันอัตโนมัติได้ถ้าเครื่องมือรองรับการตั้งค่าแบบนี้

กติกา 8–9: ทดสอบและตรวจ dependency

8. รันเทสต์ทุกครั้งก่อน commit

เหตุผล: AI บอกว่า "แก้เรียบร้อยแล้ว" ไม่ได้แปลว่าโค้ดทำงานถูก ต้องมีหลักฐานจากการรันจริง ถ้าโปรเจกต์ยังไม่มีเทสต์ ให้เริ่มจากเทสต์ส่วนที่กำลังจะแก้ก่อน

vendor/bin/codecept run unit
# หรือ
vendor/bin/phpunit

อีกเรื่องที่ต้องระวัง: ถ้าเทสต์ fail แล้ว AI เสนอให้แก้เทสต์แทนแก้โค้ด ให้หยุดคิดก่อนเสมอว่าเทสต์ผิดจริงหรือโค้ดผิด เรื่องนี้จะลงลึกในบทความ "TDD กับ AI: เขียนเทสต์ก่อน แล้วให้ AI ทำให้ผ่าน"

9. ตรวจทุก dependency ใหม่

เหตุผล: AI อาจแนะนำแพ็กเกจที่ไม่มีอยู่จริง เลิกดูแลแล้ว หรือชื่อคล้ายแพ็กเกจดังซึ่งอาจเป็นของปลอม ทุกครั้งที่ composer.json หรือ package.json เปลี่ยน ให้ตรวจว่าแพ็กเกจมีจริง มีผู้ดูแล และไลเซนส์ใช้ได้ แล้วรัน

composer audit
npm audit

กติกา 10: คนรับผิดชอบคือเรา

เหตุผล: เมื่อโค้ดถูก merge แล้ว ไม่มีใครสนใจว่าใครพิมพ์ ผู้ใช้สนใจแค่ว่าระบบทำงานถูกหรือไม่ ดังนั้นกติกาสุดท้ายคือ "อย่า merge สิ่งที่อธิบายไม่ได้" ถ้าอ่านโค้ดแล้วไม่เข้าใจ ให้ถาม AI จนเข้าใจ หรือเขียนใหม่ให้เรียบง่ายขึ้น

ในทีม ควรตกลงกันเพิ่มว่า

• Pull request ที่ AI ช่วยเขียนยังต้องผ่าน code review โดยคนอย่างน้อยหนึ่งคน
• ผู้เปิด PR ต้องตอบคำถาม reviewer เกี่ยวกับโค้ดได้เอง ไม่ใช่ตอบว่า "AI เขียน"
• งานที่แตะระบบเงิน การยืนยันตัวตน หรือข้อมูลส่วนบุคคล ต้อง review เข้มเป็นพิเศษ

เช็กลิสต์ติดโต๊ะ

คัดลอกไปใช้ในทีมได้เลย

1. สร้าง branch ใหม่ก่อนเริ่มงานกับ AI
2. Commit ทุกครั้งที่ได้ผลที่ใช้ได้
3. อ่าน git diff ทุกครั้งก่อนรับ
4. ไม่ให้ AI เห็นหรือฝัง secret ในโค้ด
5. ไม่ให้ AI เข้าถึง production
6. ให้งานทีละเรื่อง ระบุไฟล์และสิ่งที่ห้ามแตะ
7. อนุมัติคำสั่งลบ push migration และติดตั้งแพ็กเกจด้วยตัวเอง
8. รันเทสต์ก่อน commit ไม่ยอมให้แก้เทสต์เพื่อให้ผ่าน
9. ตรวจ dependency ใหม่และรัน audit
10. ไม่ merge โค้ดที่อธิบายไม่ได้

สรุป

• Git คือเครื่องมือความปลอดภัยอันดับแรกเวลาทำงานกับ AI: branch แยก commit บ่อย อ่าน diff
• Secret และ production อยู่นอกมือ AI เสมอ
• ขอบเขตงานที่แคบและชัดทำให้ตรวจง่ายและผิดน้อยลง
• เทสต์และ audit คือหลักฐาน คำว่า "เสร็จแล้ว" จาก AI ไม่ใช่หลักฐาน
• ความรับผิดชอบต่อโค้ดยังเป็นของคนที่กด merge

ลองทำ

เปิดโปรเจกต์ที่คุณดูแลอยู่ แล้วทำ "การซ้อมรับมือ" สั้น ๆ

1. ตรวจว่า .gitignore ครอบคลุมไฟล์ secret ทั้งหมดหรือยัง ด้วย git ls-files | grep -i -E "env|local|key"
2. สร้าง branch ai/practice ให้ AI แก้ bug เล็ก ๆ หนึ่งจุด โดยระบุไฟล์และสิ่งที่ห้ามแตะ
3. ดู git diff --stat แล้วนับว่า AI แก้ไฟล์เกินที่ขอหรือไม่
4. รันเทสต์ ถ้าผ่านให้ commit ถ้าไม่ผ่านให้ลองย้อนกลับด้วย git restore .
5. เขียนกติกาที่เหมาะกับทีมของคุณเพิ่มอีก 1–2 ข้อจากประสบการณ์ครั้งนี้