DEV Community: Viacheslav Fesenko

Agentic AI vs AB-CD vs AI-as-a-Helper in Practice

Viacheslav Fesenko — Thu, 06 Aug 2026 16:40:48 +0000

More routine and less developer growth should mean less developer effort.

Intro

In the previous article, I introduced AI Bounded-Context Development, or AB-CD: a workflow in which the developer determines the expected solution, controls the information boundary for each implementation step, and delegates substantial low-level implementation to an LLM.

But AB-CD is not the right workflow for every task.

Sometimes the solution itself still needs to be discovered. In other cases, both the solution and the implementation procedure are stable enough to delegate much more broadly.

This time, I want to take one real feature request and show how its engineering shape changes the choice between AI-as-a-Helper, AB-CD, and Agentic AI.

The task sounds simple:

Add a new filter end to end.

But that sentence is not enough to choose an AI workflow.

Is the filter almost identical to an existing one?

Does it introduce a new interaction pattern, data type, or database requirement?

Or does the project have no filtering infrastructure at all?

These may all be described as “adding a filter,” but they are fundamentally different engineering tasks.

Start with the task, not with your favorite AI tool.

The code samples below are reduced and anonymized. The goal is not to present this architecture as universally correct, but to show how knowledge of a real codebase affects the workflow decision.

The Project and the Task

The project is an educational startup. The relevant code belongs to a Filter-Sort-Paginate module whose primary entity is a user-created summary.

Tech stack: ASP.NET Web API, C#, OpenAPI, Angular, TypeScript, RxJS, and ng-open-api.

The panel on the left contains filtering controls.

The area on the right contains selected-filter chips and the filtered summaries.

Filter changes are broadcast through shared event hubs and consumed by several independent parts of the UI. Adding a filter is therefore not a local form change.

At a high level, the data flow looks like this:

Filter control
→ shared filter state
→ chips synchronization
→ API request contract
→ backend filtering pipeline

The task is to add a new filter through that entire flow.

I am deliberately not specifying which filter yet because that missing detail determines the workflow.

Screening the Task Before Choosing a Workflow

Before choosing a workflow, the developer needs enough understanding to answer four questions:

Is the expected solution already known?
Is the implementation path stable?
Can the information boundary be defined confidently?
Does a reusable procedure already exist?

In this project, the initial screening took approximately five to ten minutes because I already knew the codebase well.

The Angular filter component both restores external state and publishes user changes:

export class SumsFilterComponent implements OnInit {
  private _reactOnInputTechDataChanged() {
    this._sumsFilterBhub.selectedDataInputChanged
      .react()
      .subscribe((selectedDataInput) => {
        this._updateForm(selectedDataInput);
      });
  }

  private _reactOnFormValueChange() {
    this.form.valueChanges.subscribe((formValue) => {
      this._sumsFilterBhub.selectedDataOutputChanged.trigger(
        formValue as SumsFilterSelectedData,
      );
    });
  }
}

The new filter must participate in both directions. Adding a control to the template alone would leave the state flow incomplete.

The same state is also consumed by the chips module, transformed into generated API request parameters, and finally applied by the backend filtering pipeline:

if (fpsParams.FilterStarred.HasValue)
{
    query = query.Where(
        summary =>
            fpsParams.FilterStarred.Value
                ? summary.IsStarred
                : !summary.IsStarred
    );
}

Generated frontend API contracts should not be edited manually.

Whether the new filter belongs directly in the existing backend method, requires a dedicated query service, or needs a database change depends on its semantics.

At this point, the implementation path through the application is visible. The missing question is what kind of filter we are adding.

Three Different Tasks Hiding Behind One Feature Request

Case 1: Add a Filter by Analogy

Suppose the requirement is:

Add a boolean filter by following the existing starred filter.

The expected behavior, affected layers, state shape, chips lifecycle, API mapping, backend predicate, and likely test structure are already known.

This is primarily a pattern-replication task.

For the first pass, I would use AB-CD to make the implicit procedure explicit and validate it against a real change.

Once the procedure is stable and written down, later repetitions become strong candidates for Agentic AI.

Known procedure in the developer’s head
→ express it through AB-CD
→ validate it on a real task
→ encode reusable guidance
→ delegate later repetitions to Agentic AI

A task being repeatable does not automatically make it agentic. The procedure must also be explicit, stable, and verifiable.

AI-as-a-Helper would preserve control, but it would reduce a predictable end-to-end change to isolated fragments.

Case 2: Add a New Type of Filter

Now suppose the filter is not analogous to starred.

It may require:

a new control or UX;
unfamiliar state semantics;
a range, hierarchy, or multi-value shape;
a different API contract;
a database field or relationship;
a dedicated backend query.

The application already has a filtering architecture, and the affected layers are known.

What remains uncertain is the correct behavior inside that architecture.

For this case, I would use AB-CD as the primary implementation workflow.

AI-as-a-Helper would delegate too little because much of the integration path is already understood.

Agentic AI would delegate too much because important engineering decisions still cannot be encoded as a stable procedure.

A concrete loop might look like this:

