Most people use Claude Code the same way they use a chatbot — type a prompt, watch it work, respond to questions, babysit the output. That's fine for one-off fixes. But it doesn't scale. Here's the pattern I've been running instead: Claude Code as a background agent you dispatch tasks to, then walk away. The setup is simple: 1. Invoke Claude Code with --print and --permission-mode bypassPermissions 2. Pass a task description on stdin or as a prompt 3. It runs to completion and exits — no TTY required 4. Pipe the output wherever you need it (Telegram, log file, another agent) Example command: claude --print --permission-mode bypassPermissions "Fix the failing test in auth_service.py and commit the result" That's it. Claude reads the codebase, finds the test, fixes it, commits, and exits. You get a message when it's done. Where it gets powerful: • Schedule via cron — "every weekday at 9am, review open GitHub issues and draft fixes" • Chain agents — one agent researches, another implements, another reviews • Run multiple in parallel — different tasks on different branches simultaneously • Trigger on events — new PR opens, run a review agent automatically The key mindset shift: Claude Code is not a chat interface. It's a programmable worker. Once you stop treating it like a chatbot and start treating it like a subprocess, the whole thing opens up. What are you currently babysitting that you could delegate to a background agent?

Just published a free 5-lesson course for new members: 1. What is Claude Code? -- how it's different, who it's for 2. Install & First Session -- get up and running in 10 minutes 3. CLAUDE.md & Project Setup -- give your AI context so it stops guessing 4. Plugins, Skills & MCP Servers -- extend Claude Code with new capabilities 5. Customize Your Setup -- permissions, hooks, settings, context management Free for all members. Head to the Classroom to start. If you've already set up Claude Code, skip ahead to Lesson 3 -- CLAUDE.md is the single biggest improvement you can make.

Your CLAUDE.md is the difference between Claude Code that guesses and Claude Code that knows your project. Here's how to write one that actually improves your output: THE BASICS CLAUDE.md is a markdown file at your project root. Claude Code reads it automatically at the start of every conversation. Think of it as persistent instructions that survive session resets. WHAT TO PUT IN IT 1. Build/test commands - The exact commands to build, test, and lint your project. Claude Code will use these instead of guessing. Example: - Build: npm run build - Test: npm test -- --watch - Lint: npm run lint:fix 2. Architecture decisions - Things that aren't obvious from the code. "We use server components by default." "Auth goes through middleware, not page-level checks." "The API layer is in /apps/api, not /src/api." 3. Code style rules - Preferences Claude Code can't infer. "No barrel exports." "Use named exports, not default." "Error messages go in /lib/errors.ts, not inline." 4. What NOT to do - Negative constraints are powerful. "Never add Co-Authored-By to commits." "Don't use chore: prefix." "Don't add comments to unchanged code." WHAT NOT TO PUT IN IT - Secrets or tokens (it's committed to git) - Entire API documentation (too long, dilutes focus) - Things obvious from package.json or tsconfig THE STRUCTURE THAT WORKS Keep it under 200 lines. Start with build commands, then architecture, then style rules, then constraints. Claude Code reads the whole thing every time, so every line costs attention. LEVEL UP: NESTED CLAUDE.md You can put CLAUDE.md files in subdirectories. Claude Code reads the one closest to the file it's working on. Use this for monorepos: - /CLAUDE.md (repo-wide rules) - /apps/api/CLAUDE.md (API-specific patterns) - /apps/web/CLAUDE.md (frontend-specific patterns) THE TEST After writing your CLAUDE.md, start a fresh Claude Code session and ask it to make a small change. If it follows your conventions without being told, it's working. If it doesn't, your CLAUDE.md needs to be more specific.

I just published a full walkthrough on building an MCP server in Python from scratch. If you haven't touched MCP yet — it's simpler than it sounds. An MCP server is a JSON-RPC service that exposes tools to Claude. You define functions, Claude discovers them, picks the right one based on context, and your code runs. That's the entire pattern. Python is the fastest path to a working server. The FastMCP library gets you from zero to a running server in about 30 lines. You define a tool with a decorator, add a description so Claude knows when to use it, and start the server. Done. The pattern looks like this: - You write Python functions and mark them as tools - Claude connects to your server and sees what's available - When a user asks something relevant, Claude calls your tool automatically - Your code runs, returns results, Claude uses them in its response No middleware. No routing logic. No prompt engineering to get Claude to use your tool — it just works because MCP is a standard protocol that Claude speaks natively. I built my first MCP server to pull YouTube analytics. Took about an hour from "what is MCP" to "Claude is reading my channel stats." The second one took 20 minutes. Once you see the pattern, you can wrap any API or script as a tool Claude can use. The walkthrough covers setup, tool definitions, testing locally, and connecting to Claude Code. Full post here: https://kjetilfuras.com/build-mcp-server-in-python/ Full code in the post. Drop questions below.