Why Vertical Slice Architecture Fits AI-Assisted Development: One Slice = One Context

• Target audience: Software engineers involved in architecture decisions, tech leads, and developers who use AI coding tools (Claude Code, Cursor, Copilot) daily
• Prerequisites: Familiarity with layered architecture, Clean Architecture, DDD, and basic experience with AI coding tools
• Reading time: 25 minutes

Overview

As LLM-powered coding tools like GitHub Copilot, Cursor, and Claude Code become embedded in everyday development, the question “which architecture pairs best with AI-assisted coding?” has shifted from theoretical curiosity to a practical design decision.

The answer that has gained increasing attention is Vertical Slice Architecture (VSA)¹, proposed by Jimmy Bogard in 2018. VSA organizes code by feature rather than by technical layer, packaging everything required to fulfill a single request—UI, API handler, business logic, data access, tests—into one self-contained slice.

This structure aligns naturally with the unit of “context” you hand to an AI coding tool. Rick Hightower wrote in April 2025 that VSA enables “simplified context management” because “all code relevant to a specific feature is contained within a single directory,” making it easier for AI tools to grasp the complete picture and significantly reducing token consumption². Basti Ortiz made a similar point in early 2026: coding agents traverse repositories depth-first, and feature-oriented vertical structures match that exploration pattern³.

VSA is not a silver bullet, however. It tends to produce code duplication, requires care in managing shared logic, and there are documented cases of Copilot disrupting the slice structure when not properly guided⁴. This article returns to Bogard’s original definition, contrasts VSA with Layered/Clean/FSD/CQRS approaches, examines the evidence behind its AI affinity, and surveys implementation patterns in Next.js and Go—then closes with the realistic limitations.

What Vertical Slice Architecture Actually Is

Returning to Bogard’s Original Definition

Bogard’s original April 2018 article¹ is a short blog post, but it crystallizes the design principle in a single sentence:

“Minimize coupling between slices, and maximize coupling in a slice.”

A “slice” here means a distinct request—an HTTP request, a use case, a single command or query. Every concern needed to fulfill that request, from the front end through the back end to data access, lives together as a unit.

What Bogard wanted to fix were three persistent problems with traditional layered architectures:

1. Cross-cutting change cost: Adding a single feature requires editing across Controller → Service → Repository, scattering the change throughout the codebase.
2. Excessive abstraction: Patterns like Repository force features with genuinely different requirements into one shared shape.
3. Mock proliferation: Every layer boundary becomes another interface that tests must mock.

VSA solves these by coupling along the axis of change. To change one feature, you open one slice folder and find UI, API handler, business logic, and data access already collocated¹.

A Typical Folder Structure

The exact layout varies by language and framework, but the shape is consistent:

features/
├── creating_product/
│   ├── command.go         # Command object
│   ├── handler.go         # Business logic
│   ├── endpoint.go        # API endpoint
│   ├── dto.go             # Input/output data
│   └── handler_test.go    # Tests
├── getting_product_by_id/
│   ├── query.go
│   ├── handler.go
│   ├── endpoint.go
│   └── dto.go
└── updating_product_price/
    └── ...
shared/                    # Truly shared code only, kept minimal

This example follows the Go VSA template⁵, but the same principle applies in .NET, Next.js, or Python: a feature folder contains the complete set of code that completes that feature.

How VSA Differs From Other Architectural Approaches

To position VSA correctly, it helps to compare it against the approaches it is most often confused with.

flowchart TB
    A[Architectural<br>approaches] --> B[Split by<br>technical layer]
    A --> C[Split by<br>feature/slice]
    B --> D[Layered<br>N-Tier]
    B --> E[Clean / Onion<br>Hexagonal]
    C --> F[Vertical Slice<br>Architecture]
    C --> G[Feature-Sliced<br>Design FSD]
    F --> H[Free inside slice<br>minimal rules]
    G --> I[Layered rules<br>inside slice too]

vs. Layered Architecture

Layered (N-Tier) architectures split code into horizontal technical layers: UI, business, data. Adding one feature means editing several layers, and the change spreads across the project.

VSA deliberately dismantles this structure. It minimizes shared abstractions across slices and lets each feature pick the implementation that fits. Bogard explicitly framed VSA as a reaction against “unnecessary abstractions around concepts like Controllers → Services → Repositories”¹.

