Alibaba Internship
Introduction
Over the summer I spent three months interning at Alibaba’s AliExpress, working on influencer and user-growth briefs. I shipped five projects, and used every one of them to push on the same question: what AI can actually do inside a design process, rather than in a demo. This case is where that went furthest.
IMPACT
Shipped 5 projects
Built an AI design workflow
TIMELINE
May 2026 - Aug 2026
DOMAIN
User Growth
E-Commerce
AI Agent
OVERVIEW
How I used AI, project by project
I see myself as a non-traditional designer who knows AI well. On each project I used it differently, depending on the business constraints and what the brief actually needed.
Image gen
Image 2
Nano Banana 2
Video gen
Seedance 2.5
UI gen
Opus / Fable
Dev
Opus / Fable
Cheap model for execution
Examples from my internship projects:
The project
Showcase: rebuilding pages, business logic and user flows straight out of the codebase
BACKGROUND
Where the work now starts
Design used to begin in Figma. It now begins with whatever HTML I can get hold of — and that swap is where everything breaks.
BEFORE AI
Ask for the source files
→
Design in Figma
→
Hand off Figma
WITH AI
Get HTML somehow
→
Vibe-code on top of it
→
Hand off HTML
Every step of the new lane has a tax
And each one gets worse the moment a brief arrives with dozens of interaction pages in it.
Get HTML
Days before design starts
Conversions are inaccurate, front-end needs a page list and mock data, doing it yourself means test logins.
Vibe-code
The whole front of a project
The model knows nothing about the business, so PRD and background go in piece by piece.
Hand off
Nothing you can show
The flow scatters across files. You open them one at a time and talk over them.
So the tool had to do three things — and each one is a section below
FINAL DESIGN
01
EVERYTHING AT ONCE
One pull, every page
The whole live surface comes back from the repository in one run, complete enough that nothing goes missing by hand.
Every live page of the influencer platform, recovered from the front-end code.
Each page can be pulled out as clean HTML, ready to hand to a model or a developer.
02
CONTEXT INCLUDED
The context comes with it
Business logic is inferred from how the code actually renders, and the design system is derived rather than re-documented.
Every UI decision in the product, collected onto one page — straight out of the code.
03
ORGANISED VISUALLY
Organised so you can see it
Pages by hierarchy, states by blast radius, flows split into main and branch — plus versions and branches on top.
Pages, arranged by their parent–child relationships.
States, grouped by how far they reach and what they sit inside.
User flows generate themselves, split into main and branch paths.
Two views of the same flow: collapsed, or every decision laid flat.
Versions and branches sit on top, so who changed what stays answerable.
ITERATION · EXTRACTION
The scan kept reporting success
Let the model plan its own scan and it misses things, then prints “success” anyway. Looping it until it stops missing does not work either.
scan complete — 0 misses
45 types / 187 values · success
42
values it never found
22%
of the enumeration missing
0
of that in the report
The scanner grades its own homework, so its “success” is not evidence of anything.
The root cause
WHY IT KEPT MISSING
The model did not know what to scan. Nothing told it what makes a page, a state, a piece of business logic or a flow — so it could not know what it had skipped.
Survey first, then scrape
I put a stage in front of the scrape: map the repository, then pull from it. The order cannot be reversed.
WRONG
Scrape
→
Self-check
→
Ship
✗ Still missing 42 values, and the run says it is fine.
RIGHT
Survey the repo
→
Scrape
→
Closure gate
✓ Each of the 18 layers has its own gate, and the run exits when it cannot show its work.
What that bought
53%
V1 · no survey, one layer
55%
V2 · survey, eighteen layers
100%
V3 · code-derived, a gate per layer
File closure on the state-type scan. The jump is not a better scanner — it is the gate.
ITERATION · PIPELINE
Five skills, one flow
Each stage is a skill with a defined output, so a run is repeatable instead of improvised.
IN · an unfamiliar repo
→
5 skills
→
OUT · pages × states you can present
01
Onboard
Naming, source, owner, scope
02
Extract
Pages, states, logic, flows
03
Port
Components 1:1, pixel-diff
04
Model
Pages × states, collisions
05
Showcase
Three layers, presentable
ITERATION · LAYERS
The bug that came from editing the master
Open a second branch of the restaurant, edit the master recipe book to suit it, and the original dish stops coming out right. Same failure here.
What happened
A designer edited the scraped baseline directly, because it was the file sitting right there.
Why it mattered
The baseline stopped being a snapshot of the code, so every fidelity proof made against it was void.
Three layers, one of them writable
Read the stack from the bottom: the machine owns ① and ②, and a person may only ever touch ③.
IMPACT
What it takes off the clock
Same brief, three eras. Estimated person-days for one designer taking a feature from context to hand-off.
STAGE 1
Pre-AI
STAGE 2
AI era · without Showcase
STAGE 3
AI era · with Showcase
01
Getting context
Find the old PRD
0.5
Ask the last designer for files
0.5
Total
1.0
Find the old PRD
0.5
Get / generate all related HTML
1.0
Total
1.5
Browse related pages in Showcase; ask the AI
0.5
Pull all related HTML from Showcase
0.0
Total
0.5
02
Designing
Design in Figma
10.0
Build a prototype
1.5
Total
11.5
Feed the AI business + design-system context
3.0
Vibe coding / designing
2.0
Total
5.0
Branch and version, guided by the AI
0.5
Vibe-code on what Showcase holds
2.0
Total
2.5
03
Handing off
Draw the flow
1.0
Mark up specs
0.5
Total
1.5
Collect the HTML into one file
0.5
Screenshot into Figma as a flow
1.0
Total
1.5
Delivery report generates itself
0.0
Flow generates itself
0.0
Total
0.0
04
Design QA
Page-by-page walkthrough, filing bugs
1.0
Total
1.0
Deliverable is the code — fidelity is high
0.1
Total
0.1
Deliverable is the code — fidelity is high
0.1
Total
0.1
Total
15.0
person-days
8.1
person-days
3.1
person-days
A live project it is already carrying
Influencer, affiliate and live were three separate products. They are being merged into one so shared capability is built once and the architecture is common.
Influencer platform
100–200 pages
Affiliate channel
100–200 pages
Live platform
100–200 pages
→
One platform
Shared capability built once
One core architecture
Projected person-days across the merge:
STAGE 1
Pre-AI
STAGE 2
AI era · without Showcase
STAGE 3
AI era · with Showcase
150
person-days
81
person-days
31
person-days
REFLECTION
“That is not buildable”
The first extraction runs were bad enough that engineering wrote it off. But a thing that works in theory can ship — the rest is decomposition.
(
Dev
)
Easy to say. I do not think this one can actually be built.
If it works in theory it can ship. The rest is breaking it down.
(
Me
)
Page generation alone went through five rewrites before it held:
01
Hand-drawn HTML
02
Hand-labelled catalogue
03
Contract handover
04
Controlled DOM
05
Derived from the real components
What I actually learned
Three things that each cost me a day.
01
Know how the tool loads, not just what to prompt
Skills load from one specific folder. Anywhere else and whether your rules were read is luck.
02
A model’s search is not an enumeration
The agent reported 15 types and 50 values. Parsing the syntax tree found 37 and 145.
03
One rule, one home
Write the same rule twice and never read the output, and the two drift the moment either runs.