DEV Community: Majdi Zlitni

Playwright Agents The Architecture of Self-Healing

Majdi Zlitni — Tue, 01 Sep 2026 12:22:25 +0000

TL;DR

Playwright Agents (v1.56+) introduce three specialized agents Planner, Generator, and Healer that run on the Model Context Protocol (MCP) to explore your app, write Markdown test plans, synthesize validated Playwright specs, and self-heal broken tests when the UI changes. This guide walks through the architecture, setup, a full worked example, and the ROI case for bringing this into an enterprise CI/CD pipeline.

TL;DR
The problem with E2E testing today
1. The agentic testing triad
- Why MCP matters here
2. What each agent actually does
- 🎭 Planner — the strategic test architect
- 🎭 Generator — live-validated code synthesis
- 🎭 Healer — autonomous runtime self-repair
3. Setting it up
- Prerequisites
- Initialize the agents
- Resulting project structure
4. Walkthrough: a movies catalog feature
- Step 1 — write a deterministic seed fixture
- Step 2 — plan the feature with the Planner
- Step 3 — generate the executable test
- Step 4 — let the Healer fix what breaks
5. Is it worth it for an enterprise suite?
- The ROI case
- Governance and security, non-negotiable
- Where it still needs a human
Wrapping up

The problem with E2E testing today

End-to-end testing has always had the same three enemies: fragile locators, slow test authoring, and maintenance that eats a huge chunk of sprint velocity every time the UI changes. AI code assistants helped a little, but they generate code blind no access to the live DOM, no idea what actually renders in the browser.

Playwright Agents (v1.56+) close that gap. Instead of "AI-assisted code generation," you get agentic test automation: agents that operate inside a live execution loop, actually clicking through your app, reading the accessibility tree, and validating what they generate against the running page.

1. The agentic testing triad

Three agents share one Model Context Protocol connection, each responsible for a different stage of the test lifecycle:

Agent	Core input	What it does	Output
Planner	Seed fixture, app URL, requirements	Navigates the app, maps user flows, considers edge cases	Markdown test specs (`specs/*.md`)
Generator	Markdown plan + live browser context	Executes actions live, validates locators, verifies assertions	Executable spec files (`tests/*.spec.ts`)
Healer	Failing test logs, trace artifacts, DOM snapshot	Debugs step by step, evaluates selector changes, adjusts waits	Patched, re-verified test files (or explicit skips)

Why MCP matters here

MCP is what lets the LLM host VS Code Copilot Chat, Claude Code, OpenCode, whatever you're driving this from talk directly to the browser runtime instead of guessing at markup. Concretely, the agents read:

Accessibility tree snapshots ARIA roles and accessible names instead of brittle CSS selectors or auto-generated XPaths
Network traces XHR/fetch activity, so assertions can match real server-side state instead of just "something changed on screen"
Console and error diagnostics stack traces and failed assertions, which is what the Healer uses to figure out why a test broke ## 2. What each agent actually does

🎭 Planner the strategic test architect

The Planner doesn't write code first it writes a plan. It walks the live UI using a seed fixture you provide, then produces a structured Markdown spec with explicit preconditions, numbered steps, and expected outcomes. That Markdown is meant to be read and edited by a human before anything gets generated, which is the point: it's a review gate for QA leads, not a black box.

🎭 Generator live-validated code synthesis

The Generator turns that Markdown into runnable TypeScript. The key difference from a static code generator is that it validates every locator against the live DOM as it writes, preferring resilient selectors like getByRole(), getByLabel(), and getByTestId(). It also looks at your existing fixtures and page objects so the generated code matches your project's conventions instead of reinventing them.

🎭 Healer autonomous runtime self-repair

When a test breaks because of a UI refactor, a DOM shift, changed test data, or timing the Healer reruns it in a managed debug environment, diffs the DOM snapshot against what the test expected, and patches the specific thing that changed: a selector, an assertion target, a wait. If the underlying feature is actually broken (not just relocated), it skips the test and flags it for a human instead of forcing a false pass.

3. Setting it up

Prerequisites

Node.js LTS (v20.x or higher)
VS Code v1.105+ if you want native Copilot Chat agent integration
@playwright/test v1.56.0 or higher

# Confirm your Playwright version supports agents
npx playwright --version
# Must be >= 1.56.0

Initialize the agents

init-agents wires the agents into whichever execution loop you're using:

# Upgrade Playwright core
npm install -D @playwright/test@latest

# Bind to VS Code Copilot Chat
npx playwright init-agents --loop=vscode

# Or bind to Claude Code
npx playwright init-agents --loop=claude

# Or bind to OpenCode
npx playwright init-agents --loop=opencode

Resulting project structure

4. Walkthrough: a movies catalog feature

Step 1 write a deterministic seed fixture

Seed files establish a known starting state auth, seeded data, starting route before any agent starts exploring.

// tests/seed.spec.ts
import { test as base, expect } from '@playwright/test';
import { listTest as test } from './helpers/list-test';

/**
 * Seed context for authenticated movie management operations.
 * Copied by the Generator into every synthesized test file.
 */
test.describe('Seed context: Logged-in administrator', () => {
  test('Initialize movies list fixture', async ({ listPage }) => {
    const page = listPage;
    await expect(page.getByRole('heading', { name: 'Movie Catalog' })).toBeVisible();
  });
});

Step 2 plan the feature with the Planner

@planner Generate a comprehensive test plan for the "Adding a Movie" and
"Managing Movie Catalog" features. Use tests/seed.spec.ts as the entry seed context.
Save the output spec to specs/movies-list-plan.md.

The Planner explores the app and produces something like:

# Test Plan: Movies Catalog Management

## Context & Prerequisites
- **Seed Context:** `tests/seed.spec.ts`
- **User Role:** Authenticated Administrator

## Test Scenarios

### 1. Adding a New Movie Entry
- **Preconditions:** Catalog loaded, add button accessible.
- **Steps:**
  1. Click "Add Movie" primary action button.
  2. Fill "Title", "Genre", and "Release Date" input fields.
  3. Submit the form via "Save Movie" button.
- **Expected Results:**
  - Form dialog closes.
  - Toast notification displays a success message.
  - New movie record appears in the grid view.

### 2. Catalog Validation & Boundary Constraints
- **Steps:**
  1. Submit "Add Movie" form with empty mandatory fields.
- **Expected Results:**
  - Inline validation highlights missing title and release year.

Step 3 generate the executable test

@generator Generate Playwright TypeScript test files based on the scenarios defined in
specs/movies-list-plan.md under section "Adding a New Movie Entry".

// tests/movies/add-movie.spec.ts
// spec: specs/movies-list-plan.md
// seed: tests/seed.spec.ts
import { listTest as test } from '../helpers/list-test';
import { expect } from '@playwright/test';

test.describe('Movies Catalog Management', () => {
  test('Adding a New Movie Entry', async ({ listPage }) => {
    const page = listPage;

    // Step 1: Click "Add Movie" primary action button
    const addMovieBtn = page.getByRole('button', { name: 'Add Movie' });
    await expect(addMovieBtn).toBeVisible();
    await addMovieBtn.click();

    // Step 2: Fill mandatory fields using resilient ARIA-based locators
    await page.getByLabel('Movie Title').fill('Inception');
    await page.getByLabel('Genre').selectOption('Sci-Fi');
    await page.getByLabel('Release Year').fill('2010');

    // Step 3: Submit the form
    await page.getByRole('button', { name: 'Save Movie' }).click();

    // Assertions: confirm UI response and grid update
    await expect(page.getByRole('status')).toContainText('Movie successfully added');
    await expect(page.getByRole('cell', { name: 'Inception' })).toBeVisible();
  });
});

Step 4 let the Healer fix what breaks

Say the "Add Movie" button gets renamed to "Create New Entry." The suite fails:

npx playwright test tests/movies/add-movie.spec.ts

Invoke the Healer:

@healer Run and fix the failing test in tests/movies/add-movie.spec.ts

It reruns the test in a debug session, diffs the accessibility tree, finds the renamed control, and patches the file:

// HEALED BY PLAYWRIGHT HEALER AGENT (v1.56)
// Original selector: page.getByRole('button', { name: 'Add Movie' })
// Updated to match the current accessible element:
const addMovieBtn = page.getByRole('button', { name: 'Create New Entry' });
await addMovieBtn.click();

5. Is it worth it for an enterprise suite?

The ROI case

Metric	Traditional automation	Playwright agentic workflow	Impact
Test creation velocity	2–4 hours per complex flow	15–30 minutes (plan + generate)	~75% faster authoring
Maintenance overhead	High locator upkeep eats sprint time	Low Healer handles most repairs	~65% less maintenance time
Locator quality	Depends on developer discipline	Standardized, accessibility-first	Fewer flaky tests
Exploratory coverage	Limited by manual capacity	Expanded by autonomous Planner exploration	Roughly 3.5x more scenarios covered

These numbers will vary by codebase and team, but the direction is consistent: less time spent re-fixing selectors, more time spent on actual test strategy.

Governance and security, non-negotiable

Never hardcode secrets. Inject credentials from environment variables or a vault:

  await page.getByLabel('Password').fill(process.env.E2E_TEST_PASSWORD!);

Watch what leaves your network. If you're on a public LLM endpoint, application metadata and test code are part of the prompt context. Use a local model, an Azure OpenAI instance, or an enterprise Copilot tenant if that's a concern.
Review everything. Treat generated and healed tests like any other code change require a PR review before merging.

Where it still needs a human
Complex business logic deep financial calculations and domain-specific workflows need explicit human-designed test boundaries.
Adversarial security testing these agents validate expected paths, not attack surfaces. They are not a substitute for penetration testing.
Visual and UX nuance the agents check for presence and correct attributes, not whether something looks right.

Wrapping up

Playwright Agents don't replace test strategy they replace the tedious parts of it: writing boilerplate steps, chasing broken selectors, and re-authoring the same flows by hand. The Planner keeps humans in the loop before code exists; the Generator keeps the code honest against the live app; the Healer keeps the suite green without silently hiding real regressions.

