Grok Bot được công bố chỉ 7 tuần sau khi nhóm viết những dòng mã đầu tiên. Nhóm phát triển cho biết thống nhất tính năng nào nên đưa vào sản phẩm còn khó hơn việc lập trình.
Kỹ sư Lauren Tan của SpaceXSI và Roman Ugarte, thành viên nòng cốt của nhóm Grok Bot, đã chia sẻ về quá trình phát triển và cách sử dụng sản phẩm trong podcast Lightcone của Y Combinator, phát hành ngày 14.
Grok Bot là sản phẩm dạng thành viên nhóm AI, cho phép người dùng giao việc bằng cách chỉ định tên, vai trò và công cụ cho bot. Ugarte cho biết nhóm muốn áp dụng cách các nhà phát triển giao việc lập trình cho AI vào những bộ phận khác trong công ty.
Ugarte nêu ba nguyên tắc thiết kế: tổ chức công việc xoay quanh bot thay vì hội thoại hay tệp; trang bị cho mỗi bot một máy tính riêng cùng các công cụ con người sử dụng; và thiết kế để bot hoạt động liên tục, tự đề xuất ý tưởng thay vì chờ chỉ thị.
Nhóm cho biết đã phát hành sản phẩm ra bên ngoài sau khi cả nhân viên quen lẫn chưa quen với AI đều phản hồi tốt trong đợt thử nghiệm nội bộ. Nhóm cũng tính đến kết quả sử dụng bot trong công ty khi quyết định ra mắt.
Ugarte nói người dùng thường bắt đầu bằng việc giao cho bot những việc nhỏ, rồi cấp thêm công cụ nếu kết quả tốt. Công việc sau đó mở rộng từ từng nhiệm vụ sang các mục tiêu, và cuối cùng người dùng có thể giao cho bot cả một quy trình công việc.
Nhóm tiếp thị cấp cho bot quyền truy cập vào tài khoản quảng cáo Google và Facebook cùng ngân sách. Bot phối hợp với bot của nhóm thiết kế để thử nghiệm A/B nhiều mẫu quảng cáo.
Ở bộ phận hỗ trợ khách hàng, bot có thể tái hiện vấn đề dựa trên báo cáo của người dùng và xử lý một số yêu cầu từ đầu đến cuối nếu được cung cấp công cụ cần thiết. Công việc bot có thể đảm nhận tùy thuộc vào công cụ và quyền truy cập được cấp. TokenPost từng đưa tin về cách Grok quản lý các kết nối của AI theo nhiệm vụ, gồm phạm vi truy cập và quy trình phê duyệt.
Khoảng hai tuần trước, nhóm cũng ra mắt tính năng bot nhóm, cho phép chia sẻ bot do một cá nhân tạo với đồng nghiệp. Các bot có thể trao đổi với nhau và phân chia công việc.
Bot kỹ sư “Potato” của Tan từng hỏi bot phụ trách kho dữ liệu về số liệu người dùng trong một luồng thảo luận trên Slack. Các thành viên trong nhóm có thể theo dõi quá trình này. TokenPost trước đó đã đưa tin về việc bot Grok của nhóm phân tích dữ liệu trả lời câu hỏi nội bộ qua kết nối chỉ đọc.
PR là yêu cầu gửi mã đã chỉnh sửa để được xem xét và hợp nhất. Người dẫn podcast nhắc rằng số PR mà Tan từng mô tả ở mức hơn 2.000 mỗi tháng hiện đã vượt 4.000; Tan xác nhận con số này. Đây là số yêu cầu thay đổi mã, không phải số tính năng đã được phát hành.
Tan nói: “Tôi dùng quy trình tự động hóa của mình cho bảo trì phần mềm, thay vì phát triển tính năng mới”. Bà cho biết tự động hóa được dùng để sửa lỗi và cải thiện hiệu suất.
Tan cũng kể về một tính năng mới được bà và đồng nghiệp Samantha phát triển trong một luồng công khai trên Slack. Sau khi Tan trình bày ý tưởng, bot gọi tác nhân đám mây của Cursor để tạo nguyên mẫu. Các thành viên trong nhóm trao đổi ý kiến khi xem video và hình ảnh được chia sẻ trong cửa sổ trò chuyện.
Tan nói: “Trong công việc này, tôi thậm chí không mở Cursor. Mọi thứ đều được xử lý trong cuộc trò chuyện trên Slack”. Đây là ví dụ về việc nhóm xem xét nguyên mẫu ngay trong cuộc trò chuyện mà không cần mở trực tiếp công cụ phát triển.
Ugarte cho biết nhóm nhận được hàng nghìn phản hồi mỗi ngày qua sản phẩm, kênh hỗ trợ khách hàng và X. Với các lỗi nhỏ, nhóm dùng quy trình tự động hóa để tái hiện, sửa lỗi rồi đưa thay đổi vào mã.
Các tính năng làm thay đổi giao diện mà người dùng nhìn thấy mỗi ngày phải đáp ứng tiêu chí phát hành khác. Ugarte cho biết nhóm dùng thử kỹ tính năng mới trong nội bộ và có thể quyết định không phát hành ngay cả khi tính năng đã hoàn thiện nếu phản hồi không tốt.
Ugarte nói: “Nút thắt là sự thống nhất trong nhóm về những gì nên đưa vào lộ trình sản phẩm và cách đánh giá một kết quả tốt”. Ông cho rằng nếu gộp mọi tính năng vào cùng lúc, sản phẩm có thể tạo cảm giác rời rạc.
Comment 0