AI Pair Programming Workflow Patterns: Effective Copilot Usage for Frontend Developers

Real-World Problem Context

A senior frontend developer adopts GitHub Copilot and an AI coding assistant (Cursor, Cline, or similar). Initially, productivity spikes — boilerplate code appears instantly, test scaffolding is auto-generated, CSS patterns are suggested before they're typed. But after a month, problems emerge: Copilot suggests an outdated React pattern (class components in a hooks codebase), generates a useEffect with missing dependencies that causes an infinite loop, produces a CSS solution using deprecated -webkit- prefixes, and writes a fetch call without error handling that passes code review because "the AI wrote it." The developer realizes that effective AI pair programming isn't about accepting every suggestion — it's about understanding when AI excels, when it fails, and developing workflow patterns that amplify productivity while catching AI mistakes. This post covers the practical patterns, anti-patterns, and architectural decisions for integrating AI coding assistants into daily frontend development.

---

Problem Statements

1. Prompt Engineering for Code: How do you write effective prompts that produce correct, idiomatic code for your specific codebase? What context does the AI need (types, existing patterns, conventions), and how do you provide it efficiently?

2. Verification Workflow: How do you verify AI-generated code quickly without reading every line? What are the common failure modes for frontend AI suggestions, and what automated checks catch them?

3. Architectural Integration: How do you structure your codebase, documentation, and tooling to maximize AI assistant effectiveness? What project-level decisions (file organization, type coverage, naming conventions) make AI suggestions better?

---

Deep Dive: Internal Mechanisms

1. How AI Code Completion Actually Works

/*
 * Understanding the internals helps you write better prompts
 * and predict when the AI will fail.
 *
 * Context Window:
 * ┌──────────────────────────────────────────────────┐
 * │ What Copilot sees when suggesting code:           │
 * │                                                   │
 * │ 1. Current file (primary context)                 │
 * │    - Code ABOVE the cursor (strongest signal)     │
 * │    - Code BELOW the cursor (weaker signal)        │
 * │    - File name and path (infers purpose)          │
 * │                                                   │
 * │ 2. Open tabs (secondary context)                  │
 * │    - Related files you have open                  │
 * │    - Types, interfaces, similar components        │
 * │                                                   │
 * │ 3. Repository context (for chat/agent modes)      │
 * │    - Indexed codebase embeddings                  │
 * │    - README, docs, config files                   │
 * │                                                   │
 * │ The AI does NOT see:                              │
 * │    - Files you don't have open                    │
 * │    - Runtime behavior (actual API responses)      │
 * │    - Your git history or PR context               │
 * │    - Your team's verbal conventions               │
 * └──────────────────────────────────────────────────┘
 *
 * Token budget (approximate, varies by model):
 *   - Copilot inline: ~8K tokens context
 *   - Copilot chat: ~32K tokens context
 *   - Cursor/Cline: ~128K+ tokens context
 *
 * Implication: if context is wrong, suggestion is wrong.
 * The AI is a PATTERN MATCHER over its visible context.
 */

// Example: WHY Copilot suggests the wrong pattern

// File: UserProfile.tsx (new file, no other context)
// Copilot might suggest a class component because:
// 1. "UserProfile" matches millions of class component examples in training data
// 2. No other files open showing hooks patterns
// 3. No TypeScript types constraining the output

// Fix: Open a similar component file in another tab
// → Copilot sees the hooks pattern → suggests hooks

// Better fix: Have a component template comment:
// This is a React functional component using hooks.
// It follows the pattern in src/components/ExampleComponent.tsx

2. The Prompt-Code-Verify Loop

