The passenger problem. The fluency debt. Two tools built to fix both.

I'm a product designer who started building my portfolio in code about six months ago. No prior coding background. Just a design eye, a set of opinions about interfaces, and a serious ambition to become a design engineer.

The build went fast. Embarrassingly fast. Claude would implement an entire component, state, animation, dark mode, the works, while I watched the terminal. I'd review it, say “looks good,” commit it, and move on. The portfolio grew. The git log filled up. My actual coding knowledge stayed exactly where it started.

But there was a second problem I didn't notice until much later. A few months in, I sat down to write a case study for a piece I'd built. And I couldn't remember why anything worked the way it did.

In Figma, design history is ambient. You can go back and look at the version where you tried the modal layout before switching to a full page. In code, none of that exists by default. Every iteration is a rewrite. The git diff shows what changed, not why. And if you weren't the one typing the code in the first place, you have even less to go on.

These two problems needed two different tools. Butler solves the memory problem: capturing decisions as they're made so you can reconstruct the thinking months later. Relay solves the passenger problem: making sure you're actually running part of the build, not just approving Claude's output from the sidelines.

The hardest part of writing a case study isn't the writing. It's the archaeology. You're trying to reconstruct decisions that felt obvious at the time but left no trace: why you chose the tab pattern over an accordion, what constraint made you reach for a workaround, which alternatives you considered and dismissed. Butler is the trail of breadcrumbs you forgot to leave.

It runs silently in the background during a Claude Code session, logging every meaningful design decision to a .butler-log.md file in the project root, incrementally, as decisions happen, so nothing is lost if the session ends abruptly.

The scope question was the hardest design decision for Butler itself. Log everything and the file becomes noise. Log too little and it misses what matters. The rule is simple: log decisions, not implementation.

The “Rejected” line is worth paying attention to. It's the most underrated part of any case study: the thing you tried that didn't work, and why. Butler captures it automatically because it's present in almost every meaningful decision Claude makes.

The original version was a paragraph pasted into every session. Two failure modes: forgetting to paste it, and sessions ending before the log was saved. The fix was making the write operation continuous. Butler appends to the log as each decision happens, not at the end. Session dies mid-build, the last five decisions are already on disk.

I've always wanted to know how to code. When Claude Code arrived, I thought it would teach me. Instead it did everything and I watched. The metaphor that made Relay make sense to me: a senior engineer and an intern.

A good senior doesn't write all the code while the intern observes. They write some of it, explain what they're doing, then hand over a task that's within reach, something that will stretch the intern slightly but not break them. The intern does the work, the senior reviews. Over time the tasks get bigger. Relay is that dynamic, designed in.

At Apprentice and Builder, Relay uses tweak cards for simple isolated changes. Not instructions for Claude to execute, instructions for you. File, line, what to find, what to change it to, and why. The why is where the learning is: over time you stop needing the card for values you've already seen and understood.

At Engineer level the format changes. Relay isn't handing you a number to swap, it's handing you a task to implement. What needs to happen, which file, where to look, and a hint you can turn off if you want to work it out yourself. Claude only steps back in if you call /relay do it.

Relay watches how you handle handoffs and adjusts your level when a pattern is clear. Consistently completing handoffs without passing things back → bump up. Frequently calling /relay do it → step down. It always tells you before it adjusts, and you can override anytime. The point is keeping tasks in the right range: hard enough to stretch you, not hard enough to stall you.

Butler and Relay are independent but designed to work in the same session. Relay decides who does what. Butler logs the decisions behind everything Claude does, including every handoff it gave you and every /relay do it call you made.

At the end of a session, butler log gives you Claude's decision record. /relay loggives you yours: a ledger of what you built versus what you handed back. Together they create something more useful than either alone: an honest account of where your confidence is growing and where you're still leaning on the senior engineer.