AI-DLC on SAP Commerce Cloud: Deciding What Counts as Proof

AI-DLC does not get its speed from the model. It gets it from three mechanics that are easy to miss when you read the marketing summary.

The first is a walking skeleton: the smallest end-to-end slice must run through a real check before any further units of work begin. The second is a single recorded construction verification command, authorised by a human once and reused at every unit checkpoint. The third is sensors — deterministic checks that run when the agent writes a stage's output and report what is actually in the file, rather than trusting the model's own summary.

Put together, the promise is a tight loop: AI proposes, a human approves, a machine verifies. That is a good promise. It is also a conditional one.

Now put that loop in front of a SAP Commerce Cloud programme. The codebase has hundreds of thousands of files. The business logic is not in the Java — it is in XML, ImpEx, and Spring wiring. The platform source is licensed, so it is readable but not transmittable. The local development platform exists, but the only environment that tells the truth is one you do not operate.

None of that means AI-DLC is the wrong method here. It means the method is roughly twenty percent of the work. The other eighty percent is building the adapter layer that SAP Commerce Cloud does not give you.

What AI-DLC Actually Asks of Your Platform

Most criticism of AI-DLC is aimed at the three-phase summary — Inception, Construction, Operations — which is fair but shallow. The open-source implementation is far more specific: five phases and thirty-three stages, fourteen agents, eleven scopes from poc to enterprise, three depth levels, three test strategies, a five-layer rule system, and verification gates at every phase boundary.

The vocabulary is deliberately unfamiliar. Sprints become bolts — work cycles measured in hours or days. Epics become units of work. Requirements are elaborated in a mob, and construction happens in a mob too, with the team validating the agent's proposals in real time. Every artifact — plans, requirements, decisions, approvals — lands in the repository, which is what gives the method its audit trail and its ability to resume across sessions.

What matters for this article is not the vocabulary but the dependency. Every one of those mechanics assumes three things about the platform underneath: that the code is legible to the agent, that verification is cheap and local, and that the artifacts produced can be checked by something more reliable than the model that wrote them.

Where SAP Commerce Cloud Breaks the Assumptions

1. Legibility: the codebase is huge, and the logic is declarative

A Commerce repository is not a normal codebase. Types and constraints live in items.xml. Which implementation actually wins lives in Spring XML. Seed and migration data live in ImpEx. The occasional imperative corner lives in Groovy. The Java is mostly glue between those declarations.

This matters because AI-DLC's fallback for understanding an existing system is a bounded workspace scan. On a programme of this size, a bounded scan is shallow by construction. And code search alone finds identifiers without finding meaning: grepping for a class name tells you where it is referenced, not which pricing rule it enforces or why two populators disagree.

The business logic is complicated in a way that punishes naive retrieval. A single customer-facing behaviour can pass through a type definition, a constraint, a prepare interceptor, a facade, a converter, a populator, an OCC controller, and an ImpEx-driven configuration. If the agent only sees fragments, it will produce fragments.

2. Licensing: the best grounding data is the least transmittable

SAP Commerce source is available to licensees, and that is genuinely good news. It means you can ground the agent in the exact API signatures of your release instead of training data that lags several versions behind. It removes the most common failure mode in generated Commerce code: plausible calls to methods that do not exist in your version, or exist with different signatures.

But licensed platform source is not yours to paste into a hosted model. So the architecture has to be deliberate rather than default: index the source locally, keep it inside your network, and expose it as a read-only knowledge layer. Do not point Reverse Engineering at it — otherwise stage 2.1 tries to summarise the entire platform and you get two hundred pages of noise instead of a map of your own extensions.

3. Unit granularity: everything converges on one file

AI-DLC wants units of work that are independently buildable, ordered by a dependency graph. In Commerce, almost every vertical slice converges on the same shared artifact: items.xml. Add an attribute, a relation, or an enum value and you have touched a global file that every other unit also wants to touch.

Worse, a schema change forces an initialise or update cycle — the most expensive local operation in the platform. So the walking skeleton cannot be a feature. It has to be the type-system change plus one working read path, with everything afterwards additive on top of it. That is a unit-decomposition rule, not a platform complaint, and it is the single highest-leverage adjustment you will make.

