นักพัฒนาส่งงานได้เร็วขึ้น แล้วใครจะอธิบายโค้ดตอนระบบพัง

สมมุติว่าโค้ดชุดหนึ่งผ่าน test ทั้งหมด หน้าจอแสดงเครื่องหมายถูกครบทุกช่อง และเหลือเพียงคนในทีมกดอนุมัติเพื่อนำขึ้น production แล้วมีคนถามว่า “ถ้าข้อมูลจาก API มาไม่ครบ ระบบจะหยุดตรงไหนก่อน”

ห้องกลับเงียบ ไม่มีใครเขียนทุกบรรทัดด้วยตัวเอง และไม่มีใครแน่ใจพอจะอธิบายเส้นทางของข้อมูลตั้งแต่ต้นจนจบ

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

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

สองอย่างนี้ไม่ใช่สิ่งเดียวกัน

ความเร็วของโค้ดมองเห็นง่ายกว่าความเข้าใจของคน

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

ความเข้าใจกลับไม่ทิ้งร่องรอยที่ชัดเท่า เราไม่เห็นจากจำนวนบรรทัดว่าเจ้าของงานรู้เหตุผลของการออกแบบหรือไม่ เราไม่เห็นจาก test ที่ผ่านว่าเขาคาดเดาผลข้างเคียงเมื่อ requirement เปลี่ยนได้แค่ไหน และเราไม่เห็นจากความเร็วในการส่งงานว่าเขาจะเริ่ม debugging ตรงไหนเมื่ออาการจริงไม่ตรงกับกรณีที่เคยทดสอบ

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

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

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

ทักษะอ่อนลงเมื่อขั้นตอนคิดไม่ได้ถูกเรียกใช้งาน

การเปิด AI ไม่ได้ลบทักษะออกจากหัวใคร นักพัฒนาไม่ได้ลืมวิธีแก้ปัญหาเพียงเพราะขอให้เครื่องมือร่างฟังก์ชันหนึ่งครั้ง ทักษะค่อย ๆ อ่อนลงเมื่อคนข้ามขั้นตอนเดิมซ้ำจนไม่ต้องใช้มันอีก เขาไม่แยกปัญหาเอง ไม่เขียนสมมุติฐานก่อนดูคำตอบ และไม่ตรวจว่าคำตอบขัดกับภาพของระบบที่มีอยู่ในหัวหรือไม่

นักพัฒนาฝึกคิดขณะหาคำตอบ เขาอ่าน error message แล้วเดาว่าส่วนใดน่าจะผิด เปิดเอกสารเพื่อแยกพฤติกรรมที่รับประกันออกจากสิ่งที่ตัวเองเคยชิน แล้วลองแก้หนึ่งจุดเพื่อดูว่าอาการเปลี่ยนอย่างไร แม้คำตอบแรกไม่ถูก ความผิดพลาดก็ช่วยปรับภาพของระบบให้แม่นขึ้น

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

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

เราควรแยก “รายละเอียดที่ค้นใหม่ได้” ออกจาก “ภาพของระบบที่ใช้ตัดสินใจ” ให้ชัด เครื่องมือเหมาะมากกับงานประเภทแรก นักพัฒนาไม่จำเป็นต้องเก็บทุกชื่อและทุกไวยากรณ์ไว้ในความจำ แต่เมื่อเขาต้องเลือกว่าควรเชื่อคำตอบใด ภาพของระบบต้องมีอยู่ก่อน มิฉะนั้นเขาจะเปรียบเทียบได้เพียงว่าคำตอบไหนดูเรียบร้อยกว่า ไม่ใช่คำตอบไหนเหมาะกับระบบจริง

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

นักพัฒนาทำงานได้กว้างขึ้น แม้จะรู้ไม่ลึกทุกส่วน

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

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

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

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

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

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

code review ช่วยไม่ได้เมื่อคนตรวจไม่มีคำอธิบายของตัวเอง

ทีมอาจวางความหวังไว้ที่ code review ว่าถ้า AI สร้างโค้ดผิด คนจะตรวจพบก่อนนำขึ้นระบบ เหตุผลนี้ฟังขึ้น แต่มีเงื่อนไขสำคัญ: ผู้ตรวจต้องมีภาพของระบบที่เป็นอิสระจากคำตอบชุดเดียวกับผู้เขียน

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

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

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

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

