This is the first post in the log shared on our home page— the one that promises “the tools, the decisions, and what actually worked.” So before we write about anyone else’s project, it seemed only fair to start with our own: the site you’re reading this on.
Pretty Code Machine didn’t launch as a finished object. It came together over three working sessions spread across a few days this week, almost entirely through Claude Code — Anthropic’s AI coding tool — sitting alongside us as an actual collaborator rather than a search bar with better autocomplete. No page builder, no theme marketplace. Just a small hand-built WordPress theme, and a lot of back-and-forth about whether a given decision was actually right.
Here’s what that looked like, organized the way we promised: the tools, the decisions, and what actually worked.
The tools
The mechanics are almost boring, which is the point. The theme — pcm-theme — is plain PHP, CSS, and a little vanilla JS. No build step, no npm, nothing to compile. That was deliberate: it means Claude Code can read the entire theme in one pass, understand how a template, a partial, and a function connect, and make a change with the full picture in view instead of guessing from one open file.
Working this way meant every change was a real commit with a real explanation — not “update styles,” but the actual reasoning: what was broken, why, and what the fix does instead. Deploys went out over deploy-staging.sh, an rsync script Claude Code wrote early on, straight to a SiteGround staging environment before anything touched production.
The decisions
The interesting part isn’t that AI wrote code. It’s which problems it was pointed at, and how many of them were correctness and judgment calls rather than “make it prettier.”
We started with real bugs, not polish. The homepage had a blank hero section on staging — content was only rendering when the post loop found something, and on a fresh site, it hadn’t. Right behind it: the main nav menu was assigned but empty, and WordPress’s own fallback logic doesn’t catch that case — it only fires when no menu is assigned at all. Both shipped as fixes with an explanation of the actual WordPress behavior that caused them, not just a patch.
We took accessibility as a constraint, not a checklist item. Our brand accent went through four colors — orange, forest green, teal, and finally a raspberry pulled from an old values page — because the first few, while on-brand, failed WCAG contrast when carrying text. Rather than settle for a compromise, the fix made the palette role-based: the true raspberry is reserved for decoration, a deeper shade carries every button and every line of text, and a lighter tint handles the dark footer, where the rule runs in the opposite direction. Every ratio is documented in the code as a comment, not just chosen and forgotten.
We fixed the class of bug, not just the bug. Early on, a logo recolor deployed correctly but nobody could see it — the image had no cache-busting version string, so browsers kept serving the old file. The first fix extended manual versioning to cover images too. The real fix, a couple of days later, replaced manual versioning entirely: every themed asset is now stamped with its own file’s modification time, so a change can’t ship silently stale again. That’s the kind of fix that’s easy to skip when you’re moving fast, and exactly the kind an AI collaborator that remembers the whole system tends to circle back to.
We let the site’s own values shape its structure, not just its copy. Transparency is one of five things listed on our Core Values page — which is also why this log exists at all. That value shows up in the code, too: the three services on our Services page and the options in our contact form’s dropdown are defined in exactly one place, so a call-to-action can never offer something the form doesn’t actually support. It’s a small piece of engineering in service of not accidentally lying to a visitor.
What actually worked
A few things we’d point to directly, if someone asked what this workflow is actually good for:
Catching what a screenshot can’t. An AI that reads the whole codebase — templates, functions, styles — finds a broken-in-a-specific-way nav menu faster than one working from a screenshot, because it’s reading the actual logic, not guessing from pixels.
Subtraction, not just addition. Some of the best commits from this build removed things: a mascot image nothing referenced anymore, a “Book a call” button that no longer matched how we wanted people to reach us, a second contact button once one path already covered it. An AI pair that’s paying attention will tell you when something doesn’t belong anymore, which is a different (and harder) skill than adding features.
A paper trail that holds up. Every one of the commits behind this site explains its own reasoning — what was broken, what the fix changes, and why that’s the right fix rather than a workaround. That’s not a nice-to-have for a blog post. It’s what let us write this one accurately, days later, without relying on memory.
Why we’re telling you this
This isn’t a novelty. It’s the same discipline we bring to AI Enablement and Custom Development work for clients: AI-assisted development that still gets accessibility right, still catches the boring bugs, and still explains itself. If that’s the kind of partner you’re looking for — whether it’s your own site, an internal tool, or getting your team using AI with more confidence — get in touch. No pitch deck, just a look at whether this is a fit.
And if you’re curious what’s next: this log will keep going as the site — and the work behind it — keeps changing.