The latest articles on DEV Community by Prasit Tongpradit (@epichigh). https://dev.to/epichigh https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F1369426%2F17d81754-46a0-4313-a9e3-ac182bf5a60f.jpeg https://dev.to/epichigh en Prasit Tongpradit Sun, 30 Aug 2026 03:00:00 +0000 https://dev.to/epichigh/nakphathnaasngngaanaiderwkhuen-aelwaikhrcchathibaayokhdtnrabbphang-43g7 https://dev.to/epichigh/nakphathnaasngngaanaiderwkhuen-aelwaikhrcchathibaayokhdtnrabbphang-43g7 <p>สมมุติว่าโค้ดชุดหนึ่งผ่าน test ทั้งหมด หน้าจอแสดงเครื่องหมายถูกครบทุกช่อง และเหลือเพียงคนในทีมกดอนุมัติเพื่อนำขึ้น production แล้วมีคนถามว่า “ถ้าข้อมูลจาก API มาไม่ครบ ระบบจะหยุดตรงไหนก่อน”</p> <p>ห้องกลับเงียบ ไม่มีใครเขียนทุกบรรทัดด้วยตัวเอง และไม่มีใครแน่ใจพอจะอธิบายเส้นทางของข้อมูลตั้งแต่ต้นจนจบ</p> <p>งานชิ้นนั้นอาจถูกต้องก็ได้ ความเงียบไม่ได้พิสูจน์ว่ามี bug ซ่อนอยู่ แต่ความเงียบเผยให้เห็นช่องว่างอีกแบบหนึ่ง ทีมสร้างผลลัพธ์ได้เร็วกว่าที่สร้างความเข้าใจ และคนที่กำลังจะรับผิดชอบผลลัพธ์มีหลักให้ตัดสินใจน้อยกว่าที่เครื่องหมายถูกบนหน้าจอทำให้รู้สึก</p> <p>AI ทำให้ช่องว่างนี้เกิดง่ายขึ้น เพราะมันย่นระยะจากคำถามไปถึงคำตอบ นักพัฒนาไม่ต้องจำชื่อฟังก์ชันทุกตัว ไม่ต้องค้นเอกสารหลายหน้า และไม่ต้องเขียนโค้ดซ้ำที่รูปแบบชัดเจนด้วยตัวเอง ทีมได้เวลากลับมาทันที ปัญหาเริ่มขึ้นเมื่อทีมตีความว่า “ได้คำตอบเร็ว” เท่ากับ “เข้าใจคำตอบแล้ว”</p> <p>สองอย่างนี้ไม่ใช่สิ่งเดียวกัน</p> <h2> ความเร็วของโค้ดมองเห็นง่ายกว่าความเข้าใจของคน </h2> <p>ทีมมองเห็นความเร็วจากสิ่งที่นับได้ เช่น จำนวนงานที่ปิด จำนวน pull request และเวลาที่ feature ใช้เดินทางไปถึง production เมื่อเครื่องมือทำให้ตัวเลขเหล่านี้ดีขึ้น ผู้จัดการก็มีเหตุผลที่จะสนับสนุน นักพัฒนาเองมีเหตุผลไม่ต่างกัน เมื่อ prompt ไม่กี่บรรทัดสร้างร่างที่ใช้งานต่อได้ การกลับไปเริ่มจากหน้าว่างจึงดูเหมือนใช้เวลาโดยไม่จำเป็น</p> <p>ความเข้าใจกลับไม่ทิ้งร่องรอยที่ชัดเท่า เราไม่เห็นจากจำนวนบรรทัดว่าเจ้าของงานรู้เหตุผลของการออกแบบหรือไม่ เราไม่เห็นจาก test ที่ผ่านว่าเขาคาดเดาผลข้างเคียงเมื่อ requirement เปลี่ยนได้แค่ไหน และเราไม่เห็นจากความเร็วในการส่งงานว่าเขาจะเริ่ม debugging ตรงไหนเมื่ออาการจริงไม่ตรงกับกรณีที่เคยทดสอบ</p> <p>ความต่างนี้ทำให้ทีมมีโอกาสให้รางวัลผิดสิ่งโดยไม่ตั้งใจ คนที่ส่งงานผ่านเร็วได้รับสัญญาณว่าพฤติกรรมของเขาถูกต้อง ส่วนเวลาที่ใช้แกะเอกสาร ทดลองสมมุติฐาน หรืออธิบายโค้ดให้เพื่อนฟังดูเหมือนความล่าช้า ทั้งที่กิจกรรมเหล่านี้กำลังสร้างความสามารถที่ทีมต้องใช้ในวันที่คำตอบสำเร็จรูปไม่พอดีกับปัญหา</p> <p>แรงกดดันจึงไม่จำเป็นต้องมาในรูปคำสั่งว่า “ใช้ AI ให้มากขึ้น” แค่ทีมตั้งกำหนดส่งตามความเร็วใหม่ แต่ยังใช้กระบวนการตรวจสอบเดิม นักพัฒนาก็ต้องผลิตโค้ดมากขึ้นภายในเวลาเท่าเดิม เขามีทางเลือกน้อยลงว่าจะอ่านทุกบรรทัดหรือทดลองทุกเงื่อนไขได้ลึกเพียงใด เครื่องมือสร้างงานเร็วขึ้น ขณะที่ความสามารถของมนุษย์ในการตรวจงานไม่ได้เพิ่มขึ้นตาม prompt</p> <p>คำถามว่า AI ทำให้นักพัฒนาเก่งขึ้นหรือแย่ลงจึงง่ายเกินไป เครื่องมืออาจเพิ่มผลงานและลดความเข้าใจพร้อมกันได้ ทีมเห็นงานที่เสร็จเพิ่มขึ้นทันที แต่ความสามารถที่ลดลงอาจซ่อนอยู่จนกว่าจะมีเหตุให้ต้องอธิบาย ตัดสินใจ หรือแก้ระบบภายใต้เวลาอันจำกัด</p> <h2> ทักษะอ่อนลงเมื่อขั้นตอนคิดไม่ได้ถูกเรียกใช้งาน </h2> <p>การเปิด AI ไม่ได้ลบทักษะออกจากหัวใคร นักพัฒนาไม่ได้ลืมวิธีแก้ปัญหาเพียงเพราะขอให้เครื่องมือร่างฟังก์ชันหนึ่งครั้ง ทักษะค่อย ๆ อ่อนลงเมื่อคนข้ามขั้นตอนเดิมซ้ำจนไม่ต้องใช้มันอีก เขาไม่แยกปัญหาเอง ไม่เขียนสมมุติฐานก่อนดูคำตอบ และไม่ตรวจว่าคำตอบขัดกับภาพของระบบที่มีอยู่ในหัวหรือไม่</p> <p>นักพัฒนาฝึกคิดขณะหาคำตอบ เขาอ่าน error message แล้วเดาว่าส่วนใดน่าจะผิด เปิดเอกสารเพื่อแยกพฤติกรรมที่รับประกันออกจากสิ่งที่ตัวเองเคยชิน แล้วลองแก้หนึ่งจุดเพื่อดูว่าอาการเปลี่ยนอย่างไร แม้คำตอบแรกไม่ถูก ความผิดพลาดก็ช่วยปรับภาพของระบบให้แม่นขึ้น</p> <p>เมื่อ AI ส่งคำตอบที่ดูสมบูรณ์มาให้ ขั้นตอนกลางเหล่านี้อาจหายไป นักพัฒนานำโค้ดไปทดลอง เห็น test ผ่าน แล้วหยุด การหยุดตรงนั้นประหยัดเวลาในงานปัจจุบัน แต่เขาไม่ได้ลงมือเชื่อมอาการกับสาเหตุ หากปัญหาครั้งถัดไปต่างออกไปเล็กน้อย เขาจึงต้องกลับไปเริ่มจากการถามใหม่ แทนที่จะใช้ภาพของระบบที่สร้างไว้แล้วคาดเดาทิศทาง</p> <p>ความจำไม่ใช่ความสามารถเดียวที่อาจอ่อนลง นักพัฒนาอาจจำชื่อ API ได้น้อยลงโดยไม่เสียความสามารถสำคัญ เพราะชื่อเหล่านั้นค้นใหม่ได้ สิ่งที่ค้นแทนได้ยากกว่าคือแบบจำลองในหัวว่าองค์ประกอบแต่ละส่วนสัมพันธ์กันอย่างไร ข้อมูลเดินไปทางไหน เงื่อนไขใดห้ามละเมิด และการแก้จุดหนึ่งจะผลักปัญหาไปปรากฏที่ใด</p> <p>เราควรแยก “รายละเอียดที่ค้นใหม่ได้” ออกจาก “ภาพของระบบที่ใช้ตัดสินใจ” ให้ชัด เครื่องมือเหมาะมากกับงานประเภทแรก นักพัฒนาไม่จำเป็นต้องเก็บทุกชื่อและทุกไวยากรณ์ไว้ในความจำ แต่เมื่อเขาต้องเลือกว่าควรเชื่อคำตอบใด ภาพของระบบต้องมีอยู่ก่อน มิฉะนั้นเขาจะเปรียบเทียบได้เพียงว่าคำตอบไหนดูเรียบร้อยกว่า ไม่ใช่คำตอบไหนเหมาะกับระบบจริง</p> <p>AI ไม่ได้ทำให้การเรียนรู้หายไปเอง เครื่องมือเพียงลดจำนวนขั้นตอนจากปัญหาไปถึงคำตอบ ส่วนคนเป็นผู้เลือกว่าจะข้ามขั้นตอนไหน ถ้าข้ามเพียงงานค้นชื่อฟังก์ชัน ทีมได้เวลากลับมา แต่ถ้าข้ามการตั้งสมมุติฐาน การตรวจข้อจำกัด และการอธิบายเหตุผล ทีมกำลังลดโอกาสฝึกทักษะที่ต้องใช้รับผิดชอบงาน</p> <h2> นักพัฒนาทำงานได้กว้างขึ้น แม้จะรู้ไม่ลึกทุกส่วน </h2> <p>การปกป้องความรู้เชิงลึกทุกชนิดไม่ใช่คำตอบ นักพัฒนามีเวลาและความจำจำกัด ไม่มีใครรู้ทุกส่วนของระบบได้ละเอียดเท่ากัน และงานจำนวนมากไม่คุ้มกับการศึกษาลงไปถึงชั้นล่างสุดก่อนเริ่มลงมือ หากเครื่องมือช่วยให้คนหนึ่งทดลองงานนอกความถนัดได้เร็วขึ้น เขาก็มีทางเลือกมากกว่าการรอผู้เชี่ยวชาญก่อนเริ่มทุกงาน</p> <p>ในทีมเล็ก นักพัฒนาคนหนึ่งอาจต้องดูแลหน้าเว็บ แก้ API และแตะงาน deployment ภายในสัปดาห์เดียว AI ช่วยอธิบายคำศัพท์ที่ไม่คุ้น ร่างโครงเริ่มต้น และชี้จุดที่ควรเปิดเอกสารต่อ คนคนนั้นไม่จำเป็นต้องกลายเป็นผู้เชี่ยวชาญทุกด้าน เขาเพียงต้องเดินเข้าไปในพื้นที่ใหม่ได้เร็วพอที่จะทำงานร่วมกับเจ้าของระบบหรือสร้างต้นแบบที่ช่วยให้ทีมตัดสินใจ</p> <p>การรู้กว้างมีคุณค่าในตัวเอง เพราะช่วยให้คนเปลี่ยนบริบท มองเห็นทางเลือกหลายแบบ และเชื่อมงานข้ามส่วนได้ บางปัญหาต้องการคนที่เห็นว่าอาการในหน้าจออาจเริ่มจากข้อมูลหลังบ้าน ไม่ได้ต้องการคนที่จำรายละเอียดทุกชั้นได้โดยไม่เปิดเอกสาร</p> <p>แต่ความกว้างสร้างประโยชน์ได้ต่อเมื่อทีมรู้ว่าตรงไหนคือขอบเขตของมัน นักพัฒนาที่เพิ่งทำงานนอกความถนัดต้องแยกให้ออกว่าเขาเข้าใจพอจะทดลอง หรือเข้าใจพอจะอนุมัติการเปลี่ยนแปลงที่คนอื่นต้องพึ่งพา สองระดับนี้ต้องการหลักฐานไม่เท่ากัน โค้ดสำหรับต้นแบบอาจยอมรับความไม่แน่นอนได้ แต่โค้ดที่จัดการสิทธิ์ ข้อมูลสำคัญ หรือการชำระเงินต้องมีคนที่ตรวจข้อสมมุติได้ลึกกว่านั้น</p> <p>ระบบส่วนสำคัญจึงยังต้องมีคนที่รู้ลึกพอจะเห็นว่าคำตอบกำลังละเมิดเงื่อนไขใด อธิบายได้ว่าทำไมระบบจึงออกแบบเช่นนี้ และสร้างทางเลือกใหม่เมื่อแนวทางที่มีอยู่ใช้ไม่ได้ ความรู้กว้างช่วยให้ทีมเคลื่อนตัวเร็ว ส่วนความรู้ลึกช่วยจับข้อผิดพลาดที่คำตอบระดับผิวหน้าไม่เปิดเผย</p> <p>ข้อแลกเปลี่ยนไม่ได้อยู่ระหว่างใช้หรือไม่ใช้ AI แต่อยู่ที่ทีมจะกระจายความลึกอย่างไร ทุกคนไม่ต้องรู้ทุกเรื่อง แต่ระบบส่วนสำคัญควรมีคนซึ่งเข้าใจมากกว่าคำตอบล่าสุดจากเครื่องมือ หากไม่มีคนกลุ่มนี้ ความรู้ของทีมจะผูกอยู่กับชุด prompt และความพร้อมของเครื่องมือมากกว่าตัวระบบที่ต้องดูแล</p> <h2> code review ช่วยไม่ได้เมื่อคนตรวจไม่มีคำอธิบายของตัวเอง </h2> <p>ทีมอาจวางความหวังไว้ที่ code review ว่าถ้า AI สร้างโค้ดผิด คนจะตรวจพบก่อนนำขึ้นระบบ เหตุผลนี้ฟังขึ้น แต่มีเงื่อนไขสำคัญ: ผู้ตรวจต้องมีภาพของระบบที่เป็นอิสระจากคำตอบชุดเดียวกับผู้เขียน</p> <p>ถ้าผู้เขียนรับโค้ดจาก AI แล้วส่งให้ผู้ตรวจซึ่งใช้ AI อธิบายโค้ดก้อนเดิม ทีมอาจเห็นถ้อยคำสองชุดแต่ยังพึ่งแหล่งเหตุผลแบบเดียวกัน คำอธิบายอาจลื่นไหล รูปแบบอาจดูเรียบร้อย และ test อาจผ่านทุกกรณีที่ทีมเขียนไว้ ปัญหาคือไม่มีใครสร้างสมมุติฐานอีกชุดขึ้นมาเพื่อท้าทายคำตอบเดิม</p> <p>code review ที่มีความหมายจึงไม่ได้ถามเพียงว่าโค้ดดูดีหรือไม่ ผู้ตรวจควรถามว่าข้อมูลที่ไม่ครบจะถูกจัดการตรงไหน เหตุใดจึงเลือกวางเงื่อนไขไว้ชั้นนี้ การทำงานพร้อมกันสองคำขอจะสร้างสถานะใด และถ้าต้องย้อนการเปลี่ยนแปลง ทีมจะรักษาข้อมูลส่วนไหนไว้ คำถามเหล่านี้บังคับให้เจ้าของงานอธิบายความสัมพันธ์ แทนการอ่านสรุปของโค้ดกลับมาให้ฟัง</p> <p>หากเจ้าของงานตอบไม่ได้ ทีมไม่จำเป็นต้องห้ามใช้โค้ดทันที คำตอบที่ซื่อสัตย์ว่า “ยังไม่เข้าใจส่วนนี้” มีค่ามากกว่าความมั่นใจที่ยืมมาจากหน้าจอ ทีมสามารถลดขอบเขต เพิ่มการทดลอง หรือชวนคนที่มีความรู้ลึกมาช่วยได้ ปัญหาจะรุนแรงเมื่อวัฒนธรรมของทีมทำให้การยอมรับว่าไม่เข้าใจดูแย่กว่าการอนุมัติงานที่อธิบายไม่ได้</p> <p>ชุด test ก็มีข้อจำกัดคล้ายกัน มันพิสูจน์เฉพาะพฤติกรรมที่ทีมเลือกตรวจ หากคนสร้าง test และคนตรวจใช้ภาพปัญหาชุดเดียวกัน ทั้งคู่อาจพลาดเงื่อนไขเดียวกัน เครื่องหมายถูกจึงเป็นหลักฐานว่าโค้ดผ่านคำถามที่เราเขียน ไม่ใช่หลักฐานว่าเราเขียนคำถามครบแล้ว</p> <p>หน้าที่ของมนุษย์ไม่ได้อยู่ที่ตรวจทุกตัวอักษรซึ่งเครื่องมือสร้าง หน้าที่อยู่ที่กำหนดว่าคำตอบต้องเคารพเงื่อนไขใด เลือกหลักฐานแบบไหนจึงเพียงพอ และหยุดงานเมื่อความไม่แน่นอนเกินระดับที่ระบบรับได้ AI ช่วยผลิตและอธิบายได้ แต่คนที่กดอนุมัติยังต้องรับผิดชอบการตัดสินใจว่า “พอแล้ว” ด้วยเหตุผลของตัวเอง</p> <h2> โค้ดที่รันได้อาจซ่อนว่าความเข้าใจยังตามไม่ทัน </h2> <p>เมื่อนักพัฒนาที่เชี่ยวชาญหน้าเว็บต้องแก้โค้ดระดับล่าง เขารู้ว่ากำลังออกนอกพื้นที่คุ้นเคย จึงมีเหตุผลให้อ่านเอกสารหรือขอผู้เชี่ยวชาญช่วยตรวจ ปัญหาเกิดเมื่อ AI ทำให้ผลลัพธ์แรกดูใกล้เส้นชัยมากจนระยะห่างของความรู้มองเห็นยากขึ้น</p> <p>เมื่อเครื่องมือสร้างไฟล์ โครงสร้าง และ test มาให้ครบ นักพัฒนาอาจประเมินว่างานเหลือเพียงเก็บรายละเอียด ทั้งที่เขายังไม่รู้ข้อจำกัดของระบบที่กำลังแตะ โค้ดที่รันได้จึงอาจสร้างความมั่นใจเร็วกว่าความเข้าใจที่ใช้ดูแลมัน</p> <p>ผู้เชี่ยวชาญก็อาจเจอช่องว่างแบบเดียวกัน เขาตรวจคำตอบในเรื่องที่ถนัดได้ดี จึงค่อย ๆ เชื่อใจเครื่องมือมากขึ้น แต่เมื่อขยับสู่งานข้างเคียง ความมั่นใจเดิมอาจอยู่ต่อทั้งที่ฐานความรู้บางลง หากไม่หยุดกำหนดขอบเขตใหม่ เขาอาจอนุมัติงานด้วยระดับความมั่นใจที่ไม่ตรงกับสิ่งที่ตัวเองรู้</p> <p>เส้นแบ่งที่มีประโยชน์จึงไม่ใช่ junior กับ senior หรือคนใช้ AI กับคนไม่ใช้ แต่เป็นคนที่รู้ขอบเขตของตัวเองกับคนที่วัดความรู้จากคุณภาพของผลลัพธ์ นักพัฒนาคนแรกสามารถใช้ AI อย่างหนักและยังหยุดถามเมื่อไม่แน่ใจ ส่วนนักพัฒนาคนหลังอาจใช้ AI เพียงบางครั้ง แต่รับคำตอบเร็วเกินไปเพราะมันตรงกับสิ่งที่อยากเชื่อ</p> <p>การรักษาความสงสัยไม่ได้แปลว่าต้องตรวจทุกเรื่องเท่ากัน การช่วยร่างข้อความทั่วไปไม่ต้องใช้กระบวนการเดียวกับโค้ดที่แก้ข้อมูลถาวร ความพยายามควรเพิ่มตามต้นทุนของความผิดพลาด ความยากในการย้อนกลับ และจำนวนคนที่ต้องพึ่งพาผลลัพธ์ ทีมที่ใช้หลักนี้ไม่ต่อต้านความเร็ว เพียงไม่ยอมให้ความเร็วตัดสินระดับความเชื่อมั่นแทนความเสี่ยง</p> <h2> ทีมต้องเก็บการตัดสินใจบางส่วนไว้ให้มนุษย์ฝึกจริง </h2> <p>คำแนะนำให้ทุกคน “มีวินัย” ยังไม่พอ นักพัฒนาทำงานภายใต้กำหนดส่ง วิธีประเมินผลงาน และความคาดหวังของทีม หากองค์กรนับเฉพาะงานที่ปิด แต่หวังให้คนใช้เวลาสร้างความเข้าใจด้วยความสมัครใจ องค์กรกำลังให้รางวัลกับพฤติกรรมหนึ่งและฝากความปลอดภัยไว้กับอีกพฤติกรรมหนึ่ง</p> <p>ทีมควรออกแบบลำดับงานให้การคิดของมนุษย์ทิ้งหลักฐานไว้ ก่อนขอคำตอบ นักพัฒนาอาจเขียนสั้น ๆ ว่าปัญหาน่าจะเกิดตรงไหน มีข้อจำกัดอะไร และจะสังเกตอย่างไรว่าการแก้สำเร็จ ข้อความนี้ไม่ต้องเป็นเอกสารยาว จุดประสงค์คือให้คนสร้างภาพปัญหาของตัวเองก่อนเห็นคำตอบที่อาจดึงความคิดทั้งหมดไปทิศเดียว</p> <p>หลัง AI สร้างโค้ด เจ้าของงานอาจเปลี่ยนเงื่อนไขหนึ่งข้อแล้วทำนายผลก่อนรัน test ถ้าเขาอธิบายไม่ได้ว่าพฤติกรรมควรเปลี่ยนอย่างไร เขายังมีโค้ดที่ใช้งานได้ แต่ยังเข้าใจไม่พอจะดูแลมัน การทดลองเล็ก ๆ แบบนี้เปิดช่องว่างได้ตรงกว่าการถามว่า “เข้าใจไหม” เพราะการทำนายบังคับให้คนแสดงภาพของระบบที่อยู่ในหัว</p> <p>ใน code review ทีมควรให้ความสำคัญกับเหตุผลที่ตรวจสอบได้ ไม่ใช่ที่มาของแต่ละบรรทัด โค้ดที่มนุษย์เขียนเองอาจผิด และโค้ดที่ AI ร่างอาจถูกต้อง เจ้าของงานจึงควรได้รับความไว้วางใจเมื่ออธิบายข้อจำกัด แสดงหลักฐาน และบอกได้ว่าตรงไหนยังไม่แน่ใจ ไม่ใช่เพราะเขาพิมพ์โค้ดเองหรือใช้เครื่องมือชนิดใด</p> <p>ทีมยังต้องกำหนดเจ้าของการตัดสินใจให้ชัด AI อาจเสนอวิธีแก้ นักพัฒนาอาจนำไปใช้ ผู้ตรวจอาจอนุมัติ และระบบอัตโนมัติอาจนำขึ้น production แต่เมื่อระบบทำงานผิด คนกลุ่มนี้ต้องรู้ว่าใครมีอำนาจหยุด ใครต้องอธิบาย และใครรับหน้าที่แก้ไข หากทุกคนรับผิดชอบเพียงขั้นตอนของตัวเอง ไม่มีใครรับผิดชอบผลลัพธ์ทั้งชิ้น</p> <p>แนวทางเหล่านี้มีต้นทุน งานบางชิ้นจะช้าลง และนักพัฒนาจะต้องใช้แรงคิดกับเรื่องที่เครื่องมือสามารถตอบได้ทันที ทีมจึงไม่ควรใช้ความเข้มเท่ากันทุกงาน งานที่ย้อนกลับง่ายอาจทดลองเร็วได้ ส่วนงานที่ย้อนกลับยากหรือกระทบคนจำนวนมากต้องการหลักฐานและความรู้ลึกกว่า การรักษาทักษะไม่ควรกลายเป็นพิธีกรรมที่บังคับให้คนทำงานช้าโดยไม่มีเหตุผล</p> <p>เป้าหมายคือเลือกอย่างตั้งใจว่าขั้นตอนไหนเป็นเพียงแรงงาน และขั้นตอนไหนกำลังฝึกวิจารณญาณ หากทีมแยกสองอย่างนี้ไม่ออก ระบบอัตโนมัติมีโอกาสตัดทั้งคู่ทิ้งพร้อมกัน เพราะจากมุมของตัวเลขเวลา ทั้งสองอย่างดูเหมือนความล่าช้าเหมือนกัน</p> <h2> วิศวกรไม่จำเป็นต้องรู้ทุกคำตอบ แต่ต้องรู้ว่าคำตอบใดควรถูกสงสัย </h2> <p>ถ้าให้ความฉลาดหมายถึงการตอบได้โดยไม่มีความช่วยเหลือ การพึ่ง AI ก็ลดโอกาสฝึกความสามารถแบบนั้น นักพัฒนาอาจจำรายละเอียดน้อยลงและเรียกข้อมูลจากเครื่องมือมากขึ้น แต่คำนิยามนี้ให้คุณค่ากับการเก็บคำตอบมากกว่าการเลือกใช้คำตอบ ในงานวิศวกรรม การมีข้อมูลยังไม่พอ เพราะข้อมูลที่ถูกต้องอาจถูกนำไปใช้ภายใต้เงื่อนไขที่ไม่เหมาะกับระบบจริง</p> <p>วิศวกรที่ดีไม่ต้องจำชื่อฟังก์ชันทุกตัว สิ่งสำคัญกว่าคือมองออกว่าฟังก์ชันนั้นกำลังถูกใช้ภายใต้สมมุติฐานใด เขาอาจไม่ได้สร้างทุกชั้นด้วยตัวเอง แต่ต้องรู้ว่าชั้นใดเป็นจุดเสี่ยงและควรเรียกใครมาช่วย เขารับคำตอบจาก AI ได้ ตราบใดที่มีภาพของระบบแข็งแรงพอจะสังเกตเมื่อคำตอบนั้นไม่เข้าพวก</p> <p>ความสามารถแบบนี้เกิดจากการสัมผัสงานอย่างต่อเนื่อง คนต้องตั้งคำถาม ทำนาย ทดลอง อธิบาย และรับผลจากการตัดสินใจ หาก AI รับหน้าที่ทั้งหมดตั้งแต่ตีโจทย์จนถึงอธิบายผล มนุษย์จะเหลือเพียงการกดอนุมัติ และการกดซ้ำ ๆ ไม่ได้ฝึกวิจารณญาณให้ดีขึ้น ต่อให้ผลลัพธ์ส่วนใหญ่ถูกต้องก็ตาม</p> <p>AI จึงทำให้นักพัฒนาเก่งขึ้นได้ เมื่อมันรับภาระที่ค้นคืนง่ายและคืนเวลาให้คนคิดเรื่องข้อจำกัด การออกแบบ และผลกระทบ มันทำให้นักพัฒนาอ่อนลงได้เช่นกัน เมื่อความเร็วที่เพิ่มขึ้นถูกใช้เป็นเหตุผลให้ข้ามการคิดทุกอย่างที่วัดยาก เครื่องมือเดียวกันให้ผลต่างกัน เพราะทีมเลือกเก็บงานคนละส่วนไว้ให้มนุษย์</p> <p>กลับไปที่โค้ดซึ่งผ่าน test และรอการอนุมัติ คำถามสำคัญไม่ใช่ว่าใครเป็นคนพิมพ์โค้ด ไม่ใช่ว่าทีมใช้ prompt มากแค่ไหน และไม่ใช่ว่าหน้าจอมีเครื่องหมายถูกกี่ช่อง</p> <p>คำถามคือ เมื่อข้อมูลจาก API มาไม่ครบ ใครในห้องยังกล้าชี้ไปยังจุดแรกที่ควรตรวจ—ก่อนจะเปิดช่อง prompt แล้วเริ่มถามใหม่ตั้งแต่ต้น</p> ai programming softwareengineering productivity