หน้าที่ของมนุษย์ไม่ได้อยู่ที่ตรวจทุกตัวอักษรซึ่งเครื่องมือสร้าง หน้าที่อยู่ที่กำหนดว่าคำตอบต้องเคารพเงื่อนไขใด เลือกหลักฐานแบบไหนจึงเพียงพอ และหยุดงานเมื่อความไม่แน่นอนเกินระดับที่ระบบรับได้ AI ช่วยผลิตและอธิบายได้ แต่คนที่กดอนุมัติยังต้องรับผิดชอบการตัดสินใจว่า “พอแล้ว” ด้วยเหตุผลของตัวเอง

โค้ดที่รันได้อาจซ่อนว่าความเข้าใจยังตามไม่ทัน

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

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

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

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

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

ทีมต้องเก็บการตัดสินใจบางส่วนไว้ให้มนุษย์ฝึกจริง

คำแนะนำให้ทุกคน “มีวินัย” ยังไม่พอ นักพัฒนาทำงานภายใต้กำหนดส่ง วิธีประเมินผลงาน และความคาดหวังของทีม หากองค์กรนับเฉพาะงานที่ปิด แต่หวังให้คนใช้เวลาสร้างความเข้าใจด้วยความสมัครใจ องค์กรกำลังให้รางวัลกับพฤติกรรมหนึ่งและฝากความปลอดภัยไว้กับอีกพฤติกรรมหนึ่ง

ทีมควรออกแบบลำดับงานให้การคิดของมนุษย์ทิ้งหลักฐานไว้ ก่อนขอคำตอบ นักพัฒนาอาจเขียนสั้น ๆ ว่าปัญหาน่าจะเกิดตรงไหน มีข้อจำกัดอะไร และจะสังเกตอย่างไรว่าการแก้สำเร็จ ข้อความนี้ไม่ต้องเป็นเอกสารยาว จุดประสงค์คือให้คนสร้างภาพปัญหาของตัวเองก่อนเห็นคำตอบที่อาจดึงความคิดทั้งหมดไปทิศเดียว

หลัง AI สร้างโค้ด เจ้าของงานอาจเปลี่ยนเงื่อนไขหนึ่งข้อแล้วทำนายผลก่อนรัน test ถ้าเขาอธิบายไม่ได้ว่าพฤติกรรมควรเปลี่ยนอย่างไร เขายังมีโค้ดที่ใช้งานได้ แต่ยังเข้าใจไม่พอจะดูแลมัน การทดลองเล็ก ๆ แบบนี้เปิดช่องว่างได้ตรงกว่าการถามว่า “เข้าใจไหม” เพราะการทำนายบังคับให้คนแสดงภาพของระบบที่อยู่ในหัว

ใน code review ทีมควรให้ความสำคัญกับเหตุผลที่ตรวจสอบได้ ไม่ใช่ที่มาของแต่ละบรรทัด โค้ดที่มนุษย์เขียนเองอาจผิด และโค้ดที่ AI ร่างอาจถูกต้อง เจ้าของงานจึงควรได้รับความไว้วางใจเมื่ออธิบายข้อจำกัด แสดงหลักฐาน และบอกได้ว่าตรงไหนยังไม่แน่ใจ ไม่ใช่เพราะเขาพิมพ์โค้ดเองหรือใช้เครื่องมือชนิดใด

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

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

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

วิศวกรไม่จำเป็นต้องรู้ทุกคำตอบ แต่ต้องรู้ว่าคำตอบใดควรถูกสงสัย

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

วิศวกรที่ดีไม่ต้องจำชื่อฟังก์ชันทุกตัว สิ่งสำคัญกว่าคือมองออกว่าฟังก์ชันนั้นกำลังถูกใช้ภายใต้สมมุติฐานใด เขาอาจไม่ได้สร้างทุกชั้นด้วยตัวเอง แต่ต้องรู้ว่าชั้นใดเป็นจุดเสี่ยงและควรเรียกใครมาช่วย เขารับคำตอบจาก AI ได้ ตราบใดที่มีภาพของระบบแข็งแรงพอจะสังเกตเมื่อคำตอบนั้นไม่เข้าพวก

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

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

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

คำถามคือ เมื่อข้อมูลจาก API มาไม่ครบ ใครในห้องยังกล้าชี้ไปยังจุดแรกที่ควรตรวจ—ก่อนจะเปิดช่อง prompt แล้วเริ่มถามใหม่ตั้งแต่ต้น