คุณไม่ได้ข้ามการตัดสินใจ คุณตัดสินใจไปแล้ว โดยไม่ได้มอง

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

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

Productize อ่านเรื่อง vibe coding กับ agentic coding เป็นคำถามเรื่องความเป็นเจ้าของ ไม่ใช่คำถามเรื่องฝีมือ ชิ้นนี้คือตอนที่ 2 ของการอ่านแผนที่ทักษะ AI engineering ของ Andrew Ng ตอนที่ 1 ของซีรีส์ครอบแผนที่ทักษะทั้งใบไว้พร้อมกับทักษะฝั่ง AI ส่วนใบนี้ครอบครึ่งซอฟต์แวร์ ที่เป็นบ้านของการตัดสินใจแบบเงียบ

ช่วงที่ 1ประโยคเดียวที่แบกทั้งบทความ

บทความของ Andrew Ng ว่าด้วยพื้นฐานซอฟต์แวร์เปิดเรื่องด้วยคำถามข้อเดียว แล้วตอบมันด้วยประโยคเดียว ประโยคนั้นทำงาน 2 อย่างพร้อมกัน แต่คนอ่านส่วนใหญ่จับได้แค่อย่างแรก

Even when you use a coding agent to write all your code, understanding software fundamentals is important for steering your agent to make the tradeoffs you want
or to even know what tradeoffs exist to be made.

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

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

Andrew Ng เรียกกลไกนี้ตรงๆ นักพัฒนาที่ vibe code ได้แอปที่ใช้งานได้จริงและเรียบง่าย พ่วง tradeoff ที่แย่ติดมาด้วย เพราะ "the developer didn't know such tradeoffs even existed and therefore did not steer the agent to make the right decisions for their application context" เขาให้คำศัพท์ไว้ครั้งเดียวแล้วไม่ย้อนกลับมาพูดซ้ำอีกเลย คือ "latency, availability, consistency, reliability, maintainability, simplicity, and/or cost" 7 คำนี้คือสิ่งที่ทุกการตัดสินใจในช่วงถัดๆ ไปต้องเอามาชั่งกันเอง

ก่อนเดินต่อ ควรกางแผนที่ให้เห็นทั้งใบ บทความของ Ng ซอยพื้นฐานซอฟต์แวร์ออกเป็น 5 เสา เรียงตามที่เขาเขียนไว้ คือ สร้างแอปแบบ full-stack · จัดการข้อมูล · ออกแบบสถาปัตยกรรมระบบ · ทำระบบให้ปลอดภัยและเชื่อถือได้ · และ ขยายและดูแลตอนใช้งานจริง ช่วงที่เหลือของบทความนี้เดินตามลำดับนั้น ช่วงที่ 2 ยืนอยู่ที่เสาแรก ช่วงที่ 3 อยู่ที่เสาที่ 2 ซึ่งเป็นเสาที่เราจะอยู่นานที่สุด ส่วนช่วงที่ 4 เก็บ 3 เสาท้ายไว้ด้วยกัน เพราะล้มด้วยกลไกเดียวกันทั้งหมด กิ่งอีกข้างของแผนที่ใบเดียวกัน คือ 6 ข้อย่อยของการสร้างและส่งแอป AI ขึ้นใช้งาน อยู่ในช่วงที่ 4 ของตอนที่ 1

ช่วงที่ 2agentic coding เปิดทางให้เรา หรือลากเราเข้าไปยืนตรงนั้น

เสาที่ 1 · สร้างแอปแบบ full-stack

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

ต้นฉบับของ Ng เขียนไว้ตรงๆ ว่า "Agentic coding enables many developers who previously played more specialized roles (like front-end developer or mobile developer) to play a broader, full-stack role." อ่านในฐานะคำบรรยายความสามารถแล้ว ประโยคนี้จริงและน่ายินดี

