Why these simple prompt rules make frontend AI code better

Most frontend engineers start using AI like this:

“Write a React component for a table.”

That works—until it doesn’t. What you usually get:

• Untyped props
• No accessibility guarantees
• State where effects should be
• Effects where memoization should be
• UI logic leaking into data layers
• Zero awareness of your design system

The problem isn’t the model. The problem is missing constraints. In B2B SaaS, frontend code:

• Lives for years
• Is read more than it’s written
• Must integrate with real design systems
• Must be testable, observable, and refactorable

Prompt rules are how you encode those expectations.

---

Mental model: Prompts as a type system for AI

Think of prompt rules as:

• Lint rules for language models
• Architectural guardrails for generated code
• Org-level frontend standards, but executable

Bad prompt:

Build a React form

Good prompt (with rules):

Build a React form following our cursor rules:
- TypeScript strict mode
- Ant Design components only
- No local state for server data
- Accessible labels required

The difference in output quality is nonlinear. You don’t get “slightly better code”—you get structurally different code.

---

Generic frontend prompt rules (framework-agnostic)

These are the baseline rules every serious frontend team should adopt.

1. Type safety is non-negotiable

• Always use TypeScript
• No any
• Prefer explicit types over inference for public APIs
• Props and return types must be defined

Prompt rule:
Never generate untyped props, function arguments, or return values.

Why this fails in B2B SaaS:
Untyped boundaries silently break when APIs evolve, permissions change, or features are reused across products.

Before (no rules):

const Table = ({ data }) => {
  return <table>{data.map(...)}</table>
}

After (with rules):

type UserTableProps = {
  data: readonly UserRow[]
}

export function UserTable({ data }: UserTableProps) {
  ...
}

Junior-safe default. Seniors can loosen this locally—but never at module boundaries.

---

2. Code is read more than written

• Prefer clarity over cleverness
• Avoid nested ternaries
• Name variables semantically, not mechanically

Prompt rule:
Optimize for long-term readability over brevity.

Why this matters:
Most frontend bugs in SaaS are fixed months later by someone who didn’t write the code. Readable code is cheaper than clever code.

---

3. UI logic ≠ business logic

• UI components should not fetch data
• Business rules belong outside components
• Side effects must be isolated

Prompt rule:
Separate presentation, state, and effects into distinct layers.

Why this breaks at scale:
Permission logic, feature flags, and account-level behavior creep into components and become untestable.

Senior note:
Fetching data inside a component is not wrong—it’s wrong when it becomes the only place business logic lives.

---

4. Accessibility is default, not optional

• Labels for inputs
• Keyboard navigability
• ARIA only when necessary

Prompt rule:
Generated UI must meet baseline accessibility standards without being asked.

Why this matters in SaaS:
Internal tools, admin panels, and enterprise dashboards are still subject to accessibility audits—and retrofitting is expensive.

---

5. No magic, no hidden state

• Avoid implicit global state
• No undocumented behaviour
• Explicit dependencies

Prompt rule:
Every piece of state must have a clear owner and lifecycle.

Junior takeaway:
If you can’t explain who owns the state in one sentence, it’s probably wrong.

---

Framework-specific prompt rules

This is where generic advice stops working and real-world tradeoffs begin.

---

React prompt rules

Component design

• Functional components only
• Hooks at top level
• No side effects in render

Prompt rules:

• Use function components exclusively
• Hooks must follow the Rules of Hooks
• Prefer composition over configuration

Performance discipline

• Memoization must be intentional
• No premature optimization

Prompt rule:
Use useMemo and useCallback only when there is a clear dependency or performance reason.

Senior judgment required:
Blind memoization increases complexity and often worsens performance in real apps.

---

TypeScript prompt rules

Strictness

• strict: true
• No implicit any
• Exhaustive checks for unions

Prompt rules:

• Prefer unknown over any
• Use discriminated unions for the state
• Enforce exhaustiveness with never

Why this matters:
Most SaaS bugs are invalid states—not syntax errors.

---

Redux prompt rules (modern Redux Toolkit style)

B2B SaaS apps usually fail here.

State shape discipline

• Flat, normalized state
• Feature-scoped slices
• No UI state in Redux unless shared

Prompt rules:

• Use Redux Toolkit only
• No manual reducers or action types
• Async logic must use thunks or RTK Query

When to break this rule:
Ephemeral UI state (hover, focus, local form input) should stay local—even if shared elsewhere.

---

React Context prompt rules

Context is not Redux-lite.

When to use Context

• Cross-cutting concerns only
• Stable, infrequently changing values

Prompt rules:

• Do not use Context for high-frequency updates
• Wrap Context access in custom hooks
• Context providers must be colocated with domain boundaries

Failure mode:
Context re-renders become invisible performance bugs.

---

Ant Design prompt rules

Design systems are contracts.

Consistency over creativity

• Never recreate components
• Use Ant Design tokens
• Respect spacing, typography, and interaction patterns

Prompt rules:

• Use Ant Design components exclusively for UI primitives
• No custom CSS unless tokens are insufficient
• Follow Ant Design form validation patterns

Senior note:
Custom CSS isn’t evil—but undocumented divergence is.

---

Storybook prompt rules

Storybook is documentation, not decoration.

Stories as specs

• Every state must be visible
• Stories double as test cases

Prompt rules:

• Every component must include stories
• Include loading, empty, error, and edge states
• Use args and controls, not hardcoded props

Why this matters:
Future engineers learn your system through Storybook—not Confluence.

---

Open source Cursor rule file (drop-in)

Below is a generic, open-source-friendly Cursor rule file you can adapt for your team.

# Frontend AI Coding Rules (B2B SaaS)

## General
- Always generate TypeScript with strict typing
- No usage of `any`
- Optimize for readability and maintainability
- Code must be production-grade, not demo-quality

## React
- Use functional components only
- Follow Rules of Hooks strictly
- No side effects in render
- Separate data fetching from presentation

## State Management
- Prefer local state unless shared across domains
- Redux Toolkit only for global state
- No UI-only state in Redux

## TypeScript
- Explicit types for public APIs
- Use discriminated unions for state
- Exhaustive checks required

## Ant Design
- Use Ant Design components and tokens exclusively
- Do not recreate existing components
- Follow Ant Design form and validation patterns

## Accessibility
- Labels required for inputs
- Keyboard navigation must work by default
- ARIA attributes only when necessary

## Storybook
- Every component requires stories
- Include all meaningful states
- Use args and controls

## Code Quality
- No magic values
- No hidden state
- Explicit dependencies and effects

## Output Expectations
- Code should be ready for PR review
- Follow B2B SaaS scalability and maintainability standards

---

Why this matters in B2B SaaS (the real reason)

B2B SaaS frontend engineering is about:

• Predictability
• Scale
• Reduced cognitive load
• Fewer production surprises

AI doesn’t magically understand that. Prompt rules encode institutional knowledge. They turn AI from a junior dev into a force multiplier.

---

FAQs

1. Are prompt rules better than prompt templates?
Yes. Rules scale across prompts; templates don’t.

2. Should these rules live in the repo?
Absolutely. Treat them like lint rules.

3. Can this replace code reviews?
No—but it dramatically improves first-pass quality.

4. Do these rules slow down experimentation?
They reduce rework, which speeds up everything else.

5. Should designers be involved?
For design system rules—100% yes.

6. Can this work beyond frontend?
Yes. Backend and infra benefit even more from rule-based prompting.

---

Final thoughts

AI doesn’t replace senior frontend engineers. It amplifies them—if you give it the same constraints you give humans. Prompt rules are how serious B2B SaaS teams turn AI from a novelty into infrastructure.