Building a website with Claude: what I learned about AI-assisted development

My original personal website was built in 2015. It used jQuery. It worked fine, loaded quickly, represented me accurately — for 2015. But I'd spent the decade since building complex Angular applications at IBM, ADP, Vanguard, and NBCUniversal. I knew CSS Grid, custom properties, fluid type scales, the View Transitions API, scroll-driven animations. My site showed none of that. It was a résumé that undersold the person it was supposed to represent.

So I decided to rebuild it. And I decided to do it entirely with AI-assisted development — from the first concept conversation to the last deployed file — partly because I wanted to see what the process was actually like, and partly because if I was going to put a portfolio in front of potential employers, I wanted it to demonstrate that I could work this way.

What followed was one of the more interesting experiences I've had as a developer. Not because the AI wrote the code — it did, mostly — but because of what the process taught me about my own assumptions.

I expected to be the manager. I ended up being the collaborator.

Going in, I had a clear mental model of how this would work: I'd explain what I wanted, Claude would generate code, I'd review it, correct it, and direct the next step. I'd be the director. The AI would be the executor.

That's not what happened.

What emerged instead was something closer to a genuine creative partnership. We workshopped the headline concept across three rounds of iteration — I'd push back on directions that felt wrong, Claude would push back on mine, and we'd arrive somewhere neither of us would have landed alone. The animated hero headline — "Crafted code." cycling through "code," "prose," and "images" — came out of exactly that kind of back-and-forth. It started as three static lines, became a repetition structure, then collapsed into a single line with a rotating word when I realized the repetition was visually cluttered but the concept was right.

I genuinely did not expect to enjoy the process as much as I did. The brainstorming phase in particular felt energizing in a way that solo work often doesn't. There's something about having another perspective — even an artificial one — that makes you sharper about your own preferences. You figure out what you actually want faster when you have something to react to.

The friction was real — and specific.

I should be honest about what didn't work.

The most frustrating part of the process was the separation between Claude Chat and Claude Code in the Claude app. Using Chat for planning, brainstorming, and design decisions is genuinely intuitive — it's a great thought partner, it holds context well, it can workshop ideas across multiple rounds without losing the thread. But Chat isn't agentic. It can't reach into your codebase and make changes directly. At some point you realize you've been having a great conversation about a design decision and now you have to manually copy the output, find the right file, make the edit, and come back.

Claude Code solves the agentic problem — it can actually manipulate files — but the transition between the two modes isn't seamless. You lose the conversational context, the workshopping flow, the sense of continuity. It felt like having a great creative session with someone and then having to fax them the results before they could act on it.

I suspect this is a tooling problem that will get solved. But right now, in 2025, it's a real friction point in the workflow — and I say that as someone who found the overall experience positive enough to write about it.

The thing I had to unlearn.

Here's the part I've been thinking about the most since finishing the project.

I had to very intentionally shift how I thought about my role as an engineer. Before this project, I'd never examined it — my default assumption was that my job was to identify a problem and then write the code to solve it. Those two things were inseparable in my mind. The problem-solving and the code-writing were the same activity.

They aren't. Solving the problem doesn't require writing the code yourself. Code has to be written, but that doesn't mean you have to write it — or write every line of it by hand. I had to start thinking of myself differently: not as an engineer who writes code, but as someone who builds software. Someone who solves problems with software as a medium.

The part of the job I was holding onto hardest — the part I think most developers build a significant part of their professional identity around — was writing code. And working through this project made me realize that in many ways, that was the least important part. The architecture decisions, the design system, the accessibility considerations, the CSS token hierarchy, the content strategy, the ability to recognize when something isn't working and articulate why — that's where the real work lives. The code is how you express it.

This isn't an argument that code doesn't matter or that craft is dead. It's the opposite. The craft moves up the stack. You still need to know what good code looks like. You still need to be able to review it, catch its mistakes, understand its tradeoffs, and push back when it goes wrong. The technical knowledge doesn't become less important — it becomes more important, because now it's applied at the level of judgment rather than execution.

What I'd tell a skeptic.

I know some developers reading this will find it threatening. The instinct to dismiss AI-assisted development as shortcut-taking that produces mediocre work — I understand it. I felt versions of it going in.

But the site you're reading right now has a three-layer CSS token architecture, a fluid type scale built entirely with clamp(), scroll-driven animations using animation-timeline: view(), View Transitions API for cross-page fades, a Web Animations API headline rotator with a Page Visibility reset, and a custom cursor with requestAnimationFrame lerp smoothing. None of that happened because I typed less. It happened because I could think at a higher level of abstraction about what I was building and why — and execute more ambitiously than I would have if I'd been working alone.

The work is still crafted. It just took a different kind of craft to get here.

The source is public on GitHub if you want to look at what we actually built.