หลังจากคร่ำหวอดในวงการพัฒนาซอฟต์แวร์มาเกือบ 30 ปี ช่วง 3 ปีที่ผ่านมานี้ถือเป็นช่วงที่ท้าทายความเชื่อเดิมๆ ของผมเกี่ยวกับความเป็นไปได้ในการส่งมอบงานซอฟต์แวร์อย่างสิ้นเชิง จากข้อมูลเชิงลึกที่ผมและทีมงานได้เรียนรู้ เราจึงตัดสินใจปรับโครงสร้างกระบวนการพัฒนาใหม่ทั้งหมด โดยยึดหลักการทำงานร่วมกันระหว่างผู้เชี่ยวชาญที่เป็นมนุษย์ และผู้ช่วย AI
และนี่คือข้อมูลเชิงปฏิบัติที่ผมได้รับจากการทำงานจริงในฐานะ Principal Mobile Architect ที่ Seven Peaks ผ่านการใช้งาน AI ผมจะมาแชร์ให้ฟังว่า จุดไหนที่ AI สร้างมูลค่าได้มากที่สุด จุดไหนที่มันยังไปไม่รอด เราวางโครงสร้างการทำงานรอบตัวมันอย่างไร และทำไมความเชี่ยวชาญทางวิศวกรรมระดับ Senior ถึงกลายเป็นเรื่องสำคัญยิ่งกว่ายุคไหนๆ ในการทำให้การพัฒนาแบบ AI-Native นี้สำเร็จได้จริง
ในโปรเจกต์สตาร์ทอัพด้านเทคโนโลยีดนตรีล่าสุด เราสามารถส่งมอบแอปพลิเคชันระดับ MVP (Minimum Viable Product) ได้เร็วกว่าเดิมถึง 2 เท่าเมื่อเทียบกับการทำงานแบบไม่มี AI โปรเจกต์ที่เมื่อก่อนเราคงต้องบอกลูกค้าว่า "ขอโทษ เวลานี้เป็นไปไม่ได้จริงๆ" กลับกลายเป็นงานที่เราสามารถรับทำได้จริง ลูกค้าได้รับซอฟต์แวร์ที่พร้อมใช้งานจริง ในกรอบเวลาที่วิธีการพัฒนาแบบดั้งเดิมทำไม่ได้ โดยที่เราไม่ต้องเพิ่มคนหรือลดมาตรฐานคุณภาพลงเลย
แต่มูลค่าที่ได้ไม่ใช่แค่เรื่องความเร็ว เรายังสามารถรักษาความเข้มงวดทางวิศวกรรมได้ตลอดวงจรการพัฒนาซอฟต์แวร์ ทั้งสถาปัตยกรรมที่ถูกต้อง โค้ดที่สะอาด และการทดสอบที่ครอบคลุม ผมได้เรียนรู้ว่า AI ไม่ใช่เครื่องมือสำหรับทางลัด แต่มันคือเครื่องมือที่หากใช้เป็น มันจะเป็นตัวช่วยทวีคูณพลังให้กับนักพัฒนา
การเปลี่ยนตัวเองมาเป็นนักพัฒนาแบบ AI-native เปลี่ยนวิธีการทำงานของผมไปหลายอย่าง บทบาทของผมเปลี่ยนจากการใช้เวลาส่วนใหญ่ไปกับการนั่งเขียนโค้ด กลายเป็นการโฟกัสที่การวางแผนอย่างครอบคลุมก่อนเริ่มพัฒนา และการรีวิวอย่างเข้มข้นหลังจาก AI เขียนโค้ดเสร็จ โดยการทำงานที่เป็นระบบนี้จะถูกกำกับดูแลด้วยกรอบการทำงานที่นักพัฒนาเป็นคนกำหนดไว้อย่างรอบคอบ
เวลาเราทำงานกับ AI ที่ Seven Peaks เรามีกระบวนการพัฒนาซอฟต์แวร์ที่เป็นระบบ เรายังคงขับเคลื่อนด้วยสเปกงาน (Specification-driven) เหมือนเดิม แต่ AI เข้ามาเปลี่ยนวิธีการที่เราเปลี่ยนความต้องการทางธุรกิจให้กลายเป็นโค้ดที่ใช้งานได้"
เราเริ่มต้นด้วยเอกสารความต้องการของผลิตภัณฑ์ (PRD) จากทีมออกแบบของเรา เอกสารเหล่านี้จะมี User Stories, เกณฑ์การยอมรับ และความต้องการเชิงฟังก์ชัน ซึ่งเป็นตัวแทนของความต้องการทางธุรกิจและผู้ใช้ แต่ยังไม่ใช่สเปกทางเทคนิค
จากนั้นเราใช้ AI เพื่อดึง User Stories ออกมาจาก PRD วิเคราะห์เกณฑ์การยอมรับ และแปลงความต้องการกว้างๆ เหล่านี้ให้กลายเป็นสเปกงานทางเทคนิคที่ละเอียด สิ่งที่เคยเป็นกระบวนการแปลภาษาธุรกิจเป็นรายละเอียดทางเทคนิคด้วยมือ (ซึ่งกินเวลาหลายชั่วโมง) แต่ตอนนี้กลับเกิดขึ้นได้ในเวลาไม่กี่นาทีเท่านั้น
งานเทคนิคแต่ละชิ้นจะถูกย่อยให้เล็กลงและจบในตัว AI จะมีบริบทครบถ้วนว่าต้องสร้างอะไร ต้องใช้รูปแบบสถาปัตยกรรมแบบไหน กฎความปลอดภัยที่ต้องบังคับใช้มีอะไรบ้าง และผลลัพธ์ที่คาดหวังคืออะไร
AI จะสร้างส่วนที่ต้องนำไปใช้งานจริง ไม่ว่าจะเป็น HTML, CSS, JavaScript หรืออะไรก็ตามที่งานนั้นต้องการ แต่ AI จะทำงานอยู่ภายใต้กฎและรูปแบบสถาปัตยกรรมที่เรากำหนดไว้ล่วงหน้าอย่างเคร่งครัด
แทนที่จะเขียนโค้ดทีละบรรทัด ตอนนี้เราทุ่มเทความเชี่ยวชาญไปกับการวางแผนภาพรวมและการตรวจสอบความถูกต้อง โดยปล่อยให้การ Execution เป็นหน้าที่ของระบบที่ถูกกำกับด้วยกรอบที่เราวางไว้
จากการทำงานและการพูดคุยกับทีมที่ Seven Peaks ซึ่งใช้ AI ในหลายโปรเจกต์ ผมได้ข้อสรุป 4 ข้อที่ทำให้การพัฒนาโดยมี AI ช่วยนั้นประสบความสำเร็จ
เหมือนกับการพัฒนาปกติ เรากำหนดข้อกำหนดด้านความปลอดภัยไว้ล่วงหน้าเป็นส่วนหนึ่งของกฎสถาปัตยกรรม แต่เมื่อใช้ AI เราสามารถแชร์กฎเหล่านี้ไปยังทุกฟังก์ชันที่ต้องการการตรวจสอบสิทธิ์ (Authentication), การตรวจสอบข้อมูลขาเข้า (Input validation) หรือการทำความสะอาดข้อมูล (Data sanitization) ได้โดยอัตโนมัติและทั่วถึงทั้ง Codebase
AI ปฏิบัติตามกฎเหล่านี้ด้วยความสม่ำเสมอแบบสมบูรณ์แบบ มนุษย์เรายังมีความล้า มีเรื่องให้วอกแวก และข้อจำกัดด้านความจำ เราอาจทำตามกฎความปลอดภัยได้ถูกต้อง 95% แต่พลาดในกรณีข้อยกเว้น (Edge case) อีก 5% แต่สำหรับ AI ถ้ามันทำงานภายใต้กรอบที่เรากำหนด มันจะใช้รูปแบบนั้นทุกครั้ง 100%
เรายังสามารถขอให้ AI รีวิวโค้ดให้เราได้ด้วย โดยสั่งให้มันตรวจสอบว่าการเขียนโค้ดเป็นไปตามโปรโตคอลความปลอดภัยของเราไหม และเช็กหาช่องโหว่เฉพาะจุด สิ่งนี้สร้างเลเยอร์การควบคุมคุณภาพ ที่ช่วยดักจับปัญหาก่อนที่นักพัฒนาของเราจะเข้าไปรีวิวโค้ดเสียอีก
Test-Driven Development หรือการเขียนเทสต์ก่อนโค้ด เป็นแนวคิดที่มีพลังมากในทางทฤษฎี แต่ในทางปฏิบัติมันท้าทายมาก เพราะต้องเขียนเทสต์ก่อน รอมันพัง แล้วค่อยเขียนโค้ดแค่พอให้เทสต์ผ่าน ซึ่งเป็น Workflow ที่นักพัฒนาหลายคนรู้สึกขัดกับสัญชาตญาณ
แต่ AI จัดการ Workflow นี้ได้อย่างเป็นธรรมชาติ เรากำหนดเกณฑ์ความสำเร็จผ่านการทดสอบ แล้วให้ AI สร้างโค้ดที่ผ่านเกณฑ์นั้น การทดสอบจึงทำหน้าที่เป็นกรอบป้องกัน (Guardrails) ที่เฉพาะเจาะจง นอกเหนือไปจากกฎสถาปัตยกรรมทั่วไป มันสร้างข้อจำกัดที่แน่นหนาสำหรับแต่ละฟีเจอร์
วงรอบของ Feedback เร็วขึ้นอย่างมหาศาล AI ทำซ้ำได้เร็วมาก รันเทสต์ ปรับแก้โค้ด แล้วรันเทสต์ใหม่ สิ่งที่มนุษย์อาจต้องใช้เวลาลองผิดลองถูกหลายชั่วโมง เสร็จได้ในไม่กี่นาที พร้อมกับผลพลอยได้คือ Test Coverage ที่ครอบคลุม ไม่ใช่สิ่งที่มาทำทีหลัง
สถาปัตยกรรมกลายเป็นตัวชี้วัดความสำเร็จหลักของการพัฒนาด้วย AI โครงสร้างองค์กรของ Codebase เป็นตัวกำหนดว่า AI จะทำอะไรได้บ้าง
สถาปัตยกรรมแบบแนวนอน (Horizontal) ที่จัดระเบียบโค้ดตามประเภท เช่น รวม Components ทั้งหมดไว้โฟลเดอร์หนึ่ง รวม Styles ไว้อีกที่ รวม Logic ไว้ที่สาม เวลา AI จะทำฟีเจอร์หนึ่ง มันต้องวิ่งไปดูหลายโฟลเดอร์ เก็บชิ้นส่วนจากที่ต่างๆ และพยายามทำความเข้าใจความสัมพันธ์ของพวกมัน
แต่สถาปัตยกรรมแบบแนวตั้ง (Vertical) จัดระเบียบตามฟีเจอร์ หรือโดเมน ทุกอย่างที่เกี่ยวกับหน้า Home ทั้ง Components, Styles, Logic, Tests จะอยู่ในโฟลเดอร์เดียว ฟังก์ชันโปรไฟล์ก็อยู่ในโมดูลของมันเอง เมื่อ AI ทำงานกับฟีเจอร์หนึ่ง มันจะเข้าถึงบริบทที่ต่อเนื่องและมีขอบเขตชัดเจน (Bounded context)
ผลลัพธ์ที่ได้ต่างกันมาก AI ก็เหมือนมนุษย์ที่มีข้อจำกัดในการรับรู้ ถ้าเราโยนบริบทที่กระจัดกระจายไปทั่วหลายไฟล์หลายโฟลเดอร์ คุณภาพงานจะตกลง แต่ถ้าเราจัดเตรียมโครงสร้างที่เป็นระเบียบและโฟกัสที่ฟีเจอร์ AI จะสร้างโค้ดที่ถูกต้องและดูแลรักษาได้ง่ายอย่างสม่ำเสมอ
ประโยชน์ที่ไม่คาดคิดอีกอย่างคือเรื่องการสื่อสารในทีม เวลาผมร่าง Requirement เองด้วยมือ Project Manager มักจะกลับมาพร้อมคำถามขอความชัดเจน เพราะรายละเอียดบางอย่างมันซ่อนอยู่ หรือมีสมมติฐานที่ไม่ได้พูดออกมา แต่พอให้ AI ร่าง Requirement เหล่านั้นจาก Template และบริบทโครงการ มันจะช่วยงัดคำถามที่ควรจะถามออกมาให้เห็นก่อนเลย ร่างแรกจึงสมบูรณ์กว่าเดิม หมายความว่ารอบของการถามตอบเพื่อขอความชัดเจนก็น้อยลง และเสียเวลาประสานงานน้อยลง
แต่แค่มีกระบวนการ (Process) ยังไม่พอการลงมือทำ (Execution) ต่างหากที่แยกทีมวิศวกรรม AI-native ที่มีประสิทธิภาพ ออกจากทีมที่แค่ใช้เครื่องมือ AI นี่คือสิ่งที่ทำให้แนวทางของเราเวิร์กในทางปฏิบัติ
ระดับความอาวุโสของทีมพัฒนาเราคือข้อได้เปรียบมหาศาล นักพัฒนาที่มีพื้นฐานแน่นปึกและประสบการณ์สูงจะรู้วิธีแตกปัญหาที่ซับซ้อน รู้วิธีมองหาจุดที่โค้ดไม่ดี (Code smells) และรู้วิธีวางสถาปัตยกรรมระบบให้ดูแลรักษาได้ ทักษะเหล่านี้ส่งผลโดยตรงต่อการกำกับดูแล AI ให้มีประสิทธิภาพ
ถ้าคุณสามารถแตกปัญหาเพื่อสอน Junior Developer ได้ คุณก็สามารถวางโครงสร้างปัญหาเดียวกันให้ AI ได้ ถ้าคุณรีวิวโค้ดและระบุปัญหาเป็น คุณก็สามารถรีวิวโค้ดที่ AI เขียนด้วยสายตาที่เฉียบคมแบบเดียวกัน ความเชี่ยวชาญนี้มันต่อยอด (Compound) ไม่ได้ล้าสมัยไป
นี่คือเหตุผลที่เราได้ผลลัพธ์จาก AI ที่มีคุณภาพและควบคุมได้ ในขณะที่คนอื่นยังดิ้นรนกันอยู่ Junior Developer หรือทีมที่ไม่มีพื้นฐานสถาปัตยกรรมที่แข็งแกร่งจะลำบากในการกำหนดกรอบที่เหมาะสม พวกเขาอาจมองไม่ออกเมื่อ AI สร้างโซลูชันที่ไม่ดีพอ วิศวกรระดับ Senior ของเรานำประสบการณ์หลายสิบปีในการจดจำรูปแบบ และวิจารณญาณมาใช้ ซึ่งนั่นคือเส้นแบ่งระหว่างการใช้ AI แล้วเป็นภาระ กับการใช้ AI เป็นตัวทวีคูณพลัง
ถามว่าโค้ดที่ AI เขียนสร้างช่องโหว่ความปลอดภัยหรือหนี้ทางเทคนิค (Technical Debt) ไหม? ถ้าคุณปล่อยให้ AI เขียนโค้ดไปเรื่อยๆ โดยไม่มีการชี้นำ หรือที่บางคนเรียกว่า "Vibe coding" อันนั้นจริงแน่นอน แต่นั่นไม่ใช่วิธีที่เราทำงาน
เรากำหนดข้อกำหนดความปลอดภัยล่วงหน้าในกฎสถาปัตยกรรม เราตัดสินใจว่าจะใช้สถาปัตยกรรมแบบไหน เราวางมาตรฐานวิศวกรรมที่ต้องปฏิบัติตาม และ AI จะทำงานอยู่ภายใต้กรอบที่เราสร้างไว้อย่างระมัดระวังนี้
นักพัฒนายังคงรับผิดชอบต่อผลลัพธ์เต็มร้อย กระบวนการ Code Review ไม่ได้เปลี่ยนไป เราแค่มีขั้นตอนการตรวจสอบเพิ่มเติมเข้ามาเพื่อยกระดับคุณภาพเบื้องต้นของโค้ดก่อนจะส่งถึงมือมนุษย์ นักพัฒนาทุกคนในทีมเข้าใจดีว่าพวกเขาเป็นเจ้าของสิ่งที่ส่งมอบ ไม่ว่าเขาจะเป็นคนพิมพ์เองหรือ AI สร้างให้ก็ตาม
AI เก่งบางเรื่องและแย่บางเรื่อง เราเจอคอขวด 2 จุดในงานพัฒนา Mobile ของเราคือ การทำ Database connection และกรณี UI ที่มีความซับซ้อนเฉพาะ (UI edge cases) แทนที่จะมองว่าเป็นปัญหาที่แก้ไม่ได้ เราสร้างโซลูชันมารองรับมัน
Seven Peaks Product Accelerator ซึ่งเป็น Template แอปพลิเคชันภายในของเรา มีการเตรียม Database connections, ระบบ Authentication และ Library ของ UI component ไว้ให้แล้ว เมื่อ AI ทำงานบน Template นี้ มันจะใช้โครงสร้างพื้นฐานที่มีอยู่และผ่านการทดสอบมาแล้ว แทนที่จะไปสร้างสถาปัตยกรรม Database ใหม่จากศูนย์ วิธีนี้ช่วยปิดจุดอ่อนของ AI และขยายจุดแข็งของมันในด้านการเขียน Logic ธุรกิจและการพัฒนาฟีเจอร์
สำหรับความต้องการเฉพาะเจาะจงบนแพลตฟอร์ม iOS และ Android เรามีคลังคำสั่ง (Prompt libraries) ที่ผ่านการขัดเกลามาแล้วเพื่อจัดการกับรายละเอียดจุกจิก สิ่งเหล่านี้คือความรู้องค์กร และประสบการณ์สั่งสมของทีมเรา ที่ถูกแปลงเป็นรูปแบบที่นำกลับมาใช้ใหม่ได้ และดีขึ้นเรื่อยๆ ในทุกโปรเจกต์
แค่มีเครื่องมือไม่ได้ทำให้เกิดความสามารถแบบ AI-native เราจัดเซสชันอบรมกับทีมวิศวกรอย่างสม่ำเสมอ ผสมผสานระหว่างการบรรยายความสามารถของ AI กับ Workshop ที่ได้ลงมือทำจริงโดยใช้สถานการณ์จากโปรเจกต์จริง
เมื่อลูกค้าจ้างทีมของเรา พวกเขาจะได้กำลังการผลิต (Capacity) ที่เพิ่มขึ้นมหาศาลโดยไม่ต้องเพิ่มจำนวนคน ได้เวลาเข้าสู่ตลาด (Time-to-market) ที่เร็วขึ้นโดยไม่ต้องแลกด้วยคุณภาพ และได้ระบบที่ทันสมัย วางสถาปัตยกรรมมาอย่างดี สร้างโดยวิศวกรมากประสบการณ์ที่รู้วิธีเพิ่มพลังการทำงานด้วยเครื่องมืออัจฉริยะ
ความแตกต่างไม่ได้อยู่ที่การมีเครื่องมือ AI เพราะเดี๋ยวนี้ใครๆ ก็เข้าถึงได้ แต่มันอยู่ที่การรู้วิธีวางโครงสร้างระบบ กำหนดกรอบที่เหมาะสม และประสานการทำงานร่วมกันระหว่างความเชี่ยวชาญของมนุษย์กับการลงมือทำของเครื่องจักร มันคือการมี Senior Engineer ที่มองออกว่าเมื่อไหร่ AI ทำได้ดีและเมื่อไหร่ต้องดึงกลับมา และมันคือการมีความรู้องค์กรที่ถูกบันทึกไว้ใน Templates และ Prompt libraries ที่พัฒนาขึ้นเรื่อยๆ ในทุกโปรเจกต์นั่นเอง