โปรแกรมเมอร์ในยุค AI: บทบาทที่เปลี่ยนจากการสร้างโค้ดไปสู่การควบคุมความไม่เป็นเชิงกำหนด

สรุปภาพรวม

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

---

บทนำ

อัตลักษณ์ของนักพัฒนาที่ AI เข้ามาสั่นคลอน

• AI สามารถสร้างโค้ดหลายร้อยบรรทัดได้จากคำสั่งภาษาธรรมชาติ ทำให้เกณฑ์การวัดความสามารถของนักพัฒนาแบบเดิมกำลังเปลี่ยนไป

• ในอดีต ความสามารถในการเริ่มจาก editor ว่าง ๆ แล้วเขียนโค้ดได้อย่างรวดเร็วเคยถูกมองว่าเป็นความสามารถแข่งขันหลักของนักพัฒนา

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

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

• บทความนี้อธิบายประเด็นดังกล่าวโดยยึดแนวคิดเรื่อง รายละเอียด, การนามธรรม, ความไม่เป็นเชิงกำหนด, ฮาร์เนส เป็นแกนหลัก

ความหมายของประวัติศาสตร์การเขียนโปรแกรม

• องค์ความรู้ด้านการเขียนโปรแกรมในอดีตไม่ใช่เพียงรายการของทักษะ แต่คือกระบวนการที่นักพัฒนาในแต่ละยุคใช้แก้ปัญหาและสร้างชั้นของนามธรรมขึ้นมาใหม่
• ภาษาเครื่อง, assembly, structured programming, object-oriented programming และ framework ล้วนเป็นผลลัพธ์ที่ถูกสร้างขึ้นเพื่อซ่อนความซับซ้อนของชั้นล่าง
• แม้จะไม่ได้ใช้งานเทคโนโลยีเก่าเหล่านั้นโดยตรง การเข้าใจประวัติศาสตร์ก็ช่วยให้มองเห็นได้ว่าบทบาทของนักพัฒนาเปลี่ยนแปลงซ้ำ ๆ มาอย่างไร

---

เนื้อหา

1. นักพัฒนาคือผู้ทำให้รายละเอียดเป็นรูปธรรม

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

• ตัวอย่างเช่น แม้ฟีเจอร์ง่าย ๆ อย่าง ‘แก้ไขชื่อเล่น’ ก็ยังมีเงื่อนไขย่อยมากมาย เช่น

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

• งานของนักพัฒนาคือกระบวนการเปลี่ยนช่องว่างเหล่านี้ให้เป็นกฎเชิงตรรกะและการจัดการกรณียกเว้นอย่างเป็นรูปธรรม

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

2. การนามธรรมคือกระบวนการซ่อนรายละเอียดที่แก้ไขแล้ว

• เพื่อลดงานที่ทำซ้ำ นักพัฒนาจะห่อปัญหาที่เคยแก้แล้วไว้ในรูปแบบอย่างฟังก์ชัน โมดูล ไลบรารี หรือ framework

• แก่นของการนามธรรมมีดังนี้

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

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

• สภาพแวดล้อมการพัฒนาในปัจจุบันทำงานอยู่บนชั้นนามธรรมที่นักพัฒนารุ่นก่อนสร้างไว้

3. ความลึกที่นักพัฒนาต้องมีแตกต่างกันตามตำแหน่งที่ยืนอยู่

• ไม่ใช่ว่าทุกนามธรรมจะสมบูรณ์แล้ว

• ชั้นที่ซ่อนการพัฒนาภายในได้อย่างเสถียรอาจมองได้ว่าเป็น ‘นามธรรมที่เสร็จสมบูรณ์’

• ส่วนชั้นที่รายละเอียดภายในยังโผล่ออกมาเรื่อย ๆ ในรูปของปัญหาประสิทธิภาพหรือข้อผิดพลาด ถือเป็น ‘นามธรรมที่ยังดำเนินอยู่’

• แม้จะเป็นเทคโนโลยีเดียวกัน สถานะก็อาจต่างกันไปตามบทบาทของนักพัฒนา

  • สำหรับนักพัฒนาเว็บทั่วไป เบราว์เซอร์คือชั้นที่ค่อนข้างเสร็จสมบูรณ์แล้ว
  • สำหรับนักพัฒนา browser engine กระบวนการเรนเดอร์คือรายละเอียดที่ต้องจัดการโดยตรง

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

