Combining VSA and DDD for AI Development: A Map of the Approaches Currently Being Discussed

Posted May 13, 2026

23 min read

AI-Generated Content

This article was generated by AI. The accuracy of the content is not guaranteed, and we accept no responsibility for any damages resulting from use of this article. By continuing to read, you agree to the Terms of Use.

Intended audience: Software engineers, tech leads, and architects building medium-to-large AI applications (LLM apps, Agentic AI, multi-agent systems) in earnest
Assumed knowledge: Basic familiarity with Vertical Slice Architecture (VSA), and at least a passing acquaintance with Clean Architecture / DDD concepts
Reading time: 27 minutes

Summary

“VSA is a design that keeps each feature self-contained as a vertical slice, and it pairs well with AI coding.” That proposition was laid out in the predecessor article Why Vertical Slice Architecture Fits AI Development, and up to that point we are in territory where implementation examples and community discussion have accumulated.

But once the number of slices grows and the system advances into Agentic AI or multi-agent configurations, a cluster of problems surfaces that VSA alone cannot easily absorb: “the same concept appears across slices under different names,” “where do we draw an agent’s scope of responsibility,” “what is the actual difference between a Bounded Context and a feature slice?”

Against these questions, several combination proposals are being discussed in parallel during 2025–2026. The aim of this article is not to recommend any one of them, but rather to map “what is implemented today and what is still at the proposal stage,” giving readers material to judge against their own project scale, team, and domain.

To put the bottom line up front:

The hybrid of VSA + DDD strategic design is, setting aside the AI development framing, a mature area with multiple implementation templates and OSS projects in .NET / Spring Boot. The “why it works for AI development” argument is logically coherent, but quantitative data is still thin.
AI-native combinations such as Multi-Agent × Bounded Context and Hexagonal Agents are running in parallel across personal posts from Microsoft and Siemens engineers, conference talks, and arXiv papers — but operational track record has yet to accumulate.
The long-standing critique that “DDD is overkill” carries over into the AI development context as well, and at present more commentators favor the stance “adopt only strategic design, keep tactical patterns to a minimum.”

This article lays out these directions separated into implementation-grade and proposal-stage, includes the counterarguments and arXiv empirical studies, and presents the overall picture. The judgment axes are left to the reader.

Sister article: For the foundational framing, Why Vertical Slice Architecture Fits AI Development covers the origin of VSA, how it differs from other approaches, and the grounds for its AI affinity. The present article is a map that overlays multiple DDD/Hexagonal discussions on top of that base.

§1. Map of the Discussion: What Is Implemented, What Is Still at the Proposal Stage

To organize the combination debate, the first useful line to draw is “is there an implementation example or not?” The strength of evidence differs sharply between the two.

Areas with implementation examples

Combination	Representative implementation / template	Publication date
VSA + DDD (strategic design) + Modular Monolith (.NET)	meysamhadeli/booking-modular-monolith — 497 stars, .NET 10, four Bounded Contexts (Identity/Flight/Passenger/Booking)¹	Updated July 2025
VSA + DDD + Clean Architecture (.NET)	Evgeni Rusev’s template — a solution directory per Bounded Context, with Clean Architecture inside each module (the author calls it “Clean Architecture with a Modular Vertical Slice monolith”)²	June 2024
VSA + DDD + CQRS (Spring Boot)	hpalma/ddd-verticalslice-example — a small reference implementation in Java / Spring Boot³	—
VSA + DDD + SOLID (ASP.NET Core)	jeangatto/ASP.NET-Core-Vertical-Slice-Architecture⁴	Continuously updated
DDD / Hexagonal backend conventions for AI agents	Bardia Khosravi’s GitHub conventions — the code examples are in Python, and the author notes they are easily portable to Java / C# / Go⁵	July 2025
Claude Code Skill for VSA (.NET)	Vladyslav Furdak’s dotnet-vsa-webapi — by a Microsoft MVP⁶	March 2026

All of these exist as working code you can git clone and read directly. That said, each of them frames its tie to AI development “as a discussion” or “as a coding convention,” and none have any statistical measurement of the form “after we adopted this, AI coding productivity rose by X%.”

Areas at the proposal / concept stage

