arela/RESEARCH/5. Human Refactor_ VSA & AI Governance.md

AI-powered CTO with multi-agent orchestration, code summarization, visual testing (web + mobile) for blazing fast development.

# **The Human Refactor: Sociotechnical and Economic Pathways to Vertical Slice Teams and AI-Assisted Development Governance (Arela Model)**

## **Executive Summary**

This report presents an integrated framework for transitioning technology organizations to a Vertical Slice Architecture (VSA) and Modular Monolith Architecture (MMA), arguing that such a technical shift is indivisible from a "Human Refactor" of the organization itself. Analysis of sociotechnical systems confirms that the primary failures in architectural adoption are social and organizational, not technical. Consequently, a successful migration requires a sociotechnical approach that fuses technical refactoring with an organizational refactoring based on the Team Topologies framework.  
This analysis introduces three new frameworks to guide this transition:

1. **The "Strangler Fig for Teams" Model:** A phased, sociotechnical migration pattern that de-risks the human reorganization by mirroring the gradual code-level strangler pattern.  
2. **An Evidence-Based ROI Model:** A quantitative framework, based on monetizing DORA metrics , that justifies the high upfront investment of the Human Refactor by forecasting gains in velocity, quality, and retention.  
3. **The Human Refactor Readiness Matrix:** A sociotechnical checklist to identify and mitigate the cultural and political blockers—particularly middle-management resistance —that typically cause such transformations to fail.

The report also provides a quantitative economic analysis of VSA-centric testing, arguing that modern slice-level integration testing with tools like Testcontainers offers superior fidelity and lower total cost of ownership than traditional, mock-heavy strategies.  
Finally, this report establishes that the VSA/Team Topologies transition is the non-negotiable prerequisite for the next horizon of software development: hybrid human-AI teams. Analysis of 2025 pilot data reveals a critical "Speed vs. Trust" gap, where AI agents produce a high volume of low-trust code. The solution, conceptualized as the "Arela Model," is a policy-driven governance layer that enforces architectural and team-level rules. This layer requires the well-defined boundaries that only the Human Refactor can create, positioning this transition as the central strategic imperative for 2026–2027.

## **1\. The Sociotechnical Transition: A "Strangler Fig" Model for Teams**

### **1.1 The Failure of Technical-Only Transformation**

The history of software architecture is littered with transformations that failed not due to technological deficits, but due to a failure to recognize and manage the attendant social and organizational complexity. The adoption of Vertical Slice Architecture (VSA) is, first and foremost, a sociotechnical challenge.  
This is a direct consequence of Conway’s Law, which observes that organizations are constrained to produce designs that are copies of their communication structures. A horizontally-structured organization, with siloed teams for "UI," "API," and "Database," will *inevitably* produce a horizontally-layered, tightly-coupled monolithic application.  
To achieve a modular, vertically-sliced architecture, the organization *must* first (or concurrently) refactor its human communication structures into modular, vertical teams. This "Inverse Conway Maneuver" is the "Human Refactor"—an intentional redesign of the organization to produce the desired architecture. Attempts to refactor the *code* without refactoring the *teams* are destined to fail, as the misaligned human communication paths will continuously pull the code back toward a coupled monolith.

### **1.2 Deconstructing the Horizontal Team**

The traditional horizontal, or "component team," model optimizes for technical-layer efficiency, grouping specialists (e.g., all DBAs) together. While this maximizes resource utilization within a specialty, it de-optimizes the flow of value. The primary pathology of this model is the inability to deliver demonstrable, end-to-end functionality.  
Teams deliver their *layer* (e.g., "the API is done"), but no single feature is complete, leading to "sprint reviews where no functionality could be demonstrated". This creates a "Layer Tax" paid on every feature, consisting of:

* **High Communication Overhead:** Simple changes require multi-team JIRA tickets, meetings, and sign-offs.  
* **High Decision Latency:** Feature work is blocked by the backlogs and priorities of other horizontal teams.  
* **High Integration Risk:** Functionality is only integrated at the end of the cycle, leading to late, complex bug discovery.

Vertical slicing, which delivers a thin, end-to-end piece of functionality (from UI to database) within one team, is the direct solution to this problem.

### **1.3 A Phased Migration Model: The "Strangler Fig for Teams"**

A "big bang" reorganization to VSA teams is politically fraught and operationally high-risk, as evidenced by the widespread "cargo cult" failures of the Spotify Model. A de-risked approach is required.  
The "Strangler Fig for Teams" is a phased sociotechnical migration model that parallels the code-level Strangler Fig pattern. It allows an organization to gradually "strangle" its old, horizontal, monolithic structure with new, vertical teams, all while continuing to deliver value. The model synthesizes change management theory with the explicit team structures defined in *Team Topologies*.

* **Phase 0: The Monolithic Organization (Baseline):** The organization consists of horizontal component teams (e.g., UI, API, DBA). Communication overhead is high.  
* **Phase 1: The First "Strangler" Team:** A single, cross-functional "stream-aligned team" is formed for a new, well-defined business domain. This team "borrows" specialists (e.g., one DBA, one QA) who are matrixed, reporting to both the new team and their old horizontal manager. This phase temporarily *increases* political friction but is a necessary first step.  
* **Phase 2: The "Enabling Team" Transition:** As more stream-aligned teams are formed, the old horizontal teams (e.g., the "DBA Team") begin to *unfreeze*. Their charter officially changes: they transition from *doing* the work to *enabling* the stream-aligned teams to do the work. They become an "Enabling Team" , acting as mentors and "servant leaders" to upskill the stream-aligned teams.  
* **Phase 3: The "Platform Team" Evolution:** The enabling team matures and *refreezes* into a "Platform Team". Its mission changes from 1-on-1 mentoring to building a self-service *internal product* (e.g., a "Database-as-a-Service" platform) with a clear API. This platform is consumed by stream-aligned teams in an "X-as-a-Service" interaction mode. This is the critical step for managing and reducing cognitive load for all other teams.  
* **Phase 4: The "Retired Monolith" (Steady State):** The old horizontal component teams are fully "retired." The organization now matches the recommended *Team Topologies* distribution: a high percentage of stream-aligned teams (60-80%), supported by a smaller number of platform (10-20%), enabling (5-15%), and complicated-subsystem (0-10%) teams.

