Software engineer Shrivu Shankar published a detailed account of how he uses Claude Code, presenting the coding agent less as an interactive assistant and more as a system for delegated work. His central measure is the resulting pull request, not the tone or appearance of the intermediate conversation.
The guide draws on two different settings. For personal projects, Shankar says he runs Claude Code in a virtual machine several times a week. Professionally, he works with a team responsible for AI-assisted development rules and tooling used by engineers generating several billion tokens of code-related activity each month. Those experiences inform an opinionated workflow rather than a controlled comparison of available coding agents.
At the repository level, Shankar treats the root `CLAUDE.md` file as the primary operating brief. He recommends beginning with a small set of guardrails based on mistakes the agent actually makes, then adding pointers to specialized documentation only when needed. In his professional monorepo, the maintained file is about 13 KB and generally covers tools or interfaces used by at least 30 percent of engineers. Narrower instructions remain closer to the relevant product or library.
The guide warns against automatically embedding large documentation files because doing so consumes context on every run. Instead, it suggests naming a document, explaining the circumstances in which it matters and giving the agent a reason to consult it. Negative rules should also include a usable alternative, so a restriction does not leave the agent without a path forward. Shankar further recommends simplifying awkward internal commands behind clearer wrappers instead of compensating with lengthy prose. His team keeps `CLAUDE.md` synchronized with `AGENTS.md` for compatibility with other AI development tools.
Context management receives similar scrutiny. Shankar advises checking `/context` during a session and says a fresh run in his monorepo begins with roughly 20,000 of a 200,000-token window already occupied. He avoids relying on opaque automatic compaction. For a routine restart, his preferred pattern is to clear the session and use a custom catch-up command that asks the agent to inspect branch changes. For more complex work, he first records the plan and progress in a Markdown file, then starts a clean session from that durable handoff.
He applies restraint to custom slash commands and subagents as well. His shortcuts focus on branch review and pull-request preparation, while his discussion of subagents notes a tradeoff: delegated tasks can preserve the main context, but specialized agents can also hide information needed for whole-change reasoning. The guide’s broader recommendation is to externalize essential context, simplify the surrounding tooling and evaluate agents by verifiable engineering outcomes.