If you want to try it on your own project:

Upgrade to @playwright/test ^1.56.0.
Write one solid seed fixture (tests/seed.spec.ts).
Pick a single critical flow login, checkout, registration and run @planner then @generator on it.
Require PR review on anything the agents produce or heal. If you try this on a real suite, I'd genuinely like to hear how the Healer holds up against your actual UI churn drop a comment below.

Agent Skills and how to use them

Majdi Zlitni — Sat, 29 Aug 2026 17:00:46 +0000

If your AI assistant keeps giving generic, unreliable answers, the problem is not the model. It is the missing structure around it. That is exactly what Agent Skills solve.

Modern LLMs are strong enough to handle complex tasks. The real issue is that they are working without stable context, rules, or domain-specific instructions that guide how they should behave in your environment.

This is where Agent Skills change the equation.

Agent Skills Overview
Why Agent Skills?
How Do Agent Skills Work?
Start from real expertise
Project skills vs personal skills
How Copilot uses agent skills
Creating and adding a skill
Example SKILL.md file
Triggering a skill in VS Code
Skills vs custom instructions

Agent Skills Overview

Agent skills are instructions and resources that a model can use for a given task to improve its output.

Agent skills are designed to work with modern AI coding assistants and LLM-based agents. While our current implementation leverages GitHub Copilot across tools like VS Code and CLI workflows, the architecture remains provider-agnostic and can be adapted to any compatible AI platform.

You can create your own skills so an agent can perform tasks in a specific way.

You can use both skills and custom instructions to teach Copilot how to work in your repository and how to perform specific tasks.

Why Agent Skills?

Agents are massively capable, but often they don't have the needed context for more reliable output. Using skills we can solve this by packaging user-specific context into a portable version an agent can load on demand so agents can be:

Domain expertise: Capture specialized knowledge as reusable instructions and resources.

Repeatable workflows: Turn multi-step tasks into consistent, auditable procedures.

Cross-product reuse: Build a skill once and use it across any skills-compatible agent.

How Do Agent Skills Work?

Agents load skills in three stages:

Discovery: At startup, agents load only the name and description of each available skill, just enough to know when it might be relevant.

Activation: When a task matches a skill's description, the agent reads the full SKILL.md instructions into context.

Execution: The agent follows the instructions, optionally executing bundled code or loading referenced files as needed.

Full instructions load only when a task calls for them, so agents can keep many skills on hand with only a small context footprint.

Start from real expertise

A common pitfall in skill creation is asking an LLM to generate a skill without providing domain-specific context, relying solely on the LLM’s general training knowledge. The result is vague, generic procedures (“handle errors appropriately,” “follow best practices for authentication”) rather than the specific API patterns, edge cases, and project conventions that make a skill valuable.

Effective skills are grounded in real expertise. The key is feeding domain-specific context into the creation process.

Project skills vs personal skills

Project skills, stored in your repository (.github/skills, .claude/skills, or .agents/skills)

Personal skills, stored in your home directory and shared across projects (~/.copilot/skills or ~/.agents/skills)

How Copilot uses agent skills

When performing tasks, Copilot will decide when to use your skills based on your prompt and the skill's description.

When Copilot chooses to use a skill, the SKILL.md file will be injected in the agent's context, giving the agent access to your instructions. It can then follow those instructions and use any scripts or examples you may have included in the skill's directory.

For Copilot code review on GitHub:

If you want to ensure Copilot code review uses a skill, place it in a review-focused directory like code-review.

Skills in .github/skills can also be picked up automatically when relevant.

Creating and adding a skill

To create an agent skill, you write a SKILL.md file and optionally add supporting files like scripts or examples.

Create a skills directory in one of these locations:

Project skills:

.github/skills  
.claude/skills  
.agents/skills

Personal skills:

~/.copilot/skills  
~/.agents/skills

Each skill must live in its own folder:
.github/skills/webapp-testing

Folder names must be lowercase and use hyphens.

Inside it, create SKILL.md.

Important

Skill files must be named SKILL.md.

It must include:

YAML frontmatter:

- name (required): lowercase identifier matching folder name
- description (required): when the skill should be used
- license (optional)

Markdown body:

- Instructions
- Examples
- Guidelines for the agent

Example SKILL.md file

---
name: resume-update
description: Use this skill when the user asks to update, rewrite, or tailor a resume for a job application.
---

# Resume Update Skill

## Instructions
- Rewrite resumes based on job description
- Improve clarity and structure
- Use concise bullet points
- Highlight relevant skills and achievements
- Keep it ATS-friendly

## Example
User: Update my resume for a .NET backend role  
Assistant: Returns a rewritten resume emphasizing .NET, APIs, and backend experience.

Triggering a skill in VS Code

Option 1: Natural language

Just ask normally:

Help me update my resume for a .NET backend role

If skill matches description → it auto-loads

Option 2: Slash command

/resume-update
/webapp-testing
/github-actions-debugging

You can also add extra context:

/resume-update for senior backend role

SKILL.md structure

---
name: skill-name
description: When and why this skill should be used
---

Then markdown instructions:

### Instructions
- Step 1
- Step 2
- Step 3

Skills vs custom instructions

We recommend using custom instructions for simple instructions relevant to almost every task (for example information about your repository's coding standards), and skills for more detailed instructions that Copilot should only access when relevant.

10 EF Core Performance Mistakes That Ship to Production

Majdi Zlitni — Wed, 26 Aug 2026 16:16:05 +0000

If your API is fast with seed data but slows down in production, EF Core is rarely the root cause. It is usually the amplifier.

Most teams do not have one catastrophic query. They have many small query-shape decisions that compound into high P95 latency, lock pressure, and unnecessary database scale-up.

This article is a practical field guide to 10 EF Core performance mistakes I keep seeing in production .NET APIs, and the fixes that usually move the needle first.

In this post

Why this matters in production
How to spot issues fast
Architecture map of the anti-patterns
Quick summary of all 10 mistakes
Mistake 1: N+1 Queries
Mistake 2: Missing AsNoTracking
Mistake 3: Loading Whole Entities
Mistake 4: No Pagination
Mistake 5: Client-Side Evaluation
Mistake 6: Tracking Read-Only Data
Mistake 7: Cartesian Explosion
Mistake 8: No Compiled Queries
Mistake 9: Missing Indexes
Mistake 10: SaveChanges in a Loop
Batch ops caveat: ExecuteUpdate and ExecuteDelete
Decision matrix: what to fix first
What EF Core 10 improves
Troubleshooting checklist
Production baseline checklist
Wrap-up

What counts as a performance mistake?

An EF Core performance mistake is any data-access pattern that:

returns correct results in development
passes tests
but degrades badly under real data volume or concurrency

In other words: correctness is not enough. Query shape is architecture.

How to detect issues quickly

Before changing code, instrument first.

builder.Services.AddDbContext<AppDbContext>(options =>
        options.UseNpgsql(connectionString)
                     .LogTo(Console.WriteLine, LogLevel.Information)
                     .EnableSensitiveDataLogging(builder.Environment.IsDevelopment()));

Use this as your first pass:

many SELECTs per request: likely N+1
huge result row count for small parent set: likely cartesian explosion
read endpoints with heavy tracking snapshots: missing AsNoTracking
list endpoints without LIMIT/TOP: missing pagination

The anti-pattern map

Prefer scalable quality for sharing and zoom:

TL;DR

The 10 mistakes:

N+1 queries
Loading full entities instead of projections
Missing AsNoTracking on read paths
No pagination on list endpoints
Client-side evaluation patterns
Tracking read-only graphs
Cartesian explosion from multiple collection Includes
No compiled queries on hot paths
Missing indexes on hot filters and joins
SaveChanges inside loops

Plus one operational caveat: ExecuteUpdate and ExecuteDelete bypass the change tracker and should be coordinated with explicit transaction boundaries when mixed with tracked changes.

1) N+1 Queries

Problem

You load a parent set, then each navigation access triggers another database round trip.

Smell

Request count looks normal
SQL command count explodes

Fix

Use projection or eager loading intentionally.

var orders = await db.Orders
    .Where(o => o.CustomerId == customerId)
    .Select(o => new OrderDto
    {
        Id = o.Id,
        Total = o.Items.Sum(i => i.Price * i.Quantity),
        ItemCount = o.Items.Count
    })
    .ToListAsync();

Use projection for API contracts. Use Include when domain logic needs full related aggregates in memory.

2) Missing AsNoTracking

Problem

Tracking every entity in read paths increases memory and CPU for change detection.

Fix

Default to no tracking on query endpoints.

var posts = await db.Posts
    .AsNoTracking()
    .Where(p => p.Published)
    .OrderByDescending(p => p.PublishedAt)
    .ToListAsync();

For write paths, opt back in explicitly:

var entity = await db.Orders
    .AsTracking()
    .FirstAsync(o => o.Id == id);

3) Loading Whole Entities

Problem

Fetching full rows when you only need 2-3 columns inflates payload and materialization cost.

Fix

Project to DTOs.

var users = await db.Users
    .AsNoTracking()
    .Select(u => new UserListItem(u.Id, u.DisplayName, u.AvatarUrl))
    .ToListAsync();

Projection usually improves all of these at once:

less SQL payload
lower materialization cost
better API boundary control

4) No Pagination

Problem

Unbounded lists eventually become accidental load tests.

Fix

Apply deterministic ordering and pagination.

var page = await db.Articles
    .AsNoTracking()
    .OrderByDescending(a => a.CreatedAt)
    .Skip((request.Page - 1) * request.PageSize)
    .Take(request.PageSize)
    .ToListAsync();

Always cap server-side page size to prevent accidental heavy requests.

5) Client-Side Evaluation

Problem

Non-translatable logic forces EF Core to pull data and evaluate in memory.

Fix

Keep filters SQL-translatable, move complex logic after narrowing rows.

var filtered = await db.Payments
    .AsNoTracking()
    .Where(p => p.Status == PaymentStatus.Settled && p.Amount > 1000)
    .Select(p => new { p.Id, p.Amount, p.Reference })
    .ToListAsync();

