Welcome to the deep dive. OK, let's talk about
that feeling. You know the one, right? Yeah.
That mix of hope and, let's be honest, crushing
disappointment when you get some AI -generated
code. Oh, yeah. Looks perfect on the screen.
Exactly. Looks absolutely perfect. But then the
second you try to actually integrate it, it just
crumbles. It falls apart. You end up just tossing
these disconnected prompts at the AI, hoping
something sticks. People are calling it vibe
coding. Yeah, vibe coding. It's kitschy. It is.
But look, today we're digging into something
that feels pretty revolutionary, an approach
that could genuinely change that frustration
into, well, maybe phenomenal productivity. And
that change, that whole approach, it's called
context engineering. And you know, it's not just
another buzzword that's going to vanish next
month. Right. We see enough of those. We do.
This is a, it's a systematic way, really. a methodology
to dramatically improve AI coding results, basically
by giving the AI the right information, precisely.
That feels like such a key difference, doesn't
it? It shifts the focus. It's less about the
AI guessing and more about us, the developers,
actually providing the clarity it needs. It's
almost like we become architects for the AI.
That's a great way to put it. Information architects.
Yeah. So our mission for this deep dive is to
really unpack how this works. We've got some
great sources, including bits from context engineering,
the future of AI assisted development to help
guide us through this shift. Let's unpack this
then. What's the fundamental problem? Why are
developers struggling so much with AI code right
now? Why doesn't it just work more often? Well,
I think it really boils down to trust or maybe
the lack of it. There was this recent study,
Quoto did it, and it found something pretty alarming.
Oh, what was that? 76 .4 % of developers just
don't trust AI -generated code, not without a
human looking it over carefully. Wow, over three
quarters. That's huge. It is. And look, the core
problem isn't really the AI model itself. These
LLMs, they're incredibly smart, like brilliant
interns. They have this vast encyclopedic knowledge,
but they have zero practical experience with
your project, your specific setup. That's a fantastic
analogy. Brilliant interns, loads of theory,
no clue about this actual job site. Exactly.
They know general patterns, sure. But your project's
architecture, the libraries you picked, your
team's coding style, the business reason for
the feature, they know none of that. Right. So
that's the gap. So if they're these brilliant
interns, what are they missing most when we just
give them a simple, vague prompt? It's all about
that context void. When you say something short
like, Write me a user API with Express .js. Yeah,
something simple like that. You're basically
forcing the AI to guess. It has to guess, you
know, your project's directory structure or using
Mongo or Postgres. What about OS? Is it JWT OAuth
2 .0? What are your logging standards, error
handling, existing data models? All of it. It
doesn't know any of that. It's completely in
the dark on the stuff that actually matters for
making the code work in your system. And without
that specific info, it just spits out generic
code, right? Based on common stuff it saw during
training. Precisely. code that might technically
run on its own, maybe, but it's almost guaranteed
to be incompatible somehow with your existing
project. Which leads to hours of painful debugging.
Trying to figure out why this perfectly logical
-looking code is breaking everything. Hours and
hours, costly hours. And that's exactly why context
engineering isn't just like a nice idea, it's
becoming essential, a real game changer. Okay,
so that brings us neatly to the term itself,
context engineering. It's interesting. Andrzej
Karpathy coined it, and he also gave us vibe
coding, funnily enough. Yeah. Yeah. It covers
both ends of the spectrum. Right. And Toby Lidke,
the Shopify CEO, he put it really well. He said,
I really like the term context engineering over
prompt engineering. It describes the core skills
better, the art of providing all the context
for the task to be plausibly solvable by the
large language model. That quote really does
hit the nail on the head. It captures the essence
perfectly. If you want to think about the difference,
think about ordering food. OK. An analogy. I
like it. Trumped engineering is like going to
a chef and saying, cook me something nice with
beef. OK. Vague could be anything. Exactly. Steak,
stir fry, soup. Who knows? It depends entirely
on the chef's assumptions about what you want.
It's basically a shot in the dark. And how often
does that work out perfectly? Probably not very
often, so context engineering is the opposite.
Completely. Context engineering is like handing
the chef a super detailed recipe, right? Here's
300 grams of Australian beef, cut exactly two
centimeters thick, use the cast iron skillet,
get it rip and hot, add rosemary, garlic, cook
it medium rare, serve it with roasted asparagus.
Ah, okay. No ambiguity there. The result is precisely
what you asked for because you gave all the necessary
details. Exactly. So if we want a full definition,
context engineering is something like... The
skill and art of strategically selecting, organizing,
and managing the entire set of information and
AI needs at each step to do complex tasks well
efficiently and accurately. And the key is without
overwhelming it with useless stuff or leaving
out critical details. That's the art part. Finding
that balance, feeding it the perfect information
diet, you could say. OK, the perfect diet. So
here's where it gets really interesting for me.
How does having all this context actually make
such a huge difference? What are the ingredients
in this perfect diet you're talking about? Right,
so context isn't just your prompt. It's everything
the AI model gets to see before it starts generating
anything. It's multi -layered. It's structured.
It includes, well, quite a few things. Lay it
on us. What's in the mix? OK, first, the current
state of the project. That means things like
your file tree structure, the actual content
of relevant code files. Like the files it needs
to modify or interact with. Exactly. And things
like your package .json or requirements .txt
so it knows your dependencies. Then there's historical
information. Meaning? Previous turns in the same
chat session. Or maybe bigger architectural decisions
that were already made and documented somewhere
in the project. Then of course your user prompt.
But not just a one -liner. The detailed one we
talked about with business and technical needs.
Yes. Then crucially, available tools. This is
where it gets powerful. You tell the AI about
specific APIs or functions it's allowed to use.
Ah, like function calling capabilities in newer
models. Precisely. Things like a function to
query your database or an API call to send an
email. The AI can leverage these external tools.
Then there's ARAGI instructions, retrieve a logmented
generation. Guiding the AI on how to look stuff
up. Yep. How it should search and use info from,
say, external docs you provide official API docs,
technical articles, your own internal wiki, and
finally, long -term memory. Persistent rules.
Kind of. Rules, preferences, standards you set
up once, like, always use type hints in Python,
or every public function needs unit tests. These
apply to every single interaction. Wow, okay.
That's... That's a lot more comprehensive than
just a prompt. So by pulling all that together,
the AI can actually cross reference things, connect
the dots. Exactly. It can see the current code,
check the standards file, look at the API docs
you linked, understand the goal from your detailed
prompt. It's not guessing anymore. It's working
from a detailed blueprint. A blueprint. I like
that. So if you compare the two approaches side
by side, vibe coding versus context engineering,
the difference must be stark. Oh, absolutely.
Look at reliability. Vibe coding, pretty low.
Context engineering. much higher debug time vibe
coding often high context engineering way lower
because errors are caught earlier or prevented
scalability consistency vibe coding is hard to
scale or make consistent context engineering
high scalability because you can reuse templates
and rules consistency is much better what about
cost like token usage that's interesting vibe
coding feels cheap per prompt, but the back and
forth adds up fast. Context engineering might
have a larger initial request, but it's often
more optimal overall because you get it right,
or much closer to right, the first time. Fewer
iterations. Okay, so the theory makes a ton of
sense. Blueprint, detailed info, better results.
But the big question for everyone listening is
probably, OK, great, but how do I actually do
this? How do I stop vibe coding and start building
with this blueprint? Let's get practical. Right.
Let's walk through it. There's a great template
out there inspired by Coal Midden that really
demonstrates the principles. And remember, these
ideas work with basically any capable AI model.
OK, step by step. What's step one? Step one is
just laying the foundation. Basic stuff, really.
Make sure you have tools like Git, Node .js installed,
and you'll need an AI programming assistant integrated
into your IDE. Something like the Quad Code extension
for VS Code, for example. Standard developer
setup. Got it. Step two. Step two, acquire the
template. For this specific example, you'd clone
a GitHub repo. https .getup .com forward slash
duress 00000 contextengineering -intro .git.
Then just open that clone folder in your IDE.
Okay, clone the repo. Now what? This is where
the context starts coming in, right? Yeah, okay.
Step three, configuring global rules. This is
where the magic starts. You open a file, often
name something like Claude .md or systemrules
.md. This file holds the core instructions for
the AI for this project. Think of it as your
project's constitution. The constitution. I like
that. So what goes in there? All your high -level
standards and preferences. Code structure stuff.
Use hexagonal architecture. Or React components
must be functional with hooks. Testing requirements.
Use Jest and Supertest for API tests. Minimum
85 % code coverage. Reliability standards, too.
Like error handling. Yep. Always use Trycatch
for I .O. log errors using our standard logger,
even task completion rules, like only mark a
task done when code and tests are generated,
and conversation rules for the AI itself. Think
step -by -step, ask clarifying questions if unsure.
Wow, okay. So you're really setting the ground
rules for how the AI should behave and build
things within your specific project context.
And this applies every time you interact with
it for this project. That's the power. Consistency
across interactions, even across different team
members using it, it reduces that review friction.
Makes sense. So Constitution is set. What's step
four? the actual request. Step four is creating
your feature request. This usually goes in a
separate file, maybe initial .md or featurerequest
.md, and detail is absolutely king here. No more
make a login API. Definitely not. In a feature
section, you'd write something specific like,
build a post of PAV1 off login endpoint. It takes
email and password. Authenticate against the
user's table. On success, create a JWT 24 -hour
expiry, include user and rule, return the token.
super specific. Okay, that's clear. What else
goes in this request file? Critically, an example
section. This is huge. You provide snippets or
paths to existing files in your code base. Ah,
so it learns your style. Exactly. An existing
controller .js, maybe a database model .ts. You
put these in maybe an examples directory and
reference them. The AI learns your patterns,
your style, how you structure things. Okay, examples
are key. A documentation section. Paste links
to relevant docs, Stripe API page, a confluence
article on your internal standards, whatever
it needs. And finally, additional considerations.
Edge cases. Security. Precisely. Endpoint must
be rate limited. Hash passwords using bcrypt.
Performance notes. Anything else it needs to
know to do the job right. Leave no stone unturned.
Okay, foundation laid. Constitution written.
Super detailed request crafted with examples
and docs. Now this next step. Step five, generating
the product requirement plan or PRP. This sounds
like where the real departure from just asking
for code happens. Why plan first? This is the
game changer step, honestly. Instead of jumping
straight to code, you ask the AI to generate
a detailed blueprint first. Using an agent or
tool, you might run a command like agent .planrequest,
requestfeaturelogin .md, output plansloginplan
.md. And what does the AI do then? It goes to
work. It reads your request, deeply analyzes
the documentation links you provided, examines
your code base, especially those example files,
and then it constructs a detailed step -by -step
plan. It might take a few minutes, but it's doing
actual research and architectural thinking. Okay,
so it generates this plan. Step six is reviewing
that PRP. What am I looking for and why is this
review so critical? I guess catching mistakes
here is way cheaper. Way, way cheaper. Yeah.
You're catching errors on the blueprint, not
after the walls are up. A good PRP is detailed.
It'll have a requirement summary. The AI basically
repeats back what it thinks you want, confirming
understanding. Good sanity check. Absolutely.
It lists documentation references it plans to
use. It shows a file structure analysis. Here's
the current tree. Here's what I'll create or
modify. And the core is the detailed implementation
plan, literally step by step. One, create auth
.controller .js. Two, add route to routes index
.js. So you can see exactly what it intends to
do, file by file. Exactly. And often, a risk
assessment section two, potential problems it
foresees, and how it plans to handle them. Reviewing
this catches misunderstandings, logical flaws,
potential hallucinations before code is written.
It saves so much time and tokens downstream.
That feels like a huge shift. It's not just coding
faster, it's improving the design process itself.
Like having a super diligent architect review
your plans. Okay, so plan reviewed, looks good.
Step seven, execute the PRP. Yep. Now you tell
the AI to build it, a command like agent .execute
plansloginplan .md workspace .src. And the AI
just systematically works through the plan. What
does that look like in practice? It'll create
directories if needed, install dependencies via
npm or pip, write the code for each specified
file, run linters or formatters you've configured.
It might even try to run build commands or simple
validations. And if it hits small errors, it
often tries to fix them automatically based on
the error messages. That sounds pretty intensive.
Takes a while. Uses tokens. It can, yes. Especially
for complex features. It might take several minutes.
And it will use tokens as it thinks, writes,
and potentially self -corrects. But the output
quality, the adherence to your plan and standards,
it's usually far superior to just wean it with
vibe coding. Right. The upfront investment pays
off in quality and reduced rework. So execution
finishes. What's the last step? Step eight is
basically test and deploy. The AI usually finishes
by giving you the final instructions. Things
like environment variables you need to set, API
keys you need to configure, the exact commands
to install everything, npm install, run the app,
npm start, and run the tests, npm test. So it
hands off a working tested based on its generated
tests feature with instructions. Ideally, yes.
You follow its final steps, do your own thorough
testing, of course, and then deploy. But it's
built to your specifications defined in the context
in the plan. Okay, that whole process makes sense.
To really hammer home the power, maybe let's
look at a more complex, real -world example,
something beyond a simple login, like that automated
financial analysis system idea. Great idea, because
that's where you see the massive time savings.
Imagine you want an AI to build a system that
pulls quarterly financial reports and drafts
an email summary for your investment team. Okay,
that sounds complex. What would the initial .md
look like for that? Under features, you'd be
very specific. build an automated Python system,
takes a list of stock tickers, uses the Braids
search API to find the latest quarterly earnings
report PDF or web page for each, extracts key
metrics, revenue, net income, EPS, future guidance,
then uses the Gmail API to draft an email summarizing
findings comparing current quarter to previous.
Wow, okay. Very specific feature set. What about
examples and docs? Crucial here. Under examples,
you might provide a sample Python script showing
how you prefer to use libraries like requests
for fetching data and maybe Beautiful Soup for
basic HTML parsing, and definitely provide a
markdown template showing the exact format you
want for the final email draft. Style, tone,
structure. So it matches your team's communication
style. Smart docs. Direct links under documentation
to the Brave Search API docs and the Gmail API
docs make it easy for the AI. And additional
considerations. What kind of things, Zach? Things
like handle cases where an earnings report can't
be found for a ticker. Ensure the email tone
is professional and objective. maybe mention
API rate limits to be aware of, error handling
for parsing failures. Okay, and if you run this
whole context engineering process plan, review,
execute, what's the potential outcome? The outcome
could be a complete Python project, maybe with
a main script like financialanalyzer .pi, helper
modules, requirement files, a system that automatically
does that research, scrapes the data, performs
the analysis, and drafts that detailed email.
Which would normally take a human analyst star
hours. Easily. hours of manual, tedious work,
researching, downloading, reading reports, extracting
numbers, drafting. This system could potentially
do it for, what, maybe a few dollars in API fees
and token costs? That's a jaw -dropping productivity
game, moving from manual slog to automated insight.
So if we zoom out again, connect this to the
bigger picture. What are the real compounding
benefits here? Adopting this context -first approach
across a whole project or team. The benefits
really stack up, I think. First, reduced hallucinations.
Big one. By giving the AI a clear, bounded world,
your context it operates on the ground truth
you provide. less making stuff up. Makes sense.
What else? Superior planning. Like we said, forcing
the AI to plan before coding catches so many
architectural or logical flaws early. Fixing
the blueprint is way cheaper than renovating
the building. Right. Cognitive offloading, too,
maybe? Absolutely. Cognitive offloading. Developers
can focus more on what the high -level requirements,
the business value, and let the AI handle more
of the detailed how. Freeze up mental bandwidth
for harder problems. I can see that. And the
context files themselves. They become a form
of living code -based specification. your CLAWD
.md rules, your detailed initial .md requests,
the generated PRPs, they act as always up -to
-date documentation explaining how the system
is built and why certain decisions were made.
That's incredibly valuable. Documentation that
doesn't get stale and overall quality. Consistent
quality. With good context, the AI consistently
produces code that meets your standards, uses
your patterns, includes tests, fewer bugs, easier
maintenance, more reliable system overall. OK,
it sounds almost perfect, which always makes
me ask, what are the catches? Are there pitfalls
to watch out for when you start doing context
engineering? Where can things go wrong? Oh, definitely
pitfalls. It's not magic. It requires skill.
One big one is over -constraining. Too many rules.
Yeah, being too rigid. If you lock down every
single detail, you might stifle the AI's ability
to find a clever or simpler solution you didn't
think of. It can sometimes be counterproductive.
OK, so don't stifle creativity entirely. Yeah.
What else? Conflicting context. This is a subtle
one. If your global rules in Claw .md say one
thing, but your specific feature request in Initial
.md accidentally implies something contradictory.
The AI gets confused. Mixed signals. Exactly.
It can lead to unpredictable or nonsensical output
because it doesn't know which instruction takes
precedence. Consistency across your context is
key. Makes sense. What about the planning step?
Skipping PRP review? It was tempting, right?
You just want the code. But blindly trusting
the AI's plan without carefully reading it is
risky. It might have misunderstood something,
planned a flawed approach, and if you just hit
execute. You bake in the errors right at the
start. Got it. And the opposite of over -constraining.
Insufficiently detailed context. If you don't
provide enough detail, good examples, clear requirements,
relevant docs you just drift back towards. Vibe
coding. Right back where you started. The AI
is forced to guess again. So, yeah, finding that
balance detailed enough, but not too rigid and
internally consistent, that's the skill. It really
feels like context engineering is more than just
a technique. It's a fundamental shift, isn't
it? in how we even think about interacting with
these powerful AI tools. We're moving away from
just being command -givers, shouting orders into
the void, and becoming more like information
architects, curators of context. The critical
skill isn't just writing a clever prompt anymore,
is it? It's about systematically gathering, organizing,
structuring, and presenting the right information,
designing the entire conversation. That's perfectly
put. It's really about more than just training
an AI to write code snippets. It's about training
it in a way to become a capable, reliable member
of your development team. one that understands
your project's specific needs and standards.
It's truly augmenting what we can do. So, maybe
the final thought for everyone listening is this.
The era of unreliable, frustrating vibe coding
feels like it's coming to an end. The age of
systematic, context -driven software development,
that seems to be just beginning. The question
is, are you ready to be a part of that shift
and transform how you build software? It's an
exciting time to be a developer. It really is.
We definitely encourage you to explore these
ideas more, check out the resources, maybe try
building a simple context template for one of
your own projects. The future of coding is unfolding
and it looks like context is right at the heart
of it.