Dancing with Composer — and Knowing When to Lead

I think I might have a new dance partner: Composer 1.5 from the team at Cursor.

Let me walk through a small problem — and more importantly, how to think about it as a business process model.

In our ERP, Uniti.js, we have a toolset called Custom Fields. It allows users to define attributes for different types of objects. A simple real-world example is MRI model compatibility.

In a related business, we resell Siemens MRI parts. We use custom fields to tag which models a part is compatible with — especially important for coils.

We also have another tool: SKU policies which define, among other things, a default set of custom fields for a given SKU.

So now we have a decision to make when creating a new item.

If a SKU policy exists, use it. If not, fall back to the most recent item with that SKU.

In both cases, we're only pre-setting a form. The user still confirms it. But we're guiding them toward best practices.

So I switched into "Ask" mode in Cursor first. This is important.

We walked through the data flow and found the first issue: the backend wasn't returning custom settings from the most recent item.

Composer's instinct was to fix it immediately.

And this is exactly why you don't jump straight into build mode.

Because the real question is not whether we can fetch the last item. It's whether the last item should ever override a defined policy.

If a SKU policy exists, that should almost always win. Not because it's rigid — but because it represents an intentional standard.

Maybe you override it. That's fine. But that should be a human decision — not an automatic one.

This is business process modeling.

So the instruction becomes:

"If a SKU policy exists, use it. Do not fall back to the most recent item."

Now we have a clean decision tree.

This is what we actually want the system to do:

And then we build.

This pattern shows up everywhere — any time a system has multiple possible sources of truth competing for control.

Takeaway

AI can accelerate development dramatically, but speed is not the constraint. Clarity is the goal.

If you don't model the process correctly, the AI will happily build the wrong thing — faster than ever.

So the real leverage is here: move up the decision chain, understand the process, then let the AI implement it.

In "ChatGPT and Opus Sitting in a Tree," I describe a two-AI workflow where design and implementation stay separate until the plan is right. The same principle applies: converge on the process first, then build.