AI Bounded-Context Development aka `AB-CD`

Viacheslav Fesenko — Thu, 23 Jul 2026 14:15:31 +0000

Maximize developer control and AI execution on complex tasks.

My Path

When I first started working with AI agents, I was impressed by their ability to create a RESTful proof-of-concept application faster than a developer could describe it. The architecture of such an application is rarely something to showcase, but it is usually good enough for a PoC.

Some of these PoCs contain functions hundreds of lines long, with dozens of nested loops, conditions, and recursive calls. They do not scale, but they work—sometimes surprisingly reliably.

This means that an agent can create a working application architecture, while an LLM can write working low-level code.

That made it difficult for me to understand why an application created well from scratch would begin to degrade after relatively small agent-driven changes. And the more such changes accumulated, the more the codebase deteriorated.

I used to see this as a limitation of agents. Over time, however, I noticed that an agent can make a good change when the developer explains precisely enough what that change should look like.

So the question is not whether an agent can complete the task, but what price the developer must pay to specify it correctly.

What Is the Cost?

The main problem with autonomous development is not that an agent writes poor code. The problem begins earlier: the developer delegates not only implementation, but also the choice of solution, and then tries to review the result without having an expected solution of their own.

To retain control, the developer must first understand how the task should be solved—independently or with AI—and then explain what to change, what to preserve, and how the result should be evaluated.

Without an expected solution, they can only judge whether the result looks plausible, passes tests, and contains no obvious problems. That is not enough to determine whether the architecture, dependencies, and change points were chosen correctly.

You cannot delegate the engineering decision to AI and then expect to regain control during code review.

If the result contains serious problems, the developer faces a choice: continue fixing it or implement the task again from scratch.

Each iteration makes review harder because new changes must be evaluated against both the original codebase and the agent’s previous modifications. Abandoning the result also becomes increasingly difficult: after investing time in prompting, generation, and review, each new local problem appears cheaper to fix than the whole result is to discard.

Sometimes the solution can be recovered. In other cases, after many iterations, the developer still implements it manually.

This is why, for complex tasks, developers often choose the safe bet: implementing the solution themselves. Not because the agent is incapable of completing the task, but because without a predefined solution, the cost of working with it remains unknown.

Yes, writing code manually like cave people is slow and painful. But the developer understands the chosen solution, controls the changes, and knows how they fit into the codebase.

As a result, the choice often comes down to two options:

delegate both implementation and solution selection to the agent, accepting the risk of an expensive chain of iterations with no guaranteed result;
define the solution independently and implement it manually, preserving control and predictability.

By independent implementation, I do not mean only fully manual code changes. It may also include using an LLM to implement low-level details.

Between these two options, there is room for another approach: the developer defines the solution and the boundaries of the work, but delegates a much larger share of the actual implementation to AI than isolated functions, tests, or documentation.

I call this approach AI Bounded-Context Development, or AB-CD.

`AI Bounded-Context Development`

AB-CD is intended for complex engineering tasks in complex codebases. The key trigger is the suspicion that implementing the task manually may be faster than describing every do and don’t to an agent.

There is no universal complexity threshold. Additional signs include a diff too broad to review confidently, unexpected change points, or several similar architectural patterns from which AI would have to choose.

AB-CD does not necessarily pay off for small local changes, disposable PoCs, well-isolated greenfield modules, or tasks where the developer intentionally wants several alternative solutions. It is useful when the cost of choosing the wrong direction is higher than the cost of defining the boundary in advance.

Formal Definition

AI Bounded-Context Development is an AI development workflow in which the developer explicitly defines and evolves the information boundary available to the LLM for each implementation step.

Its core principle can be stated as follows:

Provide the LLM with exactly the information required for the current implementation step. No less. No more.

In AB-CD, the developer defines the expected solution and expresses it through an information boundary. AI implements one predefined step within that boundary, increasing AI Execution without delegating the architectural direction.

In the AI-as-a-Pie classification, the role of AI is evaluated along two independent axes: AI Decision Autonomy and AI Execution. The quadrant is determined by who holds the controlling interest in each dimension—who primarily chooses how the goal will be achieved, and who performs most of the actions required to achieve it.