4. AI ปรากฏขึ้นในฐานะชั้นนามธรรมใหม่

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

5. คำสั่งที่ละเอียดเกินไปอาจจำกัดประสิทธิภาพของ AI

• ผู้เขียนลองพัฒนา side project ด้าน accessibility UI โดยไม่พิมพ์โค้ดเองเลยและใช้ AI เพียงอย่างเดียว

• ในช่วงแรก ผู้เขียนบอกวิธีพัฒนาแบบเฉพาะเจาะจงแก่ AI แต่เกิดปัญหาที่ AI ยึดติดกับวิธีนั้นและคอยเพิ่มการจัดการกรณียกเว้นแบบซ้ำ ๆ

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

• กรณีนี้แสดงให้เห็นว่าวิธีเริ่มต้นที่ผู้ใช้เสนออาจกลายเป็น anchor ที่จำกัดการตัดสินใจของ AI

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

  • ที่มาและเป้าหมายของปัญหา
  • บริบทของระบบปัจจุบัน
  • ผลลัพธ์ที่ต้องทำให้สำเร็จอย่างแน่นอน
  • ข้อจำกัดที่ห้ามเปลี่ยนแปลง

6. ควรมอบหมายเป้าหมายและบริบท มากกว่ามอบหมายคำสั่ง

• ยิ่งประสิทธิภาพของ AI สูงขึ้น วิธีการมอบหมายแบบยึดเป้าหมายอาจมีประสิทธิผลกว่าการระบุขั้นตอนอย่างละเอียดด้วยตนเอง

• ในรูปแบบการมอบหมายนี้ นักพัฒนาไม่ได้กำหนดทั้งหมดว่า ‘จะพัฒนาอย่างไร’ แต่สื่อสารให้ชัดเจนว่า ‘ทำไมจึงต้องมี’ และ ‘ต้องบรรลุอะไร’

• อย่างไรก็ตาม หากให้อิสระเต็มที่ AI อาจไปโฟกัสที่การแก้โค้ดเองมากกว่าความตั้งใจของผู้ใช้

• เพราะฉะนั้นจึงจำเป็นต้องจำกัดขั้นตอนการทำงาน เพื่อให้ AI ดำเนินการดังนี้ก่อน

  • วิเคราะห์เจตนาของคำขอ
  • ถามข้อมูลที่ยังขาด
  • เสนอแผนการแก้ปัญหา
  • ลงมือทำหลังจากผู้ใช้อนุมัติ

• หัวใจสำคัญไม่ใช่การห้ามแบบกว้าง ๆ แต่คือ การระบุให้ชัดเจนว่าผลลัพธ์แบบใดที่อนุญาตในขั้นตอนปัจจุบัน

7. หนึ่งงานควรกำหนดเพียงหนึ่งผลลัพธ์

• LLM มีข้อจำกัดทั้งด้านปริมาณผลลัพธ์และขอบเขตการคิดที่สามารถจัดการได้ในการตอบหนึ่งครั้ง

• หากสั่งให้เขียนการทดสอบและการพัฒนาพร้อมกัน ทรัพยากรอาจไปกระจุกที่เป้าหมายสุดท้ายคือการทำโค้ดให้เสร็จ ทำให้คุณภาพของการทดสอบลดลง

• ผู้เขียนจึงแยกงาน TDD ออกดังนี้

  • /red: เขียนเฉพาะการทดสอบที่ล้มเหลว
  • /green: เขียนการพัฒนาขั้นต่ำที่ทำให้การทดสอบผ่าน
  • /refactor: ปรับปรุงโครงสร้างโค้ดโดยคงการทดสอบไว้

• เมื่อจำกัดให้แต่ละขั้นมีเพียงผลลัพธ์เดียว ก็จะลดปัญหาที่ AI ข้ามขั้นตอนกลางหรือทำแบบขอไปทีได้

• นี่หมายความว่าแก่นของการออกแบบพรอมป์ต์ไม่ใช่การอธิบายพฤติกรรมอย่างยืดยาว แต่คือ การนิยามผลลัพธ์ที่ต้องสร้างในงานหนึ่งครั้ง

8. เอกสาร Markdown และสกิลกำลังกลายเป็นโค้ดรูปแบบใหม่

