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

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.