Now that I use AI regularly to help write code and complete tasks, I find myself in a position where I’m not learning as much as I used to. That feels a bit crummy. Fairly often, Claude writes code I don’t fully understand. For example: I know enough TypeScript to be dangerous, but I’m definitely not an expert. Recently I had Claude take some typing I thought was overcomplicated and drastically simplify it. The new version was clearly better — I just couldn’t tell you why. So I asked Claude to explain it in simple terms. Sure enough, it did. I guess that’s a silver lining to using AI: it can at least explain why it did what it did. A coworker mentioned he has Claude write one-off explanations with examples whenever this happens, and I liked that idea. So I built a skill around it. The skill looks at my uncommitted code, breaks it down, and writes a short blog article for me to read. I’m a fan of Josh Comeau’s blog and the way he uses interactive examples to teach a concept, so I made that part of the skill too — Claude generates interactive examples alongside the explanation, then packages everything up in a small Vite environment. The first iteration was expensive to run. At least 3 minutes, and roughly 10K tokens. I’m fine burning tokens, but I’m also thrifty 😬. The second iteration kept the Vite environment and styles already wired up, so Claude only had to write the article and the examples. That brought it down to about a minute and 7K tokens. Better — though I’d still like to get the token usage lower. The blog format is great, but it’s a lot of work (for Claude) to generate all of this just to delete it when I’m done reading. It’d be nice to have these articles persist somewhere I could revisit later, or share with other people. That brought me to my current iteration. It’s an Astro project that lives on GitHub. The skill works roughly the same way — review uncommitted code, generate a post complete with interactive examples — but now it publishes to a TIL subdomain where I can read the articles at my leisure or pass them along. It’s all vibe coded, and that feels appropriate. I’m up front about it on the site itself: Things Claude changed that I didn’t understand — explained… by Claude. I’ll probably keep tinkering to bring the token usage down further, but it was a fun project to put together, and I’m happy to let Claude teach me what it’s doing.

This is an updated list of what I’m using in 2026. I’m only sharing what’s changed since last year’s list. Applications Chrome — Chrome was on my list last year, but I’m mentioning it again because I actually used Brave for most of 2025. I like Brave, and honestly I can’t even remember why I switched back to Chrome 🤷🏻. ChatGPT — I hate that I’m listing AI tools, but if I’m going to be transparent, it has to be here. I use it a bit for code, but mostly for rewording messages or rubber-ducking ideas. Claude Code — I wrote about my thoughts and reluctance to embrace AI for coding. My company pays for it, so I use it. Endel — I’m neurodiverse and have been trying to be more intentional about using tools that help me stay focused. Endel is super cool and has a lot of genuinely helpful features. Hyper — I was previously using iTerm2, but switched to Hyper mostly because it feels prettier. That’s probably a dumb reason since I could have customized iTerm2, but I installed Hyper on my new machine and never felt the need to switch back. Retcon — My team is pretty opinionated about Git history, and rewriting history via the command line or VS Code started to feel tedious. Several coworkers use LazyGit, but I didn’t want another terminal-based tool. Retcon does exactly what it promises and lets me handle more advanced Git workflows without having to be a Git super-nerd. Notion — I was using Bear for notes, but didn’t feel like I was getting enough value out of paying for it. That’s not a knock against Bear—it’s a great product. Notion’s free plan works just fine for me. I also tried Obsidian this year and liked it, but parts of it felt quirky. It also seemed like a bigger time investment to make it feel as polished as Notion or Bear. VS Code — I tried Zed for a bit, and there are things I really like about it. That said, I ran into a few weird and buggy behaviors that I just couldn’t get past. Equipment I got a 2025 M4 MacBook Pro when I started my new job this year. It’s more than powerful enough for anything I need to do.

One of the biggest challenges I’ve faced as a web designer is how often people expect a website for next to nothing. Somewhere along the way, the perception formed that a website is a commodity—quick, cheap, and interchangeable. So when someone asks what I charge (for a very basic marketing site), I usually reply, “That’ll cost around $5,000.” That number isn’t a gimmick—it’s a filter. It immediately reveals who understands the craft behind the screen, who values quality, and who’s serious about investing in their own business. It separates those looking for something fast and inexpensive from those seeking something purposeful and crafted. It used to frustrate me when people balked at the cost. Now? I see it as a helpful sorting mechanism. It shows me who I actually want to work with. The Cost of “Cheap” There’s no shortage of DIY website builders promising professional results at a low price. And honestly—sometimes that’s fine. If you just need something quick and functional, a template might be all you need. But a boutique website is something entirely different. When you hire me, you’re not buying convenience—you’re investing in craft. A boutique site is designed and engineered specifically for you. It’s not a template dressed up with new colors. It’s built intentionally, shaped around your goals, your audience, your brand’s personality, and the experience you want people to have. And cheap solutions often come with hidden costs: lost conversions poor usability and performance accessibility issues a generic, forgettable brand presence The value of a bespoke website isn’t just in what it does. It’s in how it’s made—and what it communicates about you. Why Bespoke Work Matters When I build a custom website, it’s not just about aesthetics. It’s about alignment—making sure every part of the experience supports your story, your content, and your clients’ needs. Every choice—typography, layout, semantics, performance—is intentional. Anyone can make a website that looks good. I handcraft websites that feel right and function beautifully. As a design engineer, I don’t hand off a static mockup and hope the final result captures the original intent. I design with the intent to build, carrying the project from concept to code so the final experience is cohesive, thoughtful, and true to the vision. That’s what boutique design is: every pixel and every line of code has purpose. The Bottom Line If you only need a website, you don’t need me. But if you want a boutique digital experience—something that reflects your values, your vision, and your commitment to quality—then I’m the right fit. You’re not paying for a website. You’re paying for craftsmanship, collaboration, and care. And while not everyone values that, the right clients do. My pricing isn’t just a number—it’s a filter that helps me focus on the people who appreciate the work, the craft, and the impact it can create.

