AI can build the storefront. Production is the test.

I gave AI an empty storefront, access to the Salesforce stack, and one deliberately unreasonable rule: I was not allowed to write the code.

It produced a convincing storefront quickly. That was useful. It was also about ten percent of the question.

Après Studio exists because I want to know how much of a real enterprise implementation can move through this model without hiding the human work.

That changes what I measure.

A demo answers the easy question

A demo tells me whether the system can generate something recognizable. It can show a catalog, navigation, product pages, content, or a checkout flow. It may look finished long before it is safe to operate.

Production asks different questions:

• Can another person understand what was built?
• Can the same process produce the same result twice?
• Can we test the behavior without trusting the agent’s explanation?
• Can we change one part without breaking three others?
• Can we recover when a deployment or import fails?
• Does the client own the result, or only the conversation that produced it?

Those questions are less impressive in a demo. They are most of the work.

Count the interventions

“Built by AI” is too vague to mean anything. There is always a boundary around what the model did, what a person supplied, and what somebody had to repair.

For Après Studio, I care about the interventions: catalog fixes, data-shape corrections, image mapping, environment configuration, failed imports, test gaps, and anything that required a person to understand platform behavior the model missed.

The failure is not that an intervention happened. The failure is pretending it did not.

A serious delivery model should make those interventions visible. That creates evidence about where the tooling is strong, where platform-specific knowledge still matters, and which steps can become repeatable.

The artifact matters more than the transcript

An agent can explain what it intended to do. That explanation is not the system.

The durable output is the code, configuration, data, tests, deployment path, and documentation that remain after the session ends. If the build cannot be understood without replaying a long conversation, the team does not really own it.

This is one reason I prefer generated import files, versioned configuration, and repeatable deployment steps over manual setup hidden inside an admin interface. The point is not that every click is bad. The point is that invisible state is hard to review, reproduce, and recover.

Where AI is already earning its keep

The speed is real. AI is good at creating first passes, transforming structured data, scaffolding integrations, producing test cases, and handling repetitive implementation work. It also makes some experiments cheap enough to run instead of debate.

That changes the economics of discovery. A team can test an architectural direction with working software earlier, then decide whether the idea deserves production investment.

But speed only helps if the feedback reaches the decision. A faster path to a brittle system is still a brittle system.

My current definition of done

For this experiment, a storefront that renders is a Tuesday. “Done” means somebody other than the model can deploy it, change it, test it, and recover it.

I expect that definition to move. I am building the thing because I would rather find out where I am wrong than present a theory about where AI is going.