- Coding agent สร้างโค้ดได้ด้วยความเร็วที่ไม่เคยมีมาก่อน แต่หากนำไปใช้โดยขาดวิจารณญาณที่เข้มงวด มันก็จะกลายเป็นเส้นทางที่มีประสิทธิภาพในการนำสมมติฐานที่ผิดพลาดขึ้นสู่โปรดักชัน
- โค้ดที่เอเจนต์สร้างขึ้นมักมาพร้อมคำอธิบาย PR, ผ่านการวิเคราะห์แบบสถิต และมี test coverage จนดู เหมือนเขียนโดยวิศวกรที่มีประสบการณ์ แต่ในความเป็นจริงกลับไม่สะท้อนรูปแบบทราฟฟิก โหมดความล้มเหลว และข้อจำกัดของโครงสร้างพื้นฐานในสภาพแวดล้อมโปรดักชันเลย
- การ ใช้ประโยชน์ (leveraging) จาก AI กับการ พึ่งพา (relying) AI เป็นคนละเรื่องโดยสิ้นเชิง และการใช้ประโยชน์อย่างแท้จริงหมายถึงการเข้าใจและเป็นเจ้าของวิธีการทำงานกับความเสี่ยงของผลลัพธ์จากเอเจนต์อย่างครบถ้วน
- ด้วยหลักการสามข้อคือ การดีพลอยแบบขับเคลื่อนตัวเอง, การตรวจสอบอย่างต่อเนื่อง, และราวป้องกันที่บังคับใช้ได้จริง เราสามารถสร้างสภาพแวดล้อมที่เอเจนต์ทำงานด้วยความเป็นอิสระสูงได้โดยยังคงปลอดภัย
- ยุคนี้ไม่ใช่ยุคของวิศวกรที่สร้างโค้ดได้มากที่สุดอีกต่อไป แต่เป็นยุคของวิศวกรที่ยังคงมี วิจารณญาณอันเฉียบคมต่อสิ่งที่ควรดีพลอย
ปัญหา: Green CI ไม่ได้เป็นหลักฐานของความปลอดภัยอีกต่อไป
- การที่ CI ผ่าน สะท้อนเพียงว่าเอเจนต์สามารถทำให้ pipeline ยอมรับได้ ไม่ได้เกี่ยวข้องกับความปลอดภัยของโครงสร้างพื้นฐานจริง
- สามารถดีพลอยคิวรีที่ผ่านการทดสอบ แต่ไปสแกนทั้งตารางในโปรดักชันได้
- ลอจิก retry ที่ดูปกติอาจก่อให้เกิด Thundering Herd กับบริการ downstream ได้
- แคชที่ไม่มี TTL อาจค่อย ๆ ทำให้ Redis ล่มโดยไม่มีใครสังเกต
- เอเจนต์ไม่รู้สถานะความจุของอินสแตนซ์ Redis, การที่ฐานข้อมูลมีการ hardcode รีเจียนบางจุดไว้ หรือข้อเท็จจริงที่ว่าการ rollout feature flag สามารถเปลี่ยนโปรไฟล์โหลดของระบบ downstream ได้
- ช่องว่างระหว่าง "PR นี้ดูถูกต้อง" กับ "PR นี้ดีพลอยได้อย่างปลอดภัย" มีอยู่เสมอ และเอเจนต์ทำให้ช่องว่างนี้ยิ่งกว้างขึ้น
การแยกแยะสำคัญ: ใช้ประโยชน์ vs. พึ่งพา
- พึ่งพา (Relying): วิธีคิดที่ถือว่าเมื่อเอเจนต์เขียนเสร็จและการทดสอบผ่านแล้ว ก็พร้อมดีพลอย
- ผู้เขียนไม่ได้สร้าง mental model ของการเปลี่ยนแปลงนั้น
- เกิด PR ขนาดใหญ่ที่เต็มไปด้วยสมมติฐานแอบแฝง โดยทั้งผู้เขียนและผู้รีวิวไม่เข้าใจจริง ๆ ว่าโค้ดทำอะไร
- ใช้ประโยชน์ (Leveraging): ใช้เอเจนต์เพื่อเร่งการวนซ้ำอย่างรวดเร็ว แต่ยังคงความเป็นเจ้าของผลลัพธ์อย่างสมบูรณ์
- เข้าใจอย่างแม่นยำว่าโค้ดจะทำงานอย่างไรภายใต้โหลด
- เข้าใจความเสี่ยงที่เกี่ยวข้องและเต็มใจรับผิดชอบมัน
- การมีชื่ออยู่บน PR หมายถึง "ฉันได้อ่านแล้วและเข้าใจว่ามันทำอะไร" และนี่คือจุดอ้างอิงของกระบวนการวิศวกรรม
เกณฑ์ตัดสิน: แบบทดสอบลิตมัส
- แบบทดสอบง่าย ๆ: "คุณสบายใจหรือไม่ที่จะเป็นเจ้าของโปรดักชันอินซิเดนต์ที่เชื่อมโยงกับ PR นี้?"
- ก่อนส่ง PR ให้ถามตัวเอง 3 ข้อ
- โค้ดนี้ทำอะไร? หลัง rollout แล้วมันจะทำงานอย่างไร?
- มันอาจส่งผลเสียอะไรต่อโปรดักชันหรือลูกค้าได้บ้าง?
- คุณสบายใจหรือไม่ที่จะเป็นเจ้าของอินซิเดนต์ที่เชื่อมโยงกับโค้ดนี้?
- ถ้าคำตอบคือ "ใช่" แสดงว่าคุณกำลังใช้ AI อย่างมีประโยชน์และสามารถดีพลอยได้ ถ้า "ไม่" แปลว่ายังมีงานที่ต้องทำอีก
ทางแก้: สามหลักการเพื่อป้องกันโปรดักชัน
- การดีพลอยแบบขับเคลื่อนตัวเอง (Self-driving deployments): ทุกการเปลี่ยนแปลงจะ rollout แบบค่อยเป็นค่อยไปผ่าน gated pipeline และ canary deployment จะ rollback อัตโนมัติเมื่อประสิทธิภาพลดลง
- ไม่พึ่งวิธีที่ให้วิศวกรคอยเฝ้าดูแดชบอร์ด
- เมื่อมีปัญหา จะถูกจำกัดอยู่เพียงบางส่วนของทราฟฟิกแทนที่จะกระทบทั้งหมด
- การตรวจสอบอย่างต่อเนื่อง (Continuous validation): ไม่ใช่แค่ตอนดีพลอย แต่ทดสอบโครงสร้างพื้นฐานอย่างสม่ำเสมอตลอดเวลา
- มีการรัน load test, การทดลอง chaos และการซ้อม disaster recovery อย่างต่อเนื่อง
- เหตุผลที่ database failover ซึ่ง Vercel ซ้อมไว้ในโปรดักชันเมื่อฤดูร้อนที่ผ่านมา ไม่ส่งผลกระทบต่อลูกค้าเลยเมื่อเกิดเหตุขัดข้องของ Azure จริง
- ราวป้องกันที่บังคับใช้ได้จริง (Executable guardrails): เข้ารหัสความรู้ด้านปฏิบัติการให้อยู่ในเครื่องมือที่รันได้จริง ไม่ใช่ในเอกสาร
- สกิล
safe-rolloutไม่ใช่หน้า Notion ที่อธิบายวิธีทำงานของ feature flag แต่เป็นเครื่องมือที่เชื่อมต่อแฟลก สร้างแผน rollout ที่มีเงื่อนไข rollback และระบุวิธียืนยันพฤติกรรมที่คาดหวัง - เมื่อ guardrail บังคับใช้ได้จริง เอเจนต์ก็สามารถปฏิบัติตามได้อย่างอัตโนมัติ และมนุษย์ไม่จำเป็นต้องท่องจำมัน
- สกิล
สิ่งที่ Vercel ลงทุนจริง
- เสริมความแข็งแรงให้ guardrail ของโครงสร้างพื้นฐานที่ใช้ร่วมกัน ด้วยการใช้ runtime validation ในทุกขั้นของ deployment pipeline
- เสริมการตรวจสอบแบบสถิตในขั้น PR โดยเฉพาะที่เกี่ยวข้องกับ feature flag
- นำการทดสอบ end-to-end แบบ production mirroring มาใช้ในสภาพแวดล้อม staging
- ใช้งาน เอเจนต์แบบอ่านอย่างเดียว ที่คอยตรวจสอบ invariant ของระบบในโปรดักชันอย่างต่อเนื่อง และใช้เอเจนต์เฉพาะทางเพื่อตรวจสอบสมมติฐานของเอเจนต์ที่สร้างโค้ด
- นำเมตริกอย่าง อัตราส่วน defect escape ต่อ defect commit มาใช้ เพื่อตรวจจับว่าความเสี่ยงของแพลตฟอร์มโดยรวมเพิ่มขึ้นหรือไม่
บทสรุป: วิศวกรที่มีวิจารณญาณคือความได้เปรียบในการแข่งขัน
- การลงมือทำ implementation กลายเป็นสิ่งที่มีอยู่มากมาย และตอนนี้ทรัพยากรที่หายากคือ วิจารณญาณต่อสิ่งที่สามารถดีพลอยได้อย่างปลอดภัย
- ยุคที่โค้ดคุณภาพต่ำดูออกว่าเป็นโค้ดคุณภาพต่ำได้จบลงแล้ว เครื่องมือ AI จะยิ่งทรงพลังขึ้น diff จะยิ่งใหญ่ขึ้น และแรงยั่วยวนให้เชื่อผลลัพธ์อย่างไม่ตั้งคำถามก็จะมากขึ้น
- เป้าหมายไม่ใช่โลกที่ทุกการเปลี่ยนแปลงต้องใช้ความเข้มงวดระดับพิเศษจากมนุษย์ แต่เป็นโลกที่ ตัวโครงสร้างพื้นฐานเองมีความเข้มงวด — สภาพแวดล้อมที่การดีพลอยอย่างรวดเร็วปลอดภัยโดยพื้นฐาน
ยังไม่มีความคิดเห็น