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

คนที่เพิ่งหัดสร้างของด้วย AI ในปี 2026 แค่พิมพ์อธิบายสิ่งที่อยากได้ไม่กี่ประโยค ก็ได้ของที่กดรันแล้วใช้งานได้จริงกลับมา เร็วกว่าระยะเวลาที่เมื่อก่อนต้องใช้แค่พิมพ์ฟังก์ชันแรกให้เสร็จเสียอีก ย้อนไปไม่นาน การเปลี่ยนไอเดียในหัวให้เป็นโปรแกรมที่ใช้งานได้ต้องใช้เวลาหลายชั่วโมงถึงหลายสัปดาห์ ต้องทั้งพิมพ์โค้ด เปิดคู่มือ และค่อยๆ แก้ข้อผิดพลาดไปทีละเวอร์ชัน ข้อจำกัดนี้จึงคอยแยกคนที่ทำของออกมาได้จริงออกจากคนที่พูดถึงมันได้อย่างเดียว โดยแทบไม่มีใครสังเกตเห็น
พอข้อจำกัดนี้หายไป คำถามที่ตามมาทันทีคือคนยังเหลือหน้าที่อะไร บทความสองชิ้นที่เขียนแยกกันในปี 2026 ให้คำตอบต่างกัน แต่มาจากข้อสังเกตเดียวกัน NotAShelf เรียกสิ่งที่ยังหายากว่า taste คือความสามารถในการตัดสินว่างานชิ้นไหนควรมีอยู่ ส่วน Rachel Laycock ซึ่งทำงานในตำแหน่ง CTO เรียกสิ่งนั้นว่าความสนใจ ซึ่งคนแต่ละคนมีอยู่อย่างจำกัดเมื่อต้องคุมงานหลายสายพร้อมกัน จากนั้นทั้งสองบทความแยกไปพูดคนละประเด็น แต่ยังเห็นตรงกันว่าการพิมพ์โค้ดไม่ใช่ขั้นตอนที่ทำให้งานช้าที่สุดอีกต่อไป
เมื่อก่อนต้นทุนคัดของห่วยออกไปให้เอง

