Phase 2: Designing the Developer Experience
ON THIS PAGE
The developer experience with AI agents is not a single workflow—it is a collection of patterns tailored to specific task domains, team structures, and project phases. This chapter covers the daily realities of working alongside agents: how to set up environments, which workflow patterns produce the best results by domain, and the prompt and interaction patterns that separate productive sessions from expensive token-burning exercises.
Environment Configuration #
Agents operating in developer environments must run within sandboxed containers, isolated from production credentials, sensitive API keys, and customer data. This is not just a security best practice—it is a practical necessity. Agents execute shell commands, install packages, and modify files as part of their normal operation. Without proper isolation, a single hallucinated rm -rf or an agent that pipes a database query to a logging endpoint can cause irreversible damage.
Recommended sandboxing approaches:
- Docker / Dev Containers: Run agent sessions inside ephemeral containers with bind-mounted source directories. The agent can modify code and run tests, but cannot reach production networks or secrets.
- Dedicated development databases: Provide agents with seeded mock data in isolated database instances. Never grant agents access to production or staging databases, even read-only—context window leaks can inadvertently expose PII.
- Scoped API keys: If the agent needs to interact with external services (payment gateways, email providers), provide sandbox/test credentials with no production access.
- Cloud sandboxes: Services like Codex and Cursor Background Agents provide pre-isolated cloud VMs. These are ideal for teams that want zero-configuration sandboxing, though they introduce latency compared to local execution.
Frontend Workflows #
Frontend development with AI agents works best when the agent has clear, machine-readable constraints rather than vague aesthetic directions. Telling an agent "make it look good" produces unpredictable results. Providing it with a design token system produces consistent, on-brand implementations.
Design tokens are the foundation. Before assigning any UI work to an agent, ensure your repository contains explicit tokens for:
- Color scales (primary, secondary, semantic colors, dark/light mode variants)
- Typography (font families, size scale, line heights, letter spacing)
- Spacing (a consistent spacing scale—4px base, 8px, 12px, 16px, 24px, 32px, 48px, 64px)
- Border radii, shadows, and animation timing functions
Accessibility standards should be encoded in the rules file as hard requirements, not aspirational guidelines. Specify the WCAG compliance level (typically 2.1 AA for enterprise applications), require semantic HTML elements over div soup, mandate keyboard navigation support, and enforce minimum contrast ratios. Agents will follow these constraints when they are stated as rules; they will ignore them when they are omitted.
Visual regression testing provides the feedback loop that keeps agent-generated UI changes from drifting. Tools that capture screenshots before and after changes, comparing them pixel-by-pixel, give agents (and reviewing humans) an immediate visual diff. Without this, frontend changes require manual visual inspection on every PR—a bottleneck that defeats the purpose of agent-assisted development.
Backend Workflows #
Backend development with agents produces the most reliable results when the contract is defined before the implementation. The golden rule: always supply documented API contracts (OpenAPI specifications) before asking an agent to implement endpoints.
When an agent has an openapi.yaml file specifying the exact request/response schemas, status codes, and error formats, it produces implementations that match the contract precisely. When it lacks this contract, it guesses—and its guesses may use different field names, different status codes, or different error structures than the frontend team expects.
Database migrations must follow additive, reversible patterns. Agents should never generate destructive migrations (dropping columns, renaming tables) without explicit human approval at a gate. Establish a rule in your rules file: "All migrations must be additive. Destructive changes (DROP, RENAME, ALTER TYPE) require a separate, human-reviewed PR with a rollback migration included."
API versioning and backward compatibility should be stated as explicit constraints. Agents tend to modify existing endpoints rather than creating versioned alternatives unless instructed otherwise. A simple rule like "Never modify the response schema of an existing API version; create a new version instead" prevents breaking changes.
Daily Workflow Patterns #
A productive day of agent-augmented development does not look like dictating instructions to a chatbot. It looks like a pair programming session where your partner has perfect recall, infinite patience, and no ego—but also no taste, no political awareness, and no understanding of what matters to your specific users.
Morning pattern: Planning and alignment. Start by reviewing yesterday's agent-generated PRs and providing feedback. Use planning skills (/grill-me) to align on today's tickets before the agent writes code. Spend 10-15 minutes front-loading context—it saves hours of correction later.
Core work pattern: Focused task loops. Assign one ticket at a time to the agent. Provide the ticket description, relevant file paths, and any additional context the agent needs. Let the agent draft an implementation plan, review the plan, approve or redirect, then let it execute. Review the resulting diff, provide targeted feedback, and iterate. Most well-scoped tickets complete in 1-3 agent loops.
Afternoon pattern: Review and refinement. Use the end of the day for human-driven review of accumulated agent work. Run the editorial and proofreading skills on any generated documentation. Perform the architectural review (Tier 2) on completed PRs. Update the rules file with any new patterns or constraints you discovered during the day.
Anti-patterns to avoid:
- "Fix everything" prompts: Vague instructions produce vague results. "Fix the authentication bugs" will produce chaotic multi-file changes. "Fix the case-sensitivity bug in TOTP verification described in AB#10820" produces a focused, reviewable diff.
- Context overloading: Do not paste your entire codebase into the conversation. Let the agent use its file-reading tools to pull in only what it needs.
- Skipping the plan: Jumping straight to "write the code" without reviewing the agent's plan is the most common source of wasted tokens and rejected PRs.
- Working without tests: If the code path you are modifying has no tests, write the tests first (or have the agent write them first), then make the change. Tests are the agent's only reliable feedback mechanism.
Prompt Patterns That Work #
Effective agent prompts share common structural elements:
The Context-Task-Constraints pattern: Start with what exists (context), state what needs to change (task), and define the boundaries (constraints).
Context: The TOTP verification endpoint at src/routes/mfa.ts currently does not
normalize user IDs to lowercase before Redis lookups.
Task: Add user ID normalization at the route handler level so that
rate_limit:mfa_verify:{userId} keys are always lowercase in Redis.
Constraints:
- Modify only src/routes/mfa.ts and src/services/rateLimiter.ts
- Add a test case in tests/integration/mfa_casing.test.ts
- Do not change the database schema
- Follow existing code style (see AGENTS.md)The "Show Me First" pattern: For complex or ambiguous tasks, ask the agent to explain its approach before writing code. "Show me your plan for implementing this, including which files you will modify and what changes you will make in each, before writing any code." This prevents the agent from committing to an approach that you would have redirected.