John Wesley reduced the entire Methodist movement to three rules: do no harm, do good, and stay in love with God. Not a comprehensive theology. Not thirty-seven principles. Three simple constraints that anyone in a Methodist society could remember, apply, and teach.
I’ve been thinking about Wesley’s framework — specifically his instinct that constraint creates more impact than capability — as product teams struggle with AI implementation. Claude can write, code, analyze, reason, and create. GPT-4 handles everything from customer support to strategic planning. The temptation is to throw AI at every problem and see what sticks.
Wesley understood something we keep relearning: the most powerful systems aren’t the ones that can do everything. They’re the ones that do specific things exceptionally well within clear boundaries. Here’s what his three-rule framework looks like as an AI product design principle.
Do No Harm: The First Constraint in AI Prompt Design
In AI product work, “do no harm” translates to a specific discipline: define what the AI system should not do before you define what it should do.
Most teams design AI features by expanding capability — adding more things the AI can handle, more use cases it supports, more outputs it can generate. The Wesley approach inverts this: start by naming the exclusions. What should this AI never say? What user requests should it decline to fulfill? What outputs would be harmful, misleading, or counterproductive even if technically achievable?
The constraint changes the architecture of the feature. Teams that start with capability tend to build AI that does many things adequately. Teams that start with harm prevention tend to build AI that does specific things with genuine care for the user’s actual outcome. The difference in user trust is significant and compounds over time.
In practice: before your next AI feature ships, write down three things it should never do. Make those constraints explicit in your system prompt, your evaluation criteria, and your launch checklist. The discipline of naming the harms before the capabilities will change what you ship.
Do Good: The Second Constraint
“Do good” seems obvious — of course the goal is to do good. But Wesley’s point wasn’t that doing good is obvious. His point was that you have to choose it actively and specifically. You have to name the good you’re trying to do, not assume it follows from capability.
For AI product teams, this translates to specificity of purpose. The most dangerous AI features are the ones built with vague positive intent — “help users be more productive,” “improve the experience,” “make things easier.” These goals aren’t wrong; they’re insufficiently specific. They don’t constrain what the AI does well enough to actually do good reliably.
The teams building the most impactful AI features are the ones who can answer precisely: for which specific user, in which specific situation, doing which specific task, does this AI feature create genuine value? The narrower the answer, the more intelligence you can focus on serving that specific case. AI amplifies specificity. A vague AI feature serves everyone adequately. A specific AI feature genuinely transforms a particular user’s experience.
The prompt design corollary: every AI system prompt should contain an explicit statement of the specific good the AI is designed to do. Not “help users.” Something precise enough that you could evaluate whether a given output advances it or not.
Stay in Love With the Mission: The Third Constraint
Wesley’s third rule is the hardest to translate into product terms, but the translation is important. “Stay in love with God” was Wesley’s constraint against letting the institution — the methodology, the system, the practice — become the end rather than the means. The movement existed to serve spiritual formation, not itself. When the structure started serving itself, Wesley’s third rule was the corrective.
For AI product work, this is the constraint against losing the mission in the mechanics. It’s easy to become so focused on what the AI can do — what’s technically impressive, what gets stakeholder attention, what generates engagement metrics — that you lose track of whether the AI is actually serving the user’s underlying goal.
I’ve watched this happen. A team builds an AI writing assistant that users engage with heavily — and then realize the engagement is driven by the novelty of watching the AI write, not by the quality of what users are actually producing. The metric is green. The mission has drifted. The AI became the point rather than the tool.
“Stay in love with the mission” is a standing question for every AI feature review: is this feature advancing the user’s actual goal, or is it becoming the goal itself? The discipline of asking it consistently is what keeps AI features from becoming impressive demonstrations that quietly fail the user. More on this from a product ethics perspective: the Interaction Design Foundation’s framework on design patterns is a useful lens for evaluating where AI features cross from tool to substitution.
Why Constraint Beats Capability in AI Product Design
The Methodist movement succeeded not because Wesley had the most sophisticated theology, but because he had the most practical framework. Three rules anyone could remember, apply, and teach — that’s what scaled the movement across 18th-century Britain.
The teams building the most impactful AI products right now aren’t the ones deploying every capability. They’re the ones who’ve chosen clear constraints that channel AI capability toward specific, valuable outcomes. Their prompts are shorter and more focused. Their AI features do fewer things with more precision. Their users trust the outputs because the product was clearly designed with the user’s outcome in mind rather than the AI’s capability ceiling.
In a world where AI can do almost anything, the crucial question isn’t what’s possible. It’s what’s wise. Wesley figured out how to answer that question with three rules. Your AI prompts need the same discipline.
Your Turn: Apply This Today
Apply the three-constraint framework to your current AI features:
- Write the “do no harm” list for your highest-traffic AI feature. Name three things this AI should never output, regardless of what the user asks for. Write them as explicit constraints in your system prompt. If you’ve never done this exercise, do it before your next feature review — it will surface assumptions nobody has articulated.
- Rewrite your AI feature’s purpose statement as a specific user outcome. Replace “help users be more productive” with a sentence specific enough to evaluate: “Help [specific user type] accomplish [specific task] in [specific context] faster and with better results.” If you can’t write the specific version, the feature isn’t ready to ship.
- Add a “mission drift” check to your sprint review. Ask once per sprint: are users engaging with this AI feature because it’s helping them accomplish their goal, or because it’s impressive to interact with? The engagement metric doesn’t distinguish between these. Your qualitative research should.
- Test the three-rule prompt structure on your next system prompt. Write a system prompt that has three sections: what the AI must never do, what specific good the AI is designed to do, and what the user’s underlying goal is that the AI should always serve. Compare the outputs to your current prompt. The discipline almost always improves them.
- Audit your AI feature’s constraint density. Count the constraints in your current system prompt vs. the capabilities you’ve described. If capabilities dramatically outnumber constraints, you’ve built an AI feature by expansion rather than by design. Add at least one constraint for every three capabilities you’ve described.
- Apply the “Wesley test” before your next AI feature launch. Ask: does this feature do no harm? Does it advance a specific, named good for a specific user? Does it serve the user’s mission rather than substituting for it? If you can’t answer yes to all three, the feature needs more design work before it ships.
The constraint-beats-capability principle shows up in other forms too — the choice overload paradox in AI features is the consumer-facing version of the same dynamic, and Munger’s inversion principle is a complementary framework for designing around constraints rather than toward capabilities.
Building AI features and trying to avoid the “impressive but useless” trap? I consult with product teams on AI prompt architecture, constraint-based feature design, and building AI that serves users’ actual goals rather than demonstrating capability. Let’s talk.