### **1.4 Integrating Change Frameworks: Applying Kotter and ADKAR**

The "Strangler Fig for Teams" model provides the *what*; Kotter's 8-Step Model and the ADKAR model provide the *how*—the proven "playbooks" for executing the change.  
**1\. Kotter's 8-Step Model (The Top-Down Leadership Script):** Kotter's model provides the macro-level, leadership-driven framework for organizational change and has been used successfully in agile transformations, such as splitting a large Agile Release Train (ART).

* **Steps 1–3 (Create Urgency, Build Coalition, Form Vision):** Leadership must articulate the *business* (not just technical) urgency, e.g., "Our poor DORA metrics are costing us market share." They must form a "collaborative adoption core team" (the *Guiding Coalition*) to evangelize the *Team Topologies* blueprint as the *Strategic Vision*.  
* **Steps 4–6 (Enlist Army, Remove Barriers, Short-Term Wins):** This is the "Strangler Fig for Teams" in action. The *Volunteer Army* is the first pilot stream-aligned team. The primary *Barrier* is political resistance from middle managers and the lack of a platform. The *Short-Term Win* is the pilot team's successful, measurably-faster delivery.

**2\. The ADKAR Model (The Bottom-Up Individual's Journey):** Where Kotter's model is high-level , ADKAR is a "people-centric" model for managing the individual's psychological transition, which is the most common point of failure.

* **Awareness:** "I, a DBA, am aware that we are moving to VSA teams."  
* **Desire:** This is the primary failure point. "I *want* to support this, but I fear my specialized role is being eliminated." Mitigation requires showing "what's in it for me"—a new, more powerful career path as a Platform Engineer or high-impact Enabling Team member.  
* **Knowledge:** "I have been trained in *Team Topologies* and understand how to *enable* teams instead of *controlling* data."  
* **Ability:** "I have successfully mentored three stream-aligned teams in database best practices."  
* **Reinforcement:** "My compensation and promotion are now tied to *enablement metrics* (e.g., VSA team autonomy) and *platform adoption*, not the size of my old DBA team."

The optimal strategy synthesizes these: Kotter to *initiate* the macro-organizational change, ADKAR to *manage* the individual psychological transitions, and *Team Topologies* as the *target blueprint* for the new sociotechnical system.

## **2\. The Economics of Vertical Slice Testing and Operation**

### **2.1 The "Mock Tax": Deconstructing the Hidden Costs of Mock-Based Testing**

The horizontal architecture *necessitates* a testing strategy based on extensive mocking. This strategy is often defended as "fast" and "cheap," but a total-cost-of-ownership analysis reveals the opposite. Mocks are "living a lie" ; they are a *separate, unverified implementation* of a dependency that must be maintained in parallel, incurring a significant, hidden "Mock Tax."  
This tax consists of:

1. **High Maintenance Cost:** Mocks are brittle. When the *real* implementation of a dependency (e.g., an API contract or database schema) changes, all mocks that *simulate* it must be manually updated. This is repetitive, low-value work that consumes engineering cycles.  
2. **False Confidence Cost:** Mocks inevitably drift from production behavior. Teams receive a "green" build based on a mock that no longer reflects reality, leading to integration bugs being caught in production, the most expensive possible place. Mocks cannot validate database-specific queries, transaction logic, or schema migrations.  
3. **Flakiness Cost:** Mocks for complex dependencies become stateful and unreliable, contributing to high test "flake rates" (e.g., 8% ). A flaky test suite erodes trust, wastes CI resources, and leads to developers ignoring test failures.

### **2.2 Quantifying the Testcontainer Model: Performance, Flakiness, and Maintenance**

VSA/MMA enables a superior testing strategy: *slice-level integration tests*. In this model, a single vertical slice (e.g., an API endpoint) is tested from its boundary down to *real, ephemeral instances* of its dependencies (e.g., a real PostgreSQL database) spun up in containers.

* **Fidelity:** This approach provides near-perfect fidelity. The test executes against the *actual* database schema, validating *real* SQL queries and migrations.  
* **Performance:** While a single containerized test is slower than a single mock-based unit test (e.g., 3000ms vs 200ms ), this comparison is misleading. A 2025 performance benchmark on Testcontainers shows that with modern optimizations like *PreStarting* (cached container pools) and parallelization, a full Testcontainer-based suite can be *nearly 50% faster* (e.g., 8m 50s reduced to 4m 50s) than a naive, serial implementation.  
* **Maintenance:** The maintenance cost of mocks is *eliminated*. The maintenance cost shifts from *per-test* (maintaining thousands of mocks) to *per-platform* (maintaining a single set of Docker images), which is orders of magnitude lower.

### **2.3 Hybrid Testing Strategies for Modular Monoliths**

The optimal strategy for a VSA/MMA is not an "all-or-nothing" approach but a *hybrid portfolio* that optimizes for fidelity, speed, and cost.

1. **Unit Tests (Mocks):** Used *sparingly* for pure, state-free domain logic (e.g., a complex pricing algorithm) *within* a slice. Fast, zero I/O.  
2. **Slice-Level Integration Tests (Testcontainers):** This is the *new "workhorse"* of the testing pyramid. It validates a single VSA, from its controller to a *real, containerized database*. This layer provides the highest ROI, catching \~90% of bugs with perfect fidelity and high isolation.  
3. **Full System E2E Tests:** Used *very sparingly* (\<5% of tests). These tests are slow, fragile, and complex. They should be reserved only for validating critical-path "smoke tests" (e.g., "can a user log in, add to cart, and check out?").

This report proposes a composite "Test Cost" metric to quantify these trade-offs, defined as TestCost \= (Runtime \\times FlakeRate \\times (1/CoverageYield)).  
**Table 1: Testing Cost Comparison (Mock vs. Slice vs. Hybrid)**

| Test Strategy | Avg. Runtime | Maintenance Cost (dev-hrs/mo) | Flake Rate (%) | Coverage Yield (Fidelity) | Relative Test Cost |
| :---- | :---- | :---- | :---- | :---- | :---- |
| **Unit (Mock-Heavy)** | Fast (20ms) | High (40-60) | High (5-8%) | Low (Mocks drift) | **High (Hidden)** |
| **Slice (Testcontainers)** | Medium (3000ms) | Low (5-10) | Very Low (0-1%) | Very High (Real DB) | **Medium (Explicit)** |
| **E2E (Full System)** | Very Slow (30,000ms+) | Medium (20-30) | Very High (10%+) | Highest | **Very High** |
| **Hybrid VSA Portfolio** | *(Weighted Avg)* | **Lowest (15-25)** | *Lowest (1-2%)* | **High (Optimized)** | **Lowest (Total)** |

### **2.4 Architectural Validation: Google's Service Weaver**

The VSA/MMA model, long considered a mere "stepping stone" to microservices, has been validated by recent (2023–2025) industry and academic analysis as a *destination architecture* in its own right.

* **Google's Service Weaver :** Google, a pioneer of microservices, released this open-source framework that explicitly allows developers to *write a modular monolith* (for fast development and testing) but *deploy* it as a set of distributed microservices. This is a tacit admission by a key microservice proponent that the *development and operational overhead* of microservices is prohibitively high for most applications.  
* **Academic Systematic Literature Review (2025) :** The first systematic literature review on MMA in cloud environments, published in 2025, confirms its status. It identifies the primary adoption drivers as "simplified deployment, maintainability, and reduced orchestration overhead". The review concludes that MMA is a powerful, evidence-informed alternative when microservices "introduce excessive complexity or costs".

## **3\. An Evidence-Based ROI Model for the "Human Refactor"**

### **3.1 A Quantitative Framework for VSA \+ MMA Adoption**

The "Human Refactor" represents a significant upfront investment. A quantitative model is required to justify this cost to leadership by forecasting the return. This model adapts standard test automation ROI and project ROI frameworks.  
The core formulas are:

*   
*   
*   
* 

### **3.2 Input Parameters: Quantifying the Investment (The "Costs")**

* C\_{refactor} (Refactor Cost): Total engineer-hours for the initial VSA code migration and creation of the enabling platform, multiplied by the fully-loaded cost per engineer-hour.  
* C\_{train} (Training Cost): Cost per engineer for comprehensive training in VSA, Domain-Driven Design, and *Team Topologies*.  
* C\_{dip} (Productivity Dip Cost): A critical, often-missed cost. A temporary 20-30% dip in velocity is expected as teams navigate the "unfreeze" and "change" stages. This cost is modeled as: (Avg\\\_Velocity\\\_Points\\\_per\\\_Month) \\times (\\%\\\_Dip) \\times (Dip\\\_Duration\\\_in\\\_Months) \\times (Cost\\\_per\\\_Point).  
* C\_{infra} (Infrastructure Cost): New licensing for platform tools, CI/CD pipeline upgrades, and Testcontainers Cloud or equivalent.

### **3.3 Output Metrics: Calculating the Return (The "Benefits")**

The benefits are calculated by *monetizing the DORA metrics* , the industry standard for measuring high-performing teams.

* B\_{velocity} (Velocity Gain): Monetized from DORA's **Deployment Frequency** and \**Lead Time for Change*\*. The transition to autonomous stream-aligned teams, which *Team Topologies* enables, directly improves these metrics. This benefit is calculated by the value of delivering 40-75% more features and revenue per year.  
* B\_{quality} (Quality & Stability Gain): Monetized from DORA's **Change Failure Rate (CFR)** and **Mean Time to Restore (MTTR)**. The VSA/Testcontainers model provides higher-fidelity testing, and autonomous teams can restore service faster. This benefit is calculated from the cost savings of 50-80% fewer production defects and shorter outages.  
* B\_{retention} (Retention Gain): This is the *human* ROI. The *Team Topologies* model is explicitly designed to manage and *reduce cognitive load*. High cognitive load and "low-value-added tasks" (like managing mocks) are primary drivers of developer burnout. This benefit is calculated from reduced attrition: (Old\\\_Attrition\\\_Rate \- New\\\_Attrition\\\_Rate) \\times (Avg\\\_Cost\\\_to\\\_Replace\\\_Engineer).

### **3.4 Table 2: ROI Simulation Inputs/Outputs (Comparative Analysis)**

The ROI model scales differently based on organizational size and (political) friction.

| Org. Profile | Key Drivers | C\_refactor / C\_dip | B\_{velocity} | B\_{quality} / B\_{retention} | Breakeven | 3-Year ROI |
| :---- | :---- | :---- | :---- | :---- | :---- | :---- |
| **Startup** | Speed to Market | **Very Low** | High | Low | **N/A** (Baseline) | N/A |
| **SME** | Speed, Cost-Benefit | **Medium** | **Very High** | Medium | **12-18 Months** | **300-450%** |
| **Enterprise** | Risk Reduction, Stability | **Very High** | Medium | **Very High** | **24-36 Months** | **150-250%** |

This analysis reveals that **Small and Mid-Size Enterprises (SMEs)** are the "sweet spot" for this transformation. They are large enough to experience the acute pain of a scaling monolith but small enough to execute the Human Refactor without the crippling political inertia of a large enterprise. Startups should adopt VSA from day one. Enterprises have a slower, more expensive path, but the ROI is justified by risk reduction and talent retention.

## **4\. The Human Refactor: Quantifying and Mitigating Cultural Friction**

### **4.1 Reframing Architectural Dogma: Developer Psychology and Cognitive Load**

A successful Human Refactor requires un-learning deeply ingrained architectural "dogma" and reframing the principles based on developer psychology and cognitive load.

* **"Embrace Duplication" :**  
  * **The Dogma:** "DRY (Don't Repeat Yourself) is an absolute good." This is a cognitive bias.  
  * **The Nuance:** The principle "Duplication is far cheaper than the wrong abstraction" is the correct context. The purpose of abstraction is not to reduce *code*, but to "create a new semantic level" (Dijkstra).  
  * **VSA Context:** In a VSA, prematurely abstracting a simple helper function into a "shared library" re-introduces *coupling* between two otherwise-independent slices. This *breaks* the VSA model and its primary benefit (independent deployment). It is *orders of magnitude* cheaper to duplicate 10 lines of code than to create a new, forced sociotechnical dependency. The Human Refactor re-trains developers to fear *coupling* more than they fear *duplication*.  
* **"Server-Driven UI (SDUI) is a trap" :**  
  * **The Dogma:** "All modern applications must be Single Page Applications (SPAs) with a separate JSON API."  
  * **The Nuance:** SDUI (where the server sends rendered HTML or UI-driving JSON ) is seeing a strong resurgence.  
  * **VSA Context:** A "stream-aligned team" owns the *entire feature, end-to-end*. This *liberates* them from a "one-size-fits-all" UI architecture. For a complex, interactive feature, they can use an SPA. But for a simple "Settings" or "Profile" page, they can use SDUI, letting the *slice's own backend* render the UI. This *dramatically* reduces cognitive load by eliminating the need for a separate API, client-side state management, and complex data fetching, allowing the team to focus on the business problem.

### **4.2 Measuring the Transformation: Pre- vs. Post-VSA Sociotechnical Metrics**

The human benefits of the transition can be quantified by measuring the friction in the *system of work*.

* **Communication Overhead :**  
  * *Pre-VSA (Metric):* Number of cross-team JIRA tickets, meetings, and pull request (PR) dependencies required to deliver a single feature.  
  * *Post-VSA (Goal):* This metric approaches zero. The feature is developed, tested, and deployed entirely *within* the boundaries of a single stream-aligned team.  
* **Decision Latency :**  
  * *Pre-VSA (Metric):* Time from "feature requested" to "first line of code committed." This is often weeks or months, as the request waits in the separate queues of the horizontal teams.  
  * *Post-VSA (Goal):* This metric approaches zero. The autonomous stream-aligned team can pull, plan, and execute work without external dependencies.  
  * *Proxy Metric:* The DORA metric **Lead Time for Change** is a direct, quantitative, and easily-measured proxy for *both* Communication Overhead and Decision Latency.  
* **Conway's Law Alignment :**  
  * *Pre-VSA:* The organization is *fighting* Conway's Law. The org chart (horizontal) is misaligned with the desired architecture (modular features). A Harvard study proved this: tightly-coupled, co-located teams produce tightly-coupled, monolithic code.  
  * *Post-VSA:* The organization is *using* Conway's Law. The org chart (stream-aligned teams) is *intentionally designed* to *produce* the desired architecture (modular, vertical slices). This state is known as "Socio-Technical Congruence".

### **4.3 Table 3: The Human Refactor Readiness Matrix**

This matrix is a sociotechnical checklist (Objective 5\) to assess an organization's *readiness* for the Human Refactor. It helps leadership identify and mitigate the *human blockers* before starting the expensive technical work.

| Sociotechnical Dimension | 1: Blocked (High Risk) | 2: Aware (Medium Risk) | 3: Ready (Low Risk) |
| :---- | :---- | :---- | :---- |
| **Leadership & Vision** | "Architecture is an IT problem." No executive buy-in. | "We've heard VSA is good. We've funded a 'technical' pilot." | "Execs have publicly committed to the *organizational* change (Team Topologies) and have funded the expected 'productivity dip'." |
| **Middle Management** | Functional managers (DBA/QA leads) see VSA as a threat to their power, team size, and control. | Managers are verbally supportive, but their incentives remain unchanged (e.g., "control," "empire size"). | Managers are actively retrained as "Enabling" or "Platform" leads. Incentives are shifted to *enablement* and *platform adoption*. |
| **Team Skills & Culture** | "I-shaped" specialists. Low psychological safety. "That's not my job." | Teams are "cross-functional" (one of each specialist) but still operate in mini-silos. | Culture of "Expert Generalists". High psychological safety. The *team* owns the problem end-to-end, from UI to DB. |
| **Platform Maturity** | No platform. Each team builds their own CI/CD, testing, and infra. High cognitive load. | A central "DevOps" team exists, but it is a bottleneck, not a self-service platform. | A mature *Platform Team* provides a self-service "paved path" that makes the "right way" (VSA, secure, testable) the "easy way." |

## **5\. Outlook (2025–2027): AI Governance as the Evolution of Team Topologies**

### **5.1 The Emerging Landscape of Hybrid Human-AI Teams (2025)**

The software development industry is in the early stages of a profound paradigm shift, moving from "AI as a tool" (e.g., Copilot) to "AI as a teammate". This new model, termed "Agentic Software Engineering (SE 3.0)" , involves autonomous AI agents capable of writing, testing, and submitting code.  
This shift introduces the central challenge for 2025-2027: **The "Speed vs. Trust" Gap.**  
Analysis of the 2025 AIDev dataset, which captured over 456,000 pull requests from autonomous AI agents, provides the first empirical evidence of this gap :

* **Speed:** AI agents demonstrate massive, "hyper-productive" throughput. In one case, a single developer submitted 164 agent-authored PRs in just three days—a volume that had previously taken three *years* of human-only work.  
* **Trust:** This speed is decoupled from quality. Agent-authored PRs are **accepted less frequently** than human-authored PRs. They are also **structurally simpler**; only 9.1% of agent-PRs introduced changes in cyclomatic complexity, compared to 23.3% of human-PRs.

This creates a new bottleneck: the *volume* of low-to-medium trust code generated by AI agents now *overwhelms* the *human capacity* for review and verification.

### **5.2 Measurable Limitations: Why Hallucination is a Governance Problem**

The "hallucinations" and drift of Large Language Models (LLMs) are not abstract flaws; they are concrete, measurable business liabilities that cannot be solved by simply "improving the model." They are *governance* failures.  
Recent (2024-2025) analyses provide concrete examples of this risk :

* **Fabricated Liability:** An autonomous procurement bot *fabricates a 30-page phantom contract*, creating an unauthorized spending risk and potential for fraud.  
* **Synthetic Risk Alerts:** A compliance agent for a bank *invents a "synthetic risk alert"* for a legitimate wire transfer, freezing the transaction and forcing an expensive, mandatory regulatory audit for a fictional scenario.

In both cases, the AI was "correct" in *form* (it produced a plausible-looking document) but disastrously "wrong" in *policy* and *context*. The AI lacked constraints.

### **5.3 The Arela Model: Policy-Driven Governance as a Trust-Building Layer**

The solution to the "Speed vs. Trust" gap is not to slow down the AI, but to *build verifiable trust* into the system. This is achieved with a *rule-enforcing policy layer*—conceptualized here as the "Arela Model"—that sits between AI agents and the production codebase.  
This exact solution is now being validated in 2024-2025 research. One proposed framework that "integrates custom-defined, rule-based logic to constrain... LLM behavior" was able to achieve an **85.5% improvement in response consistency**.  
This is the ultimate synthesis of this report:

1. VSA and MMA create clean, enforceable *technical boundaries* (the Slices).  
2. *Team Topologies* creates clean, autonomous *human and communication boundaries* (the Teams).  
3. This well-defined sociotechnical system is the **prerequisite** for safe AI deployment.

The "Arela Model" acts as the *digital "Team API"* for the AI agent. It enforces the policies defined by the VSA and the team. For example, the governance layer would *allow* an AI agent to refactor code *inside* its assigned Vertical Slice. However, the policy layer would *automatically block* the AI agent if it attempts to:

* Add a dependency to another slice (violating VSA principles).  
* Modify the slice's public API contract without authorization (violating the team's "API").  
* Write code that fails a "synthetic risk" check (violating business policy ).

