Andrej Karpathy coined a new term after Vibe Coding
Extending my context engineering block series, today we are talking about the difference between context engineering vs system prompt. A term with which you might be getting confused a lot.
So if you don’t know, Andrej Karpathy recently popularized another term after Vibe coding — Context Engineering, where he mentioned that he prefers context engineering over prompt engineering everyday. I have already covered a few posts on context engineering that you can check out at the below links.
So here’s the thing. Everyone’s obsessed with writing the perfect system prompt lately.
You know the drill:
“You are a helpful assistant.”
“You respond concisely and respectfully.”
“You never lie, hallucinate, or feel pain.”
System prompting feels like prompt engineering’s final boss. The sacred header that sets the tone, the vibe, the rules.
But here’s where it gets real: System prompting is just one move inside the larger game of Context Engineering.
And if you think writing a solid system prompt is the whole job, you’re going to end up with a model that behaves nicely in theory… and collapses the minute reality shows up.
What Are They, Really?
System Prompting
This is the first whisper in the model’s ear. The quiet backstage instruction before the curtain rises. It’s static. Baked into the front of the context window before the user ever types a word.
Think of it like the opening monologue:
Here’s who you are, here’s how you behave, here’s what you never do.
That’s useful. But it’s limited.
System prompting frames the model’s personality and rules — it doesn’t give it situational awareness.
Context Engineering
Context Engineering is the entire script, set, and lighting design around the conversation.
It’s not just “who you are,” it’s “what’s happened, what matters now, what’s being asked, what to ignore.”
It decides:
- What history is retained
- What external info is injected (docs, tools, memories)
- How to structure all of that inside a tight token window
- When to override or reinforce the system prompt
System prompting is one sentence at the top.
Context Engineering is the whole damn show.
Purpose
- System Prompting: Define role, tone, boundaries.
- Context Engineering: Deliver performance across varying inputs, states, and tasks — regardless of who the model “thinks” it is.
Use Cases
Everything is overlapping, do remember this
- System Prompting:
→ Set default behavior (e.g., formal, playful, medical)
→ Control tone/style/policy
→ Create personality boundaries (never say X, avoid Y) - Context Engineering:
→ Build long-running chat agents with memory
→ Handle complex multi-step tasks
→ Dynamically change behavior based on user, intent, or retrieved info
→ Keep the model sane when juggling tools, APIs, fallback logic
Relationship Between the Two
System prompting is one tool within context engineering.
It sets the foundation, the voice — but not the brain.
You can write the cleanest, most thoughtful system prompt on Earth…
…and still get trash outputs if the rest of the context window is cluttered, irrelevant, or missing critical info.
Context Engineering decides:
- What the model sees
- What gets pruned
- When the system prompt matters — and when it gets ignored
In short: Context Engineering wraps around the system prompt and decides whether it even gets heard.
Consequences of Doing It Poorly
Bad System Prompting:
- Tone shifts mid-conversation
- Model disobeys instructions or contradicts itself
- Too generic (“you are helpful”) = weak guidance
- Too strict = robotic and brittle
Bad Context Engineering:
- Irrelevant history confuses the model
- Prompt instructions get buried behind noisy docs
- Token limit exceeded = model forgets what matters
- Model outputs hallucinations, wrong references, erratic answers
How Context Engineering Helps System Prompting
- Prioritizes it. Context Engineering ensures the system prompt stays early, visible, and unpolluted.
- Reinforces it. If the system prompt says “be concise,” context engineering doesn’t flood the model with verbose examples.
- Overrides it when needed. Sometimes you want dynamic tone or task switching — context engineering handles that on the fly.
- Protects it from token noise. Retrieval, memory, and user history don’t automatically respect system prompts. You need context engineering to manage that chaos.
Final Thoughts: Are they really that different?
Yes. And no.
System Prompting is the seed.
Context Engineering is the ecosystem that makes it grow — or lets it rot.
You need both. But one is a sentence. The other is a craft.
If you’re just tuning the voice, stick with system prompts. If you’re designing real workflows, agents, products — you’re already doing context engineering, whether you know it or not.
Don’t stop at the top of the window.
Context Engineering vs System Prompt was originally published in Data Science in Your Pocket on Medium, where people are continuing the conversation by highlighting and responding to this story.
