ธนาคารห้าม junior ใช้ AI เขียนโค้ด: ระวังให้ถูกที่ หรือแค่ทำให้ทีมช้าลง

ช่วงนี้ในไทม์ไลน์ผมมีหัวข้อหนึ่งวนขึ้นมาบ่อยครับ ว่าธนาคารเริ่ม "ห้าม junior ใช้ AI เขียนโค้ด"

พอไล่อ่านจริง ๆ ภาพมันซับซ้อนกว่าพาดหัว ข่าวที่ผมตามไปอ่านเจอและมีหลายสำนักรายงานตรงกัน คือธนาคารใหญ่อย่าง Goldman Sachs จำกัดการใช้ AI coding tool ขั้นสูงให้เหลือเฉพาะวิศวกร หลังจากเคยเปิดให้คนสายอื่นอย่าง banker และ trader ใช้มาระยะหนึ่ง เหตุผลที่ให้ไว้คือชั่งระหว่าง productivity กับความเสี่ยง ซึ่งเรื่องนี้เป็นการจำกัดตาม "บทบาท" ไม่ใช่ตาม "ความอาวุโส" ส่วนเรื่องที่ว่าธนาคารไหนห้าม junior developer โดยเฉพาะ ผมยังหาแหล่งที่ยืนยันได้ไม่เจอ เลยขอพูดแบบกว้าง ๆ ว่ามีกระแสว่าองค์กรสายการเงินบางแห่งเริ่มคุมเข้มว่าใครใช้ AI เขียนโค้ดได้แค่ไหน และในวงคุยของคนทำซอฟต์แวร์ คำถามก็ไหลไปที่ junior ทันที

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

ผมเป็นทั้ง developer, PM และ PO ที่ Mulberrysoft ดูแลทีม junior สี่ทีม ใช้ Claude, Codex และ agent อื่น ๆ ทุกวัน และเขียนซีรีส์ Critical Thinking มาหลายตอน ตั้งแต่การให้ agent ทำงานแทนโดยไม่ให้มันคิดแทน ไปจนถึงนิสัยการ verify และ paradox of supervision โพสต์นี้เป็นคำถามที่ต่อจากตอนหลังโดยตรง ถ้าทักษะที่ใช้คุม agent คือทักษะเดียวกับที่หายไปเมื่อใช้ agent มากเกินไป แล้วคนที่ยังไม่มีทักษะนั้นตั้งแต่แรกล่ะ ควรให้ใช้ไหม

จุดยืนของผมสั้น ๆ คือ การห้ามแก้ปัญหาที่ถูก แต่ด้วยเครื่องมือที่ผิด ความเสี่ยงที่องค์กรกลัวนั้นมีจริง แต่การห้ามแบบเหมารวมมักย้ายความเสี่ยงไปอยู่ในที่ที่มองไม่เห็น แทนที่จะลดมัน

วันที่ผมเกือบประกาศห้าม

เมื่อต้นปี น้องคนหนึ่งในทีมส่ง PR ฟีเจอร์ export รายงานเป็น CSV มาให้รีวิว โค้ดสะอาด มี test ผ่านหมด ตั้งชื่อตัวแปรดีกว่าที่น้องเคยเขียนเองเสียอีก

ผมถามคำถามเดียวครับ "ถ้าข้อมูลมีสักห้าแสนแถว ฟังก์ชันนี้จะเกิดอะไรขึ้น"

น้องเงียบไปพักหนึ่ง แล้วตอบว่า "เดี๋ยวผมลองถาม AI ดูครับ"

คำตอบนั้นไม่ได้ทำให้ผมโกรธนะครับ แต่ทำให้ผมนั่งนิ่งไปนาน เพราะมันบอกว่าโค้ดที่อยู่ตรงหน้าไม่มีเจ้าของ น้องไม่ได้เขียนมัน ไม่ได้อ่านมันจริงจัง และไม่รู้ว่ามันโหลดทุกแถวเข้า memory ก่อนเขียนไฟล์ ซึ่งในระบบของลูกค้าเจ้านั้น รายงานบางเดือนใหญ่พอจะทำให้เซิร์ฟเวอร์ล้มได้

