Startup แบบเดิม vs ทีมที่เริ่มด้วย AI agent: ช่องว่างที่ไม่ใช่แค่เร็วขึ้นนิดหน่อย

ผมเคยอยู่ในทีมที่ทำ product แบบเขียนเองทุกบรรทัด

ประชุมเรื่อง scope หนึ่งสัปดาห์ ออกแบบอีกหนึ่งสัปดาห์ เขียนโค้ดอีกหลายสัปดาห์ แล้วรอ QA อีกรอบ กว่าลูกค้าจะได้กดปุ่มแรกจริง ๆ ไอเดียตั้งต้นก็เริ่มเก่าแล้ว

ช่วงหลังผมได้เห็นอีกแบบ

ทีมเล็กสองสามคน บางทีก็คนเดียว ใช้ AI agent ช่วยงาน แล้วขึ้น MVP ที่คนจริงลองใช้ได้ในเวลาไม่กี่วัน

ตอนแรกผมคิดว่ามันคือ "เร็วขึ้นนิดหน่อย" แบบที่เครื่องมือใหม่ ๆ เคยให้เรามาตลอด

แต่ยิ่งดูก็ยิ่งรู้สึกว่าไม่ใช่ ช่องว่างนี้ไม่ใช่ 20% หรือ 30% มันห่างกันเป็นระดับ order of magnitude ในบางงาน

สองโลกที่ทำงานคนละแบบ

Startup แบบเดิม ทำงานเป็นสายพาน

hire คนให้ครบก่อน → ออกแบบ → เขียนโค้ด → QA → ship

ทุกขั้นรอคน และทุกครั้งที่ต้องแก้ ก็ต้องย้อนกลับไปต่อคิวใหม่

ทีมที่เริ่มด้วย AI agent ทำงานเป็นวง

เขียน brief → agent ร่างโค้ด → รีวิว → ทดสอบ → ปรับ brief → วนใหม่

รอบหนึ่งอาจใช้เวลาเป็นชั่วโมง ไม่ใช่เป็นสัปดาห์

สิ่งที่เปลี่ยนไปคือบทบาทของคน

จากเดิมที่เราเป็นช่างที่ต้องเดินสายไฟเองทุกเส้น ตอนนี้เราเป็น editor และ product owner มากขึ้น คือคนที่บอกว่าอะไรควรมีอยู่ อะไรยังไม่ดีพอ และอะไรควรตัดทิ้ง

ช่องว่างจริงอยู่ตรงไหน

หลายคนมองว่า AI agent คือเครื่องพิมพ์โค้ดที่เร็วขึ้น

ผมว่านั่นเป็นแค่ผิวนอก

ช่องว่างจริงคือ cycle time จากไอเดีย → demo → feedback

ทีมที่ได้ feedback จากผู้ใช้จริงสัปดาห์ละห้ารอบ จะเรียนรู้เร็วกว่าทีมที่ได้เดือนละรอบอย่างเทียบกันไม่ได้ ต่อให้ทีมหลังเก่งกว่าในเชิงเทคนิคก็ตาม

และอีกเรื่องที่ผมเห็นบ่อย คือทีมที่ยังรอ "ให้คนเก่งพอ" ก่อนจะเริ่ม

รอ hire senior ให้ได้ก่อน รอ architecture ให้นิ่งก่อน รอทุกอย่างพร้อมก่อน

ขณะที่อีกทีมเริ่มไปแล้ว ผิดไปแล้ว แก้ไปแล้วหลายรอบ

ทีมที่ชนะไม่ใช่ทีมที่มี agent ที่ฉลาดที่สุด แต่เป็นทีมที่ออกแบบ workflow รอบ agent ได้ดีที่สุด

มุมของผมในฐานะเดฟ·PM·indie

ผมเองใช้ agent ทุกวัน และอยากเล่าแบบตรง ๆ ว่ามันช่วยตรงไหน และตรงไหนที่มันช่วยไม่ได้

งานที่ผมยกให้ agent

