Battle for Context: How We Implemented AI Coding in an Enterprise Project

425 commits, 672 files, 1.5 billion tokens — and one form. A story about learning to work with AI in a real product.

Introduction: A Task Nobody Had Solved

Imagine this: you need to give an analyst the ability to code. Not "write a prompt to ChatGPT," but actually make changes to an Enterprise product with a three-year history and a million lines of code.

The developer isn't sitting next to them dictating every line. They set up the environment, control quality, and only intervene when something goes wrong.

Sounds like science fiction? We thought so too. Until we tried.

Why This Is Harder Than It Seems

When a programmer uses an AI assistant, they control every step. They see what's happening "under the hood." They notice oddities in the code immediately.

With an analyst, everything is different. They see the result: "the form appeared" or "the form doesn't work." But code quality, architectural decisions, potential bugs — all of this remains behind the scenes.

We decided to create a system that compensates for this blindness. A system where AI can't "cause trouble" even if it really wants to.

Tool Selection: Why Cursor

We tried several options: GitHub Copilot, Claude Code, various API wrappers. We settled on Cursor for several reasons:

Multi-model Support

Cursor allows using different models for different tasks:

flowchart LR

    A[Task] --> B{Type?}

    B -->|Planning| C[Claude Opus 4.5]

    B -->|Implementation| D[Gemini 3 Flash]

    C --> E[200K tokens]

    D --> F[1M tokens]

• 
  Claude Opus 4.5 for architectural planning (smart but "expensive" in tokens)


• 
  Gemini 3 Flash for implementation (fast, cheap, and most importantly — 1 million tokens of context)

MCP Integration

Model Context Protocol — a way to connect external tools to AI:

Flexible Rules

Cursor allows creating .mdc files with rules that automatically load depending on context. Working on a React component — get React rules. Writing a script — get Node.js rules.

Security Requirements: Working Locally

Our security team set strict requirements: no access to the corporate network during development. No cloning of the production database.

This meant we needed a full mocking system. We built it on MSW (Mock Service Worker):

flowchart TD

    A[Frontend App] --> B[MSW Interceptor]

    B --> C{Request Type}

    C -->|API Call| D[Mock Handlers]

    C -->|Static| E[Pass Through]

    D --> F[Fake Data Generators]

    F --> G[@faker-js]

    D --> H[Response]

• 50+ handlers for all API endpoints


• Realistic data generators using @faker-js


• Full business logic emulation

Quality Gates: The Stricter, The Better

Here's the key insight we took from this project: AI needs strict constraints.

Without them, it starts to "create." Sees outdated code — refactors. Notices a potential vulnerability — "fixes" it. Finds a style mismatch — reformats.

Sounds useful? In practice, it means a simple task "add a field to a form" turns into a PR with 100,000 lines.

Our Quality Gates Pipeline

flowchart TD

    A[Commit] --> B[commitlint]

    B -->|Pass| C[ESLint]

    B -->|Fail| X[❌ Rejected]

    C -->|Pass| D[TypeScript]

    C -->|Fail| X

    D -->|Pass| E[Vitest]

    D -->|Fail| X

    E -->|Pass| F[Secretlint]

    E -->|Fail| X

    F -->|Pass| G[✅ Push]

    F -->|Fail| X

1. 
   commitlint — checks commit message format


2. 
   ESLint — strict TypeScript rules, import order


3. 
   TypeScript — strict mode, no any
   


4. 
   Vitest — unit tests must pass


5. 
   Secretlint — checks for accidentally committed secrets

AI cannot bypass these checks. If the code doesn't pass — the commit won't happen.

The Context Problem: The Main Pain Point

Now for the most important part. The thing that almost killed the entire project.

Context.

When you work with a simple 10-file application, AI handles it perfectly. The entire project fits in its "memory." It sees the complete picture.

But what happens when the project is a million lines of code accumulated over three years? AI sees only a fragment. The tip of the iceberg.

Here are real numbers:

After 30 minutes, AI starts to "forget." Repeats mistakes. Proposes solutions you've already rejected. Breaks what was just working.

Four Rakes We Stepped On

Rake #1: "It Worked on a Simple Example"

We ran an experiment. Asked an analyst to create a registration form on a clean boilerplate — minimal React project, reference rules, 10 files.

Result: 15 minutes, everything works perfectly.

The same task on a real project: nothing works. AI gets confused by dependencies, uses outdated patterns, conflicts with existing code.

Lesson: It's not about AI being "dumb." It's about lack of context.

Rake #2: AI "Fixed" the Entire Project

This was a catastrophe. We set a task: add one feature. AI completed it. And also:

• Replaced all any with specific types


• "Fixed" potential vulnerabilities


• Reformatted half the project


• Updated outdated dependencies

