ลองนึกถึงรีโพซิทอรีของโครงการส่วนตัวที่เลขลำดับ Issue และ Pull Request บน GitHub กำลังเข้าใกล้เลขสี่หลัก
ปฏิกิริยาแรกมักเป็นว่า
“คนเดียวทำงานพัฒนาเกือบหนึ่งพันครั้งแล้วหรือ?”
ใกล้เคียง แต่เอาตัวเลขไปแปลตรง ๆ แบบนั้นไม่ได้ ในระบบของ GitHub ทุก Pull Request ถูกนับเป็น Issue รูปแบบหนึ่ง และหมายเลข Issue กับ Pull Request ภายในรีโพซิทอรีเดียวกันจะไม่ซ้ำกัน ดังนั้นเลขที่ใกล้ 1000 ไม่ได้หมายความว่ามี Pull Request ที่ทำเสร็จแล้ว 1000 รายการ[1]
คำถามที่น่าสนใจกว่าคือ
ถ้างานระดับนี้ ทั้งการแก้ไข ตรวจสอบ ซ่อม เผยแพร่ และดูแลระบบ ต้องให้มนุษย์ทำเกือบทั้งหมดด้วยมือโดยไม่ใช้ AI จะมีต้นทุนเท่าไร และยังคุ้มทางธุรกิจหรือไม่?
นี่เป็นคำถามสำคัญของการพัฒนาแบบคนเดียวในยุค AI
1. เลข GitHub ไม่ใช่ตัวนับจำนวนครั้งในยิม
หมายเลขในรีโพซิทอรีไม่ใช่มาตรวัดปริมาณงาน
นักพัฒนาคนหนึ่งอาจแก้ 2000 บรรทัดใน Pull Request เดียว อีกคนอาจเปิด Pull Request เพื่อแก้ CSS เพียงบรรทัดเดียว และ Issue ประเภทบั๊ก บันทึกการออกแบบ คำขอฟีเจอร์ งานสืบค้น หรือภารกิจด้านปฏิบัติการก็ใช้พื้นที่หมายเลขเดียวกัน
ดังนั้น
เลขเกือบ 1000 ไม่ได้แปลว่าเป็นงานเท่ากับคน 1000 คน
และไม่ได้แปลว่า
มีฟีเจอร์เสร็จเกือบ 1000 ฟีเจอร์
ตัวเลขนี้เหมือนตัวนับคนผ่านประตูมากกว่าตาชั่ง
อย่างไรก็ตาม ถ้าในช่วงเวลาสั้น ๆ มีการสะสมการเปลี่ยนแปลงเล็ก ๆ จำนวนมาก ประวัตินั้นก็ยังบอกสิ่งสำคัญว่า วงจร ออกแบบ → ลงมือทำ → ตรวจสอบ → แก้ไข ถูกหมุนซ้ำหลายครั้ง
ถ้าจะคิดต้นทุนมนุษย์ สิ่งสำคัญไม่ใช่ตัวเลขลำดับ แต่คือแต่ละวงจรที่มีเนื้อหาจริงใช้เวลาเฉลี่ยกี่นาที
2. ยิ่งแต่ละงานดูเล็ก ยิ่งประเมินต้นทุนมนุษย์ต่ำเกินจริงได้ง่าย
รายงานที่เผยแพร่ในเดือนกันยายน 2026 จากรายการโครงการวิศวกรฟรีแลนซ์ในญี่ปุ่นระบุว่า อัตราเฉลี่ยรายเดือนของโครงการในเดือนสิงหาคม 2026 อยู่ที่ 789,000 เยน[2]
นี่ไม่ใช่เงินเดือนของนักพัฒนาทุกคน และไม่ใช่อัตราต่อชั่วโมงของบุคคลใดบุคคลหนึ่ง แต่เป็นค่าเฉลี่ยของตลาดโครงการที่ประกาศอยู่
ถึงอย่างนั้นก็ใช้เป็นเกณฑ์หนึ่งของต้นทุนทดแทนได้ว่า ถ้าต้องซื้อกำลังวิศวกรรมระดับใกล้เคียงจากภายนอก จะอยู่ประมาณไหน
ถ้าคิด 160 ชั่วโมงต่อเดือน จะอยู่ที่ประมาณ 4930 เยนต่อชั่วโมง
คราวนี้สมมติว่ามี หน่วยการเปลี่ยนแปลงที่มีสาระ 1000 หน่วย นี่เป็นเพียงตัวอย่างสมมติ ไม่ใช่ความหมายของ GitHub #1000
| เวลาเฉลี่ยต่อการเปลี่ยนแปลง | เวลารวม | คน-เดือนที่ 160 ชม./เดือน | ต้นทุนที่ 789,000 เยน/เดือน |
|---|---|---|---|
| 15 นาที | 250 ชม. | 1.56 | ประมาณ 1.23 ล้านเยน |
| 30 นาที | 500 ชม. | 3.13 | ประมาณ 2.47 ล้านเยน |
| 45 นาที | 750 ชม. | 4.69 | ประมาณ 3.70 ล้านเยน |
| 1 ชม. | 1000 ชม. | 6.25 | ประมาณ 4.93 ล้านเยน |
| 2 ชม. | 2000 ชม. | 12.5 | ประมาณ 9.86 ล้านเยน |
| 3 ชม. | 3000 ชม. | 18.75 | ประมาณ 14.79 ล้านเยน |
| 4 ชม. | 4000 ชม. | 25 | ประมาณ 19.73 ล้านเยน |
แม้การเปลี่ยนแปลงหนึ่งครั้งจะใช้เพียง 15 นาที แต่ 1000 ครั้งก็รวมเป็น 250 ชั่วโมง
“งานแต่ละชิ้นเล็ก” ไม่ได้แปลว่า “ต้นทุนรวมเล็ก”
งานเล็กยังมีต้นทุนคงที่ เช่น การสืบค้น สร้าง branch รีวิว ทดสอบ merge ตรวจ deployment และคิดเรื่อง rollback
ถ้าคนเดียวทำทุกอย่างด้วยมือ นามบัตรอาจต้องพับหลายตอน เพราะต้องใส่ทั้งนักเขียน นักแปล frontend backend QA โครงสร้างพื้นฐาน และบรรณาธิการบริหาร
3. “ทำเองจึงไม่มีค่าแรง” อาจจริงในบัญชีเงินสด แต่ไม่ใช่เรื่องเดียวกันในการเปรียบเทียบทางเศรษฐกิจ
เว็บไซต์ส่วนตัวอาจเสียค่าโฮสต์เดือนละ 1000 เยน และมีรายได้โฆษณา 5000 เยน
ในแง่เงินสดคือกำไร 4000 เยน
แต่ถ้าเจ้าของใช้เวลา 50 ชั่วโมงต่อเดือน การเปรียบเทียบในฐานะธุรกิจต้องแยกอีกมุมหนึ่ง
อย่างน้อยควรแยกเป็น
กำไรเงินสด = รายได้ − ค่าใช้จ่ายที่จ่ายจริง
กำไรหลังปรับค่าแรง = รายได้ − ค่าใช้จ่ายที่จ่ายจริง − ชั่วโมงของเจ้าของ × ค่าแรงทดแทนที่เลือก
ถ้าเป็นงานอดิเรก การตีเวลาของตัวเองเป็นศูนย์ก็สมเหตุสมผลมาก ไม่มีใครบอกว่าเล่นเกม 50 ชั่วโมงแล้วขาดทุนค่าแรง
ปัญหาเกิดเมื่อบัญชีแบบงานอดิเรกถูกนำไปใช้เป็นหลักฐานว่าโมเดลธุรกิจทำกำไรสูง
การเรียนรู้ ความสนุก ชื่อเสียง และความพอใจจากการสร้างสิ่งของล้วนมีค่า เพียงแต่ไม่ใช่กำไรทางธุรกิจแบบเดียวกัน
เมื่อเปรียบเทียบธุรกิจ เวลาไม่หายไปเพียงเพราะไม่มีใบแจ้งหนี้
4. โมเดลโฆษณาอาจต้องการจำนวนผู้ชมมากกว่าที่คิด
สูตรง่าย ๆ คือ
รายได้โฆษณา = pageview ÷ 1000 × RPM ที่เกิดขึ้นจริง
RPM เปลี่ยนมากตามประเทศ อุปกรณ์ รูปแบบโฆษณา ฤดูกาล หัวข้อ ผู้ชม และระบบโฆษณา
ดังนั้นที่นี่จะไม่อ้างว่ามี RPM ตลาดเพียงค่าเดียว แต่ใช้ตัวเลขสมมติเพื่อดูขนาด
หากต้องการชดเชย 789,000 เยนต่อเดือนด้วยโฆษณาอย่างเดียว
| RPM สมมติ | PV ที่ต้องมีเพื่อได้ 789,000 เยน/เดือน |
|---|---|
| 100 เยน | ประมาณ 7.89 ล้าน PV |
| 300 เยน | ประมาณ 2.63 ล้าน PV |
| 500 เยน | ประมาณ 1.58 ล้าน PV |
| 800 เยน | ประมาณ 0.99 ล้าน PV |
นี่ไม่ใช่การคาดการณ์รายได้ของเว็บไซต์ใดโดยเฉพาะ
ตารางเพียงชี้ว่า ถ้าประเมินแรงงานมนุษย์ด้วยต้นทุนทดแทนระดับมืออาชีพ การคืนทุนด้วยโฆษณาอย่างเดียวอาจต้องใช้ทราฟฟิกจำนวนมาก
เว็บไซต์ที่ทำด้วยมือจึงมักพึ่งรายได้หลายแบบร่วมกัน เช่น affiliate การขายสินค้า การหาลูกค้า สมาชิก การบริจาค มูลค่าแบรนด์ หรือแม้แต่มูลค่าความสนุกของงานอดิเรก
5. AI เปลี่ยนมากกว่าความเร็วในการเขียน
ถ้ามองคุณค่าของ AI แค่ว่า “เขียนบทความได้ใน 30 วินาที” จะพลาดเศรษฐศาสตร์ส่วนใหญ่
การดูแลสื่อบนเว็บมีงานรอบข้างมากมาย
- หาเรื่อง
- ค้นคว้า
- เขียน
- ตรวจข้อเท็จจริง
- แก้โค้ด
- ทดสอบ
- ทำหลายภาษา
- เผยแพร่
- ตรวจผลจริงบนระบบผลิต
- แก้เหตุขัดข้อง
- กระจายไปโซเชียลและจดหมายข่าว
- วัดผลและปรับปรุง
ถ้าทำด้วยมือ ทุกขั้นตอนที่เพิ่มมักเพิ่มต้นทุนแรงงานผันแปร
เมื่อใช้ AI ร่วมกับระบบอัตโนมัติ ต้นทุนสร้างระบบในช่วงแรกอาจสูงขึ้น แต่ต้นทุนเพิ่มของชิ้นที่สอง ชิ้นที่สิบ และชิ้นที่ร้อยอาจลดลง
นี่ไม่ใช่แค่ “นักเขียนเร็วขึ้น”
แต่ใกล้กับว่า
คนหนึ่งสามารถเป็นเจ้าของระบบปฏิบัติการของกองบรรณาธิการขนาดเล็กและทีมวิศวกรรมขนาดเล็กได้
มนุษย์ไม่ได้หายไป
บทบาทของมนุษย์ย้ายไปสู่ข้อมูลนำเข้า การตัดสินใจ ข้อกำหนด เกณฑ์คุณภาพ การจัดการข้อยกเว้น และการกำกับดูแล
จากคนที่ผลิตทุกชิ้นด้วยมือ กลายเป็นผู้ออกแบบโรงงานและบรรณาธิการบริหาร
6. AI ไม่ใช่ไนตรัสวิเศษที่ติดแล้วเร็วขึ้นเสมอ
ผลการวิจัยน่าสนใจเพราะไม่ได้ชี้ไปทางเดียว
การทดลองแบบควบคุมที่เผยแพร่ในปี 2023 พบว่าผู้เข้าร่วมที่ใช้ GitHub Copilot ทำภารกิจสร้างเซิร์ฟเวอร์ HTTP ด้วย JavaScript ที่กำหนดไว้เสร็จเร็วกว่าอีกกลุ่ม 55.8%[3]
แต่การทดลองแบบสุ่มของ METR ในปี 2025 ให้ผลตรงกันข้าม นักพัฒนาโอเพนซอร์สที่มีประสบการณ์ 16 คนซึ่งทำงานในรีโพซิทอรีที่รู้จักมาหลายปี ใช้เวลามากขึ้นเฉลี่ย 19% เมื่ออนุญาตให้ใช้เครื่องมือ AI ช่วงต้นปี 2025[4]
ในเดือนกุมภาพันธ์ 2026 METR อธิบายว่าการทดลองถัดมาวิเคราะห์ได้ยากขึ้น นักพัฒนาจำนวนมากขึ้นไม่อยากเข้าร่วมถ้าต้องทำงานโดยไม่มี AI และการวัดเวลายากขึ้นสำหรับคนที่ใช้หลายเอเจนต์พร้อมกัน เครื่องมือรุ่นใหม่อาจให้ความเร็วเพิ่มมากกว่าช่วงต้นปี 2025 แต่ข้อมูลใหม่ยังไม่รองรับตัวเลขผลกระทบที่แม่นยำเพราะมีปัญหาการคัดเลือกและการวัด[5]
ดังนั้นข้อสรุปไม่ใช่
AI เร็วขึ้น 55% เสมอ
และไม่ใช่
AI ทำให้ผู้เชี่ยวชาญช้าลง 19%
ผลขึ้นอยู่กับลักษณะงาน ความคุ้นเคยกับโค้ด วิธีใช้เอเจนต์ ภาระรีวิว การทำงานขนาน และสภาพแวดล้อมทดสอบ
AI สร้างคำตอบที่ถูกได้เร็ว ระบบที่ออกแบบไม่ดีก็สร้างบั๊กได้เร็วเช่นกัน
ตัวเลขที่ควรใช้คือผลที่วัดจากกระบวนการจริงของตนเอง
7. เว็บไซต์ที่ทำด้วยมือไม่ได้แพ้โดยอัตโนมัติ
ระบบ AI ที่ทำงานอัตโนมัติมากไม่ได้รับประกันว่าจะทำกำไรมากกว่าเว็บไซต์แบบทำมือ
การทำด้วยมือยังสมเหตุสมผลเมื่อ
- เผยแพร่เพียงไม่กี่บทความต่อเดือน
- งานเขียนของผู้เชี่ยวชาญคือสินค้าหลัก
- บทความหนึ่งสามารถขายสินค้า/บริการมูลค่าสูง
- ไม่ต้องทำหลายภาษาและกระจายจำนวนมาก
- อัปเดตน้อย
- เจ้าของสนุกกับการทำเป็นงานอดิเรก
- หรือต้นทุนสร้างระบบอัตโนมัติสูงกว่าค่าแรงที่ประหยัดได้
ระบบอัตโนมัติมีประโยชน์มากขึ้นเมื่อ
- กระบวนการเดิมเกิดซ้ำบ่อย
- ดูแลหลายภาษา
- จำนวนเนื้อหาเพิ่มขึ้น
- ทุกครั้งต้อง QA เผยแพร่ และตรวจของจริง
- ช่องทางกระจายเพิ่มขึ้น
- มนุษย์ตรวจสิ่งเดิมซ้ำไปซ้ำมา
โดยแก่นแล้วคือการแข่งขันระหว่างต้นทุนคงที่กับต้นทุนผันแปร
โรงงาน AI อาจแพงตอนเริ่ม เวิร์กช็อปคนอาจแพงต่อชิ้น
และอย่าลืมว่า ต่อให้สร้างโรงงานอัตโนมัติสุดล้ำ ถ้าไม่มีผู้อ่านเลย มันไม่ใช่อนาคตของสื่อ แต่เป็นโกดังไฮเทคมาก
8. ถ้าจะดูความคุ้มของเว็บไซต์แบบไม่ใช้ AI ให้ถามตัวเลขเหล่านี้
ไม่จำเป็นต้องตัดสินตัวบุคคล
ถ้าต้องการเปรียบเทียบระบบ แค่ตัวเลขปฏิบัติการไม่กี่อย่างก็พอเห็นภาพมาก
- ชั่วโมงทำงานของเจ้าของต่อเดือน
- PV หรือผู้ใช้ไม่ซ้ำต่อเดือน
- รายได้และค่าใช้จ่ายเงินสดต่อเดือน
- จำนวนบทความทั้งหมดและบทความใหม่ต่อเดือน
- จำนวนภาษาที่รองรับ
- จำนวนปีที่ทำและเวลาสร้างระบบช่วงแรกโดยประมาณ
จากนั้นคำนวณได้ว่า
กำไรเงินสด = รายได้ − ค่าใช้จ่ายเงินสด
ผลตอบแทนเงินสดต่อชั่วโมงเจ้าของ = กำไรเงินสด ÷ ชั่วโมงทำงาน
กำไรหลังปรับค่าแรง = กำไรเงินสด − ชั่วโมงทำงาน × ค่าแรงเปรียบเทียบ
ต้นทุนส่วนเพิ่มต่อบทความ = เวลาและค่าใช้จ่ายเพิ่มสำหรับการเขียน + แปล + QA + เผยแพร่ + กระจาย
ตัวสุดท้ายสำคัญเป็นพิเศษ
การเคยใช้เวลา 1000 ชั่วโมงในอดีตบอกอนาคตน้อยกว่า ตอนนี้บทความถัดไปต้องใช้เวลากี่ชั่วโมง
9. จุดแข็งแท้จริงของ AI ในการพัฒนาแบบคนเดียวไม่ใช่ปริมาณ แต่คือทำซ้ำได้
การสร้างไฟล์จำนวนมากในคืนเดียวไม่ใช่ส่วนที่ยากที่สุดอีกต่อไป
ส่วนที่ยากคือทำระบบให้
- ใช้เกณฑ์คุณภาพเดิมได้ในครั้งต่อไป
- ทำซ้ำเฉพาะส่วนที่ล้มเหลว
- ป้องกันการเผยแพร่ซ้ำ
- ระบุเวอร์ชันปัจจุบันได้
- ตรวจผลจริงหลังขึ้นระบบ
- ช่องทางหนึ่งติดขัดแล้วงานอื่นยังเดินต่อ
- เฉพาะการยืนยันตัวตนที่คนต้องทำจริงเท่านั้นที่ส่งกลับให้คน
- และตรวจสอบย้อนหลังได้ว่าเกิดอะไรขึ้น
นี่ไม่ใช่แค่ปริมาณการสร้าง
มันคือ สินทรัพย์ด้านการปฏิบัติการ
เว็บไซต์แบบทำมือก็สร้างสินทรัพย์ชนิดเดียวกันได้ด้วยขั้นตอน เทมเพลต CMS สำรองข้อมูล และเช็กลิสต์
ความต่างในยุค AI คือคนคนเดียวสามารถสร้างชั้นการปฏิบัติการเหล่านี้ได้ลึกกว่าที่เคยมาก
10. สรุป: คำถามที่น่าสนใจกว่า “ถึง 1000 หรือยัง?” คือ “หน่วยถัดไปมีราคาเท่าไร?”
เลขลำดับ Issue และ Pull Request ที่ใกล้สี่หลักดูน่าตื่นตา
แต่ไม่ควรใช้เป็นคะแนนประสิทธิภาพ
ตัวเลขที่มีประโยชน์กว่าคือ
ชั่วโมงมนุษย์ ต้นทุนต่อการเปลี่ยนแปลง ต้นทุนส่วนเพิ่มต่อบทความ อัตรางานแก้ซ้ำก่อนเผยแพร่ ผลผลิตต่อชั่วโมงเจ้าของ กำไรหลังปรับค่าแรงเทียบกับรายได้
เว็บไซต์ทำมือทำกำไรได้แน่นอน
เว็บไซต์ที่ใช้ AI ก็ขาดทุนได้แน่นอน
แต่เส้นต้นทุนแตกต่างกันมาก ระหว่างโมเดลที่ให้มนุษย์ทำการเขียน แปล พัฒนา QA เผยแพร่ เฝ้าระวัง และกระจายซ้ำทุกครั้ง กับโมเดลที่ลงทุนก่อนเพื่อทำขั้นตอนเหล่านั้นให้เป็นระบบและลดต้นทุนส่วนเพิ่มในภายหลัง
เลขที่ใกล้ 1000 น่าสนใจไม่ใช่เพราะเป็นเหรียญรางวัล
คำถามที่สำคัญคือ
จากการลองผิดลองถูกเหล่านั้น มีมากแค่ไหนที่ถูกเปลี่ยนเป็นกลไกซึ่งทำให้ครั้งหน้ามนุษย์ไม่ต้องทำงานเดิมซ้ำอีก?
ตรงนั้นคือจุดที่เศรษฐศาสตร์ของการพัฒนาแบบคนเดียวร่วมกับ AI เปลี่ยนไปจริง ๆ
แหล่งข้อมูล
- GitHub Docs — Issue event types / REST API. GitHub states that every pull request is an issue, but not every issue is a pull request, and that issue and pull-request numbers do not overlap within a repository docs.github.com
- En Japan / Freelance Start, 2026-09-03. August 2026 freelance-engineer listings averaged ¥789,000 per month; 445,327 listings were included at month end. This is a marketplace listing statistic, not a universal salary or an observed cost for any person discussed in this article prtimes.jp
- Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot.” In a controlled JavaScript HTTP-server task, the treatment group completed the task 55.8% faster arxiv.org
- Becker, J., Rush, N., Barnes, B., & Rein, D. / METR (2025-07-10). “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” Sixteen experienced developers completed 246 tasks in mature repositories; allowing early-2025 AI tools increased completion time by 19% on average in this study metr.org
- METR (2026-02-24). “We are Changing our Developer Productivity Experiment Design.” METR reports that later productivity experiments suffered from participant-selection and time-measurement problems, especially as developers became reluctant to work without AI and used multiple agents in parallel; the newer data are weak evidence for the size of current speedup metr.org
