Why AI Results Improve Over Time, Not Model Learning

Executive Summary

• The phenomenon: AI code generation tools, including the Infragistics Ignite UI CLI MCP server, produce increasingly accurate output on experienced developer machines – not because the underlying model’s weights have changed, but because the surrounding system has accumulated context.
• Root cause: Several layers of the AI development stack accumulate or persist contextual state locally: Agent Skills files, project code, IDE retrieval systems, conversation history, and other workspace-level configuration and tooling.
• Stack involved: Ignite UI CLI MCP server, Ignite UI Theming MCP server, Agent Skills, and the IDE workspace context layer.
• Risk for developers building AI products: The practical consequence is simple: the AI environment on a developer’s machine may become progressively more capable than the environment a first-time user experiences, even when both use the same model. Teams that do not measure against a context-free baseline will overestimate how consistent their product is for first-time users.
• Upside for clients using AI tools: Context accumulation aligns the system with team workflows and domain patterns over time – AI-assisted development quality improves naturally without waiting for a model update.
• Action: Use the clean-room test procedure described in this post to establish a reproducible, context-free baseline and measure what the model alone produces.

---

Figure 1: The layers of the local development environment where AI context accumulates – none of them are the model.

---

The Problem: A Bug That Stopped Reproducing

Every senior engineer knows the dread of a non-deterministic bug. But AI coding assistants have introduced a new, far more insidious failure mode: the bug that fixes itself.

Consider a routine debugging loop using the Ignite UI CLI MCP server. An AI agent generates an Ignite UI navbar component, but the positioning of elements inside is wrong. The troubleshooting workflow is pure muscle memory:

1. Reproduce the issue.
2. Fix the MCP provided template definition.
3. Generate again and verify the issue is no longer reproducible.
4. Revert the fix to confirm the original issue is reproducible without the change in place.

At step 4, the bug no longer reproduces… You spin up a fresh AI session. Same prompt. Same model. Same component library. The generated output is consistently correct, yet no explicit change remains in place. The natural assumption is: “The model learned from my fix.” In a standard AI coding workflow, that explanation is highly unlikely. The model weights used during inference do not change in response to edits or fixes made in a local workspace. A more plausible explanation is that some part of the surrounding system changed the context available to the agent.

While the exact source of the accumulated context cannot always be identified with certainty, modern AI development environments contain multiple persistence layers that can influence future generations without any change to the underlying model. The sections below identify exactly where that context can live.

Where Context and “Experience” Can Physically Live

That accumulated context is not stored in one place. Depending on the IDE, agent implementation, and AI tooling, conversation history, semantic indexes, retrieval caches, embeddings, workspace metadata, and agent state may be distributed across several layers of the local development environment.

IDE Workspace and Extension Storage

Many AI-enabled IDEs maintain local storage areas for extension state, chat history, workspace metadata, semantic indexes, and retrieval-related artifacts. These locations are common inspection points rather than guaranteed storage locations. IDE vendors and extensions frequently change where and how they persist context.

VS Code

Windows:

%APPDATA%\Code\User\globalStorage\
%APPDATA%\Code\User\workspaceStorage\

macOS:

~/Library/Application Support/Code/User/globalStorage/
~/Library/Application Support/Code/User/workspaceStorage/

Linux:

~/.config/Code/User/globalStorage/
~/.config/Code/User/workspaceStorage/

VS Code Insiders

Windows:

%APPDATA%\Code - Insiders\User\globalStorage\

macOS:

~/Library/Application Support/Code - Insiders/User/globalStorage/

Linux:

~/.config/Code - Insiders/User/globalStorage/

Cursor

Windows:

%APPDATA%\Cursor\User\

macOS:

~/Library/Application Support/Cursor/User/

Linux:

~/.config/Cursor/User/

Windsurf

Windows:

%APPDATA%\Windsurf\User\

macOS:

~/Library/Application Support/Windsurf/User/

Linux:

~/.config/Windsurf/User/

Project-Level AI Artifacts

In addition to IDE storage, AI tooling frequently creates project-scoped directories that persist contextual information between sessions:

.agents/
.cursor/
.claude/
.continue/
.vscode/
.cache/
embeddings/
vector-store/
chroma/
qdrant/
faiss/

Depending on the tooling stack, these locations may contain:

