We didn’t start using AI because it was trendy.
We started using it because we were tired of doing the same repetitive work again and again.
If you’ve built more than one Shopify app, you already know the pattern:
-
Rewriting authentication logic
-
Drafting the same GraphQL queries
-
Rebuilding familiar Polaris layouts
-
Copy-pasting extension scaffolding and tweaking it yet again
None of this work is particularly hard—but it adds friction. And when you’re building production apps for real merchants, that friction adds up fast.
This post is a behind-the-scenes look at how we actually use AI while building Shopify apps—what we use it for, where we avoid it, and how it helps us move faster without sacrificing quality.
No hype. No shortcuts. Just practical experience.
Our stack (for context)



We build production Shopify apps using:
-
Shopify Admin API and extensions
-
Ruby on Rails for backend services
-
Shopify Polaris for admin interfaces
-
Admin, checkout, and theme extensions
Most of our AI usage lives inside the editor, not in a separate chat window.
That detail matters more than people think.
Why we brought AI into our workflow
The honest reason: mental fatigue.
After your second or third Shopify app, you’re no longer thinking about syntax.
You’re thinking about:
-
Permissions and scopes
-
Data models
-
Performance tradeoffs
-
Shopify review requirements
-
Merchant UX
But you’re still spending time typing the same patterns over and over.
AI helps us offload the mechanical parts so we can focus on decisions that actually require judgment.
Where AI genuinely helps us move faster
Rails scaffolding (with guardrails)
We don’t let AI design our architecture, but it’s useful for:
-
Drafting controllers
-
Creating service objects
-
Generating serializers and plain Ruby objects
Most of this happens directly in Cursor.
Being able to ask questions inside the file we’re already working on—especially in larger Rails codebases—saves a lot of context switching.
We treat AI output like a first draft. It almost always gets refactored before it ships.
Our rule is simple:
If it affects long-term maintainability, a human makes the final call.
Drafting Shopify GraphQL queries
This is one of the biggest wins.
Shopify’s Admin API GraphQL queries are powerful, but they’re also verbose and easy to over-specify.
We often ask AI to draft a query, not finalize it.
It usually gets us most of the way there.
From there we:
-
Trim unnecessary fields
-
Adjust pagination
-
Match API versions
-
Sanity-check everything in the GraphQL explorer
The goal isn’t perfection on the first try—it’s avoiding a blank screen and reducing mental overhead.
Polaris UI scaffolding
Polaris gives you consistency, but building clean layouts repeatedly still takes effort.
AI helps us:
-
Scaffold basic pages (settings, index views, detail screens)
-
Draft empty states
-
Lay out forms and sections
We almost always rewrite the copy and tweak spacing manually, but starting from a draft is faster than starting from nothing.
One rule we’re strict about:
AI never decides UX—it only helps us sketch it.
Shopify extension structure
Extensions come with very specific folder structures and lifecycle hooks.
AI is useful for:
-
Initial scaffolding
-
Basic config setup
-
Placeholder logic
This is especially helpful when switching between admin, checkout, and theme extensions in the same project. At this stage, structure matters more than content, and AI handles that part well.
How Cursor fits into our workflow
Most of our AI-assisted work happens directly inside Cursor — not as a separate step.
That’s the real shift.
Instead of jumping between browser tabs, docs, and the editor, we can ask questions while the code is open:
-
Inside a Rails service object
-
In a large Polaris component
-
While refactoring an extension file
That context matters.
We mainly use Cursor for:
-
Cleaning up messy methods
-
Suggesting refactors without changing behavior
-
Drafting tests for existing logic
-
Exploring alternative implementations before committing
What we don’t use it for:
-
Designing app architecture
-
Writing billing or permission logic
-
Anything touching money or irreversible data changes
We treat it like a fast-thinking partner—helpful for momentum, never the final authority.
If something feels even slightly off, it doesn’t ship.
Where we don’t use AI (on purpose)
This part matters more than where we do use it.
Billing and payments
Anything related to subscriptions, usage-based charges, or Shopify billing APIs is written by hand. One wrong assumption here can break revenue.
Shopify Functions and pricing logic
These require precision and predictable behavior. AI suggestions often look correct but fail in edge cases.
Data migrations and production scripts
If it touches real merchant data, AI stays out of it.
App review edge cases
Shopify’s review process has nuance that only experience teaches. AI doesn’t understand that nuance—humans do.
How we actually talk to AI
We don’t use polished, “prompt-engineered” commands.
Our prompts are usually loose and conversational:
-
“This controller is getting messy—help me split it without changing behavior.”
-
“This Polaris layout feels off. Suggest a cleaner structure, not copy.”
We expect ideas, not perfect answers.
Every output goes through human review.
The biggest mistake we see teams make
Trying to replace judgment.
AI is good at patterns and repetition.
It’s bad at context, nuance, and long-term thinking.
If you let it lead, your codebase slowly becomes inconsistent.
If you let it assist, you move faster and stay in control.
What changed for us
Using AI this way didn’t:
-
Lower our engineering standards
-
Replace developers
-
Remove thinking from the process
What it did:
-
Reduce build time
-
Lower mental fatigue
-
Let us focus on real problems
-
Help us ship Shopify apps faster without cutting corners
That’s the only outcome we actually care about.
Final thought
AI isn’t the future of Shopify development.
Good developers are using AI responsibly.
Used well, it’s a strong assistant.
Used carelessly, it becomes technical debt.
We choose the first.