/*
 * Effective AI pair programming follows a tight loop:
 *
 * ┌──────────────────────────────────────────────────┐
 * │ 1. PRIME  → Set up context before asking         │
 * │    │                                              │
 * │    ▼                                              │
 * │ 2. PROMPT → Ask with specific constraints         │
 * │    │                                              │
 * │    ▼                                              │
 * │ 3. SCAN   → Quick structural check (10 seconds)  │
 * │    │                                              │
 * │    ▼                                              │
 * │ 4. VERIFY → Automated checks (lint, type, test)  │
 * │    │                                              │
 * │    ▼                                              │
 * │ 5. REFINE → Fix issues or re-prompt              │
 * └──────────────────────────────────────────────────┘
 *
 * ANTI-PATTERN: Accept → Ship (no verification)
 * ANTI-PATTERN: Read every line word-by-word (defeats purpose)
 * PATTERN: Structured quick checks + automated verification
 */

// STEP 1: PRIME — Set context before writing any code

// Open relevant files in tabs:
// - The component you're building (even if empty)
// - A similar existing component (pattern reference)
// - The TypeScript types/interfaces being used
// - The CSS module or styled-components file

// Add a "context header" comment:
/**
 * UserDashboard component
 * 
 * Requirements:
 * - Displays user stats (posts, followers, following)
 * - Uses the useUser() hook from src/hooks/useUser.ts
 * - Follows Card layout pattern from src/components/StatsCard.tsx
 * - Responsive: 3-column on desktop, stacked on mobile
 * - Uses design tokens from src/tokens.css
 * 
 * Data shape: { posts: number, followers: number, following: number }
 */

// STEP 2: PROMPT — Be specific about constraints

// ❌ Vague prompt (in chat):
// "make a dashboard component"

// ✅ Specific prompt:
// "Create a UserDashboard component that:
//  - Takes { userId: string } props
//  - Calls useUser(userId) which returns { data: User | null, isLoading: boolean }
//  - Renders 3 StatsCard components in a CSS Grid
//  - Uses var(--spacing-lg) for gap
//  - Shows a Skeleton component during loading
//  - Follows the same pattern as src/components/TeamDashboard.tsx
//  - Don't add error handling — the parent ErrorBoundary handles that"

3. Context Engineering: Making AI Suggestions Better

/*
 * "Context engineering" = structuring your codebase so AI
 * has the right information when suggesting code.
 *
 * High-impact strategies (ranked by effort → impact):
 */

// STRATEGY 1: Type-first development
// AI suggestions are dramatically better with TypeScript types.
// The types constrain what the AI can suggest.

// Without types:
function processUser(user) {
    // AI doesn't know what 'user' contains
    // Might suggest user.firstName (wrong) or user.name (right)
}

// With types:
interface User {
    id: string;
    name: string;
    email: string;
    role: 'admin' | 'user' | 'viewer';
    createdAt: Date;
}

function processUser(user: User): ProcessedUser {
    // AI KNOWS the exact shape → suggestions are accurate
    // user. ← autocomplete shows id, name, email, role, createdAt
}

// STRATEGY 2: Descriptive file and function names
// File name IS context for the AI.

// ❌ utils.ts → AI has no idea what utilities to suggest
// ✅ formatCurrency.ts → AI knows exactly what to generate

// ❌ function handle(data) → AI guesses what 'handle' means
// ✅ function validateCheckoutForm(formData: CheckoutFormData) → perfect context

// STRATEGY 3: Co-located examples and patterns
// Keep a PATTERNS.md or examples directory that AI can reference:

/*
 * src/
 * ├── patterns/
 * │   ├── component-template.tsx    ← AI reads this for new components
 * │   ├── hook-template.ts          ← AI reads this for new hooks
 * │   ├── test-template.test.tsx    ← AI reads this for test structure
 * │   └── api-route-template.ts     ← AI reads this for API patterns
 * ├── components/
 * └── hooks/
 */

// STRATEGY 4: .cursorrules / .github/copilot-instructions.md
// Project-level AI configuration:

