Senior Developer ยุค AI: บทบาทที่เปลี่ยนไป

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

จากคนเขียนโค้ดเก่งที่สุด สู่คนที่ทำให้ระบบไปถูกทาง

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

AI ตอบคำถาม "ทำอย่างไร" ได้ดีขึ้นเรื่อย ๆ แต่คำถาม "ควรทำไหม" และ "ทำแบบไหนจึงเหมาะกับทีมนี้ ระบบนี้ ลูกค้ารายนี้" ยังต้องอาศัยบริบทที่ AI ไม่มี ทั้งประวัติของระบบ ข้อจำกัดทางธุรกิจ ความสามารถของทีม และสิ่งที่เคยพังมาก่อน

บทบาทที่ 1: ออกแบบระบบ

เมื่อการเขียนโค้ดเร็วขึ้น การออกแบบที่ผิดตั้งแต่ต้นก็สร้างโค้ดที่ผิดได้เร็วขึ้นด้วย senior จึงต้องลงทุนเวลากับการคิดก่อนลงมือมากขึ้น ได้แก่ การแบ่ง module และขอบเขตความรับผิดชอบ การออกแบบ schema ฐานข้อมูล การกำหนดสัญญาระหว่างส่วนต่าง ๆ เช่น API และ event และการเลือกว่าจะไม่ทำอะไร

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

# ADR-012: ใช้ PostgreSQL full-text search แทน search engine แยก
สถานะ: อนุมัติ
บริบท: ต้องการค้นหาบทความ ข้อมูลยังไม่มาก ทีมมีคนดูแล infra จำกัด
ทางเลือกที่พิจารณา:
  1. PostgreSQL full-text search (มีอยู่แล้ว ไม่เพิ่มระบบใหม่)
  2. ติดตั้ง search engine แยก (ความสามารถสูงกว่า แต่ต้องดูแลเพิ่ม)
การตัดสินใจ: เลือกข้อ 1
ผลที่ตามมา: ฟีเจอร์ค้นหาขั้นสูงบางอย่างทำไม่ได้
ทบทวนเมื่อ: ปริมาณข้อมูลหรือความต้องการค้นหาเปลี่ยนไปอย่างมีนัยสำคัญ

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

บทบาทที่ 2: กำหนดมาตรฐาน

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

• coding standard ที่ตรวจด้วยเครื่อง เช่น ตั้ง linter และ formatter ใน CI
• static analysis ที่ช่วยจับ type error และโค้ดที่ไม่ถูกเรียกใช้
• เอกสาร convention ของโปรเจกต์ เช่น โครงสร้างโฟลเดอร์ วิธีจัดการ error วิธีเขียน migration ซึ่งเครื่องมือ AI หลายตัวอ่านเป็น context ได้
• ตัวอย่างโค้ดต้นแบบ หนึ่งฟีเจอร์ที่ทำ "ถูกทาง" ครบทุกชั้น ให้ทั้งคนและ AI ใช้เลียนแบบ
• AI Policy ของทีม ว่าใช้เครื่องมืออะไร ส่งข้อมูลอะไรได้ และรีวิวอย่างไร

มาตรฐานที่ดีทำให้ AI เป็นตัวช่วยที่ดีขึ้นทันที เพราะ AI เลียนแบบสิ่งที่เห็นเก่งมาก ถ้าเห็นของดีก็ทำของดีตาม

บทบาทที่ 3: รีวิวโค้ด

เมื่อปริมาณโค้ดเพิ่มขึ้น งานรีวิวก็เพิ่มตาม และโค้ดจาก AI มีลักษณะเฉพาะที่ต้องรู้ คือมักดูเรียบร้อยและมั่นใจ แต่อาจมีปัญหาที่มองไม่เห็นจากผิวนอก เช่น เรียก method ที่ไม่มีอยู่จริง ข้ามการตรวจสิทธิ์ จัดการ error แบบกลืนทิ้ง หรือเพิ่ม dependency โดยไม่จำเป็น

