Build Website
An exploration of how AI merges in daily work
Background
When building my personal website, I did not consider it solely as a portfolio. I treated it as a place to develop my AI capabilities. The final output is still a portfolio rather than an AI product, but AI Native Thinking can be used to continuously improve how it is built and maintained.
Here, I divide AI Native into two evaluation axes: Product concerns the experience end users receive, while Workflow concerns how producers complete their work. The former asks whether AI is part of the product’s capabilities; the latter asks whether AI is part of an ongoing production process. The two can hold independently.
| Workflow / Product | Non-AI-native product | AI-native product |
|---|---|---|
| Non-AI-native workflow | The product does not depend on AI capabilities, and production follows a conventional process | The product includes AI capabilities, but production still follows a conventional process |
| AI-native workflow | The product does not depend on AI capabilities, but production includes AI planning, execution and human feedback. This is the combination explored here | AI is part of both the product experience and its production process |
Even when the final output is not an AI Native Product, the complete interaction loop from user intent to AI execution still matters, including Agent Work Flow, AI Autonomy, Human-in-the-loop, verification and error correction. Through countless iterations, I continuously improve the process so it can ultimately be used proficiently in real commercial collaborations.
A new workflow
In this exploration, I am responsible for goals, trade-offs, taste and final approval. Within an agreed scope, AI reads the context, makes a plan, acts in the content, design or development workspace, and returns an inspectable result. It does not have to restart from scratch every time; a change can begin in the workspace that needs adjustment.
- 01Shared context
Figma assets, task scope, acceptance criteria
The checkpoints do not require a person to review every tool call. They focus on changes to goals or authority, facts entering the public narrative, proposals entering the current product, and release. Implementation and checks can continue within scope; missing material or conflicts require a pause. The content workspace still follows master approval and source synchronization rather than generating facts directly from a temporary conversation. Content or Figma asset tasks can return independently for review; development is needed only when building a page or runnable prototype. Dashed paths in diagram B represent conditional steps or next-task reads, not an autonomous background process. Without release authorization, local delivery is the endpoint for this cycle.
Conventional workflow
AI-native workflow
Working environment and feedback loop
Harness Engineering centres on giving the model an environment and constraints in which it can keep working. Progress records, incremental work and testing for long-running tasks are central topics in official engineering practices. Anthropic：Effective harnesses for long-running agents This project has similar supporting practices: Obsidian helps establish the working environment; CURRENT_SYSTEM describes the current implementation, Skills and scripts provide methods and checks, and task records and Git retain progress. AGENTS and governance documents provide constraints on authority and product boundaries.
Loop Engineering here is a human-involved execute → check → review → correct cycle. AI can continue acting on feedback, but I still confirm adoption decisions and scope expansion. Anthropic：Building effective agents
From intent to execution: eight questions to answer
- 01 / USER INTENTWhat does the user want to accomplish?
- Improve the website and develop a reusable way of working—not merely generate a first page.
- 02 / CONTEXTWhat must AI know?
- Approved facts, the current implementation, Figma assets, task scope and what must remain unchanged.
- 03 / AGENCYHow far may AI act?
- Explore, implement and check within scope. People decide on scope changes, adoption and release.
- 04 / WORKFLOWHow is the task decomposed?
- Route factual, visual and implementation work to content, design and development. Not every task needs code.
- 05 / INTERACTIONHow can people intervene?
- Use goals, references, browser comments and runnable comparisons to give feedback, change direction or stop.
- 06 / VERIFICATIONHow is correctness judged?
- Check sources, component states, responsive behaviour and runtime results. Passing checks does not replace design judgement.
- 07 / RECOVERYWhat happens after an error?
- Return the issue to its workspace; retain historical versions and change records. Pause for missing context or conflicting changes.
- 08 / MEMORYWhat context should remain?
- Approved facts, current state, adoption decisions, failure reasons and sources—not every temporary output as a permanent rule.
What changed through this process?
Rapid prototypes bring judgement one step closer to the real product. During the design-system exploration, I compared multiple directions in the same browser environment and retained V1 and V2 for comparison. Type, whitespace, surfaces and interactions could be inspected in runnable pages, helping me judge what suited the website.
The concept appeared; the priorities did not
The Folder, capability tags, identity card, and Canvas metaphor competed for attention. Mobile simply stacked the entries in sequence.
Turn “it feels wrong” into locatable problems
The review identified an unclear project entry, decoration competing with content, and a mobile experience that asked users to process equal-weight choices before seeing real work.
Show projects first, then offer classification
The Folder became the primary object, Selected Work gained an explicit path, and capability tags moved into a supporting role. Mobile moved projects forward and compressed capability cards into lighter navigation.
Design is therefore no longer only an upstream handoff before development. I still define the direction early, and become the final gatekeeper once the product can run: judging which generated results are worth keeping and which must be sent back.
How is this different from using AI in a chat?
What does AI-native mean here?
Here, AI-native describes how the work is organized. AI can read project material and edit design files or code, but must first know which facts are confirmed, what it may change, and who reviews the result. Sources and decisions stay in the project so another agent can consult them.
| Scope | Conventional AI | AI Native | This project |
|---|---|---|---|
| Work output | Deliver a final answer while most process information stays in the chat | Keep the output, change records, and review decisions for the next task to inspect | Facts live in the master, visuals in Figma, code changes in Git, and review decisions in return reports |
| Project memory | Explain the background again when a new conversation starts | Before starting, a new agent reads the confirmed material, current progress, and allowed scope | The master holds facts, governance defines boundaries, CURRENT_SYSTEM describes the implementation, and Git records changes |
| Agent collaboration | Give multiple tools the same broad prompt, or ask one model to perform every role | A handoff specifies the sources, permitted changes, checks, and required return material | Codex organizes the Figma task; WorkBuddy executes it; I review the returned structure and visuals |
| Method reuse | Rewrite the prompt each time and keep experience in personal memory | Record repeated operations as reusable steps or scripts, and correct them when problems emerge | Skills store review and Figwright steps; scripts check content sources |
| Uncertainty | Treat generated output as ready to enter the current product | Test a new proposal separately before deciding whether it enters the website; confirm any expanded scope | Candidate pages have separate routes and Figma has a pilot page; review diffs before accepting or returning the work |
| Quality continuity | Judge each output independently, so good decisions do not reach the next generation | Save accepted color, typography, and composition decisions for the next generation to use and check | Review the design system alongside a real page to check that the new result preserves confirmed design relationships |
How is the Harness environment set up?
| Scope | Purpose | Implementation |
|---|---|---|
| Memory | Make facts, rules, current state, and historical evidence readable across sessions | An Obsidian master, governance documents, CURRENT_SYSTEM, task records, Skills, and Git each hold information with a different lifetime |
| Governance | Tell an agent what can change, what must remain, and where a reusable rule belongs | AGENTS.md, Portfolio OS, domain protocols, task briefs, and audits are separated by scope |
| Skill | Separate repeatable methods and deterministic operations from one-off prompts | Review Skills, Figwright operating knowledge, UI-verification methods, and content/source scripts |
| Content pipeline | Keep facts, curation, translation, and page presentation traceable | Obsidian factual master → owner approval → selection and assets → bilingual TypeScript → project page → local review |
| Sandbox | Separate low-cost experiments from accepted product work | Isolated routes, Figma pages / collections, authority boundaries, Git diffs, and recovery records; accepted changes enter the current implementation as bounded diffs |
| Projects / Tags | Keep product entities and classification relationships correct | A Project owns the body of work, assets, and case study. Tags support discovery without replacing project identity |
Governance: keep each rule at the right scope
This table separates long-term boundaries, this task, and historical evidence. An agent can see what may change without treating an audit as a new rule.
| Scope | Rule home | Purpose |
|---|---|---|
| Shared across tasks | AGENTS.md | Working boundaries every agent must understand before taking over |
| Long-term product boundaries | Portfolio OS | Product direction, information architecture, and decisions that cannot change implicitly |
| Domain-specific practice | Domain protocols | Methods for content pipelines, design systems, and other owned areas |
| Repeatable method | Skill / script | Operating steps, checks, and known limitations |
| Current task | Task brief / handover | Goal, authority, acceptance criteria, and required return material |
| Historical evidence | Audit / return report | A record of what happened, not an automatic new rule |
The biggest challenge: AI as infrastructure
The biggest challenge in a fully native design process is making AI infrastructure, allowing it to enter at any stage of the process.
For AI to enter different stages, the difficulty is whether it receives the right context, knows what it may change, and returns results that can be judged. Completing an operation does not mean it understands the design intent.
Make the design system readable by both people and AI
I want the design system to show the effect and explain its underlying rules: why a layout works, when a component is used, how an interaction enters and exits, and which tokens and assets should be reused.
Design intent is for AI to read; the displayed effect is for people to see. Design rules, interaction semantics and Design Tokens are deeply integrated with MCP so AI can understand the intent and generate automatically. Design System V2 is a visual window for defining rules, prototyping compositions and discussing design intent. It brings explanations, state samples and runnable demonstrations together.
Second design: a good page is not yet a good system
The early design system contained colour swatches, type styles, and components, but it did not preserve the relationships that produced quality in the website.
The colours matched; the page was still rigid
The Figma draft kept approximate colours and flat blocks while losing whitespace, image scale, light–dark rhythm, and reading order.
Token and component counts cannot stand in for completion. The system has to compose a representative page with real content.
The names matched; the bindings did not
The JSON import first produced invalid variable names. The Semantic layer then stored primitive names as STRING values instead of referencing primitive COLOR values.
Inspection has to reach the real data type and alias. A complete-looking list of names is not enough.
During / Interaction specification still missing
- Trigger
- Entry
- Stable state
- Exit
- Touch alternative
- Reduced motion
The styles existed; the interaction did not
A gradient, type size, and duration do not specify trigger, entry, stable state, exit, touch alternatives, or reduced motion.
Motion needs state relationships. A static Hero fallback cannot be presented as a complete reproduction of the WebGL light field.
Primitive → Semantic Paint Style → Manual CSS mapping → Page review
- Inuse-Primitive-colorsStore real primitive COLOR values
Keep numeric names and avoid assigning text or border semantics at the primitive level
- Semantic Paint StylesExpress text, surface, action, and border use
Light / Inverse describe usage context rather than pretending to be an automatic mode system
- Inuse-dimensionsStore accepted size and spacing values
Use integers in Figma instead of reproducing every fluid CSS value
- Text / Effect / Grid StylesCompose typography, shadows, and column grids
Create variables only where reuse warrants them; apply semantic Paint Styles to text colour separately
- Representative pages and statesTest how the assets work together
Do not review the variable inventory without real content
No duplicate Semantic Color variable layer. Light / Inverse describe usage environments, not automatic modes.
Design System V2
The current local system brings tokens, component states and composition examples together for review. Figma-to-CSS mapping remains manual.
Explore Design System V2Bidirectional mapping between Figma and code
Compare the Figma component library with code exports, record identities, properties and differences, then look up the corresponding objects in both directions. The current six local mapping rows cover four code targets; three Draft Button size sets share one Button.
Bidirectional mapping between Figma and code lets designers make targeted improvements in Figma and synchronize them to code. Once code produces the complete content, the verified content can be updated back into Figma.
Next steps
Complete the property, token and state comparison between Figma and code for one real component, verifying local consistency first.
Observe whether subsequent repeated tasks correctly reuse confirmed rules, retaining both successful and failed records.
Trial a single-component detect differences → human confirmation → update one side → verify synchronization experiment, then decide whether to expand its scope.