• Agent Skills
• semantic indexes
• vector embeddings
• retrieval caches
• generated examples
• workspace fingerprints
• session metadata
• prompt history
• MCP configuration

Runtime and MCP State

Not all context is stored on disk.

AI agents and MCP servers may also maintain temporary state in:

• RAM
• long-running Node.js processes
• Python processes
• SQLite databases (*.db, *.sqlite)
• Redis instances
• JSON cache files
• vector databases

This is one reason why simply creating a new project folder does not always reproduce a clean client environment. Context can survive outside the workspace itself through extension storage, semantic indexes, cached embeddings, retrieval artifacts, or active MCP processes.

These are the general-purpose layers any AI-enabled development environment may use. The Infragistics AI-native stack adds its own structured, intentional context layers on top of these – which is where the accumulation pattern becomes both useful and worth measuring.

The Infragistics AI-Native Stack: Where Context Accumulates

Modern AI code generation systems are not single-model pipelines. The Infragistics AI-native development workflow consists of multiple layers, each with distinct responsibilities. Several of these layers accumulate or persist contextual state on the developer machine. Understanding which layers hold state – and which do not – is the foundation for diagnosing and controlling AI output consistency.

Agent Skills

Role	Persistent, developer-owned instruction packages that define correct Ignite UI component usage for a specific project.
Input	Developer prompts and agent task context, augmented by Skill file contents read from disk each session.
Output	Grounded component selection, correct import paths, and framework-native usage patterns.
Risk Reduced	Agent reaching for the wrong component, using outdated API signatures, or generating deprecated import paths.

Agent Skills are the most explicit form of context accumulation in the Infragistics stack. Skill files ship inside the Ignite UI package under node_modules/igniteui-{framework}/skills/ and are copied to the agent’s local discovery paths – .agents/skills/, .cursor/rules/, .claude/skills/ – when npx igniteui-cli ai-config is run. These files persist on disk across every session. Every AI coding session in that project has access to the same accumulated Skill context unless the files are explicitly removed or replaced. When a developer edits a Skill file to encode a project convention or a correct usage pattern discovered through debugging, that edit becomes part of every future generation in that workspace. This is not a side effect – it is the intended mechanism.

Ignite UI CLI MCP Server

Role	Documentation and component knowledge layer, exposing Ignite UI component APIs, getting-started guides, and usage best practices as structured tool calls.
Input	Agent or LLM query about Ignite UI component usage, documentation, or project scaffolding.
Output	Getting-started documentation, component lists with descriptions, verified usage best practices, and code examples aligned to the installed library version.
Risk Reduced	Agent generating hallucinated component APIs or referencing documentation from the wrong library version.

The Ignite UI CLI MCP server does not generate code autonomously – it exposes tools to the AI agent, which invokes them in response to developer prompts. The server starts fresh on every session via npx -y igniteui-cli mcp and does not maintain persistent state between sessions. However, the patterns the MCP-grounded agent generates and the developer commits to the project become part of the codebase. The IDE then indexes that codebase, and future generation sessions can retrieve those committed patterns as retrieval context. The MCP session itself is stateless; the downstream codebase it helps produce is not.

Ignite UI Theming MCP Server

Role	Design token and theming constraint layer, exposing validated theming instructions and design-system-aligned token values as structured tool calls.
Input	Agent or LLM theming intent or design token query.
Output	Theming Engine-aligned theming instructions.
Risk Reduced	CSS drift, invalid design token references, and design system divergence in agent-generated styles.

Like the CLI MCP server, the Ignite UI Theming MCP server starts stateless via npx -y igniteui-theming igniteui-theming-mcp. It does not accumulate context between sessions. Theming decisions the agent generates and the developer commits – SCSS files, CSS custom properties, design token configurations – enter the local codebase and become available to the IDE’s project context on future sessions.

Ignite UI Component Libraries

Role	Deterministic UI execution layer – framework-native, enterprise-grade component implementations.
Input	Validated component selection and configuration from the agent workflow.
Output	Production-ready, design-system-aligned, framework-native UI components.
Risk Reduced	Non-deterministic component behavior or rendering inconsistency in AI-generated applications.

The Ignite UI component libraries do not accumulate context. Each version is fixed, versioned, and deterministic. Context accumulation does not enter through this layer. The Ignite UI component libraries are the stable execution substrate against which accumulated context is validated.

