DX Optimizer Mentor

A senior developer experience agent that enhances developer productivity and happiness by optimizing build systems, development servers, IDE configuration, and workflow automation to create frictionless development experiences.

When to Use This Agent

Choose DX Optimizer Mentor when:

• Development feedback loops are too slow (build, test, reload)
• Onboarding new developers takes more than a day
• Developers spend too much time on tooling issues instead of features
• IDE and editor configurations need standardization across the team
• Local development environment setup is fragile or undocumented

Consider alternatives when:

• Optimizing production performance (use a performance engineering agent)
• Setting up CI/CD pipelines (use a DevOps agent)
• Fixing a specific build error (use a build engineering agent)

Quick Start

Copy
# .claude/agents/dx-optimizer-mentor.yml
name: DX Optimizer Mentor
description: Optimize developer experience and productivity
model: claude-sonnet
tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep

Example invocation:

claude "Analyze our development workflow and identify the top 5 developer experience improvements that would save the most time across the team"

Core Concepts

DX Assessment Framework

Area	Metrics	Target
Setup	Time from clone to running app	<15 minutes
Build	Incremental build time	<2 seconds
Test	Unit test feedback time	<5 seconds
Reload	Hot reload / HMR response	<500ms
Deploy	Time from merge to production	<30 minutes
Debug	Time to reproduce an issue	<5 minutes

Development Environment Optimization

Copy
// .vscode/settings.json — Team-shared settings
{
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit",
    "source.organizeImports": "explicit"
  },
  "typescript.preferences.importModuleSpecifier": "non-relative",
  "typescript.tsdk": "node_modules/typescript/lib",
  "search.exclude": {
    "**/node_modules": true,
    "**/dist": true,
    "**/.next": true,
    "**/coverage": true
  },
  "files.watcherExclude": {
    "**/node_modules/**": true,
    "**/dist/**": true,
    "**/.git/objects/**": true
  }
}

Fast Feedback Loop Setup

Copy
// vitest.config.ts — Optimized for fast iteration
import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    globals: true,
    environment: 'node',
    include: ['src/**/*.test.ts'],
    watch: true,
    // Only re-run tests related to changed files
    passWithNoTests: true,
    coverage: {
      provider: 'v8',  // Faster than istanbul
      reportsDirectory: './coverage',
    },
    // Parallelize test execution
    pool: 'threads',
    poolOptions: {
      threads: { minThreads: 2, maxThreads: 8 },
    },
  },
});

Configuration

Parameter	Description	Default
focus_area	Primary DX area to optimize	All areas
team_size	Number of developers on the team	Auto-detect
ide	Primary IDE (vscode, webstorm, neovim)	vscode
os_platforms	OS platforms to support (mac, linux, windows)	["mac", "linux"]
containerized	Use containerized dev environment	false
automation_level	Level of automation (minimal, standard, full)	standard

Best Practices

1. Measure before optimizing — instrument the development workflow. Add timing to build steps, test runs, and deployment stages. Many teams assume builds are slow when the bottleneck is actually test execution or dependency installation. Measure the end-to-end time from saving a file to seeing the change in the browser. Optimize the measured bottleneck, not the assumed one.

2. Automate the "first day" setup to a single command. Create a make setup or ./scripts/setup.sh that installs all dependencies, configures the local environment, seeds the database, and starts the development server. Test this script monthly by running it on a clean machine. The setup script is documentation that actually works — it cannot become outdated because it is executed.

3. Share IDE configurations in the repository, not in wikis. Commit .vscode/settings.json, .vscode/extensions.json, .editorconfig, and prettier.config.js to the repository. This ensures every developer has the same formatting, linting, and editor behavior. When configurations change, they flow through the normal PR review process. IDE settings in wiki pages become stale and create inconsistency.

4. Minimize the time between file save and visible feedback. The core developer experience loop is: edit → save → see result. Every second in this loop multiplies across thousands of daily iterations. Use HMR for frontend, incremental compilation for TypeScript, and watch mode for tests. If any step takes more than 2 seconds, investigate. The difference between 0.5s and 5s feedback fundamentally changes how developers work.

5. Create project-specific scripts for common tasks and document them in package.json. Every task a developer does more than twice should be a package.json script: npm run dev, npm run test:watch, npm run db:reset, npm run lint:fix. Scripts are discoverable via npm run and self-documenting. They prevent the "how do I run X?" question and ensure everyone runs tasks the same way.

Common Issues

Hot reload breaks after certain types of changes. Changes to configuration files, environment variables, or certain module types often bypass HMR and require a full restart. Document which files require restarting the dev server. Better yet, configure the file watcher to auto-restart when these files change. In Next.js, changes to next.config.js require a restart; in Vite, changes to vite.config.ts trigger an automatic restart.

Development environment works on Mac but fails on Linux/Windows. Case-insensitive file systems (Mac/Windows) mask import path errors that break on case-sensitive Linux (CI). Forward slashes vs. backslashes break path handling on Windows. Fix by using consistent import casing, using path.join() instead of string concatenation, and running CI on the same OS as production. Add a CI check that detects case-sensitivity issues.

Docker-based development is too slow for interactive workflows. Docker adds I/O overhead, especially on macOS where file system mounts are significantly slower than native. For development, run the application natively and only containerize external dependencies (databases, queues, caches) with Docker Compose. Reserve fully containerized development for situations requiring exact environment parity (debugging Linux-specific issues).