This is not “Layered = bad,” however. For small applications, or in organizations where staff specialize by layer (DBAs, front-end engineers), Layered can still be more comprehensible.

vs. Clean / Onion / Hexagonal Architecture

Clean Architecture (and its relatives Onion and Hexagonal/Ports & Adapters) center on controlling the direction of dependency. Business logic lives at the core, with outer layers depending only on inner ones, in a strictly one-way relationship.

The difference with VSA is in the amount of abstraction. Clean separates use cases, entities, repositories, and presenters into distinct roles. VSA collapses those boundaries deliberately and writes the code each feature needs directly.

The two are not mutually exclusive. In a 2022 article that has remained widely referenced, dev.to user rexebin describes a production application that uses Clean’s layer structure (Domain/Application/Presentation/Infrastructure) but organizes the Application layer with VSA—a hybrid approach that’s quite common in practice⁶.

vs. Feature-Sliced Design (FSD)

FSD splits code by feature like VSA does, but with more structured rules⁷:

• Layer hierarchy: A six-layer structure of App / Pages / Widgets / Features / Entities / Shared (the official documentation lists seven layers, but Processes is deprecated)
• No same-layer slice dependencies: “Slices in the same layer cannot depend on each other”
• Segments inside slices: Technical segments such as ui / api / model / lib / config

VSA, by contrast, imposes no explicit rules on the inside of a slice. The “minimalism” of VSA is closer to the original spirit; FSD is best understood as “a disciplined VSA derivative tailored for front-end work.”

vs. CQRS

CQRS (Command Query Responsibility Segregation) is a pattern that separates write (command) from read (query) responsibilities—not an organizing principle for the whole architecture like VSA.

The two pair well, though. In the .NET ecosystem, the combination VSA + CQRS + MediatR (a request/handler mediator library) has become a standard. The Go ecosystem has equivalents such as mehdihadeli/go-vertical-slice-template⁵, which combines VSA and CQRS through Go-MediatR.

Why VSA Pairs Well With AI-Assisted Development

This is the heart of the article. There are three reasons VSA fits AI coding tools particularly well.

Reason 1: Context Window Efficiency

LLMs have an upper bound on input length—the “context window.” Claude Sonnet 4.5 ships with 200K tokens by default, with a 1M-token beta available, but bigger isn’t automatically better.

The developer community has converged on what’s called the “40% rule.” Basti Ortiz framed it in his January 2026 article: “LLMs tend to considerably degrade in output quality past 40% of their context window,” explicitly noting this is anecdotal rather than an empirically established threshold³. Treat it as practitioner intuition, not a benchmark—but it captures something real.

VSA gathers everything needed to implement or modify a feature into one directory. Telling an AI “read this folder and add a new endpoint” naturally bounds the context to the necessary minimum.

In a layered codebase, a single feature change touches Controllers, Services, Repositories, DTOs, tests, and migrations scattered throughout the project. To make the AI understand the change, you end up loading unrelated classes and helpers along with what matters. As Hightower observed in April 2025, “Layered Architecture often requires AI tools to operate across multiple files and layers, consuming more tokens and potentially reducing efficiency”⁸.

Reason 2: Locality of Change and Independent Agent Operation

AI coding has been shifting from single-shot completion toward agent-style autonomy. Claude Code, Cursor Composer, and Copilot’s Agent Mode let the AI explore files, edit, and run tests on its own.

When that happens, change being localized to a single slice matters a great deal. Ortiz argues that “self-contained modules encourage incremental features (rapid iteration!) and concurrent implementation (no merge conflicts!)”³. Multiple agents can run in parallel against feature-independent slices without colliding.

In codebases with extensive cross-cutting abstractions—oversized Service layers, shared Repositories—a single AI edit can ripple into unexpected files. The same problem exists for human developers, but the AI version is harder to bound, since the agent can’t always predict the full reach of its own changes. (For more on how AI-generated code tends toward tight coupling, see The tight-coupling trap of AI pair programming.)

Reason 3: Compatibility With Few-Shot Generation Cycles

Reasons 1 and 2 are about the boundaries of what the AI reads and writes. Reason 3 is about something different: the reproducibility of the generation cycle itself.