คืนนั้นผมร่างข้อความใน Slack ไว้แล้วว่า "ตั้งแต่สัปดาห์หน้า ทีม junior งดใช้ AI เขียนโค้ดใน production ก่อนนะครับ" แต่ไม่ได้กดส่ง

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

ทำไมองค์กรที่ถูกกำกับดูแลถึงอยากห้าม

ก่อนจะวิจารณ์ ผมอยากให้เครดิตฝั่งที่ระวังก่อนครับ เพราะเหตุผลของเขาไม่ได้ไร้สาระเลย และหลายข้อผมเจอเองในงาน software house ที่ไม่ได้ถูกกำกับเข้มเท่าธนาคารด้วยซ้ำ

ทักษะไม่ได้ถูกสร้างตั้งแต่แรก คนที่ทำงานมาสิบปีแล้วเริ่มใช้ AI เสี่ยงทักษะ "เสื่อม" ซึ่งยังพอดึงกลับได้ แต่ junior ที่เริ่มต้นอาชีพมาพร้อม AI เสี่ยงกับสิ่งที่แย่กว่า คือทักษะนั้นไม่เคยถูกสร้างขึ้นเลย การ debug เป็นการสร้าง mental model ของระบบ ถ้าทุกครั้งที่ติดคือถามแล้วแปะ model นั้นจะไม่เกิด และวันที่ AI ตอบผิดแบบมั่นใจ ซึ่งเกิดแน่ ๆ คนคนนั้นจะไม่มีเครื่องมืออะไรไว้จับมันเลย ผมเขียนเรื่องนี้ไว้ละเอียดในโพสต์ comprehension debt

โค้ดที่ไม่มีใครรีวิวจริง ในองค์กรที่มี segregation of duties คนเขียนกับคนอนุมัติต้องเป็นคนละคน แต่ถ้าคนเขียนจริง ๆ คือ AI และคนที่กดส่งก็ไม่ได้อ่าน แปลว่าเหลือคนอ่านแค่คนเดียวคือ reviewer ซึ่งก็มักจะเห็นแค่ diff และ test สีเขียว การควบคุมสองชั้นกลายเป็นชั้นเดียวโดยไม่มีใครตั้งใจ

ข้อมูลรั่วออกนอกองค์กร junior มักยังแยกไม่ออกว่าอะไรวางลงใน prompt ได้ อะไรไม่ได้ log ที่มีข้อมูลลูกค้า connection string ใน config ตัวอย่าง payload จริงจาก production ทุกอย่างถูกแปะลงไปด้วยความตั้งใจดีว่าอยากให้ AI เข้าใจปัญหา

ช่องโหว่ที่ดูเหมือนโค้ดปกติ โค้ดจาก AI มักผ่าน happy path ได้สวย แต่เรื่องอย่าง authorization ที่ขาดไปหนึ่งเงื่อนไข input ที่ไม่ถูก validate หรือ dependency ที่ชื่อคล้ายของจริงแต่ไม่ใช่ เป็นสิ่งที่คนมีประสบการณ์มองหา ส่วนคนที่ยังไม่มีประสบการณ์ไม่รู้ด้วยซ้ำว่าต้องมองหา

ความรับผิดชอบต้องชี้ตัวได้ ในอุตสาหกรรมที่ต้องตอบ auditor ได้ว่าโค้ดบรรทัดนี้ใครเป็นคนตัดสินใจ คำตอบว่า "AI เขียนครับ" ใช้ไม่ได้ องค์กรต้องการคนที่อธิบายได้ว่าทำไมมันถึงเป็นแบบนี้

ทุกข้อจริงครับ และถ้าผมเป็น CTO ของธนาคาร ผมก็คงนอนไม่หลับกับมันเหมือนกัน

แต่การห้ามมีราคาที่ไม่ขึ้นบนรายงาน

