How we build with coding agents at Intershop

AI agents are becoming a new class of commerce-platform user. What does that change for B2B businesses, and what remains essential?

A growing part of what I do at Intershop involves working directly with coding agents. We use GitHub Copilot, Claude Code and Codex to explore requirements, navigate repositories, implement changes, review code and verify results. We also test what happens when AI receives a business brief instead of a list of individual development tickets.

This puts me in an unusual position. I get to see both how fast these agents can be and how quickly a convincing result can hide unanswered questions.

My current conclusion is simple: AI can build more of a commerce solution than many people expect. But getting from generated software to a dependable B2B product still requires domain knowledge, architecture, verification and human judgement.

1. Can AI build a commerce frontend?

Yes. This is no longer a theoretical scenario.

In a controlled exercise, we gave a coding agent a B2B requirements document, access to Intershop documentation and governed credentials for the Intershop Commerce Platform. The task was not to modify a prepared storefront template. It had to interpret the requirements, create a branded frontend, connect search and product data, and implement the journey through product detail, cart, checkout and order retrieval.

The result was a working experience rather than a set of disconnected screens. The agent could test the journey end to end and verify the order in the underlying commerce system.

This is an important shift. AI-assisted implementation can reduce the distance between a business requirement and something customers can actually use. It also allows teams to explore more alternatives before committing to a final experience.

There is a clear division of responsibility: AI creates and adapts the experience, while the commerce platform continues to provide the trusted pricing, customer context, permissions and transaction behind it.

2. Why is the first demo not the real finish line?

A fast storefront can create the impression that the entire commerce solution is now easy to generate. That is where I would be careful.

A production-ready B2B solution needs more than pages, search, cart and checkout. It has to support company and account structures, contract prices, permissions, approvals, multiple organizations, ERP integration, failures, security, auditability and many years of edge cases.

AI can generate code for all of this. But every missing capability still has to be specified, supplied as context, implemented, reviewed, tested, corrected and operated over time.

Starting from a blank repository therefore usually takes much longer and consumes far more model tokens than the first demo suggests. The cost is not only the model usage. It is also the time of domain experts, architects and developers who explain requirements, review decisions and close the gap between a plausible prototype and a dependable production system.

Time-to-demo is useful. Time-to-verified-production is the measure that matters.

3. Why do we use more than one coding agent?

We do not treat one model or tool as the sole authority. In our current setup, the three products play complementary roles.

GitHub Copilot is close to the everyday developer workflow. Repository instructions and task-specific prompt kits allow us to bring Intershop context into a tool that many developers already use in their IDE and GitHub environment. Our migration instruction kit is one example of how product-specific guidance can turn a general coding assistant into a platform-aware tool for a concrete engineering task. This makes GitHub Copilot particularly relevant when AI-assisted practices need to scale across a larger engineering organization rather than remain an experiment used by a few specialists.

Claude Code and Codex are useful when we want an agent to take on broader, repository-level tasks. They can take different roles in analysis, implementation and review. Executable tests remain the final judge.

As of today, Claude Code can be an uncomfortably thorough reviewer. It is the colleague you might hesitate to invite to a relaxed Friday-afternoon code review because it will find the weak assumption, the missing test and the architectural shortcut. That can be annoying. It is also exactly what I want before a change reaches production.

Codex is often effective at turning the resulting findings into focused implementation work. These roles are not permanent product characteristics. Models evolve quickly, so we measure them by task and change the assignment when the evidence changes.

A recent controlled study of cross-model code review reached a similarly nuanced conclusion. Across 116 benchmark tasks, review improved results in one model direction, while the reverse pairing did not. More review is not automatically better. The pairing, task and verification method matter.

The practical pattern is:

• Choose the tool and model for the task;

• Separate author and reviewer where risk justifies it;

• Give the reviewer fresh context;

• Require evidence for findings;

• Let tests, builds and acceptance criteria decide whether the work is done.

4. How do we structure larger agentic development work?

One agent with one enormous prompt is not a scalable engineering method.

For larger initiatives, we use a graph-based, evaluation-driven engineering workflow. Different agents take on distinct roles, but only where that separation adds real value. We do not need a swarm of agents for every task. A customer perspective and an engineering perspective, for example, benefit from being independent; deterministic steps remain deterministic.

One pattern we are evaluating works like this:

1. A customer-perspective agent receives requirements, published documentation, governed test access and an empty workspace. It builds and verifies the requested solution.

2. If documentation or platform behavior blocks the work, it submits a reproducible finding with evidence.

3. An engineering agent independently reproduces and classifies the finding, then turns accepted issues into implementation tasks with observable acceptance criteria.

