Building a 3,700-Star Open-Source GrokBot in One Day: A Record of AI Agent Construction and Automated Maintenance

A developer built an open-source AI assistant called Rakazo (dubbed the open-source GrokBot) in a single day. The project has since earned 3,700 stars on GitHub, attracted 100 contributors, and merged over 1,200 PRs. He recently shared his full methodology on Bilibili, and the core takeaway isn't how powerful the model is—it's the combination of verification-driven development and emulator testing.

Why GrokBot-Style Products Are So Popular

GrokBot is essentially an AI assistant, and users love it because it's "simple"—everything happens inside a chat window. Compared to earlier assistant products like OpenClaw^Ad and Hermes, GrokBot and Rakazo reduce configuration complexity to a minimum. According to the video, each bot has its own "computer," which can be a shared or dedicated machine, and comes with out-of-the-box capabilities like routines. Most of the time, users just need to converse—no manual settings tweaking required.

Rakazo is completely free and open source under the Apache license, and supports self-hosting. The video shows several user testimonials, one of which states plainly: "Hermes is good, but configuration is more complex. Rakazo's multi-agent workflow is better and setup is simpler." Another user says it completely replaced GrokBot and that the mobile experience is smooth.

The product covers desktop, mobile, and web, with all data running in the cloud and syncing automatically. The author notes that a year ago, building such a complex product might have required a team of 20 people working for a year—he did it in one day.

The Four Key Phases of Building in a Day

Phase 1: One Hour of Planning to Define Product Boundaries

The author emphasizes that planning remains a core skill. If you give AI a one-sentence instruction, the project will most likely get stuck halfway. He spent about an hour discussing with AI to establish several non-negotiable principles:

• Three-platform sync: Mobile, desktop, and web must all work simultaneously—this is the foundation of the GrokBot model.
• Compatibility with any model: ChatGPT subscriptions, OpenRouter, Claude API keys, and local LLMs must all be supported.
• No lock-in to any third-party service: Sandbox providers (Daytona, E2B, Box) and integration libraries (Composio, Pipedream) are all abstracted behind interfaces, so users can swap them freely.

These principles were written into the project's agents.md file to ensure that every subsequent contributor adding new features adheres to the same architectural constraints. The author believes that designing interface abstractions from day one is far easier than migrating vendors later.

agents.md is a convention that has become popular in AI-assisted programming practice in recent years: a plain-text instruction file placed in the repository root that declares to AI coding assistants the project's architectural constraints, coding standards, directory structure, prohibited actions, and acceptance criteria. It borrows the idea of README.md and CONTRIBUTING.md, but its audience is the model rather than humans. Because large language models tend to forget early instructions in long conversations and gravitate toward the path of least resistance, codifying key principles as a persistent file in the repository lets every new session and every new contributor (human or AI) automatically inherit the same boundary conditions, preventing the architecture from being gradually eroded over multiple iterations. Similar formats include CLAUDE.md and .cursorrules.

Phase 2: Using Plan Mode to Drive Continuous AI Execution

After planning, the author used Claude for UI design—since GrokBot had already solved the core UX challenges, there was no need to reinvent them. He then issued the /goal command to keep the AI working until every item in the plan was checked off. This step actually ran twice, with the first run going all night.

Phase 3: Security Hardening

After the project was initially working, the author ran DeepSec to scan for security vulnerabilities and further harden the code. This step is easy to overlook in a one-day build process, but it's especially important for open-source projects.

Phase 4: Emulator and Screenshot Verification

This is the "most valuable trick" the author repeatedly emphasized throughout the talk. He believes that verification is the dividing line that takes an LLM from "roughly works" to "truly complete."

The approach: require the AI to provide a screenshot of every page in the product. No screenshot means the goal isn't complete. AI can't fake screenshots, so this becomes a hard standard for judging whether a feature actually works. For desktop, web, and mobile, the author used tools like Expo and Maestro to let the AI click, screenshot, and compare on its own.

Emulators: Letting AI Self-Test Third-Party Integrations Offline

Building an AI assistant inevitably involves third-party services: Gmail, Slack, GitHub, Stripe, Composio, Daytona... But having AI log into real services to test runs into problems like Google bans and rate limits. Companies also don't want automated traffic hammering their APIs.

Emulators solve this contradiction. Take Vercel Labs' emulate.dev, for example: it provides a Slack clone with its own in-memory database running on localhost. When AI sends a message to the mock Slack, it gets a 200 response consistent with the real API, and message state persists across requests.

