Building this portfolio with an AI-assisted workflow
What moved faster, where judgment still mattered, and why every reversible decision was documented.
This site did not start in Figma. It started in a chat window, with me trying to explain what I wanted before I knew what it looked like. A little over a week later it was live.
Starting with words instead of screens
I opened ChatGPT and gave it everything I had. Sites I liked and why. What the portfolio needed to do for someone skimming it between meetings. Who I am, what I am drawn to, the kind of work I want next. Less of a prompt, more of a long brief written out loud.
Writing it down was useful before anything visual existed. It forced me to say what the site was for, which later became the thing I measured every idea against.
Letting it go looking on Mobbin
Then I asked it to pull references from Mobbin and come back with directions rather than a single answer. That is where the first real theme appeared: the warm porcelain field, the soft-black type, the idea that the page should feel calm and instrumented instead of loud.
I would not have landed there by browsing on my own. I would have picked whatever looked impressive that week.
Into Figma, with the models wired in
With a theme to work from I moved into Figma and connected it through MCP. That built out the bones: the design system, the type and colour decisions, the layout logic, the tokens that everything else would inherit.
It was fast in a way that still surprises me. It was also where I learned to be careful, because a system built that quickly can look finished long before it is actually considered.
Two models, marking each other's work
In code I ran Codex and Claude Code together, and the useful part was not having two assistants. It was having each one audit what the other had written. Whichever model had not produced the code was better at finding what was wrong with it, because it had no investment in the approach.
That loop caught a lot before it ever reached me: dead styles, a canvas animation that silently stopped after a few minutes, labels that had drifted below a readable size, accessible names that no longer matched their visible text. Less broken code arrived at my end, so the attention I had left went to whether the thing was any good rather than whether it worked.
Skills are the part I would not skip. They package a standard into something a model runs against its own output, so accessibility, motion performance, metadata, SEO and performance all got audited as a matter of course rather than whenever I remembered to ask. The same habit applied to the site as a whole, with Lighthouse and SEO passes run against real builds instead of assumed.
Then into code, where most of it got decided
Once the basics were chalked out I kept designing in the codebase. Mobbin came back out constantly at this stage, not for whole layouts but for specific problems. How does a good index row handle its metadata. What does a confirmation state look like when it has to feel like a real answer. How much shadow is too much.
Most of the work was small: a border that was too hard, a label two pixels too small to read properly, motion that looked good in isolation and wrong in sequence.
Some of it was not small. The desk in the homepage hero started life as one generated image, and it fell apart the moment it was scaled across the width of the page. I rebuilt it from five separately exported objects, lit to match, each one displayed well below its native size. That is the kind of problem you only find by putting the thing on a screen and looking at it properly.
- Repeated the next section
The homepage opened with an interactive stack that led to the same three projects listed right below it.
I swapped it for one shipped product, so actual work shows up before any scrolling.
- Motion got in the way
Per-element reveals made text flicker and the scroll feel unsteady.
Content now starts visible, and the motion that survived is short and skippable.
- Polish drifted
Each new section quietly invented its own type sizes, shadows and spacing.
I pulled it back into tokens and wrote down one light source, one type scale, one job for orange.
“The tools were quick at producing options. Deciding which ones were any good stayed slow, and stayed mine.”
The pull toward the middle
This is the part nobody warned me about, and the part I would tell anyone starting now. However sharp the early output is, keep going and the suggestions begin drifting toward the safe centre. A cleaner type scale that happens to be the one everywhere else. A hero arrangement you have already seen this month. Nothing arrives looking like a mistake, which is exactly why it works on you.
I think this is where most people give up on the approach or start over by hand, and conclude the tools cannot do taste. What actually happened is that the tools were doing what they do, and there was nothing firm enough on the other side to push back.
So it demanded something I did not expect: a clearer idea of what I wanted than I would have needed building this by hand, and the willingness to keep saying no to reasonable suggestions. I asked for the original type system back when a replacement made the site feel like everyone else's. I removed an underline treatment I had requested two hours earlier because it was fussier than the page needed. I reverted a layout fix that solved the measurement and made the section worse.
None of that was tidying up after the real work. That was the work.
What the tools were genuinely good at
- Looking: surfacing references I would not have found, and explaining what made a composition work.
- Building: turning an agreed layout into responsive code fast enough that I could judge it in a browser instead of in my head.
- Auditing: checking each other's output, then running accessibility, performance and SEO passes against real builds, so a visual tweak did not quietly break a page.
- Remembering: keeping a build log, so I could tell later why something had been tried and dropped.
What I would keep
Just over a week from a blank chat window to a live site, and the slowest stretches were usage limits rather than anything about the work. The speed is real. It is also the least interesting thing here.
The part worth keeping is the way of working: write the brief before the interface, look widely and early, build fast enough to test, have the models check each other, and hold a clear enough picture of what you are making to notice when you are being walked toward someone else's version of it.