Your AI Coding Tool Writes 2024 Code — Why Context Engineering Is the Only Fix That Works
I’ll say it bluntly: your AI coding tool is probably writing code that’s already out of date.
Not because the models are bad. Not because you’re using the wrong tool. But because the context you’re feeding it is stale. I’ve seen this pattern across dozens of codebases we’ve worked on with our team in Ho Chi Minh City. The AI generates clean, working code that looks right — but it’s wrong for *your* stack.
How We Migrated a Real-Time B2B Platform from a Monolithic Database to Event-Driven Architecture with a Vietnamese AI-Augmented Team
How We Migrated a Real-Time B2B Platform from a Monolithic Database to Event-Driven Architecture with a Vietnamese AI-Augmented… ...
This isn’t a hallucination problem. It’s a context starvation problem.
The Real Problem: Your AI Doesn’t Know Your Codebase
Here’s what most developers miss. When you open Cursor, Copilot, or Claude Code and start typing, these tools don’t see your entire codebase. They see a window — usually 4,000 to 16,000 tokens of context.
Why Your Team Needs AI Code Review Automation Tools (And How to Start)
TL;DR: AI code review automation tools help teams catch bugs, enforce coding standards, and speed up pull request… ...
That’s tiny.
A production codebase with 50,000 lines of TypeScript, 200 API endpoints, 12 database migrations, and custom lint rules? That’s millions of tokens. Your AI tool gets a *screenshot* of your project, not the full picture.
The result? It writes code that:
- Imports from a deprecated package you removed last month
- Uses a pattern you explicitly banned in your `.eslintrc`
- References a function signature that changed three PRs ago
- Ignores your custom error handling conventions
I recently watched a junior developer on our team in Can Tho spend 4 hours debugging an AI-generated API client. The tool had written `fetch` calls with `async/await` in a try-catch that didn’t match our team’s error contract. It compiled. It ran. But it leaked errors in production.
The tool wasn’t wrong. It just didn’t know our conventions.
Why “Better Prompts” Won’t Save You
Most developers respond to this by writing better prompts. “Be more specific,” they tell themselves. “Use more context.”
That’s a band-aid.
Honestly, the prompt engineering hype is misleading. You can write the most detailed prompt in the world — “Write a TypeScript function that uses our custom `ApiError` class, follows the `@typescript-eslint/no-floating-promises` rule, and imports from `@company/core`” — and the AI will still produce code that violates your conventions if it doesn’t have *your* codebase in its training data.
The fix isn’t better prompts. It’s better context.
Context Engineering: What Actually Works
Here’s the practical framework we use at ECOAAI with our Vietnamese engineering teams. It’s not complicated. But it’s specific.
Step 1: Build a Context Vault
Stop relying on the AI’s training data. Start feeding it *your* data.
Create a `CONTEXT.md` file in your repo root. Not a README. A *context* file. It should contain:
- Your architectural decisions: “We use `neverthrow` for error handling, not try-catch”
- Your package constraints: “`axios` is banned. Use `ky` for HTTP”
- Your coding patterns: “All API functions must return `Result
- Your dependency graph: “Don’t import from `@company/legacy`. Import from `@company/core`”
We’ve seen a 34% reduction in AI-generated PR rejections after teams added a 200-line context file. That’s not a fluke. It’s the AI having a map instead of guessing.
Step 2: Use the Right Context Injection Pattern
Don’t dump your entire `CONTEXT.md` into every prompt. That’s wasteful. Instead, use selective context injection.
Here’s the pattern we use with our ECOA AI Platform ACP:
python
# Pseudocode for context injection
def build_context_prompt(task_type, file_path, repo_analysis):
context_map = {
"api_route": load_section("api-conventions.md"),
"database_migration": load_section("db-patterns.md"),
"error_handling": load_section("error-contract.md"),
}
relevant_section = context_map.get(infer_task_type(file_path), "general.md")
return f"Task: {task}\nContext: {relevant_section}\nCodebase: {repo_analysis}"This is basic. But it works. You’re telling the AI *which* part of your codebase matters, not sending everything.
Step 3: Audit Your AI’s Output for Context Drift
This is the step nobody does.
Every week, run a diff on your AI-generated code. Look for patterns that don’t match your codebase. We call this context drift.
We built a simple GitHub Action that flags AI-generated PRs where the code pattern doesn’t match the repo’s dominant conventions. It catches about 1 in 8 PRs. That’s 12.5% of code that would have introduced subtle bugs.
Real Example: How We Fixed It for a US Client
Recently, we migrated a legacy PHP monolith to Node.js for a client. The AI coding tools were writing *correct* Node.js — but they were writing it like it was 2022.
They used `express` directly. They didn’t use our `fastify` wrapper. They wrote `try-catch` instead of our `@company/error-handler`. The code compiled. It would have worked. But it wouldn’t have matched the rest of the codebase.
The fix? We injected the client’s `api-conventions.md` into every prompt. That’s it. One file. 150 lines of Markdown.
The next batch of AI-generated code matched 92% of the team’s conventions. Before that? Maybe 60%.
The Math on Context Engineering
Let’s be concrete.
Without context engineering:
- 40% of AI-generated code needs refactoring to match conventions
- 15% introduces subtle bugs (wrong imports, mismatched error handling)
- 3-5 hours per week of debugging “AI code that looked right”
With context engineering:
- 12% needs refactoring (still not zero, but much better)
- 4% introduces bugs (detectable in code review)
- 45 minutes per week of cleanup
That’s a 4x improvement in developer time. And it costs nothing. Just a Markdown file.
Why Your Team in Vietnam (or Anywhere) Should Care
This isn’t just about AI tools. It’s about team velocity.
If you’re hiring Vietnamese developers — or any offshore team — you’re already dealing with context gaps. Time zones. Communication delays. Different conventions.
AI coding tools amplify those gaps. They write code that *looks* right but *isn’t* right for your codebase. Then your senior devs spend hours fixing it.
Context engineering closes that gap. It’s a force multiplier for your offshore team. Our developers in Ho Chi Minh City use it daily. They feed the AI the *actual* conventions, not the training data.
The Bottom Line
Stop blaming your AI coding tool. It’s not broken. It’s just context-starved.
Feed it your codebase’s actual conventions. Not your README. Not your package.json. Your *real* patterns.
You’ll get better code. Faster. With fewer bugs.
And your senior devs will stop wasting time on AI-generated PRs that don’t match your stack.
—
Frequently Asked Questions
How do I build a context vault for my AI coding tool?
Create a `CONTEXT.md` file in your repo root. Include your architectural decisions, banned packages, coding patterns, and error handling conventions. Keep it under 300 lines. Update it every time you merge a PR that changes a convention. The AI doesn’t know what’s in your head. Put it in writing.
What’s the difference between context engineering and prompt engineering?
Prompt engineering is about *how* you ask the AI. Context engineering is about *what* you feed it. Prompts are ephemeral. Context is persistent. You can’t fix a context-starved AI with better prompts. You fix it with better data.
How often should I audit my AI-generated code for context drift?
Weekly. Set up a GitHub Action that flags PRs where the code pattern doesn’t match your repo’s dominant conventions. We use a simple script that checks import paths, error handling patterns, and function signatures. It runs in 30 seconds. It catches 1 in 8 PRs.
Does context engineering work for all AI coding tools?
Yes. But it works best with tools that support system prompts or custom instructions. Claude Code, Cursor, and Copilot all support this. Aider and Cline do too. The key is consistent injection — not just one-off prompts.
Related reading: Vietnam Outsourcing: Why I Stopped Looking at India First
Related reading: Outsourcing Software in 2025: Why Top CTOs Are Betting on Vietnam Over India
