Skip to content
Popproxx brand logo in stylized cursive font.
Close-up of two pairs of clay-covered hands shaping a pot together on a potter's wheel

Building This Site With an AI Coding Agent

Jamin Giersbach

This website was rebuilt this year as a Next.js site, and most of the changes in its history credit an AI coding agent as co-author: Claude Code, made by Anthropic.

Here's why I did it, what the project's own record shows, and what it was actually like, including the parts that went wrong.

Why I rebuilt it

WordPress ran out of road. The Popproxx site had gotten complicated enough that I was pushing Elementor, the page builder it was made with, past what it was built to do, and propping it up with a growing pile of custom CSS. Every change got harder than the last. A layout tweak in one place would break something three pages away, and I spent more time fighting the page builder than building.

The bigger trigger was the customer side. I wanted a real sign-up flow and a client dashboard, and I was using SureCart for that. SureCart is a shopping cart, a good one, but it felt glued on, and there were things I needed during onboarding that it simply couldn't do. When I started sketching a proper control panel in Next.js, I realized it would live in a separate world from the WordPress marketing site: two systems, two design languages, duct tape in between. The obvious move was one codebase.

I'd also been drifting away from WordPress for a while. It feels dated to me, and it hasn't grown with how the web is built now. What I wanted was speed: have an idea on Tuesday, whether a feature, an integration or a design experiment like a gumball machine sign-up, and have it live on Wednesday. I've been coding since the mid-90s, so I'm not short on skill. I'm short on hours. The agent gives me the hours.

What Claude Code is

Anthropic describes Claude Code as "an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools" (Anthropic). The codebase is all the files a piece of software is made from.

"Agentic" is the important word. Anthropic's guide contrasts it with "a chatbot that answers questions and waits": Claude Code "can read your files, run commands, make changes, and autonomously work through problems while you watch, redirect, or step away entirely." The person's job changes with it: "Instead of writing code yourself and asking Claude to review it, you describe what you want and Claude figures out how to build it" (Anthropic). I wrote about where AI interfaces are heading beyond the chat window in The Chat Box Is 60 Years Old.

What the record shows

Every change to this site's code is recorded in git, a tool that keeps a project's full history. Each saved change is a commit, with a message saying what changed. These numbers come from that history on October 15, 2026:

WhatFigure
First commitApril 9, 2026
Commits916
Commits that name Claude as co-author588
Pull requests merged90
Test files84
Lines of TypeScript in the site's code, outside testsabout 37,100

A commit message can end with a credit line, "Co-Authored-By," naming someone who worked on it. In 588 of the 916 commits, that line names a Claude model, and six different models appear over the six months.

The work came in two bursts: 388 commits in April, 7 in May, none from June through August, then 313 in September and 208 so far in October.

The gap is the summer I spent building a tool instead. Copying my own design turned out to be much harder than I expected. I assumed I could point the agents at the old site, have them scan it and take screenshots, and get a faithful duplicate. Instead I got inconsistencies everywhere. Spacing was off, effects were missing, and the agent started inventing design elements that were never there. Screenshots show what a page looks like, not how it was built, and the agent filled the gaps with guesses.

So I stopped working on the site and built the tool I needed. That became Chromatic Bloom, a system for converting WordPress sites to Next.js that captures the real design, not just a picture of it. That, plus a few other tools, took up the summer. In September I came back, used them to reproduce the design properly, fixed the areas that had been fighting me, and started adding what I'd wanted all along: some spark, some flair, a little confetti.

From September on, the Claude line is on almost everything: 415 of the 425 commits that aren't merges. (A merge is the commit that joins a finished piece of work to the main code.) In April, it was on 125 of 383. That's because Claude wasn't the only one working in April. It was a mix: Gemini through Google's Antigravity, ChatGPT, early output from what became Chromatic Bloom, and me going in by hand to fix things and write code directly. I used whichever tool was best at the problem in front of me. The credit line only records one of them.

