My portfolio had been quietly embarrassing me for a while. It was a static site — the kind of thing you build once, feel proud of for three months, then let drift. The work section hadn't been updated in over a year. The design was fine in a "template I found once" way. And there was nothing on it that showed how I actually think.
I'd been helping organisations build technical learning systems for 15 years. The portfolio didn't reflect any of that. It was a work history with some project thumbnails. A CV with a domain name.
So I rebuilt it — from scratch, using AI as a real collaborator, not as a shortcut. Two hundred commits later, this is what that actually looked like.
Why from scratch, and why AI
I could have picked a template and swapped in content. That would have taken a weekend. But I wanted to understand what I was building — every layout decision, every component, every line of JavaScript. I've spent years telling clients that understanding the architecture of your learning technology matters. I figured the same principle applied here.
Using Claude Code as a collaborator wasn't about generating a site. It was about having a thinking partner who could hold technical context while I focused on design and content decisions. I directed the work. The AI handled the implementation speed. The combination let me build something more ambitious than I'd attempt alone in the time I had available.
What 200+ commits actually represents
The number sounds impressive. It's also slightly misleading. Let me break down what's inside it:
The real commits
Probably 40% of those commits are genuine feature work — building the dual editorial/visual view system, the articles infrastructure, the newsletter integration, the contact form, the Storyline 360 demo pages. Things that required actual design thinking and back-and-forth iteration.
The fix commits
Around 30% are fixes. Mobile layout breaking on specific viewports. A Google Analytics tag in the wrong place. A hover state that looked wrong in Safari. Navigation that worked on desktop but collapsed oddly at 768px. These aren't embarrassing — they're just what happens when you're testing against real browsers and real screen sizes instead of a localhost preview.
The lesson I didn't expect: AI writes code faster than you can test it. The bottleneck isn't generation — it's verification. Every feature that took 10 minutes to generate took 30 minutes to test properly across devices and edge cases.
The exploration commits
Maybe 30% are exploratory — directions I took, lived with for a day, and then backed away from. A sidebar navigation that made sense architecturally but felt wrong visually. A colour scheme I liked at 11pm that I didn't like at 9am. A JavaScript approach that worked but that I couldn't explain clearly, so I replaced it with something I could.
These commits are not wasted work. They're how I understood what I actually wanted.
What AI-assisted development actually looks like
The marketing version: you describe what you want, the AI builds it, you ship it.
The real version is more interesting and more effortful than that.
Context is the actual work
The quality of what AI builds is directly proportional to the quality of context you provide. That means before every session I needed to know — precisely — what I was trying to build, what constraints existed, and what decisions had already been made. Vague prompts produce technically valid but architecturally inconsistent code. I learned this the hard way around commit 40.
Maintaining that context across sessions is its own skill. I started keeping a running document of design decisions — not for the AI, but for myself. What pattern am I using for this? Why did I choose this CSS variable structure? What's the rule for when something goes in the editorial view vs the visual view? Without that, the AI would give me reasonable answers that contradicted decisions I'd made two weeks earlier.
You still need to understand the code
I can't stress this enough. If you don't understand what's been generated, you cannot debug it when it breaks. And it will break — in the specific, unpredictable ways that real browser environments surface.
There were moments where I asked for something, got a solution that looked right, shipped it, and then watched it fail in a specific browser or at a specific screen size. Understanding what the code was doing — even at a surface level — meant I could describe the failure accurately enough to get a real fix rather than a patch that introduced a new problem.
The engineers I've worked with for 15 years would recognise this pattern immediately. AI is a very capable junior developer. It writes fast, it doesn't get tired, and it has broad knowledge. But it needs direction, review, and someone who understands the system well enough to catch what it gets wrong.
The hallucination problem in front-end work
Language model hallucinations in code tend to be subtle and plausible. Not nonsense — plausible approaches that are slightly wrong for your specific context. A CSS property that works in one browser but not another. A JavaScript method that exists but doesn't behave as described for edge cases. An API pattern that was deprecated in the version you're actually using.
The filter for this is always: test it. Not just in the preview. In the real environment, on mobile, in Safari, with a slow connection. Hallucinations that survive that filter don't matter. The ones that don't survive are your problem to catch, and you can only catch them if you're actually testing.
What I built that I'm actually proud of
The dual-view system
Every page on the site exists in two forms — an editorial view (dark navy hero, linen body, serif typography) and a visual view (inspired by the kawe.ski design system, bright and bold). A fixed pill switcher in the corner lets you move between them. Session storage remembers your preference across pages.
This wasn't a vanity feature. It's a demonstration of a real capability — understanding that the same content can serve different audience expectations, and building a system that handles both without duplicating the content. That's an instructional design principle applied to a portfolio. I wanted recruiters who care about aesthetics to see the visual view. I wanted engineers and L&D practitioners to see the editorial.
The articles infrastructure
This newsletter you're reading exists as a proper editorial system now — not just LinkedIn posts, but dedicated article pages with full content, code blocks, SVG diagrams, and callout boxes. Each article is also mirrored in the visual view. It took longer to build than I expected and is more useful than I expected.
The Storyline 360 demo toolkit
Eight interactive demos, each documented with a dedicated case study. Custom notepad component, theme switcher, progress bar, video compliance tracker, speech-to-text, guided tour, PDF certificate generator, zoom and pan. Built inside the portfolio itself, not as separate links to external platforms.
What I'd do differently
Start with the content, not the design. I spent early sessions on visual decisions that changed three times because I hadn't yet decided what the site was actually for. If I'd spent the first two weeks writing all the case studies and articles, the design work would have been faster and more decisive.
Commit smaller. Many of my "fix" commits are patching things that a smaller, more focused original commit would have caught earlier. The discipline of small, atomic commits isn't just a Git hygiene thing — it's a thinking tool. It forces you to finish one thing before starting another.
Test earlier on mobile. I left mobile testing too late twice, and both times it required reworking decisions I'd already made. Mobile-first isn't just a responsive design principle — it's a constraint that clarifies design decisions before you've overcommitted to desktop assumptions.
What 15 years of L&D actually added
Here's the thing I didn't expect: domain expertise is a significant advantage in AI-assisted development. Not because AI knows less about code — it knows more. But because knowing what you're building, who it's for, and what it needs to communicate gives you the judgment to direct the work well and to reject output that's technically correct but wrong for the context.
Every decision about information architecture — what goes where, how navigation should work, what a case study needs to contain — was faster and more confident because of 15 years of thinking about how people process information. The AI could implement. I knew what to implement.
If you're thinking about rebuilding your portfolio and wondering whether to use AI for it — the answer is probably yes, but not in the way the demos make it look. Happy to talk through how I approached it: connect on LinkedIn.