The author himself is a contributor to emulate.dev's Gmail API and Microsoft API. He summarized what emulators enable: stateful operations (creating repos, pushing commits, sending emails, and Stripe charges all persist across requests), real protocol compatibility, offline operation, CI readiness, and zero configuration. Similar tools include LocalStack (local AWS) and Floci (zero-cost local AWS).

When existing emulators don't cover Composio or Daytona, the author simply has the AI scrape the API docs from the official website and build a mock version itself. He believes that mimicking an API with a small in-memory database isn't difficult, and AI is fully capable of it.

LocalStack is an open-source tool that emulates AWS services locally. It provides compatible implementations of dozens of services—S3, SQS, Lambda, DynamoDB, and more—on a single machine, so developers can run integration tests without a real cloud account. Its value lies in three things: first, tests incur no cloud costs and aren't subject to quotas or rate limits; second, tests can run offline and deterministically in CI; third, you can artificially inject failures and edge cases that are hard to reproduce on demand with real services. The emulate.dev and Floci mentioned in the article follow a similar philosophy, just swapping the target from AWS to SaaS APIs like Slack, Gmail, and Stripe. The common prerequisite for such tools is maintaining the same protocols and response formats as the real services, so that the code under test can switch without any modification.

How to Maintain an Open-Source Project with 100 Contributors

After launch, the author's role shifted from developer to PR manager. His current strategy has two layers:

Layer 1: Every PR includes a screenshot. GitHub Actions was configured early on, running Playwright tests on every PR and generating full-site screenshots—350 so far. The author doesn't need to run the project himself; he just reviews screenshots of the changed parts to judge whether there are UI issues. GitHub Actions' free tier for open-source projects is a huge help here.

Layer 2: An auto-merge bot. An agent built on GrokBot/Rakazo wakes up every few hours, reviews new open PRs, and decides on its own which ones can be merged. Simple bug fixes go straight in; large features wait for the author's approval, with screenshots attached for review. The author emphasizes that this isn't blind merging—malicious PRs are still blocked, and all changes go through review and cleanup.

There are also cron jobs that automatically clean up redundant UI copy, run security checks, and do code cleanup. These can run on Rakazo, GrokBot, or GitHub Actions, reusing existing Claude, Cursor, or Codex subscriptions.

Playwright is Microsoft's open-source headless browser automation framework, supporting the Chromium, Firefox, and WebKit engines, and is commonly used for end-to-end testing and web scraping. Compared to the earlier Selenium, it includes automatic waiting, network interception, multi-tab and multi-browser context management, and can screenshot individual page elements or entire pages directly. In this article's workflow, Playwright plays the role of "verifiability infrastructure": after AI modifies code, Playwright launches the app, traverses pages, and generates screenshot artifacts, so a human only needs to compare visual differences to judge whether a change broke the UI. Combined with GitHub Actions, these screenshots are retained as PR attachments, forming a traceable chain of acceptance evidence.

Model Choices and Observations on Timeliness

The author used GPT-5.6 during the planning phase and Grok 4.6 during the build phase—chosen simply because it had just been released that day. In the video, he notes that by the time of recording, models had already iterated to Grok 4.7 and GPT-6.1, but stresses that "models from a few months ago are completely sufficient." What really makes the difference isn't the model version—it's the verification system and the level of trust.

Three Takeaways for Developers

1. Verification before generation. Make AI prove a feature works rather than trusting it when it says it's done. Screenshots and emulators are low-cost, high-return verification tools.
2. Interface abstractions must be done on day one. No lock-in to a sandbox vendor, integration library, or model provider—this flexibility is the source of long-term vitality for open-source projects.
3. Maintenance can be automated, but not left unchecked. Auto-merge depends on a complete pipeline of tests, screenshots, and security review.

The author concludes by saying that the people pushing AI the furthest today are those who trust it the most and have the most imagination. What seemed impossible a year ago can now be done by a single person.

One-line Summary

The developer built the open-source AI assistant Rakazo in one day, earning 3,700 stars—driven by verification rather than model strength.

Paragraph Summary

The article documents a developer's full methodology for building the open-source AI assistant Rakazo (an open-source GrokBot) in one day. The project has earned 3,700 stars on GitHub, 100 contributors, and over 1,200 merged PRs. The author breaks the process into four phases: one hour of planning, with principles like three-platform sync, any-model compatibility, and no third-party lock-in written into agents.md; using plan mode to drive continuous AI execution; using DeepSec for security hardening; and using screenshots and emulators for verification. He stresses that verification is the dividing line between an LLM that "roughly works" and one that truly completes the task, since AI can't fake screenshots. Maintenance relies on Playwright full-site screenshots and scheduled agents that automatically review PRs. The author believes model versions aren't the deciding factor—the verification system and level of trust are what separate efficient workflows from the rest.