เทคนิคสำหรับ senior ในการรีวิวยุคนี้

• รีวิวการออกแบบก่อนรีวิวบรรทัด ถามก่อนว่าแนวทางถูกไหม ก่อนจะไปดูชื่อตัวแปร
• โฟกัสจุดเสี่ยง auth สิทธิ์ การจัดการข้อมูลผู้ใช้ query ที่สร้างจาก input และการเรียกบริการภายนอก
• ขอให้ผู้เปิด PR อธิบาย ถ้าเขาอธิบายโค้ดส่วนหนึ่งไม่ได้ แสดงว่ายังไม่พร้อม merge
• ให้เครื่องตรวจสิ่งที่เครื่องตรวจได้ lint, test, static analysis และ secret scanning ใน CI เพื่อให้คนเหลือเวลาคิดเรื่องที่ซับซ้อน
• จำกัดขนาด PR PR ที่ใหญ่เกินไปจะถูกรีวิวแบบผ่าน ๆ เสมอ ไม่ว่าใครรีวิว

บทบาทที่ 4: ฝึกน้องในทีม

ความท้าทายใหม่ของการเป็นพี่เลี้ยงคือ junior สามารถส่งงานที่ "ดูเสร็จ" ได้โดยยังไม่เข้าใจมัน ถ้าเราดูแค่ผลลัพธ์ เราอาจไม่รู้เลยว่าน้องยังขาดพื้นฐานตรงไหน จนวันที่เกิดปัญหาจริงใน production

วิธีที่ช่วยได้

• ในการรีวิว ถามคำถามที่ทำให้น้องต้องอธิบาย เช่น "ถ้า input ตรงนี้ว่าง จะเกิดอะไรขึ้น"
• จัด pairing session ที่ senior กับ junior ใช้ AI ด้วยกัน ให้น้องเห็นว่าเราตั้งคำถาม ตรวจสอบ และปฏิเสธคำตอบของ AI อย่างไร
• มอบงานที่มีโจทย์ด้านการตัดสินใจ ไม่ใช่แค่งานเขียนตาม ticket เช่น ให้เปรียบเทียบสองแนวทางแล้วนำเสนอ
• แบ่งปันเรื่องที่เราเคยพลาด ประสบการณ์แบบนี้ AI ให้ไม่ได้

บทบาทที่ 5: ตัดสินใจเรื่องความเสี่ยง

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

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

สรุป

• ความต่างของ senior ในยุค AI อยู่ที่วิจารณญาณ ไม่ใช่ความเร็วในการพิมพ์
• ลงทุนกับการออกแบบและบันทึกการตัดสินใจเป็น ADR ซึ่งยังใช้เป็น context ให้ AI ได้ด้วย
• ทำมาตรฐานให้เขียนไว้และตรวจได้ด้วยเครื่อง เพราะ AI เลียนแบบสิ่งที่เห็น
• รีวิวที่การออกแบบและจุดเสี่ยงก่อน และฝึกน้องให้อธิบายงานของตัวเองได้
• ใช้กรอบคิดเรื่องความเสียหาย การย้อนกลับ และข้อมูลที่ออกนอกองค์กร เพื่อตัดสินใจเรื่องความเสี่ยงอย่างสม่ำเสมอ

ลองทำ

เลือกการตัดสินใจทางเทคนิคหนึ่งเรื่องที่ทีมของคุณทำไปแล้วแต่ไม่เคยเขียนบันทึก เช่น ทำไมเลือกใช้ queue แบบนี้ หรือทำไมไม่ใช้ ORM ในบางส่วน แล้วเขียนเป็น ADR ตามแบบด้านบนไม่เกินครึ่งหน้า จากนั้นลองแนบ ADR นี้เป็น context ให้ AI แล้วขอให้มันออกแบบฟีเจอร์ที่เกี่ยวข้อง เทียบกับตอนไม่แนบ ดูว่าคำตอบต่างกันอย่างไร