Developing Code Assistants and AI Prompts in Sitecore Stream

Most personalization bugs don’t come from the architecture. They come from the tiny bits: a condition that assumes guest.orders exists, a session trait that chokes on a null value, a programmable that worked fine in staging but breaks against real guest data.

These aren’t hard problems. They’re tedious, easy to miss, and expensive to fix once they’re live.

Sitecore Stream’s Code Assistant is meant to shrink that kind of work. Instead of writing every condition, programmable, and session trait from scratch, you describe what you want in plain English and get a JavaScript draft built against the Sitecore Personalize data model. It’s not magic, and it’s not a replacement for thinking. But it does move the work from “type out the boilerplate” to “check whether this thing actually matches your data.”

What it actually handles

Code Assistant focuses on three constructs:

• Conditions - must return a Boolean.
• Session traits - must return a typed value pulled from guest or session data.
• Programmables - run inside the decisioning pipeline.

The normal flow is slow: understand the requirement, find the right data, write the JavaScript, test end to end. Code Assistant compresses the first two steps. You write the prompt, it gives you something testable, and then you validate.

The catch is that it can only work with what you put in the prompt. It doesn’t know about your custom data extensions, your third-party integrations, or the real shape of fields like guest.orders, guest.attributes, or anything else you’ve bolted onto the schema. So, the code it produces is usually syntactically right and semantically plausible, but you still have to confirm the field names, types, and null behavior against the live data.

The prompt matters more than it should

The output quality tracks closely with how specific you are. Vague prompts force the model to make assumptions about thresholds, data sources, and fallbacks and it will make them.

Compare:

Create a returning customer condition.

to:

Create a Sitecore Personalize condition that returns true when the customer has at least one completed purchase within the last 30 days. Only completed purchases count. Return false if there is no order data. The result must always be a Boolean.

The second version locks down status === "COMPLETED", the 30-day window, the null fallback, and the return type. Those are your acceptance criteria, and the prompt is the place to encode them.

A realistic example

For that second prompt, you might get something like:

const orders = guest.orders || [];

const thirtyDaysAgo = new Date(Date.now() - 30 * 24 * 60 * 60 * 1000);

const recentPurchase = orders.some(order =>

order.status === "COMPLETED" &&

new Date(order.createdAt) >= thirtyDaysAgo

);

return { value: recentPurchase };

This is a solid starting point, but treat orders, status, and createdAt as placeholders until you verify them. Maybe your schema calls it orderDate. Maybe status is lowercase "completed". Maybe guest.orders is sometimes null, sometimes undefined, sometimes an empty object. That’s the part you have to check.

Programmables and session traits work the same way

A session trait that needs to return the most-viewed category from the current session, or a programmable that picks a fallback offer when the primary one is excluded — you describe the requirement, get a draft, then run it against real data and fix what’s wrong.

What changes in practice

Code Assistant doesn’t remove engineering work. It moves it.

Less time goes into typing condition skeletons. More time goes into:

• validating field names and types,
• testing nulls, empty arrays, and malformed records,
• and thinking about how the condition fits into the larger decisioning flow.

That last part is where AI-generated code tends to fail in production. The code looks right, passes a quick test, and then breaks on the edge case nobody described in the prompt.

The useful workflow is simple:

requirement → specific prompt → generated draft → schema validation → edge-case testing → deploy

The generation step is fast. The validation and testing steps are not optional. Skip them, and you’re shipping a guess.

As this kind of tooling becomes normal in Sitecore Personalize, writing a good prompt starts to look like writing good code: precise, scoped, and aware of what can go wrong. The skill isn’t replacing JavaScript. It’s sitting next to it.

Written by

Janki Suthar

Technical Architect

Hi, I'm Janki Suthar. I work as a Technical Architect and Sitecore Certified Software Developer at Arroact Technologies, where my days are split between Sitecore XP, XM, and XM Cloud on one side, and React.js, Next.js, and .NET on the other.

What draws me to this stack is the challenge of making two very different worlds, a structured CMS backend and a dynamic frontend, work together seamlessly. Sitecore AI has become a big part of that lately, and I've been digging into how it changes what personalization can actually look like in practice.

I've learned the best fix is usually the simple one. Given a choice, I'll always pick the version that's easier to explain, even if it took longer to get there.