ส่วนที่เหลือ Ng ไม่พูด เราพูดเอง คำว่า enable บอกเป็นนัยว่าเราเลือกปฏิเสธได้ แต่ปฏิเสธไม่ได้จริง การตัดสินใจเรื่อง cache invalidation กับการวาง state ตกมาอยู่ใน repository ของเราเสมอไม่ว่าจะรู้ตัวหรือไม่ เพราะ agent ต้องเขียนอะไรสักอย่างออกมาให้ได้ และไม่มีทางหยุดถามก่อน ไม่มีทางเลือกไหนที่ใช้ coding agent แล้วปฏิเสธการตัดสินใจนั้นได้ มีแต่ทางเลือกว่าจะตัดสินใจแบบมองเห็น หรือตัดสินใจแบบไม่มอง คำแนะนำเลยเปลี่ยนไป ไม่ใช่ ตอนนี้ขยายบทบาทได้แล้ว แต่คือ บทบาทขยายไปตั้งแต่ต้นแล้ว คำถามเดียวที่เหลือคือกำลังมองอยู่หรือเปล่า

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

ภาพจริงเป็นแบบนี้ เราขอ dashboard ที่โหลดเร็วขึ้น agent เพิ่ม cache อายุ 5 นาทีไว้หน้า summary query แล้วเก็บไว้ใน memory ของแอปเอง บนแล็ปท็อปมันทำงานถูกต้อง เพราะมีแอปสำเนาเดียว ผู้ใช้คนเดียว แต่ใน production มีสำเนา 4 ชุดอยู่หลัง load balancer ซึ่งเป็นตัวกระจาย request ไปยังสำเนาที่รันอยู่ ผู้ใช้แก้ไขข้อมูล คำสั่งเขียนตกไปที่สำเนาที่สอง request ถัดไปวิ่งกลับไปที่สำเนาแรกซึ่งยังไม่เห็นการแก้ไขนั้น ผู้ใช้เลยแก้ซ้ำอีกรอบ ตอนนี้มีข้อมูล 2 ชุดแล้ว และไม่มี error โผล่มาเลยสักตัว

ส่วนที่แย่กว่านั้นคือความรุนแรงแปรผันตามจำนวนสำเนาที่รันอยู่ พอขยายระบบเมื่อไหร่ก็ยิ่งแย่ลงทันที พาทุกคนไปสงสัยการขยายระบบแทนที่จะสงสัย cache ตั้งแต่แรก คำแนะนำที่ป้องกันเรื่องนี้ได้ไม่ใช่ ระวังเรื่อง cache ให้ดี แต่คือระบุให้ชัดว่า write ตัวไหนที่ต้อง invalidate cache นี้ ใส่เข้าไปใน change เดียวกัน แล้วห้ามเก็บ shared state ไว้ใน memory ของโปรเซสเดียวเด็ดขาด

ช่วงที่ 3ทำไมข้อมูลถึงเป็นเสาต้นเดียวที่พังแบบเงียบ

เสาที่ 2 · จัดการข้อมูล

เพราะมันทรุดโดยไม่มีเสียงออกมาเลย ทุกส่วนอื่นของ stack สุดท้ายจะโผล่อะไรดังๆ ออกมาเสมอ ไม่ว่าจะ timeout หน้า error หรือบิลค่าใช้จ่าย แต่ data architecture ที่ขาดอะไรไปสักอย่างกลับให้คำตอบที่มั่นใจและฟังดูสมเหตุสมผล แล้วไม่มีอะไรในระบบดูต่างจากตอนที่มันทำงานถูก

Andrew Ng เขียนถึงข้อมูลไม่เหมือนเสาอื่น เขาบอกเองว่ามันควรได้รับความสนใจเป็นพิเศษ เพราะเป็น "a foundation that software is built on top of, that is relatively hard to change (even if agents help with migrations)" แล้วตามด้วยข้ออ้างเดียวของทั้งบทความที่พูดถึงยุค AI โดยตรงว่า "Your AI systems will get their own input context from your data source, so if data architecture is chosen poorly, the AI doesn't know what it doesn't know."