Rule: filter, sort, and paginate before materialization. Terminal operators like ToListAsync end translation and execute the query.

6) Tracking Read-Only Data

Problem

Long-running request flows with tracked entities increase memory pressure and GC churn.

Fix

Use one of these:

AsNoTracking for pure reads
AsNoTrackingWithIdentityResolution when graph identity consistency matters

var graph = await db.Orders
    .AsNoTrackingWithIdentityResolution()
    .Include(o => o.Customer)
    .Include(o => o.Items)
    .ToListAsync();

Use AsNoTrackingWithIdentityResolution when you need consistent identity for repeated references in the same result graph without full tracking overhead.

7) Cartesian Explosion

Problem

Multiple collection Includes on one query create row multiplication.

Fix

Use split queries when shape is unavoidable.

var orders = await db.Orders
    .AsNoTracking()
    .Include(o => o.Items)
    .Include(o => o.Events)
    .AsSplitQuery()
    .ToListAsync();

Split queries trade one huge cross-product for multiple smaller round trips. Measure both modes on your dataset.

8) No Compiled Queries

Problem

Hot endpoints repeatedly pay query translation overhead.

Fix

Precompile stable high-frequency queries.

private static readonly Func<AppDbContext, Guid, Task<User?>> GetUserByIdCompiled =
    EF.CompileAsyncQuery((AppDbContext ctx, Guid id) =>
        ctx.Users.AsNoTracking().FirstOrDefault(u => u.Id == id));

var user = await GetUserByIdCompiled(db, userId);

Apply compiled queries selectively to the highest-throughput read paths.

9) Missing Indexes

Problem

Critical filters run as scans instead of seeks.

Fix

Create indexes for common predicates and sort keys.

modelBuilder.Entity<Order>()
    .HasIndex(o => new { o.CustomerId, o.CreatedAt });

Also verify generated SQL and query plan. If your API filter is index-friendly but still scanning, check collation mismatches and implicit conversions.

Index guidance for hot endpoints:

index frequent WHERE columns
index JOIN keys
index ORDER BY columns used with pagination
prefer composite indexes that match filter plus sort order

10) SaveChanges in a Loop

Problem

Each SaveChanges call is a round trip and transaction boundary.

Fix

Batch entity changes, then persist once.

foreach (var item in items)
{
    item.MarkProcessed();
}

await db.SaveChangesAsync();

If this runs inside import or reconciliation jobs, moving SaveChanges out of the loop is often the fastest immediate win.

Batch operations caveat: ExecuteUpdate and ExecuteDelete

ExecuteUpdate and ExecuteDelete bypass the change tracker.

If you mix them with tracked updates in the same unit of work, wrap all operations in an explicit transaction to protect consistency.

await using var tx = await db.Database.BeginTransactionAsync();

await db.Orders
    .Where(o => o.Status == OrderStatus.Pending && o.CreatedAt < cutoff)
    .ExecuteUpdateAsync(setters => setters
        .SetProperty(o => o.Status, OrderStatus.Expired));

var audit = new CleanupAudit { RanAtUtc = DateTime.UtcNow, Affected = affectedRows };
db.CleanupAudits.Add(audit);

await db.SaveChangesAsync();
await tx.CommitAsync();

Why this matters:

batch operators bypass change tracker
SaveChanges interceptors may not run for those operations
mixed write workflows should be explicit about consistency boundaries

Decision matrix: what to fix first

Symptom	First fix	Then
many SQL commands per request	projection or Include cleanup	check for lazy loading
large payload and high serialization cost	projection DTOs	AsNoTracking
high read-path memory	AsNoTracking	query-level projection
huge row count from multi-Include	AsSplitQuery	endpoint-specific projection
slow large updates/deletes	ExecuteUpdate/ExecuteDelete	transaction + audit strategy
list endpoint timeout	pagination	indexes + projection
hot endpoint CPU overhead	compiled query	caching strategy

What EF Core 10 helps with

EF Core 10 improves the baseline, but does not remove bad query-shape costs.

Useful platform gains to leverage:

improved LINQ ergonomics for complex joins
stronger behavior around split-query ordering consistency
runtime improvements in .NET 10 that help materialization paths

Bottom line: framework improvements help good patterns more than bad ones.

Troubleshooting checklist

If performance is still poor after applying fixes:

inspect SQL plans, not just LINQ
verify index usage in production-like data
confirm no hidden lazy-loading path in serialization
verify query count per request in high-traffic endpoints
re-check page size limits and default sort columns

A practical baseline for production APIs

Default reads to no tracking
Project to DTOs, not entities
Always paginate collection endpoints
Measure query count per request
Add indexes for every top-traffic filter
Compile truly hot queries
Avoid SaveChanges inside loops
Treat batch operations as transaction-sensitive writes

EF Core performance is rarely about a single trick. It is about query-shape discipline applied consistently.

If your P95 latency is climbing, start here before scaling the database tier.

Wrap-up

Most EF Core incidents are not caused by obscure ORM bugs. They come from convenient defaults used past their safe limits.

If you adopt one rule, make it this: shape data intentionally at query time. Projection, no-tracking reads, pagination, and index-aware filters will solve most production regressions before you need heavier architecture changes.

Effective AI Agents with GitHub Copilot

Majdi Zlitni — Mon, 24 Aug 2026 16:44:08 +0000

The most successful AI agent do NOT use complex and over-engineered frameworks. Instead, they use simple, modular patterns.

To use agents you don't need to learn massive third-party agent frameworks to build powerful AI assistants. Using GitHub Copilot you get all pieces natively:

Copilot Agent Mode
Custom Agents
Agent Skills
Prompt Files
Model Context Protocol (MCP)

I will break down the core principles on how to implement them in your daily development workflow!

What is an AI Agent?
How Effective Agents Work
- Pattern 1: Prompt Chaining
- Pattern 2: Routing
- Pattern 3: Parallelization
- Pattern 4: Orchestrator Workers The Project Manager
- Pattern 5: Evaluator Optimizer
Handoffs Between Agents
- Why Single Agents Fail
- Architect to Developer Handoff
- Preserving Context Across Handoffs
Mastering Agent Skills
- The Copilot Customization Pyramid
- What is an Agent Skill?
- Integrating External Systems via MCP
Quick Comparison Matrix
Conclusion

1. What is an AI Agent?

Before we dive, let's clear up what an Agent actually is.

An agent is as a fully autonomous system using different tools to achieve a request independently

The Basic Building Block

An Augmented LLM is simply a language model (like GPT-5.6 Luna or Claude Opus) connected to:

Context: Your project's code files.
Tools: The ability to run commands and execute tests.
Memory: The chat history.

In GitHub Copilot, every query you send has access to these augmentations natively inside your IDE!

2. How Effective Agents Work

Rather than letting an AI run completely wild, effective agentic systems use one of the folowing core design patterns.

Pattern 1: Prompt Chaining

What it is: Breaking a big task into a sequence of small, step-by-step prompts. Between each step, code execution acts as a Gate to verify output before moving to the next step.
This can be achieved by:

Create a reusable prompt file inside .github/prompts/create-feature.prompt.md:

<!-- .github/prompts/create-feature.prompt.md -->
1. Read the user requirements and generate the Entity Framework Core model in `Domain/Entities/`.
2. Run `dotnet build` in the terminal to verify zero compilation errors.
3. If build succeeds, create the corresponding DTO class in `Application/DTOs/`.

Pattern 2: Routing

It classifying the user's intent and sending the request to a specialized assistant or tool.

Using GitHub Copilot's @ participants:

@workspace: Searches your entire codebase structure.
@azure: Handles cloud infrastructure questions.
@github: Interacts with PRs, issues, and actions.

Pattern 3: Parallelization

This run multiple AI checks simultaneously and combining their output into a single summary.

When running automated GitHub Actions or code reviews, trigger multiple custom prompts in parallel (e.g., checking security flaws, checking unit test coverage, checking formatting) and combine the results.

Pattern 4: Orchestrator Workers The Project Manager

A central agent dynamically breaks a complex, unpredictable request into sub-tasks, delegates work to specialized agents or tool steps, and combines the results.

This is exactly how Copilot Agent Mode works! When you prompt Copilot Agent Mode in VS Code to "Add modern rate-limiting to all ASP.NET Core endpoints," it:

Scans your solution file.
Identifies all endpoint classes.
Edits Program.cs to add middleware.
Updates individual controller attributes.
Runs dotnet build to confirm everything compiles.

Pattern 5: Evaluator Optimizer

One loop generates the solution, while an evaluation step (like a compiler or unit test suite) provides feedback until the code passes all criteria.

It matters because LLM make mistakes, but tools like dotnet test or npm test provide objective ground truth. Letting Copilot fix its own errors based on compiler output makes it dramatically more accurate!

3. Handoffs Between Agents

Why Single Agents Fail

When you try to make one single prompt handle architecture design, database migration, backend coding, and unit testing, you run into Context Rot:

The prompt becomes huge and expensive.
The model forgets early instructions.
The AI gets confused between different roles.

The Solution: Use Agent Handoffs. Divide your system into small, hyper-focused custom agents, and pass the task smoothly from one agent to the next.

Architect to Developer Handoff

In GitHub Copilot, custom agents live inside the .github/agents/ folder as Markdown files with YAML frontmatter.

Step 1: Define the Architect Agent

Create .github/agents/solution-architect.agent.md:

Step 2: Define the Backend Developer Agent

Create .github/agents/backend-developer.agent.md:

Preserving Context Across Handoffs

When passing work between agents, avoid losing context by using these Practices:

File-based handoff:

Agent writes output to a shared workspace file (e.g. .copilot/plans/spec.md) for the next agent to consume.
Structured summary:

Include a short bullet list of key decisions in the handoff prompt.
Minimal tool access:

Grant each agent only the tools it needs (e.g. no terminal access for design agents).

4. Mastering Agent Skills

The Copilot Customization Pyramid

To turn Copilot into a true expert in your codebase, GitHub provides 5 customization layers:

