The right evidence, asked at the wrong moment, also blocks

You can design a technically impeccable process and still bring it to a halt.

It won’t be for lack of information, and it won’t be because the agents fall short. Sometimes the opposite happens: we demand evidence that is valid, necessary and rigorous, and we simply ask for it too early, or we hand it to the wrong phase.

That is what we have been seeing while researching ALDC Graph. And an article published a few days ago on AWS Builder Center, about the anti-patterns of AI-DLC adoption, helped me put a name to the problem.

The debate was never speed versus rigor. What we need is a kind of rigor that helps us decide better and move faster at the same time.

Engineering workflow moving verified evidence from architecture to the correct implementation phase

AI-DLC does not mean adding AI to the current process

Atsushi Fukui’s article describes eight anti-patterns that keep showing up when organizations adopt AI-DLC: teams that leave the business owners out, projects that are too small or purely technical, organizations that keep design and implementation in separate silos, Scrum ceremonies that still dictate the pace, QA reviews that weigh too much, and release processes that take weeks.

They all grow from the same root: treating AI-DLC as a technology upgrade rather than a transformation of the development cycle itself.

We can generate code in minutes, but if a decision still waits several days, the whole system has not sped up. We have only moved the bottleneck.

What AI-DLC proposes is that AI orchestrates the full flow while people keep ownership of the decisions that matter. It also introduces an idea I find especially relevant: the depth of the process and of its validations should adapt to risk. Not every change deserves the same level of analysis, and not every piece of evidence has to be requested at the same moment.

The open implementation, AI-DLC Workflows 2.0, shows this tension well. It defines five phases, 33 stages and 14 agents, and at the same time it introduces different scopes and three depth levels: Minimal, Standard and Comprehensive. It is a broad process that tries to avoid rigidity through explicit adaptation, without throwing away structure.

This connects directly with what we are researching in ALDC Graph.

When a correct contract stops the process

Picture a medium-complexity requirement in Business Central whose solution relies on standard integration events. To protect the viability of the later implementation, the Architecture contract demands exact evidence of the selected AL declarations: signature, parameters, types, subtypes, order, use of var or temporary, and any other property that affects compilation.

The intention is sound. Nobody wants an architecture approved on the basis of an event that was imagined, incomplete or semantically wrong.

Now suppose the evidence available does not allow that exact demonstration without material human intervention. The process does what its contract tells it to do and stops. No Architecture package is approved or persisted. This is roughly what we observed in a controlled experiment with an ALDC Graph candidate that we were not allowed to tweak mid-run.

From a contractual point of view, the behavior is consistent. From the point of view of the development cycle, it exposes a problem: Architecture is absorbing detail that belongs to the technical specification.

Let me be clear: demanding evidence was never the problem. The problem was demanding all of it in that phase.

Architecture is not a technical specification brought forward

An architecture should set the direction of the solution, its boundaries, responsibilities, dependencies, risks and main decisions. In a Business Central development it should also check that the proposed extension points exist and that the strategy looks viable.

That does not mean it always has to close every AL declaration with compiler-level precision.

The technical specification carries a different responsibility. It turns the approved architecture into an implementable design: concrete objects, exact events, signatures, parameters, test contracts and expected behavior. Implementation then brings the evidence of compilation and execution. Finally, review validates quality, security and compliance.

A reasonable split could look like this:

Phase	Decision it protects	Usual evidence	What it should not absorb by default
Architecture	Direction, boundaries and viability of the solution	Existence and suitability of the extension point, dependencies and risks	Exhaustive detail of every AL signature
Technical specification	Concrete, implementable design	Object, event, signature, types, subtypes, order, `var`, `temporary` and required tests	Silently redefining the intent or the architecture
Implementation	Match between design and code	Compilation, tests and executable behavior	Resolving architectural decisions that were never approved
Review	Quality and readiness to integrate	Static analysis, BCQuality, test results and change summary	Rebuilding decisions or evidence that were never closed

