..แต่มันกำลังเปลี่ยนวิธีที่เราพัฒนาซอฟต์แวร์

AI ไม่ได้เปลี่ยนวิธีเขียนโค้ด 

ในการสนทนากับทีมครั้งล่าสุด

มีคำถามหนึ่งที่ทำให้ผมต้องคิดต่ออยู่นาน

“เวลาที่คุณเห็นจุดเล็ก ๆ ที่ต้องปรับแก้ในโค้ด  โดยคุณก็รู้ว่าต้องทำอย่างไร  คุณจะลงมือทำเอง หรือบอกให้ AI ทำ?”

ดูเหมือนจะตอบได้ง่าย

แต่กลับเป็นคำถามที่ตอบยากมาก

เพราะคำตอบไม่ได้ขึ้นอยู่กับ AI

แต่มันขึ้นอยู่กับว่า

เรากำลังพยายามสร้างอะไร

---

ผมเคยคิดว่าคำถามสำคัญคือ

“AI เขียนโค้ดแทนเราได้แค่ไหน”

แต่ช่วงหลังผมเริ่มรู้สึกว่า คำถามนี้เล็กเกินไป

คำถามที่ใหญ่กว่าคือ

ถ้า AI กลายเป็นส่วนหนึ่งของทีมพัฒนา  เราควรออกแบบกระบวนการพัฒนาซอฟต์แวร์ใหม่หรือไม่

ผมยังไม่มีคำตอบ

แต่เริ่มเห็นร่องรอยของมัน

เมื่อก่อน เราลงทุนกับการ “คิดให้ครบ”

ผมโตมากับยุคที่ต้นทุนของการเปลี่ยนแปลงสูง

การ Deploy ยุ่งยาก

การแก้ไข Bug หลังลูกค้าใช้งานจริงมีราคาแพง

Regression Test ใช้เวลานาน

การอัปเดตเวอร์ชันแต่ละครั้งกระทบผู้ใช้จำนวนมาก

ผลก็คือ เราถูกฝึกให้ทำงานแบบเดียวกัน

คิดให้ครบ

ตรวจให้ครบ

QC ให้แน่นที่สุด

แล้วค่อยปล่อย

คุณภาพของทีม วัดจากจำนวนข้อผิดพลาดที่หลุดออกไป

---

ช่วงหลัง ผมพยายามฝืนความเคยชินของตัวเองอยู่เรื่องหนึ่ง

คือ ยอมปล่อยงานออกไปก่อน

ไม่ใช่เพราะมาตรฐานลดลง

แต่เพราะต้นทุนของการแก้ไขเปลี่ยนไป

AI ทำให้การสร้าง Patch เร็วขึ้น

การเขียนใหม่เร็วขึ้น

การทดลองแนวทางใหม่แทบไม่มีต้นทุน

สิ่งที่ผมเริ่มถามตัวเองจึงไม่ใช่

“ทำอย่างไรจึงจะไม่ผิด”

แต่เป็น

ถ้าผิด เราจะเรียนรู้และส่งมอบสิ่งที่ดีกว่าได้เร็วแค่ไหน

นี่เป็นคำถามคนละชุดกับที่ผมเคยใช้มาตลอด

คอขวดอาจไม่ได้อยู่ที่การเขียนโค้ดอีกแล้ว

เมื่อ AI ทำให้การสร้าง Prototype หรือแม้แต่โค้ดใช้งานได้เกิดขึ้นภายในไม่กี่นาที

ผมเริ่มรู้สึกว่า คอขวดของการพัฒนาซอฟต์แวร์กำลังย้ายตำแหน่ง

ไม่ใช่ Coding

แต่คือ Feedback

เราไม่ได้ขาดความสามารถในการสร้างทางเลือก

เราขาดความสามารถในการรู้ว่า

ทางเลือกไหนดีกว่า

ในโลกของ AI ปัญหาไม่ใช่การ Generate

แต่คือการ Select

สิ่งที่ทำให้ผมคิดถึง Reinforcement Learning

ผมไม่ได้จะบอกว่าการพัฒนาซอฟต์แวร์คือ Reinforcement Learning

แต่ผมรู้สึกว่ามันมีโครงสร้างบางอย่างคล้ายกัน

Agent จะเรียนรู้ได้ดีหรือไม่

ไม่ได้ขึ้นอยู่กับความสามารถในการลอง

แต่ขึ้นอยู่กับคุณภาพของ Reward

ถ้า Reward ผิด

Agent ก็เรียนรู้ผิด

ในซอฟต์แวร์ก็ไม่ต่างกัน

ถ้า Feedback จากผู้ใช้ไม่มีคุณภาพ

