The Context Tax: Why Every Cursor Session Costs You 15 Minutes

"Context Tax," a productivity cost incurred when senior engineers must repeatedly re-explain their project's architectural conventions to AI coding tools like Cursor, which lack persistent memory between sessions. This tax can cost thousands of pounds annually per engineer due to time wasted on redundant context-setting and correcting "AI drift." The author proposes a solution using four `.mdc` rule files that enforce architectural boundaries, audit dependency injection, prevent error loops, and maintain a persistent learning log across sessions.

There's a hidden cost senior engineers pay every morning when they open Cursor. It compounds quietly, it doesn't show up on any dashboard, and at a typical senior billing rate it's worth thousands of pounds a year. I call it the Context Tax. Here's why it happens, what it actually costs, and the four-rule architecture I built to eliminate it. Open Cursor on Monday morning. New chat. You're picking up where you left off Friday — adding a caching layer to OrderService . You type: "Add Redis caching to this method." And the AI returns something technically correct, but architecturally wrong. It instantiates ConnectionMultiplexer directly in the service constructor. It uses IMemoryCache as if your project doesn't already register IDistributedCache . It writes a synchronous wrapper around an async call. You sigh. You type the preamble. Again. "This project uses Mediator and Result<T . We register caching through IDistributedCache in /Infrastructure/Caching. Don't reach into ConnectionMultiplexer directly. Don't put any caching logic in the Service layer — wrap it via a decorator in Infrastructure. And we never instantiate dependencies, we inject them via constructor." Three paragraphs. Maybe four. By the time the AI has the context it needs to actually be useful, you've spent fifteen minutes typing what your codebase has already shown it dozens of times before. That's the Context Tax. Cursor — like every other AI coding tool right now — has no persistent memory between sessions. Each new chat starts fresh. Every architectural decision your team has ever made, every refactor your codebase has ever absorbed, every "we tried that, it doesn't work for us" — gone the moment you close the window. The AI isn't stupid. It's amnesiac. Worse: even within a session, the AI's understanding of your architecture is a fragile probability cloud. By Wednesday afternoon it has "forgotten" the convention it followed on Monday. It starts suggesting patterns that violate your boundaries. You correct it. It double-downs. You correct it again. It loops on the same hallucination, burning tokens, burning your time. This is what I call AI drift, and on a long project it's the single biggest reason senior engineers go from "Cursor is incredible" to "I've turned the autocomplete off." Let's do the uncomfortable math. On a five-engineer team that's the cost of a junior hire. The obvious response is to write a long system prompt with all your conventions and paste it at the top of every new chat. Most senior engineers I know have tried this. It fails for three reasons: You don't need a longer prompt. You need persistence. The breakthrough — once you stop thinking of Cursor as a chat-bot and start thinking of it as a stateful pair-programmer — is that the AI needs three things to behave like a senior: Startup.cs and ServiceCollectionExtensions.cs , not on every controller. Token budget preserved.None of these are exotic. They're standard senior-engineering moves applied to the AI itself. I packaged the pattern I've been using on real .NET codebases into four .mdc files Cursor reads natively: arch-core.mdc — boundary enforcement. Detects which layer the current file lives in and refuses suggestions that cross it.dotnet-di.mdc — DI auditor. Catches Scoped → Singleton capture, HttpClient instantiation, IConfiguration leaks into business logic.bug-breaker.mdc — the circuit breaker. Watches for repeated failed attempts on the same problem and forces re-reading instead of doubling down.persistence.mdc — the engine. Maintains LEARNING LOG.md across sessions. Auto-appends decisions in an ADR-style format. Hydrates the AI on session start.The whole thing lives in .cursor/rules/ and a single root-level LEARNING LOG.md . Zero config. Zero build step. Commit it to your repo, your whole team gets the same baseline. Monday morning, two months in. New chat: "Add Redis caching to OrderService." The AI responds: "Detected Scoped lifetime conflict with IMemoryCache Singleton . Following Log Entry 27: 'PreferIDistributedCache abstraction in/Infrastructure/Caching .' Applying decorator pattern via Scrutor perarch-core.mdc §3 ..." No preamble. No correction loop. The AI already knows. The arch-core-lite.mdc rule is a stripped-down version of the kit's boundary guardian. Drop it in your .cursor/rules/ folder and watch your AI start respecting your layers today. Free download, no signup: The full Agentic Architect kit — 4 specialist rules + the persistence engine + Learning Log template — is £19.99 one-time. Lifetime updates. MIT-licensed. 14-day no-questions refund. 👉 Get the full framework — £19.99 Originally published at agenticstandardcontact-byte.github.io/agentic-architect/blog. Canonical URL is set so the original gets the SEO juice.