// .github/copilot-instructions.md:
`
# Copilot Instructions for this project

## Stack
- React 19 with Server Components
- TypeScript strict mode
- Tailwind CSS v4
- Vitest for testing
- Zustand for client state

## Conventions
- Functional components only (no class components)
- Use 'use client' directive only when necessary
- Prefer server components by default
- Use Tailwind utilities, not CSS modules
- Error boundaries at route level, not component level
- Use React.Suspense for loading states, not isLoading booleans

## File structure
- Components: src/components/{ComponentName}/{ComponentName}.tsx
- Hooks: src/hooks/use{HookName}.ts
- Types: co-located in the same file, not in a types/ directory
- Tests: co-located as {Component}.test.tsx

## Anti-patterns to avoid
- Don't use useEffect for data fetching (use server components or React Query)
- Don't use index as key in lists
- Don't use any type — use unknown and narrow
- Don't import from barrel files (import from specific files)
`;

4. Frontend-Specific AI Failure Modes

/*
 * AI coding assistants have predictable failure modes
 * in frontend code. Knowing these lets you catch errors quickly.
 *
 * ┌──────────────────────────────────────────────────┐
 * │ Failure Mode          │ Frequency │ Severity     │
 * │───────────────────────│──────────│─────────────│
 * │ Stale API/patterns    │ Very High │ Medium       │
 * │ Missing dependencies  │ High      │ High         │
 * │ Wrong hook rules      │ High      │ High         │
 * │ Accessibility gaps    │ Very High │ Medium       │
 * │ Security blindness    │ Medium    │ Critical     │
 * │ Over-engineering      │ High      │ Low          │
 * │ Phantom imports       │ Medium    │ Medium       │
 * │ State sync bugs       │ Medium    │ High         │
 * └──────────────────────────────────────────────────┘
 */

// FAILURE 1: Stale patterns
// AI trained on older code → suggests outdated patterns

// AI suggests (React 16 pattern):
useEffect(() => {
    fetchData().then(setData);
}, []);
// Problem: Should use React Query, SWR, or server component

// AI suggests (old Next.js):
export async function getServerSideProps() { ... }
// Problem: Should use App Router server components

// DETECTION: ESLint rules that ban deprecated patterns
// .eslintrc:
const eslintConfig = {
    rules: {
        'no-restricted-syntax': ['error', {
            selector: 'ExportNamedDeclaration > FunctionDeclaration[id.name="getServerSideProps"]',
            message: 'Use App Router server components instead of getServerSideProps',
        }],
    },
};

// FAILURE 2: useEffect dependency arrays
// AI frequently gets these wrong:

// AI generates:
useEffect(() => {
    const filtered = items.filter(item => item.category === selectedCategory);
    setFilteredItems(filtered);
}, []); // ❌ Missing items and selectedCategory

// DETECTION: eslint-plugin-react-hooks (exhaustive-deps rule)
// This is the #1 most important lint rule for AI-generated React code.

// FAILURE 3: Accessibility gaps
// AI almost never adds proper ARIA attributes unprompted:

// AI generates:
<div onClick={handleClick} className="button">Click me</div>
// Missing: role="button", tabIndex={0}, onKeyDown, aria-label

// DETECTION: eslint-plugin-jsx-a11y + axe-core in tests

// FAILURE 4: Security blindness
// AI generates working code that's insecure:

// AI generates:
<div dangerouslySetInnerHTML={{ __html: userComment }} />
// XSS vulnerability — AI doesn't see the security context

// AI generates:
const url = `/api/users/${userId}`;
// If userId comes from URL params, this could be a path traversal

// DETECTION: Custom ESLint rules + security-focused code review checklist

5. The Verification Checklist

/*
 * After AI generates code, run this 30-second checklist
 * before accepting. Prioritized by risk.
 *
 * ┌──────────────────────────────────────────────────┐
 * │ 10-SECOND SCAN (visual check):                   │
 * │                                                   │
 * │ □ Does it import real modules? (not hallucinated) │
 * │ □ Does it match our naming convention?            │
 * │ □ Is it using the right state management?         │
 * │ □ Any dangerouslySetInnerHTML or eval()?          │
 * │ □ Are hook dependencies listed?                   │
 * │                                                   │
 * │ 20-SECOND AUTOMATED CHECK:                        │
 * │                                                   │
 * │ □ TypeScript compiles (tsc --noEmit)              │
 * │ □ ESLint passes (especially react-hooks rules)    │
 * │ □ Prettier formats without changes                │
 * │ □ Existing tests still pass                       │
 * └──────────────────────────────────────────────────┘
 */

