วันนี้ผมตกผลึกเรื่องหนึ่งขึ้นมาครับ หลังจากใช้ AI และอยู่ท่ามกลางคนที่ใช้ AI ทั้งฝั่ง user และ developer มาประมาณ 1-2 ปี ผมเห็นคนรอบตัวเปลี่ยนวิธีสร้าง software เร็วมาก โดยเฉพาะตั้งแต่ต้นปี 2026 ที่เครื่องมือกลุ่ม coding agent และ AI สำหรับช่วยทำงานเริ่มเข้าถึงคนที่ไม่ได้เป็น programmer มากขึ้น
ตอนแรกผมใช้ AI เขียนโปรแกรมด้วยตัวเองเป็นหลัก เพราะผมเป็น programmer อยู่แล้ว จึงรู้ว่าต้องสั่งอะไร ต้องดู code ตรงไหน และควรสงสัยผลลัพธ์เมื่อไร แต่ระยะหลัง เจ้านาย น้องในทีม และเพื่อนร่วมงานที่ไม่ได้ทำหน้าที่ programmer โดยตรง เริ่มทำ prototype ออกมาเอง บางคนไปไกลถึงขั้นสร้างโปรแกรมที่ใช้งานได้ แล้วค่อยเรียก programmer เข้าไปช่วยเฉพาะจุด
ภาพนี้ทำให้ผมกลับมาถามว่า ถ้า AI เขียน code ได้เร็วมากแล้ว ทำไมหลายโครงการยังช้าเหมือนเดิม คำตอบที่ผมได้ คือ เราเร่งช่วงผลิต code ได้ แต่ช่วงที่คนหนึ่งพยายามอธิบายสิ่งที่ตัวเองต้องการให้อีกคนเข้าใจ ยังเป็นคอขวดก้อนเดิมครับ
หมายเหตุ: เอเจ้นชมพูช่วยถอดความและเรียบเรียงจากประสบการณ์กับมุมมองที่ฟิวส์เล่าอย่างละเอียด
สรุปไฮไลต์สั้นๆ
- AI เร่งการเขียน code แต่ไม่ได้ทำให้การค้นหาและถ่ายทอดความต้องการเร็วขึ้นโดยอัตโนมัติ
- คนทำ software เริ่มแยกได้ 5 กลุ่ม ตามระยะห่างระหว่างคนที่มีความต้องการกับคนที่ลงมือสร้าง
- Prototype ที่ใช้งานได้จริง สื่อสารได้ชัดกว่า requirement หรือ wireframe ที่ยังต้องตีความอีกหลายทอด
- Programmer จะขยับเข้าใกล้บทบาท consultant มากขึ้น โดยช่วยเรื่อง architecture, integration, security และ production readiness
- อนาคตอาจเหลือ workflow เด่นเพียง 2 แบบ คือ user สร้างเองโดยมี programmer ช่วยไกด์ กับ user ทำของที่ชัดแล้วส่งให้ programmer ทำต่อ
ผมเห็นคนสร้าง software อยู่ประมาณ 5 กลุ่ม
ถ้าแบ่งแบบหยาบๆ จากคนที่ผมเจอ ผมคิดว่าตอนนี้มีอยู่ประมาณ 5 กลุ่มครับ เส้นแบ่งของแต่ละกลุ่มไม่ได้อยู่ที่ว่าใครใช้ AI รุ่นไหน แต่อยู่ที่ว่าใครเป็นคนถือความต้องการ และใครเป็นคนแปลงมันให้กลายเป็นของที่ใช้ได้จริง
| กลุ่ม | รูปแบบการทำงาน | ความเร็วที่ผมสังเกต | จุดที่มักติด |
|---|---|---|---|
| 1 | Programmer คิดและเขียนเอง | เร็ว | ขอบเขตความรู้และการตัดสินใจอยู่ที่คนเดียว |
| 2 | Programmer รับคำสั่งหรือ requirement มาทำ | ช้า | ต้องถามกลับและแปลความต้องการหลายรอบ |
| 3 | User ทำ prototype แล้วส่งให้ programmer | ปานกลาง | เห็นหน้าตา แต่ behavior และเงื่อนไขอาจยังไม่ครบ |
| 4 | User สร้าง prototype หรือระบบเอง แล้วให้ programmer เป็น consultant | เร็ว | ต้องมีคนช่วยดู architecture และข้อจำกัดที่ user อาจไม่เห็น |
| 5 | User สั่ง AI และสร้างโปรแกรมเองได้ | เร็วที่สุดในบางงาน | ต้องมีพื้นฐานพอจะตรวจสิ่งที่ AI ทำ |
กลุ่มแรกเข้าใจง่ายครับ Programmer รู้ความต้องการเองและลงมือเอง เมื่อมี AI ก็เหมือนได้เครื่องมือเพิ่มกำลัง เขารู้ว่าจะออกคำสั่งอย่างไร อ่านผลลัพธ์เป็น และพอเดาได้ว่าตรงไหนน่าจะมีปัญหา
กลุ่มที่สองกลับยากกว่าที่หลายคนคิด แม้ programmer จะใช้ AI เขียน code ได้เร็ว แต่กว่าจะรู้ว่าคนขออยากได้อะไรจริงๆ ยังต้องประชุม ถามกลับ เขียน requirement แตกเป็น function แล้วแปลงต่อเป็น technical spec กว่าจะเริ่มเขียนได้ เครื่องมือเร็วขึ้น แต่รถยังติดอยู่หน้าด่านเดิมครับ
AI ทำให้มือของ programmer เร็วขึ้น แต่ยังไม่ได้ทำให้คนสองคนเข้าใจกันเร็วขึ้นเสมอไป
Prototype เปลี่ยนการคุยจากคำอธิบายเป็นของที่มองเห็น
กลุ่มที่สามคือ user ทำ prototype แล้วส่งให้ programmer ทำต่อ แบบนี้เร็วขึ้นกว่าส่ง requirement หรือ wireframe อย่างเดียวเยอะครับ เพราะ programmer เห็นหน้าจอ เห็น flow และเห็นว่าคนขอพยายามแก้ปัญหาอะไรอยู่
แต่ prototype ก็ยังมีช่องว่างของมัน หน้าจอที่กดได้อาจบอกว่า user ต้องการอะไรเมื่อทุกอย่างปกติ แต่ไม่ได้บอกเสมอว่าถ้าข้อมูลผิดจะทำอย่างไร ใครมีสิทธิ์เห็นอะไร ระบบเดิมต้องเชื่อมแบบไหน หรือข้อมูลต้องถูกเก็บนานแค่ไหน หน้าตาชัดไม่ได้แปลว่า behavior ข้างในชัดครบครับ
ถึงอย่างนั้น ผมยังมองว่ามันดีกว่าการส่งประโยคว่า อยากได้ระบบประมาณนี้ แล้วปล่อยให้คนถัดไปจินตนาการเอง เหมือนคนหนึ่งเอาภาพห้องครัวที่ลองจัดมาแล้วไปให้ช่างดู ต่อให้ยังขาดแบบไฟกับท่อน้ำ อย่างน้อยก็ไม่ต้องเริ่มคุยกันจากคำว่า อยากได้ครัวสวยๆ 555
Prototype ที่ดีไม่ได้กำจัด requirement แต่มันลดพื้นที่ที่แต่ละคนต้องจินตนาการไม่เหมือนกัน
เมื่อ user ลงมือสร้างเอง Programmer จึงกลายเป็นที่ปรึกษา
กลุ่มที่สี่น่าสนใจมากครับ User มี prototype หรือระบบที่ทำงานได้ประมาณหนึ่งแล้ว จากนั้นให้ programmer เข้าไปเป็น consultant ช่วยดูว่าส่วนไหนควรแก้ ควรต่อกับระบบเดิมอย่างไร หรือมีความเสี่ยงอะไรที่ยังมองไม่เห็น
ผมเห็นเพื่อนร่วมงานชาวต่างชาติคนหนึ่งทำแบบนี้ เขาไม่ได้เริ่มจากพื้นฐาน programmer เต็มตัว แต่เป็นคนเรียนรู้เร็ว ชอบศึกษา และมีความสามารถในการตั้งคำถาม เขาสร้างของออกมาได้ระดับหนึ่งแล้วมาปรึกษา programmer เพิ่มอีกไม่มาก จากนั้นก็กลับไปต่อยอดสิ่งที่ตัวเองต้องการได้
ลักษณะนี้ใกล้กับการมี programmer ยืนอยู่ข้างๆ มากกว่านั่งรอรับเอกสารปลายทาง บทบาทของ programmer จึงไม่ใช่คนพิมพ์ code ตามแบบ แต่เป็นคนช่วยชี้ blind spot ตั้งคำถามเรื่อง architecture, data, security และช่วยตรวจว่าของที่วิ่งได้บนเครื่อง จะไปต่อใน production ได้หรือไม่
มันมีส่วนคล้ายแนวทางของ Forward Deployed Engineer (FDE) ซึ่งเป็น engineer ที่เข้าไปทำงานใกล้กับผู้ใช้หรือทีมลูกค้า ช่วยค้นหาความต้องการ สร้าง prototype ปรับระบบ และนำไปใช้ในสภาพแวดล้อมจริง แทนที่จะรับ spec แล้วหายกลับไปเขียนอยู่คนเดียว คำอธิบายบทบาท FDE จาก DataCamp
User เขียนโปรแกรมเองได้ ทำไมถึงเร็วที่สุด
กลุ่มที่ห้าคือ user สร้างโปรแกรมเอง เขารู้ปัญหา รู้ว่าต้องการอะไร และสั่ง coding agent ให้ช่วยสร้างสิ่งนั้นได้โดยตรง ระยะทางจากความคิดไปถึงของที่กดได้จึงสั้นมาก ไม่ต้องผ่านคนกลางหลายทอด
เจ้านายผมเป็นอดีต programmer พอได้รื้อฟื้นพื้นฐานเดิมร่วมกับ AI เขาก็ไปต่อได้เร็ว เพราะยังมี foundation พอจะเข้าใจว่า code, database, API และ flow ของระบบเกี่ยวกันอย่างไร เขาอาจจำ syntax ไม่ครบ แต่ syntax กลายเป็นเรื่องที่ AI ช่วยได้แล้ว
ตรงนี้มีเงื่อนไขสำคัญครับ User ที่สร้างเองได้เร็ว ไม่ได้แปลว่าไม่ต้องรู้อะไรเลย อย่างน้อยต้องมีพื้นฐานทาง programming หรือมีความสามารถพอจะตรวจสอบ ตั้งคำถาม และรู้ว่าเมื่อไรควรเรียกคนที่มีประสบการณ์เข้ามาช่วย ไม่อย่างนั้นความเร็วอาจพาไปถึงของที่ดูเหมือนใช้ได้ แต่มีปัญหาอยู่ข้างในแบบที่เจ้าตัวไม่รู้
วันหนึ่ง คนที่ทำโปรแกรมได้ดีที่สุดอาจจะไม่ใช่มาจากโปรแกรมเมอร์ที่เก่งที่สุด แต่จะเป็น User ที่ใช้เอไอเขียนโปรแกรมได้เองตามที่ธุรกิจต้องการ
ทำไมมี AI แล้ว process เดิมยังช้า
ในกระบวนการพัฒนา software แบบเดิม ความต้องการจาก user มักต้องผ่าน Product Owner, Business Analyst, System Analyst หรือตำแหน่งอื่นตามโครงสร้างของแต่ละองค์กร คนเหล่านี้ช่วยแปลง idea ให้เป็น requirement, function, design และเอกสารที่ programmer ใช้ทำงานต่อ
จากนั้น requirement ยังอาจต้องถูกแปลงอีกรอบเป็น technical spec, API contract, application design, data model และงานย่อยต่างๆ แต่ละทอดมีทั้งเวลารอ เวลาคุย และความหมายบางส่วนที่อาจหายระหว่างทาง เหมือนเกมกระซิบที่ทุกคนตั้งใจดี แต่ประโยคปลายทางไม่เหมือนต้นทางเสียทีเดียว
ถ้า workflow ยังเป็น user อธิบายให้คนกลาง คนกลางเขียนเอกสาร แล้ว programmer เอาเอกสารไปสั่ง AI ความเร็วจะเพิ่มชัดเจนเฉพาะช่วงเขียน code ครับ ช่วงคิด ตัดสินใจ ขอข้อมูล ทำ spec และรอความเห็นยังใช้เวลาใกล้เคียงเดิม
AI อาจช่วยเขียนเอกสารให้ละเอียดขึ้น แต่เอกสารเยอะไม่ได้รับประกันว่าคนจะอ่านครบ สุดท้าย programmer อาจใช้ AI อ่านเอกสารอีกที ถ้าเอกสารต้นทางสื่อความต้องการผิด AI ก็เพียงช่วยอ่านความเข้าใจผิดนั้นให้เร็วขึ้น แล้วผลิตของที่ไม่ตรงเร็วขึ้นตามไปด้วย เจ็บปวดแบบประสิทธิภาพสูง ฮาาา
ถ้าความเข้าใจต้นทางผิด AI จะไม่ได้แก้ปัญหาให้เรา มันอาจช่วยขยายความผิดนั้นให้กลายเป็นระบบได้เร็วกว่าเดิม
อนาคตอาจเหลือ workflow หลักอยู่ 2 แบบ
จากสิ่งที่ผมเห็นภายในเวลาไม่ถึงปี ผมคิดว่า 5 กลุ่มนี้จะค่อยๆ ขยับเข้าหากัน และเหลือ workflow เด่นอยู่ประมาณ 2 แบบครับ
แบบแรก User สร้างเอง แล้วให้ Programmer ช่วยไกด์
User ใช้ AI ทำ prototype หรือระบบที่ทำงานได้เอง ส่วน programmer เข้ามาช่วย review, consult และจัดการเรื่องที่ต้องใช้ความรู้ลึก วิธีนี้ทำให้คนที่รู้ความต้องการที่สุดได้ทดลองของเร็ว และยังมีคนช่วยกันไม่ให้ prototype หลุดไปเป็น production แบบไม่มีรั้ว
แบบที่สอง User ทำ Prototype ที่ชัด แล้วให้ Programmer ทำต่อ
User ไม่จำเป็นต้องเขียนระบบจนเสร็จ แต่ควรนำความต้องการไปให้ไกลกว่าคำอธิบาย ทำ flow, UI และ behavior หลักให้เห็นจริง จากนั้น programmer เข้าไปประกบและทำให้เป็นระบบที่ใช้งานได้ วิธีนี้คล้ายการทำงานแบบ FDE ในมุมที่ engineer อยู่ใกล้ปัญหาและ feedback มากขึ้น
สองแบบนี้ลดจำนวนครั้งที่ความต้องการต้องถูกแปลครับ จากประสบการณ์การคุมงาน วางแผน และทำ project management ของผม ผมเชื่อว่ามันทำให้การพัฒนาเร็วกว่า process เดิมได้มาก และในบางกรณีอาจเกินเท่าตัว แต่ตัวเลขนี้เป็นข้อสังเกตจากงานที่ผมเห็น ไม่ใช่ benchmark ที่ใช้แทนทุกทีม
บทสรุป
สิ่งที่ผมตกผลึกวันนี้คือ AI ไม่ได้ทำให้คอขวดของการพัฒนา software หายไปครับ มันย้ายคอขวดจากการพิมพ์ code ไปอยู่ที่การรู้ความต้องการ การอธิบายให้ชัด และการตรวจว่าสิ่งที่สร้างตรงกับปัญหาจริงหรือไม่
เมื่อก่อนคนที่มี idea ต้องรอให้หลายบทบาทช่วยแปล idea นั้นจน programmer เริ่มลงมือได้ วันนี้ user สามารถใช้ AI ทำให้ความคิดกลายเป็นของที่เห็นและทดลองได้เร็วขึ้น ระยะห่างระหว่างคนที่เจอปัญหากับคนที่สร้างคำตอบกำลังสั้นลงมาก
ผมไม่ได้คิดว่า programmer จะหายไป แต่ตำแหน่งของ programmer ใน workflow จะเปลี่ยน จากคนที่รอรับ requirement ปลายทาง ไปเป็นคนที่เข้าใกล้ user มากขึ้น ช่วยถาม ช่วยไกด์ ช่วยตรวจ และจัดการส่วนที่ความเร็วอย่างเดียวเอาไม่อยู่
สุดท้ายทีมที่ได้ประโยชน์จาก AI มากที่สุดอาจไม่ใช่ทีมที่ generate code ได้เยอะที่สุด แต่เป็นทีมที่ลดจำนวนครั้งของการแปลความต้องการลงได้มากที่สุดครับ