บทความนี้ มีส่วน ๆ หลัก สรุปมาจากงานสัมนา AI Engineering Summit ที่มีทาง Sean Grove จาก OpenAI1 พูดในงานสัมนาถึง การเปลี่ยนผ่านจากโค้ดไปสู่ข้อกำหนด หรือว่า SPEC (Coding Specification) ซึ่งจะทำให้การเขียนโปรแกรม เมื่อมี AI Agent ในการเขียนโค้ดเข้ามาจะเปลี่ยนวิธีการทำงานของเหล่าโปรแกรมเมอร์ ไปอย่างมาก
ตามที่เราได้ติดตามข่าวที่เกี่ยวข้องกับวงการ AI การใช้ AI Agent เข้ามาเขียนโปรแกรมแพร่หลายมากขึ้น จนถูกนิยามคำว่า Vibe Coding ในหมู่ชาวโปรแกรมเมอร์ที่ใช้เครื่องมือ AI มามีส่วนร่วมจนเปลี่ยนรูปแบบ ความรู้สึกการเขียนโค้ดไปจากเดิม บริษัท Tech ระดับโลกยังแสดงให้เห็นถึง Coding หลายส่วน ถูกเขียนด้วย AI เพิ่มขึ้นถึง 25% ตรงนี้ทำให้พวกเราเห็นว่า การใช้ AI เขียนโค้ดเป็นสิ่งที่จำเป็นในบริษัท เราเคยเขียนถึงเรื่องนี้แล้วไปตามอ่านใน เรื่อง Self Coding Agent ได้ครับ
คุณค่าที่แท้จริงของงาน Programing
แนวคิดสำคัญ ที่เป็นแก่นของเรื่องนี้ คือ ความจริงที่ว่า Coding ในการทำงานจริง ๆ เป็นส่วนสุดท้ายที่ออกมาใช้งานกันเป็นเพียง 10-20% ของงานการเขียนโค้ดทั้งหมด 10-20% นี้เป็นผลลัพธ์คุณค่าที่แท้จริงที่คนเขียนโค้ดมอบให้ แต่ที่เหลือในการทำงานทั้งกระบวนการ อีก 80-90% อยู่ใน “การสื่อสารอย่างมีโครงสร้าง” (structured communication) ผมยกตัวอย่างให้ทุกท่านเห็นภาพมากขึ้น สำหรับใน Software House ก่อนเริ่มต้นโครงการ เรารับ Requirement ของระบบที่จะต้องพัฒนา ในขั้นการ Requirement Assessment เป็นส่วนสำคัญที่เกินเวลาอย่างมาก เพื่อพูดคุยกับลูกค้า หรือทีมงานว่าต้องการให้รายละเอียดของ Software หรือระบบนั้นออกมาอย่างไร
การกระบวนการนี้ ก็คือ การสื่อสาร ที่ Sean Grove พูดถึง ยิ่งระบบใหญ่ กระบวนการนี้ยิ่งซับซ้อน เพราะต้องครอบคลุมถึงการทำความเข้าใจความท้าทายของผู้ใช้ User Pain and Gain จะต้องกลั่นกรองเรื่องราว User Story และ การวางแผนเพื่อหาทางแก้ไข การแบ่งปันแผนงานให้กับทีมงาน และแปลงทุกข้อมูลเหล่านั้นออกมาเป็น Coding ทำให้ทั้งงานจนโครงการสำเร็จ “โค้ดเป็นเพียงส่วนเล็กๆ เป็นผลงานของกระบวนที่จับต้องได้ ของทั้งหมด (Code as a smaller part of the whole):”
โค้ดเป็นเพียงส่วนเล็กๆ ของทั้งหมด (Code as a smaller part of the whole): คุณค่าของ โปรแกรมเมอร์ จริง ๆ มีมากกว่าแค่ Coding 10-20%
การสื่อสารทำให้การพัฒนา Code เป็นคอขวด Coding Bottleneck
หลังจากเราตระหนักเรื่อง 10-20% เรื่องนี้สะท้อนให้เห็นว่า ข้อจำกัดจริง ๆ ของการพัฒนา Coding Sean Grove พูดว่า Coding Bottleneck การทำงานของการพัฒนาโปรแกรม Coding คอขวดคือการสื่อสาร Structured communication as the bottleneck
การสื่อสาร ในที่นี้คือ การที่ต้องทำความเข้าใจความท้าทายของผู้ใช้, การวางแผนเพื่อหาทางแก้ไข, และการตรวจสอบผลกระทบของโซลูชันนั้น เป็นงานยากของโปรแกรมเมอร์ เราถึงมีตำแหน่ง BA, SA มาช่วยพวกเขา ซึ่ง BA SA จะช่วยสรุป ความต้องการที่แท้จริง แล้วนำมาคุยกับทีม Programmer ให้รู้ว่าจะสร้างอะไร, สร้างอย่างไร, สร้างไปเพื่ออะไร, และสิ่งที่สร้างขึ้นนั้นถูกต้องหรือไม่
การมาของ Vibe Coding ก็เป็นตัวอย่างหนึ่งที่ชัดเจนของเรื่องนี้ คนที่เขียนโค้ดโดยมี AI มาช่วยมาก ๆ คนนั้นต้องเก่ง ในการสื่อสารเจตนาไปยังโมเดล (AI) ผ่านพรอมต์ (prompts) และให้โมเดลจัดการงานที่ต้องใช้แรงงานหลักๆ แทน ภาพตัวอย่างด้านล่างที่ถูกยกให้เป็นภาพว่า การเริ่มงานพัฒนา เราต้องเริ่มจากการสื่อสารทั้งสิ้นจนจบงาน ซึ่งถอดออกมาแล้วก็เป็น Structured ที่เหมือน ๆ กันในทุกโครงการ
หากคนเขียนโค้ด ไม่มีทักษะในการสื่อสาร เจตนาไปยัง AI แม้งานที่ทำโดยไม่ใช้ AI ถ้าสื่อสารไม่เก่ง ปลายทางของงานก็ไม่ตอบโจทย์และได้ตามความต้องการที่แท้จริง โค้ด 10-20% ก็จะเป็นผลลัพธ์ของ การสื่อสารที่สูญเสียไประหว่างทางของการสื่อสาร หรือก็คือ Code as a lossy projection หมายความว่าโค้ดไม่สามารถถ่ายทอดเจตนาและคุณค่าดั้งเดิมออกมาได้อย่างครบถ้วน จะเข้าใจมากขึ้นด้านล่างครับ นั่นคือสิ่งที่จะกลายเป็นคอขวด ในปัจจุบัน งานไม่จบเพราะเราสื่อสารกันไม่ดี
เมื่อเราจะเข้าสู่ยุค Coding Agent โดย AI Structured communication สิ่งนี้ทำให้การสั่งงาน AI หรือการสื่อสารกับ AI Agent จะต้อง ใส่ใจให้ความสำคัญ เรื่อง intent and values อย่างมาก อาจมากกว่า เรื่อง Code ด้วยซ้ำ เราจะไม่ต้องการให้ AI ลืม Prompt ที่เราเคยสั่งงานไป เพราะเท่ากับว่า เราต้องเริ่มบอกสิ่งนั้นใหม่
“เมื่อ AI ‘ลืม’ บริบทหรือเจตนาที่เราเคยป้อนให้ไปแล้ว (เช่น เมื่อเริ่มแชทใหม่ หรือ context window หมดไป) ความตั้งใจเหล่านั้นมันหายไปอยู่ที่ไหน?” มันคือ การสื่อสารที่สูญเสียไประหว่างทางในการใช้งาน Coding Agent นั่นเอง วึ่งงานก็จะไม่สมบูรณ์เหมือนกันกับที่เราสั่งงานไม่ว่าจะคนหรือ AI ก็จะได้ผลลัพธ์ที่ไม่น่าพอใจ หรือใช้ไม่ได้เลยด้วยซ้ำ
แล้ว เราควรจะทำอย่างไร กับเรื่องนี้ ส่งผลต่อ AI Coding ยังไง
Structured communication จะเริ่มเป็นความสำคัญ และเป็นทักษะหายากรูปแบบใหม่ (The new scarce skill) ของนักพัฒนาต้องเปลี่ยนตัวเองให้เป็น นักถ่ายทอด intent and values มีความสามารถในการเขียนข้อกำหนดที่สามารถถ่ายทอด เจนตนาของการพัฒนา Program และคุณค่าของงานนั้น ๆ (Value) ได้อย่างสมบูรณ์ครบถ้วน ซึ่งสิ่งนี้เองจะกลายเป็นทักษะใหม่ที่หายากในนักพัฒนาซอร์ฟแวร์แทน การแค่เขียนโค้ดเก่ง ๆ
การเขียนข้อกำหนดนี้เสมือนงาน ผู้จัดการผลิตภัณฑ์ (Product managers) และผู้ร่างกฎหมาย (lawmakers) ที่เป็นผู้เขียนข้อกำหนดต่าง ๆ ที่ต้องสื่อสาร สิ่งที่ต้องการอย่างชัดเจน เข้าใจได้
มีการยกตัวอย่างเรื่องนี้ ด้วย เคส การข้อกำหนดสำหรับโมเดล (Model spec example) ในการพัฒนาโมเดลของ Open AI มีการเขียน เอกสาร (living document) ที่ระบุ ขอยกภาษาอังกฤษมาเลยนะครับ “expresses intentions and values, using markdown for accessibility to both technical and non-technical people.” คือ ระบุเจตนาในการพัฒนา คุณค่า โดยใช้ภาษา Markdown เพื่อให้ทั้งคนที่มีความรู้ทางเทคนิคและไม่มีก็สามารถเข้าถึงและทำความเข้าใจได้ สิ่งนี้จะถูกใช้งาน ในการพัฒนา Program ร่วมกับ AI โดยที่จะไม่ทำให้ intent and values ไม่หายไประหว่างทาง
เพราะการสื่อสารที่ไม่ดีทำให้ “Code is a lossy projection”? (โค้ดคือภาพฉายที่สูญเสียข้อมูล) กระบวนการเปลี่ยนจาก “แนวคิด/เจตนา/ข้อกำหนด” ที่ BA/SA ทำนั้น กว่าจะไปเป็น “โค้ด” ออกมาเป็น Software มาให้เราใช้งาน นั้น เป็นกระบวนการแบบ “Lossy” (สูญเสียข้อมูลบางส่วน) เพราะเขาต้องรวบรวมสรุป ย่อ อธิบายออกมาให้ทีมงานได้ทำงานกันต่อ ต่อให้ละเอียดแค่ก็ไหนก็เป็นไปได้มากที่จะสูญหายไปบางส่วน
สิ่งที่ “สูญเสียไป” ในระหว่างการแปลงจากแนวคิดไปเป็นโค้ด คือ:
คุณค่า (Values): ตอนที่เขียนโค้ดนี้ เราให้ความสำคัญกับอะไรมากที่สุด? ความเร็ว? ความปลอดภัย? การอ่านง่าย? หรือการเขียนให้เสร็จเร็ว?
เจตนา (Intentions): “ทำไม” ถึงเขียนโค้ดแบบนี้? มีทางเลือกอื่นอีกไหม? ทำไมถึงไม่เลือกทางอื่น? บริบททางธุรกิจ ณ ตอนนั้นคืออะไร?
นิยามใหม่ของวิศวกรรม (Engineering redefined) เพื่อให้ Bottleneck Shift ลดคอขวดการพัฒนา Software
เราเห็นความสำคัญของการที่โปรแกรมเมอร์ต้องเป็นนักถ่ายทอด ซึ่งเป็น ทักษะหายากรูปแบบใหม่ (The new scarce skill)
Engineering is portrayed as the exploration of software solutions to human problems, shifting from machine encodings to a unified human encoding. แปลเป็นไทย วิศวกรรมคือการสำรวจหา Solutions ที่เป็นไปได้นำมาแก้ไขปัญหาของมนุษย์ โดยเปลี่ยนจากการเข้ารหัสด้วยเครื่องจักร (ภาษาโค้ดดิ้ง) ไปสู่การเข้ารหัสของมนุษย์ (ภาษาธรรมชาติ) มารวมกันเป็นหนึ่งเดียว
ขยายความ : นี่นิยามใหม่ของวิศวกรรม (Engineering redefined): ในงานวิศวกรรมด้าน Software ที่เคยถูกนำเสนอในมุมมองของการพยายาม หาโซลูชัน เพื่อนำไปสู่การพัฒนาโปรแกรมเพื่อแก้ไขปัญหา จะถูกเปลี่ยนเป็นว่า งานวิศวกรรม Software จากที่เน้นการเข้ารหัสสำหรับเครื่องจักร (machine encodings) ไปสู่การเข้ารหัสที่เป็นหนึ่งเดียวและมนุษย์สามารถเข้าใจได้ (unified human encoding) ซึ่งตรงนี้เอง จะทำให้เครื่องมือ IDEs ที่โปรแกรมเมอร์ใช้ในการเขียนโค้ด ก็จะต้องเปลี่ยนให้รับกับเรื่องนี้ด้วยเช่นกัน มุมมองการเขียน Spec สำคัญกว่าการเขียนโค้ด Coding Specification เป็นหัวใจของ Engineer ในโลกใหม่
ยุคของ AI คนที่สามารถสื่อสารได้อย่างมีประสิทธิภาพสูงสุด จะกลายเป็นโปรแกรมเมอร์ที่มีคุณค่ามากที่สุด
บทสรุปของความเปลี่ยนแปลง
“การเริ่มต้นด้วยข้อกำหนด” (start with a Coding specification) เป็นแนวคิดสำคัญที่ถูกนำเสนอว่าเป็น “รหัสใหม่” (the new code) และเป็นวิธีการที่มีประสิทธิภาพเหนือกว่าการมุ่งเน้นที่โค้ดเพียงอย่างเดียวในการ “นำไปปฏิบัติ” (implementation/putting into practice) โดยเฉพาะอย่างยิ่งในยุคของปัญญาประดิษฐ์ขั้นสูง
การเริ่มต้นด้วยข้อกำหนด เปลี่ยนวิธีการลงมือการเขียนโค้ดไปจากเดิมอย่างมาก ที่ทีมพัฒนา Software ต้องปรับตัว ต้องลดความคิดว่าโค้ดยังสำคัญ เพราะ โค้ดไม่ใช่สาระสำคัญที่สุด: Sean ให้มุมมองว่า นักพัฒนา ซอฟต์แวร์ งานส่วนใหญ่ไม่เกี่ยวกับโค้ดเป็นหลัก ในงานภาพรวมโค้ดเป็นเพียง 10-20% ของคุณค่าที่โปรแกรมเมอร์ ส่งมอบให้สู่องค์กร หรือลูกค้า ส่วนอีก 80-90% คือ การสื่อสารที่มีโครงสร้าง (structured communication) เพื่อให้ได้ ข้อกำหนด SPEC ซึ่งคือ สิ่งที่มีความสำคัญมากในกระบวนการ Coding เห็นตัวอย่างการมาของ “vibe coding” เป็นหนึ่งในรูปแบบการเขียนโค้ดโดยเน้นการสื่อสารเจตนา เรามักจะทิ้งพรอมต์ (ซึ่งเป็นเหมือนข้อกำหนดเบื้องต้น) และเก็บโค้ดที่สร้างขึ้น ซึ่งผิดหลักการ เพราะพรอมต์นั้นคือ “แหล่งที่มา” (source spec) หรือ ข้อกำหนดต้นทางที่เป็นวัตถุที่มีค่า การทิ้งพรอมต์เหมือนกับการทิ้งต้นฉบับแล้วเก็บไฟล์ไบนารีไว้ “สเปก” (Coding specifications) ที่ชัดเจน ซึ่งเปรียบเสมือน “ระดับใหม่ของ Prompt Engineering” ที่ควรให้ความสำคัญกับการสื่อสารตั้งแต่ระดับเป้าหมายและข้อกำหนด มากกว่าการเขียนโค้ดเพียงอย่างเดียว
ในมุมผมแล้ว นักเขียนโค้ดที่สามารถจัดระเบียบความคิด มี Critical Thinking และ เป็นนักสื่อสารที่เก่ง จะสามารถปรับตัวเข้าสู่ยุคใหม่ของ Coding Agent ได้ง่ายกว่า และทักษะของการเป็น Prompt Engineering เปลี่ยนสู่ Coding Specification Engineering แทน จะเป็นที่ต้องการอย่างมากในการทำงานด้านเทคโนโลยี
- Sean Grove คือใคร
Sean Grove คนหนึ่งที่โดดเด่นในวงการเทคโนโลยีและ AI โดยเฉพาะด้านการพัฒนาเครื่องมือสำหรับนักพัฒนาและระบบ alignment ของ AI Sean เคยเป็นผู้ร่วมก่อตั้ง OneGraph สตาร์ทอัพด้านเครื่องมือสำหรับนักพัฒนาที่ใช้ GraphQL และได้รับการเข้าซื้อโดย Netlify
ปัจจุบัน Sean ทำงานด้าน alignment reasoning ที่ OpenAI โดยมีบทบาทสำคัญในการแปลง “ความตั้งใจระดับสูง (high‑level intent)” ให้กลายเป็นสเปกและวิธีประเมินที่ใช้ได้จริง เช่น ระบบ “Model Spec” เขาได้พูดเกี่ยวกับความสำคัญของการเขียน “สเปก” (specifications) ที่ชัดเจน ซึ่งเปรียบเสมือน “ระดับใหม่ของ Prompt Engineering” ที่ควรให้ความสำคัญกับการสื่อสารตั้งแต่ระดับเป้าหมายและข้อกำหนด มากกว่าการเขียนโค้ดเพียงอย่างเดียว
↩︎
