Understand why AI-assisted engineering fails without durable project context and why context engineering is the most impactful skill for AI-assisted development.
Transcript14 entries
Instructor:Your AI coding agent writes confident code that breaks your repo's rules, ignores your architecture, and invents patterns that don't exist. Sound familiar? I'm Nilay Parikh. I've spent two decades compounding technical expertise across Big Tech and the startup ecosystem. Today, I lead LocalM and Ergosum, where we're pushing the boundaries of Agentic AI across SDLC, Platforms, and Quant Research. In this course, we'll learn how to turn GitHub Copilot from a generic coding assistant into a project-aware partner, whether you're midway through AI-assisted development
Instructor:or just getting started. By the end, you'll understand how to make Copilot work with your repo, avoid instruction bloat, and reduce hallucinations. This first lesson is simple by design. We'll run the exact same prompt twice, once with context and once without. Then we'll go under the hood and see how the coding agent behaves in both cases. That comparison shows why context matters and sets up the rest of the course. So don't skip this lesson.
Instructor:You'll see why context is one of the most important levers for keeping AI from wasting your time. Let's start with the big question: why does AI-assisted coding fail? AI coding tools are strong generalists, but they miss what's specific to your project unless you teach them. Without lasting context, they pick the wrong framework, the wrong naming, and the wrong constraints. Those aren't model failures. They're context failures. Let me show you real data before we get into VS Code. We gave claude-haiku-4.5 the exact same coding task twice. With context, the model found the hidden spec within 15 seconds, planned all 14 requirements, and made a tight 3.1 KB patch.
Instructor:It touched only the 2 files it actually needed. That run scored 14 out of 14 on the assessment rubric. We'll walk through the quality gap in a moment. Without context, the same model built an entirely new escalation subsystem. Five new files, a new data schema, new queue contracts, and 34.8 KB of confident, well-structured, but repo-wrong code. That kind of output is much harder to maintain, especially as the system grows. That run scored 4.5 out of 14. More code, more confidence, more wrong. Let's go into VS Code and see how it worked. We're in VS Code now, and I have both examples in front of me.
Instructor:First, I'll run the simple task for the demo. This Python file is just a wrapper around GitHub Copilot CLI. It sets up the project, removes old project files, and makes sure the CLI runs with the correct prompt. It doesn't interfere with the run itself. It just gives us logs and a patch at the end. When the run finishes, we can inspect the changed files and see exactly what happened. It also dumps the full logs so we can trace the session step by step. Before we inspect the output, look again at the session-efficiency numbers from the earlier slide.
Instructor:In a short run, token usage drops dramatically when the model gets the right context. In this lesson, the context token usage is roughly one third of the baseline, and sometimes even lower. A lot of teams hit rate limits because tokens run out very quickly, and users assume the model is the problem or that the application is just too token hungry. That's not the whole story. No, a big part of the cost comes from the model spending thinking tokens to traverse and understand the codebase during the request.
Instructor:Good context makes the process faster, cheaper, and more reliable. Now we already have the with-context version, so let's look at it first. The demo patch is only about 102 lines. Just 2 files changed, and if we inspect the diff, that is exactly what we see. The without-context run times out, not because the repo is failing, but because I intentionally capped the runtime for this lesson. Even so, it still generates the change log, and that contrast is the point. One path is context engineering. The other is just functional guesswork.
Instructor:They're not the same thing. Both can produce output, and guesswork can still give you a quick prototype if you never need to maintain it. But that is the catch. If you're building an enterprise application where iteration and support matter, context is not optional. There's a myth in the industry that says your code is your context. You don't need anything else. This demo shows why that's wrong, because the source code alone doesn't carry the hidden rules. That's exactly where curated context helps. Now the second result is back, and yes, the change has been delivered.
Instructor:Look at the size. The without-context patch grows to more than 600 lines, almost six times more code, and it touches almost 9 files. It changes the database, the queue contracts, and even permission rules. Both sessions are complete now. If you compare them side by side, you can see where the compliant path stays tight and where the blind path overbuilds. That is the difference between treating code as context and giving the agent real project context. Try this on your own machine if you can, and remove the timeout flag if you want the full baseline run.
Instructor:Now let's go back to the original presentation. The exact same prompt went into a workspace that exposed only the source code. There was no .github behavior layer, no architecture docs, and no custom context files. If you go through the logs, you can see how much raw code it had to read. It read almost 19 files, about 18 percent of the codebase. And if the codebase were larger, that kind of exploration would consume even more tokens. Very quickly, it can fill the context window. Add 5 glob searches and around 40 calls, and the token burn climbs fast.
Instructor:That's where hallucinations and wrong architectural guesses start to show up. The model found code patterns, but nothing that spelled out the actual requirements. That was the gap. Around 80 seconds in, it made the critical wrong call. Instead of adding a side workflow to existing modules, it chose to build a brand-new subsystem from scratch. That was never the right move. It created a new escalation service, new routes, new schema, and new contracts. The runtime hit the 3 minute timeout that we set. Even then, it still produced 34.8 KB across 8 files. It looked substantial,
Instructor:but it missed the hidden spec and failed most of the rubric. On the other hand, the prompt was identical, but the curated workspace exposed the real context. Within the first 15 seconds, the agent read the source-of-truth docs and discovered exactly where to edit. By around T plus 60, it had a 14 point plan. Then it edited only applications.ts and loan-service.ts, which was exactly where the change belonged. No new routes, no new schema, and no new queue contracts. The result was a compact 3.1 KB patch, done in 1 minute 24 seconds, scoring 14 out of 14. Context doesn't make the model smarter.
Instructor:It makes the model relevant to your repo. Teams move through this maturity ladder: guessing, manual pasting, repo-level context, and finally context as a maintained system. This course walks you through that progression. We will curate context, layer instructions, plan, build, validate, and maintain, one lesson at a time. That's the foundation. AI-assisted coding fails without lasting context. Context engineering is how you fix it. Now I want to hear from you: what's the biggest challenge you're facing with AI-assisted coding in your repo right now? Is it naming, architecture drift, or something else entirely?
Instructor:Share your thoughts and questions in the comment section below. We'll be selecting the best comments for upcoming live sessions, so don't miss that invite. Make sure to subscribe and turn on notifications, and I'll see you in Lesson 2.
Learning Objectives4
- Explain why AI-assisted engineering fails when project context is missing
- Distinguish prompt engineering from durable repository-level context engineering
- Describe why context should be treated as engineering infrastructure rather than ad hoc chat setup
- Position context engineering as the foundation for planning, implementation, review, and maintenance workflows
Q&A
Q & A
Q
What is the main failure mode this course addresses?
AI systems are strong generalists but weak at project-specific judgment unless you teach them how your repository works. Wrong frameworks, wrong conventions, and wrong validation steps are usually context failures, not model failures.
Q
Why does this matter more for agents than autocomplete?
Autocomplete only needs the current file. Agents need architecture, tooling, validation commands, and role boundaries to act safely and correctly across a whole repository.
Q
What is the durable alternative to repeating context in chat?
Encode the shared knowledge once in .github and /docs so every developer, every session, and every agent run gets the same context automatically.