Build một Grok Bot mã nguồn mở trong một ngày

1. Rakazo: một Grok Bot mã nguồn mở, build trong một ngày

Elie Steinbock mở đầu thẳng vào việc: anh đã build Rakazo trong một ngày. Rakazo là một Grok Bot mã nguồn mở (open source), và trong video này anh sẽ cho xem anh đã làm điều đó như thế nào. Tại thời điểm quay, repo có 3.700 sao trên GitHub và 100 người đóng góp (contributor). Anh cũng sẽ cho xem cách anh bảo trì (maintain) dự án.

Anh mở danh sách pull request trên GitHub: lúc đó chỉ có 15 PR đang mở. Anh thấy con số này hơi điên rồ, vì dự án đã đóng tới 1.200 PR, và anh thậm chí không phải lúc nào cũng tự tay quản lý chuyện này.

2. Grok Bot là gì, và vì sao người ta thích nó

Với những ai chưa biết, Grok Bot là một trợ lý AI (AI assistant). Người ta rất thích nó vì nó dễ dùng: mọi thứ chỉ là một cuộc chat. Trước đây đã có rất nhiều sản phẩm trợ lý, ví dụ OpenClaw và Hermes, nhưng tất cả đều khá khó cài đặt. Điều Grok Bot và Rakazo làm rất tốt là khiến mọi thứ trở nên siêu dễ.

Một điểm rất hay là mỗi bot có máy tính riêng của nó. Elie cho xem một demo nhanh trên trang chủ: mỗi bot có một máy của riêng mình. Riêng với Rakazo, các bot có thể dùng chung một máy (shared machine), hoặc mỗi bot có máy riêng. Rồi có nhiều bot khác nhau, mỗi bot một cuộc chat, để bạn nói chuyện với từng con.

Nó cũng có sẵn những thứ như routine ngay khi cài xong (out of the box). Bạn không cần tự quản lý những thứ này bằng tay. Phần lớn thời gian bạn chỉ nói chuyện với AI của mình, chứ không phải loay hoay chỉnh từng thiết lập.

3. Miễn phí, giấy phép Apache, và người dùng nói gì

Hiện tại Rakazo hoàn toàn miễn phí. Nó là mã nguồn mở, dùng giấy phép Apache. Vì vậy Elie mời mọi người cứ tự host (self-host) nó.

Anh lướt qua phần testimonial trên trang chủ: người dùng thật sự thích nó. Một người viết rằng Hermes tốt nhưng cài đặt phức tạp hơn, còn Rakazo có workflow nhiều agent (multi-agent workflow) tốt hơn và cài đơn giản hơn. Một người khác kể họ tìm tới đây sau trải nghiệm đầu tiên với Grok Bot, rồi phát hiện ra bản thay thế này và xác nhận "công trình của bạn thật tuyệt": nó thay thế hoàn toàn Grok Bot cho họ, và app mobile cũng rất mượt.

Đó là chủ đề của video hôm nay: Rakazo được build như thế nào. Elie nhắc người xem cho dự án một sao trên GitHub và đăng ký kênh.

Anh nói đã trình bày bài này vài lần trước đây, nên anh sẽ đi theo ghi chú của mình. Đến đây đã nói xong Grok Bot là gì và vì sao người ta thích nó: điều chính là nó rất dễ dùng, mỗi bot có máy tính riêng, một máy tính thật mà bot dùng được, và nó chạy trên cả desktop lẫn mobile. Với Rakazo, nó chạy cả trên web nữa.

4. Chạy trên desktop, mobile, web, đồng bộ qua cloud

Mọi thứ chạy trên cloud và tự đồng bộ (sync). Nếu muốn bắt đầu, Elie nói bạn chỉ cần copy prompt trên trang chủ (nút "Set up with your agent") và agent của bạn sẽ tự đi cài đặt. Bạn cũng có thể tải app desktop có sẵn, và app mobile đã được đưa lên App Store; ngoài ra còn có bản Android.

Đây là một sản phẩm khá phức tạp. Theo Elie, một năm trước, nó dễ dàng đã cần một đội 20 người, có khi mất cả năm để build. Hoặc ít nhất nếu lùi lại hai năm, đây là một sản phẩm thật sự phức tạp. Vậy mà anh build được nó trong một ngày, và phần còn lại của video là cách anh làm.

5. Bản đầu tiên, và một dự án của cộng đồng

