AI code reliability: เมื่อความเร็วแซงความเข้าใจระบบ
AI code reliability คือความสามารถของโค้ดที่สร้างโดยเครื่องมือ AI ในการทำงานได้ตรงตามที่ออกแบบอย่างสม่ำเสมอและปลอดภัยในสภาพแวดล้อมโปรดักชันที่ซับซ้อน มีการเรียก API จำนวนมาก การรองรับผู้ใช้พร้อมกันระดับพัน และการเก็บรักษาคอนเท็กซ์ยาวนานหลายสัปดาห์ โดยไม่หลุดข้อกำหนดทางธุรกิจหรือความปลอดภัยใดๆ. ปัญหาของยุคนี้ไม่ใช่แค่ AI เขียนโค้ดผิด แต่คือโค้ดถูกตามสเปกระยะสั้นแต่ไม่ผ่านด่านความน่าเชื่อถือระยะยาว รายงานหนึ่งพบว่าโค้ด Java ที่สร้างโดย GenAI กว่า 70% ไม่ผ่านการตรวจสอบด้านความปลอดภัย ขณะที่ C#, JavaScript และ Python อยู่ที่ 45%, 43% และ 38% ตามลำดับ. เมื่อรวมกับการสำรวจที่ระบุว่า 61% ของวิศวกรซอฟต์แวร์เชื่อว่าโค้ดจาก AI "อาจถูกต้อง แต่ไม่จำเป็นต้องน่าเชื่อถือเสมอไป" ภาพจึงชัดว่าความเร็วกำลังทิ้งความเข้าใจและสถาปัตยกรรมไว้ข้างหลัง. ที่น่ากังวลคือการยอมรับโค้ดที่เครื่องมือส่งมาโดยไม่อ่านละเอียด การตรวจทีละ 30 บรรทัดใช้เวลาราว 20 นาที แต่ถ้ารับแบบไม่อ่านใช้เวลาเพียงประมาณ 3 นาที และเมื่อทำแบบนี้ 40 ครั้งในบ่ายเดียว ความต่างเวลาบานไปเกิน 13 ชั่วโมง ขณะที่เราได้ระบบที่ทำงาน 40 ฟีเจอร์แต่โมเดลในหัวกลับตามไม่ทัน. นี่คือหนี้ความรู้ที่สะสมเงียบๆ ทุกครั้งที่เรากด “ยอมรับ” โดยไม่ทำความเข้าใจ.
สถาปัตยกรรมโปรดักชัน: ปัญหาไม่ได้อยู่ที่โมเดล แต่อยู่ที่โครงสร้าง
คำหลอกลวงใหญ่ของการเดโมเอเยนต์ AI คือความรู้สึกว่า "ทำได้ซ้ำ" เท่ากับ "พร้อมโปรดักชัน" ทั้งที่สภาพแวดล้อมเดโมควบคุมได้หมด API ตอบตรงตามสัญญา คอนเท็กซ์เล็ก เครื่องมือพร้อมใช้ตลอด และเซสชันสั้น แต่อย่างที่หลายทีมพบเมื่อขึ้นโปรดักชันจริง ระบบเริ่มตัดสินใจไม่สอดคล้อง การเรียกเครื่องมือหมดเวลา Retrieval เสื่อมคุณภาพ คอนเท็กซ์ปนเปื้อนข้อมูลเก่า และเวิร์กโฟลว์หลายเอเยนต์ถึงขั้นเดดล็อกเมื่อรับโหลดสูง. สิ่งที่ดูเหมือน "โมเดลไม่เก่ง" แท้จริงคือปัญหาอินฟราสตรักเจอร์และสถาปัตยกรรมที่ออกแบบมาเพื่อเดโม ไม่ใช่เพื่อความน่าเชื่อถือในโลกจริง. ผู้ใช้ปลายทางสัมผัสผลกระทบชัดเจนเมื่อแชตบอตซัพพอร์ตต้องรับลูกค้าพันคนพร้อมกัน หรือเอเยนต์วิจัยต้องยิง API เป็นสิบครั้งในเวิร์กโฟลว์เดียว ระบบที่เคยรันได้สวยในห้องทดลองเริ่มช้าและผิดเพี้ยนต่อหน้าองค์กร. ทางออกคือเริ่มออกแบบ production safeguards ตั้งแต่วันแรก ไม่ใช่เติมทีหลังด้วยการรีไตรหรือแดชบอร์ดมอนิเตอร์ สถาปัตยกรรมควรแยกชัดเจนระหว่างการวางแผน การลงมือ และการประเมินผล เพื่อให้ปรับแต่งและดีบักได้เมื่อขยายขนาด. การเลือกว่าจะใช้เวิร์กโฟลว์แบบมี state หรือไร้ state ให้เหมาะกับงาน ก็ช่วยให้ตัดสินใจแบบ reversible decision ปรับเปลี่ยนได้โดยไม่ต้องรื้อระบบใหญ่หรือทิ้งความรู้เดิม.
หนี้ความรู้และ technical debt: โค้ดเดินหน้าเร็วกว่าความเข้าใจทีม
หนี้ความรู้เกิดขึ้นทุกครั้งที่ทีมรับโค้ดจาก AI โดยไม่ได้ทำความเข้าใจตั้งใจว่า "ระบบนี้ตั้งใจจะทำอะไร" ผลคือพฤติกรรมระบบใหญ่กว่าภาพในหัว และช่องว่างระหว่างสองอย่างนี้ขยายทุกครั้งที่เราตอบตกลง. เมื่อถึงวันที่ต้องแก้บั๊ก เราไม่อาจรู้ได้อีกต่อไปว่าเรากำลังแก้หรือกำลังฝังปัญหาให้ลึกลง นั่นคือใบแจ้งหนี้ที่ส่งมาช้าแต่แน่นอน. ด้าน technical debt การจัดระเบียบโค้ดให้เรียบง่ายและรวมฟังก์ชันใกล้เคียงให้เหลือหนึ่งเดียวคือสิ่งที่ทำให้ระบบยังเล็กพอจะถือภาพรวมในหัวได้. ในทางตรงกันข้าม การก็อปปี้โค้ดแบบรวดเร็วตรงไปตรงมา คือการสร้างแนวคิดเดียวกันไว้สี่ที่ในโค้ด แล้ววันที่ต้องเปลี่ยน เราต้องไปหาทั้งสี่ โดยไม่รู้ด้วยซ้ำว่ามีสี่เพราะเราไม่เคยอ่านมัน. การใช้ AI refactor ก็มีด้านมืด เอเยนต์พร้อมจะคืนโค้ดใหม่ที่ดูสะอาดสั้นและตั้งชื่อดี แต่แอบตัดฟีเจอร์ที่ "ดูเกะกะ" โดยไม่เข้าใจว่าเป็นส่วนรับโหลดหรือป้องกันการฉ้อโกง. ผู้เขียนบางรายจึงรักษา preservation anchors รายการสิ่งที่ห้ามเปลี่ยน พร้อมคำว่า "เพราะอะไร" และดันลงไปถึงชั้น constraint ในฐานข้อมูล เพื่อให้แม้แต่เอเยนต์ที่ตั้งใจดีแต่เข้าใจไม่ครบก็ไม่สามารถ "พัฒนา" จนทำลายฟีเจอร์สำคัญได้.
code governance และ AI code review: ประตูที่มนุษย์ต้องเป็นเจ้าของ
เมื่อ AI เขียนโค้ดได้เป็นร้อยบรรทัดในคำสั่งเดียว หลายทีมเริ่มหวังว่า automation และ AI code review จะเป็นด่านสุดท้ายแทนมนุษย์ แต่ประตูนี้ยังต้องการเจ้าของที่มีชื่อจริงและความรับผิดชอบต่อผลิตภัณฑ์ โดยเฉพาะในระบบที่มีข้อกำกับด้านกฎระเบียบ. งานวิจัยหนึ่งพบว่าโปรแกรม 1,689 ชุดที่สร้างโดย Copilot มีช่องโหว่ถึง 40% และทุก PR เหล่านั้นเกือบแน่นอนว่ามีชื่อมนุษย์กดอนุมัติอยู่เบื้องหลัง. เครื่องมือรีวิวอัตโนมัติทำงานดีในการจับ pattern ช่องโหว่และบั๊กซ้ำๆ ในปริมาณสูง ซึ่งมักดีกว่ามนุษย์ที่อ่าน PR ที่สี่ของบ่ายวันเดียว. แต่ปัญหาเริ่มขึ้นเมื่อเราเข้าใจผิดว่าความเร็วนี้แทนที่การพิจารณาเชิงบริบทว่าฟีเจอร์นั้นเกี่ยวข้องกับความเสี่ยงอะไร การอนุมัติโค้ดเกิน 400 บรรทัดในครั้งเดียวถูกพบว่าทำให้การจับ defect ด้อยลงอย่างชัดเจน ในขณะที่คำสั่งจาก AI เดียวกันอาจส่งโค้ด 600 บรรทัดขึ้นไปให้เราอ่านแบบเพียง "ดูว่าผ่านเทสต์ไหม" แล้วกด merge. เพื่อให้ code governance มีความหมาย ทีมควรจำกัดขนาดโค้ดต่อรีวิวให้อยู่ในช่วงที่มนุษย์ถือภาพรวมได้ใกล้กับเพดาน 400 บรรทัด มากกว่าปล่อยให้ diff ปลายสปรินต์พุ่งไป 900 บรรทัด. และต้องยอมรับว่าการตัดสินใจว่าช่องโหว่ไหนควรถูก escalated ในบริบทข้อบังคับเฉพาะไม่ใช่งานของ AI เพราะมันไม่ถือบริบทครบถ้วนและไม่ควรถือด้วยซ้ำ. Regulated code จึงต้องมีเจ้าของมนุษย์ที่ชัดเจน ไม่ใช่คณะกรรมการหมุนเวียนที่กด approve แบบกลุ่ม.
agentic QA, production safeguards และการจัดการหนี้ระยะยาว
ฝั่งคุณภาพซอฟต์แวร์ เราเห็นภาพคล้ายกันกับการเขียนโค้ด: agentic QA tools อย่าง Claude Code และ Playwright ทำให้การสร้างเทสต์ฟังก์ชันรวดเร็วขึ้นอย่างมาก โดยเฉพาะทีมที่เดิมไม่มีออโตเมชันเลยหรือทีมที่เคยลงทุนแพลตฟอร์ม QE ระดับองค์กรอยู่แล้ว. แต่การมีเทสต์เพิ่มไม่เท่ากับมี testing strategy ที่ดี ผู้ให้บริการรายหนึ่งชี้ว่า AI tools เร่งการสร้างเทสต์ได้ถึงห้าเท่าในเวลาเท่าเดิม หมายความว่าเราเพิ่มพื้นที่ที่ต้องบำรุงรักษาเชิงอัตโนมัติโดยไม่มีใครถือหนี้นี้อย่างชัดเจน. ตัวอย่างชัดคือ Playwright healer agent ที่รันชุดเทสต์ ซ่อมเทสต์ที่ล้มเอง และติดธงเทสต์ที่เห็นว่าเสียจริง มันทำงานได้ดี และนั่นคือปัญหา เพราะการซ่อมลงโค้ดทันทีโดยไม่มีรอยเชื่อมกับ requirement ต้นทาง ทำให้เราไม่รู้ว่าเจตนาการป้องกันฟีเจอร์เดิมถูกเก็บรักษาไว้หรือไม่. คุณภาพระดับองค์กรต้องการ governance, traceability, test data และ coverage ข้ามเทคโนโลยีที่เอเยนต์ทั่วไปไม่ให้ได้. บนสถาปัตยกรรมโปรดักชัน การออกแบบ production safeguards ที่ดีควรยอมรับว่าความล้มเหลวเป็นสภาวะปกติ ระบบ distributed ML ที่ใช้เฟรมเวิร์กอย่าง ZeRO หรือ FSDP ทำงานได้ดีเพราะสมมติว่าความล้มเหลวจะเกิดขึ้น และจึง checkpoint state อย่างสม่ำเสมอ การกู้คืนจึงเป็นส่วนหนึ่งของสถาปัตยกรรม ไม่ใช่ภาคเสริมทีหลัง. ฝั่งคุณภาพก็เช่นกัน แพลตฟอร์มอย่าง AI Workspace ถูกสร้างมาเป็น control plane สำหรับทีม QE เพื่อซ้อนชั้น agentic governance ทับสิ่งที่ Playwright และ Claude สร้างขึ้น และจัด orchestrate คุณภาพตลอด SDLC. นี่คือการใช้ fitness functions และนโยบายกำกับเพื่อให้ระบบวิวัฒน์ได้โดยไม่ต้องรื้อใหม่ทั้งก้อนหรือสูญเสียความรู้เชิงสถาบันทุกครั้งที่มีการ refactor.