Discussion	Proponent	Publication date
Multi-agent AI × DDD Bounded Context	James Croft (Microsoft Senior SWE)⁷	April 2026
Agent as Bounded Context (two models: Cognitive Agent / Workspace)	Philipp Kostyra⁸	August 2025
Agentic Codebases × four DDD principles (contract schemas, ACL, Context Map)	Nikita Golovko (Siemens AI Portfolio Architect, AI Coding Summit talk)⁹	February 2026
The efficacy of DDD in AI development (alignment of Ubiquitous Language with prompts)	Leric Zhang (Senior Software Architect)¹⁰	August 2025
Hexagonal Agents (an AI agent at the center, with Ports as tool boundaries)	Joshua Oliphant¹¹	March 2026

All of these are personal posts, talks, or blog articles, and they do not imply organizational adoption by the authors’ employers. “An engineer at Microsoft writes this” does not mean “Microsoft operates this way” — that distinction matters.

flowchart TB
    A[VSA and DDD combination discussions] --> B[Implementation examples exist]
    A --> C[Proposal / concept stage]
    B --> D[VSA + DDD strategic design<br>Modular Monolith]
    B --> E[VSA + DDD + CQRS<br>templates]
    B --> F[Conventions for<br>AI coding agents]
    C --> G[Multi-Agent ×<br>Bounded Context]
    C --> H[Agent as<br>Bounded Context]
    C --> I[Hexagonal Agents]

§2. Direction A: VSA + DDD Strategic Design (Minimal)

The most mature combination sits here. This is the camp that adopts only the strategic side of DDD — Bounded Contexts, Ubiquitous Language, Context Maps — and brings in tactical patterns (Aggregates, Repositories, Domain Services, etc.) only as needed inside individual slices.

What the structure looks like

Looking at meysamhadeli/booking-modular-monolith¹, four Bounded Contexts — Identity, Flight, Passenger, Booking — are separated as modules, and the inside of each module is organized as VSA feature slices (Command/Query Handler, Endpoint, Repository). The multiple modules are deployed as a single binary, and inter-module communication uses gRPC and MassTransit (event-driven).

The same idea is applicable in Next.js or Go. A Go layout might look like this:

internal/                          # Go example
├── sales/                         # Bounded Context: sales
│   ├── domain/                    # Minimal Aggregates / VOs as needed
│   ├── acl/                       # Translates input from other contexts
│   └── features/                  # VSA slices
│       ├── creating_order/
│       └── cancelling_order/
├── inventory/                     # Bounded Context: inventory
│   ├── domain/
│   ├── acl/
│   └── features/
└── shared/                        # Truly cross-cutting (minimal)

The benefits being discussed

The advantages cited across implementation templates align fairly closely:

The growth in slice count gets stratified at the context level, which keeps the cost of grasping the dependency graph in check.
Routing access between Bounded Contexts through an ACL (Anti-Corruption Layer) prevents refactoring inside one context from rippling out into others.
Terminology conventions can be documented per context (proposals exist for placing CLAUDE.md / .cursorrules per Bounded Context).

Leric Zhang argues that “when prompts use Ubiquitous Language, AI output aligns closely with business intent”¹⁰. The claim is intuitively agreeable, but there is no quantitative data behind it, so at the moment it should be received on the basis of logical coherence rather than measured evidence.

Limitations that have been pointed out

Rico Fritzsche, who argues that “VSA is not an evolution of Clean Architecture — it is a different philosophy,” criticizes the pattern of keeping Clean’s layered structure intact and merely wrapping it in Bounded Contexts. His core claim is “Clean Architecture can never be domain-driven anyway,” and he points out that hybrids preserving Clean’s layers are half-measures if you are serious about feature independence¹².

Because most implementation templates do preserve Clean’s layers, this critique cannot be dismissed. Adopting “Bounded Context × VSA” is one thing; whether you constrain the inside with Clean’s dependency rules is a separate decision on top of it.

§3. Direction B: Full DDD Including Tactical Patterns

The camp that says “go all the way and implement Aggregates, Value Objects, Repositories, and Domain Services properly” uses tactical patterns as coding conventions to constrain the AI.

Bardia Khosravi’s published GitHub conventions⁵ are a representative example of this direction. The author positions “AI coding agents as another developer on the team” and aims to make AI output reviewable by providing predictable patterns. The code examples are in Python, but tactical patterns like Entity / Value Object / Aggregate Root / Repository Interface are organized as language-independent concepts, and the author notes that they are easily portable to Java / C# / Go.

Prerequisites for this direction

If you go as far as tactical patterns, the keys are whether the following prerequisites hold:

