- Replit นิยามองค์กรที่มนุษย์เป็นผู้กำหนดเป้าหมาย ลำดับความสำคัญ และจุดแลกเปลี่ยน ขณะที่ AI agent หลายตัวรวบรวมบริบทที่จำเป็น ทำงาน ตรวจสอบ และยกระดับประเด็นว่าเป็น บริษัทขับเคลื่อนอัตโนมัติ (The Self-Driving Company)
- ไม่ได้ปล่อยให้ agent อยู่แค่ใน editor หรือเครื่องมือแชต แต่เชื่อมต่อเข้ากับระบบภายในองค์กร และมอบ agent ผู้จัดการที่รัน sub-agent หลายตัวแบบขนานให้พนักงานแต่ละคน เพื่อขยาย loop engineering ที่ทำซ้ำงานที่ตรวจสอบได้
- ตั้งแต่ต้นเดือนมกราคมถึงปลายเดือนมิถุนายน 2026 ปริมาณการมีส่วนร่วมในโค้ดทั้งหมดเพิ่มขึ้น 5.8 เท่า และผลผลิตต่อคนของกลุ่มวิศวกรเดิมเพิ่มขึ้น 2.9 เท่า แต่ความล่าช้าในการรีวิวโค้ด การ revert และ incident ไม่ได้เพิ่มขึ้น อีกทั้งเวลาที่มนุษย์ใช้รีวิว PR ลดลง 30%
- การใช้ agent แพร่ขยายไปสู่การวิเคราะห์ข้อมูล ฝ่ายขาย การตลาด และฝ่ายสนับสนุนลูกค้า ช่วยทำตัวชี้วัดและเอกสารแบบเรียลไทม์ สำรวจลูกค้าเป้าหมาย สร้างเอกสารการเปิดตัว และตรวจสอบ ticket สนับสนุน โดยเวลาที่มนุษย์ใช้แก้ ticket สนับสนุนที่ยากลดลง 60%
- เมื่อ agent ภายในมีต้นทุนต่ำกว่าและบูรณาการได้ดีกว่าเครื่องมือเชิงพาณิชย์บางตัว การตัดสินใจแบบ สร้างเองหรือซื้อ ก็เปลี่ยนไปด้วย และ Replit ต้องการนำรูปแบบการดำเนินงานนี้ไปให้ผู้ใช้ในรูปแบบที่มีการควบคุมนโยบาย สิทธิ์ ความปลอดภัย และต้นทุน
องค์กรขับเคลื่อนอัตโนมัติที่มนุษย์เป็นผู้กำหนดจุดหมาย
- บริษัทขับเคลื่อนอัตโนมัติไม่ใช่องค์กรที่ไร้มนุษย์ แต่เป็นองค์กรที่มนุษย์เลือกจุดหมาย ตัดสินใจเรื่องสำคัญ จุดแลกเปลี่ยนที่ยาก และรสนิยม พร้อมรับผิดชอบต่อผลลัพธ์
- มนุษย์ไม่ต้องลงมือทำทุกรายละเอียดเพื่อไปให้ถึงเป้าหมายเอง แต่ agent จะรับเป้าหมาย รวบรวมบริบท ทำงาน จากนั้นตรวจสอบผลลัพธ์ และยกระดับเฉพาะจุดที่ต้องใช้วิจารณญาณของมนุษย์
- Agent ของ Replit ถูกใช้ในการตรวจสอบ incident ใน production, รีวิว PR, ตอบคำถามภายในองค์กร, วิเคราะห์ข้อมูลธุรกิจ, จัดหมวดหมู่ ticket สนับสนุน, สำรวจบัญชีฝ่ายขาย และปรับปรุง Replit Agent เอง
- พนักงานมองว่าบทบาทของตนไม่ได้ถูกทำให้เป็นอัตโนมัติ แต่ได้หลุดพ้นจากงานซ้ำ ๆ และหันไปรับผิดชอบการตัดสินใจเชิงกลยุทธ์และเชิงสร้างสรรค์มากขึ้น
การเปลี่ยนแปลงที่เริ่มขึ้นเมื่อทำงานระยะยาวได้
- ตั้งแต่ปลายปี 2025 เมื่อโมเดลสามารถทำงานต่อเนื่องได้นานขึ้น การจัดหมวดหมู่ alert และการสืบหาสาเหตุรากของปัญหาที่ก่อนหน้านี้ล้มเหลวซ้ำ ๆ ก็เริ่มทำงานได้
- เมื่อ AI จัดการได้แม้กระทั่งบั๊กที่เคยแก้ยาก จึงเริ่มไม่มอง agent เป็นแค่เครื่องมือภายใน editor หรือหน้าต่างแชตอีกต่อไป แต่ผสานเข้ากับโครงสร้างการดำเนินงานของบริษัทโดยตรง
- หลังจากยืนยันผลลัพธ์ในงานวิศวกรรมแล้ว แต่ละทีมก็เริ่มส่งต่องานน่าเบื่อให้ agent ทำ ทำให้การใช้งานแพร่ไปทั่วทั้งองค์กร
โครงสร้างพื้นฐาน agent ภายในที่เชื่อมกับระบบทั้งบริษัท
- ตั้งแต่ปลายเดือนมกราคม 2026 ได้ขยายโครงสร้างพื้นฐานเพื่อให้ทดลอง use case ของ agent ภายในได้อย่างรวดเร็ว
- ใช้ agent harness, microVM และ remote filesystem ที่มีอยู่เดิม เพื่อให้วิศวกรสามารถ orchestrate agent หลายตัวแบบขนานได้
- หลังจากใช้นโยบายการเข้าถึง, token proxy, audit log และเครือข่าย ZeroTrust แล้ว จึงอนุญาตให้เข้าถึงระบบงานต่าง ๆ เช่น GitHub, GCP, Azure, Linear, Notion, Slack และ ZenDesk
- เมื่อสามารถใช้บริบทจากหลายระบบร่วมกันได้ การทดลองที่เคยล้มเหลวจึงทำได้จริง และปริมาณการผลิตโค้ดเพิ่มขึ้นอย่างรวดเร็ว
การเพิ่มขึ้นของปริมาณการผลิตโค้ดและตัวชี้วัดคุณภาพ
- ในช่วง sprint เดือนมีนาคม 2026 ระหว่างเตรียมเปิดตัว Agent 4 เส้นโค้งผลิตภาพพุ่งขึ้นไปอีกระดับเมื่อเทียบกับก่อนหน้า และเชื่อมโยงเรื่องนี้กับการนำระบบ agent ภายในมาใช้
- ตั้งแต่ต้นเดือนมกราคมถึงปลายเดือนมิถุนายน 2026 จำนวนบรรทัดโค้ดที่มีส่วนร่วมเพิ่มขึ้น 5.8 เท่า
- แม้ตัดผลจากการจ้างงานใหม่ออกและเปรียบเทียบเฉพาะกลุ่มผู้เขียนเดิม ปริมาณการผลิตโค้ดก็ยังเพิ่มขึ้น 2.9 เท่า
- ระหว่างที่ขยายขนาดทีมเป็นสองเท่า ผลผลิตต่อวิศวกรหนึ่งคนเพิ่มขึ้นราวสามเท่า
- เวลา delay ในการรีวิวโค้ดไม่ได้เพิ่มขึ้น
- Agent ประเมินระดับความเสี่ยง และเรียกมนุษย์คนที่สองมารีวิวเฉพาะเมื่อจำเป็น
- ประหยัดเวลาที่มนุษย์ใช้รีวิว PR ได้มากกว่า 30% และสัดส่วนนี้ยังคงเพิ่มขึ้น
- อัตราการ revert PR และแนวโน้มการเกิด incident ยังคงทรงตัว
- ผู้รีวิวที่เป็นมนุษย์พบ bug ได้มากขึ้นด้วยความช่วยเหลือจาก agent ที่ร่วมรีวิว
- Agent ตรวจสอบ incident ช่วยค้นหาสาเหตุราก ทำให้เวลาเฉลี่ยในการบรรเทาปัญหา (MTTM) ลดลง
- ความเร็วในการทำโปรเจกต์ให้เสร็จตามที่วัดใน Linear ก็เพิ่มขึ้นมากพร้อมกับปริมาณการผลิตโค้ด แสดงว่าโค้ดที่เพิ่มขึ้นนำไปสู่การปล่อยฟีเจอร์จริง
Loop engineering ที่รัน agent หลายตัวซ้ำ ๆ
- พนักงานทุกคนใช้ agent ผู้จัดการที่สามารถสร้าง sub-agent หลายตัวได้ และสามารถจัดโครงให้ agent หลายตัวทำงานที่ตรวจสอบได้ซ้ำ ๆ
- กรณีการใช้ swarm ของ agent เปลี่ยนสมมติฐานเดิมเกี่ยวกับความเป็นไปได้ของงาน
- ทำ migration ระบบ CSS ที่หยุดชะงักมานานให้เสร็จสมบูรณ์
- ทำ automation สำหรับ migration ที่ทำให้รองรับการแปลผลิตภัณฑ์เป็นภาษาท้องถิ่นได้
- ทำ automation สำหรับการบำรุงรักษา test ที่ไม่เสถียร
- CTO ใช้ swarm ของ agent แก้บั๊กเครือข่ายที่ยากซึ่งเกี่ยวข้องกับ PSC และการปิด file descriptor
- ทีม AI สร้าง ระบบเรียนรู้อย่างต่อเนื่อง ที่วิเคราะห์ feedback จากผู้ใช้ เสนอแนวทางปรับปรุง แล้วตรวจสอบผลด้วย benchmark และ A/B test
- ระบบนี้ทำให้ Replit Agent มีวงจรที่ปรับปรุงตัวเองตาม feedback ได้
การตัดสินใจสร้างเองหรือซื้อที่เปลี่ยนไป
- เมื่อ agent ภายในถูกบูรณาการลึกกับ knowledge base และระบบงาน พร้อมปรับแต่งให้เข้ากับบริษัท จึงเกิดกรณีที่มีประโยชน์กว่า solution เชิงพาณิชย์ภายนอก
- Replit ยกเลิกสัญญา SaaS มูลค่าเจ็ดหลักดอลลาร์ต่อปี เพราะตัดสินว่าแอปพลิเคชันที่สร้างขึ้นภายในดีกว่า และพนักงานก็ย้ายไปใช้เครื่องมือภายในแล้ว
- แม้เทียบกับผลิตภัณฑ์ภายนอกที่เชี่ยวชาญเฉพาะงาน agent ภายในก็ยังแข่งขันได้
- เครื่องมือจัดหมวดหมู่ alert และวิเคราะห์สาเหตุรากของ incident ให้คุณภาพใกล้เคียงกัน แต่มีต้นทุนรันสูงกว่า agent ภายใน 10 เท่า
- เครื่องมือ penetration testing อัตโนมัติพบช่องโหว่น้อยกว่าเวอร์ชันภายใน แต่มีต้นทุนสูงกว่า 10 เท่า
- เครื่องมือภายในทั้งสองตัวถูก deploy ใน production แล้ว ช่วยลด MTTM ของ incident และเสริมการป้องกันการโจมตีของระบบหลัก
การเปลี่ยนการวิเคราะห์ข้อมูลเป็น self-service
- เมื่อพนักงานคนอื่นเห็นวิศวกรสั่งงาน agent ใน Slack การใช้งานจึงแพร่ออกจากงานวิศวกรรม
- ช่วงแรก การใช้งานที่พบมากที่สุดคือการผสานสถานะของ knowledge base และ codebase เพื่อถามเกี่ยวกับพฤติกรรมของผลิตภัณฑ์และสิ่งที่คาดหวัง
- พนักงานสามารถตรวจสอบข้อมูลผลิตภัณฑ์และแก้ไขข้อความหรือเอกสารได้เอง โดยไม่ต้องรอคำตอบจากวิศวกร
- ทีมข้อมูลจัดเตรียม semantic layer เหนือ data warehouse เพื่อให้ agent เข้าใจตารางข้อมูลมาตรฐานและความสัมพันธ์ระหว่างตาราง
- พนักงานทุกคนสามารถได้คำตอบสำหรับคำถามด้าน business intelligence และสร้าง chart กับสไลด์นำเสนอจากข้อมูลเรียลไทม์ได้
- ทีมข้อมูลสามารถโฟกัสกับปัญหาที่ยากขึ้น แทนคำขอซ้ำ ๆ
- Product manager คนหนึ่งทำการวิเคราะห์การเปิดตัวเอง โดยผสาน event ใน codebase, วิธีที่ถูกบันทึกใน customer data platform และสถานะ subscription ที่ซับซ้อน
- Chart ทั้งหมดในบทความก็สร้างขึ้นโดยใช้ agent ภายใน
การเปลี่ยนแปลงในฝ่ายขาย/การตลาด/ฝ่ายสนับสนุนลูกค้า
- ทีมพัฒนาการขายใช้ความรู้ภายในเพื่อค้นหาและเติมข้อมูล product-qualified lead
- ใช้บริบทที่เครื่องมือฝ่ายขายทั่วไปเข้าถึงไม่ได้ เพื่อเขียน outreach ที่เฉพาะเจาะจงยิ่งขึ้น
- พนักงานฝ่ายขายสำรวจคุณค่าผลิตภัณฑ์รายลูกค้า โปรเจกต์ที่ active และปริมาณการใช้เครดิตเทียบกับสัญญาเมื่อต้องเตรียมคุยกับลูกค้า
- จัดผลการวิเคราะห์เป็นสไลด์นำเสนอแบรนด์ตามแต่ละบัญชีโดยอัตโนมัติ
- เพิ่มทั้งจำนวนและคุณภาพของ touchpoint กับลูกค้า
- ทีมการตลาดร่างข้อกำหนดผลิตภัณฑ์จาก prompt เดียว โดยอิงจากบทสนทนาและเอกสารของทีมวิศวกรรม/ผลิตภัณฑ์
- ทำให้เริ่มเตรียมการเปิดตัวได้เร็วและตามการเปลี่ยนแปลงได้โดยไม่ต้องเข้าร่วมทุกประชุม
- ใช้เวลาที่ได้กลับมาไปกับการวางแผนและงานสร้างสรรค์
- ทีมสนับสนุนลูกค้าเพิ่มทักษะการตรวจสอบปัญหาตามขั้นตอนมาตรฐานให้ agent
- Agent เสนอคำตอบในน้ำเสียงบริการลูกค้ามาตรฐาน หรือยกระดับไปยังทีมวิศวกรรมพร้อมสรุป ticket และผลการตรวจสอบ
- เวลาที่ใช้แก้ ticket ยากที่ส่งต่อมาถึงมนุษย์ลดลง 60%
สภาพแวดล้อมการทำงานขับเคลื่อนอัตโนมัติสำหรับผู้ใช้
- Replit มองว่าการดำเนินงานแบบขับเคลื่อนอัตโนมัติไม่ได้กำจัดผู้ลงมือทำ แต่เปลี่ยนไปสู่บทบาทที่กำหนดผลลัพธ์และทิศทาง
- เพื่อมอบแนวทางนี้ให้ผู้ใช้ระดับองค์กรและผู้ก่อตั้งของ Replit บริษัทกำลังพัฒนาฟีเจอร์ด้านนโยบาย สิทธิ์ ความปลอดภัย และการควบคุมต้นทุน
- เห็นว่าหากจะนำไปใช้กับผู้ใช้ที่ดำเนินธุรกิจจริง จำเป็นต้องมี guardrail ที่ขยายได้ตามขนาดองค์กร
ยังไม่มีความคิดเห็น