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.