Layer	Component	Purpose
1	Global Rules	`.github/copilot-instructions.md` / `AGENTS.md`
2	Task Prompts	`.github/prompts/*.prompt.md`
3	Specialized Personas	`.github/agents/*.agent.md`
4	Procedural Skills	`.github/skills/*/SKILL.md` (agentskills.io)
5	External Tooling	Model Context Protocol (MCP)

What is an Agent Skill?

While Custom Instructions tell Copilot what style of code to write, an Agent Skill teaches Copilot how to perform a specific standard operating procedure (SOP) step-by-step.

Agent Skills follow the open agentskills.io standard, making them portable across AI environments!

Integrating External Systems via MCP

To connect your Copilot agents to real-world infrastructure (Azure SQL, GitHub Issues, Jira, Redis), use Model Context Protocol (MCP).

Now your agents can directly inspect Azure resource health or query GitHub Issues without leaving VS Code!

Human-in-the-Loop Safety & Guardrails

Never leave an autonomous agent completely unsupervised in production:

Require Confirmation for Destructive Commands: Use terminal execution settings in VS Code to prompt for approval on git push --force, docker run, or az deploy.
Set Iteration Limits: Limit Copilot Agent Mode loops to a maximum of 5–10 attempts so it doesn't get stuck in an endless loop if tests fail.

5. Quick Comparison Matrix

Configuration Type	Where It Lives	Main Purpose
Global Rules	`.github/copilot-instructions.md`	Coding style, project conventions, library choices
Prompt Files	`.github/prompts/*.prompt.md`	Single-click reusable task workflows
Custom Agents	`.github/agents/*.agent.md`	Specialized developer personas & handoff rules
Agent Skills	`.github/skills/*/SKILL.md`	Step-by-step procedure guides (`agentskills.io`)
MCP Servers	`.vscode/mcp.json`	Real-time external API & database integration

6. Conclusion

Building powerful AI agents doesn't require complex external frameworks. By combining GitHub Copilot Agent Mode, Custom Agents, Agent Skills, and MCP, you can build a clean, reliable, and production-grade developer agent right inside your IDE!

Have you built custom agents or skills for GitHub Copilot yet? Let me know in the comments below!

The Context Packet: The Right Architectural Coding Agents

Majdi Zlitni — Mon, 24 Aug 2026 00:44:12 +0000

A coding agent with access to your entire repository does not necessarily understand your system better. It may understand less.

Because a large repository may contains obsolete code, and decisions that were never written down. Giving an agent more files increases the amount of text it can inspect, but this does not guarantee it will identify the constraints that matter more.

The better design is a context packet

a small, versioned, machine-readable description of the system. The packet complements source code by recording the contracts and decisions that source code alone may not reveal.

The Problem: Repository Access Is Not System Understanding

A normal coding request might look simple:

Add retry handling to the payment notification worker.

An agent can find the worker, inspect its dependencies, and produce a patch quickly. But a safe implementation depends on questions that may not be answered in the worker's directory:

Is the message delivered at least once?
Does the payment provider support idempotency keys?
Which exceptions are transient?
Does the consumer rely on a specific delivery count?
Can this change be deployed independently of the producer?

The repository may contain clues, but clues are not contracts.

When the agent receives only the ticket and nearby files, it fills the gaps with plausible assumptions. When it receives the entire repository, it has a different problem: the important rule may be surrounded by thousands of irrelevant or contradictory signals.

The gap comes from context design.

Retrieval Boundaries and Signal Density

AI coding systems have a finite context budget. The deeper concern is signal density: the proportion of useful constraints among all the material an agent must interpret.

Suppose an agent receives 100 files:

10 define the target feature
20 are related infrastructure
30 are historical implementations

The agent can technically read all of them. It still has to decide which rules apply, which code is authoritative, and which behavior is accidental.

More input creates more opportunities for:

Conflicting examples
Outdated implementation patterns
Incorrect dependency inference

The common response is to improve the prompt. But prompts are a weak place to store architecture because they are difficult to version and validate.

The retrieval boundary should answer three questions before content is added to the packet:

Can this change affect it?
Does it define a contract to keep?
Is it up to date for this branch/commit/env?

This turns context selection into a policy that can be inspected and improved.

The Context Packet Pattern

A context packet is the minimal scoped input for a single change or workflow. It includes only the necessary context and constraints, built from a dependency graph instead of folder structure.

A useful packet covers these technical layers:

Intent: expected outcome
Boundary: services, modules, files, data in scope
Contracts: APIs, events, schemas, ownership, compatibility
Constraints: security, reliability, performance, compliance
Evidence: tests, traces, incidents, metrics, examples
Execution policy: allowed tools and required approvals

The packet should be versioned and reviewed like code.
It should also remain small enough that an engineer can read it and update it without a separate platform team.

A Context Packet in a PR

Taking the example of opening a PR titled “Retry payment notifications after provider timeouts.” The agent does not need a second copy of the repository. It needs the small set of facts that determine whether the change is safe.

The context assembler follows the changed worker through its dependency graph and produces a short packet:

change: retry-payment-notifications
owner: payments-platform

intent: Retry provider timeouts without sending a notification twice.

read:
  - PaymentNotificationWorker.cs
  - PaymentProviderAdapter.cs
  - PaymentNotification.v2.schema.json
  - ADR-017-provider-retries.md

edit:
  - PaymentNotificationWorker.cs
  - NotificationReplayTests.cs

must_preserve:
  - NotificationId is stable for every delivery attempt.
  - The adapter classifies provider failures.
  - Dead-letter records include the failure classification.

checks:
  - NotificationReplayTests
  - DeadLetterContractTests

The agent makes one scoped change using the packet. It can read/edit code and rerun tests, but not change infra or identity. CI/CD runs two checks and rejects the PR if it edits outside edit or lacks evidence.

That is the complete loop:

Each field has a job:

read supplies relevant implementation and architecture decisions.
edit limits the proposed diff.
must_preserve records behavior that source code may not explain.
checks connects the packet to the delivery pipeline.

Keep the packet as a change brief, not as a repository summary.

Context Assembler and Dependency Graph

The assembler starts with the files changed by the pull request and follows declared dependencies outward. A simple graph might look like this:

The graph determines what belongs in the packet. A node is included when it is directly changed, is a dependency of a changed node, or defines an operational contract for that dependency. Unrelated services and historical examples stay outside the retrieval boundary.

The assembler can collect artifacts from controlled sources:

Repository ownership metadata
Architecture decision records
API and event schemas

The assembler should rank artifacts by relevance.

Measuring Packet Value

A well-organized packet is useful only when it improves engineering outcomes.

Start with four signals:

Signal	Question
Rework	Did the agent need repeated corrections about the same constraint?
Boundary violations	Did the proposal touch files or tools outside its declared scope?
Evidence coverage	Were the required checks appropriate and actually run?
Review effort	Did reviewers spend less time reconstructing system context?

Tradeoffs and Operational Limits

Context Assembly Has a Maintenance Cost

Owners must update contracts, schemas, and service metadata. This cost is real. It is also preferable to depending on undocumented knowledge that exists only in one engineer's memory.

Narrow Context Can Hide Important Dependencies

A packet that is too narrow can create false confidence. Include dependency evidence and make the agent able to request an expanded boundary. Expansion should be logged and, for sensitive boundaries, approved.

Versioning Adds Friction

Recording packet versions, source revisions, and freshness introduces process overhead. That overhead pays for itself mainly on changes where debugging and rollback are expensive.

Authorization Belongs to the Runtime

A packet can say that an agent may edit a path, but the runtime must enforce it. Never use a prompt or JSON field as the only security boundary.

Architecture Ownership Remains Human

Engineers still define the contract, decide which behavior is intentional, and accept the tradeoffs. The packet makes that work explicit and reusable.

Conclusion

The value of a context packet lies in helping an agent distinguish governing rules from code that happens to be nearby.

AI-assisted development becomes more reliable when context is designed and maintained as part of the engineering system.

AI Is Changing What 'Correct Software' Means

Majdi Zlitni — Sat, 22 Aug 2026 16:41:58 +0000

Software engineers used to define a "Correct software" via a simple deterministic binary an Expected Output.
All Test are passed, but this is collapsing, a green CI pipeline no longer guarantees correct software, with AI-generated code that's look syntactically perfect and test-compliant yet they are semantically wrong in a ways that appears in productions.
The bottleneck in software engineering is no longer writing code, it is verifying it execution intent

The Determinism Illusion
Why Unit Tests Fail to Catch AI Era Bugs
The Architecture Shift: From Test Suites to Verification Engines
Practical Implementation Invariant Verification in Dot NET and Azure
Tradeoffs and Structural Limitations
Conclusion

The Determinism Illusion

Traditional software used to relies on deterministic assertions. We write code with known paths, control inputs, and verify exact results:

[Fact]
public void CalculateDiscount_StandardUser_ReturnsTenPercent()
{
    var calculator = new DiscountCalculator();
    var result = calculator.GetDiscount(UserType.Standard, orderTotal: 100);
    Assert.Equal(10, result);
}

This works well because we write the logics and most bugs comes from missed edge cases or small mistakes.
But with AI-generated codes, it follows a patterns based on trained context and user prompt. An agent will write code that pass 100% of our unit tests but silently violation non-functional, implicit system boundaries:

It Adds hidden performance costs.
It breaks state machine idempotency under concurrent execution.
It bypasses domain entity validation rules by instantiating raw records directly.

So we got a syntactically valid and test passing code but architecturally incorrect.

Why Unit Tests Fail to Catch AI Era Bugs

AI agents are exceptionally good at writing tests for the very code they just generated. If an agent writes a flawed implementation, it generates an equally flawed, matching assertion suite.

When tests mirror the assumptions of the generation engine, unit tests become a confirmation bias machine.

To govern AI-generated code, we must shift our definition of correctness from Output Equality (Assert.Equal) to System Invariants (Constraint Validation at Execution Runtime).

The Architecture Shift: From Test Suites to Verification Engines

