The Vibe Father
Playbook
A Discord bot is the perfect weekend project to build with AI. The scope is naturally small, the platform's SDKs are well-trodden ground the models know cold, the feedback loop is instant — you type a command in a channel and see it work — and it's genuinely useful the moment it runs. Agents are excellent at this: slash commands, a few API calls, a reply. This playbook is the stack, the deploy, and the gotchas that turn a two-hour build into a two-day one if you don't know them going in.
The stack
Keep it boring and it'll be done by Sunday:
- A bot application + token. Registered in the Discord developer portal. The token is a secret — it goes in an environment variable, never in the repo, or your bot gets hijacked.
- A library the models know. A mature Discord library in the language you're comfortable in. Don't pick the exotic new wrapper; pick the one with a decade of examples in the model's training data.
- Slash commands. The modern, discoverable way to expose functionality. Users type
/and see your commands with argument hints. Prefer these over message-parsing. - Optional persistence. A single SQLite file or small database if your bot needs to remember anything — scores, settings, a queue. Skip it entirely for a stateless bot.
The build order
- Get "hello" working first. Register the app, get the token, connect the bot, and make one slash command reply. Confirm the whole loop — auth, connection, command registration, response — before adding any real logic. This is where the fiddly platform setup lives; clear it first.
- Register commands correctly. Slash commands must be registered with Discord, and there's a real gotcha here (below). Get one command showing up reliably before you add ten.
- Add your commands one at a time. Each command: define it, handle it, reply. Test each in a real channel before the next. Agents write these fast; your job is verifying each actually behaves.
- Add persistence if needed. Wire the database only when a command genuinely needs to remember something. Resist building state you don't use yet.
- Handle failure gracefully. A command that errors should reply with a clear message, not silently do nothing — a silent bot feels broken even when it's mostly working.
The gotchas that eat the timeline
These are the specific traps. Knowing them turns the frustrating parts into a checklist:
- Global vs guild command registration. Global commands can take up to an hour to appear; guild-scoped commands appear instantly. During development, register commands to your test server (guild) so you're not waiting an hour to see a typo. Switch to global for release.
- The 3-second interaction deadline. Discord expects an initial response within about three seconds. If your command does slow work — an API call, a database query — you must acknowledge (defer) the interaction immediately and send the real reply after. Agents forget this constantly; the symptom is "This interaction failed."
- Gateway intents. To read message content or member events, you must enable the matching intents in the portal and in your code. Forget one and your bot silently receives nothing. This is the top "why isn't my bot seeing messages" cause.
- Permissions and roles. Your bot needs the right permissions in the server, and its role must sit high enough to act on the roles it manages. A bot that "does nothing" is often just under-permissioned.
- Rate limits. Discord rate-limits aggressively. Don't loop sending messages without spacing them, or your bot gets throttled mid-task.
Deploy — keep it running
| Concern | Boring correct answer | Effort |
|---|---|---|
| Where it runs | A small always-on host or container | Low |
| Staying up | Process manager that restarts on crash | Low |
| The token | Environment variable on the host | Low |
| Knowing it broke | Log errors somewhere you'll see them | Low |
A Discord bot needs to be always-on, so a laptop that sleeps won't do. A small cloud instance or container with a process manager that restarts on crash is the simple, durable answer. Keep the token in the host's environment, and log errors somewhere you'll actually notice them.
Security, briefly
A bot that takes commands from a public server is a small attack surface. Validate command inputs, don't eval user text, be careful with any command that touches a shell or a file path, and scope its permissions to exactly what it needs. Run the relevant parts of the AI coding security checklist before it joins a server you care about.
Model picks
A Discord bot is value-model work start to finish — Sonnet 5 or GPT-5.3 Codex handle the SDK and command logic cheaply, and Gemini Flash's speed makes the "add a command, test it in the channel" loop delightful. You almost never need a top model here; save that for the hard-reasoning projects. Pick a mature library and a boring host and the whole thing genuinely fits in a weekend.
The move
Register the app, get one command replying, clear the interaction-deadline and intents gotchas early, add commands one at a time, and deploy to something always-on with the token in the environment. That's a real, running bot by Sunday. It's a great first end-to-end project — and if it whets your appetite, things to build with AI agents ranks more honestly-scoped ideas, building a chatbot with AI agents is the natural next step if you want the bot to actually converse, and shipping your first product with AI agents walks the full path when you're ready. The Vibe Father can run a Builder on the commands while you test in Discord, but a weekend bot ships happily from a single terminal.
