Developer Productivity
with Claude
Learn how to build developer productivity agents that explore codebases, understand legacy systems, generate boilerplate, and automate repetitive tasks using the Agent SDK's built-in tools and MCP integrations.
Four Core Developer Jobs — Click Each
Codebase Explorer - Orientation at Speed
A developer joins a project. Instead of spending 2 days reading code, the Codebase Explorer agent maps the architecture in under 5 minutes. It uses Glob to find all key files, Read to scan entry points and config, Grep to find class definitions and routes, and Bash to check git history.
The output is a structured report: tech stack, directory annotated tree, key entry points, data flow diagram (in ASCII), and "top 3 things a new dev should know." This is a read-only agent, it never writes. Set max_turns=15 and restrict to read operations.
Select a Tool to Explore
Reads the full content of a file at the given path. Returns raw text.
| Parameter | Description |
|---|---|
| file_path | Absolute or relative path |
| offset | Optional: start from line N |
| limit | Optional: read at most N lines |
- Read config/manifest files first to orient
- Use offset+limit for large files
- Read before Write - always understand the file first
Expand Claude's Reach — Click to Explore
MCP servers extend the built-in tools with access to external systems. A developer productivity agent typically needs 3–5 MCP servers for full coverage of the dev lifecycle.
Let the agent create PRs after making changes, search for similar code across the organization, and post automated review comments.
Let the agent understand your data model by querying the schema directly, run read-only analytical queries, and generate migration scripts based on actual schema state.
Let the agent retrieve library documentation, fetch API specs, look up error messages, and check dependency versions.
Let the agent look up real production errors, read the full stack trace, then navigate directly to the relevant code to diagnose and fix the bug.
Useful when the dev agent needs to access files outside the project workspace, shared config files, monorepo access, or generating outputs to a separate docs directory.
Let the agent access secrets from Vault to populate .env files for local development or verify that all required secrets for a new feature are provisioned.
.claude/settings.json under the mcpServers key. Claude discovers available tools automatically at session start via session.list_tools().
Watch the Agent Execute Real Dev Tasks
Reference Patterns
Design Patterns — Click to Expand
The single most important rule: Read the file before writing it. An agent that writes without reading will generate code that violates the project's existing conventions.
System prompt enforcement: "Before modifying any file, Read it first. Before generating a new file of type X, Read 2 existing files of type X." This eliminates 80% of style mismatch issues.
Before doing anything else, run Glob("**") to get the complete file inventory. This takes 1 tool call and 0 content tokens - just paths. An oriented agent makes dramatically better decisions.
Analog: you wouldn't start debugging without first looking at the project structure. Glob is instant orientation at minimal cost.
After every Write, run a verification command with Bash. Run the specific test file, or at minimum run the linter. Never write 5 files and run tests once at the end.
Each Write should be followed by: Bash("npm test -- path/to/test"). If the test fails, fix immediately before writing the next file.
Any operation that touches more than 3 files is a "bulk operation." Before executing it, the agent should pause and output a proposed change manifest.
Without this, a simple "add TypeScript types everywhere" task can modify 80 files. Most will be fine, but 3 will have subtle bugs.
When you need to find something specific, all usages of a function, and all API routes use Grep. Don't read 20 files hoping to find it. Grep returns the answer in 1 tool call.
Grep use cases: finding function call sites before refactoring, discovering deprecated API usage, counting module imports, finding config key references.
The most powerful workflows combine MCP server data with built-in file tools. Example: fetch a Sentry error (MCP) - Grep for the failing function - Read the file - Write the fix - run tests (Bash).
Composition pattern: MCP tools provide external context (error traces, database schemas, PR diffs), built-in tools perform local file operations.