4. Verification: the loop exists, but it is heavy and not authoritative

Here is where the picture improves. You do not need the cloud to verify. Developers run Commerce locally, on whatever database they choose, with unit tests that run in seconds and integration tests that run against a locally started platform. There is a real loop.

It is just not free, and it is not the truth. So the design question is not "how do we make the loop fast" — it is "which loop counts as proof at which gate". The answer is a tiered design, and the fast tier is what you record as the construction verification command.

One practical rule follows from this: wrap tiers one and two in a single script. AI-DLC reuses one recorded command. If your verification is five manual steps and a memory of which profile to use, you do not have a verification command — you have a ritual.

5. Parity: local is your choice, the cloud is SAP's

Locally you can run Commerce on HSQLDB, MySQL, MariaDB, PostgreSQL, Oracle, SQL Server, or HANA. In the cloud you get SAP-managed infrastructure on Azure, and a database that is not your decision.

That gap is wider than it looks. FlexibleSearch is translated into SQL, so collation, case sensitivity, NULL ordering, and constraint behaviour can differ between your laptop and the cloud. Aspects behave differently depending on what is actually running. Solr configuration differs. Per-environment properties and manifest.json useConfig blocks are only exercised in a real build. Extension dependencies that resolve locally can fail in a clean cloud build.

The honest conclusion: no local test can prove that a schema change or a query is cloud-correct. Green twice is not the same as deployed. That is exactly why tier three is reserved for phase gates — and why the phase gate is not bureaucracy.

6. The deterministic second opinion does not ship

Of the six sensors bundled with AI-DLC, only the two code-level ones exist — and they lint and type-check TypeScript and JavaScript. The rest check document shape and traceability. On a Java, XML, and ImpEx codebase you start with zero guards — precisely where the risk is highest. If you want the method's deterministic layer, you write it yourself:

• no writes into core or platform extensions
• every new type declares a deployment table explicitly
• no string-concatenated FlexibleSearch queries
• no locale files other than English
• ImpEx must be re-runnable without duplicating rows
• no secrets or connection strings in extension configuration

Each of those is a small script. Together they are the difference between a method that checks its own work and a method that asks the model whether it did a good job.

7. Operation is not yours, but it is not closed either

Most of the Operation phase assumes you own provisioning and deployment. You do not: environments, scaling, observability, and incident handling belong to SAP. Skipping those stages is not a compromise, it is an accurate reading of the platform.

Deployment, however, has an interface. The Cloud Portal exposes a deployments API that takes a build, an environment, a database update mode, and a strategy. That turns the deployment stages from fiction into a thin, guarded wrapper — a tool the pipeline agent can call, with a human approving the call.

8. Two governance models cannot both be authoritative

Commerce programmes run on SAP Activate, tracked in Cloud ALM, with a change advisory process and environment promotion rules. AI-DLC brings bolts, verification gates, and its own approval rhythm. You cannot run both as written.

The workable mapping is to treat AI-DLC's artifacts as the evidence for the existing process rather than a parallel one: units map to backlog items, bolts map to sprint work, and the repository audit trail becomes an input to change approval. One approval model stays authoritative. The other becomes traceability.

9. Confidentiality is a design constraint, not a footnote

Custom commerce code is customer IP, and it sits next to customer data. Prompts need a no-training agreement, a region that satisfies your residency obligations, and a hard rule about what never enters them: product data, customer records, credentials, and production extracts. This is the one area where the cheapest option is usually the wrong one.

The Adapter Layer

Nine steps, but really three ideas: declare the environment, curate the rules, and engineer verification as a designed artifact. Everything else supports those three.

Declare the environment before the first workflow

AI-DLC reads a technical environment document from the space's knowledge folder. Write it before you run anything, and be explicit that the platform is SAP-managed rather than something the agent provisions.

The allow and disallow tables matter more than the prose. Without them the agent either asks about every choice or picks a default you then have to unwind.

Curate the rules instead of trusting discovery

Practices Discovery is the highest-leverage stage in the method and the one teams skip. Left alone, the agent will happily apply generic Spring conventions to a Commerce codebase: editing an extension it should extend, introducing a repository where a service belongs, adding a locale file nobody maintains.

