Mastering Blazor Development in VS Code with AI Instruction Files

 

From Boilerplate to Vibe Coding

For years, serious Blazor development meant Visual Studio, long scaffolding sessions, and an uncomfortable amount of manual boilerplate. VS Code was “nice for quick edits,” but not where real Blazor work happened.

That has changed.

Today, VS Code + the C# Dev Kit + AI instruction files has quietly become one of the most powerful Blazor development environments available—if you know how to use it correctly.

The shift isn’t just about tooling.
It’s about who writes the code.

You no longer write every line.
You design the rules, and the AI executes.

Welcome to vibe coding.

---

The VS Code + Blazor Renaissance

VS Code’s evolution into a first-class Blazor IDE happened in layers:

• C# Dev Kit brought proper project system awareness, debugging, and Razor support
• Razor tooling stabilized enough for real component work
• AI copilots moved from autocomplete to context-aware code generation

The result?

VS Code is no longer “lighter Visual Studio.”
It’s a prompt-driven architecture workbench.

When paired with AI agents (Claude, Cursor, Copilot Chat), VS Code becomes the place where:

• Architecture decisions are encoded
• Standards are enforced automatically
• Boilerplate becomes cheap and consistent

But only if you stop treating AI like ChatGPT-in-a-textbox.

---

The Power of Instruction Files (claude.md, .cursorrules, .copilot-instructions)

Most developers use AI like this:

“Here’s my feature. Please write some code.”

And then they’re surprised when:

• The architecture shifts mid-project
• EF Core is replaced with Dapper for no reason
• Naming conventions evaporate after file three

The problem isn’t the AI.

The problem is stateless prompting.

Instruction Files Fix This

Instruction files give the AI persistent architectural memory at the repository level.

Examples:

• claude.md
• .cursorrules
• .copilot-instructions

These files answer questions before they’re asked:

• What patterns are allowed?
• What frameworks are forbidden?
• How should data access be implemented?
• How are Blazor components named and structured?

Instead of repeating yourself in every prompt, you:

• Encode standards once
• Enforce them everywhere
• Let the AI generate within constraints

This is the difference between AI assistance and AI-driven development.

---

Defining Coding Standards in the Instruction File

Instruction files are not documentation.
They are contracts.

Here’s what actually belongs in them.

Language & Project Standards

## General C# Standards

 

- Use file-scoped namespaces only

- Target .NET 8+

- Prefer C# 12 features when appropriate

- Primary constructors are required for services and handlers

- No region directives

- No implicit usings inside generated code

Blazor Component Conventions

## Blazor Component Standards

 

- Components must use @code blocks (no code-behind)

- One public component per .razor file

- Parameters must be explicitly typed

- Events use EventCallback<T>

- No direct DbContext usage inside components

- UI logic stays in the component; business logic goes in services

This is how you prevent the AI from inventing “creative” interpretations of clean code.

---

Pattern Enforcement: The Database Example (Where Most AI Goes Off the Rails)

Data access is where AI hallucinations do the most damage.

If you don’t lock this down, you’ll eventually see:

• Random repository abstractions
• DbContext usage leaking into UI
• DTOs skipped “for simplicity”
• Query logic scattered across layers

So you define the pattern once.

Example: Enforcing a Service + EF Core Pattern

Below is a realistic claude.md snippet that forces consistency.

## Data Access Architecture (Mandatory)

 

- Entity Framework Core is the only data access technology

- DbContext usage is allowed ONLY inside *Data* implementations

- Blazor components must never reference DbContext directly

- Services expose DTOs, never EF entities

- Mapping must be explicit (no AutoMapper)

 

### Required Pattern

 

For each domain feature:

 

1. A service interface in /Services

2. A concrete EF Core implementation in /Data

3. DTOs in /Contracts

4. The DbContext injected only into the EF implementation

 

### Example Structure

 

/Features/Orders

  /Contracts

    OrderDto.cs

  /Services

    IOrderService.cs

    OrderService.cs

  /Data

    OrderService.Ef.cs

Service Contract Example

public interface IOrderService

{

    Task<IReadOnlyList<OrderDto>> GetOpenOrdersAsync(CancellationToken ct);

}

EF Core Implementation Standard

public sealed class OrderService(AppDbContext db) : IOrderService

{

    public async Task<IReadOnlyList<OrderDto>> GetOpenOrdersAsync(CancellationToken ct)

        => await db.Orders

            .Where(o => o.Status == OrderStatus.Open)

            .Select(o => new OrderDto(

                o.Id,

                o.CustomerName,

                o.Total))

            .ToListAsync(ct);

}

This does three critical things:

1. Constrains architecture
2. Prevents mid-project pattern drift
3. Keeps AI output boring—in the best way possible

Boring code scales.

---

The Vibe Coding Workflow (How This Actually Works Day-to-Day)

This isn’t magic. It’s a loop.

1. Architect the Instruction File

You decide:

• Patterns
• Boundaries
• Trade-offs

The AI does not get a vote here.

2. Prompt the Feature

Your prompt becomes simple:

“Add order filtering by date range following existing service and DTO standards.”

No re-explaining.
No copy-pasting rules.
No architectural babysitting.

3. Review Against Standards

You’re no longer reviewing logic line-by-line.
You’re reviewing conformance.

• Did it follow the pattern?
• Did it leak dependencies?
• Did it respect boundaries?

4. Refine the Rules (Not the Code)

If something goes wrong, you don’t fix the file.

You fix the instruction.

That improvement applies forever.

---

Why This Changes the Role of the Blazor Developer

This approach flips the value stack:

• Junior devs → writing boilerplate
• Senior devs → reviewing syntax

Becomes:

• AI → writing boilerplate
• Developers → designing systems

You stop being a typist.
You become an architect with leverage.

Blazor, with its strong typing and clear boundaries, is perfect for this style of development—if you embrace instruction-first thinking.

---

Final Thought

AI will not replace Blazor developers.

But Blazor developers who understand:

• Instruction files
• Pattern enforcement
• Vibe-driven workflows

Will absolutely replace those who don’t.

The future of Blazor isn’t about writing faster code.

It’s about writing fewer rules—and enforcing them perfectly.