---

How an AI Agent Uses This Stack

The canonical Infragistics AI-native workflow is: Developer → IDE → Agent → Agent Skills → MCP servers → Ignite UI Library → Production-ready output. The step sequence below identifies which stages introduce or consume accumulated local context.

Figure 2: The AI-assisted development workflow. Steps 2 and 4 are where accumulated local context enters the pipeline.

Step 1 – Developer Input: Feature description, requirements, or design intent provided as a prompt. Process: Developer submits the prompt to the IDE agent in a workspace with Agent Skills and MCP servers configured. Output: Structured prompt received by the agent, with Skills on disk and MCP tool access available in the active session.

Step 2 – IDE Context and Retrieval Layer Input: Developer prompt, plus IDE workspace state – open files, semantic index of the existing codebase, and conversation history. Process: Depending on the IDE and agent implementation, the workspace may contribute additional context through indexing, code search, file selection, embeddings, or retrieval mechanisms that surface relevant project patterns. Output: Enriched context passed to the agent. For many AI coding environments, this is one of the primary paths through which accumulated project context influences generation.

Step 3 – Agent Input: Enriched context from the IDE, including existing codebase patterns, conversation history, and the current prompt. Process: Agent decomposes developer intent into subtasks and selects components, consulting Agent Skills files available in the workspace. Output: Structured subtasks with Ignite UI-grounded component choices ready for MCP validation.

Step 4 – Agent Skills Input: Agent subtask requiring component selection, framework integration patterns, or usage decisions. Process: Agent reads the Skill file from the local discovery path and applies the defined patterns, import paths, and constraints for the target framework. Output: Validated component selection and framework-correct usage patterns for the target Ignite UI library variant.

Step 5 – MCP Servers Input: Agent query for component documentation, API reference, or design token validation. Process: The Ignite UI CLI MCP server returns documentation-aligned component guidance; the Ignite UI Theming MCP server returns design-token-validated theming instructions. Output: MCP-grounded component configuration, free of hallucinated API calls or invalid token references.

Step 6 – Ignite UI Library Input: Validated, MCP-grounded component selections and configuration from the agent workflow. Process: The target Ignite UI library variant renders the component using framework-native, enterprise-level component implementations. Output: Production-ready UI component rendered in the application.

---

Code Examples

Example 1: Locating AI Context Artifacts on the Developer Machine

Library:       N/A - system diagnostic
MCP server:    Ignite UI CLI MCP server (igniteui-cli)
Purpose:       Locate AI context artifacts accumulated on the local machine
               during Ignite UI AI-assisted development

# --- WORKSPACE-LEVEL CONTEXT (project-scoped, persists across sessions) ---

# Agent Skills - written to disk by ai-config, read by the agent each session
ls -la .agents/skills/              # Cross-agent convention (Copilot, Cursor, Gemini CLI, Windsurf)
ls -la .cursor/rules/               # Cursor-specific rules and skills directory
ls -la .claude/skills/              # Claude Code-specific skills directory
cat .github/copilot-instructions.md # GitHub Copilot workspace instructions

# MCP server configuration - defines which servers the IDE launches
cat .vscode/mcp.json                # VS Code (GitHub Copilot) MCP config - written by ig ai-config
cat .mcp.json                       # Claude Code MCP server config
cat .cursor/mcp.json                # Cursor MCP server config

# --- MACHINE-LEVEL CONTEXT (global, not project-scoped) ---

# npx package cache - MCP server packages are resolved from here after first download
# macOS / Linux (npm 7+)
ls ~/.npm/_npx/

# Windows (npm 7+) - run in PowerShell
# dir "$env:LOCALAPPDATA\npm-cache\_npx"

# Claude Desktop MCP configuration (macOS)
cat ~/Library/Application\ Support/Claude/claude_desktop_config.json

# Claude Desktop MCP configuration (Windows - run in PowerShell)
# type "$env:APPDATA\Claude\claude_desktop_config.json"

These files persist across every AI session in the project and are read by the agent at the start of each generation. They represent intentional, developer-controlled context accumulation – and they are the primary reason an experienced developer’s environment produces consistently better output than a clean machine.

---

Example 2: Clean-Room Test Procedure – Isolating Model Behavior from Accumulated Context