ปัญหาของการห้ามคือมันวัดความสำเร็จง่ายเกินไปครับ เปิดนโยบาย ประกาศ ทุกคนรับทราบ ตัวเลขการใช้งานในเครื่องมือขององค์กรลดเหลือศูนย์ ดูเหมือนสำเร็จ แต่ราคาจริงไปเกิดในที่ที่ไม่มีใครวัด

Shadow AI นี่คือราคาที่ใหญ่ที่สุด junior ไม่ได้เลิกใช้ AI เพราะถูกห้าม เขาแค่เลิกใช้ในที่ที่องค์กรเห็น เปลี่ยนไปใช้บัญชีส่วนตัว บนโทรศัพท์ หรือในเบราว์เซอร์อีกตัว ซึ่งแย่กว่าเดิมทุกมิติ ข้อมูลยังรั่วเหมือนเดิมแต่ไปอยู่ในบริการที่องค์กรไม่ได้ทำสัญญาด้วย โค้ดยังมาจาก AI เหมือนเดิมแต่ไม่มีใครรู้ และที่แย่ที่สุดคือ reviewer จะรีวิวโดยเชื่อว่าน้องเขียนเอง จึงตั้งคำถามน้อยลง

ช่องว่างระหว่างรุ่นถ่างออก ถ้า senior ใช้ได้แต่ junior ใช้ไม่ได้ senior ก็จะเร็วขึ้นเรื่อย ๆ ส่วน junior ไม่ได้ฝึกทักษะที่ตลาดจะต้องการในอีกสองสามปีข้างหน้า คือการสั่งงาน ตั้งขอบเขต และตรวจงานของ AI ทักษะนั้นไม่ได้เกิดเองในวันที่เลื่อนขั้นเป็น senior มันต้องฝึกตั้งแต่ตอนที่ความผิดพลาดยังราคาถูก

junior ช้าลงในงานที่ไม่ได้ช่วยให้เก่งขึ้น งานบางอย่างไม่ได้สร้างทักษะอะไรเลย เช่น เขียน mapping ระหว่าง DTO สิบกว่าฟิลด์ หรือแปลงข้อมูลทดสอบจาก JSON เป็น SQL การบังคับให้ทำด้วยมือไม่ได้ทำให้ใครเข้าใจระบบมากขึ้น แค่ทำให้เหนื่อยและเบื่อเร็วขึ้น

สัญญาณที่ส่งออกไปผิด การห้ามเฉพาะ junior บอกน้องว่า "เราไม่ไว้ใจคุณ" แต่ไม่ได้บอกว่า "ต้องทำอะไรถึงจะได้รับความไว้ใจ" มันเป็นกำแพง ไม่ใช่บันได

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

ทางกลางที่ผมใช้กับสี่ทีม

หลังคืนที่ไม่ได้กดส่งข้อความนั้น ผมใช้เวลาสองสัปดาห์คุยกับ lead ของแต่ละทีม แล้วค่อย ๆ ตั้งกติกาที่ใช้มาจนตอนนี้ หลักใหญ่มีอยู่ข้อเดียว

ไม่ได้คุมว่าใครใช้ AI ได้ แต่คุมว่าใช้กับงานแบบไหน และต้องพิสูจน์อะไรก่อน merge

กติกาข้อแรก: อธิบายไม่ได้ เท่ากับยังไม่เสร็จ

นี่คือกติกาเดียวที่ไม่มีข้อยกเว้นครับ ใครจะเขียนเอง ให้ AI เขียน หรือก๊อปจาก Stack Overflow ก็ตาม ถ้าตอนรีวิวอธิบายไม่ได้ว่าโค้ดทำอะไร ทำไมถึงเลือกแบบนี้ และจะพังได้ยังไง PR นั้นถือว่ายังไม่เสร็จ

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

ในทางปฏิบัติ reviewer ในทีมผมจะเลือกบล็อกโค้ดที่ซับซ้อนที่สุดใน PR มาหนึ่งจุด แล้วถามสามคำถาม

1. บรรทัดนี้ทำอะไร ถ้าลบออกจะเกิดอะไรขึ้น
2. มีทางเลือกอื่นไหม ทำไมไม่เลือกแบบนั้น
3. input แบบไหนที่จะทำให้มันพัง