In VSA, the moment one slice is complete, it becomes the template for the next. Telling an AI “look at the structure and test pattern in features/creating_product/ and create features/creating_order/ in the same style” causes the new slice to inherit naming conventions, error handling, validation logic, and even test granularity automatically. This is few-shot prompting at its most efficient—and layered architectures cannot reproduce the same fidelity.

Once this cycle is running, the prompts you give the AI keep getting shorter. The first slice requires detailed requirements and conventions; by the third or fourth, “same pattern as the existing X, just with these fields swapped” is enough. John Miller, writing in CODE Magazine in March 2026, recommends a planning sequence for AI-assisted greenfield development that goes “domain facts → workflow inventory → slice mapping → dependency diagram → implementation order”⁹—planning that presupposes exactly this few-shot generation cycle.

flowchart TB
    A[Request: add new feature] --> B{Architecture}
    B -->|Layered| C[Edit Controller]
    C --> D[Edit Service]
    D --> E[Edit Repository]
    E --> F[Edit DTO]
    F --> G[Edit Tests]
    G --> H[Context scattered<br>token-inefficient]
    B -->|VSA| I[Create folder<br>features/new_feature/]
    I --> J[Everything completes<br>in one directory]
    J --> K[Context localized<br>AI understands easily]

Implementation Patterns by Stack

VSA is a structural principle, not tied to a specific language. But typical implementation patterns differ by ecosystem.

Next.js (App Router) for Full-Stack Use

The Next.js 15+ App Router, with directory-based routing and Server Components/Server Actions, fits VSA naturally. Farzaneh Haddadi’s November 2025 article recommends a structure like this¹⁰:

app/(dashboard)/
├── _components/    # UI shared across the dashboard
├── _hooks/         # Shared logic
├── _services/      # Shared network helpers
├── _utils/         # Small utilities
├── products/       # Feature slice: products
│   ├── page.tsx
│   ├── _components/
│   ├── _services/
│   ├── _schemas/
│   └── _hooks/
├── orders/         # Feature slice: orders
│   └── ...
└── customers/      # Feature slice: customers
    └── ...

The _ prefix marks “private folders” that Next.js excludes from routing, useful for organizational purposes. The rule “if two features share something, move the reusable part up to the parent shared space”¹⁰ balances reuse against independence.

By keeping Server Actions and Route Handlers inside the slice, the UI, server processing, and schema definitions cluster naturally—exactly the boundary the AI needs.

Go (API-Only)

The canonical Go example is mehdihadeli/go-vertical-slice-template⁵, which combines a lightweight stack of Echo (web framework), GORM (ORM), Go-MediatR (CQRS mediation), Uber Zap (logging), and Viper (configuration):

internal/
├── catalogs/                          # Domain
│   └── products/
│       └── features/
│           ├── creating_product/
│           │   ├── commands/
│           │   ├── endpoints/
│           │   ├── dtos/
│           │   └── events/
│           └── getting_product_by_id/
│               ├── queries/
│               ├── endpoints/
│               └── dtos/
├── pkg/                               # Shared utilities
└── shared/                            # Cross-cutting concerns

Each feature folder contains the full set: Command/Query, Handler, Endpoint, DTO, Event. Go’s interface system combined with a DI container (uber-go/dig) supports per-slice dependency management without requiring layered structure⁵.

Choosing a Stack: A Practical Guide

In practice, “Next.js vs. Go” is rarely a binary choice—both can host VSA. A useful guide:

• Full-stack with front end: Next.js (App Router) + Server Actions + feature folders
• API-only back end: Go + Echo + Go-MediatR, or .NET + MediatR + Carter
• Incremental migration of existing codebases: “VSA only for new features,” a hybrid that works in practice

I should note that as of April 2026, I could not find a credible benchmark quantitatively comparing AI coding productivity between Next.js and Go. Practitioner wisdom holds that languages with more training data (JavaScript/TypeScript, Python) produce higher AI generation accuracy, but Go’s standard library and major frameworks are well-represented enough that the practical difference has narrowed.

Counterarguments and Caveats: VSA Is Not a Silver Bullet

To avoid overselling VSA, here are the legitimate counterarguments and caveats.

Code Duplication

