The interesting part wasn’t the model. It was designing what a visitor should notice, explore, and do next.
A few people assumed I rebuilt my portfolio using Claude Opus 5.5.
I didn’t.
I used a free AI model, worked in (its a secret service btw) instead of the coding tools people kept asking me about, and rebuilt the site in roughly half a day.
That sounds like a story about the model. It isn’t—not really.
The more interesting question is: when AI makes implementation faster, what makes the result feel intentional instead of merely generated?
For me, the answer was the experience around the code: what a visitor sees first, where a project link leads, and whether each page gives them a reason to keep exploring.
The page is designed to be scanned. The spacing separates groups; the headings create hierarchy; the links make the next move visible.
That is what I mean by spatial design here: arranging information on a two-dimensional page so it has a readable order and useful groupings. I’m not talking about 3D spatial computing, AR, or VR.
The visitor isn’t forced into one journey. They can read about me, browse projects, open a post, download the CV, or leave. That choice is a small but important part of the UX.
One small detail can also trigger curiosity. When a visitor sees a familiar reference such as ChatGPT in their Search Engine, they may want to find out what it means or explore the related project. I’ve heard that kind of reaction informally; I don’t have analytics proving that it causes searches or conversions. Curiosity is a useful design signal, but it is not the same as measured behavior.
That “next step” matters most on the Projects page. A project card should answer three quick questions: What is this? What did I build? Where can I inspect it?
A demo and a repository are different kinds of proof. One lets someone try the experience. The other lets them examine the implementation. Some of my projects have one link, some have another, and the interface should make that clear instead of pretending every project has everything.
The rebuild itself took about half a day. It doesn’t mean every asset, case study, deployment check, or follow-up improvement took only half a day.
The speed came from a combination: a clear enough brief, a free model that was useful for [tugas sebenarnya], and an editor that fit the way I wanted to work. I used Code Editor, not Antigravity or Claude Code (its a secret). That isn’t a claim that one tool is better; it’s a reminder that the outcome depends on the workflow and the decisions around the tool.
AI helped me move through copy exploration, component scaffolding, styling iterations, debugging, etc. I still had to decide what belonged in the portfolio, review the generated code, check the claims, and verify that the published links worked.
There’s another boundary I want to keep clear: the portfolio links to AI-related work, but it is not itself an embedded AI agent or multimodal application. It does not become Agentic UX just because one of its projects involves AI.
If I add an agent, voice interface, or image/audio interaction later, I’ll treat that as a separate product decision—with a task, user controls, failure handling, and testing. For now, I would rather describe what is actually there than decorate the story with a feature that isn’t.
The part I’m proudest of is not that a website can be rebuilt quickly. It’s that speed gave me more room to ask: what does the visitor need, and what should happen after they click?
You can explore the portfolio here: [https://kimsilalahi.vercel.app/].
What would you inspect first in this portfolio: the projects, the code, the visual hierarchy, or the route each call to action takes you through?
Top comments (0)