นี่คือการตัดสินใจชุดเดียวกับที่ตอนที่ 1 เรียกว่าการป้อนข้อมูลให้โมเดล มองจากอีกด้าน ด้านนั้นถามว่าจะเก็บข้อมูลเป็นดัชนีเวกเตอร์ (ค้นด้วยความใกล้เคียงของความหมาย) กราฟความรู้ (เก็บว่าอะไรเกี่ยวกับอะไร) หรือชั้นความหมายที่วางทับตารางเดิม (ตัวแปลให้ query ใช้คำอย่างลูกค้าหรือยอดขาย แทนชื่อตารางดิบ) ส่วนด้านนี้ถามว่าถ้าเลือกผิดไปแล้ว จะรู้ตัวได้ยังไง กลไกตรงนี้หนักกว่าข้อโต้แย้งทั่วไปที่ว่าข้อมูลแย่ให้คำตอบแย่ ผลลัพธ์ของโมเดลเป็นฟังก์ชันของ context และ context ก็ถูกประกอบขึ้นจากโค้ดที่วิ่งเข้าไปหา data layer ของเรา ขอบนอกสุดที่ระบบรู้ได้จึงเท่ากับขอบของสิ่งที่ data layer นั้นคืนกลับมาได้ ไม่มีอะไรข้างในโมเดลมองเห็นขอบนั้นจากด้านในได้เลย คนที่ไม่รู้อะไรสักอย่างยังสังเกตช่องว่างนั้นได้ แต่โมเดลที่ได้รับ context ที่ถูกตัดทอนมาไม่รู้สึกว่าถูกตัดทอน กลับรู้สึกว่า context ที่ได้มานั้นครบแล้ว

ผลลัพธ์ว่างเปล่าคืนไบต์ชุดเดียวกัน ไม่ว่าคำตอบนั้นจะไม่มีอยู่เลย หรือคำถามนั้นตอบจาก schema นี้ไม่ได้มาตั้งแต่ต้น ไม่มีภาษา query ตัวไหนแยก 2 กรณีนี้ออกจากกันได้ เพราะความต่างอยู่ที่ประวัติการเก็บข้อมูล ซึ่งไม่ได้ถูกเก็บไว้ในฐานข้อมูลด้วยตัวมันเอง

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

ข้อเท็จจริงหายไปแบบมองไม่เห็นได้ 4 ทาง ควรจำไว้ให้ขึ้นใจตั้งแต่แรกเห็น

• ไม่เคยถูกโมเดลไว้ ข้อเท็จจริงนั้นไม่เคยเป็น field มาก่อน มี amount แต่ไม่มี reason ระบบตอบได้แค่ว่าเท่าไหร่ ไม่เคยตอบว่าทำไม แล้วไม่มีผลลัพธ์ไหนใบ้เลยว่าคำถามว่าทำไมนั้นเคยตอบได้
• ถูกลบทิ้งเพราะ retention หน้าต่าง 90 วันของประวัติการโต้ตอบ แปลว่าถ้าเรื่องนั้นเกิดขึ้นเกิน 90 วันที่ผ่านมา agent ที่ถูกถามว่าลูกค้ารายนี้เคยยกเรื่องนี้ขึ้นมาไหม ก็ตอบว่าใช่ไม่ได้เลย จะไม่บอกว่าเห็นได้แค่ 90 วัน จะบอกว่าไม่เคยเลยต่างหาก คนที่เลือกหน้าต่าง 90 วันนั้นกำลังชั่งน้ำหนักระหว่างต้นทุน storage กับกฎ compliance อยู่ ไม่มีใครในห้องนั้นกำลังตัดสินใจเรื่อง memory horizon ของระบบที่ตอนนั้นยังไม่มีอยู่เลย
• เข้าไม่ถึง แถวข้อมูลนั้นมีอยู่จริง แต่เส้นทางดึงข้อมูลไปถึงไม่ได้ อาจเพราะ filter กันไว้ permission scope (ขอบเขตสิทธิ์เข้าถึงข้อมูล) บังไว้ field ไม่ถูกทำดัชนีไว้ให้ค้นเจอ หรือรอยตัดท่อนข้อความ (chunk boundary) ตัดประโยคที่สำคัญขาดกลาง ระบบเลยทำตัวเหมือนไม่มีข้อมูลนั้นอยู่เลยในทุกมุมที่สังเกตได้
• ยังไม่ถูก resolve 2 ระเบียนพูดถึงลูกค้าคนเดียวกันโดยไม่มีอะไรโยงเข้าด้วยกัน คำตอบที่ได้จึงเป็นแค่ครึ่งเดียวของคนคนนั้น และครึ่งหนึ่งไม่ใช่รูปทรงที่จะโผล่มาในคำตอบได้ นี่คืออันตรายที่สุดใน 4 แบบ เพราะผลลัพธ์ไม่ได้ว่างเปล่า ดูสมเหตุสมผลและครบไปครึ่งหนึ่ง