1. The developer decides that the filter is a nullable date range.
2. The developer defines its form, chips, API, and backend semantics.
3. A Context Contract is created for the frontend-state step.
4. The LLM implements the step inside that boundary.
5. The developer reviews the result and clarifies empty-value behavior.
6. The boundary changes for the backend step.
7. The LLM implements the predicate and tests.
8. The API client is regenerated and the final flow is reviewed.

A single feature does not need to use one workflow from beginning to end.

AI-as-a-Helper:
investigate unfamiliar UX or architectural alternatives

AB-CD:
implement the selected solution through controlled steps

Agentic AI:
apply an established procedure to routine parts

Workflow ownership can change between phases of the same task.

Case 3: Build Filtering in a Vacuum

Now suppose the project has no filtering architecture.

The task is no longer “add one more filter.”

The real task is:

Design and implement a filtering pipeline that can support multiple filter shapes without becoming unmaintainable.

What remains uncertain includes:

where filtering state should live;
how controls communicate with the rest of the UI;
how filters are serialized;
how predicates compose;
how pagination and sorting interact with filtering;
how future filters extend the design.

At this stage, the most important work is not implementation.

It is determining the correct solution.

Here, AI-as-a-Helper should be the primary reasoning workflow. AI may research alternatives, trace dependencies, or generate exploratory code, while the developer retains ownership of the architecture.

The workflow is defined not by how much code AI produces, but by who owns the decision loop.

AB-CD would be premature because there is not yet a sufficiently understood solution from which to derive stable boundaries.

Agentic AI would be risky because broad autonomous implementation could turn one plausible architecture into an accidental commitment.

Agents may still help with codebase exploration, dependency tracing, and disposable proofs of concept. Their output remains evidence for the decision, not a substitute for it.

Once the architecture becomes understood, the workflow can change:

AI-as-a-Helper
→ determine the architecture and resolve high uncertainty

AB-CD
→ implement the understood solution through controlled boundaries

Agentic AI
→ repeat a stable, explicit, and validated procedure

Not every task needs to pass through all three stages.

The Developer Changes the Equation

The task is not the only variable.

The same request may deserve a different workflow depending on who performs it.

I know this codebase well because I am its architect. I can quickly recognize which path is intentional, which abstractions should remain untouched, and whether an AI-generated result is merely plausible or actually correct.

On a less familiar project, I would delegate less implementation ownership.

AB-CD does not depend on job title. It depends on whether the developer can:

recognize the important engineering decisions;
define the expected solution;
identify the relevant information boundary;
decompose the implementation;
critically review the result.

Learning value is also relative.

A filtering task may be routine for the project architect and valuable design practice for a developer encountering the problem for the first time.

Delegate more when the implementation path is understood, the result is reliably verifiable, and the developer’s learning value is low.

The goal is not maximum AI autonomy.

The goal is to spend developer effort where it creates the most value.

Choosing the Workflow

Evaluation criterion	AI-as-a-Helper	AB-CD	Agentic AI
Solution uncertainty	High — the solution still needs to be discovered	Moderate — the expected solution is mostly understood	Low — the result and path are largely known
Procedure stability	Low — no proven implementation path exists	Partial — the path can be defined step by step	High — the task follows a repeatable procedure
Validation	Human judgment is primary	Human review compares implementation with an expected solution	Strong automated or predictable validation is usually required
Repeatability	Low	Low to moderate	High
Developer learning value	High	Moderate	Low

This matrix is not a scoring system.

The criteria may point in different directions.

A repetitive task without clear validation may still be unsafe for an agent.

A high-cost change may still use Agentic AI if it runs in a sandbox and is covered by strong validation.

A well-understood one-off task may still use AB-CD even if there is no reason to formalize it into a reusable agentic procedure.

The point is not to memorize the table, but to understand why implementation ownership shifts.

Summary

“Add a filter” is not one engineering task.

When the solution itself is unknown, the developer should retain ownership of the reasoning loop through AI-as-a-Helper.

When the expected solution is understood but deliberate adaptation remains, AB-CD becomes the natural implementation workflow.

When the procedure is stable, explicit, repeatable, and strongly validated, Agentic AI becomes increasingly rational.

A feature may move between these workflows as uncertainty decreases.

More routine and less developer growth should mean less developer effort.

AB-CD is most useful when the developer understands the expected solution, wants to preserve decision ownership, and can express that solution through controlled implementation steps and information boundaries.

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.

See next: Agentic AI vs AB-CD vs AI-as-a-Helper in Practice.

DEV Community: Viacheslav Fesenko

Agentic AI vs AB-CD vs AI-as-a-Helper in Practice

Intro

The Project and the Task

Screening the Task Before Choosing a Workflow

Three Different Tasks Hiding Behind One Feature Request

Case 1: Add a Filter by Analogy

Case 2: Add a New Type of Filter

Case 3: Build Filtering in a Vacuum

The Developer Changes the Equation

Choosing the Workflow

Summary

AI Bounded-Context Development aka `AB-CD`

My Path

What Is the Cost?

AI Bounded-Context Development

Formal Definition

Context Contract

The Key Idea Behind AB-CD

Main Flow

Why AB-CD Is Not an Extra Mile

A Practical Guideline for Context Size

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

How to Use AB-CD in Practice

Summary

`AI Bounded-Context Development`

The Key Idea Behind `AB-CD`

Why `AB-CD` Is Not an Extra Mile

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

How to Use `AB-CD` in Practice