In AB-CD, the developer investigates the task, chooses the solution, divides it into steps, and defines each step’s information boundary. AI implements a predefined part of that solution.

This places AB-CD in the first quadrant of AI-as-a-Pie: low AI Decision Autonomy with high AI Execution. Unlike AI-as-a-Helper, AI performs a substantial share of the implementation; unlike agentic approaches, it does not choose the path.

Context Contract

The primary artifact of AB-CD is the Context Contract—an explicit description of the current step’s role, the information available to the model, and the implementation constraints.

It may include:

Step Role — which part of the expected solution the current step implements and what result it must leave behind;
Editable Scope — listings that the LLM is allowed to modify;
Read-only Scope — listings required to understand the task but not to modify, including auto-generated files;
Excluded Scope — relevant listings intentionally excluded from the context because they must not influence the current step’s solution;
Project Constraints — architectural constraints, code style, local project rules, and special instructions.

A Context Contract is not merely a list of files. It captures the role of the step within a previously chosen solution and limits the information on which the LLM may base its implementation choices.

For example, a task such as “add a new filter end to end” affects more than the form itself. The filter value passes through shared state, appears in chips, is converted into API parameters, and is applied in the backend filtering pipeline. In addition, the frontend contract may be generated from OpenAPI and must not be edited manually.

Before implementation begins, the developer investigates this flow and defines the expected solution: what state type the filter needs, how null and empty values should be interpreted, where API mapping occurs, whether the backend should reuse an existing predicate or use a separate query service, and whether a database change is required.

The task is then divided into implementation steps. For the frontend-state step, the Editable Scope may include the filter component, UI model, and facade. A broadcaster hub may be provided as Read-only Scope because it explains the existing boundary but does not need to change. Generated API models may also be included only to clarify the current contract, with an explicit prohibition against editing them.

A similar legacy filter may be deliberately placed in the Excluded Scope if the developer has already decided not to reproduce its architecture. The LLM does not receive the entire chain at once or the right to choose the path independently. It receives only the information required to implement one specific step within a predefined solution.

After review, the boundary changes: for the backend step, the Editable Scope may include the request contract, filtering pipeline, and tests, while the frontend files are no longer necessary. If the LLM proposes an unexpected dependency or a change outside the anticipated locations, the developer does not need to investigate the architecture from scratch. Instead, they verify whether the Context Contract is incorrect or the model has stepped outside the role assigned to the current step.

In this way, one end-to-end task is implemented not through a single broad prompt, but through a sequence of controlled boundaries, each expressing a distinct part of an already chosen engineering solution.

A Context Contract does not have to exist as a separate document. What matters is that the boundary is explicitly defined by the developer and can evolve together with their understanding of the task.

The Excluded Scope does not necessarily need to be enumerated in full either. The developer may require the LLM to rely only on the provided files and to explain any missing context instead of making assumptions or producing a partial solution.

The exact form of the contract depends on the tool and the developer’s preferences. The controlled boundary is mandatory; its syntax is not.

The Key Idea Behind `AB-CD`

AB-CD does not introduce a new technical mechanism. It formalizes context-management practices into a workflow where the context is derived from a predefined engineering solution and used as a constraint on AI.

The focus is not only on which listings enter the Editable Scope and Read-only Scope, but also on which relevant parts of the system are deliberately excluded.

Excluded Scope is as much an engineering decision as Editable Scope.

AB-CD is not merely about reducing context size. It controls the space of admissible solutions by controlling the information that may influence implementation.

AB-CD limits not the number of files provided, but the set of solutions that AI can justify at the current step.

Additional modules, similar implementations, and alternative patterns give the model more plausible paths, not all of which match the developer’s intent. My practical hypothesis is that this is why excessively broad context often produces unexpected change points and gradual scope expansion. This is an observation, not a universal law.

An agent that does not know the final solution must either collect broad context to avoid missing dependencies or minimize it and risk excluding something important. Both strategies can work, but choosing the context requires an understanding of the expected solution.

Once the developer has that understanding, the boundary becomes an architectural filter: the model receives only the patterns that should influence the current step. Review also changes—from evaluating an independently chosen AI solution to checking whether implementation conforms to the predefined role of the step.

