สรุปแล้วในยุค AI ต้นทุนของการ 'ตอบตกลง' เปลี่ยนไปอย่างไร?

ส่วนที่แพงที่สุดของคำขอฟีเจอร์เล็กๆ (small feature request) เคยเป็นการเขียนโค้ด แต่ในปัจจุบัน มักจะกลายเป็นการประชุมเพื่อตัดสินใจว่าจะเขียนโค้ดนั้นหรือไม่

นั่นคือการเปลี่ยนแปลงที่เกิดขึ้นจริง และมันทำลายสัญชาตญาณทางวิศวกรรมไปอย่างเงียบๆ วิศวกรเรียนรู้ตั้งแต่เนิ่นๆ ว่า "คำขอเล็กๆ" ส่วนใหญ่นั้นไม่เล็กจริง พวกมันต้องการการทดสอบ, แผนการเปิดตัว (rollout plan), ใครสักคนที่คิดเผื่อกรณีขอบเขต (edge cases) และรับผิดชอบพฤติกรรมของมันหลังจากใช้งานจริง การเปลี่ยนแปลงที่ใช้เวลาสองชั่วโมงสามารถกลายเป็นเรื่องกวนใจที่กินเวลาสองสัปดาห์ได้หากมันไปแตะส่วนที่ผิดพลาดของระบบ ดังนั้นเราจึงมักจะคัดค้าน เรื่องนี้จำเป็นจริงๆ หรือ? มันควรอยู่ในรุ่นนี้ไหม? มันเปลี่ยนสัญญา (contract) ที่เราตกลงกันไว้แล้วหรือเปล่า? ผมจะไม่ยอมทิ้งสัญชาตญาณนั้นไป

แต่มันตั้งอยู่บนสมมติฐานที่กำลังพังทลายลงอย่างเงียบๆ นั่นคือการเขียนโค้ดเวอร์ชันแรกเป็นขั้นตอนที่แพง สำหรับการเปลี่ยนแปลงเฉพาะบางประเภท มันไม่ใช่แบบนั้นอีกต่อไป หากคุณสามารถแยกแยะการเปลี่ยนแปลงเหล่านั้นออกจากส่วนที่เหลือได้ คุณสามารถเปลี่ยนคำถามที่ว่า "สิ่งนี้อยู่ในขอบเขต (scope) หรือไม่?" ให้กลายเป็นคำถามที่คุณสามารถตอบได้ในสามสิบนาที แทนที่จะเป็นการโต้เถียงกันนานสองวัน

การโต้เถียงมักมีราคาแพงกว่าการแก้ไข

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

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

เอเจนท์ (agent) สามารถสร้าง patch แรกนั้นได้ในขณะที่เธรดการสนทนาเพิ่งเริ่มอุ่นเครื่อง มันไม่ใช่ของฟรีและไม่ได้ถูกต้องโดยอัตโนมัติ แต่มันถูกพอที่จะทำให้การตัดสินใจที่ฉลาดคือการหยุดเดา แล้วหันมาดูความแตกต่างของโค้ด (diff) จริงๆ

Patch แรกคือการเช็คราคา ไม่ใช่ผลิตภัณฑ์

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

• มันไปแตะไฟล์ที่คุณคาดไว้ หรือมันกระจายไปทั่วห้าแพ็กเกจ?
• การทดสอบนั้นชัดเจน หรือการเปลี่ยนแปลงนี้ยากที่จะทดสอบ?
• มันรักษาโครงสร้างนามธรรม (abstractions) เดิมไว้หรือไม่?
• มันแอบต้องการการตัดสินใจใหม่ในตัวผลิตภัณฑ์หรือไม่?
• คุณจะรู้สึกสบายใจที่จะรับผิดชอบพฤติกรรมนี้ในอีกหกเดือนข้างหน้าหรือไม่?

คำถามเหล่านี้ดีกว่าการถามว่า "นี่เข้าข่ายขอบเขตงานบานปลาย (scope creep) หรือไม่?" เพราะตอนนี้คุณกำลังตัดสินจากหลักฐานแทนที่จะเป็นความรู้สึก หากฟีลด์ last_active_at กลับมาพร้อมกับ diff เพียงสี่บรรทัดและผ่านการทดสอบ ก็ส่งมอบมันไปเสีย เพราะการโต้เถียงต่างหากคือส่วนที่แพง แต่ถ้าคำขอนั้นกลับไปแตะ auth middleware คุณก็จะได้รู้ทันทีว่ามันไม่ใช่เรื่องเล็ก และที่สำคัญคือคุณรู้เรื่องนี้ได้ใน 30 นาที แทนที่จะใช้เวลาถึง 2 วัน

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

เขียนโค้ดถูก ไม่ได้แปลว่าต้นทุนการเป็นเจ้าของจะถูกตาม

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

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

• การเพิ่มฟิลด์แสดงผลที่มีอยู่แล้วใน backend มักจะราคาถูก
• การเปลี่ยนแปลงพฤติกรรมเรื่องการอนุญาต (authorization) ไม่ถือว่าถูก ไม่ว่า diff จะดูสะอาดแค่ไหนก็ตาม
• การทำ refactoring ตัวช่วย (helper) ที่มีชุดทดสอบรองรับมักจะราคาถูก
• การเปลี่ยนแปลงนโยบายการเก็บรักษาข้อมูล (data-retention) นั้นไม่ถูก

การเปลี่ยนแปลงจำนวนมากยังควรได้รับคำตอบว่า "ไม่" แม้โค้ดจะดูเล็กน้อย โดยเฉพาะสิ่งที่เปลี่ยนข้อตกลงผลิตภัณฑ์ (product contract), สร้างภาระในการแก้ปัญหา หรือเกี่ยวข้องกับความเป็นส่วนตัว การเรียกเก็บเงิน และกฎระเบียบ (compliance) แม้ AI จะช่วยลดต้นทุนในการ ผลิต ตัวเลือก แต่ไม่ได้ช่วยลดต้นทุนในการ เป็นเจ้าของ ตัวเลือกนั้นเลย

ย้ายวินัยการคุมขอบเขตงานมาอยู่บนฐานของหลักฐาน

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

ก่อนจะถกเถียงเรื่องงานเล็กๆ ให้ทดลองทำภายใต้ข้อจำกัดดังนี้:

• สร้าง patch ที่เล็กที่สุด
• เก็บไว้หลัง feature flag
• ห้ามเปลี่ยนสัญญาข้อตกลงสาธารณะ (public contract)
• อัปเดตชุดทดสอบ และระบุไฟล์ที่ได้รับผลกระทบทั้งหมด

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

ทักษะใหม่คือการประเมินราคาความไม่แน่นอน

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

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

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

ต้นทุนของการตอบตกลงเปลี่ยนไปแล้ว ต้นทุนของการปฏิเสธก็ควรเปลี่ยนตามไปด้วย