# AI Learning Community, AI Discussion Group, Claude Code tips > Source: > Published: 2026-08-19 23:38:01+00:00 # AI Learning Community, AI Discussion Group, Claude Code tips [Claude Code](/en/tags/claude%20code/)Prompts Most AI discords are noise. People posting screenshots of "look what I built" with zero context. Or asking "how do I center a div" for the fiftieth time. I left six of them last year. Then a colleague sent me an invite to a private server. Twenty developers. No memes. Just raw [Claude](/en/tags/claude/) Code sessions — pasted terminal output, broken prompts, the fixes that worked. Three weeks later I'd cut my refactor time on a legacy Rails app from two days to four hours. Here's how to find (or build) that kind of community, plus the specific Claude Code workflows we actually use. ## The signal-to-noise problem Public Discords optimize for engagement. Questions get answered by whoever's online, not whoever knows. The "help" channel becomes a dumping ground for homework assignments. A real learning community looks different: **Barrier to entry**: Application, referral, or visible portfolio** Show-your-work culture**: Failed prompts are valued more than successes** Tool-specific focus**: One channel per tool, not one channel for "AI"** Time-boxed threads**: Discussions auto-archive after 48 hours The server I'm in requires a 150-word writeup on your hardest debugging session with an LLM. Took me twenty minutes. Kept out the tourists. ## Setting up your own Claude Code workflow Before you even join a group, get your local loop tight. Here's what I run every morning: ``` bash # ~/.claude-code/startup.sh #!/bin/bash claude-code --model sonnet-4 \ --allowed-tools "Read,Write,Edit,Bash,Grep,Glob,Task" \ --max-turns 30 \ --permission-mode acceptEdits \ --output-format stream-json \ --mcp-config ~/.claude-code/mcp.json ``` The `--permission-mode acceptEdits` flag is the game-changer. Lets Claude apply multi-file refactors without pausing for confirmation on every write. Saved me roughly 200 keystrokes per session. My `mcp.json` connects three servers: ``` { "mcpServers": { "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"], "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${GH_TOKEN}" } }, "postgres": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-postgres"], "env": { "DATABASE_URL": "${DEV_DB_URL}" } }, "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/home/dev/projects"] } } } ``` GitHub [MCP](/en/tags/mcp/) lets Claude open PRs directly. Postgres MCP means it can write and test migrations against my actual dev database. Filesystem MCP keeps it from hallucinating paths. ## The prompt template we actually use Stop writing "refactor this" and expecting miracles. Our standard template: ``` ## Context - Repo: {name} | Branch: {branch} | Language: {lang} - Files involved: {glob patterns} - Test command: {exact command} ## Goal {One sentence. Measurable. "Extract UserService into its own module with 90%+ test coverage"} ## Constraints - Don't touch: {files/patterns} - Must preserve: {behavior/contracts} - Style guide: {link or inline rules} ## Current state {Paste `git diff --stat` or relevant file tree} ## Acceptance criteria - [ ] Tests pass: {command} - [ ] No new lint errors - [ ] {Specific behavioral check} ``` Copy that into a snippet. Use it every time. The "Current state" section forces you to give Claude the map — it can't navigate what it can't see. ## Real example: The Rails-to-Service extraction Last Tuesday. Legacy `app/services/user_registration_service.rb` — 480 lines, zero tests, called from twelve controllers. Classic god object. My prompt (condensed): ``` ## Context - Repo: core-api | Branch: extract-user-reg | Language: Ruby - Files: app/services/user_registration_service.rb, spec/**/*registration* - Test: bundle exec rspec spec/services/user_registration_spec.rb ## Goal Extract email verification, password hashing, and welcome email into separate classes. 90% coverage on each. ## Constraints - Don't touch: app/controllers/**/* - Must preserve: UserRegistrationService.call interface - Style: Rubocop config in .rubocop.yml ## Current state $ git diff --stat app/services/user_registration_service.rb | 480 ++++++++++++++++++++++++++++++ ## Acceptance - [ ] rspec passes - [ ] rubocop -A clean - [ ] Integration test: POST /api/v1/users returns 201 with verification email queued ``` Claude produced four files in one turn. `EmailVerificationService` , `PasswordHasher` , `WelcomeEmailJob` , and a thin `UserRegistrationService` orchestrating them. Tests passed first run. Rubocop clean. The wild part? It caught a bug I'd missed — the original service swallowed `ActiveRecord::RecordNotUnique` and returned a generic error. Claude's extraction surfaced it as a proper `EmailTakenError` with a test. That's the level of specificity a good community teaches you to demand. ## Finding (or starting) your group Don't overthink the platform. Discord, Slack, Matrix — whatever your people already use. The structure matters more: **Weekly rhythm that works:** - Monday: "What broke last week?" thread (30 min sync) - Wednesday: Live coding session — someone shares screen, works a real ticket - Friday: "Shipped this" thread with links to PRs **Channels we keep:** `#claude-code` — tool-specific, prompt patterns, version gotchas`#architecture-decisions` — ADRs for AI-assisted changes`#failed-prompts` — the most valuable channel. Paste the prompt, the bad output, what you changed`#context-sharing` — repo maps, schema dumps, API contracts people reference **Channels we killed:** `#general` — became watercooler`#resources` — nobody clicks links. We use a shared Notion instead`#jobs` — attracts recruiters, kills psychological safety The `#failed-prompts` channel alone is worth the price of admission. Saw a senior engineer post a prompt that produced a SQL injection vulnerability. The breakdown of *why*Claude missed it — missing `sql_safe` annotation on a dynamic scope — saved three of us from the same mistake.## The unwritten rules 1. **No "here's my code, fix it" without the template above**. Lazy prompts get ignored. 2. **Share the diff, not the file**. `git diff` > `cat file.rb` . Context is everything. 3. **Credit the model, own the decision**. "Claude suggested X, I chose Y because Z." 4. **Version your prompts**. We tag them `v1` , `v2` in the thread. Regression testing for prompts is real. 5. **If it works, document the pattern**. Our `Resources` page started as a pinned message. Now it's a searchable Notion with 47 tested patterns. ## Measuring whether it's working Track three numbers monthly: **Prompt-to-PR ratio**: How many prompts become merged code? Ours is 1:3.2** Rework rate**: PRs reverted or heavily revised within a week. Target < 15%** Time-to-first-review**: From "prompt sent" to "human review requested." Median 22 minutes If rework rate climbs, the prompts are too vague. If time-to-review drags, the diffs are too big. Both are fixable. ## What's next for our group We're experimenting with a shared prompt registry — versioned, tested, tagged by task type. Think npm for prompts. Early prototype: ``` # Install a vetted prompt pattern prompt-get rails/service-extraction@v3 # Run it against current repo prompt-run rails/service-extraction@v3 --files app/services/user_registration_service.rb ``` Still rough. But the idea: stop rewriting the same extraction prompt every month. Share the iteration history. The community didn't make me a better programmer. It made me a better *collaborator with the tool*. That distinction matters. The prompts in `#failed-prompts` taught me more about Claude's blind spots than any documentation. If you're coding with AI alone, you're leaving velocity on the table. Find three people who push commits daily. Start a thread. Use the template. Ship something this week. [Next The dead giveaways that a site was vibe coded →](/en/threads/6943/) ## All Replies （0） No replies yet — be the first!