มุมมองของวิศวกร frontend ต่อเวิร์กโฟลว์ผลิตภัณฑ์-วิศวกรรมยุค AI แบบใหม่
ตัวเลขที่ไม่น่าเชื่อ
12 วัน สองคน: นักออกแบบผลิตภัณฑ์และวิศวกร frontend หนึ่งคน สร้างแพลตฟอร์มใหม่ทั้งระบบ
ไม่ใช่แค่ต้นแบบ ไม่ใช่ MVP แต่เป็นการแทนที่แอปพลิเคชันที่ใช้งานจริงทั้งระบบ จบลงด้วย PR เดียวที่ลบโค้ดเก่าออกไป 26,000 บรรทัด ทุกหน้า ทุกเส้นทาง ทุกปฏิสัมพันธ์ ถูกสร้างขึ้นใหม่ทั้งหมดและส่งมอบให้ผู้ใช้จริง
ในเวิร์กโฟลว์พัฒนาผลิตภัณฑ์แบบดั้งเดิม ระยะเวลานี้แทบเป็นไปไม่ได้ โปรเจกต์ขนาดนี้ปกติใช้เวลาหลายเดือน: ออกแบบใน Figma หลายสัปดาห์ ทบทวนกับผู้มีส่วนได้ส่วนเสีย ส่งมอบงาน วางแผน sprint แล้วค่อย ๆ ลงมือทำให้ตรง pixel ทุกจุด สิ่งที่เกิดขึ้นที่นี่แตกต่างโดยสิ้นเชิง ไม่ใช่เพราะเราทำงานหนักขึ้น แต่เพราะวิธีการทำงานร่วมกันเปลี่ยนไป
นี่คือเรื่องราวของการส่งมอบแพลตฟอร์ม Zero ที่ VM0 และสิ่งที่ผมได้เรียนรู้เกี่ยวกับอนาคตของความร่วมมือระหว่างทีมออกแบบและวิศวกรรม
คอขวดแบบเดิม
วิศวกร frontend ทุกคนรู้จักขั้นตอนแบบดั้งเดิมนี้ดี:
- นักออกแบบสร้าง mockup ใน Figma
- ทบทวน ออกแบบ ปรับแก้ และอนุมัติ
- สเปกพร้อมคำอธิบายเรื่องระยะ สี จุดเปลี่ยนขนาดหน้าจอ
- วิศวกรแปลงสเปกภาพเป็นโค้ด
- วนไปมา: "ช่วยขยับอันนี้ไปทางซ้ายอีก 4px ได้ไหม?"
- สุดท้ายเชื่อมต่อ API layer
- ทดสอบการเชื่อมต่อ วนกลับไปแก้ไขอีก
คอขวดไม่ได้อยู่ที่ขั้นตอนใดขั้นตอนหนึ่ง แต่มันอยู่ที่ช่องว่างระหว่างขั้นตอน: การรอคอย การแปลความผิดพลาด การสลับบริบท โมเดลความคิดของนักออกแบบเกี่ยวกับปฏิสัมพันธ์ เมื่อถูกแปลงเป็นเฟรม Figma แบบนิ่งและใส่คำอธิบาย ก็ถูกลดทอนลงแล้ว วิศวกรสร้างสิ่งที่นักออกแบบจินตนาการขึ้นใหม่ แต่สุดท้ายมันก็เป็นเพียงสำเนาที่สูญเสียรายละเอียดไป
เราคุ้นชินกับแรงเสียดทานนี้จนมองไม่เห็น มันกลายเป็น "วิธีการทำงานปกติ"
การทดลอง: ถ้านักออกแบบส่งโค้ดเองล่ะ?
วันที่ 5 มีนาคม 2026 Ming นักออกแบบผลิตภัณฑ์ของเรา เปิด PR #3685: feat(platform): add zero app with shell, pages and polish เพิ่มโค้ด React ที่ใช้งานได้จริง 4,146 บรรทัด
ไม่ใช่ไฟล์ Figma ไม่ใช่ export design token แต่เป็นแอปพลิเคชันที่รันได้จริง
PR นี้มีโครงสร้างแอปครบถ้วน: แถบข้างนำทาง โครงสร้าง routing โครงหน้าสำหรับ chat, schedule, activity, team management และ settings ทั้งหมดใช้ดีไซน์ซิสเต็มของเราและแสดงผลในเบราว์เซอร์ ข้อมูลยังเป็น mock แต่ UI จริง คุณสามารถ npm run dev และคลิกดูทุกหน้าได้
Ming ไม่ได้เขียนโค้ดนี้เองแบบดั้งเดิม เธอใช้เครื่องมือเขียนโค้ดด้วย AI (เริ่มจาก Cursor ต่อด้วย Claude Code) เพื่อแปลงวิสัยทัศน์การออกแบบเป็น React component โดยตรง AI จัดการแปลงโครงสร้าง (JSX, CSS, การประกอบ component) ส่วน Ming ตัดสินใจเรื่องภาพและปฏิสัมพันธ์ที่ AI ยังทำไม่ได้: จังหวะของ layout ลำดับข้อมูล ความรู้สึกของการเปลี่ยนผ่าน
สี่วันถัดมา มี PR เพิ่มอีกสามชุด:
| วันที่ | PR | สิ่งที่ Ming ส่ง |
|---|---|---|
| Mar 5 | #3685 | โครงแอป, แถบข้าง, โครงหน้าทั้งหมด (+4,146 บรรทัด) |
| Mar 6 | #3825 | หน้า schedule, เก็บรายละเอียด UI (+2,650 บรรทัด) |
| Mar 9 | #3993 | Onboarding flow, กล่องตั้งค่า Slack (+1,146 บรรทัด) |
| Mar 9 | #4050 | หน้า About, การ์ดนำทางลอย |
ถึงวันที่ 9 มีนาคม พื้นผิว frontend ทั้งหมดของแพลตฟอร์มใหม่ของเราก็กลายเป็นโค้ดที่รันได้ ทุกหน้าที่จะเห็นใน production คลิกดูได้หมดใน dev environment เพียงแต่ยังไม่เชื่อมต่อข้อมูลจริง
ตรงนี้เองที่ผมเข้ามา
งานใหม่ของผม: เติมชีวิตให้ระบบ
เมื่อผมเปิด codebase วันที่ 9 มีนาคม ผมไม่ได้เจอความท้าทายเดิม ๆ ในการแปลงดีไซน์แบน ๆ เป็นโค้ด โค้ดมีอยู่แล้ว งานของผมคือแทนที่ mock ทุกจุดด้วยของจริง เชื่อมต่อทุกพื้นผิวที่ออกแบบไว้อย่างสวยงามกับ backend ที่ทำงานจริง
สิ่งนี้เปลี่ยนวิธีคิดของผมโดยสิ้นเชิง จากเดิมที่คิดเรื่อง pixel กลายเป็นคิดเรื่อง data flow จากที่เคยถามว่า "ตรงกับ mockup ไหม" กลายเป็น "หน้านี้ต้องเรียก API อะไร ถ้า error จะเกิดอะไรขึ้น"
นี่คือสัปดาห์แรกของผม:
วันที่ 1 (9 มีนาคม): ระบบ auth และสลับองค์กร ผมเชื่อม shell ของ Ming กับ Clerk authentication เพิ่ม redirect ข้ามโดเมน และทำให้ org switcher ใช้งานได้จริง สอง PR รวมในวันเดียว
วันที่ 2 (10 มีนาคม): เชื่อมต่อ connector และ schedule ผมแทนที่ grid connector mock ด้วยข้อมูล API จริง เชื่อมแท็บ schedule กับ cron job จริง และเชื่อม editor คำสั่งกับ backend สี่ PR
วันที่ 3 (11 มีนาคม): วัน wiring ใหญ่ หน้า team ได้ข้อมูล subagent จริง (+3,271 บรรทัด) หน้า activity ได้ log จริง และไฮไลต์: หน้า chat เชื่อมกับ pipeline agent run จริง แทนที่โค้ดเดโม ~1,200 บรรทัดด้วยอินเทอร์เฟซสนทนา AI ที่ใช้งานได้จริง วันเดียวกันนั้น ผมเพิ่ม FeatureSwitchKey.Zero ฟีเจอร์แฟลกที่ให้เรารันแพลตฟอร์มเก่าและใหม่คู่กัน
วันที่ 4-5 (12-13 มีนาคม): แนบไฟล์ จัดการ session สนทนาแบบหลาย agent บันทึกการตั้งค่า ทุกหน้าที่ Ming สร้างไว้เริ่มทำงานจริง
จังหวะงานเหมือนดนตรี ทุกเช้าผมเลือกหน้าจาก scaffold ของ Ming ศึกษาโครงสร้าง component ดูว่าต้องการข้อมูลอะไร สร้างการเชื่อมต่อ API จัดการ error แล้ว push ตอนบ่ายอีกหน้าก็ใช้งานได้
ฟีเจอร์แฟลก: โลกคู่ขนาน
ฟีเจอร์แฟลก FeatureSwitchKey.Zero สมควรกล่าวถึงเป็นพิเศษ เพราะมันทำให้การย้ายระบบนี้ปลอดภัย ไม่ใช่เสี่ยง
ตั้งแต่ 11 มีนาคมเป็นต้นไป แอป production ของเรารัน UI สองชุดคู่กัน ผู้ใช้ระบบเก่าเห็นเส้นทางเดิม ผู้ทดสอบภายในเห็น Zero ทุกหน้าที่ผมเชื่อมต่อสามารถทดสอบในบริบท production ได้โดยไม่กระทบ workflow ของผู้ใช้จริง
นี่ไม่ใช่เรื่องใหม่ ฟีเจอร์แฟลกเป็นมาตรฐานอยู่แล้ว แต่เมื่อรวมกับเวิร์กโฟลว์ design-as-code มันพิเศษขึ้น: เราตรวจสอบ UX ใหม่ได้ทั้งระบบ (เพราะ Ming สร้าง UI ที่คลิกได้ครบ) ขณะเดียวกันก็ทยอยทำให้แต่ละหน้าทำงานจริง (เพราะผมเชื่อมต่อทีละหน้า) ถ้ามีอะไรผิดพลาดก็แค่สลับกลับ
ไม่มีอะไรผิดพลาดเลย
วันที่ 12: พลิกสวิตช์ใหญ่
วันที่ 17 มีนาคม ผมเปิด PR #5095: refactor: remove all non-zero platform pages and feature flag
ผลต่าง: +456 บรรทัด, -26,041 บรรทัด
ก่อน: VM0 Platform เก่า ตาราง run ID ข้อมูล session ดิบ
หลัง: Zero ใหม่ พื้นที่ทำงาน AI แบบสนทนา มี agent ปักหมุดและการ์ด use case
merge เดียว ลบ route เก่าทั้งหมด ฟีเจอร์แฟลกถูกถอดออก Zero ไม่ใช่ตัวเลือกอีกต่อไป แต่เป็นโหมดเดียว PR ถัดมา (#5155) ลบ prefix URL /zero ออกหมด: จากที่เคยเป็น /zero/chat กลายเป็น /chat เฉย ๆ
ทำไมผมมั่นใจตัดสินใจแบบนี้?
- ทุกหน้ารันภายใต้ฟีเจอร์แฟลกอย่างน้อย 5 วัน
- ทุก API integration ทดสอบกับข้อมูล production แล้ว
- ระบบเก่าและใหม่ใช้ backend เดียวกัน แค่สลับ frontend ไม่ใช่ย้ายข้อมูล
- มีผู้ใช้จริงบนระบบใหม่ให้ feedback ตลอด
26,000 บรรทัดที่ถูกลบ ไม่ได้ลบด้วยความกังวล แต่ลบด้วยความโล่งใจ
รูปแบบนี้เกิดซ้ำ
สิ่งที่ทำให้ผมประหลาดใจไม่ใช่การย้ายระบบ แต่คือเวิร์กโฟลว์ที่ค้นพบนี้กลายเป็นมาตรฐานสำหรับทุกฟีเจอร์ถัดไป Ming สร้าง UI shell ด้วย AI ผมเชื่อม logic และขยายสถาปัตยกรรม รูปแบบ design-as-code เดิมในระดับฟีเจอร์:
ระบบสิทธิ์ (มีนาคม 19 → เมษายน 7)
Ming ส่ง PR #5467 UI ลิ้นชักสิทธิ์พร้อม Sheet component และ toggle สาม commit UI สะอาด
ผมเพิ่ม commit 13 ใน PR เดียวกัน: ย้ายฐานข้อมูลสำหรับ firewall_access_requests, endpoint API, integration test, แก้ lint สองสัปดาห์ถัดมา PR ตามอีก 10+ ชุด สร้างระบบสิทธิ์เต็มรูปแบบ: ออกแบบ approval card ใหม่ แจ้งเตือน Slack สำหรับคำขอสิทธิ์ คำสั่ง CLI doctor สำหรับวิเคราะห์ปัญหา และสุดท้ายเปลี่ยนชื่อจาก "firewall" เป็น "permission" ทั้ง codebase
ลิ้นชักของ Ming คือเมล็ด ระบบ permission คือทั้งต้นไม้
ระบบตารางเวลา (มีนาคม 23 → เมษายน 13)
Ming ออกแบบ route รายละเอียดตารางเวลาและ UX ปฏิทิน (#6155) สาม commit งาน UI สะอาด
ผมเพิ่ม commit 14: แก้ไขคำอธิบายพร้อมสร้างอัตโนมัติ เลือกช่อง Slack สำหรับแจ้งเตือน กล่องยืนยันเมื่อยังไม่บันทึก รวมมุมมองปฏิทิน/รายการ และทดสอบครบถ้วน PR ตามอีก 15+ ชุด ขยายเป็นระบบงานประจำเต็มรูปแบบ มีประวัติ run รองรับ timezone และ cron expression
การเชื่อมต่อ Telegram (เมษายน 27 → เมษายน 28)
ถึงจุดนี้ รูปแบบนี้คล่องจนเราส่ง integration ทั้งแพลตฟอร์มใน 48 ชั่วโมง Ming สร้าง UI ตั้งค่า (#11196) และ onboarding (#11399) ผมสร้าง API หลายบอท ส่ง/รับข้อความ อัปโหลด/ดาวน์โหลดไฟล์ ข้อความ rich context อัปเดต real-time ด้วย Ably และทดสอบ E2E วันถัดไปเปิดให้ผู้ใช้ทุกคน
บทบาทของ AI
ผมอยากอธิบายบทบาทของ AI ให้ชัด เพราะมันง่ายที่จะพูดเกินจริงหรือดูแคลน
AI ทำให้นักออกแบบเขียนโค้ดได้ Ming เป็นนักออกแบบผลิตภัณฑ์ ไม่ใช่วิศวกรซอฟต์แวร์ เธอคิดเป็น layout ลำดับชั้น ปฏิสัมพันธ์ ไม่ใช่ React hook หรือ TypeScript generic เครื่องมือ AI (Cursor, Claude Code) เชื่อมช่องว่างนี้ด้วยการแปลงเจตนาการออกแบบเป็นโค้ดที่ใช้งานได้ Ming กำกับ AI พิมพ์ ผลลัพธ์คือโค้ดที่นักออกแบบสร้างแต่วิศวกรต่อยอดได้
AI เร่งรอบการรีวิว ใน PR ร่วมกัน AI agent ของผมจะรีวิวโค้ดของ Ming จัดลำดับปัญหา (P0/P1/P2) และ push commit แก้ไขโดยตรง PR #5060 ผ่านห้ารอบรีวิวใน 38 นาที PR #5467 สามรอบใน 20 นาที นี่ไม่ใช่ "AI แทน code review" ผมยังอ่านทุกการเปลี่ยนแปลง แต่งานกลไกอย่าง lint, type, test gap ถูก automate ไป
AI ไม่ได้ตัดสินใจออกแบบ สถาปัตยกรรมข้อมูลแต่ละหน้า รูปแบบปฏิสัมพันธ์ ลำดับภาพ มาจากสัญชาตญาณผลิตภัณฑ์ของ Ming จาก user research และความเชี่ยวชาญ AI สร้างหน้า settings ได้ แต่ตัดสินใจไม่ได้ว่าอะไรควรเป็น toggle หรือ dropdown หรือเมื่อไรควรมี dialog ยืนยัน
AI ไม่ได้ตัดสินใจสถาปัตยกรรม การเลือกใช้ฟีเจอร์แฟลกสำหรับ deployment คู่ กลยุทธ์แยก API layer การเชื่อมหน้าทีละหน้าแทนที่จะรวดเดียว ทั้งหมดคือวิจารณญาณวิศวกร AI ช่วยให้เขียนโค้ดเร็วขึ้น แต่ลำดับและการจัดการความเสี่ยงเป็นงานมนุษย์
สรุปตรงไปตรงมา: AI กำจัดชั้นแปลความระหว่างออกแบบกับวิศวกรรม ไม่ได้แทนที่ใคร แต่ลบช่องว่างระหว่างกัน
บทบาทของผมที่เปลี่ยนไป
หลังใช้เวิร์กโฟลว์นี้สามเดือน ผมมองบทบาทวิศวกร frontend ต่างออกไป
ผมไม่ใช่คนแปลภาพเป็นโค้ดอีกต่อไป หมดยุครับไฟล์ Figma แล้วนั่งจับระยะ pixel ทีละจุด ไม่ใช่เพราะผมทำเร็วขึ้น แต่เพราะมันไม่ใช่งานของผมอีกแล้ว เจตนานักออกแบบมาถึงเป็นโค้ด ไม่ใช่ภาพโค้ด
ผมคือผู้ขยายสถาปัตยกรรม งานหลักคือรับ UI ที่ใช้งานได้ แล้วสร้างโครงสร้างเบื้องหลัง: เชื่อม API ตรวจสอบข้อมูล จัดการ error ตรวจสิทธิ์ อัปเดต real-time ทดสอบ อัตราส่วนใน PR ร่วมกันบอกชัด Ming ส่ง commit UI 3 ผมส่ง commit ส่วนอื่น 13
ผมคือผู้ควบคุมคุณภาพ ด้วยรอบรีวิวที่ AI ช่วย ผมดูแลคุณภาพโค้ดในพื้นที่กว้างขึ้น งานกลไก AI จัดการ ผมโฟกัสที่สถาปัตยกรรม กรณีขอบ และให้แน่ใจว่าฟีเจอร์ทำงานครบวงจร
ผมคือผู้วางกลยุทธ์ส่งมอบ ฟีเจอร์แฟลก การเชื่อมต่อทีละส่วน การ deploy คู่ ลำดับการนำฟีเจอร์ขึ้น production กลายเป็นงานหลัก ไม่ใช่เรื่องท้ายสุด
ตัวเลข
สามเดือน สองคน มี AI ช่วยตลอด
- PR รวม 914 ชุด (ของผม 679, ของ Ming 235)
- 12 วัน จาก scaffold แรกถึงแทนที่แพลตฟอร์มทั้งระบบ
- 48 ชั่วโมง สำหรับ integration Telegram ครบชุด (ฟีเจอร์ที่เร็วที่สุด)
- 26,000 บรรทัด ถูกลบใน merge เดียวอย่างมั่นใจ
- 88% ของ PR ผม และ 66% ของ Ming มี AI ร่วมเขียน
นี่ไม่ใช่ตัวเลขโชว์ความขยัน เราไม่ทำงานวันหยุดหรืออดนอน ความเร็วเกิดจากการตัด dead time: ประชุมส่งมอบ สเปกเข้าใจผิด วนแก้ pixel เมื่อเจตนาออกแบบไหลตรงสู่โค้ด และวิศวกรต่อยอดโค้ดนั้นในที่เดียวกัน ของเสียก็ลดลง
ความหมายสำหรับทีม
ผมไม่ได้บอกว่าทุกทีมควรทำแบบนี้ เวิร์กโฟลว์นี้เกิดจากบริบทเฉพาะ: ทีมเล็ก โอกาสสร้างใหม่ และได้ใช้เครื่องมือ AI coding ก่อนใคร ผลลัพธ์แต่ละทีมอาจต่างกัน
แต่ผมเชื่อว่าการเปลี่ยนแปลงนี้เป็นสากล: ขอบเขตระหว่างออกแบบกับวิศวกรรมกำลังเลือนหาย และ AI คือสารละลาย เมื่อ AI แปลเจตนาเป็นโค้ดได้ดีขึ้น นักออกแบบจะส่งโค้ดเองมากขึ้น วิศวกรจะใช้เวลาน้อยลงกับการแปล มากขึ้นกับสถาปัตยกรรม คุณภาพ และการส่งมอบ
งานวิศวกร frontend ไม่หายไป แต่มันเปลี่ยนรูป และพูดตรง ๆ รูปแบบใหม่น่าสนใจกว่าเดิม
Yuma เป็นวิศวกร frontend ที่ VM0 สร้างแพลตฟอร์มที่ขับเคลื่อน Zero ระบบปฏิบัติการ AI agent เขาเคยลบโค้ดเก่าจำนวนมากกว่าที่อยากยอมรับ
