Context Injection and AI Agent Management: How Not to Kill Your Architecture During Change Requests

The rise of AI assistants in IDEs has completely rewritten the rules for greenfield development. Writing boilerplate code, defining models, or generating CRUD operations is now a matter of moments. However, once we move into enterprise environments filled with proprietary frameworks, obscure dependencies, and constant iterations on business logic, generative models hit their limits.

Context / TL;DRThe biggest problem with current AI-assisted development isn't the cognitive capacity of LLMs, but rather context management and so-called "Day-2 operations." If you generate a system using SpecDD (Specification-Driven Development) tools, you get the code, tests, and drafted tasks. However, any subsequent change—typically adding a new field to a domain object—instantly breaks the synchronization of the entire tree. At the same time, models are shown to hallucinate massively when dealing with internal libraries for which no public training data exists.

The way out isn't burning tokens on more expensive models with giant context windows, but pragmatically constraining AI agents and implementing explicit Context Injection directly into the workspace.

Deep Dive: Strategies for Sustainable AI Development

1. Hardcore Context Injection for Proprietary CodeAn AI assistant (whether in Cursor or GitHub Copilot) cannot guess exactly what your corporate logging library or custom OIDC integration looks like. Attempts to create semantic RAG databases over a company wiki often yield inaccurate results with significant latency.

The most reliable and cheapest intervention is manual workspace preparation. Clone the source code of the required internal libraries (strictly tied to the correct Git tag) as separate folders directly into your local development environment in the IDE. If relevant, include shared CI/CD templates. This provides the assistant with raw definitions without losing semantics. Models stop inventing non-existent methods and instead hook into the real API contracts of your utilities.

2. Decomposition and Parallel RefactoringInstead of forcing an orchestrator to re-evaluate the entire project every time business requirements change, a much more stable approach is to use a single shared source of truth. Defining architectural guardrails in rules.md files at the repository root is becoming common practice.

When modifications (Change Requests) are needed, it is more efficient to deploy several separate micro-agents. One agent updates DTO objects, while another fixes tests in parallel. The developer thus reassumes orchestration, and working with AI feels more like an asynchronous code review of someone else's Pull Requests than traditional coding.

3. Legacy Boundaries: Terminal vs. Black BoxDeploying AI on systems decades old reveals a clear limit to machine learning capabilities. If you have standard source code (e.g., COBOL or older RPG) available via a terminal plugin directly from AS/400, agents can reliably detect dead code, suggest memory optimizations, and replace old constructs with modern patterns.

However, the situation is entirely different for low-code generators and prehistoric CASE tools like CA 2E (Synon). These systems function as a semantic black box. There is no direct text-based source code for the model to latch onto. Any attempt at reverse engineering or training custom models over the visual abstractions of these tools immediately turns into an absurd FinOps overhead.

Trade-offs: Compromises and Risks of the Approach

• Cloned Dependency Sync: If you clone internal libraries for Context Injection, you risk forgetting to update them. Once the central repository moves forward, your AI will stubbornly generate deprecated code based on the old local copy.
• Hidden Costs of Constant Prompting: Occasionally getting an agent stuck in a dead end leads developers to engage in lengthy chat explanations. The time spent engineering the "perfect prompt" often exceeds the time it would take a senior developer to write the class by hand.
• Blurring of Responsibility: While using parallel agents speeds up refactoring, it worsens the traceability of decisions. AI tools will willingly and rapidly replicate technical debt if given the space.

Code itself is gradually losing value; maintaining domain boundaries and strict contracts is becoming key. Even the most powerful AI model requires the guardrails of a clearly defined architecture; otherwise, it merely automates the path into a dead end.

‍