ทีมพัฒนาก็เรียนรู้อะไรไม่ได้

ต่อให้ AI สร้างโค้ดได้เร็วขึ้นสิบเท่า

ก็ไม่ได้ทำให้ซอฟต์แวร์ดีขึ้น

เพราะคอขวดไม่ได้อยู่ตรงนั้น

มันอยู่ที่วงจรการเรียนรู้

แล้วเราจะสร้าง Feedback ที่ดีได้อย่างไร

คำถามนี้ผมยังตอบไม่ได้

แต่เริ่มคิดว่าบางที

เราอาจไม่ควรสร้างคำตอบเพียงแบบเดียว

แต่สร้างหลาย Variants

แล้วปล่อยให้การใช้งานจริงเป็นผู้คัดเลือก

แนวคิดนี้ฟังดูคล้าย A/B Testing

แต่ ERP ไม่ใช่ Consumer App

เราไม่สามารถสุ่มหน้าจอใหม่ให้ฝ่ายบัญชีของลูกค้าลองเล่นได้

ความผิดพลาดมีต้นทุนจริง

ดังนั้น วิธีคิดแบบ Consumer Software อาจใช้ตรง ๆ ไม่ได้

ผู้วางระบบอาจมีบทบาทใหม่

สิ่งหนึ่งที่ผมคิดวนอยู่พักใหญ่

คือบทบาทของผู้วางระบบ (Implementer)

ในอดีต เขาเป็นคน Configure ระบบ

เลือก Option

ปรับแต่ง Workflow

ให้เหมาะกับธุรกิจ

แต่ถ้า AI สามารถสร้าง Workflow ได้เป็นจำนวนมาก

บทบาทของผู้วางระบบอาจเปลี่ยน

จากคนที่ “สร้าง”

มาเป็นคนที่ “คัดเลือก”

ลูกค้าไม่จำเป็นต้องเห็นตัวเลือกทั้งหมด

เหมือนที่ผู้ใช้โทรศัพท์

ไม่จำเป็นต้องเข้าใจทุก Library ที่อยู่เบื้องหลังแอปพลิเคชัน

สิ่งที่ลูกค้าต้องการ

คือระบบที่เหมาะกับธุรกิจของตัวเอง

ผู้วางระบบจึงทำหน้าที่ประกอบองค์ประกอบที่เหมาะสมที่สุด

จนผู้ใช้รู้สึกว่า

นี่คือซอฟต์แวร์ที่สร้างขึ้นสำหรับบริษัทของเขา

ทั้งที่จริงแล้ว

มันอาจเกิดจากการคัดเลือกและประกอบ Pattern 

ที่ผ่านการใช้งานจริงมาแล้วหลายร้อยครั้ง

บางที สิ่งที่มีค่าที่สุดอาจไม่ใช่คลังโค้ด

AI ทำให้การสร้าง Pattern ใหม่แทบไม่มีต้นทุน

สิ่งที่หายากจึงไม่ใช่ Pattern

แต่คือความรู้ว่า

Pattern ไหนควรอยู่รอด

ผมเริ่มคิดว่า

ในอนาคต

คลังที่มีค่าที่สุดอาจไม่ใช่ Source Code

แต่เป็นประวัติของการคัดเลือก

Pattern นี้เหมาะกับธุรกิจแบบไหน

เคยถูกใช้กับใคร

ทำไมจึงถูกเลือก

ทำไมจึงถูกเลิกใช้

Pattern ถัดไปจึงไม่ได้ดีขึ้น

เพราะ AI ฉลาดขึ้นเพียงอย่างเดียว

แต่มันดีขึ้นเพราะทั้งระบบเรียนรู้ร่วมกัน

นี่เป็นเพียงบันทึก

ผมยังไม่มีข้อสรุป

อาจคิดผิดเกือบทั้งหมดก็ได้

แต่ผมอยากบันทึกความคิดนี้ไว้

เพราะผมเริ่มรู้สึกว่า

AI ไม่ได้เปลี่ยนวิธีเขียนโค้ดของผมมากนัก

สิ่งที่มันกำลังเปลี่ยน

คือวิธีที่ผมมอง “การพัฒนาซอฟต์แวร์”

บางที ความสามารถของทีมในอนาคต 

อาจไม่ได้วัดจากการส่งมอบซอฟต์แวร์ที่สมบูรณ์ที่สุด

แต่วัดจากการออกแบบระบบที่เรียนรู้จากการใช้งานจริงได้ดีที่สุด

และถ้าเป็นเช่นนั้น

งานของวิศวกรซอฟต์แวร์

อาจไม่ได้จบลงเมื่อ Deploy เสร็จ

แต่มันเพิ่งเริ่มต้น..