This model solves the new bottleneck. It provides *verifiable trust* *before* the code ever reaches a human reviewer, allowing the organization to safely leverage the *speed* of AI agents.

### **5.4 Readiness Milestones (2026–2027): From "Agentic SE" to Verifiable Trust**

The strategic challenge for 2026–2027 is shifting from *AI-generated code* to *AI-verified code*. The frontier of research is moving to "AI-based verification and validation (V\&V) of AI generated code" because *trust* is now the limiting factor, not generation.  
This leads to the final, critical conclusion:

* Organizations that **fail** the "Human Refactor"—those that remain as horizontal, component-siloed, monolithic organizations—will be **incapable of safely deploying autonomous AI agents.** They have no clean boundaries, no "Team APIs," and no "Slice architecture" for a governance layer (like Arela) to enforce. They will be stuck in the "AI-as-a-tool" (Copilot) era, overwhelmed by the untrusted output.  
* Organizations that **succeed** in the "Human Refactor" will have created the necessary sociotechnical boundaries to implement AI governance. They will be the first to safely leverage "AI-as-a-teammate," unlocking exponential gains in productivity and quality.

The Human Refactor—the indivisible synthesis of VSA, MMA, and Team Topologies—is therefore no longer just "best practice." It is the central, strategic prerequisite for surviving and thriving in the 2026–2027 Agentic AI transition.