// Automated verification script:
// package.json:
{
    "scripts": {
        "verify": "concurrently \"tsc --noEmit\" \"eslint --quiet .\" \"vitest run --reporter=dot\"",
        "verify:quick": "tsc --noEmit && eslint --cache --quiet ."
    }
}

// VS Code task for instant feedback:
// .vscode/tasks.json:
{
    "version": "2.0.0",
    "tasks": [{
        "label": "Verify AI Code",
        "type": "shell",
        "command": "npm run verify:quick",
        "problemMatcher": ["$tsc", "$eslint-stylish"],
        "group": { "kind": "test", "isDefault": true },
        "presentation": { "reveal": "silent", "clear": true }
    }]
}
// Bind to Cmd+Shift+T → verify after every AI accept

// Pre-commit hook that catches AI mistakes:
// .husky/pre-commit:
`#!/bin/sh
npx lint-staged`

// lint-staged.config.js:
module.exports = {
    '*.{ts,tsx}': [
        'eslint --fix --max-warnings=0',
        'tsc-files --noEmit',  // Type-check only changed files
    ],
    '*.{ts,tsx,css}': 'prettier --write',
};

6. Prompt Patterns for Common Frontend Tasks

/*
 * Proven prompt templates for recurring frontend tasks.
 * These work across Copilot, Cursor, and ChatGPT.
 */

// PATTERN 1: Component Generation
// → Provide: types, similar component, constraints
`Create a ${ComponentName} component that:
- Props: ${paste TypeScript interface}
- Follows the pattern in ${similar component path}
- Uses ${styling approach} for styles
- Handles loading with Suspense (no isLoading prop)
- Include: ${specific features}
- Exclude: ${things you DON'T want}`;

// PATTERN 2: Hook Extraction
// → Provide: the component code, what to extract
`Extract the ${feature} logic from this component into a custom hook:

${paste component code}

The hook should:
- Be named use${Feature}
- Return { ${list return values} }
- Handle cleanup in the return function
- Be generic enough to reuse in ${other component}`;

// PATTERN 3: Test Generation
// → Provide: component code, what to test, testing library
`Write tests for this component using Vitest + React Testing Library:

${paste component code}

Test these scenarios:
1. Renders correctly with default props
2. ${specific interaction test}
3. ${edge case}
4. Handles error state from ${hook/API}

Use:
- screen.getByRole() over getByTestId()
- userEvent over fireEvent
- Mock ${specific dependency} with vi.mock()
- Don't test implementation details`;

// PATTERN 4: Refactoring
// → Provide: current code, target pattern, constraints
`Refactor this component from ${current pattern} to ${target pattern}:

${paste code}

Constraints:
- Don't change the public API (same props)
- Keep all existing test cases passing
- Use ${specific library/pattern}
- The component is used in: ${list parents}`;

// PATTERN 5: Bug Fix
// → Provide: bug description, reproduction, relevant code
`Fix this bug:

Symptom: ${what happens}
Expected: ${what should happen}
Reproduction: ${steps}

Relevant code:
${paste code}

The issue is likely in ${suspected area}.
Don't change ${things that should stay the same}.`;

7. AI-Assisted Code Review

/*
 * Using AI to review code (yours or others') —
 * but with structured prompts that prevent "looks good" responses.
 */

