Software Needs Memory

บันทึกการสนทนากับ AI ที่ทำให้ผมเริ่มตั้งคำถามใหม่

ช่วงนี้ผมคุยกับ ChatGPT เยอะกว่าปกติ ไม่ใช่เพื่อให้มันเขียนโค้ด

แต่เพื่อช่วยเรียบเรียงสิ่งที่กำลังเกิดขึ้นในทีม

หลายครั้งผมเริ่มต้นด้วยเรื่องเล็ก ๆ

เล่าว่า…

หัวหน้าทีมวางระบบของเรา เริ่มใช้ AI ออกแบบหน้าจอที่ต้องการเอง

เขาไม่ได้เป็นโปรแกรมเมอร์

หน้าที่ของเขาคือเข้าใจธุรกิจของลูกค้า แล้วออกแบบว่าระบบควรทำงานอย่างไร

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

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

ทีมพัฒนาจึงไม่ต้องเดาอีกต่อไป หน้าที่ของเราคือคิดว่าจะทำให้สิ่งนั้นเข้าไปอยู่ใน Core ERP ได้อย่างไร

หลังจากเล่าเหตุการณ์นี้ให้ AI ฟัง ผมคิดว่าคำตอบที่น่าจะได้ คงเป็นเรื่อง Productivity หรือไม่ก็การใช้ AI ให้เก่งขึ้น

แต่สิ่งที่มันตอบกลับมา กลับไม่ใช่แบบนั้น มันถามผมว่า

“คุณกำลังพูดถึงการเขียนโค้ด หรือกำลังพูดถึงการส่งต่อความเข้าใจ”

ผมหยุดคิดอยู่พักหนึ่ง

แล้วเริ่มรู้สึกว่า…

ใช่

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

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

เมื่อก่อนโปรแกรมเมอร์คือคนสร้าง

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

บทสนทนาดำเนินต่อ

ผมเล่าว่า ทุกวันนี้ ไอเดียของทีมวางระบบอยู่ใน Obsidian ต้นแบบอยู่ในไฟล์ HTML

ส่วนทีมพัฒนา เมื่อปรับให้เข้ากับ Core ERP แล้ว ก็เขียน Comment อธิบายแนวคิดและตรรกะสำคัญไว้ในโค้ด

แต่ทุกอย่างยังกระจัดกระจาย

ผมบอกกับ AI ว่า “ผมยังรู้สึกว่ามันไม่ค่อยลงตัว”

ผมนึกว่ามันจะช่วยคิดเรื่องโครงสร้างโฟลเดอร์ หรือแนะนำเครื่องมือใหม่

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

“อย่าเพิ่งรีบแก้”

แล้วอธิบายว่า Git ก็เคยกระจัดกระจาย Source Code ก็เคยกระจัดกระจาย Issue ก็เคยกระจัดกระจาย

ก่อนที่วงการจะค่อย ๆ สร้างเครื่องมือขึ้นมารองรับ

ประโยคนั้นทำให้ผมเริ่มมองสิ่งที่เกิดขึ้นต่างไป

บางที สิ่งที่เรากำลังสร้าง ยังไม่มีชื่อเรียกที่ชัดเจนด้วยซ้ำ ผมเคยเรียกมันว่า Knowledge Base แต่ AI เสนอคำที่ผมชอบกว่า

มันเรียกว่า Design Memory

ไม่ใช่เอกสารแต่คือ “ความทรงจำของระบบ”

ความทรงจำว่า ทำไมจึงเลือกแนวทางนี้ ทำไมไม่เลือกอีกแบบ

ลูกค้าเคยเจอปัญหาอะไร และทำไมโค้ดส่วนนี้จึงมีหน้าตาแบบนี้

โค้ดอธิบายว่าระบบทำอะไร

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

ประโยคนี้ทำให้ผมนึกถึง ERP ของตัวเอง

หลายปีที่ผ่านมา  ผมเขียนบทความเรื่อง Pseudo Account เรื่อง Document Flow เรื่องการเลิก Post GL เรื่อง Hybrid ERP เรื่อง Accounting Workspace

ผมแทบไม่เคยอธิบายว่าโค้ดเขียนอย่างไร ผมเขียนแต่เหตุผลว่าทำไมเราจึงออกแบบแบบนั้น

ผมเพิ่งมารู้ตัวจากบทสนทนาครั้งนี้ว่า บางที บทความเหล่านั้นอาจไม่ใช่บทความ แต่มันคือ Design Memory ของระบบ

ถ้าวันหนึ่ง AI ต้องเข้ามาดูแล Core ERP แทนคนรุ่นผม สิ่งที่มันต้องอ่าน อาจไม่ใช่ Source Code อย่างเดียว แต่มันต้องอ่านเหตุผลของการออกแบบด้วย

แล้วผมก็เริ่มคิดต่อเอง

ที่ผ่านมา เราเชื่อว่าซอฟต์แวร์ประกอบด้วยสองสิ่ง

Source Code และ ฐานข้อมูล

แต่ในวันที่ AI เริ่มมีบทบาทในการพัฒนา ผมเริ่มสงสัยว่า ซอฟต์แวร์อาจกำลังต้องการองค์ประกอบที่สาม

ไม่ใช่ข้อมูล ไม่ใช่โค้ด แต่คือ “ความทรงจำ”

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

ผมยังไม่รู้ว่าคำตอบสุดท้ายคืออะไร

ผมยังไม่รู้ด้วยซ้ำว่าอีกห้าปีข้างหน้า  เราจะยังใช้ Markdown หรือ Obsidian อยู่หรือไม่ เครื่องมือคงเปลี่ยนไปอีกหลายครั้ง

แต่ผมเริ่มเชื่อว่า มีบางอย่างที่สำคัญกว่าเครื่องมือ

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

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

บทสนทนาที่ไม่ได้ให้คำตอบ แต่ช่วยทำให้ผมมองเห็นคำถามที่ชัดขึ้นกว่าเดิม