The domain has genuine complexity (not a simple CRUD application).
The team has multiple members who understand DDD tactical patterns.
A documentation system exists that can present tactical patterns to the AI as explicit “conventions.”

The “Dogmatic DDD” critique

In a 2021 piece titled “STOP Doing Dogmatic Domain Driven Design,” Derek Comartin argues that “writing repositories and aggregates is not the same as doing DDD” and that “real DDD is not pattern compliance — it is understanding the domain’s boundaries and language”¹³.

In other words, even if you adopt full DDD, you will not reap the benefits if you mechanically line up tactical patterns. There is even the opposite risk that the code becomes heavy with pattern compliance, and the context you need to hand to the AI swells. Comartin’s follow-up the next year, “Should You Use Domain Driven Design?” (2022), summarizes the case: “DDD is overkill for small applications; concentrate on strategic patterns and be realistic”¹⁴.

This critique applies in the AI development context too. On “should we equip tactical patterns from the start, or start with strategic design and add tactical patterns as needed?”, more commentators currently lean toward the latter.

§4. Direction C: Hexagonal Agents (Ports & Adapters)

Different in lineage from VSA but discussed in parallel for AI development is the application of Hexagonal Architecture (Ports & Adapters).

Joshua Oliphant’s “Hexagonal Agents,” published in March 2026, proposes that “the center of the hexagon does not have to be a rule engine — it can be a reasoning engine”¹¹. The design places an AI agent at the center and defines Inbound Ports (triggers) and Outbound Ports (tools / capabilities) as the agent’s boundaries.

flowchart TB
    A[Inbound Port<br>HTTP / Event / Schedule] --> B[AI Agent<br>reasoning engine]
    B --> C[Outbound Port: DB]
    B --> D[Outbound Port: External API]
    B --> E[Outbound Port: Tool]
    F[Guardrails<br>validation policy] -.-> B

Characteristics of this direction

LLM swappability: Provider dependence (OpenAI / Anthropic / Google) can be separated from the central logic.
Explicit tool boundaries: Each Outbound Port becomes “a tool the LLM can call,” which aligns well with Function Calling / MCP.
A natural insertion point for guardrails: Validation and authorization checks can be enforced at the Port layer.

Relationship to VSA

Hexagonal Agents is not mutually exclusive with VSA, but the philosophical center of gravity differs. VSA places locality of change at the center; Hexagonal places control of dependency direction at the center. Implementation examples that integrate the two are still rare. A three-level nesting — “apply Hexagonal inside a Bounded Context, then organize the features inside it with VSA” — is theoretically possible, but at that depth there is a concern that the cost of organizing the context handed to the AI rises sharply.

§5. Direction D: Multi-Agent × Bounded Context (Entirely Proposal Stage)

This is the idea, in an architecture where multiple LLM agents collaborate, of mapping each agent’s scope of responsibility onto a Bounded Context.

Current commentators

James Croft (Microsoft Senior SWE) in April 2026 presents the correspondence “one or more agents represent a Bounded Context, and agents encapsulate the knowledge and rules of a specific domain”⁷.
Philipp Kostyra in August 2025 proposed a model that positions a Bounded Context as either a Cognitive Agent (the entire context as a single autonomous agent) or a Workspace (a working space in which multiple agents collaborate)⁸. The picture is, for example, treating a “regulatory compliance context” as a single Cognitive Agent that completes policy checks, while treating an “inventory context” as a Workspace in which multiple specialist agents (replenishment judgment, allocation, stocktake) coexist.
Nikita Golovko (Siemens AI Portfolio Architect) at the AI Coding Summit in February 2026 presented an organization that positions Bounded Contexts as agent responsibilities, contracts as schemas, ACLs as semantic firewalls, and Context Maps as executable integration architecture⁹.

What “proposal stage” means here

All of these commentators publish on a personal basis, and that does not imply organizational adoption by their employers. As of May 2026, almost no public record exists of failure or success patterns from production multi-agent operations. What is being discussed is a design framework, not case studies of “we adopted this and failed / succeeded in this way.”

That said, empirical research in adjacent territory is beginning to appear. arXiv 2604.04990 “Architecture Without Architects” (April 2026) experimentally demonstrates that AI coding agents make architectural decisions implicitly through prompts¹⁵. The report that on the same task, prompt wording alone causes code size to fluctuate between 141 and 827 lines, supports the “prompt = architectural specification” framing. The idea of baking Bounded Context boundaries into prompts is one to watch from this angle as well.

How to handle these

