Part 6 of Claude Code, Beyond the Prompt — patterns from running a live automated trading system on Claude Code. Part 5: semantic code search.
"Vibe coding" gets mocked, but the core of it is real: you describe what you want, Claude builds it, you iterate. It's genuinely fast.
It's also a disaster waiting to happen the moment you have more than one thing in flight. Five parallel changes, no record of what you asked for yesterday, no diff anyone reviewed, no answer to "why is this code like this?" three months later. Vibe coding without structure isn't productivity — it's fast chaos that you pay for later.
The structure that fixes it is one you already have: GitHub. Not as a place to push code — as the shared workspace that turns loose AI-assisted coding into something you can trust and trace.
GitHub plays three roles for an AI workflow
Stop thinking of it as "where the repo lives." For an agent, GitHub is three things at once:
1. The task queue. Issues are Claude's to-do list. Instead of "the thing we discussed," there's issue #142 with a title, a description, and acceptance criteria — persistent, referenceable, unambiguous. Claude can read it, work it, and link its work back to it.
2. The unit of change. Every change lands as a pull request: a reviewable diff with a written why. The PR is the checkpoint where you — or an automated review pass — look before anything merges. This is the brake that makes the speed safe.
3. The audit log. Closed issues and merged PRs are the permanent record of what changed and why. Six months later, git blame → PR → issue tells the whole story. Your memory files (Part 1) hold current state; GitHub holds history. You need both.
The simplest version
Use the gh CLI. Authenticate once:
gh auth login
That's OAuth — a browser flow, no token pasted anywhere. Now Claude can run gh issue list, gh issue view 142, gh pr create, and the rest, directly. Add a line to your CLAUDE.md:
## GitHub
- Work is tracked as issues. Reference the issue number in the branch and PR.
- Land every change as a pull request, never a direct commit to main.
- Never commit secrets or tokens. Auth is via `gh auth login` / environment only.
Now the loop has a shape:
idea → issue (captures intent) → branch → Claude implements → PR (reviewable diff) → review → merge → issue closes.
Every step leaves a record. You still move fast. You just stop losing the thread.
The golden rule: never commit a secret
One rule in this whole series is non-negotiable, and it's this one: never commit secrets, tokens, or keys. Not in a file, not in a config, not "just temporarily."
Authenticate through OAuth (gh auth login) or environment variables — never a token living in the repo. A leaked token in a public commit is the kind of mistake that ends up in a breach report. Two cheap safeguards: keep secrets in a git-ignored env file, and add a secret-scanning pre-commit check so a slip gets caught before it's pushed, not after.
When Claude is writing code fast, this guardrail matters more, not less — because "move fast" and "paste the API key inline to make it work" are dangerously close neighbors. Make it structurally impossible, don't rely on remembering.
How I scaled it
The three roles above are the beginner version. Here's what they become under load.
Issues aren't just tasks — some are gates. An experiment that needs a go/no-go decision on a specific date becomes a labeled issue with that date attached and an automated check scheduled to fire on it, posting a PASS / FAIL / NEEDS-MORE-DATA verdict as a comment. The result: the issue tracker doubles as a deadman's switch for every in-flight experiment. Nothing quietly runs forever because I forgot to check on it — the date arrives, the verdict posts itself.
Labels carry the deploy handoff. When code merges but isn't live yet, it gets a needs-deploy label. Remember the session-start ritual from Part 2? It checks for that label first thing. The label is the explicit handoff between "merged" and "actually running" — closing exactly the half-done-handoff gap that Part 2 warned about.
Claude manages the queue directly. Through the MCP tools from Part 4, Claude reads, comments on, and closes issues mid-session, as part of the work — not as a separate bookkeeping chore I do afterward. Managing the task queue is part of doing the task.
PRs stay the unit of change precisely because they're the review checkpoint. Even when I'm moving fast, nothing reaches the main branch without a diff that either I or an automated review pass has looked at. That single discipline is what keeps vibe coding from degrading into vibe debugging.
The lesson: structure is what makes speed safe
Here's the counterintuitive thing, and it's the heart of this article.
People assume process slows you down. In an AI workflow it's the opposite: structure is what lets you move fast without fear. Because every change is issue → PR → merge with a full record, nothing is lost, everything is reviewable, and everything is reversible. That safety net is exactly what makes it rational to let Claude move quickly. Take the net away and you have to move slowly and check everything by hand — which is slower, not faster.
Speed and structure aren't opposites. Structure is the precondition for speed you can trust.
A smaller lesson: the issue is the spec
A well-written issue — clear description, explicit acceptance criteria — is a better prompt than a chat message. It's persistent, it's referenceable, and writing it forces you to decide what "done" actually means before Claude starts building the wrong thing quickly.
Writing the issue first feels like overhead. It's the opposite: it's the cheapest place to catch a misunderstanding, before any code exists. Ten minutes on a good issue routinely saves an hour of building-then-rebuilding.
The payoff
Honestly: you can vibe-code across a dozen parallel workstreams without losing the plot, and every change is traceable and reviewable. GitHub doesn't magically organize you — you still write the issues and review the PRs. What it gives the AI is a shared, persistent workspace instead of an ephemeral chat that evaporates when you close the terminal.
That's the difference between "Claude helped me code today" and "Claude is part of how this project runs."
Next — the capstone
Six pieces now: memory that persists (1), rituals that ground (2), commands that encode your workflows (3), MCP tools that act on your systems (4), semantic search that finds by meaning (5), and GitHub as the shared source of truth (6).
They don't just each help a little. They compound — mostly by cutting the amount of junk Claude has to read and redo. Part 7 puts numbers on it: how this stack cut my token bill and sped up every session, and how to measure the same on yours.
Part 6 of a series on running real systems on Claude Code. The deeper RAG research is open source — see RE-call. The finale, Part 7, is next.
Top comments (0)