In an AI-native engineering workflow, correctness is defined by bounded runtime guardrails and architectural fitness functions.
Instead of testing whether a function returned 10, a verification engine continuously enforces structural constraints across the entire codebase execution model.
Using this we are not just checking test results we are enforcing rules at runtime and checking that the system design stays valid.

Practical Implementation Invariant Verification in Dot NET and Azure

Let's build a practical implementation of an architectural verification pipeline.

Step 1: Enforce System Invariants in the Architecture Pipeline

Instead of trusting AI-generated tests we will enforce rules that our system must always follow:

Before merge (CI) → check code structure
At runtime → check what the AI is trying to do

using NetArchTest.Rules;
using Xunit;

public class ArchitectureVerificationTests
{
    [Fact]
    public void DomainEntities_MustBeImmutable_AndNeverBypassedByAgents()
    {
        // Enforce that AI-generated code cannot introduce mutable state into the Core Domain
        var result = Types.InCurrentDomain()
            .That()
            .ResideInNamespace("OrderSystem.Domain")
            .Should()
            .BeImmutable()
            .GetResult();

        Assert.True(result.IsSuccessful, "AI generated mutable entities in the domain layer!");
    }

    [Fact]
    public void Handlers_MustEnforceIdempotencyDecorator()
    {
        // Ensure every generated Command Handler implements IIdempotentCommand
        var result = Types.InCurrentDomain()
            .That()
            .HaveNameEndingWith("CommandHandler")
            .Should()
            .ImplementInterface(typeof(IIdempotentCommand))
            .GetResult();

        Assert.True(result.IsSuccessful, "AI generated a command handler lacking explicit idempotency execution!");
    }
}

Step 2: Runtime Semantic Guardrail Verification Engine

For AI agent workflows running in production or ambient background tasks when it tries to change code or data, we validate its intent before allowing it so we ensure:

No direct DB access outside repositories
No performance-heavy allocations
Every external change must trigger an event

using Microsoft.SemanticKernel;
using Microsoft.Extensions.Logging;

public record ExecutionIntent(string TaskDescription, string TargetNamespace, string ProposedDiff);
public record VerificationResult(bool IsValid, string StructuralDivergenceReason);

public class AgentVerificationEngine
{
    private readonly Kernel _kernel;
    private readonly ILogger<AgentVerificationEngine> _logger;

    public AgentVerificationEngine(Kernel kernel, ILogger<AgentVerificationEngine> logger)
    {
        _kernel = kernel;
        _logger = logger;
    }

    public async Task<VerificationResult> VerifyAgentActionAsync(ExecutionIntent intent)
    {
        // Define hard system invariants that the LLM engine cannot negotiate
        var verificationPrompt = """
            You are an Architectural Verification Engine. Evaluate the proposed code change against the system invariants:

            SYSTEM INVARIANTS:
            1. No direct database access outside Infrastructure/Repositories.
            2. Memory allocations on critical paths must avoid heap overhead (no boxing, use ReadOnlySpan<T> where applicable).
            3. All external state modifications MUST emit an IntegrationEvent.

            PROPOSED CHANGE:
            Target: {{$target}}
            Diff: {{$diff}}

            Respond ONLY in JSON format:
            {"is_valid": true|false, "reason": "Detailed failure justification"}
            """;

        var arguments = new KernelArguments
        {
            ["target"] = intent.TargetNamespace,
            ["diff"] = intent.ProposedDiff
        };

        var result = await _kernel.InvokePromptAsync(verificationPrompt, arguments);
        var responseJson = result.GetValue<string>();

        // System parses verification evaluation deterministically
        return System.Text.Json.JsonSerializer.Deserialize<VerificationResult>(responseJson)!;
    }
}

Azure Deployment Architecture

Deploy this verification process directly inside your Azure DevOps Pipeline or GitHub Actions Engine alongside Azure Container Apps for isolation:

Tradeoffs and Structural Limitations

Moving to an invariant-driven verification architecture introduces real engineering trade-offs:

Increased CI Execution Latency: Evaluating structural ASTs and executing dynamic LLM-driven verification gates adds 30–90 seconds per pull request compared to simple syntax compilation.
High Upfront Modeling Cost: Defining system invariants requires deep domain expertise. You cannot ask an AI to write your system invariants — doing so reintroduces the confirmation bias loop.
Over-Constrained Evolution: Overly strict architectural fitness functions can cause false positives, blocking valid edge-case refactoring tasks generated by agents or human engineers.

Conclusion

AI is not removing the need for software engineering — it is raising the level of abstraction.

When writing code becomes frictionless, the primary value of a senior engineer shifts from syntax authoring to system boundary definition. Stop relying solely on traditional unit tests to validate AI-generated code. Build verification engines that enforce immutable architecture invariants, audit non-deterministic outputs, and protect runtime stability.

Software correctness is no longer about passing unit tests. It is about proving your system cannot violate its core invariants.

How are you adapting your CI/CD pipelines to handle AI-generated code? Are you relying on static unit testing, or building verification boundaries? Drop your thoughts in the comments below!

Vibium Under the Hood

Majdi Zlitni — Sat, 25 Jul 2026 20:02:58 +0000

My previous blog in my automation series was a first step on how to:

Install Vibium
Record a login scenario
Visualize recorded test

Refreshing, Vibium is an open source automation tool, written in Go with JS/TS, Python, and Java client libraries.

In this blog post, we will go through:

The Protocol Bet: Why WebDriver BiDi
System Architecture
Daemon Mode
Using Vibium MCP and SKILLs
Reliability vs Speed with AI Agents
Closing

The Protocol Bet: Why WebDriver BiDi

Vibium's design isn't a CLI choice, it's the protocol used underneath.

Browser automation has gone through three protocol generations:

WebDriver (2004–present): Selenium’s foundation. Uses HTTP + JSON with a request/response model that controls browsers in a one-way manner: the browser only responds when asked.

Chrome DevTools Protocol (2017–present): CDP swapped HTTP for WebSockets, and that unlocked bidirectional communication: the browser sends and receives events in real time like logs, network activity, and DOM changes. Puppeteer and Playwright are both built on CDP, but it is Chrome-internal.

WebDriver BiDi (2021–present): The W3C's answer to "what if we kept CDP's bidirectional WebSocket model but made it an actual cross-vendor standard?".

And that's the main reason I think Vibium is built directly on WebDriver BiDi.

Below is the diagram presenting these interactions:

Here our browser can push events, like messages, and when a page throws an error, WebDriver BiDi can receive them.

Browser support is still maturing with:

Chrome/Chromium supports BiDi via ChromeDriver
Firefox has native support
Edge inherits Chromium's support
Safari's support is in development

The tooling ecosystem is converging on this protocol, not just Vibium.

System Architecture

Vibium ships as a single compiled binary. This indicates that:

You can invoke it directly from the CLI.
You can use the MCP server and register it with an agent host.

Both surfaces funnel into the same internal command engine, which talks to Chrome over a BiDi WebSocket connection it manages internally.

Both methods target the Vibium binary, which interacts with Chrome using WebDriver BiDi over WebSocket.

Two details worth calling out:

Vibium uses the same core engine for CLI commands, MCP tools, and language clients. Client libraries connect to the binary through WebSocket instead of rebuilding browser automation logic.
Vibium can be installed as an agent skill via
npx skills add https://github.com/VibiumDev/vibium --skill vibe-check
allowing AI coding agents to discover and use it through a SKILL.md definition and automatically resolve the required binary.

Daemon Mode

Daemon mode improves performance. Instead of starting a new browser for every command, it keeps a background browser alive and reuses it across all commands.

vibium go https://example.com
vibium map
vibium click @e1

So the browser starts once, keeping agent workflows faster. The daemon can also be manually controlled with start, status, and stop commands, which is useful for CI environments.

Using Vibium MCP and SKILLs

Before moving on to the AI integration with Vibium I wanted to clarify the difference between MCP and Skills because there is slight confusion

MCP (Model Context Protocol) is the runtime used by agents to execute tools. It controls the communication between agents and binaries.

SKILL.md is definition on how to do things it is a file that describes a tool used by MCP so MCP reads SKILL.md to know how to expose and invoke the skill.

In short: MCP execute using skills, and a skill tells MCP how execute.

To use a skill defined via SKILL.md, you first need to register it:

npx skills add https://github.com/VibiumDev/vibium --skill vibe-check

Once added, I used the vibe-check skill to automate a simple scenario.
I use this prompt within GitHub Copilot in agent mode

use the vibe-Check skill to open https://opensource-demo.orangehrmlive.com/web/index.php/auth/login
and login using:
Username: Admin
Password: admin123

Reliability vs Speed with AI Agents

Using Vibium with AI is very interesting but this comes with a balance between speed and reliability.

At first glance it seems very fast and smart, it understands what the user wants using simple words and execute actions based on that.
But in practical things can get messy

It true that AI can know the UI elements with a faster setup but as you can seen a simple login flow still struggles, the agent got stuck and couldn't identify the element from the first attempts.
The interesting part is how it behaves using a quickly recover,
it true that it gives more adaptability but also a less deterministic behavior.

Closing

Betting on WebDriver BiDi aligns with a cross-vendor standard for browser automation. Vibium is moving toward a full AI-driven system built on three layers:

Sense (Retina): Browser-level observation via a Chrome extension
Think (Cortex): Memory, reasoning, and navigation planning
Act (Vibium): Execution using BiDi

Vibium is early, maturing these layers could move browser automation from "sometimes works" to production-ready.

Explore the CLI reference, BiDi explainer, and roadmap in the repo to dig deeper.

What’s your biggest bottleneck with browser automation today? Drop your thoughts or check out the repo to start experimenting!

Vibium: A CLI Browser Automation Tool

Majdi Zlitni — Fri, 24 Jul 2026 07:00:00 +0000

Browser automation has been dominated by tools like Selenium and Playwright. They're very powerful, but you need to understand the DOM, manage selectors, and set up a testing stack before doing anything meaningful.

Vibium takes a different approach, by using a step-based commands.

