VS Code Agent Mode: An Architect's Perspective for the .NET Ecosystem

GitHub Copilot agent mode had several enhancements in VS Code as part of its July 2025 release, further bolstering its capabilities. The supported LLMs are getting better iteratively; however, both personal experience and academic research remain divided on future capabilities and gaps. I've had my own learnings exploring agent mode for the last few months, ever since it was released, and had the best possible outcomes with Claude Sonnet Models.

After 18 years of building enterprise systems — ranging from integrating siloed COTS to making clouds talk, architecting IoT telemetry data ingestions and eCommerce platforms — I've seen plenty of "revolutionary" tools come and go. I've watched us transition from monoliths to microservices, from on-premises to cloud, from waterfall to agile. I've learned Java 1.4, .NET 9, and multiple flavors of JavaScript. Each transition revealed fundamental flaws in how we think about software construction.

The integration of generative AI into software engineering is dominated by pattern matching and reasoning by analogy to past solutions. This approach is philosophically and practically flawed. There's active academic research that surfaces this problem, primarily the "Architectures of Error" framework that systematically differentiates the failure modes of human and AI-generated code.

At the moment, I'm neither convinced by Copilot's capability nor have I found reasons to hate it. My focus in this article is more on the human-side errors that Agent Mode helps us recognize.

Why This Isn't Just Another AI Tool

Copilot's Agent Mode isn't just influencing how we build software — it's revealing why our current approaches are fundamentally flawed.

The uncomfortable reality: Much of our architectural complexity exists because we've never had effective ways to encode and enforce design intent.

We write architectural decision records that few read. We create coding standards that get violated under pressure. We design patterns that work beautifully when implemented correctly but fail catastrophically when they're not.

Agent Mode surfaces this gap between architectural intent and implementation reality in ways we haven't experienced before.

The Constraint Problem We've Been Avoiding

Here's something I've learned from working on dozens of enterprise projects: Most architectural failures aren't technical failures — they're communication failures.

We design a beautiful hexagonal architecture, document it thoroughly, and then watch as business pressure, tight deadlines, and human misunderstanding gradually erode it. By year three, what we have bears little resemblance to what we designed.

// What we designed
public class CustomerService : IDomainService<Customer>
{
    // Clean separation, proper dependencies
}

// What we often end up with after several iterations
public class CustomerService 
{
    // Direct database calls mixed with business logic
    // Scattered validation, unclear responsibilities
    // Works, but violates every architectural principle
}

Agent Mode forces us to confront this differently. AI can't read between the lines or make intuitive leaps. If our architectural constraints aren't explicit enough for an AI to follow, they probably aren't explicit enough for humans either. 

The Evolution from Documentation to Constraints

In my experience, the most successful architectural approaches have moved progressively toward making correct usage easy and incorrect usage difficult.

Early in my career, I relied heavily on documentation and code reviews. Later, I discovered the power of types, interfaces, and frameworks that guide developers toward correct implementations. Now, I'm exploring how to encode architectural knowledge directly into development tooling (and Copilot).

/ Evolution 1: Documentation-based (fragile)
// "Please ensure all controllers inherit from BaseApiController"

// Evolution 2: Framework-based (better)
public abstract class BaseApiController : ControllerBase
{
    // Common functionality, but still optional
}

// Evolution 3: Constraint-based (AI-compatible)
public interface IApiEndpoint<TRequest, TResponse>
    where TRequest : IValidated
    where TResponse : IResult
{
    // Impossible to create endpoints that bypass validation
}

The key insight: Each evolution makes architectural intent more explicit and mechanical. Agent Mode simply pushes us further along this path. 

We can work around most AI problems like the "AI 90/10 problem" arising from hallucinated APIs, non-existent libraries, context-window myopia, systematic pattern propagation, and model drift. LLM responses are probabilistic by nature, but they can be made deterministic by specifying constraints.

Practical Implications

Working with Agent Mode on real projects has revealed several practical patterns:

1. Requirement Specification

Vague prompts produce (architecturally) inconsistent results. This isn't a limitation — it's feedback about the clarity of our thinking at any role, especially around SDLC, including the architect. We struggled with the same problems with the advent of the outsourcing era, too. SaaS inherits this problem through its extensibility and flexibility.

[BAD] Inviting infinite possibilities: "Create a service for managing customers relationship"
[GOOD] More effective: "Create a CustomerService implementing IDomainService<Customer> 
   with validation using FluentValidation and error handling via Result<T> pattern"

2. The Composability Test

If AI struggles to combine your architectural patterns correctly, human developers probably do too. 

They excel at pattern matching but fail at:

• Systematicity: Applying rules consistently across contexts
• Productivity: Scaling to larger, more complex compositions
• Substitutivity: Swapping components while maintaining correctness
• Localism: Understanding global vs. local scope implications

This also helps to identify the architectural complexity.

3. The Constraint Discovery Process

Working with AI has helped me identify implicit assumptions in existing architectures that weren't previously explicit. These discoveries often lead to better human-to-human communication as well. 