ถ้าน้องตอบได้ ผมไม่สนใจว่าโค้ดมาจากไหน ถ้าตอบไม่ได้ ก็กลับไปทำความเข้าใจแล้วมาคุยกันใหม่ ไม่มีการลงโทษ ไม่มีการตำหนิ แค่ยังไม่ merge

กติกาข้อสอง: บอกตรง ๆ ว่าใช้ AI ตรงไหน

ใน PR template ของทีมผมมีช่องหนึ่งที่เพิ่มเข้ามา

## AI ช่วยตรงไหน
- [ ] ไม่ได้ใช้
- [ ] ใช้ช่วยอธิบาย / หาข้อมูล / debug แต่เขียนเอง
- [ ] ใช้ร่างโค้ดบางส่วน (ระบุไฟล์หรือฟังก์ชัน):
- [ ] ใช้ร่างโค้ดส่วนใหญ่

ส่วนที่ AI ร่าง ผมตรวจอะไรไปแล้วบ้าง:
ส่วนที่ยังไม่มั่นใจและอยากให้ reviewer ดูเป็นพิเศษ:

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

และกติกานี้จะได้ผลก็ต่อเมื่อการบอกว่าใช้ไม่ทำให้น้องเดือดร้อน ถ้าวันไหนที่ติ๊กช่อง "ใช้ร่างโค้ดส่วนใหญ่" แล้วโดนมองแปลก ๆ วันรุ่งขึ้นทุกคนจะติ๊ก "ไม่ได้ใช้" ทันที ผมเลยติ๊กช่องนี้ใน PR ของตัวเองให้ทีมเห็นทุกครั้งเหมือนกัน

กติกาข้อสาม: เรียนก่อน แล้วค่อยเร่ง

สำหรับน้องที่เพิ่งเข้ามา หรือน้องที่กำลังเรียนเทคโนโลยีใหม่ ผมใช้กติกาที่เรียกในทีมว่า "ลองเองก่อนสามสิบนาที"

เมื่อติดปัญหา ให้ลองเองก่อนอย่างน้อยสามสิบนาที อ่าน error อ่านเอกสาร ใส่ log ตั้งสมมติฐาน หลังจากนั้นถาม AI ได้ แต่ให้ถามแบบนี้

ผมกำลังแก้ปัญหานี้: [อธิบาย]
สิ่งที่ลองไปแล้ว: [ระบุ]
สมมติฐานของผมคือ: [ระบุ]

อย่าเพิ่งเขียนโค้ดแก้ให้
ช่วยบอกว่าสมมติฐานผมถูกหรือผิดตรงไหน
และควรไปดูส่วนไหนของระบบต่อ

ความต่างระหว่าง "แก้ให้หน่อย" กับ prompt ข้างบน คือคนที่ใช้ prompt แบบหลังยังเป็นคนแก้ปัญหาอยู่ AI แค่เป็นพี่เลี้ยงที่ว่างตลอดเวลา และหลายครั้งพอน้องเขียนช่อง "สมมติฐานของผมคือ" เสร็จ ก็เจอคำตอบเองก่อนจะกดส่งด้วยซ้ำ

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

กติกาข้อสี่: ข้อมูลอะไรห้ามออกจากเครื่อง

ข้อนี้ผมไม่ต่อรองเลยครับ และใช้กับทุกคนในทีมรวมทั้งตัวผมเอง

• ใช้เฉพาะเครื่องมือและบัญชีที่บริษัทจัดให้ ซึ่งตรวจเงื่อนไขเรื่องการเก็บและนำข้อมูลไปใช้แล้ว
• ห้ามวางข้อมูลจริงของลูกค้า ข้อมูลส่วนบุคคล log จาก production secret key หรือ connection string ลงใน prompt
• ถ้าต้องการให้ AI เห็นโครงสร้างข้อมูล ให้ใช้ข้อมูลตัวอย่างที่สร้างขึ้นเอง
• โปรเจกต์ไหนที่สัญญากับลูกค้าห้ามใช้ AI ภายนอก ก็ไม่ใช้ ไม่ว่าจะเป็น junior หรือ senior