Bản đầu tiên đã chạy được. Trong README có một video cho thấy bản đầu tiên trông thế nào: app mobile chạy tốt với Expo, và app desktop là một app Electron.

Từ đó tới nay đã có rất nhiều thay đổi, vì có 100 contributor. Đây thật sự là một dự án đặt cộng đồng lên đầu (community first): rất nhiều người đóng góp và liên tục cải thiện dự án, điều mà Elie thấy thật sự rất hay.

Anh làm mã nguồn mở đã lâu. Sản phẩm chính của anh, Inbox Zero, đã tồn tại hơn ba năm, có hàng chục nghìn người đăng ký và 12.000 sao trên GitHub. Nhưng Rakazo là một con quái vật hoàn toàn khác về số lượng đóng góp đổ về. Inbox Zero được build trước làn sóng sản phẩm AI khổng lồ; nó cũng có contributor, nhưng thường bạn phải tự tay viết phần đóng góp của mình. Chỉ trong khoảng một năm trở lại đây, việc đóng góp cho một dự án mới trở nên thật sự rất dễ, và đó là điều đã xảy ra với Rakazo: rất nhiều người khác nhau gửi những pull request chất lượng cao.

6. Bốn bước trong một ngày, bắt đầu bằng plan

Vậy cụ thể anh đã build gì trong một ngày, bản Rakazo gốc ra đời thế nào? Trước hết, anh có một plan.

Elie biết nhiều người nghĩ rằng lập kế hoạch (planning) không còn cần nữa; có thể bạn không dùng Shift+Tab để vào plan mode. Anh khẳng định planning vẫn rất cần. Nếu bạn build một dự án lớn và chỉ bảo AI một câu "đi build cái này", nó nhiều khả năng sẽ bị kẹt giữa chừng. Bạn muốn xác định chính xác những gì cần build trong dự án, và đó là giai đoạn planning. Nó đặc biệt hữu ích khi bạn nhận một việc lớn như tự build Grok Bot của mình trong một ngày.

Anh tạo plan trong khoảng một tiếng.

7. Claude Design, /goal chạy qua đêm, rồi DeepSec

Sau plan, anh dùng Claude Design để làm phần UI theo đúng ý. Anh không thật sự cần sáng tạo gì ở UI, vì đã biết rõ mình nhắm tới cái gì: Grok Bot đã giải xong những quyết định UX khó, và làm cho sản phẩm đơn giản hết mức có thể.

Tiếp theo anh chạy /goal. Anh lấy cái plan lớn đã có, chạy một goal lên nó. Về cơ bản điều đó có nghĩa là AI sẽ tiếp tục làm cho tới khi mọi mục trong plan được đánh dấu xong. Thực ra anh phải chạy hai lần, nhưng lần đầu chạy qua đêm.

Sau tất cả những việc đó, anh chạy DeepSec, một dự án của Vercel. Nó soi vào dự án để tìm lỗ hổng bảo mật, nhờ vậy dự án được gia cố (harden) và được ủi phẳng thêm nữa.

8. Nguyên tắc: mọi nền tảng, mọi model

Quay lại với plan: Elie đã hình dung rất rõ mình muốn build gì.

Thứ nhất, nó phải chạy trên mobile, desktop và web. Đó là điều hiển nhiên, đơn giản vì Grok Bot chạy như vậy, và mọi thứ phải đồng bộ giữa các nền tảng. Nó phải chạy được ở bất cứ đâu bạn đang ở. Đó là cốt lõi, không phải một quyết định anh cần đưa ra.

Thứ hai, nó phải chạy với mọi model. Anh dùng Pi làm harness, trong khi với Inbox Zero, nhóm anh dùng AI SDK. Anh đã nghe nhiều điều tốt về Pi; thật lòng mà nói, nếu chọn AI SDK thì cũng ổn. Điểm chính là nó phải là một thư viện được bảo trì đều đặn, và phải chạy được với mọi nhà cung cấp model. Anh phải dùng được gói đăng ký ChatGPT, một dịch vụ API trung gian cho model, một Claude API key, bất cứ thứ gì bạn nghĩ ra cũng phải chạy được, kể cả LLM chạy local.