เวอร์ชันที่พบได้ทุกวันของทั้ง 4 แบบนี้คือ NULL ใน schema จริง แทนความหมายได้อย่างน้อย 5 อย่าง คือไม่เกี่ยวข้อง ไม่ทราบ ยังไม่ถูกเก็บ เก็บแล้วแต่ค่าว่างจริง และหายไปตอน migration โมเดลที่อ่านเจอ NULL แยกความหมายพวกนี้ออกจากกันไม่ได้ ส่วนใหญ่แล้วเราเองก็แยกไม่ออกเหมือนกัน คำถามตรวจสอบข้อเดียวที่ได้ผลมากเป็นพิเศษกับ schema ที่ agent สร้างขึ้นมาก็คือ NULL ในคอลัมน์นี้แปลว่าอะไร แล้วเป็นมากกว่าหนึ่งความหมายหรือเปล่า

Ng บอกปัญหาไว้แล้วไม่ได้เสนอทางแก้ไว้เลย ทิ้งคำเตือนเรื่องความรวนที่มองไม่เห็นไว้โดยไม่มีเครื่องมือติดไปด้วย เครื่องมือที่ดีที่สุดที่เรารู้จักอยู่ตรงจุดที่ agent อ่านข้อมูลเข้าไป คือตัวดึงข้อมูล (retrieval tool) ที่ถูกสั่งให้ filter ตามมิติที่ต้นทางไม่มี ควรตอบกลับมาตรงๆ ว่า field นี้ไม่มีอยู่ตรงนี้ ไม่ใช่ส่ง list ว่างเปล่ากลับมาเฉยๆ วิธีนี้เปลี่ยนความว่างเปล่าแบบเงียบให้กลายเป็น token หนึ่งใน context ที่โมเดลอ่านได้ รายงานได้ และวางแผนหลบได้

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

ช่วงที่ 43 เสาท้ายของแผนที่ พังด้วยกลไกเดียวกัน

เสาที่ 3-5 · สถาปัตยกรรมระบบ · ความปลอดภัยและความน่าเชื่อถือ · ขยายและดูแลตอนใช้งานจริง

เสาที่ 3 ออกแบบสถาปัตยกรรมระบบ คือจุดที่บทความนี้แม่นที่สุดแบบเงียบๆ Ng บอกไว้ว่า "the right architecture is a moving target, depending on the phase of the project" รูปทรงตอน prototype ไม่ใช่รูปทรงเดียวกับตอนขึ้น production จริง แล้ว "that too may change as the application scales" ด้วย generation ที่ถูกลงจึงไม่ใช่ข้ออ้างให้สร้างใหญ่ขึ้นตั้งแต่แรก แต่เป็นข้ออ้างให้ผูกมัด (commit) ช้าลง

Ng พูดถึงแค่นี้แล้วหยุด ส่วนที่เราอยากเติมคือ one-way door ไปกองอยู่ตรงไหนของระบบ ประตูทางเดียวไม่ได้กระจายเท่ากันทั่วทั้งระบบ มันไปกองอยู่ที่ขอบ ขอบพวกนี้คือ URL ที่เผยแพร่ไปแล้ว รูปทรง API ที่ client รายที่สองรับไปใช้แล้ว ID ที่ user เห็นอยู่ตรงหน้า tenant key ตัวแรกที่ migration แตะไปแล้ว ซึ่งก็คือฟิลด์ที่แยกข้อมูลของลูกค้าแต่ละรายออกจากกัน ตำแหน่งจริงที่ byte นอนอยู่ และสิ่งที่เคยสัญญาไว้ว่าจะลบทิ้ง โครงสร้างภายในของระบบยังกลับตัวได้นานกว่าที่คนส่วนใหญ่คิดไว้ ส่วน interface กลับย้อนกลับไม่ได้เร็วกว่าที่คิดไว้เหมือนกัน กฎที่ได้จากตรงนี้คือ ใช้ความคิดให้มากตรงขอบ แล้วเร่งความเร็วตรงกลาง

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

