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

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

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

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

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

บทความของ 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 เลือกค่าให้เอง เทสต์ผ่าน หน้าโหลดเร็ว ส่วนความผิดถูกนัดไว้ล่วงหน้าอีกสามสัปดาห์ข้างหน้า

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 คำนี้คือสิ่งที่ทุกการตัดสินใจในช่วงถัดๆ ไปต้องเอามาชั่งกันเอง

ช่วงที่ 2agentic coding ปลดปล่อยเรา หรือเกณฑ์เราเข้าประจำการ?

เกณฑ์เราต่างหาก บทบาทที่ขยายออกไป 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 อายุห้านาทีไว้หน้า summary query แล้วเก็บไว้ใน memory ของแอปเอง บนแล็ปท็อปถูกต้องเป๊ะ เพราะมีแอปสำเนาเดียว ผู้ใช้คนเดียว แต่ใน production มีสำเนา 4 ชุดอยู่หลัง load balancer ผู้ใช้แก้ไขข้อมูล คำสั่งเขียนตกไปที่สำเนาที่สอง request ถัดไปวิ่งกลับไปที่สำเนาแรกซึ่งยังไม่เห็นการแก้ไขนั้น ผู้ใช้เลยแก้ซ้ำอีกรอบ ตอนนี้มีข้อมูล 2 ชุดแล้ว และไม่มี error โผล่มาเลยสักตัว

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

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

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

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."

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

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

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

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

• ไม่เคยถูกโมเดลไว้ ข้อเท็จจริงนั้นไม่เคยเป็น field มาก่อน มี amount แต่ไม่มี reason ระบบตอบได้แค่ว่าเท่าไหร่ ไม่เคยตอบว่าทำไม แล้วไม่มีผลลัพธ์ไหนใบ้เลยว่าคำถามว่าทำไมนั้นเคยตอบได้
• ถูกลบทิ้งเพราะ retention หน้าต่างเก้าสิบวันของประวัติการโต้ตอบ แปลว่าถ้าเรื่องนั้นเกิดขึ้นเกินเก้าสิบวันที่ผ่านมา agent ที่ถูกถามว่าลูกค้ารายนี้เคยยกเรื่องนี้ขึ้นมาไหม ก็ตอบว่าใช่ไม่ได้เลย จะไม่บอกว่าเห็นได้แค่เก้าสิบวัน จะบอกว่าไม่เคยเลยต่างหาก คนที่เลือกหน้าต่างเก้าสิบวันนั้นกำลังชั่งน้ำหนักระหว่างต้นทุน storage กับกฎ compliance อยู่ ไม่มีใครในห้องนั้นกำลังตัดสินใจเรื่อง memory horizon ของระบบที่ตอนนั้นยังไม่มีอยู่เลย
• เข้าไม่ถึง แถวข้อมูลนั้นมีอยู่จริง แต่เส้นทาง retrieval ไปถึงไม่ได้ อาจเพราะ filter กันไว้ permission scope บังไว้ field ไม่ถูก index หรือ 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 ที่ไม่เคยรายงานขีดจำกัดของตัวเองสักครั้งเดียว ก็ยังไม่เคยพิสูจน์ว่าตรวจจับขีดจำกัดได้จริง

ช่วงที่ 4ส่วนที่เหลือของแผนที่ เล่าจบในเรื่องเดียว

สถาปัตยกรรมคือจุดที่บทความนี้แม่นที่สุดแบบเงียบๆ 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 พูดถึงแค่นี้แล้วหยุด ส่วนที่เราอยากเติมคือ irreversibility จริงๆ ไปกองอยู่ตรงไหนของระบบ ประตูทางเดียวไม่ได้กระจายเท่ากันทั่วทั้งระบบ มันไปกองอยู่ที่ขอบ ขอบพวกนี้คือ URL ที่เผยแพร่ไปแล้ว รูปทรง API ที่ client รายที่สองรับไปใช้แล้ว ID ที่ user เห็นอยู่ตรงหน้า tenant key ตัวแรกที่ migration แตะไปแล้ว ตำแหน่งจริงที่ byte นอนอยู่ และสิ่งที่เคยสัญญาไว้ว่าจะลบทิ้ง โครงสร้างภายในของระบบยังกลับตัวได้นานกว่าที่คนส่วนใหญ่คิดไว้ ส่วน interface กลับย้อนกลับไม่ได้เร็วกว่าที่คิดไว้เหมือนกัน กฎที่ได้จากตรงนี้คือ ใช้ความคิดให้มากตรงขอบ แล้วเร่งความเร็วตรงกลาง

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

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

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

ช่วงที่ 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 เป็นคนตัดสินใจอยู่ดีไม่ว่าทางไหน ตัวแปรเดียวคือมีใครมองดูมันหรือเปล่า

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

§