The project's instructions file lists the stack, the set of services the site runs on: Next.js for the pages, a Neon Postgres database, Stripe for payments, Clerk for accounts and sign-in, and Postmark for email. The site is hosted on Vercel.

How the work is organized

Five habits run through the repository, the folder that holds the code and its history. Most have a counterpart in Anthropic's own advice.

Standing instructions in one file

Anthropic says "CLAUDE.md files are markdown files that give Claude persistent instructions for a project" and that "Claude reads them at the start of every session." It also says Claude "treats them as context, not enforced configuration" (Anthropic). The file guides the agent; it doesn't guarantee anything.

This project's CLAUDE.md was written on the first day and has changed five times since. Its opening describes the job as "a pixel-perfect recreation" of the old Popproxx WordPress site, and from day one its rules have included: "Content accuracy: All text, images, sections, and page structure from the original — do not guess or fabricate content." That rule was in place all through April, and the agent still invented design details, as you'll read below.

A written plan before the code

A folder of design documents holds seven specs and nine plans, dated September 4 to October 4. A spec says what to build and why, and carries a status line such as "approved in conversation with the owner." A plan breaks the work into numbered tasks, and eight of the nine open with a note addressed "For agentic workers." The longest, for the last stage of the online flow a new client uses to start a project, runs 7,536 lines.

Anthropic's guide has a section called "Explore first, then plan, then code," and warns that "Letting Claude jump straight to coding can produce code that solves the wrong problem" (Anthropic).

One change, one pull request

A pull request is a proposed change, kept on its own branch with a description, that joins the main code only when it's merged. The descriptions of all 90 merged pull requests carry the line "Generated with Claude Code," and all 90 were merged under my GitHub account. Their titles say what each one does: "Give the transactional emails a design," "Remove proof and offers the site can't back up," "Fix the intermittent blog hydration failure that drops dark mode."

Most descriptions also say how the change was checked. One from October 11 lists the test suite passing ("npm test: 568/568"), a type check, a lint check (an automated scan for code problems), two production builds, and a comparison of the changed sections against the live site.

How closely I read a pull request before merging depends on the change, and I don't follow a formula. Sometimes it's all three: the code, the description and the preview. Sometimes a quick look at the preview is enough. A color tweak and a change to the sign-up flow don't get the same attention. It also helps that I'm not the only reviewer. Other AI models review the code independently before it reaches me, so I'm often reading their flags as much as the code itself.

Tests that pin what matters

A test is a small program that checks one thing and fails loudly when it's wrong. Some of the 84 test files here check business content, not just code. One checks the three build fees and the pay-in-full prices to the cent. Another checks every blog post: one topic, my byline, a recorded source for its cover photo, and the call to action pinned for that post, "so refiling a post cannot quietly change its offer."

Anthropic's advice is to "Give Claude a check it can run: tests, a build, a screenshot to compare." Its reason: "Claude stops when the work looks done. Without a check it can run, 'looks done' is the only signal available" (Anthropic).

"Live" means checked on the real site

One of the plans spells out the rule: "'Live' means merged to main, deployed by Vercel, and verified on https://www.popproxx.com by request. The owner merges." A change isn't finished when the code is written, or even when it's merged. It's finished when someone has loaded the real page and seen it work.

Anthropic's list of common mistakes makes the same point: "If you can't verify it, don't ship it" (Anthropic).

How I built sites before

The old site was WordPress and Elementor. I'm very fluent in Elementor, but I hit its limits constantly and wrote a lot of custom CSS to get what I wanted. Sales ran through SureCart, which handled subscriptions well but was missing features I needed for selling plans and services.

Around that sat the usual plugin stack: Elementor Pro, FluentSMTP connected to Postmark for email, Link Whisper Premium, LiteSpeed Cache, SEOPress Pro, Simply Static and WPvivid Pro, plus backups kept offsite. Every one of those is something to license, update and keep compatible with everything else.

On the new site, I've written very little of the code by hand, a few percent at most. But I've read most of what matters: sign-up, payments, accounts, anything customer-facing that could break or cost money. With 30 years of coding behind me, I can read what the agent produces and spot when something's off. My job shifted from writing code to directing it and checking it.