ใต้เรื่องนี้มีความไม่สมดุลที่ agentic coding สร้างขึ้นโดยไม่บอกใคร การสร้างโค้ดถูกลงแบบก้าวกระโดด การ migration ถูกลงนิดหน่อย เพราะ agent เขียนจุดที่เรียกใช้ของเดิม (call site) ใหม่ให้ได้ แต่เจรจาเปลี่ยนสัญญากับผู้ใช้บริการที่เราคุมไม่ได้แทนเราไม่ได้ ส่วนต้นทุนตอนใช้งานจริงไม่ขยับลงเลย เพราะมันเป็นฟังก์ชันของพื้นที่ผิวของระบบ คือจำนวนจุดเชื่อมต่อ บริการ และเส้นทางข้อมูลทั้งหมดที่มีอยู่จริง ไม่สนว่าโค้ดถูกเขียนขึ้นมาด้วยวิธีไหน generation ที่ถูกลงจึงไม่ได้ทำให้สถาปัตยกรรมที่ดีถูกลงตามไปด้วย มันทำให้สถาปัตยกรรมที่ผิดหาซื้อได้ถูกลง ส่วนต้นทุนการถือครองยังแพงเท่าเดิม ไม่มีใครลงมือสร้าง 7 service ด้วยมือให้ prototype เพราะไม่มีใครมีเวลาสักสุดสัปดาห์ ความฝืดจากการพิมพ์เคยทำหน้าที่คุมความทะเยอทะยานไว้ พอความฝืดหายไป ตัวคุมก็หายไปด้วย แต่ต้นทุนไม่ได้หายตามไปด้วยเลย

เสาที่ 4 ทำระบบให้ปลอดภัยและเชื่อถือได้ Ng ขอ 2 อย่างจากเสานี้ อย่างแรกคือกลยุทธ์การทดสอบ ว่าจะผสม unit test กับ integration test ยังไง และเอาความครอบคลุมแค่ไหน อย่างที่ 2 คือการออกแบบเผื่อความล้มเหลวไว้ตั้งแต่ต้น ทั้งการรับมือตอน API ชน rate limit การถอยลงอย่างนุ่มนวล และการจำกัดวงความเสียหายให้แคบที่สุด ที่ Ng เรียกว่า "minimize the blast radius of failures" เขายังชี้ว่างานความปลอดภัยกำลังขยับมาต้นทาง ตามแนวคิด shift left ที่ย้ายงานความปลอดภัยมาไว้ตั้งแต่ตอนออกแบบ แทนที่จะไปทำหลังเขียนเสร็จ จนถึงจุดที่ "many developers are now also partly security engineers" ส่วนความรวนที่เราเจอซ้ำในเสานี้ไม่ใช่มีเทสต์น้อยเกินไป แต่เป็นเทสต์ที่แดงไม่เป็นเลยสักครั้ง กับ check ที่ขึ้นเขียวเพราะเหตุผลผิด ในหน้างานจริง alert ที่ไม่เคยดังกับ alert ที่พังไปแล้ว มองจากข้างนอกแยกไม่ออก เพราะทั้งคู่ให้ความเงียบเหมือนกัน

เสาที่ 5 ขยายและดูแลตอนใช้งานจริง รายการของ Ng ตรงนี้ยาวและเป็นงานช่าง ตั้งแต่การตั้งค่าสภาพแวดล้อมที่จะ deploy การเลือกจังหวะปล่อยของ การวาง CI/CD ไปจนถึง observability (การรู้ว่าระบบกำลังทำอะไรอยู่จากภายนอก) การตั้ง alert การรับมือ incident แล้วปิดท้ายด้วยการขยายระบบ ทั้ง sharding (ตัดข้อมูลแบ่งเก็บหลายเครื่อง) · indexing (ทำดัชนีให้ค้นเร็ว) · และ replication (ทำสำเนาไว้หลายชุด) สิ่งที่ผูกเสานี้กลับเข้ากับทั้งบทความคือคำสั่งเล็กๆ ที่ว่าต้อง "understand the real load" เพราะโหลดจริงคือสิ่งเดียวที่บอกได้ว่า cache ใน memory ของสำเนา 4 ชุดในช่วงที่ 2 เป็นปัญหาหรือยัง agent เขียนโค้ดที่ deploy ได้ให้เราแล้ว แต่ไม่มีทางรู้ว่าโหลดจริงหน้าตายังไง เพราะมันไม่เคยเห็น

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