• หากแยกงานอย่างการเขียนข้อกำหนด การทดสอบ การพัฒนา การตรวจสอบ และการ commit ออกเป็นสกิลแต่ละตัว ก็สามารถสร้าง pipeline แบบนี้ได้

  • เขียนข้อกำหนด
  • สร้างการทดสอบที่ล้มเหลว
  • พัฒนาฟังก์ชัน
  • รีแฟกเตอร์
  • ตรวจสอบ
  • commit

• แต่ละสกิลมีทั้งอินพุต เอาต์พุต และข้อจำกัด จึงทำงานคล้ายฟังก์ชัน

• เอกสาร Markdown ที่บันทึกสกิลและกฎต่าง ๆ จึงไม่ได้เป็นเพียงคู่มือธรรมดา แต่ทำหน้าที่เป็นกฎปฏิบัติการที่กำหนดพฤติกรรมของ AI

• ในกระบวนการนี้ยังสามารถนำหลักการออกแบบซอฟต์แวร์แบบเดิมมาใช้ได้ด้วย

  • หลัก single responsibility ที่ให้หนึ่งสกิลมีเพียงหนึ่งความรับผิดชอบ
  • การทำ modularization โดยแยกความรู้และกฎออกเป็นไฟล์ต่างหาก
  • หลัก open-closed ที่ขยายด้วยไฟล์ความรู้ภายนอกโดยไม่แก้ไขสกิลหลัก

• แม้แพลตฟอร์มจะเปลี่ยนจาก IDE มาเป็นเอกสาร Markdown แต่การแยกย่อยงานและเชื่อมต่อมันเข้าด้วยกันก็ยังคงเป็นการเขียนโปรแกรมอยู่ดี

9. ความเสี่ยงหลักของการเขียนโค้ดด้วย AI คือความไม่เป็นเชิงกำหนด

• โปรแกรมแบบดั้งเดิมมักให้ผลลัพธ์เดิมกับอินพุตเดิมเป็นส่วนใหญ่

• แต่ AI สามารถสร้างทั้งโค้ดและการตัดสินใจที่ต่างกันได้ แม้จะเป็นคำขอเดียวกัน

• หาก AI ทำการรีแฟกเตอร์ขนาดใหญ่ แม้ฟังก์ชันจะยังทำงานได้ ก็ยังมีปัญหาต่อไปนี้คงอยู่

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

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

• ในสภาพแวดล้อม production สิ่งสำคัญยิ่งกว่าความสามารถในการสร้าง คือ ความสามารถในการควบคุมขอบเขตของการเปลี่ยนแปลงและตรวจสอบผลลัพธ์

10. AI เก่งกับปัญหาที่เพดานไม่สูง

• ปัญหาที่ AI จัดการได้อย่างง่ายดาย มักเป็น ‘ปัญหาที่นิยามไว้ชัดเจน’ ซึ่งทั้งความต้องการและวิธีแก้เป็นที่รู้จักดีแล้ว

• ปัญหาแบบนี้สามารถแก้ได้ด้วยการประกอบองค์ประกอบนามธรรมที่เสร็จสมบูรณ์แล้ว เช่น ไลบรารี framework และแพตเทิร์น

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

• ในทางกลับกัน ปัญหาที่ยากระดับสูงต่อไปนี้ยังต้องอาศัยการตัดสินใจเพิ่มเติมจากมนุษย์

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

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

11. รายละเอียดที่นักพัฒนาต้องรับผิดชอบกำลังย้ายไปสู่การควบคุม AI

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

• แต่ในยุค AI เราต้องใช้ AI ที่ไม่เป็นเชิงกำหนดเพื่อสร้างผลิตภัณฑ์ที่เป็นเชิงกำหนด

• รายละเอียดที่นักพัฒนาต้องจัดการกำลังย้ายไปอยู่ในพื้นที่ต่อไปนี้

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

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

12. ผลลัพธ์ของ AI ต้องถูกตรวจสอบด้วยเครื่องมือเชิงกำหนด

• การให้ AI อีกตัวตรวจสอบผลลัพธ์ที่ AI สร้างขึ้นเพียงอย่างเดียว อาจยังไม่เพียงพอสำหรับความน่าเชื่อถือที่ต้องการ

• หากจะตัดสินว่าผลลัพธ์ของระบบถูกต้องหรือไม่ จำเป็นต้องมีเกณฑ์คำตอบที่ชัดเจน หรือก็คือ oracle