ข้อสุดท้ายสำคัญครับ ลูกค้าบางเจ้าของเราเป็นองค์กรที่ถูกกำกับดูแล และมีเงื่อนไขในสัญญาเรื่องนี้ชัดเจน กติกาตรงนี้ไม่ได้มาจากความอาวุโสของคนใช้ แต่มาจากความอ่อนไหวของข้อมูล

งานไหนให้ใช้ได้แค่ไหน

สิ่งที่ช่วยทีมผมมากที่สุดคือการเลิกถามว่า "junior ใช้ AI ได้ไหม" แล้วเปลี่ยนเป็น "งานนี้ ถ้าผิด แพงแค่ไหน และคนทำมีเครื่องมือพอจะจับความผิดไหม"

ผมแบ่งงานเป็นสามโซนครับ

โซนเขียว: ใช้ได้เต็มที่ งานที่ผิดแล้วเห็นทันทีและแก้ถูก หรืองานที่ไม่ได้สร้างทักษะอะไร เช่น เขียน test data, boilerplate, ร่าง unit test สำหรับโค้ดที่เขียนเองแล้ว, แปลง format ข้อมูล, อธิบายโค้ดเก่าที่ไม่มีใครจำได้, สคริปต์ใช้ครั้งเดียวบนเครื่องตัวเอง

โซนเหลือง: ใช้ได้ แต่ต้องอธิบายได้และรีวิวเข้ม งาน feature ทั่วไปที่ขึ้น production แต่ไม่แตะเรื่องอ่อนไหว เช่น หน้าจอ CRUD, API ภายในที่ไม่เกี่ยวกับเงินหรือสิทธิ์, refactor ที่มี test คลุม กติกาข้อหนึ่งถึงสามใช้เต็ม ๆ ในโซนนี้

โซนแดง: AI ช่วยคิดและตรวจได้ แต่คนต้องเป็นคนเขียนและมี senior ร่วมรีวิว งานที่ผิดแล้วแพงหรือย้อนคืนยาก เช่น authentication และ authorization, การคำนวณเงินหรือแต้ม, migration ที่แก้ข้อมูลจริง, การเข้ารหัส, การเชื่อมต่อ payment หรือระบบภายนอกที่มีผลทางกฎหมาย

สังเกตว่าโซนแดงไม่ได้ห้ามใช้ AI นะครับ AI ช่วยได้มากในการหาช่องโหว่ ไล่ edge case หรือตั้งคำถามกับ design ที่เราเลือก แต่คนที่ตัดสินใจและพิมพ์โค้ดส่วนที่สำคัญต้องเป็นคน และกติกาโซนแดงนี้ผมใช้กับ senior ด้วย ไม่ใช่แค่ junior

แล้วความอาวุโสอยู่ตรงไหน คำตอบคือ มันเป็นตัวกำหนดว่าใครเลื่อนงานจากโซนเหลืองเข้าโซนเขียวได้เอง senior ที่เคยทำระบบส่วนนั้นมาแล้วตัดสินได้ว่างานชิ้นนี้ความเสี่ยงต่ำพอ ส่วน junior ต้องถาม lead ก่อน เพราะการประเมินว่าอะไรเสี่ยง ก็เป็นทักษะที่ต้องสร้างเหมือนกัน

บันได ไม่ใช่กำแพง

สิ่งที่ผมพยายามแก้จากสัญญาณผิดของการห้าม คือทำให้น้องเห็นว่าต้องทำอะไรถึงจะได้อิสระมากขึ้น ในทีมผมจึงมีระดับคร่าว ๆ ที่ lead แต่ละทีมใช้ร่วมกัน

ระดับเริ่มต้น ใช้ AI ในโซนเขียวได้ ในโซนเหลืองใช้ได้แบบพี่เลี้ยงตามกติกาสามสิบนาที ทุก PR มีการรีวิวแบบถามสามคำถาม