Điều này rất quan trọng với anh, vì nếu không mang lại sự linh hoạt này thì dự án còn ý nghĩa gì nữa. Ý nghĩa của dự án là nó mã nguồn mở, mọi người tự chạy được, nó cho bạn sự linh hoạt tối đa và không ép bạn phải gắn chặt (buy in) vào một stack cụ thể nào. Với Inbox Zero anh đã thấy sức mạnh của việc cho phép linh hoạt tối đa, nên ngay từ ngày đầu anh biết mình muốn điều đó cho Rakazo.

9. Mọi sandbox, mọi thư viện integration, không phụ thuộc bên thứ ba

Nếu bạn muốn chạy nó trên AWS hay trên Hetzner, hay muốn dùng Claude, hay muốn dùng một sandbox provider như Daytona, E2B hoặc Box, tất cả phải chạy ngay khi cài xong. Đó là nguyên tắc thứ hai: chạy được với mọi sandbox provider. Elie nói thêm Box thực ra đã đổi tên thành Boat; anh có một video khác về họ, đáng xem, và giá của họ rất hợp lý. (Trên README của Rakazo lúc này vẫn ghi tên Box.)

Rồi tới thư viện integration. Grok Bot có thể kết nối tới hàng nghìn API và MCP tool khác nhau, và có vài thư viện cho phép làm việc đó: một là Composio, một lựa chọn khác là Pipedream, còn vài cái khác nữa. Anh cũng không muốn dự án bị trói vào bất kỳ cái nào trong số đó. Một người tự host Rakazo không nên bị bắt phải dùng Composio mới bắt đầu được. Lại là nguyên tắc linh hoạt tối đa: Rakazo không phụ thuộc vào bất kỳ dịch vụ bên thứ ba nào.

Elie lưu ý thêm: nếu bạn lên plan cho sản phẩm theo cách này từ đầu, bạn có thể build nó thật tốt để giải trước những vấn đề sẽ gặp về sau. Ví dụ bạn build sản phẩm cho E2B ngay từ đầu, rồi sau đó lại muốn chuyển sang Boat hoặc thêm hỗ trợ Boat, việc đó có thể khó, ít nhất là trước đây thì khó. Nhưng nếu ngay từ ngày đầu bạn biết mọi thứ nằm sau một interface và bạn không bị trói vào provider nào, những việc này trở nên dễ hơn nhiều.

Điều này được ghi trong file AGENTS.md của dự án: bất kỳ ai thêm một feature mới đều phải build theo cách này, sản phẩm không được phụ thuộc vào dịch vụ bên thứ ba nào.

10. Verification là chìa khoá

Một điều thật sự quan trọng khiến việc này làm được và build được trong một ngày là dùng emulator, computer use và screenshot để kiểm chứng (verification).

Nếu bạn đọc các bài trên X, verification về cơ bản là việc số một bạn cần làm để LLM chạy tốt. Theo Elie, chúng đã ở mức thiên tài, tự build được rất nhiều thứ. Nhưng nếu bạn muốn nó xong thật sự 100%, thì nó kiểm chứng càng tốt, kết quả bạn nhận được càng tốt. Về cơ bản, đó là thứ đưa bạn từ một agentic engineer tạm được, hay gọi chúng ta là gì cũng được, thành, có lẽ là, một người chuyên nghiệp.

Bạn kiểm chứng càng tốt, dự án càng tốt, và bạn càng tin được nhiều hơn. Đó cũng là cách bạn có thể chạy một dự án bên lề với 100 contributor khác nhau, vì mọi thứ luôn được kiểm tra rất kỹ. Nếu chỉ nhớ một điều từ video, hãy nhớ điều này: verification là chìa khoá. Và mẹo dùng emulator mà anh sắp giải thích cũng là chìa khoá để dự án chạy thật sự tốt.

Verification cũng giúp xây niềm tin (trust) vào LLM. Chúng ngày càng tốt hơn, nên niềm tin của chúng ta cũng tăng lên liên tục. Nhưng Elie nghĩ khác biệt giữa những người đẩy AI đi thật xa và những người vẫn đang chật vật nằm ở chỗ bạn tin AI làm tốt tới mức nào. Một phần lớn của niềm tin đó không phải là tin mù quáng, kiểu hy vọng Opus 5.5 sẽ làm thật tốt. Có lẽ nó sẽ làm tốt, nhưng có lẽ nó cũng sẽ mắc lỗi. Cách để nó tránh mắc lỗi, và điều này đúng với mọi LLM, là bắt nó chứng minh rằng mọi thứ đang chạy. Bắt nó tự kiểm chứng.

11. Bắt AI chụp screenshot mọi trang