Library:       N/A - clean-room validation procedure
MCP server:    Ignite UI CLI MCP server (igniteui-cli)
Purpose:       Establish a reproducible, context-free baseline to verify AI output
               against a genuine first-run user experience

# Step 1: Create a new isolated workspace with no inherited AI context
mkdir clean-room-test && cd clean-room-test

# Step 2: Confirm no AI context files are present in the new workspace
ls .agents/skills/ 2>/dev/null \
  && echo "WARNING: Agent Skills found - remove before testing" \
  || echo "Clean: no Agent Skills"

ls .cursor/rules/ 2>/dev/null \
  && echo "WARNING: Cursor rules found - remove before testing" \
  || echo "Clean: no Cursor rules"

ls .github/copilot-instructions.md 2>/dev/null \
  && echo "WARNING: Copilot instructions found - remove before testing" \
  || echo "Clean: no Copilot instructions"

# Step 3: Configure MCP servers only - no Ignite UI package installed yet
# This mirrors the exact experience of a new user before installing Ignite UI.
# MCP servers will be configured; Agent Skills will not be available.
npx igniteui-cli ai-config

# Expected output:
# > Ignite UI CLI MCP servers configured for your selected clients
# > No AI skill files found. Make sure packages are installed (npm install)
#   and your Ignite UI packages are up-to-date.

# Step 4: Start the Ignite UI CLI MCP server in the isolated workspace
npx -y igniteui-cli mcp

# Step 5: Run the same prompts used in your accumulated-context environment
# Compare output - differences reveal what the accumulated context was contributing
# to generation quality in the original environment.

This procedure produces a reproducible baseline representing what a first-time user encounters. The expected output from step 3 is documented behavior: MCP servers are configured, but Agent Skills are absent until the Ignite UI package is installed. The generation quality difference between this baseline and a fully-configured development environment is the measure of accumulated context contribution.

---

Example 3: Inspecting Agent Skills as Designed Persistent Context

Library:       All Ignite UI frameworks (Angular / React / Web Components / Blazor)
MCP server:    Ignite UI CLI MCP server (igniteui-cli)
Purpose:       Inspect and edit the Agent Skills files that constitute designed,
               persistent context for AI agents across all development sessions

# After running: npx igniteui-cli ai-config (with Ignite UI installed)
# Skills are copied to your agent's discovery paths - same location regardless of framework

ls .agents/skills/                      # Cross-agent (Copilot, Cursor, Gemini CLI, Windsurf)
ls .cursor/rules/                       # Cursor-specific
ls .claude/skills/                      # Claude Code-specific

# Inspect a Skill file (directory name reflects your installed framework)
cat .agents/skills/igniteui-angular-components/SKILL.md

# To re-copy clean Skills from the package (resets any custom edits):
npx igniteui-cli ai-config

Agent Skills are developer-owned. Editing a Skill file to reflect a correct usage pattern found during debugging – for example, a navbar layout constraint – encodes that pattern into every future generation session in the project. The Skill file is the designed, version-controllable mechanism for intentional context accumulation. The clean-room procedure in Example 2 demonstrates what generation looks like when these files are absent.

---

Integration Scenarios

Scenario 1: Development Environment Context Accumulation

Scenario: A developer’s environment progressively accumulates AI context over the project lifecycle. This example uses Angular; the pattern applies across all supported frameworks. Trigger: Developer runs npx igniteui-cli ai-config at project initialization, then evolves the project over weeks. Flow: Developer → adds features, fixes bugs, and edits Agent Skills to encode patterns discovered through generation. IDE → re-indexes the codebase as files are committed; semantic index reflects the current project state. Agent → reads updated Skills and retrieves context from the indexed codebase on each session. Agent Skills → updated Skill files inject corrected and project-specific patterns into agent context. MCP servers → the Ignite UI CLI MCP server provides fresh documentation-aligned guidance; the Ignite UI Theming MCP server provides token-validated theming. Ignite UI for Angular → renders production-ready output grounded in accumulated project context. Output: Consistent, progressively improving AI generation that reflects the project’s established patterns and conventions.

---

Scenario 2: Clean-Room Testing – Validating First-Run User Experience

