Build
Give it the real system.
Catalogs, APIs, permissions, deployment, ugly data, old decisions. The happy path is the least interesting part.
Applied AI
I use AI every day.
I want to know
where it holds up.
I’ve given it real commerce work, real APIs, and plenty of chances to fail. That is where it gets interesting.
It is fast. It is also very willing to be wrong.
AI makes it much easier to try an idea. I want to understand what that changes about delivering the thing.
I know a model can make something that looks finished. I want to know what happens when it meets a weird catalog, a brittle integration, a release window, and somebody who has to support it on Friday night.
That part rarely fits in the demo.
01 /Position
What I want to know.
The model gets a real task. I look at what worked, what failed, and what a person still had to do.
Measure
Keep score.
Where did I step in? What did it misunderstand? What had to be rebuilt? Speed without the intervention count is marketing math.
Operate
Know what happens when it fails.
Identity, permissions, limits, logs, tests, approvals, and a stop button. Someone still needs to be able to see what happened and recover.
02 /Current experiment
Après Studio
I wanted to find the edge.
So I gave AI OCAPI, SCAPI, WebDAV, MRT, an empty storefront, and one rule: I was not allowed to write the code.
It built far more than I expected. It also got sloppy, burned context, took shortcuts, and reminded me why platform knowledge still matters. Après Studio is where I keep testing both sides of that.
See the experiment ↗03 /Field Notes
What I’ve found so far.
The useful parts, the ugly parts, and what happens after the prototype works.
01 / Applied AIRun the storefront from Slack.
Bring storefront marketing and merchandising into Slack with a merchant agent for Salesforce commerce. Discuss the change, approve it and verify the result.
02 / Applied AIThe purchase happened. The conversation kept going.Stripe is integrated into Après Studio's Storefront Next checkout and Juniper AI concierge, keeping the purchase in the storefront and the shopper in control.
03 / Applied AII think Claude-first commerce is a thing.Juniper integrates Claude into Salesforce Storefront Next for product discovery, comparisons, bag updates and a conversation that stays with the shopper.
04 / Applied AIAI can build the storefront. Production is the test.I let AI build a real Salesforce storefront. The pages were the easy part. Production is where the experiment became useful.
05 / Applied AIThe bottleneck moves when AI writes the codeAI writes code fast. Then context, review, integration, and ownership become the queue nobody planned for.
06 / Applied AIAgentic systems need an operating modelBefore we give an agent a clever name, I want to know what it can change, who owns the result, and how we stop it.
07 / Applied AIAI code review needs system contextAI can find a bad branch. I care whether it can see the locally correct change that is wrong for the whole system.
08 / Applied AIThe hard part of AI delivery is recoveryAI makes change cheap. Recovery tells me whether the team owns what it shipped or just got lucky in the demo.
09 / Applied AIEnterprise AI needs boring controlsThe model is new. Identity, permissions, logs, tests, limits, approvals, and a reliable stop button are not.
10 / Applied AIAgents are microservices with a friendlier voiceAI agents still need service boundaries, authorization, idempotency, and recovery. A commerce demo shows where conversational orchestration breaks down.
11 / Applied AIProduction is already becoming multi-modelCode written with different AI models can land in one production system. Govern context, changes, review, and deployment without confusing authorship with runtime.