This page documents a repeatable execution model for turning design intent into working product artifacts — without an engineer handoff. The system combines structured prompt architecture, persistent AI skills, and a reusable component library to produce high-fidelity SAP Fiori demos, portfolio infrastructure, and AI system interfaces at the speed of a single working session.
Output TypesSAP Fiori demos · Portfolio pages · Internal tools · AI system interfaces
Primary StackHTML · CSS · SAPUI5 · Claude Code · Custom AI Skills
What This Is
Design intent → working artifact, same session. The system closes the gap between what can be designed and what can be shipped — without relying on an engineer handoff or a later sprint to validate decisions.
Vibe coding is an execution model, not a shortcut. Producing correct code with AI requires design system literacy, structured prompt architecture, and enough technical fluency to review output against spec. The quality of the output is a direct function of the quality of the brief.
Reusability is the structural goal. Each build outputs reusable CSS patterns, component classes, or AI skill files. The system compounds — the tenth build is faster than the first because the infrastructure already exists.
01 / 06
What Vibe Coding Means Here
The core structural problem with design-to-engineer handoffs is latency: design decisions don't get tested until they're expensive to change. Vibe coding — design-led, AI-assisted prototyping — solves that by collapsing the feedback loop. The designer maintains architectural authority; the AI handles implementation. The gap between a decision and a working artifact becomes a single session.
The system works because the AI is given specifications, not visions. Exact CSS class names, token values, layout logic, interaction states — the same level of precision a good engineer expects in a design handoff. Reviewing the output is reviewing code against a spec, not looking at a screenshot and guessing.
Step 01
Design Intent
Define what the component needs to communicate, what states it has, and what tokens or design system rules it must follow.
Step 02
Structured Prompt
Translate design intent into a precise build brief — layout rules, CSS class names, token references, component constraints, output format.
Step 03
Build + Review
AI generates the code. I review against the design spec — catching token drift, layout breaks, missing interaction states, and semantic errors.
Step 04
Refine + Reuse
Correct outputs become reusable patterns. Recurring components get extracted into CSS classes, AI skills, or prompt templates I use in the next build.
The key constraint: AI writes fast and confidently — including confidently wrong code. The skill is knowing what correct looks like before you prompt, so you can catch the drift immediately rather than after the build is embedded in the page.
02 / 06
What I've Built
Each artifact below was produced with this system — design intent to working code in a single session. Collectively they represent a reusable execution infrastructure, not a collection of one-off prototypes.
SAP Fiori Demo
ASN Joule Demo
Full SAP Business Network Advanced Ship Notice workflow with an embedded Joule AI assistant panel — pixel-perfect Horizon tokens, live filter bar, table interactions, and contextual AI responses.
SAPUI5Horizon tokensSingle-file HTMLSAP-icons
SAP Fiori Demo
Order Confirmation Joule Demo
Buyer-side Order Confirmation workflow with a Joule assistant panel for exception handling — designed to demonstrate AI decision support in supply chain operations.
SAPUI5DynamicPageBN filter barJoule panel
Portfolio Infrastructure
katejieyu.com
This entire portfolio site — built from scratch with a custom design system, CSS token architecture, and case-study page template system. All coded with AI assistance.
HTML/CSSCSS custom propertiesResponsive layout
AI System Interface
SyncoPro Decision UI
The product planning interface for SyncoPro — AI-assisted session flow, structured decision outputs, and an evolution tracking system that persists context across sessions.
AI skill systemSession architectureClaude Code
Internal Tool
AI Demo Reference Library
A self-hosted design token reference, icon search tool, and SAP Fiori component catalog I use to accelerate demo builds — built as a single HTML file with live search.
SAP-icons registryToken JSONSingle-file HTML
Design System
BN Component Library
A reusable SAP Fiori component library for Business Network demos — canonical filter bar, ShellBar, table toolbar, and KPI tile patterns — extracted from production builds and locked as reusable CSS + AI skill references.
CSS component systemHorizon tokensAI skill filesReference HTML
03 / 06
The Prompt Architecture
A prompt is a design brief. Inconsistent output is almost always a briefing problem, not a model problem. The prompt format below produces correct-on-first-pass code for Fiori components by giving the AI the same information a precise engineering spec would contain — nothing less, nothing more.
The five elements of a build prompt
Element 01
Context + Constraint
What system this component lives in, what design tokens apply, what the output format must be. The AI needs to know the rules of the world before it can build in it.
Element 02
Structure Spec
Exact HTML structure — element types, class names, nesting hierarchy. Not a description of what it should look like. A blueprint of what it should be.
Element 03
Visual Rules
Token values, spacing, typography, color — either referenced by name (var(--sapBrandColor)) or as explicit values where precision matters.
Element 04
State + Interaction
Hover, active, selected, disabled states. What changes and how. Without this, the AI produces static HTML that breaks when a user touches it.
"The difference between a good vibe-coding session and a frustrating one is whether you know what you're building before you start prompting."
The fifth element — which is harder to systematize — is knowing what to watch for in the output. Token drift, semantic HTML errors, missing ARIA attributes, layout logic that breaks at a non-standard viewport. These don't always show up in a visual review. You have to read the code.
04 / 06
Custom AI Skills
The leverage problem with AI-assisted building is that context doesn't persist across sessions. Without a memory layer, every build re-establishes the same design system rules, token conventions, and component constraints from scratch. Skills solve this — they're structured knowledge files that load as session context, so every build starts from a known baseline instead of zero.
SAP Icon Skill
Complete reference for all 700+ SAP-icons: codepoints, HTML entities, CDN paths, font-face declarations, and rendering patterns. Any build that needs an icon queries this skill — no manual lookup, no hardcoded unicode.
"/sapicon search arrow" → returns all arrow icons with entities
Design Guide Skill
Full Horizon, Quartz, and Belize token tables — brand colors, button states, field styles, shell tokens, spacing scale. Queried inline during every Fiori demo build to ensure token accuracy.
"/design-guide button" → exact token values for all button variants
BN Shell + Nav Skill
Reference implementation for the SAP Business Network ShellBar and side navigation — canonical HTML structure, exact Horizon tokens, collapse behavior, icon rendering via IconPool.
Paste as base shell for any BN demo page — no re-prompting required
Filter Bar Rules
Locked CSS classes, field types, action button patterns, and DynamicPageHeader integration for BN filter bars — sourced from the canonical reference file and memory-persisted across sessions.
Prevents AI from reverting to OverflowToolbar pattern on each new session
SyncoPro Evolution Engine
A meta-skill for SyncoPro product development — session memory, test orchestration, phase verdicts, and evolution tracking. Turns each Claude session into a continuous product development loop.
Product decisions compound across sessions instead of resetting
Why skills matter: Without persistent context, every session starts from zero. The AI has no memory of the design system you're working in, the component rules you've locked, or the decisions you've made. Skills are the fix — they're the shared memory that makes vibe coding a system rather than a series of one-off prompts.
05 / 06
How This Connects to Design Work
The design-to-engineer handoff is a feedback latency problem. Decisions made in Figma don't surface as real behavior until they've been handed off, specced, built, and reviewed — often weeks later, when they're expensive to change. AI-assisted building eliminates the gap. The same session that produces the design spec produces the working artifact.
The skills required are the same — design system literacy, layout logic, component state modeling — applied at a different speed and without the dependency on a separate implementation track.
Traditional
Design → Handoff → Build
Design intent translated into specs, handed to an engineer, built in a later sprint. Feedback loop is slow. Decisions made in Figma don't get tested in the browser until they're expensive to change.
Vibe Coding
Design → Prompt → Ship
Design intent translated directly into a working build. Designer reviews the output in a browser, not a mockup. Feedback loop is same-session. Decisions get tested immediately.
Where It Matters
Demos, Prototypes, Infrastructure
Not every product needs this. But demos, portfolio work, and internal tools — where speed and fidelity both matter — are exactly where AI-assisted building outperforms traditional workflows.
The constraint: this only works when the designer understands the technical substrate well enough to prompt precisely and review accurately. Vibe coding without design system literacy produces visually plausible but structurally incorrect code. The skill is in both halves.
06 / 06
Execution Principles
These are the structural patterns that hold across every build — not reflections, but constraints that govern how the system is used reliably at scale.
AI is a collaborator, not a generator
The best builds come from a real-time dialogue — give structure, review, correct, iterate — not from one long prompt and hoping the output is right. Treat it like pair programming, not autocomplete.
Average SAP Fiori demo: 30–50 exchanges across a session
Reusability requires investment upfront
Building the first filter bar from scratch took 3 hours. The twentieth took 15 minutes. The delta is in the CSS classes, skill files, and prompt templates built during those first builds.
BN filter bar skill: source of truth for every subsequent demo
Specificity beats length
A 4-line prompt with exact class names and token values produces better output than a 20-line prompt describing visual intent. The AI doesn't need vision. It needs constraints.
"Use .bn-filter-field, 223px width, flex-direction:column" vs "make it look like the SAP filter"
The hardest part is not the code
The hardest part is defining what you're building precisely enough that the AI can build it correctly. That's a design skill. The code is the easy half.
Most rework comes from under-specified prompts, not AI capability limits