Open a website
Find an element
Fill a field
Click a button
Validate the result

Vibium supports two ways for agentic usage:
A command-style skill used for browser automation, and an MCP server for structured workflows. For element discovery, vibium find uses semantic signals like text, labels, placeholders, test IDs, CSS, XPath, and the accessibility tree, then returns stable references that can be reused until the page changes.

Why Vibium?
Installing Vibium
Your First Vibium Automation
Understanding the Core Commands
Recording
Viewing the Trace
Where Vibium Fits
Vibium vs. Selenium vs. Playwright
Final Thoughts

Why Vibium?

Traditional automation usually follows a familiar path:

Find the CSS selector
Inspect the DOM
Set up a framework
Write the code
Maintain the selectors as the app changes

In Playwright, that ends up looking like this:

await page.Locator("#username").FillAsync("Admin");

Nothing wrong with that it works, and it's the standard for a reason. But it requires you to already know the DOM structure before you write a single line.

Vibium flips the workflow around. Instead of hunting for selectors first, you discover elements interactively and reference them as you go:

vibium fill "@e1" "Admin"

Vibium finds the element for you and hands back a temporary reference (@e1) that you can immediately act on.

Installing Vibium

Install the CLI globally with npm:

npm install -g vibium

The first browser-based command you run will automatically download a managed Chrome for Testing build, so there's no separate browser setup step.

Verify everything works:

vibium go https://example.com

A browser will open with the given URL

Your First Vibium Automation

Let's automate a simple login flow against the OrangeHRM demo site.

The plan:

Start recording
Open OrangeHRM
Find the username field and enter a value
Find the password field and enter a value
Click the login button
Stop recording and save the trace

Using Vibium map to scans the current page for interactive elements.

Here a line by line PowerShell script:

vibium record start

vibium go "https://opensource-demo.orangehrmlive.com"

vibium map

vibium fill "@e1" "Admin"

vibium fill "@e2" "admin123"

vibium click "@e3"

vibium record stop

That's a full, working login automation in about ten lines no selector hunting, no test framework scaffolding.

Understanding the Core Commands

Start recording

vibium record start

Open URL

vibium go "https://example.com"

Find element

vibium find placeholder "Username"

Fill input

vibium fill "@e1" "Admin"

Find and click button

vibium find role button
vibium click "@e3"

Recording

This is the one distinction worth internalizing before you build anything real with Vibium.

Recording mode is great for exploring a workflow, and sketching out an automation quickly.

Viewing the Trace

After you stop recording:

vibium record stop

Vibium writes out a record.zip trace file. Open it with the Playwright Trace Viewer:

npm install -g playwright
playwright show-trace record.zip

From there you can step through screenshots, actions, timing, failures, and browser state for the whole session handy for debugging a flaky step after the fact.

Where Vibium Fits

AI agents. Vibium's command surface maps naturally onto the kind of steps an LLM already reasons in "open the site, find the login field, enter credentials, click submit, verify the result" which makes it noticeably easier for an agent to generate a working automation than raw locator-based code.

Test automation. Regression suites, smoke tests, end-to-end tests, and user-journey validation (login → create user → update profile → logout, for example) all map cleanly onto Vibium's step-based style.

Internal automation. Repetitive browser work data entry, admin dashboards, report pulling, back-office workflows is often not worth building a full test framework for. Vibium's low ceremony makes it a reasonable fit for these one-off or lightly-maintained scripts.

Vibium vs. Selenium vs. Playwright

Selenium and Playwright still win on ecosystem maturity, plugin support, and battle-tested reliability at scale. Vibium's edge is in how quickly you can go from "I want to automate this" to a working script.

Final Thoughts

Vibium lowers the barrier to entry for browser automation, especially for AI-driven workflows. But it does so by shifting responsibility from the developer to the tool.

If you're a developer, a QA engineer, or you're building AI agents that need to act on the web, Vibium is worth a look.

What Actually Enforces Code Standards in the AI Era

Majdi Zlitni — Sat, 18 Jul 2026 15:21:09 +0000

If your team has ever spent 20 minutes on a pull request arguing about brace placement instead of the actual bug, welcome to the club.

StyleCop was the tool to keep C# codebases from turning into everyone's personal-style soup. It did its job. But it's also old, slow, and wasn't built for a world where half your codebase might be vibe coded.

The good news: .NET now ships with everything you need to enforce style natively, faster, and without an extra NuGet package. This post walks through why the old approach creaks under modern workloads, and gives you a copy-pasteable migration plan to fix it.

The Real Cost of Style Debates
Quick Refresher: What Is StyleCop?
Do We Even Need Linters Now That AI Writes Code?
The Problem With StyleCop: It's Slow
The Modern Toolbox
The 3 Layer Guardrail Strategy
Step by Step Migration Guide
Before and After Seeing It In Action
Key Takeaways
Wrapping Up

The Real Cost of Style Debates

Nobody has ever gotten a promotion for winning a tabs-vs-spaces argument. Yet these debates eat real time:

PR bikeshedding,reviewers nitpick spacing instead of catching actual logic bugs.
Noisy git diffs,one developer's auto-formatter touches 300 lines to fix a 3-line bug.
Cognitive overhead,jumping between services that each "feel" different slows everyone down.

A linter's whole job is to make these arguments boring and automatic, so humans can focus on things that actually matter,like whether the code works.

Quick Refresher: What Is StyleCop?

StyleCop (and its Roslyn-based version, StyleCop.Analyzers) is a static analysis tool that checks the visual grammar of your C# code,not bugs, not security holes, just style:

Are public members documented?
Are namespaces organized consistently?
Do braces follow the "approved" pattern?

It's not checking if your code is correct. It's checking if your code looks correct.

Do We Even Need Linters Now That AI Writes Code?

Short answer: yes, more than ever.

AI coding assistants (Copilot, Cursor, and friends) are great at logic, but they have zero awareness of your team's conventions. They're trained on millions of repos with wildly different styles, so pasted-in AI code tends to bring some chaos with it:

Paradigm mixing,old-school patterns sitting right next to brand-new C# syntax in the same file.
Random formatting,inconsistent spacing and bracing, because the model has no idea what your team prefers.
Comment bloat,giant XML doc comments explaining that GetName() "gets the name."

💡 Tip: Think of AI-generated code like a very talented intern who's never seen your style guide. Brilliant ideas, questionable formatting. It needs a quick pass before it joins the team.

The Problem With StyleCop: It's Slow

Here's the part that actually hurts: StyleCop.Analyzers walks the compiler's entire Abstract Syntax Tree (AST) every time you build locally. On a large, modern codebase, that adds real, measurable time to every single compile.

Your Code → Hit Build → Roslyn AST + Heavy StyleCop Analysis → Slow Build

And it gets worse: hundreds of style rules are configured as Warnings, so your build output turns into a wall of noise. Real errors get buried underneath "add a blank line here" messages. That's not code quality,that's warning fatigue.

The Modern Toolbox

Microsoft baked style enforcement directly into the .NET SDK, so you don't need a heavyweight third-party package anymore. Here are your main options:

1. Native .editorconfig (the real successor to StyleCop)
Define your rules in a plain text file. The .NET SDK reads it instantly and surfaces issues as built-in compiler diagnostics. No extra packages.

2. CSharpier
An opinionated formatter, like Prettier for C#. It skips debates entirely,one deterministic output, no configuration arguments. Runs outside the compiler, so it doesn't touch build performance.

3. SonarQube / SonarCloud
For the deep stuff,security holes, memory leaks, async anti-patterns,push that to a cloud-based SAST engine instead of your local build. Keep local checks fast and lightweight; let the cloud do the heavy lifting asynchronously.

Tool	Good for	Runs where
`.editorconfig` + SDK analyzers	Style, naming, layout	Local build (fast)
CSharpier	Deterministic formatting	Out-of-process
SonarQube/Cloud	Security & deep quality checks	CI / cloud (async)

The 3 Layer Guardrail Strategy

The trick to using AI tools without letting them wreck your codebase is a simple pipeline: Seed → Ground → Enforce.

1. SEED                 2. GROUND              3. ENFORCE
AI Instruction File  →  IDE Format on Save  →  CI Gate
(AGENTS.md)             (.editorconfig)        (dotnet format)

Seed: Tell the AI your conventions upfront, before it generates a single line.
Ground: Let your IDE auto-fix formatting the moment code is pasted or saved.
Enforce: Fail the build in CI if anything slipped through ungrounded.

Three checkpoints. Nothing style-broken survives all three.

Step by Step Migration Guide

Here's the hands-on plan to move off StyleCop and onto native tooling.

Step 1: Set Project-Wide Standards

Create a Directory.Build.props file at the root of your repo (next to your .sln):

<Project>
  <PropertyGroup>
    <!-- Turn on the SDK's built-in Roslyn analyzers -->
    <EnableNETAnalyzers>true</EnableNETAnalyzers>
    <AnalysisLevel>latest</AnalysisLevel>
    <AnalysisMode>Recommended</AnalysisMode>

    <!-- Make the build actually respect .editorconfig -->
    <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
  </PropertyGroup>
</Project>

This applies the same rules across every project in the solution, no more "well, my microservice does it differently."

Step 2: Generate Your `.editorconfig`

dotnet new editorconfig

Then customize it. Here's a solid starting template:

root = true

[*.cs]
# Indentation & layout
indent_style = space
indent_size = 4
end_of_line = lf
insert_final_newline = true

# Modern C# preferences
csharp_style_file_scoped_namespaces = true:error

# Explicit rule mappings (these replace old StyleCop rules)
dotnet_diagnostic.IDE0005.severity = warning   # remove unused usings
dotnet_diagnostic.IDE0040.severity = warning   # require explicit access modifiers
dotnet_diagnostic.IDE0055.severity = warning   # flag whitespace/brace issues

Step 3: Give Your AI Tools the Memo

Drop a AGENTS.md file in your repo root so AI assistants know the rules before they start typing:

# C# Code Generation Rules
- All generated code must follow the root `.editorconfig`.
- Use file-scoped namespaces only.
- Keep classes tightly encapsulated; prefer primary constructors.
- Skip self-explanatory XML doc comments on basic properties.