The Skills That Remain Valuable

Based on my experience so far, certain architectural skills have become more important now:

• Domain understanding: AI can generate technically correct code, but understanding business context and constraints remains fundamentally human.
• Pattern recognition: Identifying when existing patterns apply and when new ones are needed becomes crucial for defining AI constraints.
• System thinking: Understanding emergent behaviors and system-level properties remains beyond current AI capabilities.
• Trade-off analysis: Evaluating architectural decisions based on business context, team capabilities, and long-term maintainability.

What's Actually Changing

The shift isn't as dramatic as "AI replacing architects or developers." It's more subtle:

• From implementation to intent: Less time writing boilerplate, more time clarifying what we actually want the system to do.
• From review to prevention: Instead of catching architectural violations in code review, we encode constraints that prevent them upfront.
• From documentation to automation: Architectural knowledge becomes executable rather than just descriptive.

These changes feel significant to me, but they're evolutionary rather than revolutionary.

Challenges I'm Still Working Through

• The learning curve: Developing fluency with constraint-driven development requires rethinking established habits.
• Team adoption: Not everyone is comfortable with AI-assisted development yet, and that's understandable.
• Tool maturity: Current AI tools are impressive but still have limitations around context understanding and complex reasoning.
• Validation strategies: Traditional testing approaches may not catch all AI-generated issues, so we're developing new validation patterns.

A Measured Prediction

Based on what I'm seeing, I expect a gradual shift over the next 3–5 years toward:

• More explicit architectural constraints in codebases
• Increased automation of pattern enforcement
• Enhanced focus on domain modeling and business rule specification
• Evolution of code review practices to emphasize architectural composition over implementation details

This won't happen overnight, and it won't replace fundamental architectural thinking. But it will change how we express and enforce architectural decisions.

What I'm Experimenting With

Currently, I'm exploring:

1. Machine-readable architecture definitions that can guide both AI and human developers.

{
  "architecture": {
    "layers": ["Api", "Application", "Domain", "Infrastructure"],
    "dependencies": {
      "Api": ["Application"],
      "Application": ["Domain"],
      "Infrastructure": ["Domain"]
    },
    "patterns": {
      "cqrs": {
        "commands": "Application/Commands",
        "queries": "Application/Queries",
        "handlers": "required"
      }
    }
  }
}

2. Architectural testing frameworks that validate system composition automatically.

[Test]
public void Architecture_Should_Enforce_Layer_Dependencies()
{
    var result = Types.InCurrentDomain()
        .That().ResideInNamespace("Api")
        .ShouldNot().HaveDependencyOn("Infrastructure")
        .GetResult();
    
    Assert.That(result.IsSuccessful, result.FailingTypes);
}

[Test]
public void AI_Generated_Services_Should_Follow_Naming_Conventions()
{
    var services = Types.InCurrentDomain()
        .That().AreClasses()
        .And().ImplementInterface(typeof(IDomainService))
        .Should().HaveNameEndingWith("Service")
        .GetResult();
    
    Assert.That(services.IsSuccessful);
}

3. Constraint libraries that make common patterns easy to apply correctly, starting with domain primitives.

```csharp
// Instead of generic controllers, define domain-specific primitives
public abstract class DomainApiController<TEntity, TDto> : ControllerBase
    where TEntity : class, IEntity
    where TDto : class, IDto
{
    // Constrained template that AI can safely compose
}

// Service registration primitive
public static class ServiceCollectionExtensions
{
    public static IServiceCollection AddDomainService<TService, TImplementation>(
        this IServiceCollection services)
        where TService : class
        where TImplementation : class, TService
    {
        // Validated, standard registration pattern
        return services.AddScoped<TService, TImplementation>();
    }
}

4. Documentation approaches that work well with AI-assisted development. An example is documenting architecture in the Arc42 template in Markdown, diagrams in Mermaid embedded in Markdown.

Early results are promising, but there's still much to learn and explore.

Looking Forward

After 18 years in this field, I've learned to be both optimistic about new possibilities and realistic about the pace of change.

VS Code Agent Mode represents an interesting step forward in human-AI collaboration for software development. It's not a silver bullet, but it is a useful tool that can help us build better systems — if we approach it thoughtfully.

The architectures that thrive in an AI-assisted world won't necessarily be the most sophisticated ones. They'll be the ones that most clearly encode human insight in ways that both AI and human developers can understand and extend.

That's a worthy goal, regardless of the tools we use to achieve it.

Final Thoughts

The most valuable architectural skill has always been clarity of thought about complex systems. AI tools like Agent Mode don't change this fundamental requirement — they just give us new ways to express and validate that clarity.

As we navigate this transition, the architects who succeed will be those who remain focused on the essential questions: What are we trying to build? Why does it matter? How can we make success more likely than failure?

The tools continue to evolve, but these questions remain constant.

I'm curious about your experiences with AI-assisted development. What patterns are you seeing? What challenges are you facing? The best insights come from comparing experiences across different contexts and domains.