Full Width 
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from Daniel Marino
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.
When I first got into hand-lettering, I had a hard time finding people who shared their full process—especially the digitizing phase. So here’s a look at how I typically work. Everyone’s process is different, and a lot depends on your style and how you plan to present the piece. For me, since I don’t have the steadiest hand, I tend to embrace rough, scrappy, distressed looks. Most of my work ends up digital anyway, so mistakes can be fixed later. Here’s a short process video I made a while back. Thumbnails & Sketching Start with quick thumbnail ideas on scrap paper. Refine the chosen direction with a pencil on Bristol Paper. If possible, I use a drawing pencil (softer, lighter lead makes cleanup easier). After inking, I clean up with an art gum eraser. Inking My go-tos are Microns in different thicknesses. In the video I sharedI used a .08 for outlines and Graphic 1 for filling letters. I used a Gelly Roll 10 to add cut-outs, create depth, and fix small mistakes 😬. Digitizing I scan the inked artwork using Scanner Pro on iOS. Clean up in Pixelmator Pro. Add textures for distress and wear (I’ve collected a bunch of texture packs over the years). Where I’ve Used This This is basically the same process I followed for my State Motto series, and most of my other lettering projects. Don’t be afraid to lean into your natural tendencies (like a scrappier style if your hand isn’t steady) and use the digital phase to enhance or correct. Trial and error is a huge part of it.
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?
More in programming
A clip of me singing a funny song from Gilbert and Sullivan’s Ruddigore back in 2013
In this video, we look at why fork() needs copy-on-write, how it works inside the kernel, and a memory usage problem that Instagram encountered with Python.
Comments require commitment, but they’re worth it.
An aggregation is some kind of summary of a set of data. This can be the sum, length, minimum, etc. It is quite common to want to calculate such a summary repeatedly, e.g. “the maximum noise level in dB for the past 30 seconds” for a nuisance detector. In such a case we say there is a sliding window over our data, and we want to aggregate over our window. If our aggregation is a binary operator with an inverse, like integer sums, there is a very easy solution using a double-ended queue: from collections import deque class SlidingWindowSum: def __init__(self): self.sum = 0 self.elems = deque() def push(self, x): self.sum += x self.elems.append(x) def pop(self): self.sum -= self.elems.popleft() def eval(self): return self.sum But what if our operator has no inverse? This is actually the case for most interesting summaries such as minimum, quantile, approximate unique count (for example using HyperLogLog), etc. In fact, even something as simple as a floating-point sum suffers from the fact that floating-point addition is not invertible. For example, if you ever have a NaN in your input data with the above naive algorithm your sum will forever remain NaN, even long after the bad value has left your window. Six years ago I came up with an algorithm for maintaining just the minimum/maximum in a sliding window and posted it to cs.stackexchange. I now consider this algorithm pointless, because it turns out there is a simple and efficient algorithm that solves this problem for a very wide class of aggregations. I’m writing this blog post to spread the word, because I feel it should be more widely known. Folklore I came across this algorithm while reading a far more advanced paper, Low-Latency Sliding-Window Aggregation in Worst-Case Constant Time by Tangwongsan et al. Why is this paper titled low-latency? Because it does the same as what I’m about to describe, but in O(1) time for each step. However, in it they also described a “two-stack” algorithm, which does it in amortized O(1), and is far, far simpler. Amortized O(1) means that across many operations the total amount of work per element is constant, but an individual operation can take much longer. This is almost always fine, unless you absolutely need a low upper bound on latency. Funnily enough that paper attributes this algorithm to “adamax” from a 2011 Stack Overflow post. They in turn credit a 2001 lecture note by D. Sleator for the inspiration. However, this lecture note does not describe a sliding window aggregate, it describes the classical two-stack algorithm for implementing a FIFO queue and does amortized analysis on it. Ultimately I would not be surprised to find that this algorithm was already described in an obscure paper from the 1970s, seeing how simple and brilliant it is. Two stacks Like the authors of the paper, I will generalize the two-stack algorithm to arbitrary associative aggregation functions. By abstracting the aggregation as a set of functions, empty(), unit(x), combine(x, y) and finalize(x), you can describe many possible aggregations, for example a mean: empty = lambda: (0, 0) unit = lambda x: (x, 1) combine = lambda x, y: (x[0] + y[0], x[1] + y[1]) finalize = lambda x: x[0] / x[1] if x[1] else None I’d like to note here that these functions have the following signatures: fn empty() -> Agg; fn unit(x: Value) -> Agg; fn combine(x: Agg, y: Agg) -> Agg; fn finalize(x: Agg) -> Out; I’m making a distinction here between Value, Agg and Out because while they seem superficially similar for something like an integer sum, for an approximate unique count on strings you would have (Value, Agg, Out) = (String, HyperLogLogSketch, u64), three wildly different types. Without further ado, the algorithm: class TwoStackAgg: def __init__(self): self.values = [] self.values_agg = empty() self.cum_aggs = [] def push(self, x): self.values.append(x) self.values_agg = combine(self.values_agg, unit(x)) def pop(self): if not self.cum_aggs: cum_agg = empty() while self.values: cum_agg = combine(unit(self.values.pop()), cum_agg) self.cum_aggs.append(cum_agg) self.values_agg = empty() self.cum_aggs.pop() def eval(self): return finalize( combine(self.cum_aggs[-1], self.values_agg) if self.cum_aggs else self.values_agg ) That’s it, the entire algorithm. There’s two stacks (values and cum_aggs) and one more aggregate, values_agg. At any point in time values_agg holds the aggregate of values, and cum_aggs contains the cumulative aggregates of all values in our window that aren’t in values, in reverse order. From this we can get the aggregate over our entire window in constant time by by combining the last value of cum_aggs with values_agg. The neat part is that (assuming w is our window size) every wth operation we drain all of values and maintain a running aggregate while pushing the partial cumulative aggregates onto cum_aggs. This is what makes it amortized O(1), doing O(w) internal operations every wth pop bounds the total amount of work per element to O(1), even though a singular operation might not be constant time. I think this is best visualized. Suppose we sum [1, 2, ..., 10] with a fixed-size sliding window of four elements, then the state on each eval() call would look like this (values_agg not shown as it is simply the aggregate of the values): cum_aggs values out [] [] = 0 [] [1] = 1 [] [1, 2] = 1 + 2 [] [1, 2, 3] = 1 + 2 + 3 [] [1, 2, 3, 4] = 1 + 2 + 3 + 4 [4, 3 + 4, 2 + 3 + 4] [5] = 2 + 3 + 4 + 5 [4, 3 + 4] [5, 6] = 3 + 4 + 5 + 6 [4] [5, 6, 7] = 4 + 5 + 6 + 7 [] [5, 6, 7, 8] = 5 + 6 + 7 + 8 [8, 7 + 8, 6 + 7 + 8] [9] = 6 + 7 + 8 + 9 [8, 7 + 8] [9, 10] = 7 + 8 + 9 + 10 [8] [9, 10] = 8 + 9 + 10 [] [9, 10] = 9 + 10 [10] [] = 10 [] [] = 0 In total the memory usage is O(w), where w is your maximum window size. Note that for simplicity of analysis and the example I assumed a fixed-size window w, but there is nothing about the two-stack algorithm that requires this. You can call push(x) and pop() as many times as you’d like between each eval(), growing and shrinking the window size as needed. Floating-point non-associativity Note that we required above that our aggregate combine is associative, meaning: combine(combine(x, y), z) = combine(x, combine(y, z)) Technically speaking, floating-point addition doesn’t respect this. Nevertheless, the above algorithm is still very useful because the results closely match the expected outcome, even more so if you use a compensated summation algorithm like Kahan summation. Another neat thing about the two-stack algorithm is that it doesn’t require commutativity, if you follow the above implementation precisely. The order of operands is maintained, which can matter for things like string concatenation. However, there is a second very useful property of the above algorithm. Each aggregate is strictly a combination of the elements in the window, and none outside the window. This means if your window contains a NaN or infinity (or some other outlier), that value only poisons the windows that contain it rather than the rest of your computation. But even without NaN or infinity it is useful, due to not propagating errors endlessly. E.g. if your sliding window starts with [1e20, 1], this is what would happen with a naive rolling sum: >>> 1e20 + 1 - 1e20 - 1 -1.0 Compensated summation will reduce these effects, but not making your result depend on values outside of the window will eliminate long-term error accumulation entirely.