## **Bibliography**

Vertical Slicing, Smaller is Better. (n.d.). *ResearchGate*. Vertical vs Horizontal Slicing in Data Science Deliverables. (n.d.). *Data Science PM*. Why the Best Developers are OBSESSED with Vertical Slices. (2023, August 31). *Dev Leader*. Unlocking Agile Success: The Power of Vertical Slicing in User Stories. (2024, May 22). *Medium*. Why Vertical Slices are the BEST way to Build Software. (2023, September 6). *YouTube*. Change Management Models Compared: Lewin vs Kotter vs ADKAR. (n.d.). *Sideways6*. ADKAR vs Kotter: Compare Change Management Models. (n.d.). *Prosci*. 10 Best Change Management Models & Frameworks. (2024, October 15). *Whatfix*. 9 proven change management models and frameworks in 2025\. (n.d.). *Lumenalta*. 10 change management models to know in 2025\. (2025, October 20). *Zendesk*. Vertical Slices: The Software Engineering BEST Practice You Need To Know\! (2024, February 23). *YouTube*. Can someone explain why we ditched monoliths for microservices? (2024, May 25). *Reddit*. Digital transformation and changes in organizational structure: Empirical evidence from industrial organizations. (2025, May 1). *Taylor & Francis Online*. Digital Transformation and Changes in Organizational Structure: Empirical Evidence from Industrial Organizations. (2025, May). *ResearchGate*. Resource Management in IoT-Driven 6G Networks: A Survey of Existing Solutions and Future Directions. (2024, December 11). *IEEE Xplore*. Management Sciences and Future Challenges. (2022). *FH Münster*. Design of transformation initiatives implementing organisational agility: an empirical study. (2021, May 15). *SpringerLink*. Team Topologies: The Leading Approach to Team-of-Teams Org Design. (n.d.). *Team Topologies*. Case studies and examples of Team Topologies. (n.d.). *Team Topologies*. Team Topologies: Five Years of Transforming Organizations. (n.d.). *IT Revolution*. Key concepts from Team Topologies. (n.d.). *Team Topologies*. Key concepts from Team Topologies. (n.d.). *Team Topologies*. Team Topologies: The Leading Approach to Team-of-Teams Org Design. (n.d.). *Team Topologies*. Team Topologies: A Summary. (n.d.). *Runn.io*. Implementing a Team Topology. (2022, October 2). *4lex.nz*. TeamTopologies. (2023, July 25). *Martin Fowler*. Data Mesh. (n.d.). *Thoughtworks*. Effective ML Teams (Chapter 1). (n.d.). *Thoughtworks*. Patterns for legacy displacement Pt. 1\. (2024, February 15). *Thoughtworks*. Designing Platform-Centric Organizations with Domain Thinking and Team Topologies. (2024, October 31). *Team Topologies*. Looking Glass: A guide to the tech trends shaping 2023\. (2023). *Thoughtworks*. Team Topologies: The DevOps framework for effective teams. (n.d.). *Atlassian*. Organize teams into distinct topology types to optimize the value stream. (n.d.). *AWS Well-Architected Guidance*. The Four Team Types. (2019, June 10). *IT Revolution*. Key concepts from Team Topologies. (n.d.). *Team Topologies*. TeamTopologies. (2023, July 25). *Martin Fowler*. Organize teams into distinct topology types to optimize the value stream. (n.d.). *AWS Well-Architected Guidance*. Case studies and examples of Team Topologies. (n.d.). *Team Topologies*. TeamTopologies. (2023, July 25). *Martin Fowler*. Organize teams into distinct topology types to optimize the value stream. (n.d.). *AWS Well-Architected Guidance*. The evolution of socio-technical systems. (1981). *Internet Archive*. A Framework for Assessing Strategies to Combat Individuals' Resistance to Technological Innovation. (2021, October). *ResearchGate*. Organizational design and Team Topologies in the age of AI. (2025, September 18). *YouTube*. Organizational design and Team Topologies in the age of AI. (2025, September 18). *Thoughtworks*. Case studies and examples of Team Topologies. (n.d.). *Team Topologies*. Team Topologies: The Leading Approach to Team-of-Teams Org Design. (n.d.). *Team Topologies*. Team Topologies and Data Mesh: A perfect match. (2022, November 23). *Thoughtworks*. Socio-technical systems engineering. (2011, January 1). *Oxford Academic*. CSCW 2026 Papers. (n.d.). *ACM CSCW*. Team topologies fix the Spotify model. (2022, July 10). *George Vassilis Blog*. Kotter's Change Management Model. (n.d.). *Agile Academy*. The 8 Steps for Leading Change. (n.d.). *Kotter International*. Kotter's 8-Step Change Management Theory. (n.d.). *Prosci*. Agile Transformation in the context of Kotter's Change Model. (2018, July 17). *Medium*. Applying Kotter's 8-Step Model to agile transformation Team Topologies. (2024, May 25). *YouTube*. What Is The ADKAR Model For Change Management? (n.d.). *6Sigma.us*. The ADKAR Change Model and Customer Journey Maps. (n.d.). *Heart of the Customer*. Case Studies Using the Prosci ADKAR Model. (n.d.). *Aithor*. Improving the Patient Experience With the ADKAR Change Model. (2020, August 19). *PubMed Central*. Customer Success Stories. (n.d.). *Prosci*. Change Management Models Compared: Lewin vs Kotter vs ADKAR. (n.d.). *Sideways6*. ADKAR vs Kotter: Compare Change Management Models. (n.d.). *Prosci*. 10 change management models to know in 2025\. (2025, October 20). *Zendesk*. Change Management Models. (n.d.). *Prosci*. Quantifying software architecture quality: report on the first international workshop on software architecture metrics. (2015, August). *ResearchGate*. ArchHypo: A Hypothesis Engineering Technique for Managing Uncertainties in Software Architecture. (2024, December). *IEEE Xplore*. Antecedents to the Adoption of Software Engineering Processes in Small Software Companies. (2021, November 11). *IEEE Xplore*. Factors Influencing Cloud System Integrators' Intention to Adopt Software-Defined Networking Technology. (2020). *Walden University*. Socio-technical systems engineering. (2011, January 1). *Oxford Academic*. Integrated Sensing, Computation, and Communication for 6G-Enabled Edge AI. (2025, January 13). *arXiv*. Scalable Correctness and Performance Measurement of Collective Operations. (n.d.). *ETH Zürich*. The Impact of Active Messages on Workstation Cluster Performance. (1996, October). *UC Berkeley*. Role of machine learning algorithms in optimizing emerging technologies for 6G networks. (2024, October 16). *PubMed Central*. Conway's Law: The Silent Force Shaping Your Architecture. (2024, May 15). *Medium*. Conway's Law Revisited: The Evidence for a Task-Based Perspective. (2008, November). *ResearchGate*. Conway's law. (n.d.). *Wikipedia*. Demystifying Conway's Law. (2021, March 18). *Thoughtworks*. Empirical Research Supports Conway's Law. (2008, August 14). *Allan Kelly*. Socio-Technical Congruence: A Framework for Assessing the Impact of Technical and Work Dependencies. (2010, May). *ResearchGate*. How Modern Engineering Teams Approach Refactoring. (n.d.). *Stepsize*. Development of a Framework and Checklist to Guide the Translation of AI Systems for Clinical Care. (2024). *University of Illinois Chicago*. Why Developers Do (Not) Test: A Socio-Technical Grounded Theory of Software Testing. (2025, April 14). *arXiv*. The need for a sociotechnical systems (STS) approach to artificial intelligence in healthcare. (2023, January 20). *PubMed Central*. Modular Monolith: Is This the Trend in Software Architecture? (2024, January). *arXiv*. Clean Architecture with Modular Monolith and Vertical Slice (2025). (2025, October 24). *Medium*. Architecture Patterns: Modular Monolith. (2022, July 10). *Sufficiently Advanced*. Modular Monolithic Architecture in Cloud Environments: A Systematic Literature Review. (2024, November). *MDPI*. Mastering Clean Architecture, Modular Monoliths, and Vertical Slices in.NET. (2024, August 28). *YouTube*. Using testcontainers vs mocking repositories. (2024, May 25). *Reddit*. Supercruising with Testcontainers: Making tests faster and more flexible. (2025, October 10). *Java Pro*. Testcontainers Cloud vs. Docker-in-Docker for Testing Scenarios. (2024, June 6). *Docker Blog*. Why Your Microservice Integration Tests Miss Real Problems. (2024, April 18). *Medium*. The Death of Mocks by Testcontainers. (2024, August 1). *Dev.to*. Software Testing Trends for 2025: AI, Automation, and Beyond. (n.d.). *AccelQ*. Best Practices for End-to-End Testing in 2025\. (n.d.). *Bunnyshell*. Hybrid Penetration Testing: A 2025 Guide. (n.d.). *BrightDefense*. Testing: When does it make sense to mock a Database or use a real test Database? (2021, February). *Reddit*. Should I mock my database? (2024, April 17). *Medium*. All-Hazards Return of Investment Model Development for U. S. Army Installation Resilience. (2024, February). *MDPI*. AI in Neuroimaging for Alzheimer’s Disease: A 2020–2025 Narrative Review. (2024, December 31). *PubMed Central*. 2023 Annual Report to the Legislature. (2023). *State of Hawaii DBEDT*. Market and Technical Assessment of Advanced Fuel and Powertrain (AFV) Technologies for Heavy-Duty Vehicles. (2020, December). *California Air Resources Board*. An accelerated approach to implementing earned value management in small and mid-sized enterprises. (2007, July). *Project Management Institute*. Vertical Slice Architecture and Comparison with Clean Architecture. (2024, April 4). *Medium*. Why Vertical Slice Architecture is the Key to Modernizing Insurance Systems. (2024, July 17). *Praxent*. Business Intelligence in Small and Medium Enterprises. (2023). *Politecnico di Torino*. A Systematic Review of Big Data Impact on SMEs: Drivers, Barriers, and Business Performance. (2024, November 13). *MDPI*. Cross-project defect prediction: a review. (2021, March). *MDPI*. Episode 32: Event Sourcing, with Andrzej Ludwikowski. (2024, May 25). *Libsyn*. Duplication is far cheaper than the wrong abstraction. (2015, February). *Reddit*. Cognitive Load Theory in Software Engineering. (2021). *Lund University*. The Uncanny Valley: A systematic review of the empirical research. (2015, April 21). *Frontiers in Psychology*. AI in Education: A Systematic Review of Cognitive and Neuroscience Studies. (2024, November 29). *PubMed Central*. Cognitive Biases in Software Engineering. (2017). *Brunel University London*. A Systematic Review of Human-AI Collaboration: Dimensions, Modalities, and Open Challenges. (2025, March 14). *arXiv*. Human-AI Teaming with Multi-Agent Generative AI: Developer Perspectives on Collaboration, Capabilities, and Challenges. (2025, October 9). *arXiv*. A Systematic Review of Human-AI Collaboration: Dimensions, Modalities, and Open Challenges. (2024, February 8). *arXiv*. Human-AI Teams Produce a Similar Amount of Output as Human-Human Teams with Half as Many Workers. (2025, March 29). *arXiv*. MindMeld: A Novel Experimental Platform for Studying Human-AI Collaboration. (2025, March 29). *arXiv*. Hallucinations in LLMs: What You Need to Know Before Integration. (n.d.). *Master of Code*. 5 Real-World AI Hallucination Examples & How to Fix Them. (n.d.). *Galileo*. Auto-Data-Science: An End-to-End Data Science Workflow with LLM-Powered Autonomous Agents. (2025, October 7). *arXiv*. A Rule-Based Governance Framework for Enhancing LLM Response Consistency in Production. (2024, December 31). *MDPI*. Seizing the agentic AI advantage. (2025, January). *McKinsey & Company*. Agentic Software Engineering (SE 3.0): A New Era of Autonomous AI Teammates. (2025, September 10). *arXiv*. Agentic AI in Software Engineering: Beyond the Prompt. (2025, August 28). *arXiv*. AIDev: A Large-Scale Dataset of Autonomous AI Agent Contributions in Open Source. (2025, July 25). *arXiv*. Agents in Software Engineering: Survey, Landscape, and Vision. (2024, September 23). *arXiv*. The AI Race: 2025-2027 Outlook. (n.d.). *ai-2027.com*. Team Topologies: The DevOps framework for effective teams. (n.d.). *Atlassian*. Agile & DevOps Delivery Efficiency Levers. (n.d.). *Umbrex*. Is Your IT Culture Blocking Uptime, Speed, and Innovation? (n.d.). *CIOMastermind.com*. Optimizing for high-performance technology in competitive markets. (n.d.). *Reaktor*. VSM Reference Architectures. (n.d.). *VSM Consortium*. Measuring productivity in agile software process: a systematic mapping study. (2021). *Semantic Scholar*. A Quasi-Experiment on the Impact of Agile Methodology on Software Development Performance. (2021, September). *MDPI*. Yes, you can measure software developer productivity. (2022, May 23). *McKinsey & Company*. Measuring Productivity in Agile Software Development Process: A Scoping Study. (2015, December). *ResearchGate*. Challenges in Using Agile Software Development Performance Metrics: A Mixed-Method Study. (2024, July 9). *arXiv*. Modular Monolithic Architecture in Cloud Environments: A Systematic Literature Review. (2024, November). *MDPI*. ELLIIT Annual Report 2021\. (2021). *ELLIIT*. Measure and Improve Developer Productivity: A Complete Guide. (n.d.). *OpsLevel*. What Are DORA Metrics and How Can They Help You? (2023, June 21). *New Relic*. What Are DORA Metrics? (n.d.). *Planview*. How to Measure Developer Productivity. (n.d.). *Jellyfish*. Flow Metrics: The 5 Key Metrics for Measuring Software Delivery. (n.d.). *GetDX*. Team Topologies: The DevOps framework for effective teams. (n.d.). *Atlassian*. Measuring Platform Impact Beyond DORA Metrics: Team Cognitive Load as a Proxy Metric. (2024, May 24). *YouTube*. Mastering Team Effectiveness: The Power of Managing Cognitive Load. (2024, July 23). *Team Topologies*. How Engineering Teams Transcend Cognitive Limitations Through Strategic Platform Thinking. (n.d.). *SoftwareSeni*. Measuring socio-technical congruence in software development. (2014). *Journal of Software: Evolution and Process*. A Framework for Measuring Socio-Technical Congruence in Software Development. (2020). *WARSE*. The Science of Teams in C2 Sociotechnical Systems. (2009). *International C2 Journal*. A Survey on Communication Overhead Reduction in the IoT-Edge-Cloud Continuum. (2024, April 30). *arXiv*. Communication overhead: The hidden cost of team cognition. (2004, January). *ResearchGate*. SDLC: A Guide to the Software Development Lifecycle. (n.d.). *Palo Alto Networks*. Service Performance Monitoring: A Comprehensive Guide. (2024, June 14). *Splunk*. What Are DORA Metrics & How They Supercharge DevOps? (2024, August 28). *Appinventiv*. Software Engineering Metrics That Matter. (n.d.). *Chaordic*. How observability-driven development creates elite performers. (2022, October 12). *Stack Overflow Blog*. Team Topologies: How to structure your teams (and how not to). (2025, March 6). *Team Topologies*. To Be and Not to Be: Middle Managers’ Resistance in Self-Managing Organizations. (2023). *M@n@gement*. A new leadership challenge: Navigating political polarization in organizational teams. (2023, February). *ResearchGate*. To Be and Not to Be: Middle Managers’ Resistance in Self-Managing Organizations. (2023). *management-aims.com*. Team Topologies: How to structure your teams (and how not to). (2025, March 6). *Team Topologies*. Failed squad goals: A former Spotify engineer on why the "Spotify Model" failed. (2020, July 20). *Jeremiah Lee*. A Multi-Case Study on Dynamic Reteaming in Practice. (2024). *RIT Scholar Works*. Reading Team Topologies (2nd time). (2025, May 24). *patricia.no*. Case study: scalable, extensible identity provider. (2019, May 5). *George Vassilis Blog*. How do you keep agile truly agile when scaling? (2024, May 25). *Reddit*. The Art of Splitting an ART. (2022, August 23). *Agile Alliance*. Succeeding with new technology: Breaking down adoption barriers. (2024, November 6). *Red Hat*. Team Topologies: Organizing Business and Technology Teams for Fast Flow (Excerpt). (2019). *IT Revolution*. SAFe Teams. (n.d.). *Agility at Scale*. Clean Architecture With.NET. (2024). *Scribd*. Programming Professional Learning. (2024, October). *Packt*. A Domain-Specific Language for Lightweight Generation of User Interfaces. (2022). *Andrea L. Thesis*. Scaling mobile delivery. (2024, November 14). *Thoughtworks*. BrightDigit Episodes. (2025, June). *BrightDigit*. Modular Monolithic Architecture in Cloud Environments: A Systematic Literature Review. (2024, November). *MDPI*. Service Weaver: Write Modular Monoliths, Deploy as Microservices. (2024). *Scribd*. Google Open Source Blog: March 2023\. (2023, March). *Google Open Source Blog*. Performance Impact of Microservice Granularity Decisions: An Empirical Evaluation Using the Service Weaver Framework. (2024, August). *ResearchGate*. Modular Monoliths: Revolutionizing Software Architecture for Efficient Payment Systems in Fintech. (2023, October). *ResearchGate*. How to Calculate Test Automation ROI. (n.d.). *BrowserStack*. Test Automation ROI: How to Calculate the ROI of Test Automation. (2024, March 14). *Medium*. Automated Testing Strategy ROI for Enterprises. (n.d.). *Virtuoso*. A Pragmatic Approach to Test Automation in Practice. (2009). *DiVA Portal*. A Model for Calculating Return on Investment of Software Test Automation. (2007). *University of South Florida*. Benefit-Cost Analysis of Data Integration. (2012). *University of Pennsylvania*. Cost-Benefit Analysis of Using Dependency Knowledge at Integration Testing. (2016, July). *ResearchGate*. A Longitudinal Case Study on Continuous Software Engineering. (2021). *DiVA Portal*. Cost-Benefit Analysis of Automation Testing: Is It Worth the Investment? (n.d.). *Beta Breakers*. An evidence-based digital health cost-benefit analysis (eHealth-CBA) framework. (2024, June 6). *PubMed Central*. Automation has started to feel like another full-time job. (2024, May 25). *Reddit*. Automation Testing Services. (n.d.). *Belitsoft*. Quality Assurance (QA) Automation Engineer Interview Questions. (n.d.). *Startup.jobs*. An Empirical Study of the Costs and Benefits of Test Oracles. (n.d.). *University of Albany*. MBTCover: A Model-Based Testing Tool for Code and Test Coverage. (2024, August 12). *arXiv*. Evaluating and Improving Coverage-Based Test Suite Reduction. (2013). *University of Texas at Austin*. An Evaluation of Test Coverage Tools in Software Testing. (2012, June). *ResearchGate*. An In-Depth Study of Runtime Verification Overheads during Software Testing. (2024). *Cornell University*. Inaccessible Website. AIDev: A Large-Scale Dataset of Autonomous AI Agent Contributions in Open Source. (2025, July 25). *arXiv*. A Rule-Based Governance Framework for Enhancing LLM Response Consistency in Production. (2024, December 31). *MDPI*. Modular Monolithic Architecture in Cloud Environments: A Systematic Literature Review. (2024, November). *MDPI*. The Art of Splitting an ART. (2022, August 23). *Agile Alliance*.