4. After implementation, a new candidate is evaluated again from the customer perspective.

The result is a closed improvement loop: requirement, implementation, evidence, engineering decision and independent re-evaluation. The durable state lives in explicit artifacts and work items, while each agent receives only the context needed for its role.

This separation matters. An engineering agent may know that a capability exists in the code. A customer-perspective agent only knows whether it can discover, understand and use it through the published product surface.

Humans remain responsible for objectives, architectural boundaries, priorities and final judgement. Agents provide leverage where a specialized role makes the process more reliable.

5. What makes a platform usable by coding agents?

The most capable coding agent still struggles when the platform depends on undocumented knowledge.

We have found that coding agents benefit from many of the same qualities human developers value, but they depend on those qualities more consistently:

• Structure and context: predictable repositories, concise context files with working commands, and deterministic dependency and interface inventories.

• Contracts and documentation: stable APIs, explicit business contracts, current documentation and realistic sandbox data.

• Verification: structured errors, fast tests with objective pass or fail results, and visible runtime state for end-to-end checks.

This changes how I think about developer experience. Documentation is not a layer added shortly before release. Tests are not only internal quality assurance. Repository structure is not cosmetic. Together, they form an interface through which people and coding agents understand the product.

If a new engineer or coding agent cannot explain, implement and test a relevant scenario from the approved context, the missing implicit knowledge is a product problem.

6. What do focused greenfield projects teach us?

Greenfield work is most useful when it is tightly bounded: a new service, a specialized agent, an integration or a customer experience developed outside the transactional core.

These focused projects are valuable because they let a team test new architecture and AI-assisted development patterns without carrying every historical implementation decision into the experiment. They also reveal how quickly even a small service depends on established commerce knowledge.

They reveal the limits of AI just as clearly. An agent does not magically turn a broad objective into a production-ready service on its own. It still needs guidance, architectural boundaries, business decisions, acceptance criteria and access to the right tools and context. When requirements conflict or a trade-off affects the product, security or operations, a person still has to make the call.

The effort does not disappear. It shifts. Teams may spend less time writing every line of code by hand, but more time on requirements engineering, clarifying business rules, preparing context and discussing alternatives with the AI. A productive session often looks less like issuing one perfect prompt and more like working with a very fast colleague: explain the objective, challenge assumptions, review the result, correct misunderstandings and make the decisions the agent cannot make responsibly on its own.

Large tasks also need to be planned and broken into smaller, verifiable increments. AI can help create that plan, but it should not disappear into a long autonomous run and return with a result that merely looks complete. Each increment needs a defined outcome, tests and evidence before the next one builds on it. The larger the task, the more important this engineering discipline becomes.

A merchant agent processing an order request still needs to understand customer identity, products, contract prices, permissions and approvals. A new integration service still needs to respect order states, retries and duplicate protection. A generated storefront still depends on reliable search, pricing, inventory, cart and checkout behavior.

This is one of the strongest observations from teams working on focused greenfield services and agents: a mature commerce platform contains an enormous amount of accumulated domain knowledge. Much of it no longer appears as a visible feature. It is encoded in rules, state transitions, validation, error handling, integration behavior and exceptions learned from real customer projects.

AI can help us make this knowledge explicit and use it in a new component. It cannot invent the correct business behavior where the requirements have never been defined. A new service or agent should use the platform’s existing commerce capabilities, not recreate complex B2B rules such as pricing, permissions, approvals and order processing.

That changes the economics. The coding agent can spend its context, tokens and time on the new customer experience, workflow or integration while the established commerce platform continues to provide the trusted transactional behavior behind it.

Focused greenfield projects show what AI can build and help us challenge unnecessary complexity. They are a practical way to evolve the platform in small, testable steps.

Our standard should be evidence, not magic.

Three takeaways

1. AI can build real commerce experiences. A clear brief, accessible documentation and stable interfaces can take GitHub Copilot, Claude Code, Codex and other coding agents surprisingly far.

2. The work shifts from typing code to engineering intent. Clear requirements, explicit decisions, structured handovers and independent verification matter more than adding another agent to the workflow.

3. Domain knowledge remains the decisive asset. The goal is not to regenerate decades of B2B behavior with tokens. It is to make proven knowledge usable by agents and focus their effort on differentiation.

The models will change. The engineering discipline should remain.

Continue exploring

• Previous article in this series: From API-first to agent-first commerce

• Explore Intershop's AI copilots & agents

• Read the Intershop roadmap to practical agentic commerce

• Download the Intershop B2B commerce playbook