Most developers who tried an AI coding agent in 2023 or 2024 and bounced off it are still thinking about the problem as "prompt engineering" — finding the magic phrasing that gets the model to behave. That framing is outdated. The agents got smarter; the bottleneck moved. Today the difference between an agent that reliably ships correct code and one that hallucinates confidently wrong changes is almost entirely about what's in its context window and when, not how cleverly you phrased the ask. This is context engineering, and it's a skill you can build deliberately.
Here's what that looks like in practice, with patterns you can adopt this week.
If you're re-explaining your test framework, your commit conventions, or "don't use any
in TypeScript" in every single session, you're burning tokens and patience on facts that don't change. Tools like Claude Code, Cursor, and Windsurf all support a project-level instructions file (CLAUDE.md
, .cursorrules
, AGENTS.md
). Treat it like an onboarding doc for a new hire who is extremely fast but has zero institutional memory.
What actually belongs there:
What doesn't belong: things derivable from reading the code. A CLAUDE.md that restates your file structure or explains what each function does will rot the moment someone refactors, and it trains you to trust stale docs over the actual source. The file should contain decisions and constraints, not documentation.
A single long-context conversation is not the same as persistent memory. Within a session, an agent can hold your whole codebase in its head. The moment that session ends, it's gone — including any hard-won context about why a particular fix was tricky, or what you rejected and why.
The fix is a lightweight external memory: a directory of small, topic-scoped notes the agent reads at the start of relevant work and writes to when something worth remembering happens. The key discipline is separating what belongs in memory from what belongs in the code or git history. Don't store "the login function is in auth.py" — that's one grep away. Do store "we tried rate-limiting at the middleware layer and reverted it because it broke websocket upgrades" — that's a scar tissue fact no static analysis will ever recover, and the next agent (or the next you, six months later) will otherwise repeat the mistake.
If you're rolling your own, keep each memory file small and single-purpose, and maintain a short index file that's cheap to load every time so the agent knows what's available without reading everything. The obvious pitch for subagents is "do things concurrently." The underestimated pitch is that they let you quarantine context. A research task that reads twenty files to answer one question shouldn't leave twenty files' worth of tokens sitting in your main conversation for the rest of the session — that's context you'll pay to re-process on every subsequent turn, and it crowds out the thing you're actually trying to build.
Practical rule: any exploratory task that produces a lot of intermediate reading but a small final answer ("where is X handled," "what's the current test coverage for Y," "summarize this API's auth flow") should go to a subagent that returns a distilled result. Anything where you need the full detail retained for iterative editing stays in the main thread.
This also changes how you write the request. A subagent has no memory of your conversation — it needs the why, not just the what. "Find where sessions expire" gets a shallow grep-and-report. "We're debugging users getting logged out mid-checkout; find where session expiry logic lives and check whether it accounts for long-running requests" gets you an answer that's actually useful, because the agent knows what would count as relevant.
The single most common failure mode in agentic coding right now isn't bad code generation — it's an agent (or a developer reviewing its output) treating "the code compiles" or "the diff looks plausible" as equivalent to "the feature works." It isn't. Type checking and unit tests verify correctness of what you told the system to build; they say nothing about whether that was the right thing, or whether the actual runtime behavior matches intent, especially for anything with a UI or external side effects.
The cheap version of this discipline: before you tell an agent (or a teammate, or yourself) that a task is done, make it state what was actually run and observed — not what should work. "Ran the new test, it passed, here's the output" is verification. "This should handle the edge case correctly" is a guess wearing a confidence suit. This sounds obvious written down, but it's the single highest-leverage habit for anyone directing AI-assisted work, because LLMs are fluent enough that confident wrong answers and confident right answers read identically until you check.
Once you have subagents and memory working, it's tempting to fan everything out — five agents reviewing a one-line CSS fix, a full research pipeline for a question you could answer in thirty seconds. Resist this. Orchestration has real cost: token spend, latency, and the cognitive overhead of reviewing more surface area than the task warranted. Match the machinery to the blast radius of the change. A typo fix needs a diff read. A schema migration touching a production table earns the full pipeline: independent review, adversarial verification, a real test against a real (or realistic) dataset.
None of this requires a smarter model. It requires treating context — what the agent knows, when it learned it, and what it's allowed to forget — as an engineering surface with the same rigor you'd apply to caching or database schema design. The teams getting compounding value out of coding agents right now aren't the ones with the best prompts. They're the ones who stopped re-explaining themselves every session, gave their tools a memory, and built the habit of checking claims against evidence before shipping them. That's a process change, not a model upgrade, and you can start it today with whatever agent you already have open.