ช่วงที่ 5พรุ่งนี้ถาม diff เรื่องอะไรได้บ้าง

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

• ค่าที่ cache ไว้ตัวนี้อยู่ที่ไหนกันแน่ ใน process นี้ ใน shared store ใน CDN หรือในเบราว์เซอร์ ถ้าอยู่ใน process นี้ จะมีกี่ process พร้อมกัน
• เขียนตรงไหนที่ทำให้ค่านี้เป็นโมฆะ (invalidate) แล้วบรรทัดนั้นอยู่ใน change เดียวกันนี้ไหม
• การตรวจสิทธิ์ (authorization) ตรงนี้รันอยู่ฝั่ง server จริงๆ หรือ server แค่เชื่อค่าที่ client ส่งมาเฉยๆ
• session นี้รอดจากการ restart ไหม แล้วรอดตอนมี 2 instance ทำงานพร้อมกันด้วยไหม
• endpoint นี้แบ่งหน้า (paginate) ไว้หรือเปล่า แล้วถ้าลูกค้ารายหนึ่งมีข้อมูลเป็นหมื่นแถวจะเกิดอะไรขึ้น
• คอลัมน์ไหนที่เป็น nullable ได้ ต้องถามทุกตัวว่า NULL ตรงนี้แปลว่าอะไร และแปลได้มากกว่าหนึ่งความหมายหรือเปล่า
• ระยะเวลาเก็บข้อมูล (retention) ตรงนี้กำหนดไว้เท่าไร ใครเป็นคนตัดสินใจ แล้วชั้น AI จะเสียอะไรไปตรงขอบเขตนั้น
• นอก repository นี้มีใครอ่านคอลัมน์พวกนี้อยู่บ้าง แล้วรู้รายชื่อทั้งหมดมาจากไหน ค้นแค่ repo เดียวไม่นับว่าไล่รายชื่อครบ
• พอคำถามหลุดขอบเขตของสิ่งที่แหล่งข้อมูลนี้มีอยู่ เครื่องมือตอบกลับมาเป็นผลลัพธ์ว่างเปล่า หรือบอกตรงๆ ว่า unsupported
• แก้ต้นทางแค่บรรทัดเดียวแบบไหน ที่จะทำให้เทสต์ตัวใหม่นี้ขึ้นแดงได้

ไม่มีข้อไหนต้องลงมือเขียน implementation เอง นั่นแหละคือประเด็น พื้นฐานพวกนี้ฝึกได้ตอน review งาน ไม่ต้องรอเข้าคอร์สอย่างเดียว

Ng ปิดท้ายบทความด้วยการบอกว่า นักพัฒนาที่เข้าใจการทำงานของซอฟต์แวร์อย่างลึกซึ้ง "vastly outperform those who vibe code without understanding" โดยอ้างว่ามาจาก internal study ของตัวเอง แต่ไม่เผยตัวเลขออกมาสักตัว จึงควรอ่านเป็นจุดยืนที่ผ่านการไตร่ตรอง ไม่ใช่ผลวัดที่พิสูจน์ได้ ฉบับของเราแคบกว่านั้นแต่เถียงยากกว่าเดิม agent เป็นคนตัดสินใจอยู่ดีไม่ว่าทางไหน ตัวแปรเดียวคือมีใครมองดูมันหรือเปล่า

อีกครึ่งหนึ่งของแผนที่ทักษะคือทักษะเฉพาะด้าน AI ที่ตั้งอยู่บนพื้นฐานเหล่านี้ อ่านได้ที่ ตอนที่ 1 แผนที่ทักษะ AI ของ Andrew Ng

ช่องที่ 3 ของแผนที่คือการใช้ coding agent และคำถามที่แผนที่ไม่ได้ถามคือใครตรวจตัวตรวจ อ่านได้ที่ ตอนที่ 3 ใช้ coding agent ให้เป็น

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

ทำแอปเสร็จแล้วแต่ยังไม่รู้จะเอาขึ้นที่ไหน เราเทียบ 3 เจ้าตามงานไว้แล้ว อ่านได้ที่ Hostinger, Vercel, Cloudflare เลือกตามงาน ไม่ใช่ราคา

§