Treat the stage's output as a draft for an architect to review, then commit the reviewed version into the project's memory. That is the moment domain expertise stops being tribal knowledge and becomes an input the agent reads at every stage.

Engineer verification as an artifact

Write the tier one script, make it deterministic, make it fast, and record it as the construction verification command. Add tier two for anything that touches persistence. Reserve the cloud build for the phase gate, and make the gate's evidence explicit: build identifier, environment, database update mode, strategy, smoke result, approver.

Three channels of knowledge, three trust levels

The knowledge layer is where the licensing constraint and the scale problem converge. Split it by trust, not by technology.

Context7 covers the public half well: platform documentation is indexed, versioned, and cited back to SAP's own help pages. It tells the agent what the API is.

It cannot tell the agent what your system does. That is the job of a private retrieval layer, and this is where ContextMCP Dockerized fits — and it fits unusually well for Commerce specifically. It parses code structurally, extracting classes and methods, while treating configuration files as whole documents. That is exactly the right shape for a codebase where items.xml and Spring XML are first-class logic rather than noise.

Its multi-repo indexing lets one index span custom extensions, the platform source, the storefront repository, and internal architecture docs. Its backup and restore means one person pays the indexing cost once and the team reuses the corpus instead of re-embedding a monorepo on every laptop. And because it runs locally — local embeddings, local vector store — the licensed platform source never leaves your network.

AI-DLC already anticipates this seam. Its adaptive composer will use an external code-knowledge MCP server for structural analysis if one is configured, and otherwise falls back to the bounded workspace scan. Configuring one is not a hack — it is using the extension point the method provides.

Map the method to your governance, then pilot

Decide which approval model wins, map AI-DLC's artifacts into the one that does, and pilot on a single extension for two or three bolts. Measure four things: lead time per unit, cloud build cycles consumed, review defects per unit, and the percentage of generated code accepted without modification. If the fourth number is low, your rules are the problem, not the model.

One Feature, One Bolt, One Gate

Take a customer-specific price list. In a Commerce codebase it is deceptively small: a new type, a relation to the customer, a constraint, a facade method, a populator, an OCC endpoint, and seed data.

Unit zero is the schema. The item type, the relation, the deployment declaration, and one read path that returns an empty list through the real service stack. That is the walking skeleton, and it is the only unit allowed to force an initialise. Everything after it is additive.

Retrieval comes before generation. A semantic query against the local index finds the two existing populators that already solve ninety percent of this problem, and the internal doc that explains why one of them is deprecated. A documentation query against Context7 confirms how the deployment attribute behaves on the target database. The agent now has a pattern to follow instead of an invention to make.

Tier one runs at every checkpoint — compile plus unit tests, under a minute. Tier two runs once the facade and populator exist — integration tests against the local platform, proving the relation loads and the constraint rejects the wrong input. Tier three runs at the phase gate — a cloud build, a deployment to a non-production environment with an update rather than an initialise, a smoke test, and a named approver.

That is a bolt. It is not hours, and pretending otherwise would be dishonest. But it is days instead of weeks, and every gate in it is backed by something a human can inspect.

Keep, Replace, Skip

Roughly two-thirds of the method survives intact. That is why the verdict is adoption rather than rejection.

Verdict

The platform is legible if you give the agent something better than a bounded scan. The loop exists if you accept that local is fast and the cloud is true. The method's spine — intent, units, walking skeleton, verification gates, repository-based audit trail — transfers cleanly.

What does not transfer is the assumption that verification is cheap and the platform is yours. So adopt the spine, replace the cloud-shaped parts, and spend your real effort on the two things SAP Commerce Cloud will not hand you: a licensed, version-pinned knowledge layer, and an honest answer to which loop counts as proof.

Until both exist, do not promise bolt cadence to anyone.

Sources

• AI-DLC white paper — the method definition
• AWS DevOps blog: AI-Driven Development Life Cycle
• awslabs/aidlc-workflows — phases, scopes, rules, sensors, technical environment document
• SAP Commerce documentation and SAP Commerce Cloud, public cloud