• scaffold โปรเจกต์ใหม่ และ boilerplate ที่เขียนมาเป็นร้อยรอบแล้ว
• test case ที่รู้อยู่แล้วว่าต้องมี แต่ขี้เกียจนั่งพิมพ์
• refactor เชิงกลไก เช่น rename หรือย้ายโครงสร้างไฟล์

เมื่อก่อนงานพวกนี้กินเวลาผมทั้งคืน ตอนนี้ผมใช้เวลานั้นไปคิดเรื่องที่สำคัญกว่า

งานที่ผมยังเก็บไว้เอง

• เลือก scope ว่าอะไรต้องมีในรอบนี้ อะไรรอได้
• security และเรื่องข้อมูลของผู้ใช้
• UX ในจุดที่ผู้ใช้รู้สึกได้
• คำถามว่าลูกค้าจะจ่ายเงินให้อะไรจริง ๆ

agent ช่วยร่างคำตอบได้ แต่ judgment ยังเป็นของคน

พอแบ่งงานแบบนี้ได้ ผมเห็นว่าทีมเล็ก หรือแม้แต่คนเดียว ที่จัดระบบ agent ดี อาจทำ throughput ได้ใกล้เคียงทีมใหญ่แบบเก่าในงานบางประเภท โดยเฉพาะงาน MVP งาน internal tool หรืองานที่ requirement ชัด

ผมพูดว่า "บางงาน" นะครับ ไม่ใช่ทุกงาน

อีกด้านของช่องว่าง

ช่องว่างนี้มีสองทิศ

ทิศแรกคือทีมที่ใช้ agent เป็นแล้วนำหน้า

ทิศที่สองคือทีมที่ vibe code จนได้ของที่ดูเหมือนใช้ได้ แต่ไม่มีใครเข้าใจว่ามันทำงานยังไงใน production

ไม่รู้ว่า query ไหนช้า ไม่รู้ว่า endpoint ไหนเปิดข้อมูลเกินที่ควร ไม่รู้ว่าอีกหกเดือนจะ maintain ยังไง

ของที่สร้างได้เร็ว ก็พังได้เร็วเหมือนกัน ถ้าไม่มีระบบ review

สิ่งที่ผมทำคือ อ่านทุก diff ที่ agent เขียนก่อน merge มี test ที่รันได้จริง และถามตัวเองเสมอว่า "ถ้าโค้ดนี้พังตอนตีสาม ผมแก้มันเองได้ไหม"

ถ้าคำตอบคือไม่ได้ แปลว่าผมยังเข้าใจมันไม่พอ

เก่าไม่ได้แปลว่าแย่

ผมไม่ได้จะบอกว่า startup แบบเดิมผิด

ประสบการณ์ใน domain ความสัมพันธ์กับลูกค้า และวินัยในการ ship ของจริง เป็นสิ่งที่ agent ให้ไม่ได้ และยังมีค่ามากเหมือนเดิม

บางทีมที่ทำมาสิบปีรู้เรื่องลูกค้าลึกกว่าทีมใหม่ที่มี agent สิบตัวเสียอีก

แต่ถ้า workflow ของทีมยังไม่แตะ agent เลย ทั้งที่งานหลายอย่างเหมาะกับมัน ช่องว่างจะไม่หยุดนิ่ง

มันจะกว้างขึ้นเรื่อย ๆ ทุกไตรมาส

สรุป

ผมคิดว่าคำถามตอนนี้ไม่ใช่ "จะใช้ AI ไหม" อีกต่อไปแล้ว

คำถามที่ดีกว่าคือ

"ทีมเราออกแบบให้ agent เร่ง cycle ได้แค่ไหน โดยไม่ทิ้งคุณภาพ"

เริ่มจากเล็ก ๆ ก็ได้ครับ เลือกงานซ้ำ ๆ หนึ่งอย่างที่กินเวลาทีมทุกสัปดาห์ ลองยกให้ agent ทำ แล้ววาง review ให้ชัด

ดูว่า cycle สั้นลงแค่ไหน แล้วค่อยขยายต่อ

ช่องว่างนี้ปิดได้ แต่ไม่ได้ปิดด้วยการรอ