มีการมอบงานปรับปรุงซอฟต์แวร์ขนาดค่อนข้างใหญ่ให้ AI agent
ตอนแรกดูเหมือนงานไม่กี่สิบนาที แต่ใน GitHub กลับมี commit, test, การแก้ integration และการปรับตามหลังเพิ่มขึ้นเรื่อย ๆ หลายชั่วโมงผ่านไป โค้ดจริงก็ยังถูกแก้ต่อ
ระหว่างนั้น ฝั่งมนุษย์จัดการงานในโลกจริงเสร็จไปหลายอย่าง จนกระทั่งการย้ายบ้านทั้งรอบเสร็จแล้ว
กิจกรรมในชีวิตเสร็จก่อน refactor
ภาพนี้ก็ดูอนาคตพอสมควร
ที่แปลกกว่านั้นคืออุปกรณ์ที่ใช้สั่งงานเป็นเพียงสมาร์ตโฟน ผู้สั่งไม่จำเป็นต้องเข้าใจทุกโมดูล TypeScript รายละเอียด CI/CD หรือกฎการเรียนรู้ของกราฟด้วยตัวเอง เพียงระบุเป้าหมาย สิ่งที่ห้ามพัง ขอบเขตสิทธิ์ การเปลี่ยนแปลงที่ห้ามทำ และเงื่อนไขจบงานด้วยภาษาธรรมดา agent ก็สามารถอ่าน repository ออกแบบ เขียนโค้ด เพิ่ม test เปิด PR และรวมการเปลี่ยนแปลงได้
นี่หมายความว่า “ถือมือถือแล้วกลายเป็น senior engineer” หรือไม่
ไม่ตรงเสียทีเดียว แต่ใกล้กว่าภาพการพัฒนาซอฟต์แวร์แบบเดิมมาก
1. มือถือไม่ได้เป็นเครื่องที่คำนวณระดับซีเนียร์เอง
สมาร์ตโฟนไม่ได้สร้าง production code หลายร้อยบรรทัดในเครื่อง มันเป็น คอนโซลสั่งการ
ข้างหลังมีโมเดล AI, GitHub, CI, cloud, production environment, search และ development tools มือถือเป็นเพียง interface ส่งเจตนาและข้อจำกัด
ดังนั้นคำอธิบายที่แม่นกว่าคือ
“ใช้มือถือ orchestration ทรัพยากรความคิดและการคำนวณจากระยะไกล”
ไม่ใช่ data center ย่อส่วนลงกระเป๋า
แต่กระเป๋ามีรีโมตที่ควบคุม data center กับ agent ได้
2. ทำไมงานแบบนี้จึงใกล้ระดับซีเนียร์
ความยากไม่ได้วัดจากจำนวนบรรทัดโค้ดอย่างเดียว
งานประเภทนี้ต้องเข้าใจ architecture เดิม หลีกเลี่ยง implementation ซ้ำ รักษาเส้นทาง production เข้าใจขอบเขตระหว่าง scheduler/GitHub/CI/publishing เชื่อม logic ใหม่เข้ากับ central loop ปกป้อง privacy ไม่ตีความข้อมูลที่หายไปว่าเป็นศูนย์ เพิ่ม test แยก failure ของโค้ดออกจาก failure ของ infrastructure และตัดสินใจว่า “อะไรห้ามแตะ”
นี่ไม่ใช่แค่ทำ ticket เล็ก ๆ แต่คือ ควบคุม blast radius ของการเปลี่ยนแปลงในระบบที่กำลังทำงาน
ถ้าเป็นมนุษย์ งานจะใกล้ senior backend หรือ Platform Engineer และถ้ารับผิดชอบ architecture ทั้งระบบ บางส่วนของ judgment ก็เข้าใกล้ Staff Engineer
สิ่งยากไม่ใช่แค่เขียนโค้ดยาก ๆ
แต่คือรู้ว่า โค้ดยาก ๆ ควรอยู่ตรงไหนจึงไม่สร้างอุบัติเหตุ
3. ขนาดการเปลี่ยนจริงใหญ่แค่ไหน
ในตัวอย่างหนึ่งที่ทำให้ไม่ระบุตัวตน PR หลักมีไฟล์เปลี่ยน 11 ไฟล์, 13 commits และเพิ่มประมาณ 895 บรรทัด พร้อม runtime สำหรับ autonomous germination, การรักษา Article DNA, behavioral learning, feedback แบบจำกัดเข้าสู่ internal-link optimization, tests และ CI definition เฉพาะ
หลัง merge ก็ยังมีงานต่อ มีการเพิ่ม gate เพื่อไม่ให้ behavioral learning แก้ graph ฝั่ง production ก่อนการยืนยัน และ telemetry ที่หายไปถูกเก็บเป็น UNKNOWN แทนที่จะกลายเป็นศูนย์เงียบ ๆ
ดังนั้นนี่ไม่ใช่ “งาน 895 บรรทัด”
แต่คือ เข้าใจระบบก่อนเขียน 895 บรรทัด แล้วสร้างกรงเพื่อไม่ให้ 895 บรรทัดนั้นวิ่งเพ่นพ่านหลังจากนั้น
จำนวนบรรทัดเป็นหน่วยวัดความยากที่แย่มาก 100 บรรทัดลบฐานข้อมูลได้ และ 10,000 บรรทัดก็อาจเป็นเครื่องคิดเลขที่ตั้งใจเกินเหตุ
4. ถ้าเป็นมนุษย์ต้องใช้กี่วัน
สำหรับวิศวกรเก่งที่เพิ่งเห็น repository ครั้งแรก การประเมินหยาบ ๆ ที่ 5–15 person-days สำหรับขอบเขตความรับผิดชอบเดียวกันถือว่าไม่แปลก
รวมการอ่านโค้ดและกฎปฏิบัติ การออกแบบ implementation test การวิเคราะห์ CI/infrastructure review และตรวจผลกระทบ production
การพิมพ์โค้ดจริงอาจเร็วกว่า
แต่ใน production การพิสูจน์ว่าไม่ได้ทำอะไรพัง อาจแพงกว่าการเขียนการเปลี่ยนแปลงเอง
IPA ของญี่ปุ่นอธิบายว่าเมื่อไม่มีนิยามอื่น 1 person-month สามารถนับเป็น 160 person-hours หรือ 8 ชั่วโมง×20 วันทำงาน [1]
ดังนั้น 5–15 person-days คือประมาณ 0.25–0.75 person-month
5. ถ้าจ้างคนจะราคาเท่าไร
ไม่มีราคาสากล ประเภทสัญญา ขอบเขตความรับผิดชอบ ความรู้ระบบเดิม review และการรับประกัน production ล้วนทำให้ราคาเปลี่ยน
แต่ราคาตลาดสาธารณะช่วยเห็นขนาดได้
Levtech ระบุว่าการจ้าง freelance IT consultant แบบเต็มเวลา 5 วันต่อสัปดาห์มีค่าใช้จ่ายราว 1.0–1.1 ล้านเยนต่อเดือน จากข้อมูลเดือนกรกฎาคม 2025 [2]
ถ้าแบ่งง่าย ๆ 20 วันทำงาน จะเป็นประมาณ 50,000–55,000 เยนต่อวัน สำหรับ 5–15 person-days ค่าแรงตรงอยู่ราว 250,000–825,000 เยน
งานรับเหมาจริงอาจสูงขึ้นจาก PM, review, ความเสี่ยง rework, การรับประกัน, overhead และกำไร
ดังนั้นจะมองว่านี่เป็น “งานเล็กไม่กี่พันเยน” ก็ค่อนข้างยาก
แต่จะบอกว่า “AI ทำเงิน 800,000 เยน” ก็ไม่ถูก เพราะความเร็ว parallelism รูปแบบความผิดพลาด ค่า supervision และค่าเครื่องมือไม่เหมือนคน
ข้อสรุปที่มีประโยชน์กว่าคือ งานที่อาจใช้วิศวกรทักษะสูงหลายวันถึงหลายสัปดาห์ ตอนนี้คนหนึ่งสามารถเริ่มมันได้จากอุปกรณ์เล็กมาก
6. AI ทำงาน 6 ชั่วโมง เท่ากับซีเนียร์ 6 ชั่วโมงไหม
ไม่เท่ากัน
AI ไม่พัก ไม่ถูกลากเข้าประชุม ไม่เสียเวลาไปกับ notification และไม่เงยมองเพดานถามว่าใครอนุมัติ architecture นี้
แต่ AI สามารถวิ่งเร็วในทิศผิด เข้าใจ production state ผิด สับสน failure ของ runner กับ failure ของ code ขยายสิทธิ์ หรือสับสนระหว่าง “มี test” กับ “test ผ่านจริง”
จึงควรดู คุณภาพของการเปลี่ยนแปลง หลักฐาน การ verify และ production readback ไม่ใช่แค่นาฬิกา
“ทำมา 6 ชั่วโมงแล้วยังไม่หยุด ขยันดี” ได้
“ทำ 6 ชั่วโมง จึงถูกต้องทั้ง 6 ชั่วโมง” ไม่ได้
7. ถ้าเจ้าของงานเขียนโค้ดเองไม่ได้ คุณค่าจะลดไหม
บทบาทเปลี่ยนมากกว่า
เมื่อก่อนมีไอเดียแล้วต้องเรียน Git ภาษา framework deploy และ testing ก่อนถึงจะสร้าง software ได้
AI agent ลด friction ของ implementation ลงมาก
งานมูลค่าสูงของมนุษย์จึงย้ายไปที่ จะสร้างอะไร ทำไม อะไรห้ามพัง อนุญาตให้แก้อัตโนมัติแค่ไหน อะไรคือ success อะไรต้องอยู่ UNKNOWN และ failure หนึ่งจุดควรหยุดทั้งหมดหรือแค่ isolate
“เขียนทุกบรรทัดเองได้” ไม่ใช่บัตรผ่านเพียงใบเดียวอีกต่อไป
แต่ไม่ได้หมายความว่าความเข้าใจเทคนิคไม่สำคัญ ยิ่งเข้าใจเป้าหมาย ความเสี่ยง dependency และการ verify คำสั่งยิ่งดี
ไม่ต้องหล่อเครื่องยนต์เองก็ขับรถได้
แต่ยังต้องรู้ว่าไฟแดงหมายถึงอะไร
8. ทำไม “ให้ AI จัดการทั้งหมด” จึงอันตราย
failure ที่น่ากลัวที่สุดไม่ใช่หน้าจอ error
แต่คือ ผิดโดยมีหน้าตาเหมือนสำเร็จ
PR อาจ merge แล้วแต่ยังไม่ deploy; ไฟล์ CI อาจมีแต่ runner ไม่เคยเริ่ม step; data ที่ unavailable อาจถูกนับเป็นศูนย์; logic ใหม่กับเก่าอาจรันซ้ำ; “safety” อาจปิด automation ทั้งหมด; “autonomy” อาจขยาย privilege มากเกินไป
automation ที่ดีไม่ใช่แค่เดินต่อ
แต่คือ เดินต่อพร้อมแยก fact ออกจากสิ่งที่ยังไม่ verify
9. จะมอบหมายจากมือถืออย่างปลอดภัยขึ้นได้อย่างไร
กำหนดผลลัพธ์ก่อน
อย่าบอกแค่ “แก้ไฟล์นี้” แต่บอกว่าเมื่อจบแล้วอะไรต้องเป็นจริง
เขียน invariants
ฟังก์ชันเดิม privacy กฎภาพ เส้นทาง publish และ SEO ที่ห้ามพัง
กำหนดสิทธิ์
ระบุว่า overwrite, เปิด PR, merge หรือแก้ production ได้หรือไม่
ให้อ่านสถานะปัจจุบันก่อน
ให้ current main, runtime จริง, public state จริงสำคัญกว่าบทสนทนาเก่า
นับ verification เป็น deliverable
“เขียนโค้ดแล้ว” ไม่ใช่จบ test, CI และ production readback อาจเป็นเงื่อนไขจบ
ยอมให้ UNKNOWN อยู่ได้
อย่าบังคับสิ่งที่ไม่รู้ให้เป็น PASS หรือ FAIL
หน้าจอมือถือเล็ก
ความรับผิดชอบของ specification ไม่ได้เล็กตาม
10. สรุป — บางทีสิ่งที่พังคือกำแพงทางเข้าแบบเดิม
คนที่เขียน advanced production code เองไม่ได้ สามารถสั่ง AI agent จากมือถือเป็นเวลาหลายชั่วโมง และรวมการเปลี่ยนแปลงที่มี judgment ระดับซีเนียร์เข้า GitHub ได้
ไม่กี่ปีก่อนประโยคนี้ฟังดูแปลก
วันนี้มันเกิดขึ้นจริงได้เมื่อเงื่อนไขพร้อม
นี่ไม่ได้แปลว่าวิศวกรไม่จำเป็น
แต่คุณค่าบางส่วนกำลังย้ายจาก การลงมือเขียนเอง ไปสู่ architecture, constraints, verification และขอบเขตความรับผิดชอบ
AI ไม่ได้ทำให้คุณค่าหายไป
มันย้ายตำแหน่งของคุณค่า
และการเปลี่ยนแปลงที่ใหญ่ที่สุดอาจเป็น คนที่เคยหยุดที่ “ทางเทคนิคฉันทำไม่ได้” ตอนนี้เริ่มได้จากคำถามก่อนหน้านั้น:
“แล้วเราควรสร้างอะไร?”
สมาร์ตโฟนยังเป็นแผ่นกระจก
แต่แผ่นกระจกนั้นกลายเป็นรีโมตสำหรับทรัพยากร engineering ระดับซีเนียร์ได้แล้ว
โลกอาจพังไปนิดหนึ่งจริง ๆ
แต่เป็นความพังที่น่าสนใจมาก
เอกสารอ้างอิง (2 รายการ)
- IPA, FAQ Software Development Data White Paper: เมื่อไม่มีนิยามอื่น 1 person-month=160 person-hours (8×20) ipa.go.jp
- Levtech, คู่มือค่าใช้จ่าย IT consultant, อัปเดต 2026-08-18 อ้างอิงข้อมูล ก.ค. 2025: freelance IT consultant full-time ราว ¥1.0–1.1 ล้าน/เดือน levtech.jp