ของทุกอย่างที่เคยมีล้วนผ่านเงื่อนไขข้อหนึ่งมาแล้วโดยไม่มีใครต้องประกาศ นั่นคือการสร้างของเหล่านั้นมีต้นทุนสูงจนต้องมีคนตัดสินใจก่อนว่าจะทำจริงไหม ต้นทุนจึงคอยคัดกรองมาตลอด ไม่มีใครทำฟีเจอร์เดียวกันออกมาเป็นพันเวอร์ชันแบบกลางๆ เพราะพันเวอร์ชันหมายถึงค่าใช้จ่ายที่เพิ่มขึ้นพันเท่า ของที่มาถึงมือคนใช้จึงผ่านการคัดมาแล้วอย่างน้อยหนึ่งชั้น แม้จะไม่มีใครตั้งใจสร้างขั้นตอนนี้ก็ตาม
บทความเรื่อง taste ยกคำพูดเก่าของ Sturgeon ที่เขียนไว้ในนิตยสารตั้งแต่ปี 1958 มาอธิบายเรื่องนี้ ประโยคนั้นบอกว่าเก้าสิบเปอร์เซ็นต์ของทุกอย่างคือของห่วย และสัดส่วนนี้ไม่ได้เปลี่ยนไปจนถึงวันนี้ สิ่งที่เปลี่ยนคือเมื่อก่อนนิยายห่วยหนึ่งเล่มใช้เวลาหนึ่งปี ซอฟต์แวร์ห่วยหนึ่งตัวใช้เวลาหนึ่งเดือน ต้นทุนจึงช่วยจำกัดปริมาณไว้ตั้งแต่ต้นทาง เมื่อข้อจำกัดด้านต้นทุนหายไป สัดส่วนยังเท่าเดิม แต่จำนวนของที่สร้างออกมาแบบ "พอใช้ได้" แทบไม่มีขีดจำกัด
บทความเตือนไว้ตรงๆ ว่าของที่พอใช้ได้ทำให้เหตุผลที่จะพัฒนาต่อให้ดีกว่านั้นหายไป เมื่อได้ของที่ผ่านเกณฑ์ขั้นต่ำมาฟรีและทันที ก็แทบไม่มีใครถามแล้วว่าถ้าลงแรงต่ออีกหน่อยจะทำให้มันดีขึ้นได้แค่ไหน คำถามที่คนถามกันมาตลอดอย่าง "ทำได้ไหม" จึงไม่สำคัญเท่าเดิม ส่วนคำถามที่ยากกว่ามากอย่าง "อันนี้ควรมีอยู่หรือเปล่า" ยังไม่มีเครื่องมือไหนตอบแทนได้
คำตัดสินว่าอะไรดีพอ คือของหายากอย่างแรก
ลองนึกภาพว่ามีฟังก์ชันแบบเดียวกันวางอยู่ตรงหน้าสามเวอร์ชัน ทั้งสามอันดูเข้าท่าและเปิดแล้วทำงานได้ ถ้าใครมองแล้วรู้ทันทีว่าสองอันในนั้นผิด คนนั้นก็มีสิ่งที่บทความแรกเรียกว่า taste
คำนี้อาจฟังดูเหมือนเรื่องรสนิยมส่วนตัว ผู้เขียนจึงแยกให้ชัดตั้งแต่ต้นว่าไม่ใช่เรื่องเดียวกับการเถียงกันว่าจะวางวงเล็บปีกกาไว้บรรทัดไหน สิ่งที่เขาหมายถึงคือการตัดสินที่เกิดขึ้นก่อนเจ้าตัวจะอธิบายเป็นคำพูดได้ บางครั้งเหตุผลตามมาทีหลัง และบางครั้งเจ้าตัวก็อธิบายเหตุผลไม่ได้เลย เขาเชื่อมโยงเรื่องนี้กับแนวคิด Quality ของ Robert Pirsig ที่ว่าคนเรามองออกว่าอะไรดีก่อน แล้วค่อยอธิบายว่าทำไมถึงดี
จุดที่คนเข้าใจผิดกันได้ง่ายคือคิดว่าคำตัดสินแบบนี้เกิดจากการนั่งรอแล้วปฏิเสธของที่เครื่องส่งมา แต่บทความบอกว่ามันต้องเกิดจากการลงมือทำงานจริง ตัวอย่างที่ยกมาก็จับต้องได้ ทั้งการออกแบบโครงสร้างข้อมูลที่ต้องรองรับการเติบโตได้จริง การรักษาความเป็นส่วนตัวจริงๆ ไม่ใช่แค่เขียนไว้ในหน้าเงื่อนไข และการยอมรื้อฟังก์ชันมาเขียนใหม่เป็นรอบที่สี่ เพราะรอบที่สามแค่พอใช้ได้ คนที่จะตัดสินแบบนั้นได้ต้องเคยทำงานมามากพอจนรู้ว่ารอบที่สามพลาดตรงไหน
บทความยังพูดตรงๆ ถึงสิ่งที่ต้องแลกเพื่อให้ได้คำตัดสินที่ดี นั่นคือเวลา เพราะต้องส่งงานที่ดูเข้าท่ากลับไปทำใหม่ เนื่องจากดูเข้าท่ากับถูกต้องเป็นคนละอย่างกัน ถ้าวัดกันด้วยความเร็วอย่างที่ตลาดนิยมใช้ ทั้งคนที่มีคำตัดสินแบบนี้และคนที่ไม่มีก็ส่งงานได้พอๆ กัน ปัญหาที่มีคนป้องกันไว้ไม่ให้เกิดจึงไม่เคยปรากฏในรายงานประจำเดือน และไม่มีโค้ดบรรทัดไหนบันทึกไว้ว่าตรงนี้เกือบพังแล้ว แต่มีคนเห็นก่อน
ความสนใจของคนคือคอขวดตัวถัดไป