// Code review prompt template:
const CODE_REVIEW_PROMPT = `Review this React/TypeScript code for a production frontend app.

CHECK EACH CATEGORY and list specific issues found:

## 1. Correctness
- Hook dependency arrays complete?
- State updates batched correctly?
- Event handlers cleaned up?
- Conditional rendering edge cases?

## 2. Performance
- Unnecessary re-renders? (missing memo, inline objects in JSX)
- Large objects in dependency arrays?
- Missing code splitting opportunities?
- N+1 query patterns in list rendering?

## 3. Accessibility
- Semantic HTML elements used?
- ARIA attributes where needed?
- Keyboard navigation works?
- Focus management on route changes?

## 4. Security
- User input sanitized?
- No dangerouslySetInnerHTML with user data?
- API keys or secrets exposed?
- CSRF/XSS vectors?

## 5. Maintainability
- Types specific enough (no 'any')?
- Component does one thing?
- Naming clear and consistent?

For each issue, provide:
- File and line reference
- What's wrong
- How to fix it

If a category has no issues, say "No issues found."

CODE TO REVIEW:
`;

// Automated PR review bot integration:
async function reviewPRWithAI(prDiff, projectRules) {
    const prompt = CODE_REVIEW_PROMPT + prDiff + `

PROJECT-SPECIFIC RULES:
${projectRules}

Focus on issues that a human reviewer might miss.
Don't flag style issues (Prettier/ESLint handles those).`;
    
    const review = await callLLM(prompt, {
        model: 'gpt-4o',
        temperature: 0.1,
        maxTokens: 2000,
    });
    
    // Parse issues and filter by severity:
    const issues = parseReviewIssues(review);
    
    // Only comment on high-confidence issues:
    return issues.filter(i => i.severity !== 'nit');
}

8. Multi-File Editing Patterns

/*
 * AI assistants (Cursor, Cline) can edit multiple files.
 * This requires careful task decomposition.
 *
 * ┌──────────────────────────────────────────────────┐
 * │ ANTI-PATTERN: "Add a new feature to the app"     │
 * │                                                   │
 * │ Problem: too vague → AI makes wrong assumptions   │
 * │ about file structure, state management, routing    │
 * │                                                   │
 * │ PATTERN: Decompose into file-level tasks          │
 * │                                                   │
 * │ 1. "Create types in src/types/search.ts:          │
 * │     interface SearchResult { ... }"               │
 * │                                                   │
 * │ 2. "Create hook in src/hooks/useSearch.ts          │
 * │     that calls GET /api/search?q={query}          │
 * │     and returns SearchResult[]"                   │
 * │                                                   │
 * │ 3. "Create SearchBar component in                 │
 * │     src/components/SearchBar/SearchBar.tsx         │
 * │     using the useSearch hook"                     │
 * │                                                   │
 * │ 4. "Add SearchBar to the Header component         │
 * │     in src/components/Header/Header.tsx"          │
 * │                                                   │
 * │ Each step: small, specific, verifiable.           │
 * └──────────────────────────────────────────────────┘
 */

// Effective multi-file prompt (for Cursor/Cline agent mode):
const MULTI_FILE_PROMPT = `
## Task
Add search functionality to the app.

## Files to create/modify
1. CREATE src/types/search.ts — SearchResult and SearchParams types
2. CREATE src/hooks/useSearch.ts — hook using React Query
3. CREATE src/components/SearchBar/SearchBar.tsx — component
4. CREATE src/components/SearchBar/SearchBar.test.tsx — tests
5. MODIFY src/components/Header/Header.tsx — add SearchBar

## Constraints
- Use existing pattern from src/hooks/useUser.ts for the hook
- Use existing pattern from src/components/FilterBar/FilterBar.tsx for the component
- React Query with suspense: true
- Debounce search input by 300ms using use-debounce
- Don't add any new dependencies

## Type definitions
interface SearchResult {
  id: string;
  title: string;
  excerpt: string;
  url: string;
  score: number;
}

interface SearchParams {
  query: string;
  limit?: number;
  offset?: number;
}

## API
GET /api/search?q={query}&limit={limit}&offset={offset}
Response: { results: SearchResult[], total: number }
`;

9. When NOT to Use AI