Result: PR with 100,000+ lines. GitLab physically couldn't display the diff. We spent two weeks figuring it out. The product was broken.

Lesson: You need rules that explicitly limit the scope of AI work.

Rake #3: Token Limitation

We didn't immediately understand that most models have context limited to 100-200K tokens. For an Enterprise project, this is enough for 3-5 iterations.

Then AI starts "forgetting" the beginning of the conversation. Proposes solutions you've already rejected. Repeats mistakes.

Lesson: For Enterprise, you need models with at least 1 million tokens of context.

Rake #4: Auto-Mode Is a Trap

Cursor can automatically select a model. Sounds convenient? In practice, it often chooses a "cheap" model with a small context.

We wasted a lot of time before we understood: for serious work, you need to manually select the model.

Lesson: Opus for planning, Gemini Flash for implementation. No auto-mode.

How We Solved the Context Problem

After all the rakes, we developed a system. It's not perfect, but it works.

Two-Level Task Tracking

flowchart TD

    subgraph Jira [Jira - Team Level]

        J1[VP-385: Add Registration Form]

    end



    subgraph Beads [Beads - Atomic Level]

        B1[bd-1: Review UserForm.tsx]

        B2[bd-2: Add email field]

        B3[bd-3: Write test]

    end



    J1 --> B1

    B1 --> B2

    B2 --> B3

Jira — top level. Tasks for the team: "VP-385: Add registration form."

Beads — atomic level. Tasks for AI:

• "bd-1: Review file UserForm.tsx"


• "bd-2: Add email field"


• "bd-3: Write test"

Beads is stored locally, syncs with git. AI always knows what step it stopped at.

Memory Bank

This is "external memory" for AI. We store:

• Current context (what we're working on)


• Progress (what's already done)


• Research (what we found out)


• Archives of completed tasks

When AI "forgets" context, it can access Memory Bank and restore understanding.

Model Combination

We split work between two models:

Claude Opus 4.5 — architect. Creates plans, writes specs, conducts reviews. It has "only" 200K tokens, but for planning that's enough.

Gemini 3 Flash — executor. Implements code according to plan. 1 million tokens of context — can work for hours without losing the thread.

flowchart LR

    A[Task] --> B[Opus: Planning]

    B --> C[Opus: Spec/TZ]

    C --> D[Gemini: Implementation]

    D --> E[Opus: Review]

    E -->|Issues| D

    E -->|OK| F[Done]

Cycle: Opus plans → Gemini implements → Opus reviews.

Project Statistics

Over 1.5 weeks of work on the feature/msw-mocks branch:

What was implemented:

• ✅ Full MSW mocking system (50+ handlers)


• ✅ Schedule Timeline with Gantt chart


• ✅ Quality Gates (ESLint, TypeScript, Husky)


• ✅ Beads integration


• ✅ 200+ unit tests

Comparison: Traditional Development vs AI

Honest comparison:

Including infrastructure setup, learning, and all the rakes.

Important nuance: the first time is expensive. We spent 1.5 weeks understanding how this works. Setting up rules. Stepping on rakes.

The second feature will take 10 times less time.

Role Evolution

AI coding changes team roles:

Analyst no longer just "writes specs." They become a junior developer. Must understand SQL, work with Git, read code at a basic level.

Developer no longer just "writes code." They become an architect. Design patterns are more important than knowing a specific language. Java, Node.js, Python, Go — AI will write in any.

Developers become universal specialists. Can work with any stack because they understand principles, not syntax.

Conclusions and Recommendations

What Works

1. 
   Opus + Gemini combination — smart architect + fast executor


2. 
   Quality Gates — the stricter the constraints, the better the result


3. 
   Two-level tracking — Jira for team, Beads for AI


4. 
   Memory Bank — external memory to not lose context


5. 
   Data mocking — complete development autonomy

What Doesn't Work

1. Auto-mode for model selection


2. AI without constraints (will fix the entire project)


3. Models with context less than 1M tokens for Enterprise

Checklist for Getting Started

• [ ] Set up local development environment


• [ ] Implement Quality Gates (ESLint, TypeScript strict)


• [ ] Create a data mocking system


• [ ] Connect MCP (Jira, Context7, Memory Bank)


• [ ] Train analyst on Git and SQL


• [ ] Choose the right models (Opus + Gemini)

Conclusion

The battle for context hasn't been won yet. Technologies evolve, context windows grow, but the problem remains.

Enterprise projects are too large for AI to "see" them in full. This means we need systems that help AI maintain focus. Task trackers, Memory Bank, Quality Gates.

We spent 1.5 billion tokens to understand this. I hope our experience helps you spend less.

What's your experience with AI coding in large projects? Share in the comments!

About the Author

Working on UI with React. Tools: Cursor IDE, Claude Opus 4.5, Gemini 3 Flash.

ai #cursor #enterprise #programming #devjournal