Why AI Tools Fail: The Context Crisis That Broke My Code
Last Tuesday, I asked GitHub Copilot to fix a simple pagination bug. Ten minutes later, our checkout flow was broken, user notifications weren't sending, and the admin dashboard was throwing 500s.
The AI did exactly what I asked. That was the problem.
The Bug That Wasn't Just a Bug
Here's what happened. We had a pagination component that was skipping items when users navigated between pages. Classic off-by-one error in the offset calculation. I opened the file, highlighted the buggy function, and asked Copilot: "Fix the pagination offset calculation to prevent skipping items."
It generated a perfect fix. The logic was sound. The code was clean. I shipped it.
// Before
const offset = (page - 1) * pageSize;
// After (Copilot's suggestion)
const offset = page * pageSize;
Looks reasonable, right? Except our checkout flow was using that same pagination component to step through a multi-page form. Now it was skipping the first page—which collected email addresses. No email meant no order confirmation emails. No order confirmation emails meant angry customers and a very angry PM.
The admin dashboard? It paginated through user records. Now it was starting at record 21 instead of record 1. Same component, different context, different disaster.
Copilot didn't fail. I failed by giving it a problem without any real context about what this code was for.
Your AI Tool Is Flying Blind
Every AI coding assistant—Copilot, Cursor, Claude Code—operates on the same fundamental limitation: they only see what you show them. If you have a file open, that's their entire universe. They don't know:
What feature this code belongs to
Which other files depend on this function
Whether this component is shared across three different user flows
That the product team spent six weeks debating this exact implementation
That you already tried this fix last quarter and it broke everything
They're incredibly smart, but they're looking at your codebase through a keyhole.
The worst part? You don't realize how much context you're carrying in your head until you watch an AI tool confidently break something. You knew that pagination component was shared. You knew checkout was sensitive. You just forgot that the AI doesn't know.
The "Just Ask Better" Myth
The standard advice is: "Write better prompts. Give more context."
Sure. Let me just write a 500-word essay every time I want to rename a variable.
I tried this. For the pagination bug, I went full prompt engineering mode:
"This pagination component is used in three places: the product list (where we're seeing the bug), the checkout flow (multi-page form, don't break the step tracking), and the admin dashboard (user record pagination). Fix the offset calculation for the product list without changing behavior for the other two use cases."
Copilot's response? It created a new prop called isProductList and added conditional logic. Now I have a component that needs to know where it's being used. That's not fixing complexity, that's exporting it.
The real problem: I shouldn't need to be a walking dependency graph. The tool should know what I know.
What "Context" Actually Means
When I say AI tools need context, I don't mean more code in the prompt. I mean they need to understand your codebase the way you do after working on it for six months:
Feature boundaries. That pagination component isn't just "pagination." It's part of three separate features: product browsing, checkout flow, and admin tools. Each one has different requirements, different stakeholders, different blast radius.
Dependency chains. If I change this function, what breaks? Not just TypeScript errors—what features stop working? What assumptions are other developers making about this code's behavior?
Historical context. Why does this function have this weird edge case? Probably because someone tried the "obvious" fix and it broke something. That knowledge lives in Slack messages and PR comments, not in your codebase.
Ownership and intent. Who wrote this code? Who maintains it now? What was it designed to do, versus what it's actually doing today?
Your brain does this automatically. You look at a function and you immediately know: "Oh, this is part of the checkout flow, Sarah owns it, we can't change the API because the mobile team depends on it, and that weird validation logic is there because of that bug we had last quarter."
AI tools have none of this. They're reading your code like it's the first day of the job.
The Feature-Shaped Hole
Here's what I actually needed when I asked Copilot to fix that bug:
Not just the pagination component file. Not even all the files that import it. I needed to understand that this component is shared infrastructure serving three distinct features, each with different requirements.
This is where tools like Glue actually matter. Not because they have better AI, but because they index your codebase at the feature level, not the file level. When you ask about pagination, Glue knows: "This component is used by the Product Catalog feature, the Checkout Flow feature, and the Admin User Management feature. Here's what each one needs from it."
That's not prompt engineering. That's giving AI the same mental model you have.
Real Context Is About Relationships
The pagination disaster taught me something: code relationships are more important than code content.
Copilot could read the entire pagination component perfectly. What it couldn't see was the web of dependencies, assumptions, and implicit contracts connecting that component to the rest of the system.
When I asked it to fix the offset calculation, it optimized for the code in front of it. It didn't know it should be optimizing for "don't break checkout" and "don't break admin" because those weren't in the file.
This is why AI tools feel amazing for greenfield code and terrifying for production systems. New code has no relationships yet. Production code is all relationships.
What Actually Works
After the pagination incident, I changed how I work with AI tools. I don't ask them to fix things directly anymore. I ask them to help me understand the problem space first.
Instead of: "Fix this bug"
I ask: "What would break if I changed this function?"
Instead of: "Refactor this code"
I ask: "What depends on this code and what assumptions are they making?"
It's slower. It's less magical. But I haven't broken production in three weeks.
The better solution? Tools that understand features, not just files. Glue does this by maintaining a map of your codebase that includes not just the code structure, but the feature structure. When you're working on pagination, it knows that you're actually working on three features at once.
This isn't about better AI models. GPT-5 won't solve this. The problem is architectural: current AI coding tools don't have the right level of abstraction for understanding how codebases actually work.
The Real Cost
The pagination bug took two hours to fix properly and another three hours to verify we hadn't broken anything else. That's five hours for what should have been a five-minute change.
Multiply that across your team. How many times has someone asked an AI tool for help and gotten a confidently wrong answer? How many times have you caught an AI-suggested change that would have broken something subtle?
We're spending more time reviewing AI-generated code than we saved by using AI in the first place.
This is the context crisis. AI tools are fast enough to be useful but blind enough to be dangerous. They can write code faster than they can understand it. They can implement solutions faster than they can evaluate consequences.
What's Next
I'm not suggesting you stop using AI tools. Copilot is still in my editor. Cursor is still fantastic for boilerplate. Claude Code is genuinely helpful for exploration.
But I've stopped pretending they understand my codebase. They're powerful tools with a critical limitation: they only know what you tell them, and you can't tell them everything.
The next generation of code AI needs to solve the context problem. Not with bigger context windows—no one wants to paste their entire codebase into every prompt. With actual understanding of how your code is organized into features, how those features connect, and what breaks when you change things.
Some tools are getting there. Glue's feature-level indexing is a start. MCP integrations that give AI access to your full codebase structure are another. But we're still early.
Until then, treat AI coding assistants like junior developers. They're fast, they're eager, they write clean code. But they don't know what they don't know. And that's your job to manage.
The pagination bug was my fault, not Copilot's. I asked a tool without context to solve a problem that was all about context. I won't make that mistake again.