ซอร์สโค้ดไม่ใช่สิ่งที่ต้องส่งต่อ

แต่เหตุผลที่ทำให้เกิดซอร์สโค้ดต่างหาก

“ความเร็วในการสร้างต้นแบบ  เพิ่มเร็วกว่าความเร็วในการทำให้ระบบเสถียร คอขวดของการพัฒนาซอฟต์แวร์จึงย้ายตำแหน่ง”

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

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

ที่ผ่านมา สิ่งที่อยู่ในหัวของเขา  ต้องอาศัยโปรแกรมเมอร์ค่อย ๆ แปลงออกมาเป็นซอฟต์แวร์

แต่ครั้งนี้  เขาใช้ AI ช่วยสร้างต้นแบบของหน้าจอที่ต้องการเอง ทีมพัฒนาจึงไม่ต้องเริ่มจากศูนย์อีกต่อไป

หน้าที่ของเรากลายเป็นการคิดว่า  จะนำสิ่งที่ถูกออกแบบไว้  เข้ามาอยู่ใน Core ERP ได้อย่างไร  โดยไม่ทำลายโครงสร้างเดิม

หลังจากนั้น  ทุกอย่างก็เหมือนเขื่อนแตก

ต้นแบบถูกปรับ ถูกทดลอง ถูกนำไปคุยกับลูกค้า แล้วถูกปรับอีกครั้ง

ภายในเวลาไม่นาน  แนวคิดใหม่ชุดเดียวกัน  กลับได้รับการตอบรับจากลูกค้าสิบแห่งพร้อมกัน

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

แล้วผมก็เริ่มตั้งคำถาม

ถ้าวันนี้  การสร้างต้นแบบไม่ใช่คอขวดอีกต่อไป คอขวดใหม่คืออะไร

หลายสิบปีที่ผ่านมา  วงการซอฟต์แวร์เติบโตมาพร้อมสมมติฐานว่า  การเขียนโค้ดมีราคาแพง

เมื่อโค้ดแพง  เราจึงพยายามทำทุกอย่างให้เป็นมาตรฐานเดียว

ซอฟต์แวร์สำเร็จรูป จึงพยายามให้ทุกคนทำงานเหมือนกัน เพราะเขียนง่ายกว่า ทดสอบง่ายกว่า อบรมง่ายกว่า และซัพพอร์ตง่ายกว่า

แนวคิดนี้ไม่เคยผิด มันเหมาะกับยุคที่ต้นทุนของการเปลี่ยนแปลงมีราคาสูง

แต่ถ้าวันนี้  ต้นทุนของการเปลี่ยนแปลงลดลงมาก เราควรถามคำถามเดิมอีกครั้งหรือไม่

กิจการที่ขึ้นระบบกับเราในช่วงสัปดาห์เดียวกัน  ล้วนทำธุรกิจคล้ายกัน

แต่ประสบการณ์สอนเรามาตลอดว่า คำว่า “คล้าย”ไม่เคยแปลว่า “เหมือน”

เมื่อเริ่มลงรายละเอียด  ทุกแห่งจะมีคำว่า  “แต่…” “แต่บริษัทเรา…” “แต่ลูกค้าของเรา…” “แต่สินค้าของเรา…” “แต่ขั้นตอนนี้…”

คำว่า “แต่” เพียงคำเดียว  ก็ทำให้วิธีทำงานแตกต่างออกไป

และคำว่า “แต่” นั่นเอง ที่ทำให้ธุรกิจแตกต่างกัน

ในอดีต  เรามักมองว่าความแตกต่างคือปัญหา เพราะทุกความแตกต่างหมายถึงต้นทุนในการพัฒนา

แต่เมื่อการสร้างสิ่งใหม่เร็วขึ้น ความแตกต่างอาจไม่ใช่สิ่งที่ต้องกำจัดอีกต่อไป อาจกลายเป็นสิ่งที่ควรเปิดพื้นที่ให้มันเกิด

ผมเริ่มรู้สึกว่า  ซอฟต์แวร์ในอนาคต  อาจไม่ใช่การแข่งขันว่า ใครสร้างฟีเจอร์ได้เร็วกว่า แต่เป็นการแข่งขันว่า ใครสามารถรองรับการเปลี่ยนแปลงได้ดีกว่า

ความเสถียรใหม่ อาจไม่ใช่หยุดนิ่ง

แต่คือสามารถเปลี่ยนแปลงไปเรื่อยๆ

อย่างไรก็ตาม  เรื่องที่ทำให้ผมคิดมากที่สุด  ไม่ใช่การสร้างต้นแบบ

แต่เป็นวันหลังจากนั้น..

เมื่อ ERP ไม่ใช่ซอฟต์แวร์ที่อยู่กับลูกค้าไม่กี่เดือน มันอยู่เป็นสิบปี บางแห่งอยู่ยาวกว่านั้น

ถ้าวันนี้ เราสร้างหน้าจอใหม่ได้ภายในไม่กี่ชั่วโมง ปีหน้าอาจมีอีกหลายร้อยหน้าจอ อีกห้าปีอาจกลายเป็นหลายพันจุดที่ถูกสร้างขึ้นด้วย AI

แล้วใครจะเป็นคนดูแลมัน

ผมไม่ได้กังวลว่า AI จะเขียนโค้ดไม่ได้

ผมกังวลว่า  ไม่มีมนุษย์คนไหนจะอ่าน  ทำความเข้าใจ  และเชื่อมโยงโค้ดทั้งหมดได้ทัน

ดังนั้นสิ่งที่ตามมา วันหนึ่ง AI จะต้องแก้โค้ดที่ AI รุ่นก่อนเขียน คำถามจึงไม่ใช่ว่า AI เขียนเก่งแค่ไหน แต่คือ AI จะต้องเข้าใจว่า “ทำไม” โค้ดชิ้นนั้นจึงถูกเขียนขึ้น

ตรงนี้เองที่ผมเริ่มมอง Knowledge Base ต่างไปจากเดิม

ที่ผ่านมา  เรามักมองเอกสารว่าเป็นของแถมของโครงการ มีเวลาก็เขียน ไม่มีเวลาก็ปล่อยผ่าน

แต่บางที  ในยุคที่การสร้างโค้ดแทบไม่มีต้นทุนแล้ว

สิ่งที่มีค่ากว่าโค้ด  อาจเป็นเหตุผลที่ทำให้โค้ดนั้นถือกำเนิดขึ้น

ซอร์สโค้ดอธิบายว่า  “ระบบทำอะไร”

แต่ Knowledge Base อธิบายว่า  “ทำไมระบบจึงเป็นแบบนี้”

ผมเริ่มคิดว่า  การส่งมอบซอฟต์แวร์ในอนาคต  อาจต้องส่งมอบความเข้าใจของระบบไปพร้อมกัน

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

เราอาจกำลังเดินเข้าสู่ยุค ที่โปรแกรมเมอร์ไม่ได้มีหน้าที่สร้างทุกอย่างด้วยตัวเองอีกแล้ว

แต่มีหน้าที่สร้าง  “ระบบที่สามารถถูกสร้างต่อได้”

และถ้าเป็นเช่นนั้นจริง คอขวดของการพัฒนาซอฟต์แวร์  ก็ไม่ได้หายไปไหน

มันเพียงย้ายจาก  “การเขียนโค้ด”

มาเป็น  “การส่งต่อความเข้าใจ”

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