Does anyone else hate the term vibe coding? I’ve been pretty resistant to incorporating AI directly into my development workflow. I use it all the time to clean up emails, Slack messages, and blog posts (including this one). It’s helped me plan vacations, write my cover letter for Planning Center, and even gain insights from journaling. But coding? That felt like crossing a line. At first, I confined AI to repetitive tasks—formatting long word lists into arrays, deciphering cryptic console errors, or exploring how to integrate Vite into a Rails codebase still using Sprockets. All helpful, but I steered clear of anything that touched “real” engineering. Still, AI isn’t going anywhere. And as much as I hate admitting how much I rely on it, it genuinely makes my life easier. So I gave vibe coding a shot. Spoiler: I’m sold—with a few caveats. Vibe Coding an Alfred Workflow I’d played with basic Alfred workflows before, using the built-in UI or tools like Alfy. But I had an idea for something more complex—and neither the time nor the motivation to learn how to build it from scratch. The Problem At Planning Center, our design system has 300+ tokens (and counting). To grab one, I’d open our Storybook instance, scroll to the search bar, type in a few characters, click to copy, then return to my editor to paste it. Repeat that a few dozen times a day, and the friction starts to add up. The Solution An Alfred workflow that lets me search tokens via fuzzy matching, press Enter to copy, and paste directly—eliminating multiple steps and speeding up my flow. Using Claude Code I’ve tried ChatGPT and GitHub Copilot. They both work well (though I find Copilot’s integration with VS Code a bit invasive). I’m not ready to pay out of pocket, so I started using Claude Code through Planning Center’s access. Setup took less than 10 minutes. Anthropic’s documentation is clear, and their tips on effective usage are actually helpful. Building the Workflow with Claude Code I kicked things off with a prompt: I want an Alfred extension where I can enter “tt” followed by characters, and tokens from URL redacted will be shown using fuzzy search. Claude generated a Python script… that didn’t work. It produced a workflow Alfred couldn’t import. So I responded with: The Alfred extension fails to import. Claude replied something like, “You’re right, let me fix that,” and, impressively, it did. After about three hours of iterative prompts and debugging, I had a fully functional Alfred workflow that: Stores design tokens as a JSON database Caches data locally Refreshes if unused for over an hour Fuzzy-finds tokens on input Displays color swatches for color-based tokens I also used Claude to: Generate 100+ color swatches (since Alfred can’t use data URIs) Write a Bash script that builds the workflow with semantic versioning I don’t know much Python, but I know enough to skim the output and feel confident in the structure. And because this was a small, siloed project, I wasn’t concerned about maintainability or codebase conventions. The Cost Aside from the monthly AI access fee, the entire three-hour build process cost around $10 in usage tokens. That’s ~$3.33/hour—far below the value of my time. And now, every use of the workflow saves me 10+ seconds. That adds up quickly. If I’d tried to build this from scratch, it easily could’ve taken 10+ hours and been half as effective. That’s not even accounting for generating the color swatch images. I did spend about an hour trying to get Claude to scrape the tokens directly from the design system site, but that turned out to be unreliable. Still, the final solution works and required zero extra effort from the rest of my team. The Pros and Cons of AI in the Workflow Pros Efficiency Boost: Great at handling menial but necessary tasks—JSON formatting, token lookups, error decoding, etc. Rapid Prototyping: I built a working Alfred workflow in a single evening. Even if it were only a prototype, it would’ve been valuable. Creative Leverage: Designers and PMs can use AI to sketch out ideas and flows, helping engineers jump into development faster. Cons Skill Stagnation: Over-reliance on AI could erode problem-solving ability or deeper understanding of frameworks and languages. Job Displacement: AI is replacing some roles. At Planning Center, leadership has been clear AI won’t replace people—only support them. But the broader industry picture is less certain. Environmental Cost: Running large AI models consumes a lot of energy. Price Tag: Even if it saves time, AI access and usage can get expensive—especially if you’re footing the bill. So Why Do I Still Feel Icky? It took me a while to name the feeling, but I got there: I’m grieving the loss of what it means to be an engineer. I’ve spent over 20 years solving problems, building UIs, and turning ideas into code. I’ve always taken pride in being able to take a design and bring it to life. But now, what it means to be an engineer is changing—and that’s uncomfortable. I don’t want to become just a prompt wrangler. But I also don’t want to be the person who gets left behind because they refused to adapt. The logic is clear: why pay one engineer for 10 hours of work when another can produce the same result in two with AI? Finding the Sweet Spot I think the answer lies somewhere in the middle. Engineers should still understand their craft—be able to reason through problems, write maintainable code, and build features from scratch when needed. But AI should be a tool we use intentionally to reduce toil and accelerate progress. We don’t call it cheating when someone uses code completion. Why should this be any different?