Architecting Frontend Systems for the AI Agent Era: Beyond the 2,000-Line Pull Request

The promise of AI-assisted engineering was fast feature delivery. The reality on many frontend teams today is a pull request queue clogged with 2,000-line monolithic diffs generated by AI coding agents.

An agent can scaffold an entire CRUD view, update three shared state stores, write five custom hooks, and modify your design system tokens in under sixty seconds. But while generating code has become nearly frictionless, reviewing, maintaining, and merging that code has become a major bottleneck.

If your frontend architecture was designed for human pacing—where developer velocity was gated by typing speed and manual context assembly—it will buckle under AI agent workflows. To harness agent velocity without suffocating in technical debt, we must redesign our frontend systems for machine authoring and human review.

---

The AI Velocity Paradox in Modern Frontend

When developers use AI agents to generate feature spikes, agents default to standard language model patterns: they modify global files, inline logic across multiple components, and introduce subtle regressions in shared utilities.

A human engineer building a new feature usually takes an iterative approach:

1. Update data models and types.
2. Add the API service layer.
3. Build UI components in isolation.
4. Wire state management and routing.

An AI agent, when given a prompt like "add bulk export capabilities to the analytics table," frequently attempts to complete all four steps in a single execution loop. The resulting pull request touches 25 files across four architectural layers.

Reviewing these massive pull requests forces senior engineers to perform mental context switching across disparate subsystems. Worse, if a single abstraction in step two is flawed, the reviewer must reject or request changes on the entire 2,000-line change.

To solve this, frontend architects must address two core problems: codebase boundary clarity and pull request topology.

---

Pattern 1: Vertical Slice Architecture for Agent Isolation

Traditional horizontal layering (separating applications strictly into /components, /hooks, /services, and /types) creates a broad blast radius. When an AI agent scans your workspace, it sees global directories and attempts to edit global files.

Switching to a Vertical Slice Architecture organizes code around distinct business domains and feature boundaries rather than technical roles.

Consider this directory model:

src/
├── features/
│   ├── analytics-export/
│   │   ├── api/
│   │   │   └── fetchExportStatus.ts
│   │   ├── components/
│   │   │   └── ExportModal.tsx
│   │   ├── hooks/
│   │   │   └── useExportTask.ts
│   │   ├── index.ts          # Strict public API surface
│   │   └── types.ts
│   └── user-management/
└── shared/
    └── ui/                    # Read-only design system primitives

By enforcing strict boundaries via lint rules (such as ESLint boundaries or dependency-cruiser), feature slices are forbidden from importing internal modules from other feature slices. They may only interact through explicitly exported public APIs (index.ts).

Why this matters for AI agents

When you target an agent using slash commands or contextual workspace scopes, you can restrict the agent's context window directly to src/features/analytics-export/.

• Reduced Hallucinations: The agent does not read unrelated business logic.
• Blast Radius Mitigation: The agent cannot inadvertently alter shared helper functions in /shared/utils without explicitly targeting them.
• Context Window Optimization: Token usage drops, improving both the accuracy and speed of the generated output.

// src/features/analytics-export/index.ts
// Explicit public contract for the feature slice
export { ExportButtonContainer } from './components/ExportButtonContainer';
export type { ExportFormat } from './types';
// Internal hooks and API helpers remain private to prevent agent cross-contamination

---

Pattern 2: Decomposing Workflows into Stacked Changesets

Once module boundaries are isolated, the next shift is operational: teaching both human engineers and AI agents to produce Stacked Pull Requests instead of single monolithic diffs.

Stacked pull requests split a complex feature into a series of small, dependent branches that build sequentially on top of one another.

For example, instead of one massive PR for an analytics export feature, the architecture requires four stacked PRs:

1. PR #101 (Base): Data models and backend contract types (feature/export-types)
2. PR #102 (Layer 1): API client abstraction and state hook (feature/export-api -> targets #101)
3. PR #103 (Layer 2): UI Presentational Components (feature/export-ui -> targets #102)
4. PR #104 (Layer 3): Integration page route and state assembly (feature/export-integration -> targets #103)

Implementing Agent Stacking in Practice

Modern agent interfaces allow multi-step orchestration. Instead of giving an agent an open-ended specification, engineer your prompt templates to enforce step-by-step execution across git branches:

# Step 1: Agent creates domain types and schema
git checkout -b feature/export-types
github-copilot-cli exec "Create TypeScript interfaces for export payloads in src/features/analytics-export/types.ts"

# Step 2: Agent builds service hooks on top of types
git checkout -b feature/export-api
github-copilot-cli exec "Build TanStack Query hooks using types in src/features/analytics-export/types.ts"

Reviewing PR #101 takes three minutes. Once approved, downstream reviews (#102, #103) become far easier because the foundational contracts are already locked down. If PR #103 requires UI changes, PR #101 and PR #102 remain unaffected and ready for merge.

---

Managing Technical Debt and Third-Party Dependencies

AI agents are inherently biased toward introducing new npm packages to solve small problems. Ask an agent to parse a CSV, and it will likely add a 50KB third-party dependency to package.json rather than utilizing existing utilities.

This introduces two critical risks: bundle bloat and supply chain security vulnerabilities.

System-Level Guardrails

To keep your architecture clean, rely on automated system checks rather than human vigilance during review:

1. Dependency Lockfile Restrictions: Configure CI pipelines to fail if an AI-generated PR modifies package.json without an explicit label or flag from an engineer.
2. Package Vetting Pipelines: Integrate automated supply chain scanning directly into your build checks. Tools scanning vulnerability databases and package health flags must block untrusted additions before code reaches human review.
3. Bundle Size Budgets: Enforce strict per-slice size limits in your bundler configuration (e.g., Vite or Webpack). If an agent's code increases feature bundle size beyond acceptable thresholds, the build fails automatically.

// Example bundlewatch or performance budget contract
{
  "files": [
    {
      "path": "dist/assets/features/analytics-export-*.js",
      "maxSize": "15 kB"
    }
  ]
}

---

The Role of the Senior Engineer Shift

When AI agents handle primary implementation details, the role of Staff and Principal Engineers pivots from writing code to defining system contracts, constraints, and architecture rules.

Your code review comments shouldn't focus on formatting or simple logic bugs—linters and agents should catch those before human eyes ever see the diff. Instead, focus on:

• Are domain boundaries respected?
• Is the state localized properly?
• Does this change conform to our team's performance and security budgets?

If an agent-generated PR is difficult to read, do not attempt to refactor it manually. Reject the stack, refine your system boundary rules, update your prompt specs, and re-run the pipeline.

---

Key Takeaways

• Monolithic AI PRs are an architectural failure mode. Large, unreviewable diffs indicate a lack of module boundaries and execution constraints.
• Vertical Slice Architecture protects codebase health. Isolating features into domain-specific modules minimizes agent blast radius and reduces token context size.
• Stacked PRs restore code review quality. Decomposing large tasks into small, dependent layers allows teams to review foundational contracts before UI assembly.
• Automate dependency and size guardrails. Prevent agent-induced bloat and supply chain risks with strict CI budgets and package lock file enforcement.

---

What You Should Do Today

1. Audit your top directory structure: Identify global catch-all folders (/utils, /helpers) and plan a migration toward domain-isolated feature slices.
2. Establish a Stacked PR workflow: Introduce tooling to streamline dependent branch creation and review for complex feature work.
3. Add linting for module boundaries: Configure strict import limits so code inside feature slices cannot reach across boundaries without explicit entry points.
4. Set up CI bundle budgets: Add automated bundle size limits on a per-route or per-feature basis to block bloated AI-generated pull requests automatically.