/*
 * AI pair programming has clear zones of effectiveness:
 *
 * ┌──────────────────────────────────────────────────┐
 * │ AI Excels At:                    │ AI Struggles With:     │
 * │─────────────────────────────────│──────────────────────│
 * │ Boilerplate code                │ Business logic         │
 * │ CRUD operations                 │ Complex state machines │
 * │ Test scaffolding                │ Performance debugging  │
 * │ CSS from description            │ Architecture decisions │
 * │ Type definitions from examples  │ Security-critical code │
 * │ Regex patterns                  │ Multi-system integration│
 * │ Data transformations            │ Race conditions        │
 * │ Documentation                   │ Debugging production   │
 * │ API client generation           │ Database migrations    │
 * │ Config files                    │ Breaking change analysis│
 * └──────────────────────────────────────────────────┘
 *
 * Rule of thumb:
 *   If the code is MECHANICAL (transforms, CRUD, patterns),
 *   AI saves you time.
 *
 *   If the code requires JUDGMENT (architecture, security, perf),
 *   AI gives you a starting point but you make the decisions.
 *
 *   If the code is NOVEL (new algorithm, unique business logic),
 *   AI often wastes your time.
 */

// Example: AI excels at this (mechanical):
// "Convert this REST API response to our frontend model"
function mapApiResponseToUser(response: ApiUserResponse): User {
    return {
        id: response.user_id,
        name: `${response.first_name} ${response.last_name}`,
        email: response.email_address,
        role: mapRole(response.role_code),
        createdAt: new Date(response.created_at),
    };
}
// AI generates this instantly and correctly from types.

// Example: AI struggles with this (judgment):
// "Design the state management for a real-time collaborative editor"
// → AI will suggest a basic approach that doesn't handle:
//   - Operational transform / CRDT conflicts
//   - Cursor position synchronization
//   - Undo/redo across collaborators
//   - Network partition recovery
// → You need to make the architectural decisions

10. Measuring AI Effectiveness

/*
 * Track whether AI is actually helping or creating
 * more review/fix work than it saves.
 *
 * Metrics to track:
 *
 * 1. Acceptance rate: % of suggestions accepted
 *    - Below 20% → context is bad, fix your setup
 *    - 20-40% → normal for complex codebases
 *    - Above 40% → AI is well-configured for your project
 *
 * 2. Revert rate: % of AI code that gets reverted/rewritten
 *    - Above 10% → verification process is insufficient
 *
 * 3. Bug attribution: bugs from AI vs human code
 *    - Track via commit metadata or PR labels
 *
 * 4. Time savings: actual measurement, not feeling
 */

// Simple tracking (add to your git hooks):
// .husky/prepare-commit-msg — tag AI-assisted commits:

function tagAICommit(commitMsgFile) {
    const msg = fs.readFileSync(commitMsgFile, 'utf8');
    
    // Check if Copilot/Cursor was active during this session:
    const aiActive = checkAIAssistantActive(); // Check process list or extension state
    
    if (aiActive) {
        // Add trailer to commit message:
        const tagged = msg.trimEnd() + '\n\nAI-Assisted: true\n';
        fs.writeFileSync(commitMsgFile, tagged);
    }
}

// Weekly metrics script:
function analyzeAIMetrics(since = '1 week ago') {
    const log = execSync(
        `git log --since="${since}" --format="%H %s" --all`,
        { encoding: 'utf8' }
    );
    
    const commits = log.trim().split('\n').map(line => {
        const [sha, ...msgParts] = line.split(' ');
        const msg = msgParts.join(' ');
        
        const body = execSync(`git show -s --format=%b ${sha}`, { encoding: 'utf8' });
        const aiAssisted = body.includes('AI-Assisted: true');
        
        return { sha, msg, aiAssisted };
    });
    
    const aiCommits = commits.filter(c => c.aiAssisted);
    const humanCommits = commits.filter(c => !c.aiAssisted);
    
    // Check revert rate:
    const reverts = commits.filter(c => c.msg.startsWith('Revert'));
    const aiReverts = reverts.filter(r => {
        // Check if the reverted commit was AI-assisted:
        const revertedSha = extractRevertedSha(r.msg);
        return aiCommits.some(c => c.sha.startsWith(revertedSha));
    });
    
    return {
        totalCommits: commits.length,
        aiAssisted: aiCommits.length,
        aiPercentage: (aiCommits.length / commits.length * 100).toFixed(1),
        revertRate: (aiReverts.length / Math.max(aiCommits.length, 1) * 100).toFixed(1),
    };
}