The Croft / Kostyra / Golovko discussions are stimulating, but for production adoption today you have to accept “you are the one drawing the failure pattern lottery for your own team.” Treating them as a wait-and-see direction is the moderate stance.

§6. Empirical Data Spanning AI Development (Limited)

As material for judging the combination debate, one paper hints that AI development may change the very horizontal division of labor.

arXiv 2601.22667 “From Horizontal Layering to Vertical Integration: A Comparative Study of the AI-Driven Software Development Paradigm” (January 2026) argues that with AI assistance, “Vertical Integration in which individual engineers own features end-to-end” becomes feasible. The authors report person-month reductions of 8.3× in a traditional enterprise case and 33× in an AI-native startup case, across two studies¹⁶.

That said, the numbers come with caveats:

The case studies number only two, and statistical generalization is difficult.
“Person-month reduction” likely includes not only AI capability gains, but also organizational restructuring and scope reduction.
The authors’ affiliations (Moximize.ai, etc.) sit in the AI-native space, so a selection bias is plausible.

With those reservations, the paper’s qualitative observations — “senior engineers shift from execution coding to architectural oversight and accountable governance,” and “a single engineer crosses what used to be role boundaries” — suggest that “feature-and-responsibility vertical structures,” such as VSA or Bounded Context, point in a direction that is congruent with the AI era’s organizational shape.

§7. Counterarguments and Caveats

Counterarguments and reservations to the whole combination debate deserve the same weight.

Counter 1: DDD is overkill

As Derek Comartin has argued consistently¹³¹⁴, bringing DDD into a domain without complexity does not pay for itself. The risk is real that “if you cannot even see three Bounded Contexts, introducing DDD leaves you only with the weight of tactical patterns.”

Counter 2: VSA’s own limits

The traditional critiques of VSA — code duplication, degraded consistency across slices, and the cost of managing cross-cutting concerns — remain after the combination as well. Drawing on Milan Jovanović’s framing, the trade-off underpinning VSA is “Duplication is cheaper than the wrong abstraction” plus the Rule of Three (don’t abstract until the same code appears three times). At larger scale, however, this duplication can also turn into debt¹⁷.

Counter 3: An era where prompts decide the architecture

As arXiv 2604.04990 shows, in the AI agent era a large part of “architecture” is decided by prompts, scaffolding, and defaults rather than by code¹⁵. Even if you decide to adopt VSA or DDD, lax prompt conventions handed to the AI will erode the structure quickly. “Architecture selection” and “prompt conventions” need to be discussed with the same weight.

Counter 4: The absence of quantitative data

A weakness common to the entire combination debate is that quantitative effect measurements in the AI development context are essentially absent. Logical coherence and implementation examples have accumulated, but as of May 2026 there is no controlled comparison of “teams that adopted VSA + DDD vs. teams that did not.”

Counter 5: Team-skill prerequisites

DDD demands a certain level of experience even when limited to strategic design. The judgment “where to draw a Bounded Context” is heavy for teams not used to domain modeling. VSA, too, explicitly assumes “teams with strong refactoring skills and code-smell awareness,” as Bogard himself states in the original article. If you adopt both, you need the prerequisites for both.

§8. How to Judge for Your Own Project

Building on the discussion so far, here is a framework for judgment. The intent of this article is not to compress the answer into a single line, but useful questions for judgment can be offered.

Question 1: Are Bounded Contexts visible?

Are there places inside the system where the same word carries different meanings in different contexts? Does “an order in sales” model differently from “an order in inventory”? Does “a customer in regulatory compliance” carry different attributes from “a customer in marketing”?

Not visible (a single Bounded Context): VSA alone is enough. Add DDD strategic design later when the need arises.
Two or three are visible: The VSA + DDD strategic-design hybrid (Direction A in §2) is a realistic candidate for consideration.
Four or more are visible, or are still growing: A combination with the Modular Monolith pattern (a structure like booking-modular-monolith in §2) becomes worth discussing.

Question 2: Are you willing to take on tactical-pattern complexity?

Do you have the capacity and the need to implement Aggregates, Value Objects, Repositories, and Domain Services?

Neither the need nor the capacity: Strategic design only, tactical patterns inside slices on an as-needed basis.
Both: Direction B in §3 (e.g., Khosravi’s conventions) is a useful reference.
You feel the need but lack capacity: A staged introduction — “start from strategic design, and add tactical patterns only where the pain is felt” — fits.

Question 3: What agent configuration will you adopt?