• หาก AI ที่ไม่เป็นเชิงกำหนดสร้างแม้แต่เกณฑ์การตรวจสอบขึ้นมาแบบตามใจ ก็อาจเกิดการแก้ผลลัพธ์ที่ถูกต้องให้ผิด หรือบิดเบือนเกณฑ์การตรวจสอบได้

• ดังนั้นเกณฑ์การตรวจสอบจึงควรถูกสร้างจากเครื่องมือที่เป็นเชิงกำหนดให้มากที่สุด

  • คอมไพเลอร์และตัวตรวจสอบชนิดข้อมูล
  • การทดสอบอัตโนมัติ
  • ลินเตอร์และ static analysis
  • การตรวจสอบ schema
  • เกณฑ์ด้านประสิทธิภาพ·ความปลอดภัย
  • ขั้นตอนอนุมัติและการจำกัดขอบเขตการเปลี่ยนแปลง

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

13. ฮาร์เนสจะกลายเป็นโครงสร้างพื้นฐานหลักของการพัฒนาด้วย AI

• ฮาร์เนสคืออุปกรณ์ตรวจสอบที่วางไว้ทีละขั้น เพื่อไม่ให้ AI สะสมข้อผิดพลาดระหว่างทำงานหรือออกนอกขอบเขต

• องค์ประกอบหลักมีดังนี้

  • pipeline ที่แยกขั้นตอนการทำงาน
  • รูปแบบอินพุตและเอาต์พุตในแต่ละขั้น
  • การทดสอบอัตโนมัติและ static analysis
  • verification gate ที่หยุดการทำงานเมื่อเกิดความล้มเหลว
  • การจำกัดไฟล์และขอบเขตที่แก้ไขได้
  • ขั้นตอนการอนุมัติและการรีวิวโดยมนุษย์

• ฮาร์เนสช่วยป้องกันไม่ให้ข้อผิดพลาดเล็ก ๆ ในขั้นหนึ่งถูกขยายใหญ่ในขั้นถัดไป

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

---

บทสรุป

นักพัฒนาไม่ได้หายไป แต่บทบาทกำลังเคลื่อนย้าย

• AI กำลังทำให้การเขียนโค้ดอย่างง่ายและการพัฒนาที่ทำซ้ำเป็นอัตโนมัติอย่างรวดเร็ว

• แต่หากจะสร้างผลลัพธ์ระดับผลิตภัณฑ์ ก็ยังคงต้องมีบทบาทต่อไปนี้

  • การกำหนดปัญหาและเป้าหมาย
  • การออกแบบโครงสร้างระบบ
  • การแยกขั้นตอนงานและผลลัพธ์
  • การประสานลำดับการทำงานระหว่าง AI agent
  • การสร้างเกณฑ์ตรวจสอบและฮาร์เนส
  • ความรับผิดชอบขั้นสุดท้ายต่อผลลัพธ์การปฏิบัติการ

• งานของนักพัฒนามีแนวโน้มจะลดสัดส่วนการพิมพ์โค้ดโดยตรงลง และเปลี่ยนไปในทิศทางของการจัดระเบียบและควบคุมโค้ดที่ AI สร้างให้กลายเป็นระบบ

การเขียนพรอมป์ต์คือการเขียนโปรแกรมรูปแบบใหม่

• กระบวนการทำคำสั่งที่ใช้ซ้ำให้กลายเป็นสกิลและกฎ แล้วเชื่อมต่อเป็น pipeline มีความคล้ายกับการออกแบบฟังก์ชันและโมดูล
• เอกสาร Markdown สามารถทำหน้าที่เป็นชั้นโค้ดแบบใหม่ที่นิยามบริบท พฤติกรรม และรูปแบบผลลัพธ์ของ AI
• นักพัฒนาต้องทำให้นามธรรมของประสบการณ์และเกณฑ์การตัดสินใจโดยนัยของตนอยู่ในรูปเอกสารที่ AI นำกลับมาใช้ซ้ำได้
• นี่ไม่ใช่แค่การนามธรรมระบบเดิม แต่คือ การนามธรรมวิธีทำงานและกระบวนการตัดสินใจของตัวนักพัฒนาเองด้วย

สมรรถนะหลักของนักพัฒนาในอนาคต

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

การประเมินโดยรวม

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