Made in Humane Club
A Practical Guide to Using AI in Frontend Code
This article builds directly on my earlier post about prompt rules for AI-generated code. That piece focused on how to communicate with AI and why constraints matter more than clever prompts.
If you haven’t read it, start there:
👉 Why these simple prompt rules make frontend AI code better
This post moves one step forward and answers a different question: Where does AI actually fit in a real frontend workflow?
Deciding what should be prompt-driven vs. manually coded
Before involving AI, I make a clear distinction: Is this work deterministic or contextual? That single question determines ownership.
Prompt-driven work
AI is useful when the output:
- Follows established patterns
- Is structurally predictable
- Has little to no business ambiguity
Examples:
- UI scaffolding
- Layout composition
- Translating designs into JSX
- Repetitive component wiring
Manually written work
Keep AI out of code that:
- Encodes business rules
- Manages state transitions
- Handles side effects
- Has performance implications
This boundary prevents AI from making decisions it isn’t equipped to make.
Data layer first, UI second
Before AI touches UI code, the data layer is fully defined:
- State shape
- Events and transitions
- Loading and error states
- Async behavior
This follows the same reasoning described in my earlier post on why data-first systems scale better than UI-first ones:
👉 Building Frontend Features the Scalable Way: Why Data-First Architecture Wins
The rule is simple: UI consumes state. It doesn’t define it.
Why this changes how AI performs
Once the data layer exists:
- All valid states are explicit
- Actions are known
- Transitions are constrained
At that point, AI is no longer guessing. It is assembling UI against a fixed contract.
Typical prompt:
“Build UI components that consume this state and respond to these transitions. Do not introduce new state.”
This keeps AI focused on presentation and composition, where it performs reliably.
Design-to-code with Figma MCP
Design handoff improves significantly when AI has access to structured design data, not screenshots or descriptions.
With Figma MCP, the workflow becomes direct and mechanical.
📖 Guide:
https://help.figma.com/hc/en-us/articles/32132100833559-Guide-to-the-Figma-MCP-server
Workflow
- Copy the link to a specific frame or layer in Figma
- Paste it directly into the prompt
- Add constraints:
- Component boundaries
- Existing design tokens
- Reuse expectations
AI works from structure instead of inference.
Where AI consistently adds value
Within these boundaries, AI is effective at:
- Translating designs into JSX
- Applying layout and spacing rules
- Wiring components to known state
- Generating UI variants without logic drift
The common thread is that decisions already exist before prompting.
The operating model
I don’t treat AI as a collaborator. I treat it as a compiler for intent. That means:
- Thinking longer before prompting
- Asking narrower questions
- Making constraints explicit
The quality of the output reflects the clarity of the input.
Pre-prompt checklist
Before using AI, I verify:
- ✅ State is fully defined
- ✅ Business logic is locked
- ✅ Design source is linked, not described
- ✅ Constraints are explicit
- ✅ I can explain the generated code
If any of these are missing, AI stays out of the loop.
Conclusion
AI helps most in frontend development when it operates after structure, not before it. Prompting too early introduces guesswork. Prompting after decisions are made creates leverage. That difference determines whether AI genuinely helps—or just produces code that looks finished.