อีกบทความหนึ่งเผยแพร่เมื่อ 31 กรกฎาคม 2026 และเปิดเรื่องด้วยการค้านคำถามตั้งต้น ผู้เขียนบอกว่าการมอง AI เป็นเครื่องมือเพิ่มผลผลิตที่ช่วยให้เขียนโค้ดเร็วขึ้น ได้ฟีเจอร์มากขึ้น และสร้างของได้ถูกลง เป็นการตั้งคำถามผิดตั้งแต่แรก
ผู้เขียนเล่าว่า ขณะที่ AI เขียนโค้ดเก่งขึ้นเรื่อยๆ คอขวดหรือขั้นตอนที่ทำให้งานช้าที่สุดก็ขยับไปตามลำดับของงานพัฒนาซอฟต์แวร์ เริ่มจากการเขียนโค้ด ก่อนจะไปอยู่ที่การออกแบบและเขียนข้อกำหนดของงาน จากนั้นจึงไปอยู่ที่การวางโครงสร้างระบบ และสุดท้ายคือการตรวจว่าของที่ได้มาถูกต้องจริงหรือไม่ แต่ข้อสรุปสุดท้ายคือคอขวดตัวถัดไปอยู่ที่ความสนใจของคน ผู้เขียนสรุปว่า AI ไม่ได้เปลี่ยนว่าซอฟต์แวร์ที่ดีหน้าตาเป็นอย่างไร แต่มันเปลี่ยนว่าอะไรคือของหายาก
เมื่อก่อนคนทำซอฟต์แวร์ให้ความสำคัญกับเวลายาวๆ ที่ได้จดจ่อโดยไม่มีอะไรมาขัด พวกเขาจับคู่กันเขียนโค้ด หรือกันเวลาช่วงบ่ายทั้งหมดไว้ทำงานเงียบๆ เพราะของดีเกิดขึ้นในช่วงเวลานั้น พวกเขาจึงจัดตารางทั้งวันโดยกันเวลานี้ไว้เป็นหลัก แต่คนเก่งที่ผู้เขียนเห็นในตอนนี้ไม่ได้ทำงานแบบนั้นทั้งวันอีกแล้ว พวกเขากำลังคุม agent หรือผู้ช่วย AI หลายตัวพร้อมกัน วิธีทำงานจึงคล้ายการทำงานของวาทยกรมากกว่าของโปรแกรมเมอร์
ภาพวาทยกรนี้มาจากตอนที่ผู้เขียนดูคลิป Jacob Collier คุมวงบนยูทูบ วาทยกรไม่ได้ลงมือเล่นเครื่องดนตรีทุกชิ้นเอง หน้าที่ของเขาคือฟังภาพรวมของเพลง เรียกเสียงแต่ละกลุ่มเข้ามาให้ถูกจังหวะ แล้วควบคุมให้ทั้งวงเล่นออกมาเป็นเพลงเดียวกัน คุณค่าของวาทยกรอยู่ที่การเก็บภาพรวมของทั้งเพลงไว้ในหัว ไม่ใช่การลงมือเล่นเครื่องดนตรีเอง เมื่อเทียบกับงานจริง agent คือนักดนตรีในวง ส่วนคนทำงานคือคนที่ยืนอยู่ข้างหน้า
คนคุมยังมีงานหลักอยู่ไม่กี่อย่าง อย่างแรกคือเลือกว่าจะส่งงานให้ agent ตัวไหนทำ จากนั้นให้ข้อมูลที่มันจำเป็นต้องรู้ ตรวจงานที่ส่งกลับมาเพื่อหาจุดผิดเล็กๆ ที่มองข้ามได้ง่าย แล้วตัดสินว่างานไหนต้องทำอีกรอบ ส่วนงานไหนพอแล้วและเดินหน้าต่อได้ เมื่อทำครบสี่ขั้นตอนก็กลับไปเริ่มใหม่กับงานถัดไป แต่ละรอบจึงต้องจบด้วยการตัดสินใจของคน การเพิ่ม agent อีกหนึ่งตัวจึงเท่ากับเพิ่มงานอีกหนึ่งชุดที่ต้องดูแลพร้อมกัน มีวิศวกรคนหนึ่งบอกผู้เขียนว่าการรัน agent พร้อมกันแปดตัวเป็นเรื่องปกติ ส่วนตัวเลขที่ได้ยินจากคนอื่นมีทั้งสิบและสิบสอง ถ้ามากกว่านั้น คนที่คุมก็กลายเป็นคอขวดเสียเอง
ผู้เขียนเคยเจอรูปแบบนี้มาก่อนแล้วจากงานประจำในตำแหน่ง CTO งานหลายเรื่องเข้ามาพร้อมกันแบบกระจัดกระจาย ทั้งบทสนทนา อีเมล เอกสาร ข้อความแชท และไอเดียที่ยังคิดไม่จบ หน้าที่คือตัดสินใจว่าจะให้ความสนใจกับเรื่องไหน ปะติดปะต่อข้อมูลที่ไม่ครบให้พอมองเห็นภาพ แล้วส่งข้อมูลพื้นฐานที่จำเป็นให้คนอื่นทำงานของตัวเองต่อได้ ตอนแรกผู้เขียนคิดว่าสิ่งที่ขาดคือการบริหารเวลาให้ดีกว่าเดิม แต่สุดท้ายพบว่าสิ่งที่ต้องบริหารจริงๆ คือพลังงาน เพราะสิ่งที่เปลืองแรงคือการสลับไปคิดเรื่องต่างๆ ทั้งวัน ต้องตัดสินใจเรื่องใหม่ๆ อย่างไม่สิ้นสุด และรู้สึกว่าไม่มีงานไหนเสร็จจริงสักอย่าง
ผู้เขียนสังเกตต่อว่าองค์กรใช้เวลาหลายสิบปีฝึกผู้บริหารให้ตัดสินใจทั้งที่ข้อมูลไม่ครบ รับมือกับเรื่องจำนวนมากที่ต้องคิดพร้อมกัน จัดลำดับความสำคัญ และรักษาพลังงานของตัวเองไว้ แต่ยังฝึกคนเขียนโค้ดให้ทำงานในโลกที่แต่ละคนลงมือทำงานของตัวเอง เราออกแบบเครื่องมือกันใหม่หมดแล้ว แต่ยังไม่ได้เริ่มออกแบบลักษณะงานกันใหม่เลย อย่างไรก็ตาม ผู้เขียนย้ำว่าเรื่องนี้ไม่ได้หมายความว่าคนเขียนโค้ดกำลังกลายเป็นผู้จัดการ และไม่ได้หมายความว่า AI เข้ามาแทนงานวิศวกรรม ยังต้องใช้ความเชี่ยวชาญเดิมทั้งหมด เพียงแต่ต้องใช้ในจุดที่ต่างออกไปและใช้บ่อยขึ้น เพราะการลงมือทำเร็วขึ้นมาก ข้อสันนิษฐานที่ทิ้งไว้ตอนท้ายคือคนเขียนโค้ดน่าจะเป็นเพียงกลุ่มแรกที่เจอความเปลี่ยนแปลงนี้ ก่อนที่คนทำงานสายอื่นจะเจอตามมา
ทักษะแบบนี้ฝึกจากการทำของที่ยังไม่ดีด้วยมือตัวเอง
ถ้าคำตัดสินคือของหายาก คำถามถัดไปคือจะฝึกได้อย่างไร บทความเรื่อง taste ตอบตรงๆ ว่าไม่ได้มาจากการดูของดีจำนวนมากเพียงอย่างเดียว การอ่านโปรแกรมชั้นเยี่ยมร้อยชิ้นไม่ได้ทำให้เราตัดสินงานได้ดีขึ้นเอง เช่นเดียวกับที่การไปกินอาหารร้านดีๆ ทุกวันไม่ได้ทำให้กลายเป็นเชฟ วิธีฝึกคือการลงมือทำของที่ยังไม่ดีด้วยตัวเอง อยู่กับผลของมันจนรู้ว่ามีปัญหาตรงไหน แล้วจดจำความรู้สึกนั้นไว้ใช้ในรอบต่อไป ความยากลำบากที่เคยต้องผ่านจึงเป็นส่วนหนึ่งของการฝึก ไม่ใช่อุปสรรคอย่างที่เข้าใจกัน
ตรงนี้คือจุดที่คนเริ่มต้นในปี 2026 เสียเปรียบจริง คนที่เริ่มวันนี้ได้ของที่ใช้งานได้ตั้งแต่วันแรกโดยไม่ต้องผ่านความผิดพลาดด้วยตัวเอง บทเรียนที่เคยมากับความยากจึงหายไปพร้อมกับความยาก บทความจึงสรุปว่าคนเหล่านี้สร้างอะไรก็ได้ แต่ยังบอกไม่ได้ว่าควรสร้างมันไหม
ข่าวดีคือเงื่อนไขที่ช่วยให้คนตัดสินงานได้ดีขึ้นไม่ได้หายไปไหน เพียงแต่มันไม่ได้เกิดขึ้นเองอีกแล้ว ใครอยากตัดสินงานได้แบบนี้ต้องตั้งใจฝึกด้วยตัวเอง
เริ่มฝึกได้ตั้งแต่งานชิ้นหน้า
บทความเรื่องความสนใจมีคำแนะนำที่นำไปใช้ได้ทันทีอยู่สี่ข้อ เป็นหลักที่โค้ชผู้บริหารเคยสอนผู้เขียนไว้ และตอนนี้ผู้เขียนมองว่าคนที่ทำงานกับ agent ต้องใช้หลักเดียวกัน ตารางข้างล่างอธิบายวิธีนำหลักทั้งสี่ข้อนี้มาใช้กับ AI
| สิ่งที่โค้ชสอนไว้ | แปลเป็นวิธีทำงานกับ AI |
|---|---|
| ปกป้องความสนใจของตัวเอง | รู้ว่าเปิดงานพร้อมกันได้กี่อย่างแล้วยังตรวจไหว แล้วหยุดไว้ตรงนั้น |
| จัดการพลังงาน ไม่ใช่แค่เวลา | เอาช่วงที่หัวสดที่สุดของวันไว้ให้งานตรวจ ไม่ใช่ไว้ให้งานสั่ง |
| ลดการตัดสินใจที่ไม่จำเป็น | ตกลงกับตัวเองก่อนเริ่มว่างานชิ้นนี้แค่ไหนเรียกว่าพอ จะได้ไม่ต้องตัดสินใหม่ทุกรอบ |
| สร้างระบบที่ช่วยสมอง ไม่ใช่ช่วยแค่ปฏิทิน | เก็บบริบทของงานไว้ในที่ที่หยิบส่งให้ agent ซ้ำได้ ไม่ต้องรื้อจากความจำใหม่ทุกครั้ง |
ส่วนความสามารถในการตัดสินว่าอะไรดีพอ เราฝึกได้จากสิ่งที่ทำอยู่แล้วทุกวัน แค่เปลี่ยนว่าจะเอาแรงไปลงตรงไหน
- ฝึกตรวจงานที่ AI ทำมาให้ แทนที่จะฝึกสั่งงานให้เร็วขึ้น ความเร็วในการสั่งงานมีขีดจำกัด แต่ความแม่นยำในการตรวจยังพัฒนาได้อีกมาก
- กล้าส่งงานที่เปิดใช้งานได้แล้วแต่ยังไม่ดีพอกลับไปแก้ การยอมรื้อเขียนใหม่ในรอบที่สี่ช่วยให้ตัดสินงานได้ดีขึ้น
- ลงมือทำของสักชิ้นด้วยมือตัวเองทั้งที่รู้ว่ามันจะออกมาไม่ดี แล้วอยู่กับมันจนเห็นว่ามีปัญหาตรงไหน นี่คือบทเรียนที่ AI ทำแทนให้ไม่ได้
- เวลามีของสามแบบวางอยู่ตรงหน้า ฝึกบอกเหตุผลว่าทำไมถึงเลือกอันนี้ แม้จะยังอธิบายได้ไม่ครบก็ตาม การพยายามอธิบายสิ่งที่รู้สึกช่วยให้มองเห็นหลักที่ใช้ตัดสินได้ชัดขึ้น
ประโยคปิดของบทความฝั่ง taste พูดไว้สั้นกว่าทั้งหมดนี้มาก ตอนนี้ใครก็สร้างอะไรก็ได้ แต่แทบไม่มีใครบอกได้ว่าอะไรควรค่าแก่การสร้าง นั่นคือทักษะที่ยากกว่ามาตลอด และตอนนี้มันคือทักษะเดียวที่เหลืออยู่
ข้อดีคือทักษะที่ยากกว่านี้ไม่ได้ขึ้นอยู่กับความเร็วในการพิมพ์ คนที่เพิ่งเริ่มจึงไม่ได้ตามหลังใครอยู่หลายปีอย่างที่กลัวกัน ถ้าอ่านงานชิ้นต่อไปที่ AI ทำมาให้จนจบ แล้วกล้าบอกว่างานนี้ยังไม่ดีพอ ก็เท่ากับเริ่มฝึกไปแล้วหนึ่งรอบ
ที่มา:
- บทความ Taste Is All That's Left จาก NotAShelf
- บทความ The Conductor Developer จาก Rachel Laycock
ชอบเรื่องแนวนี้ มีอีบุ๊คฟรีให้อ่านต่อ
NotebookLM ฉบับเข้าใจง่าย โยนเอกสารให้ AI อ่าน แล้วได้สรุป พอดแคสต์ และคลังความรู้ส่วนตัว
กดสมัครแล้วเราจะส่งเทคนิค AI และของแจกใหม่ๆ ให้ทางอีเมล เลิกรับได้ตลอด
Claude Cowork · The Business Playbook

ฉบับภาษาไทย 15 บท เรียนรู้ผ่านโปรเจกต์จำลองต่อเนื่องทั้งเล่ม ตั้งแต่ตั้งค่า Workspace จัดการไฟล์ เชื่อมแอป ตั้งระบบอัตโนมัติ จนถึงสร้าง Plugin