Single-agent coding assistance (Claude Code / Cursor, etc.) is central: The discussions in §2 / §3 apply directly.
You are considering multi-agent production operation: §5’s discussion is to be consulted, but with the readiness to record your own failure patterns.
You use AI only as a tool: It is safer to judge DDD on the merits independent of AI.

Question 4: How will you integrate prompt conventions with architecture conventions?

As arXiv 2604.04990 shows, prompts are part of the architectural specification¹⁵. Whether you can explicitly convey Bounded Context boundaries, the Ubiquitous Language, and slice conventions to the AI via CLAUDE.md / .cursorrules / .github/copilot-instructions.md becomes the final key to translating the combination debate into implementation.

Conclusion

As of May 2026, the VSA-and-DDD combination debate is a growing area where implementation examples and proposal-stage ideas coexist.

Implementation examples exist for: the VSA + DDD strategic-design hybrid, integration with Modular Monolith, and coding conventions for AI agents — in each case multiple templates are published in .NET / Spring Boot.
Still at the proposal stage: Multi-Agent × Bounded Context, Hexagonal Agents, and the Cognitive Agent model — these live in personal posts and conference talks, and operational accumulation is yet to come.

This article was written as a map, not as a recommendation guide. The answer to “which one should I adopt?” shifts with individual circumstances — the number of Bounded Contexts, the capacity to take on tactical patterns, the agent configuration, and the state of prompt conventions.

One thing can be said with confidence: “Even as AI coding spreads, architecture selection does not disappear.” On the contrary, as arXiv 2604.04990 suggests, precisely because prompts and scaffolding now implicitly decide the architecture, explicit discussion of structure matters more than before. VSA, DDD, and Hexagonal — none is a silver bullet on its own, but following the debate around how to combine them makes it easier to locate the structure your own project needs.

A realistic next step after reading this article is probably to ask, “Are Bounded Contexts visible in my own system?” If they are, picking up one of the implementation templates in §1 in a language and scale that match yours and reading it carefully will make the discussion concrete in one stroke.

You may also find these related articles useful:

Why Vertical Slice Architecture Fits AI Development: One Slice, One Context as a Design Principle — the predecessor article that grounds the present one. It covers the origin of VSA, how it differs from other approaches, and the basis of its AI affinity.
Balancing Coupling in Software Design: A New Design Principle Beyond Loose-Coupling Absolutism — theoretical backing for controlling coupling between Bounded Contexts.
The Tight Coupling Trap in AI Pair Programming — the tight-coupling problem in AI-generated code, and a design-led perspective on containing it.
Building an AI-Native Engineering Team — the organizational and design issues that arise when leveraging AI at team scale.

References

The references below are listed in the order of citation numbers used in the body.

Implementation examples (GitHub templates / OSS projects)

Proposal / concept work (personal posts, conference talks)

Counterarguments / critique

Empirical research (arXiv)

Additional references (not cited by number in the body)

Vertical Slice Architecture — Jimmy Bogard (April 19, 2018). [Reliability: High] The original VSA article.
Leveraging Generative AI for Enhancing Domain-Driven Software Design — Götz-Henrik Wiegand, Filip Stepniak, Patrick Baier, arXiv:2601.20909 (January 28, 2026; Upper-Rhine AI Symposium 2024 proceedings). [Reliability: Medium] Research in the reverse direction: partially automating DDD meta-model generation using generative AI.
mehdihadeli/go-vertical-slice-template — Mehdi Hadeli, GitHub (v1.0.0: July 26, 2025). [Reliability: Medium] A VSA + CQRS template for Go.
Why Vertical Slice Architecture Fits AI Development — predecessor article on this blog (April 26, 2026). The base on which the present article builds.