Một việc rất dễ làm: khi build Rakazo, Elie bảo AI rằng anh cần screenshot của mọi thứ. "Tôi không muốn bạn giả vờ hay đoán là cái này chạy được." Nếu AI đưa cho anh screenshot của từng trang một trong sản phẩm, anh biết là nó thật sự chạy. Và AI cũng biết điều đó.

Đó thật ra chính là mục tiêu (goal): đảm bảo bạn có screenshot của mọi thứ. Nếu chưa có screenshot, nghĩa là bạn chưa đạt goal và phải làm tiếp.

Một trở ngại bạn sẽ gặp khi đi theo hướng này là có rất nhiều thứ không dễ test. Trước đó anh đã nói tới nhiều integration trong sản phẩm, ví dụ Daytona, Box hay Composio. Hãy tưởng tượng mỗi lần muốn tự kiểm tra, AI phải đăng nhập vào dịch vụ thật. Postgres thì nó tự chạy được, Redis cũng tự chạy được. Nhưng nếu nó cần, chẳng hạn, đăng nhập vào một tài khoản Gmail để test việc tự gửi email, thì Google sẽ chặn AI, bạn sẽ chạm giới hạn tần suất (rate limit), vì các công ty không muốn bạn tự động hoá trên dịch vụ của họ. Sẽ khá khó để làm cho nó chạy và để AI tự kiểm tra chính mình.

12. Emulator: bản clone mini của API thật

Đây là lúc emulator xuất hiện. Elie mở emulate.dev, một dự án của Vercel Labs, chỉ là một trong rất nhiều dự án như vậy. Anh không nghĩ Rakazo dùng emulate.dev; anh dùng nó cho Inbox Zero, nhưng hiểu khái niệm tổng thể là điều hữu ích ở đây.

Về cơ bản, giả sử bạn build một integration với Slack (rất nhiều app ngày nay tích hợp với Slack, Rakazo cũng vậy), và bạn phải gọi tới Slack API thật để test xem nó có chạy không, thì bạn sẽ không đi được xa. Slack sẽ chặn bạn, bạn phải cài đặt đủ thứ, và bạn không kiểm soát được toàn bộ hệ thống. Thứ bạn muốn là một bản Slack giả, về cơ bản là một bản Slack được mock.

Nhưng emulator còn đi xa hơn. Về cơ bản chúng là một bản clone của Slack, chỉ là bản rất cơ bản, có database mini riêng, thường chỉ nằm trong bộ nhớ (in memory). Nếu anh gửi một tin nhắn tới Slack bot của mình, nó sẽ bắt chước Slack API, tương tác y hệt. Gửi tin, nhận lại response 200, mọi thứ chạy y như vậy, chỉ khác là request đi tới localhost:4003 thay vì Slack API thật.

Xa hơn nữa, nó có bộ nhớ riêng. Ví dụ anh gửi một tin nhắn lên Slack, rồi gửi thêm một tin, rồi cho một bot khác gửi tin hoặc đọc các tin trước đó, mọi thứ đều chạy như mong đợi, vì nó có database in-memory riêng. Với tất cả các dịch vụ khác cũng vậy. Nếu bạn dùng GitHub API qua emulate, nó sẽ giả lập phía bên kia: bạn bảo "tôi muốn tạo một repository mới", và trong bộ nhớ nó sẽ nhớ là đã có một repository được tạo với cái tên giả của bạn. Ví dụ khác là gửi email qua Resend, thanh toán qua Stripe, hay dùng Gmail API. Elie kể anh chính là người đóng góp phần Gmail API và các API của Microsoft cho emulate.dev.

Tóm lại, nó cho bạn những gì:

• Stateful: tạo một repo GitHub, push commit, mở PR, gửi email qua Resend, charge thẻ trên Stripe; trạng thái được giữ qua các request.
• Real protocols: dùng đúng các giao thức mà dịch vụ thật dùng, nên AI có thể thật sự tự kiểm tra khi offline.
• Offline và sẵn cho CI, zero config: chỉ cần chạy npx emulate là nó chạy.

13. LocalStack, và những emulator tự build

Elie nhắc tới emulate.dev, nhưng có cả đống công cụ kiểu này, và chúng đã tồn tại khá lâu. Nếu bạn làm với AWS, có những công cụ AWS chạy local, "không tốn tiền, không thoả hiệp", cho phép bạn test toàn bộ hệ thống với một bản clone của AWS. LocalStack là một ví dụ khác. Ý tưởng này đã có từ lâu, nhưng trước đây rất khó để tạo một bản giả cho từng dịch vụ bên thứ ba bạn dùng. Giờ thì việc đó thật sự rất dễ.

