Grok Bot เปิดตัวหลังพัฒนา 7 สัปดาห์ แม้ PR ทะลุ 4,000 ครั้งต่อเดือน แต่ทิศทางผลิตภัณฑ์ยังเป็นคอขวด

ทีมพัฒนา Grok Bot เปิดตัวผลิตภัณฑ์หลังเริ่มเขียนโค้ดได้เพียง 7 สัปดาห์ โดยระบุว่าการตกลงกันว่าจะใส่ฟีเจอร์ใดลงในผลิตภัณฑ์กลายเป็นเรื่องยากกว่าการเขียนโค้ด

ลอเรน แทน (Lauren Tan) วิศวกรของ SpaceXSI และโรมัน อูการ์เต (Roman Ugarte) สมาชิกทีมหลักของ Grok Bot เล่าถึงขั้นตอนพัฒนาและกรณีใช้งานในพอดแคสต์ Lightcone ของ Y Combinator ซึ่งเผยแพร่เมื่อวันที่ 14

Grok Bot เป็นผลิตภัณฑ์ที่ให้ผู้ใช้กำหนดชื่อ บทบาท และเครื่องมือให้เพื่อนร่วมทีม AI เพื่อมอบหมายงาน อูการ์เตกล่าวว่าทีมต้องการนำวิธีที่นักพัฒนามอบหมายงานเขียนโค้ดให้ AI ไปใช้กับแผนกอื่นในบริษัทด้วย

อูการ์เตอธิบายหลักการออกแบบไว้สามข้อ ได้แก่ จัดงานโดยมีบอตเป็นศูนย์กลางแทนการใช้บทสนทนาหรือไฟล์ ให้บอตมีคอมพิวเตอร์ของตัวเองพร้อมเครื่องมือที่คนใช้ และออกแบบให้ทำงานต่อเนื่องโดยไม่ต้องรอคำสั่ง พร้อมเสนอแนวคิดได้

ทีมเปิดเผยว่าได้ทดลองใช้ภายในก่อน โดยพนักงานทั้งที่คุ้นเคยกับ AI และไม่คุ้นเคยต่างตอบรับในทางที่ดี จากนั้นจึงนำผลการใช้งานภายในมาประกอบการตัดสินใจเปิดตัวต่อสาธารณะ

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

ทีมการตลาดให้บอตเข้าถึงบัญชีโฆษณา Google และ Facebook พร้อมกำหนดงบประมาณ บอตทำงานร่วมกับบอตของทีมออกแบบเพื่อทดสอบชิ้นงานโฆษณาหลายแบบด้วย A/B testing

ในทีมสนับสนุนลูกค้า บอตใช้รายงานจากผู้ใช้จำลองปัญหา และจัดการคำถามบางส่วนได้ตั้งแต่ต้นจนจบเมื่อมีเครื่องมือที่จำเป็น งานที่มอบหมายได้จึงขึ้นอยู่กับเครื่องมือและสิทธิ์ที่ให้บอตไว้ ก่อนหน้านี้ TokenPost เคยรายงานกรณีการจัดการคอนเน็กเตอร์ของ Grok ซึ่งเกี่ยวข้องกับขอบเขตการเข้าถึงบัญชีและขั้นตอนอนุมัติของ AI สำหรับงาน

ราวสองสัปดาห์ก่อน ทีมยังเปิดตัวฟีเจอร์บอตสำหรับทีม ที่ช่วยให้ผู้ใช้แชร์บอตซึ่งสร้างขึ้นคนเดียวกับเพื่อนร่วมงานได้ บอตสามารถสนทนาและแบ่งงานระหว่างกัน

บอตวิศวกรชื่อ Potato ของแทนถามตัวเลขผู้ใช้จากบอตที่ดูแลคลังข้อมูลผ่านเธรดใน Slack ทำให้สมาชิกทีมติดตามขั้นตอนการทำงานได้ ก่อนหน้านี้ TokenPost เคยรายงานกรณีทีมวิเคราะห์ข้อมูลใช้การเชื่อมต่อแบบอ่านอย่างเดียวให้บอต Grok ตอบคำถามภายในบริษัท

PR หรือคำขอให้ตรวจสอบและรวมโค้ดที่แก้ไข คือรายการส่งงานเพื่อขอทบทวนและนำโค้ดเข้าโครงการ ผู้ดำเนินรายการกล่าวว่า PR ซึ่งแทนเคยระบุว่ามีเดือนละราว 2,000 รายการ เพิ่มเป็นมากกว่า 4,000 รายการในปัจจุบัน และแทนยืนยันตัวเลขดังกล่าว ตัวเลขนี้สะท้อนปริมาณคำขอเปลี่ยนแปลงโค้ด ไม่ใช่จำนวนฟีเจอร์ที่เปิดตัว

แทนกล่าวว่า “ผมใช้เวิร์กโฟลว์อัตโนมัติเพื่อดูแลซอฟต์แวร์ มากกว่าจะใช้สร้างฟีเจอร์ใหม่” โดยอธิบายว่าเขาใช้ระบบอัตโนมัติแก้ข้อผิดพลาดและปรับปรุงประสิทธิภาพ

แทนยังเล่าถึงกรณีที่เขากับเพื่อนร่วมงานชื่อซาแมนธา (Samantha) สร้างฟีเจอร์ใหม่ผ่านเธรดสาธารณะใน Slack หลังแทนอธิบายแนวคิด บอตเรียกใช้เอเจนต์คลาวด์ของ Cursor เพื่อสร้างต้นแบบ ทีมงานแลกเปลี่ยนความคิดเห็นโดยดูวิดีโอและภาพที่แชร์ไว้ในหน้าสนทนา

แทนกล่าวว่า “งานนี้ผมไม่ได้เปิด Cursor เลย ทุกอย่างจัดการผ่านบทสนทนาใน Slack” กรณีนี้แสดงให้เห็นว่าทีมสามารถตรวจดูต้นแบบผ่านการสนทนาภายในได้โดยไม่ต้องเปิดเครื่องมือพัฒนาโดยตรง

อูการ์เตกล่าวว่าทีมได้รับความคิดเห็นจากผู้ใช้หลายพันรายการต่อวันผ่านผลิตภัณฑ์ ช่องทางสนับสนุนลูกค้า และ X ทีมใช้เวิร์กโฟลว์อัตโนมัติจำลองและแก้ข้อผิดพลาดเล็ก ๆ ก่อนนำการแก้ไขเข้าโค้ด

ฟีเจอร์ที่เปลี่ยนหน้าจอซึ่งผู้ใช้เห็นทุกวันมีเกณฑ์การเปิดตัวต่างออกไป อูการ์เตกล่าวว่าทีมจะทดลองใช้ฟีเจอร์ใหม่ภายในให้เพียงพอ และจะไม่เปิดตัวแม้ฟีเจอร์นั้นจะเสร็จสมบูรณ์แล้ว หากผลตอบรับไม่ดี

อูการ์เตกล่าวว่า “คอขวดคือการที่ทีมต้องเห็นพ้องกันว่าจะใส่อะไรลงในแผนพัฒนาผลิตภัณฑ์ และจะตัดสินอย่างไรว่าผลลัพธ์ดี” เขาอธิบายว่าการรวมทุกฟีเจอร์เข้าด้วยกันในคราวเดียวอาจทำให้ผลิตภัณฑ์ดูไม่เป็นชิ้นเป็นอัน