This is the "Seed" layer from earlier; cheap insurance against a lot of cleanup later.

Step 4: Automate Formatting Locally

In your IDE (Visual Studio, VS Code, Rider,doesn't matter which), turn on:

Format on Save
Format on Paste

This is what actually "grounds" AI-pasted code into your team's style, automatically, with zero manual effort.

Need to clean up an entire existing codebase in one go?

dotnet format

Step 5: Add a CI Gate

Add this to your pipeline (GitHub Actions, Azure DevOps, whatever you use) before the build step:

- name: Verify Code Style & Layout Compliance
  run: dotnet format --verify-no-changes --verbosity normal

- name: Execute Production Build
  run: dotnet build --configuration Release

If anyone bypasses their IDE formatting (we all know someone), the pipeline catches it before it merges.

Before and After Seeing It In Action

Before: technically compiles, but it's a mess:

// InconsistentOrderProcessingService.cs
using MyApp.Core;
   using System;

namespace MyApp.Services{
public class orderService
{
      private readonly IRepository _repo;

    public orderService(IRepository repo)
    {_repo=repo;}

      public void processOrder(int id){
            var order = _repo.Get(id);
      if(order==null) throw new Exception("Order context is missing.");
        // Business execution path...
   }
}
    }

After,run dotnet format, and this is what comes out the other side:

// OrderProcessingService.cs
using System;
using MyApp.Core;

namespace MyApp.Services;

public class OrderProcessingService
{
    private readonly IRepository _repository;

    public OrderProcessingService(IRepository repository)
    {
        _repository = repository ?? throw new ArgumentNullException(nameof(repository));
    }

    public void ProcessOrder(int orderId)
    {
        var order = _repository.Get(orderId);
        if (order == null)
        {
            throw new InvalidOperationException($"Order with ID {orderId} was not found.");
        }

        // Business execution path...
    }
}

Same logic. Zero manual cleanup. Nobody had to open a PR comment thread about it.

Key Takeaways

StyleCop is slow because it walks the full AST on every local build; that adds up fast on large codebases.
AI-generated code needs grounding, not banning. Seed it with conventions, then auto-format on save.
.editorconfig + SDK analyzers replace most of what StyleCop did, natively, and faster.
CI should verify, not fix. Use dotnet format --verify-no-changes as a gate, not a cleanup crew.
Split concerns: style stays local and fast; deep security/quality checks (SonarQube) move to CI/cloud.

Ready to use template

Reading about code standards is easy. Applying them consistently across a team is the hard part.

To make this process easier, I created a ready-to-use .NET code governance template that packages the approach described in this article
👉 DotStyle .NET Code Governance Template

Wrapping Up

Moving off StyleCop isn't about lowering your standards, it's about enforcing them somewhere that doesn't slow you down. Seed your AI tools with clear rules, let your IDE ground the output automatically, and use CI as the final backstop. Fast local builds, clean diffs, and PR reviews that actually talk about the code instead of the commas.

Give it a try on one repo this week, use a proper .editorconfig, wire up dotnet format in CI, and see how much quieter your next pull request review is.

Have a different setup that works for your team? something else entirely? Drop it in the comments 👇

Bypassing the Parser: Connecting Azure AI Foundry to VS Code Copilot via BYOK

Majdi Zlitni — Wed, 17 Jun 2026 09:51:35 +0000

The vibe coding era just took a massive hit.

As of June 1, 2026, GitHub completely dismantled its old request-based model for Copilot and transitioned to a strict Usage-Based Billing Model powered by GitHub AI Credits.

For developers riding on the GitHub Copilot Student plan, the reality is harsh: while basic inline code completions remain unlimited, Copilot Chat and agentic features are now heavily restricted. To make matters worse, top-tier reasoning models have been completely stripped from the Student tier self-selection menu to keep the free tier sustainable.

But if you are a student with an Azure for Students subscription, you hold a massive golden ticket in your hands: Free Azure cloud credits.

By using the Bring Your Own Key (BYOK) feature inside VS Code, you can deploy cutting-edge coding models on your own Azure instance and route them straight into your IDE, falling into three distinct tiers:

Cloud-Hosted Enterprise Models (Azure AI Foundry & OpenAI)
External Third-Party API Gateways (DeepSeek, OpenRouter & Anthropic)
Fully Offline Local Models (Ollama, vLLM & Foundry Local)

While BYOK supports everything from local Ollama instances to third-party gateways, this guide will focus specifically on Azure subscription credits using Azure AI Foundry.

Here is how to trick the system, bypass the budget limits, and build your own autonomous development environment.

Prerequisites: Snagging Your Azure Student Subscription
vs code Configuration Blueprint
- Step 1: Open the Custom Models Panel
- Step 2: Input Your Azure Endpoint Details
- Step 3: Clear the IDE Cache Layers
The Result: Infinite Coding Freedom

Prerequisites: Snagging Your Azure Student Subscription

First you need a valid Azure subscription with active credits to host your models. If you don't have one yet, Microsoft offers a dedicated Azure for Students tier that gives you free cloud credits annually with no credit card required.

Scenario A: You Already Have an Active Azure subscription

Log into Azure AI Foundry and create a new Azure Foundry resource.
Create a new project under your subscription(student subscription if you have one). Select an optimal region for model availability (for my case I selected Sweden Central). Create your resource group.
Navigate to the Model Catalog and choose Explore Models.
Select your preferred available coding model.
Deploy it using the default settings, making note of the target model name (e.g.,for my case I used gpt-5.3-codex).
Copy your Endpoint URL and API Keys from the model deployment dashboard. Keep these secure we will need them for VS Code.

Scenario B: You Need to Create One

Head over to the official Azure for Students Portal, sign in using your academic university email address (.edu or your institutional domain), and verify your student status. Your cloud sandbox and free credit allotment will provision instantly.

vs code Configuration Blueprint

Instead of wrestling with native extension limitations, we are going to configure your connection as an open-standard, OpenAI-Compatible gateway, while preserving the specialized Responses API handling required by modern Azure Foundry endpoints.

Step 1: Open the Custom Models Panel

Launch VS Code.
Open your Copilot Chat panel on the sidebar.
Click on the model selection dropdown menu at the top or bottom of the chat interface.
Select "Other Models..." from the bottom of the list.

Step 2: Input Your Azure Endpoint Details

A new UI panel labeled "Adding custom endpoint" will appear. Populate the fields using the credentials you copied from your Azure AI Foundry dashboard:

Endpoint URL: Paste your Azure endpoint (ensure it targets the base /openai/v1 route).
API Key: Paste your secure Azure endpoint key.
Model ID: Match it to your deployment name (e.g., gpt-5.3-codex).

💡 Pro-Tip: Deep Tweaking via JSON

If you prefer fine-grained control or want to explicitly enforce parameters like context windows or vision support, you can open your user chatLanguageModels.json file via the Command Palette (Ctrl+Shift+P / Cmd+Shift+P -> Chat: Manage Language Models) and drop in this clean schema:

[
    {
        "name": "[Azure AI Foundry (BYOK)]",
        "vendor": "customendpoint",
        "apiKey": "${input:chat.lm.secret.YOUR_SECRET_ID}",
        "apiType": "responses",
        "models": [
            {
                "id": "gpt-5.3-codex",
                "name": "GPT-5.3 Codex (Foundry)",
                "url": "[https://***.services.ai.azure.com/openai/v1](https://***.services.ai.azure.com/openai/v1)",
                "toolCalling": true,
                "vision": true,
                "maxInputTokens": 128000,
                "maxOutputTokens": 4096
            }
        ]
    }
]

Step 3: Clear the IDE Cache Layers

To ensure VS Code registers the new custom endpoint layout:

Reload your window via the Command Palette (Developer: Reload Window).
Open your Copilot Chat panel.
Click the model dropdown selection menu. You should now see your deployed model available as a selectable model option!

The Result: Infinite Coding Freedom

Once your endpoint is active and your environment is refreshed, you are ready to build without constraints.

You have officially decoupled your IDE's intelligence layer from restrictive credit pools. By routing your Azure subscription credits straight into your workspace via a BYOK configuration, you gain full autonomy over your development ecosystem completely free of token caps or artificial feature tiers. Happy hacking!

I would love to get your feedback and insights on this.

Are you currently implementing BYOK setups or custom routing within your local teams and IDEs?
How are you balancing API performance and cost management across modern developer environments?

Stop Writing 'Fixed Bug': Git Day-to-Day with Conventional Commits

Majdi Zlitni — Fri, 15 May 2026 15:12:57 +0000

We’ve all been there. A critical bug is reported in production. You grab your coffee, crack your knuckles, and run 'git log' to trace when the issue was introduced. And what do you see?

7a3b4c9 fixed bug
1d9e2f4 updated config
9f8a7b6 wip
3c2d1e8 finally works pls

Tracking what actually happened turns into an archaeological dig. When hundreds of developers on a team all push commits with vague messages, your repository's history becomes a chaotic nightmare.

But there is a better way. Welcome to Conventional Commits.

What is a Conventional Commit?

A Conventional Commit provides a lightweight, standardized structure to your commit messages. By imposing a simple set of rules, commits become easily readable by both human developers and automated machines (like your CI/CD pipelines).

Think of it as turning your Git history from a messy journal into a structured database.

The Anatomy of a Perfect Commit

The standard format is simple but powerful:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Here is a real-world comparison:

❌ Bad Commit: 'fixed the token issue'

✅ Good Commit: 'fix(auth): resolve token parsing issue caused by expired JWT format'

Common Commit Types (Prefixes)

To keep things consistent, we use predefined prefixes:

feat: A new feature for the user or the API.
fix: A bug fix for the user or the API.
docs: Documentation-only changes (README, swagger, etc.).
style: Formatting, missing semi-colons, etc; no code change.
chore: Changes to the build process or auxiliary tools (e.g., updating dependencies).
refactor: A code change that neither fixes a bug nor adds a feature.
test: Adding missing tests or refactoring tests; no production code change.

💡 Pro Tip: Need to memorize these? Add a '.gitmessage' template to your project so every time you run 'git commit', the types are printed as comments in your editor!

🔄 Revamping Your Daily Git Workflow

Adopting Conventional Commits is more than just typing a prefix; it’s a mindset shift. Your daily workflow adjusts to prioritize clean, isolated history.

1. Branch Out

Always ensure you're starting on a clean, isolated branch from 'main'.
bash git checkout main git pull git checkout -b feature/user-profile

2. Make Isolated Changes

Pitfall: Don't group unrelated changes together. If you are fixing a UI bug and adding a new database field, those belong in separate commits, and possibly separate branches. Keep your commits atomic.

3. Commit Accurately

Use the prefixes rigorously! Be descriptive but concise.

git add src/components/UserProfile.tsx
git commit -m "feat(ui): add user profile dashboard component"

4. Rebase, Don't Merge (Usually)

When bringing your feature branch up to date with 'main', prefer rebasing over merging.

Merging ('git merge main') creates a "merge commit," tying two histories together. It's safe, but it makes the history look like a tangled web.
Rebasing ('git rebase main') plucks your commits and plays them on top of the latest 'main'. It creates a beautiful, perfectly linear history.

git fetch origin
# Rebase your current branch onto the latest main
git rebase origin/main
# Resolve any conflicts, then force push safely:
git push --force-with-lease

Why Go Through the Trouble?

Making your commits structured feels like extra typing at first. But the ROI is massive:

Instant Context for Reviewers: Your peers instantly understand the scope and intent of your Pull Request. 'chore(deps)' tells them this is a dependency update, while 'feat(checkout)' tells them to look for new business logic.
Automated Changelogs: Scripts can automatically parse 'feat' and 'fix' commits to generate pristine Release Notes instantly.
CI/CD Magic: Tools like Semantic Release rely wholly on these prefixes to automate versioning and deployments (which we cover in the next article!).

Conclusion & Next Steps

Switching to Conventional Commits transforms how your team interacts with the codebase. You stop guessing what a commit does and start treating your Git history as a source of truth.

Your Challenge for Today:
Try formatting your next 3 commits using the Conventional format. See how much cleaner your 'git log' looks!

In Part 2 of this series, we will take this to the next level. We'll show you how to leverage these structured commits to completely automate your application versioning using Semantic Release.

If you found this helpful, drop a ❤️ below! How does your team structure commit messages? Let me know in the comments!

Level Up Your Dev Setup: Get GitHub Copilot for Free with the Student Developer Pack

Majdi Zlitni — Wed, 22 Apr 2026 10:54:24 +0000

Hey coding wizards, open source heroes, and dedicated learners! Ever felt like the tools you need to build the next big thing are locked behind a paywall steeper than mount Everest? Or maybe you're just tired of writing boilerplate code manually while your wallet looks a bit thin?

Fear not! GitHub, in its infinite wisdom and generosity, has compiled the ultimate cheat code for students: the GitHub Student Developer Pack. But what exactly is it, how do you get your hands on it, and most importantly, how can you use it to access top-tier AI tools like GitHub Copilot? Let's dive in!

What is the Developer Pack?
How to Claim Your Pack: Step by Step
The Ultimate AI Workbench: VS Code and GitHub Copilot
Tips to Maximize Your Pack
Conclusion

What is the Developer Pack?

The GitHub Student Developer Pack provides students with free access valid for 2 years to premium developer tools, cloud hosting, domains, and learning platforms to kickstart your career.
After the 2-year period, you can reapply and renew your benefits

Who Qualifies?
Any currently enrolled student (high school, college, university, or verified bootcamps) aged 13+ with a verifiable school email address or proof of enrollment.

What's Included? You get a massive bundle of resources, including:

GitHub Ecosystem: Free GitHub Pro & GitHub Copilot. Includes 1 free certification voucher.
Microsoft Azure: $100 credit and 25+ free services for 1 year.
Cloud & Domains: $200 DigitalOcean credit. Grab a free .me (w/ SSL) from Namecheap, a .TECH domain, or choose from 25+ other extensions like .live and .dev.
Developer Tools: Full educational license for all JetBrains IDEs (IntelliJ, PyCharm, etc.), plus a Datadog Pro Account (10 servers for 2 years).
Learning & Interview Prep: 3 months of DataCamp, free Pluralsight training, 1 week of Interview cake, and 20 free questions + 10% off at AlgoExpert.
MongoDB Certification: Receive a 100% free certification voucher within 24 hours of completing any Learning Path on MongoDB University.
Productivity & Design: Free Notion Education plan (extra sharing & AI features), 2,000 SlideCoach AI presentation credits, and 60 Premium Icons monthly.
Business: Zero transaction fees on your first $1,000 in revenue via Stripe.
And many more!

How to Claim Your Pack: Step by Step

Getting access is straightforward, but the verification step requires a little attention to detail. Here is exactly how to get approved:

Step 1: Prep Your GitHub Profile
Ensure your GitHub profile name matches your student ID. If your account is named "DarkNinja99" with no real name attached, the automated system is going to be very suspicious. Use your real name!

Step 2: Confirm Your Payment Information
Go to your Payment Information settings and include your full name, last name, address, city, country, and zip code. Don't panic, they will not request a credit card! This is simply required as part of the verification process.

Step 3: Enable Two-Factor Authentication (2FA)
GitHub requires you to secure your account. Head over to your Security settings and enable 2FA via the setup page.

Step 4: Add Your School Email
Go to your GitHub account settings and add your school issued email address. Verify it. (A school verification email is required for the most efficient process).

Step 5:
Head over to education.github.com/pack, click "Sign up for Student Developer Pack". Select your role in education as "Student" ,and select this school email as an academic domain associated with your school/university.

Step 6: Application Submitted
Your application has been submitted successfully! If needed earlier in the process, you may have used your webcam to snap a picture of your Student ID or transcript.

Step 7: Wait for the Magic
Once you submit, the initial review process generally takes between 48 to 72 hours. Using a valid school-issued email address is the most effective way to speed up this phase. Welcome to the big leagues!

The Ultimate AI Workbench: VS Code and GitHub Copilot

One of the absolute best perks of the Student Pack is free access to GitHub Copilot Pro.

Having Copilot tightly integrated into your IDE feels exactly like having an endlessly patient, 10x senior engineer sitting right next to you, pair-programming. It doesn't just format your text; it understands your intent.

Before We Take Off (The Prerequisites):

VS Code 1.99+ (or version 1.116+ to have the magic built right in).
GitHub Copilot + Copilot Chat extensions installed (if you're running pre-v1.116).
An active GitHub Copilot subscription (which you just scored for free with your Student Pack!).
Make sure you are signed into your authenticated GitHub account.

Give It a Mission!

Here comes the fun part. Tell your agent what you want to accomplish (e.g., "Refactor the database connection logic in src/ to use the new connection pool pattern and ensure all tests pass").
Now sit back, sip your coffee, and watch it autonomously navigate files, write code, run tests, and fix errors!

With this setup, you're not just writing lines of code anymore you're architecting solutions while your AI pair-programmer handles the manual labor.

Tips to Maximize Your Pack

Don't Hoard, Use! The free cloud credits (like DigitalOcean and Azure) are a use-it-or-lose-it investment in your education. Deploy a portfolio site or spin up a backend server.
Snag a Free Domain: Pair your free domain from Namecheap or .tech with your hosting credits to deploy live, working projects. Recruiters love seeing live sites!
Turbocharge Your Learning: Use your free access to platforms like Educative or Frontend Masters to dive deep into modern frameworks and algorithms.
Secure Your Secrets: Get comfortable with tools like 1Password (included in the pack) from day one. Good security habits start early!

Conclusion

The GitHub Student Developer Pack is more than just free software; it's a massive sandbox for your coding career. By leveraging tools like VS Code and GitHub Copilot, you can learn faster, build bigger, and code smarter.

Stop writing code that only lives on your laptop. Claim your pack, build something real, and launch it to the world!

Got questions about getting set up? Drop them in the comments below! Happy coding!

DEV Community: Majdi Zlitni

Playwright Agents The Architecture of Self-Healing

TL;DR

Table of Contents

The problem with E2E testing today

1. The agentic testing triad

Why MCP matters here

🎭 Planner the strategic test architect

🎭 Generator live-validated code synthesis

🎭 Healer autonomous runtime self-repair

3. Setting it up

Prerequisites

Initialize the agents

Resulting project structure

4. Walkthrough: a movies catalog feature

Step 1 write a deterministic seed fixture

Step 2 plan the feature with the Planner

Step 3 generate the executable test

Step 4 let the Healer fix what breaks

5. Is it worth it for an enterprise suite?

The ROI case

Governance and security, non-negotiable

Where it still needs a human

Wrapping up

Agent Skills and how to use them

Table of Contents

Agent Skills Overview

Why Agent Skills?

How Do Agent Skills Work?

Start from real expertise

Project skills vs personal skills

How Copilot uses agent skills

Creating and adding a skill

Example SKILL.md file

Triggering a skill in VS Code

Option 1: Natural language

Option 2: Slash command

SKILL.md structure

Skills vs custom instructions

10 EF Core Performance Mistakes That Ship to Production

In this post

What counts as a performance mistake?

How to detect issues quickly

The anti-pattern map

TL;DR

1) N+1 Queries

Problem

Smell

Fix

2) Missing AsNoTracking

Problem

Fix

3) Loading Whole Entities

Problem

Fix

4) No Pagination

Problem

Fix

5) Client-Side Evaluation

Problem

Fix

6) Tracking Read-Only Data

Problem

Fix

7) Cartesian Explosion

Problem

Fix

8) No Compiled Queries

Problem

Fix

9) Missing Indexes

Problem

Fix

10) SaveChanges in a Loop

Problem

Fix

Batch operations caveat: ExecuteUpdate and ExecuteDelete

Decision matrix: what to fix first

What EF Core 10 helps with

Troubleshooting checklist