"A hand reaching out to touch a single glowing pixel of bright color, dark background"

Generated with flux-latentpop and seedance-1-pro-fast.

❯ cd ~/code/

Pika, automation, and reigniting creativity with AI

Overview
Automation isn't the enemy of creativity, it's the thing that clears the path back to it.
Last Updated
20/03/2026
Tags
pika, automation, ai, creativity, tools

I built Pika because, honestly, I wanted to build a Mac App, and it was the pandemic. An ocean of time and a laptop. I'm also a designer, and I liked the idea of doing something around accessibility. Picking a color off the screen should be dead simple.

So I built Pika.

The thing about tools

There's a version of this where I talk about Pika's features - the WCAG contrast checking, the color name lookup, the keyboard shortcuts, the Raycast integration. And those things are genuinely useful. But that's not the interesting part.

The interesting part is how painful making it was. I spent hours googling, reading documentation, and trying to figure out how to do things in SwiftUI and AppKit and XCodde that should be straightforward but weren't. The friction was exhausting.

When you stop thinking about how to do the thing, you start thinking about what you're doing. And that shift - from process to purpose - is where creativity lives.

Coding with AI, and what it changed

Shipping a macOS app has a lot of overhead. You build, you archive, you sign, you notarize, you wait, you create a DMG, you generate delta updates, you write release notes, you update the Sparkle feed, you push to GitHub, and then you do it all again for the Mac App Store target. It's not hard, exactly. It's just a lot of steps that aren't the interesting part.

I'd been using Claude Code for a while, and at some point I had this thought - what if I built a workspace that could handle all of that for me?

So I set up a monorepo that pulls together the Pika source, a release tool I built called releasecast, the marketing assets, and the website. Then I wrote Claude Code slash commands - /release, /screenshots, /setup - that orchestrate the whole thing.

The /release command handles the full pipeline. Build, notarize, create the DMG, generate the appcast, push to GitHub Releases, write the changelog, deploy the website. One command. What used to be an afternoon of careful copy-pasting and waiting for notarization emails turned into something I could kick off and walk away from.

But the screenshots were the thing that really surprised me.

I'd been putting off updating Pika's marketing assets for months. Taking screenshots of a color picker means getting the right colors on screen, the right window positions, the right appearance mode - light and dark - and then doing it all over again for the website, the README, and the App Store. It's fiddly, repetitive, and easy to get wrong.

I added a pika:// URL scheme to the app so it could be configured programmatically - set the foreground color, the background color, pick which window to show. Then I built a pipeline that launches Pika, triggers each shot configuration, captures the windows, and composites them into the layouts I need. Fan layouts for the website. Overlapping windows for the README. Clean PNGs for Figma.

The whole thing took a couple hours to build. And now updating the screenshots for a new release takes about thirty seconds, automatically.

That's the part that changed something for me. Not the time saved, exactly - although that's real. It's that the tedious stuff stopped being a reason not to ship. Every release used to come with this mental tax of all the boring work I'd need to do after the fun part was done. Now the boring part is automated, and I get to stay in the fun part longer.

Reigniting the thing

I've been making things since I was a kid. Side projects, experiments, things that have no business case and no roadmap. Pika is one of those.

But there's this thing that happens with side projects where the gap between what you want to build and what you can actually ship keeps growing. You get better at knowing what good looks like, and worse at finding the time to get there. The ideas don't stop, but the energy to push through the last 20% does.

What changed for me was the combination of AI and a willingness to experiment with how I work. Not just using AI to write code - although that's part of it - but using it to rethink which parts of the process need me and which parts don't. The color accuracy improvements, the OKLCH decimal precision, fixing Xcode build issues - I could describe the problem, work through it collaboratively, and ship the fix in a fraction of the time it would have taken me alone.

And that freed up space for the parts that actually need a human. The product decisions. The feel of the interactions. Whether a feature is worth adding at all.

There's a specific feeling when someone you've never met finds your little tool useful. A tweet you didn't ask for or an email from someone who uses Pika every day. Small tools accrue meaning over time in a way that's hard to predict and impossible to plan for.

That feeling is what keeps you making things. And anything that shortens the path from idea to shipped - anything that removes a reason to procrastinate - is worth its weight in gold.

What's next

Pika does a lot. It also doesn't do some things I want it to do yet.

Palettes just landed in beta - saving and organizing groups of colors, not just individual picks. There's more coming after that. I'm not sure exactly what shape it'll take, but that's the fun part.

It's a lot easier to be excited about what's next when shipping doesn't feel like a chore.

The tools we build reflect how we want to work. I want to work fast, stay focused, and spend more time on the parts that require a human.

So yeah, that's it. That's the automation manifesto, I guess.

Edit on GitHub
Links