A normal working session

I rarely work on just one thing. On a typical day the agent is building on the site while I'm working for the two nonprofits I'm involved with, Rogue Advocates and Protect Rural Oregon, maybe running another website build in OpenAI's Codex, and making graphics in Adobe. I check in when the agent needs a decision or there's something to look at.

The pattern I've settled into is: come up with an idea, build a quick prototype, and often throw it away. It's closer to making art than engineering. The best results come from iterating until it's right, and you can feel it when it is, but it almost never happens on the first try. What the agent changed is the cost of that loop. A prototype used to be days of work, so I'd commit to my first idea. Now it's cheap enough to try five and keep the one that feels right.

What worked better than I expected

How fast ideas become real. Things I would have shelved as "someday" on WordPress, like an interactive sign-up or a gamified page, are now an afternoon of experimenting. And once the design system was defined (the colors, type and spacing the whole site shares), the agent applied it everywhere without the drift I used to get from page builders.

What went wrong

Two things, and they hurt in different ways.

The big one was copying the design. That cost me the whole summer and ended with me building Chromatic Bloom just to get past it.

The smaller but more painful one was dark mode. I thought it would be easy. It wasn't, because dark mode touches nearly every part of the design, and every change needed real confidence about what it was altering and whether the result still looked right. I built about four color palettes to make it work. Then, while running several agent sessions at once, I deleted the wrong session and wiped out all of that work. I had to rebuild it from scratch. That one was on me, not the agent. Parallel sessions are a huge speed boost, but you have to keep track of what each one is doing, and that day I didn't.

An upgrade soon after launch

A little while after the new site launched, it needed a major upgrade. It was built on Next.js 15. Next.js's support policy gives each major version two years of maintenance from its release, and in that phase it ships "only critical bug fixes and essential security updates" (Next.js). Version 15 came out on October 21, 2024, so its two years were almost up.

The move happened in one evening, October 11, in four pull requests: a last update within version 15, along with a newer version of Clerk, the sign-in service; the jump to Next.js 16.4; a follow-up that switched three code checks back on, which caught a real bug in the client intake form; and an update to React, alongside a fix for a menu that took two taps to open in Chrome. Three leftover fixes went out the next morning.

Before the main upgrade merged, screenshots of the site's pages in light and dark mode were compared pixel by pixel against the version 15 build, and the menus, search and forms were clicked through on the new version. Two days later, a fresh agent session that hadn't done the work reviewed the whole migration: 455 requests compared between the old and new versions, the screenshots again, and the same clicks on both. It found no regressions in anything it could test. A real sign-out on the live site and a pass on actual phones and tablets are still on my list.

One nice side effect: I'd been carrying a small patch for a React bug that kept dropping dark mode on blog posts. Next.js 16.4 includes the fix, so the patch came out.

What this means for you

If you want to build or rebuild your own site this way, write down what you want before you start, in plain words, and be specific. The agent is only as good as the brief. Approve the plan before it builds. Look at the result yourself on a real phone, not just the code. And protect the things that cost you money if they break: prices, contact info, the sign-up form. Those should be checked every time something changes. If you're not technical, find someone who is to review the critical pieces. The agent does the typing; you still own the judgment.

If someone else builds your website with an AI agent, the useful questions are about the checks around it. Is there a written brief the agent works from? Do you approve a plan before the work starts? Are there tests for the things that matter to your business, like prices and contact details? Is there a second reviewer that isn't the same AI that wrote the code? And who looks at the live site before calling a change done?

The record here suggests the agent is only part of the system. The rest is ordinary discipline: write down what you want, check the result, and don't call it live until you've seen it.

Jamin Giersbach, who runs Popproxx
Written by

Jamin Giersbach

Jamin Giersbach is one of the three designers who started Popproxx in New York City in 2000. Early clients included WebMD, MSD Capital and Bookmans. In 2007 he took Popproxx to Oregon, and he has run it on his own ever since.

Read the full story →