Với Rakazo, dự án kết nối vào các dịch vụ bên thứ ba như Composio, nhưng emulate.dev không có emulator cho nó, và cũng chẳng ai khác có. Nên nhóm tự build, vì bắt chước một API không khó lắm: có một database mini, hoặc lưu trong bộ nhớ những gì đang diễn ra, bạn đã kết nối những tool nào, hay giả lập các response trả về. Tất cả đều khá khả thi, và AI của bạn có thể tự build hết.

Vậy nên những emulator anh có ở đây không tồn tại ngoài kia. Anh tự build hết, và khi nói "build", ý anh là anh bảo AI build. AI dễ dàng lên mạng, tìm website của Composio hay Daytona, rồi bắt chước API của chúng, để có một bản chạy đầy đủ ngay trên máy mà tự test.

Elie nói đây có lẽ là mẹo giá trị nhất anh có thể đưa: verification là chìa khoá, và emulator khiến việc thật sự kiểm chứng dễ hơn rất nhiều.

14. AI tự click trên màn hình, và model đã dùng

Bạn cũng có thể để AI tự kiểm chứng bằng cách click trên màn hình. Ví dụ, nó dùng Expo cho app React Native và click lần lượt qua đó. Elie nghĩ có lẽ anh đã dùng Maestro để test. Nó có thể chụp screenshot cả app desktop, app web lẫn app mobile. Khi nó làm hết những việc đó, bạn có thể khá chắc chắn là mọi thứ thật sự chạy. Về cơ bản, khó mà giả được những thứ như vậy.

Có thể bạn đang thắc mắc anh dùng model nào. Anh dùng GPT 5.6 cho giai đoạn planning. Giai đoạn này mất khoảng một tiếng, chủ yếu là thảo luận với AI để dựng cấu trúc tổng thể. Ở đó rất quan trọng là code được tái dùng, các interface phải sạch, và vân vân.

Rồi anh dùng Grok 4.6 để build chính dự án. Tại sao dùng Grok? Đơn giản vì 4.6 ra đúng ngày hôm đó, và nó là một model mạnh. Tới giờ đã có những phiên bản mới hơn (anh nhắc tới 4.7 và 6.1), nên chỉ trong một hai tháng qua mọi thứ đã tiến thêm nữa. Nhưng ngay cả với các model của vài tháng trước, tất cả việc này đều hoàn toàn làm được.

15. Bảo trì: screenshot cho mỗi pull request

Từ khi dự án lên sóng, rất nhiều người dùng nó, nghĩa là anh phải bảo trì. Người khác đóng góp còn nhiều hơn chính anh. Hiện giờ anh giống như người quản lý của tất cả những pull request đến từ một đội 100 người, ai cũng chạy đủ loại agent trên dự án.

Mẹo đầu tiên giúp việc quản lý trở nên rất dễ là có screenshot của mọi thứ. Không chỉ trong lần build đầu anh có screenshot; từ rất sớm, anh quyết định thêm screenshot cho mỗi pull request. Anh cho xem trang này đã chạy vài nghìn lần: có một số lần thất bại, nhưng nhìn chung phần lớn là thành công.

Bấm vào một lượt chạy, anh thấy chuyện gì đang xảy ra: screenshot của gần như toàn bộ dự án, từ các trang landing marketing, trang đăng nhập, mọi thứ. Anh lướt qua được hết mà không cần tự chạy dự án; screenshot cứ nối tiếp nhau không dứt. Nếu có gì không ổn, nhóm sẽ đi sửa. Anh chỉ chiếc máy tính đang chạy ở góc màn hình: nhóm cũng có emulator cho những thứ như vậy.

Có đủ loại màn hình khác nhau, có cả phần cho mobile. Có một màn hình artifact mà một người khác tự thêm vào hoàn toàn, chẳng phải do nhóm anh làm. Có phần avatar khác nhau, cũng là một đóng góp từ cộng đồng; bản đầu tiên không phức tạp như vậy. Có dark mode, và trang cứ dài mãi, hàng trăm screenshot. Nhưng tất cả đều là bằng chứng kiểm chứng rằng mọi thứ đang thật sự chạy.