Unexpected dependencies then become signals that either the contract is incomplete or the model has stepped outside it. This allows the developer to use AI for substantial low-level implementation while preserving control over the intended solution.

Main Flow

The basic AB-CD cycle looks like this:

Discover

The developer investigates the task and defines the expected solution.

↓

Define Boundary

A Context Contract is created for the current step based on the expected solution.

↓

Implement

The LLM receives the bounded context and implements a specific part of the solution.

↓

Review

The developer compares the changes with the expected solution.

↓

Refine Boundary

If the result is incomplete or incorrect, the developer refines the instruction and the information boundary.

↓

Next Step

Once the step is complete, the cycle repeats for the next part of the task.

Why `AB-CD` Is Not an Extra Mile

Defining the information boundary may look like additional work, but a Context Contract does not create a new analysis stage. It turns an already chosen engineering solution into an executable constraint for AI.

By the time implementation begins, the developer should already know which parts must change, which modules are needed only for understanding, and which constraints must be preserved. Capturing that knowledge in a boundary moves uncertainty from the expensive post-generation phase into the cheaper step-design phase.

An error found while defining the boundary usually requires adjusting the context or splitting the step. The same error found after broad generation may require analyzing the diff, reverting dependencies, and repeating the review.

The primary engineering responsibility shifts from writing prompts to defining the model’s knowledge boundary for each implementation step.

This is what distinguishes AB-CD from simply “providing the necessary files”: the developer first restricts the solution space and only then delegates implementation within it.

A Practical Guideline for Context Size

Excluding irrelevant files provides another advantage: both the context and the resulting diff remain reviewable. Token savings are more of a side effect.

In my experience, the most predictable results occur when a single implementation step fits within roughly a couple of thousand lines of input context, give or take, while the expected amount of change remains comparable or smaller.

This is not a universal threshold beyond which LLM quality magically drops. For me, it is a practical guideline: the step remains coherent enough for the model, while the result remains compact enough for confident review.

The exact limit depends on the language, code density, relationship complexity, and the capabilities of the model. What matters is not the context size itself, but whether the developer can keep track of the role each provided fragment plays in the expected solution.

Why Is an LLM Preferable to an Agent for `AB-CD`?

For AB-CD, the tool matters less than the guarantee that the executor cannot silently expand the defined boundary.

An agent may discover additional dependencies, open neighboring modules, or pass more files to the underlying LLM. That is useful in ordinary agentic work, but in AB-CD it shifts control over context composition back to the agent.

The preferred executor is therefore one that cannot move beyond the supplied context—most often, an LLM without direct codebase access. An agent is still suitable if every context expansion requires explicit developer approval.

Agents may also help during investigation, dependency discovery, and context preparation. The expected solution and final context composition for each implementation step remain the developer’s responsibility.

How to Use `AB-CD` in Practice

AB-CD does not require a dedicated tool. The executor simply must receive only the context defined for the current step.

A developer can use an agent in a limited-scope mode, provided it cannot read beyond the supplied files without approval and the complete context remains visible. When stricter control is needed, the context can be passed directly to an LLM.

If a step affects one or two files and does not require many project-specific instructions, it is enough to copy the relevant listings, add the constraints, and send everything to a regular LLM chat—just as developers did before agents.

That is technically sufficient. Across several implementation steps, however, manually assembling file sets, repeating project instructions, and applying changes back in the IDE becomes distracting routine.

To automate this mechanical part of the process, I created LLM Copypaster.

The developer selects files and folders in VS Code; the extension concatenates them with project instructions and copies the prompt to the clipboard. A structured response can then be applied back to the project.

Copypaster is a deterministic algorithm: no AI magic, but complete predictability and transparency when assembling context. It is free and open source.

In any case, AB-CD does not depend on Copypaster or on any particular agent. They merely provide different ways to preserve an information boundary defined by the developer.

Summary

AB-CD begins with an expected engineering solution, which the developer divides into implementation steps and expresses through a sequence of controlled information boundaries.

Its goal is to delegate as much of the direct implementation as possible to AI while keeping the choice of architectural direction and control over the final solution in the developer’s hands.

The developer defines the solution and its information boundaries. AI executes within them.

DEV Community: Viacheslav Fesenko