Scenario: A developer validates that AI output quality is consistent for a new user with no accumulated context. This procedure is framework-agnostic – the example uses React to illustrate applicability across all supported frameworks. Trigger: QA phase – the development team needs to confirm output quality on a machine with no project or session history. Flow: Developer → creates an isolated workspace with no Skills, no IDE embeddings, and no conversation history. IDE → starts with no semantic index for the project; agent has no codebase retrieval signal. Agent → operates on documentation context from the Ignite UI CLI MCP server only; no codebase retrieval signal available. Agent Skills → absent; agent applies general training knowledge for component selection in the absence of Skill grounding. MCP servers → the Ignite UI CLI MCP server provides documentation-aligned guidance; the Ignite UI Theming MCP server provides token-validated theming. Ignite UI for React → renders components based on MCP-grounded selections only. Output: Baseline AI generation result reflecting the first-time user experience – a valid reference point for measuring accumulated context contribution.

---

Scenario 3: Client Onboarding – Context Accumulation as a Progressive Feature

Scenario: A client team starts AI-assisted development and observes steadily improving generation quality over time. This example uses Angular; the pattern applies across all supported frameworks. Trigger: Client installs Ignite UI for Angular, runs npx igniteui-cli ai-config, and begins generating UI components with AI assistance. Flow: Developer → generates components, reviews output, commits accepted patterns to the project repository. IDE → indexes the growing codebase; retrieval signal improves as more Ignite UI-correct patterns are committed. Agent → retrieves progressively richer context from the indexed codebase on each generation session. Agent Skills → available immediately after ai-config; developer edits Skill files to encode team-specific conventions. MCP servers → the Ignite UI CLI MCP server and the Ignite UI Theming MCP server provide consistent documentation-aligned grounding throughout the lifecycle. Ignite UI for Angular → renders production-ready output that increasingly reflects the client’s established patterns. Output: AI generation quality often improves over the project lifecycle without requiring a model update, provided the agent can use accumulated project context.

---

Evaluation and Differentiation

What the stack delivers on every session: The Ignite UI CLI MCP server provides documentation-aligned component guidance and verified code examples on every session, regardless of accumulated local context on the developer machine. Agent Skills ship with every Ignite UI package release and provide a documented, version-controlled starting point for agent grounding. The Ignite UI Theming MCP server generates design-token-aligned theming instructions on every call, using the Ignite UI Theming Engine’s palette, typography, and component-theme APIs as its reference model, regardless of session history.

How much this grounding changes real output is measured. In a 7-scenario paired benchmark across Ignite UI for Blazor and Ignite UI for Angular, sessions with the MCP servers and Agent Skills enabled raised Ignite UI component compliance from 0/5 to 5/5 in every scenario where the untooled model ignored the library, and lifted single-prompt feature completion from 71% to 100%. The full comparison is in Why Ignite UI AI Tooling Produces Better Results and the accompanying research paper.

Failure Modes Prevented: Agent hallucinating component APIs not present in the installed Ignite UI version – prevented by CLI MCP server documentation grounding. CSS drift and invalid design token references in agent-generated styles – prevented by Theming Engine-aligned generation from the Theming MCP server. Incorrect import paths or deprecated component signatures in generated code – prevented by Agent Skills. Inconsistent first-run experience caused by unmeasured accumulated context – identified and reproduced using the clean-room procedure described in this post.

Assumptions Not Required: The context accumulation phenomenon described in this post does not require the underlying LLM to have been updated; the Ignite UI package to have been updated; any explicit configuration change by the developer; or any action by Infragistics after initial setup. The accumulation occurs through normal development activity – generating, reviewing, committing, and refining AI-assisted code over time.

---

Closing Signal

The intelligence that makes AI code generation appear to improve is not always in the model – it is distributed across the surrounding system: Agent Skills on disk, IDE semantic indexes, committed codebase patterns, and MCP configuration files. Developers building AI-native products on the Infragistics stack need to account for this distribution when measuring output consistency and validating first-user experiences. Establish the controlled baseline with Agent Skills, the Ignite UI CLI MCP server, and the Ignite UI Theming MCP server – and use the clean-room procedure to confirm what the AI system produces when accumulated local context is removed.

In traditional software engineering, teams learn to ask: “Does it work on the client’s machine?” In AI-native development, an equally important question is emerging: “Is the AI seeing the same context on the client’s machine?”

Explore the Ignite UI AI-assisted development toolchain → Ignite UI Agent Skills → React Data Grid →

---