Your AI Coding Tool Has No Idea What Your Codebase Looks Like: A Practical Guide to Context Engineering

You’ve been blaming the wrong thing.

Every developer I talk to complains that AI coding tools generate useless, half-baked code. “Copilot suggested a Python 2 syntax last week.” “Claude Code wrote a SQL query using a table that doesn’t exist.” “Cursor hallucinated an entire API endpoint.”

I Maintained a 10K-Star Open Source Project for 2 Years—Here’s What Actually Made It Survive (and It’s Not Code)

I Maintained a 10K-Star Open Source Project for 2 Years—Here’s What Actually Made It Survive (and It’s Not… ...

They blame the model. They blame the tool.

But here’s the truth: your AI coding tool doesn’t know your codebase. It has no idea what your project structure looks like, what naming conventions you follow, which database schema you’re using, or what version of that library you pinned in `requirements.txt`. It’s guessing based on generic training data.

I Scanned 10,000 Open Source PRs: The 5 Deadly Patterns That Get You Rejected Every Time

I Scanned 10,000 Open Source PRs: The 5 Deadly Patterns That Get You Rejected Every Time Let me… ...

So of course the output is garbage. You’re asking a chef to cook a meal without showing them the pantry.

Let’s fix that.

What “Context Engineering” Actually Means

Context engineering is the deliberate practice of feeding your AI coding tool the right information so it produces code that actually works in *your* specific project. Not generic code. *Your* code.

It’s not prompt engineering. Prompt engineering is about phrasing the question. Context engineering is about giving the AI the answer key before it even starts.

We’ve been doing this with our team in Can Tho for the last 6 months. The results are hard to ignore:

Bad suggestion rate dropped from ~40% to ~16%
Time spent reviewing AI-generated code fell by 55%
Developer satisfaction scores went from “meh” to “this actually saves me time”

Here’s the framework we built. Four levels of context. Each one matters.

Level 1: The Prompt Itself (You’re Doing It Wrong)

Most developers write prompts like they’re texting a friend:

“Write a function to validate email addresses”

That’s garbage. Here’s why: the AI doesn’t know what “valid” means in your context. Do you accept `+` addressing? International domains? Disposable email providers? What about the specific regex you already use elsewhere in the codebase?

Bad prompt output:

python
import re

def validate_email(email):
    pattern = r'^[\w\.-]+@[\w\.-]+\.\w+$'
    return bool(re.match(pattern, email))

That works for a tutorial. It’ll fail in your production system.

Good prompt:

“Write an email validation function following our existing validation patterns in `src/validators/`. Use the same regex style as `phone_validator.py`. We don’t allow `+` addressing. Check against our blocklist in `config/blocked_domains.yaml`. Return typed `ValidationResult` objects, not booleans — see `src/types/validation.py`.”

See the difference? I just gave the AI a map of your codebase. Now it can actually look at the right files (if the tool supports it) and generate code that fits.

A rhetorical question for you: How many lines of AI-generated code did you delete last week because it “looked right” but didn’t match your project conventions?

Exactly.

Level 2: The Open Tabs / Current File Context

This one’s subtle but powerful. Most modern AI coding tools (Copilot, Cursor, Claude Code, Codex CLI) use your currently open files as context. But developers rarely optimize this.

Here’s what we do differently:

Before asking the AI to write code, we open 3-4 related files first. Not the whole project — just the relevant context.

If I’m asking Copilot to write a new API endpoint:

I open the router file to show routing patterns
I open the model file to show the database schema
I open one existing endpoint that’s similar to what I want
I open the test file for that endpoint

Then I write my prompt in the new file.

The difference is night and day. Copilot stops guessing and starts *matching*.

Pro tip: Close irrelevant tabs first. If you have 30 tabs open, the AI’s context window fills up with noise. We tell our juniors in Ho Chi Minh City: “Before prompting, close everything except 4 files max. Context is a scarce resource — spend it wisely.”

Level 3: The Project Map (Your Secret Weapon)

This is the level most teams skip entirely. And it’s the most impactful.

Create a project overview document that describes:

Your architecture (monolith? microservices? event-driven?)
Key directories and what they contain
Naming conventions (snake_case? camelCase? PascalCase?)
Database schema overview
Key dependencies and versions
Testing framework and conventions

We call this the `CONTEXT.md` file and we keep it in the project root. Every AI tool can reference it.

Example snippet from a real project:


## Project: Fintech Payment Service

## Architecture
- Clean architecture with 3 layers: domain, application, infrastructure
- Domain layer has NO external dependencies

## Naming
- Interfaces: IPrefix (e.g., IPaymentGateway)
- Implementations: ClassName + Impl
- Test files: {ClassName}Test.php

## DB Schema
- MySQL 8.0
- All tables use InnoDB
- Primary keys: BIGINT UNSIGNED AUTO_INCREMENT
- Timestamps: created_at, updated_at (snake_case)
- Soft deletes: deleted_at (DATETIME NULL)

## Key Constraints
- We support 3 currencies only: USD, EUR, GBP
- All monetary values stored as BIGINT (cents)
- Transaction IDs follow format: TXN-{timestamp}-{uuid_short}

When we onboard a new developer from our ECOA AI team, they read this file first. Then they add it to the AI tool’s context. The AI instantly produces code that matches our architecture. No more “why is this using raw SQL when we use an ORM?” nonsense.

Want to test this? Next time you use an AI coding tool, paste your `CONTEXT.md` at the start of the conversation. Watch the output quality jump.

Level 4: The Live Runtime (Advanced)

This one’s for the power users.

Some AI coding tools can now access your actual running code. Cursor’s “composer” mode can read your terminal output. Claude Code can execute commands. Codex CLI can inspect your environment.

We abuse this mercilessly.

Before generating code, we:

Run the test suite and paste failures into the context
Show type errors from mypy or TypeScript strict mode
Include linter output from ruff or ESLint
Show actual data samples from the database

Here’s a real interaction I had last week with Claude Code:


Me: "Generate the migration to add a `refund_policy` column to the `orders` table."

Claude Code: "Before I write that, let me check your current schema..."
*Runs: DESCRIBE orders;*
*Shows current columns, types, indexes*

Claude Code: "I see you have an ENUM for `order_status` with values 'pending', 'confirmed', 'shipped', 'delivered'. The refund policy should probably be added to a separate `refund_requests` table instead. Here's why..."

It caught my mistake *before* I made it. Because it had live context.

Honestly, this is where AI coding tools go from “fancy autocomplete” to “actual pair programmer.” But you have to give them the runtime context. They can’t invent what they can’t see.

The Exact Workflow We Use at ECOA AI

Let me give you the concrete workflow our team in Vietnam follows every day. It’s not complicated. But it works.

Start with CONTEXT.md — Paste it into the AI conversation or reference it in your `.cursorrules` file
Open 3-4 relevant files — Show the AI the patterns it needs to match
Write a specific prompt — Include file paths, type names, and constraints
Run the generated code immediately — Don’t review it first. Run it. See if it compiles, passes tests
Feed errors back — Copy the error output into the AI and say “fix this”
Commit only after 2 successful rounds — Never commit AI output on the first try

One more rhetorical question: How many of you have accepted AI-generated code, run it, seen it fail, and then *manually fixed it* instead of feeding the error back? That’s lost learning. The AI won’t