Một điều có ích ở đây: là dự án mã nguồn mở thì chạy GitHub Actions rẻ hơn; anh nghĩ là miễn phí không giới hạn, điều đó rất tuyệt. Nhóm dùng rất nhiều GitHub Actions để chạy hết những thứ này. Anh cho xem các MCP đã được thêm vào, rồi chỉ một màn hình trông không ổn, có gì đó hơi vỡ ở UI: đó là thứ anh muốn đi sửa. Có screenshot khiến việc soát và sửa trở nên rất dễ. Kéo xuống tới cuối, có 350 screenshot.

16. Screenshot ngay trong PR

Elie cho xem nhanh cả PR. Trang lượt chạy có link về PR, điều này rất tiện. Trong mỗi PR cũng sẽ có các screenshot khác nhau. PR anh mở không có feature mới nên không có gì để hiện, nhưng nhóm thường đưa screenshot vào ngay trong PR, và sẽ đưa những thứ mới, hoặc ít nhất là cố gắng làm vậy.

Có 350 screenshot, anh không xem hết mỗi lần, nhưng anh muốn thấy những gì đã thay đổi. Đó là một điều giúp anh rất dễ theo kịp mọi thứ.

17. Bot tự merge PR, và dọn slop theo cron

Việc thứ hai nhóm đang làm là rất nhiều thứ được merge tự động. Một pull request đi vào, rồi một Grok Bot, hay về cơ bản là một agent Rakazo, chạy vài tiếng một lần: nó thức dậy, xem các pull request mới đang mở, và tự quyết định cái nào merge được, cái nào không. Vài tháng trước điều này chưa thể làm được, nhưng hôm nay thì được. Theo Elie, nhóm đang đẩy giới hạn của AI khá mạnh.

Ngay trong lúc quay, lại có thêm một pull request vừa đến trong vài phút qua: có người đang thêm Railway làm sandbox provider. Dù hôm nay anh không đụng vào dự án, vẫn có một loạt pull request đã được merge tự động.

Nếu một feature lớn đi vào, bot sẽ chờ anh duyệt (approval). Nó sẽ gửi anh vài screenshot để xem trước khi anh quyết định có merge thật không. Còn nếu chỉ là một bug fix đơn giản, nó sẽ tự merge. Và nó không merge mù quáng: nếu bạn thử nhét một PR độc hại, nó sẽ không tự động merge. Mọi thứ đều được review, được sửa lại và dọn sạch.

Nhóm còn làm nhiều thứ khác, ví dụ các automation. Có rất nhiều "slop" có thể lọt vào UI hay vào copy, tức là những thứ chỉ gây nhiễu. Elie kể anh thường phải bảo AI: "này, cắt bớt copy đi, có quá nhiều chữ giải thích rồi". Nhưng nhóm cũng có bot chạy tự động để gỡ slop đó khỏi dự án. Những lượt soát bảo mật và dọn dẹp này diễn ra liên tục.

Về cơ bản những việc này chạy theo cron job, rất dễ làm với Rakazo, với Grok Bot hoặc các công cụ tương tự. Bạn cũng có thể dùng GitHub Actions. Có rất nhiều cách để làm cho nó chạy bằng các gói đăng ký bạn đang có, như Claude, Cursor hay Codex.

Anh nói thêm: các bài test vừa cho xem đều là mã nguồn mở, bạn mở được các link đó, và tìm thấy ngay trong repository. Đó là các test Playwright.

18. Điều rút ra: verification, trust và trí tưởng tượng

Elie khép lại: anh hy vọng video hữu ích và mọi người có thêm vài ý tưởng hay. Điều lớn nhất cần mang về là verification là chìa khoá. Emulator giúp rất nhiều cho việc đó, nhất là khi bạn dùng nhiều dịch vụ bên thứ ba.

Những người đang đẩy AI đi xa nhất hiện nay là những người tin nó nhiều nhất, và cũng là những người có trí tưởng tượng lớn nhất. Điều bạn nghĩ là bất khả thi một năm trước thì hôm nay rất khả thi. Bạn có thể cạnh tranh với những công ty khổng lồ, build những thứ bạn chưa từng nghĩ là làm được, trong một khoảng thời gian rất ngắn.

Cuối video, anh mời mọi người đăng ký kênh, cho Rakazo một sao, và cho cả Inbox Zero, công ty còn lại của anh, một sao.