/*
 * Team-level workflow recommendations:
 *
 * 1. Share .cursorrules / copilot-instructions across the team
 * 2. Add AI-specific lint rules (catch common AI mistakes)
 * 3. Include "AI-generated?" in PR template checklist
 * 4. Run AI metrics monthly → adjust instructions
 * 5. Maintain a "AI gotchas" doc with project-specific failures
 *
 * The goal isn't 100% AI code — it's EFFICIENT human+AI code
 * where the human makes architectural decisions and the AI
 * handles mechanical implementation.
 */

---

Trade-offs & Considerations

---

Best Practices

1. Invest in context engineering over prompt engineering — your codebase structure matters more than clever prompts — strong TypeScript types, descriptive file names, co-located pattern templates, and project-level AI instructions (.github/copilot-instructions.md, .cursorrules) provide persistent context that improves every suggestion; a well-typed codebase with a patterns directory gets better AI suggestions with zero-effort prompts than a loosely-typed codebase with elaborate prompts.

2. Run automated verification after every AI code acceptance — TypeScript, ESLint, and tests are your safety net — bind tsc --noEmit && eslint . to a keyboard shortcut and run it after accepting any non-trivial AI suggestion; the react-hooks/exhaustive-deps rule alone catches the most common AI mistake in React code; pre-commit hooks with lint-staged provide a final safety net before code enters the repository.

3. Decompose multi-file tasks into single-file steps with explicit types and constraints — AI agents handling multi-file edits make compounding errors: a wrong type in file 1 cascades to wrong implementations in files 2-5; break features into typed interfaces first, then hooks, then components, then integration; verify each step before proceeding to the next.

4. Know when to stop using AI and write the code yourself — judgment code, security code, and novel logic are human territory — AI excels at mechanical code (data transforms, CRUD, test scaffolding, CSS) and struggles with architectural decisions, race conditions, security-critical paths, and novel business logic; using AI for these domains often creates more fix-up work than manual coding.

5. Track AI effectiveness metrics and adjust — if acceptance rate is below 20% or revert rate is above 10%, fix your setup — tag AI-assisted commits with metadata, measure acceptance rates, track bug attribution to AI vs human code, and review metrics monthly; use the data to update project-level AI instructions, add lint rules for recurring AI mistakes, and maintain a team "AI gotchas" document.

---

Conclusion

Effective AI pair programming for frontend development is a workflow discipline, not a tool installation. The AI code completion model works from a context window of the current file, open tabs, and (in agent mode) indexed repository — if that context is wrong or incomplete, suggestions will be wrong. Context engineering (strong TypeScript types, descriptive naming, co-located pattern templates, project-level instructions) provides persistent improvement to every suggestion. The prompt-code-verify loop structures each interaction: prime context by opening relevant files, prompt with specific constraints and anti-requirements ("don't use useEffect for fetching"), scan the output for the five common frontend AI failure modes (stale patterns, missing hook dependencies, accessibility gaps, security blindness, phantom imports), and verify with automated tooling (TypeScript compiler, ESLint with react-hooks rules, existing tests). Multi-file edits require decomposition into typed, single-file steps with verification gates between them. The measurable outcome is acceptance rate (20-40% is normal, below 20% means fix your context setup) and revert rate (above 10% means fix your verification process). AI handles mechanical code — data transforms, CRUD, test scaffolding, CSS — at 3-10x human speed; humans handle judgment code — architecture, security, novel logic — where AI creates more fix-up work than it saves.