- การพัฒนาซอฟต์แวร์ภายในองค์กร กำลังก้าวเข้าสู่ยุคที่แม้แต่ผู้ที่ไม่ใช่ผู้เชี่ยวชาญก็สามารถสร้าง แอปที่สมบูรณ์ ได้ด้วยภาษาธรรมชาติ อันเป็นผลจาก generative AI
- ในอดีต เครื่องมือ low-code/no-code ยังไม่อาจหลุดพ้นจากการพึ่งพาวิศวกรได้ เนื่องจากข้อจำกัดด้านการผสานรวม ความปลอดภัย และความสามารถในการขยายระบบ
- แต่ AI app builder อย่าง Replit, Lovable และ Vercel v0 กำลังทำให้การสร้างต้นแบบอย่างรวดเร็วและการทำเวิร์กโฟลว์ที่ผู้ใช้ขับเคลื่อนเองเป็นไปได้
- เช่นกรณีของ Sears, Zillow และ Intuit ที่ ทีมที่ไม่ใช่วิศวกร กำลังพัฒนาแอปภายในหลายสิบตัวเพื่อใช้งานจริงในการปฏิบัติงานด้วยตนเอง
- อย่างไรก็ตาม ความปลอดภัย การกำกับดูแล และการผสานรวม ยังคงเป็นประเด็นสำคัญ และ กระบวนทัศน์ใหม่ ที่ต้นแบบสามารถต่อยอดไปเป็นระบบใช้งานจริงได้ทันที กำลังใกล้เข้ามา
ประวัติของเครื่องมือภายใน
- เป็นเวลานานแล้วที่องค์กรต้องการซอฟต์แวร์ภายใน เช่น แดชบอร์ด เวิร์กโฟลว์ และฐานข้อมูล
- เคยมีความพยายามด้วย Lotus Notes, Excel macro และ Access แต่ก็มีข้อจำกัดจากปัญหาการบำรุงรักษาและการขยายระบบ
- ในช่วงทศวรรษ 2010 เมื่อ cloud และ SaaS แพร่หลายมากขึ้น การแยกขาดของข้อมูลยิ่งรุนแรงขึ้น ทำให้ เครื่องมือภายในถูกมองว่าเป็นโครงสร้างพื้นฐานที่จำเป็น
- Facebook ประสบความสำเร็จจากการลงทุนในแดชบอร์ดภายในและเครื่องมือสำหรับนักพัฒนา แต่บริษัทส่วนใหญ่ยังขาดความสามารถในการสร้างเอง
- ด้วยเหตุนี้แพลตฟอร์มยุคแรกอย่าง Retool และ Zapier จึงถือกำเนิดขึ้น แต่ก็ยังมีข้อจำกัดอยู่
ข้อจำกัดของ low-code/no-code
- ขาด self-service อย่างสมบูรณ์: ทำงานอัตโนมัติแบบง่ายได้ แต่ตรรกะที่ซับซ้อนยังต้องใช้สคริปต์
- ปัญหาด้านการผสานรวมและความปลอดภัย: เมื่อนำไปใช้ในองค์กรขนาดใหญ่ ยังขาด RBAC, audit log และการรับรองด้านความปลอดภัย
- ข้อจำกัดด้านการขยายระบบ: รองรับข้อมูลขนาดใหญ่และ UI ประสิทธิภาพสูงได้จำกัด รวมถึงข้อจำกัดในการเข้าถึง API
- แรงเสียดทานในองค์กร: เอกสารไม่เพียงพอ ไม่มีการจัดการสิทธิ์ และมีความเสี่ยงจาก shadow IT
Generative AI และ Text-to-Apps
- หลังปี 2023 ได้เกิดเครื่องมือรุ่นใหม่ที่สามารถ สร้างแอปจากภาษาธรรมชาติ ขึ้นมา
- Lovable, Replit, Vercel v0, Figma Make และ Bolt ต่างมอบระบบอัตโนมัติครอบคลุมตั้งแต่ UI ตรรกะ DB ไปจนถึงการ deploy
- ข้อดี:
- เวลาสร้างต้นแบบ ลดจากระดับเป็นสัปดาห์เหลือเพียงไม่กี่ชั่วโมง
- ผู้ที่ไม่ใช่วิศวกร ก็สามารถสร้างแอปสำหรับงานจริงได้
- กรณีใช้งานระยะแรกครอบคลุมความต้องการทางธุรกิจจริง เช่น แดชบอร์ด การจัดการตั๋วงาน และงานอัตโนมัติที่อิง API
กรณีใช้งานจริง
- Sears Home Services: ผู้ที่ไม่ใช่ผู้เชี่ยวชาญสร้างแอปภายในมากกว่า 50 ตัว (ระบบตั๋วงาน การแจ้งเตือน SMS แดชบอร์ดสั่งซื้ออะไหล่ เป็นต้น)
- Zillow: ทีมกลยุทธ์สร้างแดชบอร์ดการขายบนพื้นฐานของ Three.js เพื่อนำไปใช้ในการตัดสินใจของผู้บริหาร
- Oscar Health: วิศวกรสร้างเครื่องมือสร้างอวาตาร์ผู้ให้บริการด้วยเครื่องมือ AI
- Ostro: สร้างเครื่องมือจัดหมวดหมู่บันทึกการสนับสนุนลูกค้าและจัดระเบียบ data pipeline
- Intuit: ผู้จัดการผลิตภัณฑ์ใช้ Replit สร้างการจำลองแคมเปญและแดชบอร์ดที่ใช้งานได้จริง
ข้อจำกัดในปัจจุบัน
- ผู้ที่ไม่ใช่ผู้เชี่ยวชาญยังแก้ไขข้อผิดพลาดได้ยาก และมี ข้อจำกัดของการ re-prompt
- เมื่อต้อง ผสานรวมกับระบบภายใน ความเร็วจะลดลงเพราะการตรวจสอบความปลอดภัย ความซับซ้อนด้านการยืนยันตัวตน และการขาดคอนเน็กเตอร์
- แม้จะเป็นโค้ดที่สร้างขึ้นมา ก็ยังคง ต้องการการบำรุงรักษา อยู่ดี
- การกำกับดูแลยังไม่เพียงพอ: ขาดการควบคุมการเข้าถึง การตรวจสอบย้อนหลัง และการจัดการเวอร์ชัน
- ส่วนใหญ่ยังคง เน้นต้นแบบ ขณะที่ระบบระดับ production ยังต้องพึ่งวิศวกร
- ข้อจำกัดด้านคุณภาพของพรอมป์ต์: อาจเกิดข้อผิดพลาดเมื่อจัดการดีไซน์ที่ไม่เป็นมาตรฐานหรือตรรกะที่ซับซ้อน
ความต่างของลำดับความสำคัญระหว่างเครื่องมือภายในกับต้นแบบ
- เมื่อต้องสร้างเครื่องมือภายใน: ความปลอดภัย การควบคุมการเข้าถึง การผสานรวม และการกำกับดูแล คือหัวใจสำคัญ
- เมื่อต้องสร้างต้นแบบ: UI/ดีไซน์ ความยืดหยุ่น และการทำซ้ำอย่างรวดเร็ว จะได้รับความสำคัญมากกว่า
แนวโน้มในอนาคต
- เครื่องมือ generative AI ยังไม่ได้มาแทนที่วิศวกร แต่กำลังเปลี่ยนแปลง วิธีวางแผน ทดสอบ และแชร์ซอฟต์แวร์ภายใน
- ทิศทางการพัฒนา:
- การเปลี่ยนผ่านอย่างลื่นไหลจาก ต้นแบบ → เครื่องมือใช้งานจริง
- ความสามารถของ ทีมแนวหน้า ในการสร้างแอปได้ทันที
- การสร้าง ระบบภายในแบบปรับแต่งเฉพาะ ที่เหมาะกับเวิร์กโฟลว์ของแต่ละทีมได้โดยตรง
- บางบริษัทกำลังจ้าง internal deployment engineer (IDE) เพื่อเร่งการเปลี่ยนแปลงนี้ในระดับองค์กร
บทสรุป
- หาก no-code ยุคแรกเคยให้คำมั่นเรื่อง การเข้าถึงได้ง่าย เครื่องมือที่ขับเคลื่อนด้วย AI ก็ให้ทั้ง ความเร็วและความสามารถในการขยายระบบ
- มีความเป็นไปได้สูงที่เครื่องมือภายในซึ่งเคยหยุดอยู่แค่ระดับต้นแบบ จะพัฒนาไปเป็น โครงสร้างพื้นฐานหลักของสภาพแวดล้อมการปฏิบัติงานจริง
1 ความคิดเห็น
ดูจากประเด็นเรื่องการควบคุมภายในหรือการตรวจสอบแล้ว เรื่องนี้ก็ดูเหมือนจะยังไม่ง่ายนักสำหรับผู้ที่ไม่ใช่นักพัฒนาในการนำไปใช้ด้วยเช่นกัน ตอนนี้ยิ่งชัดเจนขึ้นว่า LLM ในปัจจุบันไม่สามารถกลายเป็น AGI ได้ และยังมีข้อจำกัดในการเขียนโค้ดอยู่ จึงดูเหมือนว่าจะมีคำประกาศแบบกัดฟันว่า "ไม่ นี่ใช้ได้จริงนะ" ออกมากันมากขึ้นเรื่อย ๆ