#### **Works cited**

1\. Socio-technical systems: From design methods to systems engineering | Interacting with Computers | Oxford Academic, https://academic.oup.com/iwc/article/23/1/4/693091 2\. Team Topologies \- Organizing for fast flow of value, https://teamtopologies.com/ 3\. Agile, DevOps & Delivery-Efficiency Levers | Umbrex, https://umbrex.com/resources/strategic-cost-cutting-playbook/agile-devops-delivery-efficiency-levers/ 4\. How to measure and improve developer productivity: a complete guide \- OpsLevel, https://www.opslevel.com/resources/measure-and-improve-developer-productivity-a-complete-guide 5\. Team Topologies: How to structure your teams using nine principles and six core patterns for better value, https://teamtopologies.com/news-blogs-newsletters/2025/3/6/team-topologies-how-to-structure-your-teams 6\. Why Testcontainers Cloud is a Game-Changer Compared to Docker-in-Docker for Testing Scenarios, https://www.docker.com/blog/testcontainers-cloud-vs-docker-in-docker-for-testing-scenarios/ 7\. Why Your Microservice Integration Tests Miss Real Problems | by Signadot \- Medium, https://medium.com/@signadot/why-your-microservice-integration-tests-miss-real-problems-27d76fcc6cc8 8\. The death of mocks by Testcontainers \- DEV Community, https://dev.to/benjamindaniel/the-death-of-mocks-by-testcontainers-2535 9\. Agentic Software Engineering: Foundational Pillars and a Research Roadmap \- arXiv, https://arxiv.org/html/2509.06216v1 10\. The Rise of AI Teammates in Software Engineering (SE) 3.0 \- arXiv, https://arxiv.org/pdf/2507.15003 11\. Conway's Law: The Silent Force Shaping Your Architecture | by Enes Hoxha | Medium, https://medium.com/@eneshoxha\_65350/conways-law-the-silent-force-shaping-your-architecture-18c61899732e 12\. Conway's law \- Wikipedia, https://en.wikipedia.org/wiki/Conway%27s\_law 13\. Demystifying Conway's Law | Thoughtworks, https://www.thoughtworks.com/en-us/insights/articles/demystifying-conways-law 14\. Vertical Slicing: Smaller is Better \- ResearchGate, https://www.researchg