Context Engineering 101 : "Introduction & Stuff"

While navigating a large codebase—vibecoding my way through Cursor, Trae, and Google’s Gemini CLI—I hit a wall.

You're in flow. You're debugging. You request a new feature. And suddenly the AI:

• Deletes working logic,
• Introduces fresh bugs,
• And forgets what you just told it two prompts ago.

You plead:

“Please don’t remove that part. It was essential. Just add the new piece next to it.” But it doesn’t listen. You start worrying: “This AI will corrupt my entire Git history.”

I expected an intelligent pair-programmer—some magical multi-agent architecture inside Cursor or Gemini CLI that understood the full picture of my code. But that’s not what’s happening.

So I fell into the context engineering rabbit hole.

I needed to know:

• What happens when I request a feature?
• How much context does the AI really read?
• How many agents are involved?
• Do they have memory? Tools? Awareness of my file structure?
• Is the architecture fundamentally flawed, or am I just not feeding it enough structure?

And it turns out—it's not the AI’s fault. The missing piece is context engineering.

🤖 What This Article Is (and Isn’t)

This isn’t a deep technical dive (yet). It’s an intro to the mumbo jumbo around context engineering—the keywords, the problems, and why they exist.

Think of this as a primer.

In upcoming posts, we’ll break down each buzzword:

• RAG, summarization, clash, distraction, context poisoning...
• We'll ask: Is this a first-principles need? Or a patch for poor system design?

🧠 TL;DR (for the impatient hacker)

If you’ve ever screamed at your AI pair-programmer for forgetting what you just said— Welcome. You’ve started your journey into Context Engineering.

Anyway, What Is Context?

As Cursor puts it neatly:

“Context” refers to the information provided to the model (in the form of input tokens) that it uses to predict its response (in the form of output tokens).

In simpler terms: Context is everything the model knows at the time of answering your request.

In a Coding IDE (like Cursor or Gemini), there are two types of context:

1. Intent Context

What the user wants the model to do.

This is your goal or prompt - Things like:

• “Add a loading state to this component,”
• “Fix the bug in the loop,”
• “Generate unit tests.”

2. State Context

What the model knows about your current world.

This includes:

• Open files and tabs
• Directory path (pwd)
• System and project config
• Console logs & error traces
• Code surrounding your current file
• Possibly even images or diagrams

Together, these two types of context work in harmony by describing the current state and desired future state, enabling AI/IDE to make useful coding suggestions.

But,

1. If you provide only your intent but not the state, the model has to guess.

2. If you overload it with too much irrelevant state, it gets distracted.

3. If you provide conflicting or stale context, it gets confused or “clashes”.

That’s where Context Engineering comes in: It’s about feeding the right information at the right time to help the AI do what you asked without breaking everything else.

As Andrej Karpathy puts it, "Context Engineering is the delicate art and science of filling the context window with just the right information for the next step".

Is it important to quote Karpathy, everytime someone writes about Context Engineering? - it's like importing React at the top of every file - we don’t question it, we just do it.

I think we should continue more on Context Engineering in upcoming article, we will be covering another set of mumbo - jumbo of our shiny new buzzword.

I’ve spent a lot of time taming flaky AI agents with better context. DM me if you’re working on agent workflows, RAG setups, or just want to debug context chaos together.