Mastering Claude Code: From Prompting to Programmable Engineering

For many, Claude Code is used as a high-end autocomplete—a tool where you type a prompt and accept a suggestion. However, there is a vast difference between casual usage and treating Claude Code as a programmable agent. When internalized, the tool shifts from a prompt-and-wait chatbot to an autonomous system with memory, custom commands, and a project setup that compounds in value over time.

To move beyond the basics, you must stop guiding the model line-by-line and start delegating. The core philosophy, championed by Boris Cherny and the Anthropic team, is to give Claude a way to verify its own work. By establishing a deterministic feedback loop—such as running a test suite or a linting command—Claude can iterate independently until the solution actually works, leading to a 2-3x improvement in output quality.

The Strategic Workflow: Explore, Plan, Execute

High-leverage users avoid jumping straight into code. Instead, they follow a disciplined sequence:

Explore: Use Plan mode (Shift+Tab twice) for read-only exploration. Trace data flows and understand the model without modifying files.
Plan: Generate a technical plan. For complex changes, a common power-user pattern is to have one Claude session write the plan and a second, fresh session review it as a "staff engineer" to eliminate context bias.
Execute: Only after the plan is vetted (and potentially tweaked via Ctrl+G in the editor) does the implementation begin.

Throughout this process, precision is key. Rather than describing a module, reference it directly (e.g., @src/auth/login.py). When errors occur, pipe them directly into the session: cat error.log | claude.

Engineering Memory with the `.claude` Directory

Claude Code utilizes a layered configuration system that separates project-specific needs from personal preferences. This is managed through the .claude/ directory.

The Role of `CLAUDE.md`

CLAUDE.md is the heartbeat of a project's agentic memory. It is loaded at the start of every session. The most effective CLAUDE.md files are concise and focused on build commands, type-checking rituals, and project-specific "gotchas."

A critical habit for compounding engineering is to let Claude write its own rules. When the model makes a mistake, the prompt should be: "Update CLAUDE.md so you do not repeat this." Over time, this transforms the file into a curated list of every architectural quirk and common pitfall in the codebase.

Personalization via `CLAUDE.local.md`

While CLAUDE.md is shared via git, CLAUDE.local.md is private. This is an ideal place to dump feedback from PR reviews. By recording recurring nitpicks from human reviewers, you ensure Claude applies those specific preferences in future iterations, effectively automating your own professional growth within the project.

Scaling Expertise: Skills and Subagents

Skills as Reusable Expertise

Skills are the unit of reusable expertise, defined in .claude/skills/<name>/SKILL.md. Unlike simple commands, skills can bundle templates, reference docs, and inline shell commands (using the ! prefix).

Key advantages of skills include:

Progressive Disclosure: Only the description is loaded initially; the full instructions load only when the skill is invoked.
Explicit Control: Using disable-model-invocation: true ensures that high-impact skills (like /ship for deployment) only run when explicitly called by the user.

Subagents for Context Isolation

Subagents run in their own context window, allowing them to process large amounts of data (e.g., reading fifty files) without polluting the main session. This is particularly powerful for the Writer/Reviewer pattern: Session A implements a feature, and a pr-review subagent evaluates the work in a fresh context, free from implementation bias.

System Awareness via Model Context Protocol (MCP)

MCP transforms Claude from a coding agent into a system-aware agent. By connecting to external servers, Claude can interact with tools like GitHub, Sentry, Linear, and Figma directly from the terminal.

One advanced implementation is the Three-Tier Memory Architecture using an Obsidian MCP:

Hot Storage: Daily session logs capturing raw progress.
Warm Storage: Project-specific notes and goals.
Cold Storage: Long-term Architectural Decision Records (ADRs) and reusable knowledge atoms.

Advanced Commands and Automation

Beyond basic interaction, several underused commands significantly boost productivity:

/rewind: Restores the session to a previous checkpoint, preventing context pollution when a path leads to a dead end.
/goal: Sets a deterministic completion condition (e.g., "all tests in test/auth pass"). Combined with auto-mode and /focus, this allows the user to set a brief and walk away until the goal is met.
/batch: Fans out tasks to parallel agents across multiple git worktrees, enabling mass migrations with minimal manual overhead.

Critical Perspectives and Trade-offs

While the potential for productivity is high, the community remains divided on the "agentic" approach. Some developers argue that the overhead of maintaining .md files and orchestrating subagents introduces "accidental complexity" and that the AI should inherently understand the codebase without such hand-holding.

Others point to the risk of "SaaS lock-in," where a project's intelligence becomes trapped in a specific tool's configuration. There is also a noted tension between the speed of generation and the quality of the model; many power users prefer the slower, more deliberate output of Opus over smaller, faster models to reduce the time spent on corrections.

Ultimately, the shift is from using a tool to operating a system. The most successful users are those who treat the setup—the rules, the skills, and the verification loops—as the primary engineering task, leaving the execution to the agent.