The most common criticism of VSA is that it violates DRY (Don’t Repeat Yourself). The same validation logic and conversion code can appear across multiple slices.

The VSA response is that this is a deliberate trade-off. Tolerating incidental duplication between slices buys independence and locality of change inside each slice. Bogard’s original article makes the case that “abstractions imposed for the sake of sharing actually force genuinely different requirements into one shape”¹—surface-level duplication is healthier than forced unification.

In practice, teams keep truly cross-cutting code (auth, logging, foundational validation) in _shared or shared/ and accept business-logic duplication.

When AI Disrupts the Structure

A February 2026 article from .NET Web Academy, “Stop Letting Copilot Ruin Your Vertical Slice Architecture,” documents specific failure modes when Copilot is used on VSA projects⁴:

• Structural inconsistency: Copilot generates Controllers instead of minimal API endpoints, scattering folders and logic.
• Duplicate DTOs: Redundant DTOs appear across server, shared, and client projects.
• Loss of architectural discipline: Without explicit instruction, CQRS separation and the Mediator pattern aren’t preserved.

The author’s prescription: make your architectural conventions explicit in prompts. Instructions like “Use minimal APIs instead of controllers,” “Use CQRS,” “Use Mediator” can be stored in reusable instruction files (Claude Code’s CLAUDE.md, Cursor Rules, Copilot Instructions) so you don’t repeat them per feature.

In other words, VSA does not magically produce good AI-generated code on its own. Reaping the benefit requires explicitly telling the AI what architectural rules to follow.

Limits at Large Scale

Once you reach dozens or hundreds of slices, understanding the relationships between slices becomes its own problem. At that scale, combining VSA with the Modular Monolith pattern—grouping related slices into “modules”—becomes practical.

DDD’s Bounded Context is also a different unit of granularity than a VSA slice. In larger systems, a stable hybrid is to enforce Clean’s dependency rules at the Bounded Context boundary while organizing the inside with VSA.

Team and Project Preconditions

Bogard explicitly states in the original article that VSA assumes “teams with strong refactoring skills and the ability to recognize code smells”¹. The freedom to “pick the best implementation per feature” can become “different quality per feature” in teams that lack the judgment to decide.

For junior-heavy teams or projects without explicit quality standards, the rigid templates that Layered or Clean provide may produce more consistent outcomes.

Practical Tips for AI-Assisted VSA Development

A few concrete tips for working in VSA with AI coding tools.

1. Write Project-Level Instructions

Files like CLAUDE.md, .cursorrules, and .github/copilot-instructions.md should encode rules such as:

## Architecture Rules
- Use Vertical Slice Architecture: each feature in its own folder under `features/`
- Each slice contains: command/query, handler, endpoint, DTO, test
- Do not create shared Service classes; keep logic inside slice handlers
- Shared code goes only into `shared/` (auth, logging, validation primitives)
- Use CQRS pattern with MediatR-style request handlers

2. Use Existing Slices as Templates

When adding a new feature, tell the AI: “Create features/creating_order/ with the same structure as features/creating_product/.” Loading the existing slice as a few-shot example causes naming conventions, test patterns, and error handling to be inherited automatically.

3. One Slice = One Session

Scope each AI agent session to “completing one slice.” This keeps context from ballooning. For larger refactors that span multiple slices, decompose them by hand first and feed the AI individual slice tasks.

4. Keep Shared Code Minimal

AIs love to extract “convenient shared helpers.” During review, ask whether the helper is genuinely used by multiple slices. If only one slice uses it, push it back inside that slice.

Conclusion

Vertical Slice Architecture is a simple but powerful organizing principle: complete each feature vertically. The principle Jimmy Bogard articulated in 2018—”minimize coupling between slices, maximize coupling in a slice”—is being re-evaluated now that AI coding tools are part of daily work.

The reason is that the unit of “context” the LLM handles aligns naturally with the VSA slice. A feature that lives in one directory carries exactly the context the AI needs—necessary and sufficient—which improves both generation accuracy and token efficiency. The Next.js App Router and Go’s framework ecosystem each provide implementation patterns that support VSA in their own way.

