SOURCE // LABS

Running Claude Code in Production: What Actually Works and Earns Its Keep

Running Claude Code in Production: What Actually Works and Earns Its Keep

Everyone's got a "10 AI coding tricks" post. This isn't that. This is what's left after three weeks of running Claude Code on a real project — a bilingual booking bot for a beauty salon (Telegram + WhatsApp, Postgres, Google Calendar) — once the novelty wore off and only the useful parts survived.

Out of the box, Claude Code is a very smart intern with amnesia. Every session it shows up brilliant and clueless. The whole game is fixing the clueless part. Four things did that for me: a CLAUDE.md file, two custom agents, one skill, and two hooks. Everything else I tried, I deleted.

The CLAUDE.md file sits in your repo root and gets read at the start of every session. Mine started as three lines. It grew every time the assistant did something I had to undo. That's the trick, honestly. Don't write CLAUDE.md upfront — grow it from failures. Mine now includes things like:

## Architecture rules
- Business logic lives in src/core/ and must not know about Telegram or WhatsApp. Channel code lives in src/adapters/.
- All times stored in UTC; convert only for display.
- Booking creation must stay double-booking-safe — never remove locks or constraints around it.

## Working agreements
- Before 'done': run typecheck && lint && test and show the result.
- Schema changes go through a migration file. Always.
- Prefer the smallest diff that does the job.

Each of those lines exists because the assistant once did the opposite. It put Telegram-specific code in core logic — new rule. It "fixed" a UTC timezone bug by converting at storage time — new rule. It reported "done" with failing types — new rule. Three weeks in, I almost never repeat an instruction. That file is the difference between an assistant and a goldfish.

Custom agents live in .claude/agents/ as markdown files with a system prompt. You invoke them for a specific job, they do it with their own instructions and tool limits, and they don't pollute your main session's context. The one that earns its keep daily is a code-reviewer:

---
name: code-reviewer
description: 'Reviews changes for bugs and security issues before they are committed.'
tools: Read, Grep, Glob, Bash
---

You are a strict but practical code reviewer.
Check, in this order: correctness (timezone boundaries, double-booking windows), security (unvalidated webhook input, SQL built by concatenation, missing signature checks), project rules from CLAUDE.md, and whether behavior changed without a test changing.
Report findings ordered by severity, with file:line and a concrete fix. If something is fine, don't pad the review.

The point isn't that it catches everything. The point is that it's a different context with one job. The main session wrote the code and is biased, whereas the isolated code-reviewer maintains objectivity.

[AgentUpdate Depth Analysis] The architectural success of Claude Code lies in its elegant combination of context constraint (CLAUDE.md) and role isolation (Custom Agents). Unlike traditional autocomplete plugins like GitHub Copilot, Claude Code operates as an active, CLI-based AI Agent with direct system access. By structuring instructions dynamically and separating the writer from the reviewer, it effectively mitigates the common LLM pitfalls of hallucination and confirmation bias. This paradigm shift highlights the future of software engineering: AI is moving from a basic helper utility to an autonomous team member that respects guardrails and organizational standards. As frameworks like MCP (Model Context Protocol) continue to mature, the pattern of deploying lightweight, localized, and highly-specialized Agents will become the standard for robust, enterprise-grade software development.