I am not proposing to turn this table into another rigid rule. That is precisely what we need to avoid. Evidence belongs to the first phase where it becomes necessary for a safe decision, rather than to a phase fixed in advance.

When exact evidence does belong in Architecture

Reality has nuances.

Some architectural decisions depend on an exact property of the AL declaration. If the solution needs to modify a record through a var parameter, interrupt the flow with an IsHandled pattern, work with a temporary record or run at a specific point in the transaction, that information stops being an implementation detail.

In those cases Architecture must demand the exact declaration before approving the direction. If the property does not exist, the architecture may be unviable or may need a different pattern.

On the other hand, if Architecture only needs to confirm that a reasonable extension point exists, and the final choice between several equivalent events can be settled during the specification, stopping the whole process because every detail is not yet available would be over-engineering.

The right question is which decision becomes unsafe without that evidence, rather than whether we could gather more of it.

Adaptive depth, without weakened contracts

Here comes the most useful lesson from the AI-DLC article: depth should respond to risk and scope.

A local, reversible change that the compiler covers well may only need a light path. A medium functional evolution that relies on standard events needs to confirm its extension strategy in Architecture and close the exact declarations in the Technical Specification. A change to the posting process, a data migration or a feature with legal impact may justify exact evidence much earlier and more demanding human gates.

None of this means accepting partial evidence as if it were exact, or letting the architect invent a signature and delegate it without control. The alternative is to record an explicit evidence obligation, assign it an owner and place the gate before the moment when that evidence becomes indispensable.

That is very different from looking the other way.

A pending piece of evidence can coexist with a conditioned architecture as long as we know:

which claim still has to be proven;
which decision depends on it;
who has to resolve it;
in which phase it must be closed;
and which action stays blocked while it remains pending.

This is, in my view, one of the most powerful values of the Graph approach. The graph should not be there to pile up documents and relationships. It should let us connect decisions, claims, evidence, risks and responsibilities, and detect when a transition tries to move forward without the required proof.

What ALDC should learn from AI-DLC, and what it should not

AI-DLC and ALDC are not the same thing, and they do not need to become the same thing.

AI-DLC proposes a general transformation of the development cycle, the organization and the culture. ALDC is specialized in AL and Business Central development. Its differential value lies in the contracts of its agents, its domain knowledge, the separation of responsibilities, traceability, and the integration of mechanisms such as symbols, structural evidence, compilation, tests and BCQuality.

The lesson has nothing to do with renaming agents or copying the AWS phases. It comes from noticing a shared signal: when we accelerate one part of the cycle, the gates, the responsibilities and the decision rhythms have to evolve with it.

Nor would I buy, without reservations, the idea of first applying a methodology faithfully and adapting it afterwards. In a stable product used in real projects, experimenting directly on the canonical framework would be irresponsible. That is why ALDC Research Lab keeps research and adoption apart: the lab’s results need evidence and a human decision before they become a product contract.

What we have found is a real tension that deserves a new hypothesis and another controlled test, rather than a reason to change ALDC automatically.

The next evolution should not add more bureaucracy

The blunt reading of a process that stops in Architecture is that it failed, or that it should have demanded even more detail from the start. Neither reading is very useful.

The one I prefer is different: the contract correctly protected implementation viability, but assigned Architecture a depth of evidence higher than some decisions required. The next step must keep the rigor and improve how responsibilities are distributed across Architecture, Technical Specification, Implementation and Review.

This changes the goal. It is no longer a choice between stopping or accepting weak evidence. It is about designing a third option: continue in a conditioned way, with an explicit evidence debt and a mandatory gate placed before the decision that truly depends on it.

The conversation about agentic development cycles should not be measured by how many agents, documents or controls we add. It should be measured by the quality and speed of the decisions the system allows us to make.

The right evidence, requested too late, creates risk. Requested too early, it creates friction and over-engineering. The challenge is to ask for enough evidence, at the precise moment, from the right responsibility.

For me, that is the interesting direction for ALDC Graph: a process that is more aware of why it needs each proof, rather than a heavier one.