ระดับกลาง เมื่อตอบคำถามรีวิวได้สม่ำเสมอ และเคยจับความผิดพลาดของ AI ได้เองอย่างน้อยสองสามครั้ง ก็ใช้ AI ร่างโค้ดในโซนเหลืองได้เต็มที่ reviewer ถามสามคำถามแบบสุ่มแทนทุก PR

ระดับไว้ใจ เมื่อรีวิว PR ที่ AI ร่างของคนอื่นได้ และชี้ปัญหาที่ test ไม่จับได้ ก็เลื่อนงานระหว่างโซนได้เอง และช่วย lead ดูแลน้องที่อยู่ระดับเริ่มต้น

เกณฑ์ข้อที่ผมให้น้ำหนักมากที่สุดคือ "เคยจับความผิดพลาดของ AI ได้เอง" เพราะมันเป็นหลักฐานที่ดีที่สุดว่าคนคนนั้นไม่ได้แค่ยอมรับคำตอบ ผมเคยเขียนเรื่องวันที่คำตอบของ agent กลายเป็นความเห็นของเรา ไว้ และนี่คือวิธีวัดแบบง่ายที่สุดที่ผมคิดออกว่าใครยังไม่ยอมจำนน

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

สิ่งที่เปลี่ยนไปหลังใช้กติกานี้

ผมไม่มีตัวเลขสวย ๆ มาอวดครับ และไม่อยากแต่งตัวเลขขึ้นมาด้วย แต่มีสามอย่างที่ผมสังเกตเห็นชัด

อย่างแรก การรีวิวยาวขึ้นในช่วงแรก แล้วสั้นลง ช่วงเดือนแรก ๆ ทุกคนบ่นว่ารีวิวช้า เพราะต้องคุยกันจริง แต่พอน้องรู้ว่าจะโดนถามอะไร เขาก็เตรียมตัวมาก่อน อ่านโค้ดที่ AI ร่างอย่างจริงจังก่อนเปิด PR และหลายครั้งแก้ปัญหาเองก่อนผมจะเห็น

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

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

Template นโยบาย AI สำหรับหัวหน้าทีม

ผมรวบรวมทั้งหมดข้างบนเป็น template ที่ lead ในทีมผมใช้เป็นจุดตั้งต้นครับ ไม่จำเป็นต้องใช้ทุกข้อ และองค์กรที่ถูกกำกับดูแลเข้มกว่าเราก็คงต้องเพิ่มอีกหลายข้อ แต่อยากให้ทุกข้อที่ตัดออกเป็นการตัดที่ตั้งใจ

# นโยบายการใช้ AI coding tool ของทีม [ชื่อทีม]

ปรับปรุงล่าสุด: [วันที่]  ผู้ดูแล: [lead]

## หลักการ
- ทุกคนใช้ AI ได้ ความต่างอยู่ที่ประเภทงานและสิ่งที่ต้องพิสูจน์ก่อน merge
- คนที่เปิด PR คือเจ้าของโค้ด ไม่ว่าใครหรืออะไรเป็นคนร่าง
- อธิบายไม่ได้ = ยังไม่เสร็จ

## เครื่องมือและข้อมูล
- เครื่องมือที่อนุญาต: [รายชื่อ + บัญชีองค์กร]
- ห้ามวางลง prompt: ข้อมูลลูกค้าจริง, ข้อมูลส่วนบุคคล, log จาก production,
  secret / key / connection string, โค้ดของโปรเจกต์ที่สัญญาห้ามใช้ AI ภายนอก
- โปรเจกต์ที่ห้ามใช้ AI ภายนอก: [รายชื่อ]

## โซนงาน
- เขียว (ใช้ได้เต็มที่): [ตัวอย่างของทีม]
- เหลือง (ใช้ได้ อธิบายได้ รีวิวเข้ม): [ตัวอย่างของทีม]
- แดง (คนเขียน + senior รีวิวร่วม): [ตัวอย่างของทีม]
- ใครเลื่อนงานระหว่างโซนได้: [ระดับไว้ใจ / lead]

## ระดับ
- เริ่มต้น / กลาง / ไว้ใจ: [เกณฑ์ของแต่ละระดับ]
- ทบทวนระดับทุก: [เช่น ทุกไตรมาส ใน 1:1]