meysamhadeli/booking-modular-monolith — A .NET 10 implementation integrating VSA + DDD + Modular Monolith + Event-Driven + CQRS. Four Bounded Contexts: Identity / Flight / Passenger / Booking. 497 stars (as of July 2025). [Reliability: Medium-High] Both in scale and continuous updates, it is a highly referenceable implementation example. ↩︎ ↩︎²
.NET Domain Driven Design Template with a Vertical Slice architecture — Evgeni Rusev, Medium (June 22, 2024). [Reliability: Medium] Splits one solution directory per Bounded Context and assembles the whole solution as a modular VSA monolith (the author calls it “Clean Architecture with a Modular Vertical Slice monolith”). A GitHub template is provided. ↩︎
hpalma/ddd-verticalslice-example — A small reference implementation integrating DDD + VSA + CQRS + Domain Events on Spring Boot. [Reliability: Medium] A reference in the Java ecosystem. ↩︎
jeangatto/ASP.NET-Core-Vertical-Slice-Architecture — An integration of VSA + CQRS + REST API + DDD + SOLID. [Reliability: Medium] A reference in the .NET ecosystem. ↩︎
Backend Coding Rules for AI Coding Agents: DDD and Hexagonal Architecture — Bardia Khosravi, Medium (July 12, 2025). [Reliability: Medium] DDD / Hexagonal conventions for AI coding agents. The code examples are in Python; the author notes easy portability to Java / C# / Go. A conventions repository (bardiakhosravi/ai-agent-backend-standards) is published on GitHub. ↩︎ ↩︎²
Vertical Slice Architecture for Claude Code: dotnet-vsa-webapi Explained — Vladyslav Furdak, Microsoft MVP (March 16, 2026). [Reliability: Medium] A VSA scaffolding Skill for Claude Code. Deliberately excludes MediatR / AutoMapper / generic Repository. ↩︎
Applying domain-driven design principles to multi-agent AI systems — James Croft, Microsoft Senior Software Engineer (April 8, 2026; updated May 4, 2026). [Reliability: Medium] This is personal output and does not imply organizational adoption by the author’s employer. ↩︎ ↩︎²
Agent as Bounded Context (Part 1) — Philipp Kostyra, Medium (August 1, 2025). [Reliability: Medium] Proposes the two-model framing (Cognitive Agent / Workspace). No implementation example provided. ↩︎ ↩︎²
From Prompt Spaghetti to Bounded Contexts: DDD for Agentic Codebases — Nikita Golovko, Siemens AI Portfolio Architect, AI Coding Summit (February 26, 2026). [Reliability: Medium] Conference talk. Presents Bounded Contexts, contract schemas, ACLs, and Context Maps as four principles. ↩︎ ↩︎²
Domain-Driven Design: Streamlining AI-Powered Software Development — Leric Zhang, Senior Software Architect, Medium (August 2, 2025). [Reliability: Medium] Organizes the points where DDD (Ubiquitous Language, Bounded Context, Aggregate) helps AI development. No empirical data. ↩︎ ↩︎²
Hexagonal Agents: What If Your App’s Business Logic Was an AI Agent? — Joshua Oliphant (March 18, 2026). [Reliability: Medium] Proposes placing an AI agent at the center of a Hexagonal Architecture. Discusses LLM provider swappability and tool boundaries. ↩︎ ↩︎²
Why Vertical Slices Won’t Evolve from Clean Architecture — Rico Fritzsche (May 15, 2025). [Reliability: Medium] Argues VSA and Clean are different philosophies. “Clean Architecture can never be domain-driven anyway.” ↩︎
STOP Doing Dogmatic Domain Driven Design — Derek Comartin, CodeOpinion (June 9, 2021). [Reliability: Medium-High] A critique of DDD biased toward tactical-pattern compliance. The essence is understanding boundaries and language. ↩︎ ↩︎²
Should You Use Domain Driven Design? — Derek Comartin, CodeOpinion (February 16, 2022). [Reliability: Medium-High] The DDD-overkill argument: “Not needed for simple CRUD — concentrate on strategic patterns.” ↩︎ ↩︎²
Architecture Without Architects: How AI Coding Agents Shape Software Architecture — Phongsakon Mark Konrad et al., arXiv:2604.04990 (April 5, 2026). [Reliability: Medium-High] Demonstrates that AI coding agents make implicit architectural decisions via prompts. Reports code-size fluctuations between 141 and 827 lines for the same task. ↩︎ ↩︎² ↩︎³
From Horizontal Layering to Vertical Integration: A Comparative Study of the AI-Driven Software Development Paradigm — Chi Zhang et al., arXiv:2601.22667 (January 30, 2026). [Reliability: Medium] Argues that Vertical Integration becomes feasible with AI assistance. Reports 8.3× and 33× person-month reductions across two case studies, but the numbers should be read with care because they include organizational restructuring and scope reduction. ↩︎
Vertical Slice Architecture: Where Does the Shared Logic Live? — Milan Jovanović. [Reliability: Medium] A discussion of where shared logic lives in VSA. Organizes the trade-off around DRY violations. ↩︎

Software Design

This post is licensed under CC BY 4.0 by the author.