VSA is not a silver bullet, however. Code duplication, the risk of AI disrupting structure, complexity at large scale, team-skill prerequisites—all remain as challenges independent of AI affinity. Hybridizing with Clean, combining with Modular Monolith, making project-level instructions explicit—the realistic answer almost always involves combining several techniques.

“There is no single right answer in the AI era, but the idea of completing features vertically returns us to the basic value of locality of change—whether or not we use AI.” That’s where the meaning of re-examining VSA through the AI-affinity lens ultimately lies.

A one-line guide for the adoption decision: VSA is a strong choice for teams where features are highly independent, new features arrive continuously, and AI coding tools are used daily. Conversely, in domains where consistency between features is critical (financial transactions, medical records) or in junior-heavy teams, hybridizing with Clean or adopting incrementally tends to be more stable. Architecture choices always come back to the question of what you’re optimizing for.

Related Articles

• Understanding “Balancing Coupling in Software Design” — The coupling-degree theory that grounds VSA’s “maximize coupling in a slice” principle.
• The tight-coupling trap of AI pair programming — Why AI-generated code trends toward tight coupling, and what design choices counteract it.
• Writing Markdown documentation that AI reads efficiently — Documentation design from the perspective of context efficiency.
• Building an AI-native engineering team — Organizational and design considerations when scaling AI-assisted development across a team.

References

References are listed in the order they are cited in the body.

Additional References (Not Cited Inline)

• Vertical Slice Architecture and Comparison with Clean Architecture - Mehmet Özkaya, Medium. 【Reliability: Medium】Comparative positioning of VSA and Clean.
• From Layers to Slices: Revolutionizing .NET Application - Bhargav Koya, Medium. 【Reliability: Medium】Walkthrough of migrating from Layered to VSA in the .NET ecosystem.

1. Vertical Slice Architecture - Jimmy Bogard (April 19, 2018). 【Reliability: High】The original VSA article. Definition and principles directly from the proponent. ↩︎ ↩︎² ↩︎³ ↩︎⁴ ↩︎⁵ ↩︎⁶

2. A Deeper Dive: When the Vibe Dies — Comparing Codebase Architectures for AI Tools - Rick Hightower, Medium (April 18, 2025). 【Reliability: Medium】Expert-blog analysis of VSA’s fit with AI tools. No quantitative data. ↩︎

3. Coding Agents as a First-Class Consideration in Project Structures - Basti Ortiz, DEV Community (January 5, 2026). 【Reliability: Medium】Project-structure thinking for the coding-agent era. The “40% rule” is explicitly noted as anecdotal. ↩︎ ↩︎² ↩︎³

4. Stop Letting Copilot Ruin Your Vertical Slice Architecture - .NET Web Academy, Substack (February 16, 2026). 【Reliability: Medium】Concrete failure modes when Copilot disrupts VSA, and prompt-level countermeasures. ↩︎ ↩︎²

5. mehdihadeli/go-vertical-slice-template - Mehdi Hadeli, GitHub (v1.0.0: July 26, 2025). 【Reliability: Medium】VSA + CQRS template for Go. Echo, GORM, Go-MediatR. ↩︎ ↩︎² ↩︎³ ↩︎⁴

6. Clean Architecture vs Vertical Slice Architecture - rexebin, DEV Community (February 1, 2022). 【Reliability: Medium】Hybrid Clean + VSA approach with implementation example. ↩︎

7. Feature-Sliced Design: Overview - Feature-Sliced Design official documentation. 【Reliability: Medium-High】Official FSD docs covering layers, slices, and segments. ↩︎

8. Keep the AI Vibe: Optimizing Codebase Architecture for AI Coding Tools - Rick Hightower, Medium (April 18, 2025). 【Reliability: Medium】Overview of architecture optimization for AI coding tools, framing VSA as AI-friendly. ↩︎

9. AI-Assisted Greenfield Software Development, Part 6: Vertical Slices and Implementation Planning - John Miller, CODE Magazine (March 31, 2026). 【Reliability: Medium-High】Slice-level planning method for AI-assisted greenfield development. ↩︎

10. How to Organize a Growing Next.js App: A Practical Guide to Vertical Feature Slicing - Farzaneh Haddadi, Medium (November 7, 2025). 【Reliability: Medium】VSA implementation patterns in the Next.js App Router. ↩︎ ↩︎²