## การรีวิว
- PR template มีช่อง "AI ช่วยตรงไหน"
- reviewer เลือกบล็อกที่ซับซ้อนที่สุด ถามสามคำถาม:
  ทำอะไร / ทำไมเลือกแบบนี้ / พังได้ยังไง
- โค้ดที่ AI ร่างในโซนแดง ต้องมี reviewer อย่างน้อยหนึ่งคนที่ไม่ได้ใช้ AI ช่วยรีวิว

## เมื่อมีปัญหา
- พบข้อมูลหลุดเข้า prompt: แจ้ง [ช่องทาง] ภายใน [เวลา] ไม่มีการลงโทษถ้าแจ้งเอง
- พบโค้ดจาก AI ที่ก่อปัญหาใน production: ทำ postmortem แบบไม่หาคนผิด
  และปรับโซน / กติกาตามสิ่งที่เรียนรู้

และนี่คือ checklist ที่ผมใช้เวลาจะตัดสินใจเรื่อง AI กับทีม junior ครับ

ก่อนตั้งนโยบาย

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

ตอนตั้งกติกา

• คุมตามประเภทงานและความอ่อนไหวของข้อมูล ไม่ใช่ตามตำแหน่งอย่างเดียว
• กติกาโซนแดงใช้กับทุกคน รวมทั้ง senior และตัวเราเอง
• มีเกณฑ์ที่ชัดว่าต้องทำอะไรถึงได้อิสระมากขึ้น
• แยกช่วงเรียนรู้กับช่วงทำงานจริง ช่วงเรียนให้ใช้ AI แบบพี่เลี้ยง ไม่ใช่แบบคนเขียนแทน
• ระบุให้ชัดว่าข้อมูลอะไรห้ามเข้า prompt พร้อมตัวอย่างจริงของทีม

ระหว่างใช้งาน

• PR template มีช่องให้บอกว่า AI ช่วยตรงไหน และ lead ติ๊กช่องนี้ใน PR ของตัวเองด้วย
• รีวิวด้วยคำถามว่าเข้าใจไหม ไม่ใช่แค่ดู diff และ test
• สังเกตว่าน้องคนไหนพึ่ง AI ในเรื่องที่ควรเรียนเอง แล้วคุยใน 1:1 ไม่ใช่ในที่สาธารณะ
• ชมเมื่อมีคนจับความผิดพลาดของ AI ได้ ให้ทีมเห็นว่านี่คือทักษะที่มีค่า
• การแจ้งเองว่าทำข้อมูลหลุดหรือใช้ผิดกติกา ต้องไม่ถูกลงโทษ ไม่อย่างนั้นจะไม่มีใครแจ้ง

ทบทวนเป็นระยะ

• ทบทวนโซนงานเมื่อเครื่องมือเปลี่ยน หรือเมื่อมีเหตุการณ์ที่สอนอะไรเราใหม่
• ทบทวนระดับของแต่ละคนใน 1:1 ตามรอบที่ตกลงกันไว้
• ถามทีมตรง ๆ ว่ากติกาไหนทำให้ช้าโดยไม่ได้ช่วยอะไร แล้วกล้าตัดทิ้ง

ท้ายที่สุด

ผมไม่คิดว่าองค์กรที่ระวังเรื่องนี้ผิดครับ ถ้าต้องเลือกระหว่างองค์กรที่ระวังเกินไปกับองค์กรที่ไม่ระวังเลย ผมเลือกแบบแรก โดยเฉพาะในระบบที่ถือเงินของคนอื่นอยู่

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

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

ข้อความใน Slack ที่ผมร่างไว้คืนนั้นยังอยู่ในโฟลเดอร์ draft ครับ ผมไม่ได้ลบ เก็บไว้เตือนตัวเองว่าวันที่เหนื่อยและกลัว การปิดประตูง่ายกว่าการสร้างบันไดเสมอ

แต่คนที่จะเดินขึ้นบันไดนั้นได้ คือคนที่เราจะต้องพึ่งพาในวันหน้าครับ