01 — The situationThe bottleneck moved

Review has always been part of how I work. At finsit I spent a lot of time making critical flows dependable with Cypress and Jasmine, and the people I worked with there credited me with the courage to give honest feedback. At YieldComputer I defined a testing strategy across unit, integration and end-to-end tests and tried to lift standards across teams without having a formal title to do it. At InSpace I lead the Experience Team, where a review is often the last moment to ask whether an interface is really right for the person using it.

What changed with agents is the ratio. When agents do the drafting, writing stops being the slow part. Judging is. A browser-tab routine (open the notification, scroll the diff, lose your place, switch tabs to check a caller) doesn't survive that. So I rebuilt review the way I'd treat any bottleneck: a flow with clear stages and little friction between them.

1. Triage in gh-dash
2. Claude's first pass
3. Full-diff read
4. My pending review
5. Submit
6. Loop feeds the author
7. Checklist learns

02 — The queueTriage before reading

I start from a queue, not from notifications. My PR list lives in gh-dash, a terminal dashboard for GitHub, and it's split by the action each PR needs rather than by repository: CI failing, changes requested, ready to merge, needs my review, and involved for threads I'm part of but don't own.

A red build and a PR waiting on my approval need completely different kinds of attention, and one mixed inbox gives each of them half. Triage is quick, and it decides where the deep reading goes.

From any PR in that list, a handful of keys do the rest:

03 — The readRead the whole change

The web diff shows you files. I want to see the change: every file at once, with the surrounding code one keystroke away. So i runs a small script called pr-review. It fetches the PR head into a detached, throwaway worktree, then soft-resets it to the merge-base with the base branch. The result is that lazygit shows the entire PR as staged changes, as if I'd written it myself and was about to commit. My own checkout is never touched, and the worktree is deleted when I quit.

# the PR head, detached, in its own throwaway worktree
$ git worktree add --detach <tmp> <pr-head>
# rewind to where the branch left base, keeping the changes staged
$ git reset --soft $(git merge-base origin/<base> <pr-head>)
$ lazygit   # the whole PR is now one staged diff

Inside that session, three keys build a real GitHub review without opening a browser:

Two details make this trustworthy. The line picker builds its list from git's Myers diff, so the hunks line up with the diff GitHub accepts comments on and every line number I pick is one GitHub will take. And because everything goes into a pending review, I can draft, reread and delete before a single word reaches the author. A review is a piece of writing, and I'd rather edit it before I send it.

04 — The first passClaude first, never last

Before reading a larger PR, I can hand it to Claude first with I. In the background, Claude checks out the PR on its own and reviews it against that repository's checklist. It works read-only: it can read files, grep and run git diff, git log and gh pr view, but editing and writing are switched off. When it's done, I get a macOS notification, and its findings are already sitting in my pending review.

The instructions shape what it writes. Every finding has to be anchored to a line inside the diff and written as the comment the author will read: the problem, the concrete input or state that breaks it, and what to change. Judgement calls are phrased as suggestions. If a finding can't be attached to a line GitHub accepts, it's kept as a file-level comment rather than silently dropped.

What this buys me is focus. There are too many examples to pick one, but they fall into a clear pattern:

Having the first list flagged before I open the diff leaves my attention for the second, which only a person with context can judge.

05 — Complex workA cold second opinion

For work the cockpit rates as complex or critical, there's one more reviewer before the PR is handed to me. A fresh agent gets the PR reference and the repo's checklist, and nothing else: no plan, no reasoning, no conversation history. It reviews what the diff is, not what the author meant. One line in its instructions has become a rule I use myself:

“If something only makes sense with context you weren't given, that's a finding. A human reviewer won't have that context either.”

It works through the same lenses I'd use, and it's told to try to break the change rather than confirm the happy path:

• Claim vs diffDoes the code deliver every Definition of Done item the PR ticks off?
• CorrectnessEdge cases, error paths, empty states, races, partial failure.
• Hidden couplingThe caller the diff forgot to update.
• ChecklistThis repository's known traps, one by one.
• Test adequacyWould these tests fail without the change?
• Security & dataAuthorisation on new paths, checks the server must repeat.

Before it reports anything, it has to try to refute its own findings and drop whatever it can't back with a concrete failure scenario. It only approves when it has zero confirmed findings, and it never approves anything on GitHub. My favourite line in its brief: a short honest report beats invented nitpicks. That's true for human reviewers too.

06 — The human partWhat I look for

Automation takes care of a lot of the mechanical work. What's left is judgement, and that's where my experience earns its keep. These are the questions I bring to every diff:

1. Is it right for the person using it?"Does it work" is where I start, not where I stop. Who is using this, what are they trying to achieve, and what is the interface really asking of them? An interface has to tell one story: a badge that says "failed" next to text that says "due shortly" is a bug, even when every test is green.
2. Would the tests catch a regression?A test that still passes when you delete the check it protects proves nothing. I look for failure paths, not just happy ones, and for the second interaction: open, act, close, then open again. Every bug fix should come with a test that failed before the fix.
3. Does it fail closed?An error from a check that guards a write has to stop the write. A job that half-worked must not report success. And anything the interface checks, the server has to check again.
4. Is the interface clear?Names that promise what they deliver (a parse function can fail, a to function can't), one responsibility per function, and shared components instead of one-off overrides. A comment explaining a block of code is often a sign that the block wants to be its own function.
5. What does it break for someone else?Removing or renaming anything other code depends on is a breaking change, and the PR should say so out loud.

None of these are new ideas. Most of them I learned the slow way, in teams where quality came from steady discipline rather than heroics. What's new is that I have time to ask them of every change.

07 — After the reviewClosing the loop

Once a review is submitted, a loop in the cockpit takes over. It checks every open PR on a timer: CI status, the review decision, and any new human comments since it last looked. Anything actionable goes straight back to the agent session that wrote the code, with a brief that stands on its own: the PR, exactly what fired (the failing checks with trimmed logs, or each comment quoted with its file and line), and a standing instruction. Fix it, re-run the gate, self-review only the new diff, push, then reply to each thread.

It works through red CI first, then requested changes, then merge conflicts, and it limits how many sessions it wakes at once so the laptop stays usable. It never merges, closes or marks a PR ready for review on its own. Those are my calls.

The checklist that learns

The last step is the one that compounds. When a human review comment applies beyond its PR, the loop adds it to that repository's review checklist. Every future task reads that checklist while it codes and again during self-review, and Claude's first pass reviews against it too. So a comment I make once becomes something the next PR is checked for automatically.

There's one hard rule: only human feedback goes into the checklists. Never bot comments, never the loop's own opinions. The system can't be allowed to mark its own homework.

08 — HonestlyThe trade-offs

• Review fatigue is real. More drafts arrive than I could ever write, and attention doesn't scale the way agents do. My defences are structural: the queue is triaged by action, how much process a task gets depends on its complexity so small changes stay small, and the mechanical checks are done before I start reading.
• Rubber-stamping is the risk I watch most. When an AI reviewer has already been through a PR, it's tempting to skim. So the AI never approves: its findings are drafts in my review, the cold reviewer can't approve on GitHub, I still read the full diff, and teammates still review. Agents open drafts; people decide what merges.
• AI reviewers can be noisy. That's why they have to defend every finding with a concrete failure case, and why I delete freely before submitting.
• It costs something. Every AI review has a price, and I can see it per review. I spend it where the risk justifies it, not by reflex.
• It's my own glue. A shell script, a lazygit config, a few keybindings and skills. When it breaks, I'm the one who fixes it.

The shift I've accepted is simple. Writing code is now often the cheap part. Deciding whether it's right, for the codebase and for the person on the other side of the screen, is the job. It deserves the same care and tooling I'd put into anything else I ship.

01 — The situationHeads down

The best part of my day is the stretch where I'm deep in a diff or a design problem and nothing interrupts me. To protect it, I switch notifications off, either with macOS Focus or by starting a 25- or 50-minute focus timer in my own menu bar. Then I get on with the work.

The catch is obvious once you say it out loud. A calendar reminder is a notification, so the one thing Focus mode reliably silences is the thing I can't afford to miss: the meeting where a client, a teammate or a product decision is waiting for me. I wanted deep focus and a guarantee that the important meeting still reaches me.

The second requirement came straight after. Anything that can see my calendar and my screen is handling personal data, mine and the people I meet with, so it has to be built with the care I'd expect from any product feature that touches personal data. Privacy and security have been interests of mine for a long time, and a personal tool doesn't get a pass.

Both answers ended up in the same place: the menu bar. My desktop runs on AeroSpace, a tiling window manager that keeps its own workspaces, so macOS's own bar can't show them anyway. I cover the rest of the setup in My setup, and how I got here. The bar is SketchyBar, an empty strip where every item is a small script. In June it was SketchyBar's sample config. By September it had become a small, tested piece of software built around these two ideas.

02 — FocusThe meeting that matters

The trick is that the meeting pill isn't a notification at all. Focus mode filters notifications; it doesn't hide the menu bar. The MTG pill is drawn by SketchyBar from data a small calendar helper keeps up to date, so it appears whether Focus is on, off or halfway through a 50-minute session. The bar doesn't know or care what Focus is doing, and that's the point.

• It shows up early. MTG appears 30 minutes before a meeting starts, with a countdown in minutes (12m) that becomes NOW at the start time.
• It stays until it stops being useful. The pill goes away five minutes after the start or when the meeting ends, whichever comes first, so a late join is still one click away.
• It sits next to the focus timer, not under it. Starting a focus session adds a FOCUS countdown to the bar and hides nothing. When a meeting comes into range, both pills are visible side by side. The timer ends with a short chime and DONE, and clicking DONE starts the break.
• One meeting at a time. If two meetings overlap, it shows the one that starts first.

The last rule matters as much as the pill itself: a wrong meeting is worse than no meeting. If the calendar helper hasn't refreshed in the last three minutes, or calendar access hasn't been granted, the pill simply isn't drawn. It won't offer a link from a cache that has gone stale. The test for it is named exactly that: stale meeting never opens old link.

03 — PrivacyA calendar is personal data

Behind the pill is a native helper, written in Swift, that reads the calendars macOS already syncs. It refreshes every minute and whenever a calendar changes. A calendar holds names, client meetings, private appointments and call links, so I held the helper to the same standard as a feature that handles someone else's data:

1. Read-only.macOS calls the permission "Full Access", but the helper only reads events. It never creates, edits or deletes one, and the permission prompt says exactly that.
2. As little as possible, for as short as possible.It only looks at the next 24 hours and skips all-day, cancelled and declined events. For each meeting it keeps four things: start, end, title and a vetted call link. Notes and locations are scanned for a link, but never stored.
3. Owner-only storage.The cache is written atomically into an owner-only folder under ~/Library/Caches, and no credentials live in the dotfiles.
4. Links are data, not commands.A join link must be HTTPS, on a known meeting domain, with no embedded username or password. It's checked once when the helper stores it and again before it's opened, then passed to open as a single argument. The controller's first line says it plainly: "External names and URLs never become shell code."
5. Quiet logs.When something fails, the log records the type of error and nothing else: no titles, no URLs, no arguments.

None of this is exotic. It's data minimisation, least privilege and input validation, the same rules I'd ask for in a code review. They just apply to a menu bar this time.

04 — Screen sharingSafe to share

The other place a menu bar leaks is a screen share. Everyone on the call sees the app you're in, the song that's playing and the title of your next meeting. Three things keep that under control:

• Presentation mode (⌥⇧P) hides app, media and meeting titles with one shortcut. The meeting pill keeps its countdown but drops the title, and even its menu says "Upcoming meeting". An orange PRESENT pill stays visible so I can't forget it's on, clicking it turns it off, and the mode survives a reload of the bar.
• No flash of private titles. Window-focus events are coalesced, so an event already in flight can't briefly show an app name after presentation mode has been switched on.
• A mic/camera card appears only while one of them is actually live: amber for the microphone, red for the camera. It asks CoreAudio and CoreMediaIO the same question that drives macOS's own orange and green dots, rather than guessing from which apps are open, and it ignores output-only devices so music never lights it up.

On the laptop screen a compact profile goes further and drops app, media and meeting titles entirely, because the space beside the camera notch is too small for them.

05 — Design ruleQuiet by default

A bar that shouts all day would undo the focus it's meant to protect. The rule that shapes everything is a comment at the top of the config:

“Ordinary information sits directly on the bar. Only focus and alerts get a surface.”

• Metric cards stay hidden until they matter. CPU only appears above 70%, in amber, and turns red at 90%. Memory also appears above 70%, but its colour follows the kernel's memory-pressure level, which is what actually predicts slowdowns. Clicking either opens btop. With coding agents building in the background, that's my early warning.
• Battery only speaks when it has something to say. It hides while charging unless it's low, shows time left on battery, and shows the charge rate while charging.
• One accent colour means "attention". Orange marks the focused workspace, the meeting pill and presentation mode, and it matches the outline JankyBorders draws around the focused window.

Getting here took a round trip. In August I added network and disk cards; in September I took them out again, along with the list of apps in every workspace. If it doesn't help me decide something right now, it doesn't get a place.

06 — Under the hoodBuilt like a product

There's no framework and nothing exotic. The pieces are small, and each has one job:

sketchybarrc            # the bar, its defaults, which items exist
items/*.sh              # declare each item and when it updates
plugins/*.sh            # fill items in from AeroSpace, pmset, vm_stat…
plugins/toolbar.py      # one controller: menus, timers, meetings, privacy
native/ToolbarBridge    # Swift: calendars, audio outputs, screens
bin/capture_state       # Swift: is the mic or camera live?
tests/test_toolbar.py   # privacy, meetings, launching, timers, profiles

• Source, not binaries. The Swift helpers are compiled from source on first run and whenever that source changes, so the repo only carries code I can read.
• One owner for shared state. The Python controller takes a file lock, writes its state atomically with owner-only permissions, and is the only thing that decides what's visible. A display change can't interrupt a timer or switch presentation mode off.
• Cheap when idle. The controller only ticks every second while a timer is running; otherwise it checks in every few seconds.
• Works on any desk. The bar measures the camera notch instead of hard-coding it, gives the cards that won't fit beside it a twin on the other side, and switches layout profiles when I dock or undock.
• Tested like a feature. The test suite reads like a spec for the two promises in this post. A few of its names:

• meeting window
• meeting excludes stale ended and old
• join link validation
• stale meeting never opens old link
• presentation survives refresh and hides titles
• granola visibility and render never start recording

A menu bar with a test suite sounds like overkill until you remember what it touches: my calendar, my microphone and whatever is on my screen when I share it.

07 — IterationReproducible, and still changing

The bar lives in mac-setup next to the rest of my dotfiles, and GNU Stow symlinks it into ~/.config. Editing the bar is editing the repo, and a new Mac gets it with the same single command as everything else. AeroSpace starts SketchyBar and JankyBorders at login.

1. June
   The sample config. Workspaces with their app names, the date, volume, battery and CPU, always on.
2. August
   Awareness. Notch detection and twin cards, the mic/camera indicator, colour thresholds, and network and disk cards.
3. September
   Focus and privacy. The meeting pill and Granola shortcut, the focus timer, presentation mode, the read-only calendar helper, display profiles and the tests. Network, disk and the per-workspace app lists went back out.
4. Next
   Whatever gets in my way. That's been the only roadmap so far.

The honest trade-offs

• It's a lot of machinery for a menu bar. Shell, Python and Swift in one folder is powerful, but I'm the only maintainer.
• It depends on the calendar being right. The pill is only as good as what's synced to macOS. A meeting that isn't on my calendar won't show up, and a stale sync hides the pill on purpose.
• It leans on other people's behaviour. Granola's desktop link could change in a future version, and macOS permission prompts shift between releases.

Standing on shoulders

• SketchyBarthe bar itself
• AeroSpacetiling window manager
• JankyBordersfocus outline
• btopwhere the cards lead
• Granolameeting notes
• SF Symbolsthe icons

If you want to borrow one idea, take this one: put the signal you can't miss somewhere that Focus mode doesn't reach, and treat everything it reads as private.

01 — The problemBig releases are scary

My starting point will look familiar to a lot of small teams: build the app locally, then drag and drop the files onto the server. It worked, most of the time. But every release depended on whatever was on that laptop, on one person remembering the steps, and on a lot of care. Going back to the previous version meant doing it all again, by hand, under pressure.

Releases rarely get scary because of one bad decision. They get scary through a loop, and every step in it looks sensible from the inside:

When a release is big and risky, extra checks, freeze windows and a senior engineer on standby are all reasonable responses. The trouble is that each of them makes releasing more expensive, so the next release gets bigger.

You can't get out of that loop with courage. You get out by making releases cheap: cheap enough that a small change is worth shipping on its own, and safe enough that shipping it isn't a decision anyone has to agonise over.

Most product quality comes from boring discipline, not heroics.

02 — The effectBehaviour follows the pipeline

What surprises people is that a good pipeline changes the team more than it changes the code. Three things shift once releasing stops being an event:

• Changes get smaller. When a release costs almost nothing, there's no reason to bundle. A change small enough to review in one sitting is also small enough to reason about when something goes wrong.
• Fear goes down. When rolling back is a routine command rather than an emergency meeting, "what if it breaks?" stops being a reason to wait. It becomes "how will we know if it breaks?", which is a much better question.
• Feedback gets faster. Small releases reach users sooner, so you learn sooner whether a change did what you hoped it would.

That last point is where the pipeline meets the product. At YieldComputer, alongside the pipeline and the testing strategy, I introduced product analytics and instrumentation, and helped move the team from pure development towards product-oriented thinking. Those things reinforce each other. It's hard to ask "did this actually help anyone?" when a change takes weeks to reach users, and easy when it reaches them the same day.

Shipping often is only half the job. The other half is seeing what happened.

03 — The anatomyWhat a good pipeline contains

The tools change from team to team, but the shape doesn't. This is what I look for, and what I build when it isn't there:

1. Pull request
2. Checks
3. Merge
4. Build once
5. Deploy
6. Observe
7. Roll back

1. Tests at the right layers.Most checks should be fast unit tests on logic. Fewer integration tests should cover the contracts between pieces, and a small set of end-to-end tests the journeys that must never break. At finsit I learned what that last layer is worth, using Cypress and Jasmine to cut regressions in critical flows. Flip the pyramid, with slow end-to-end tests for everything, and the pipeline loses the team's trust.
2. One path to production.Every change takes the same route, urgent ones included. A hotfix is the normal pipeline with priority, not a side door. Side doors are where incidents hide.
3. Build once, promote what you tested.The thing you deploy should be the thing that passed the checks. Rebuilding separately for each environment is a quiet way to ship something nobody tested.
4. Rollback is a workflow, not a ritual.Undoing a release should be a documented, automated path that anyone on the team can run, ideally one that has been exercised before you need it. If rollback needs one specific person, you don't have rollback. You have a dependency.
5. Observe after you ship.A release isn't done when it's deployed. It's done when you've seen it behave: errors, performance, and the product events that tell you people can still do what they came to do.
6. Fast enough that nobody routes around it.A slow pipeline gets bypassed, and a bypassed pipeline protects nothing. Speed is a safety feature.

04 — The adoptionLeading without a title

At YieldComputer I was a technical leader without formal authority. That turns out to be a good fit for this kind of work, because a pipeline isn't something you can mandate anyway. People adopt it when it's obviously the easier way to do their job. The approach I use is simple to describe, even if it takes patience:

• Find the real bottleneck. Before proposing anything, look at where the time goes and where the fear sits. It's rarely where the loudest complaint is.
• Build the fix, don't pitch it. A working pipeline that ships a real change beats any slide about how one could work.
• Make the new path the easy path. Use good defaults, write short docs, and pair on the first few releases. If the automated way takes more steps than the manual one, people will keep doing it by hand, and they'll be right to.
• Keep it visible. Show status where the team already looks. Trust grows when people can see what the pipeline did and why.
• Then find the next bottleneck. Once releasing is boring, something else becomes the slowest part. That's progress, not a failure.

It's also how standards rise across teams without anyone announcing new standards. A colleague summed it up more kindly than I would:

“He consistently improved team processes and efficiency through practical tooling and automation.”Shiva, Backend Developer & Scrum Master at YieldComputer

05 — The trade-offsWhat it costs

Boring shipping isn't free, and pretending it is how pipelines get abandoned halfway:

• It slows you down before it speeds you up. Building the pipeline and the test suite takes time away from features. That should be a conscious trade the team agrees to, not something done on the side.
• Flaky tests are worse than missing ones. A test that fails at random teaches everyone to ignore red. Fix it or quarantine it the same week.
• A pipeline is a product. It needs an owner, maintenance and the occasional refactor. When nobody owns it, it gets slow, and then it gets bypassed.
• Automation doesn't replace judgement. A green pipeline means the checks passed, not that the change was a good idea. Review still matters.

06 — Today at InSpaceSame ideas, new team

At InSpace I lead the Experience Team working on NOVA, and much of my own work now runs through coding agents, each in its own isolated worktree. I wrote about the whole setup separately. What matters here is that a room full of agents needs exactly what a team needs from a pipeline: a cheap way to check work while iterating, one check you can trust before anything goes up for review, and no duplicated effort.

So the same rules apply, one level down:

Boring is a feature. If releases are the least interesting part of your week, your pipeline is doing its job, and your team can spend its attention where it matters: on the people using what you ship.

01 — Where it comes fromWriting down "correct"

At finsit, part of Wolters Kluwer, I grew from junior into someone the team relied on for critical processes. The lesson that stuck from that time is that you can only hand work to someone else when tests and clear writing define what "correct" means. A good ticket, a clear acceptance criterion and a test that fails when it should are what let a new colleague change code they didn't write without breaking it.

At YieldComputer I learned the other half: teams get fast when the safety lives in the process, not in someone's memory. Nobody should have to remember to check; the pipeline checks.

An agent is the most extreme version of a new colleague. It's capable, it's fast, and it has none of the context that lives in the team's heads. So the question I care about isn't "can it write this?" but "can I trust what comes back?" My answer is the same as it would be for a person: agree on what done looks like, agree on the approach, and then let them work.

02 — The defaultRead-only by default

Every task session starts in its own git worktree, on its own branch, in plan mode: it can read the code, search and investigate, but it can't edit a file or run a command that changes anything. It stays that way until I approve its plan.

That sounds slow, but reading is cheap and wrong code is expensive. A plan is the cheapest place to be wrong, and there's a worked example of why below.

Once the plan is approved, a shared settings file pre-approves the tools the workflow needs (editing files, the package manager, git, the GitHub CLI, the test commands), so the agent doesn't stop to ask for every edit. Approval is one decision at the right moment, not fifty interruptions.

03 — The contractThe Definition of Done

The first thing a task session does is read the ticket and turn it into a Definition of Done: a checklist of observable outcomes. Not "implement the filter", but things you can check:

# observable outcomes, not activities
- [ ] user can <do the thing>
- [ ] <component> renders when <condition>
- [ ] no regression in <the flow next door>

That list isn't paperwork. It travels through the whole task, and every later stage answers to it:

1. Definition of Done
2. Plan addresses it
3. Code satisfies it
4. Verification walks it
5. PR reports each item

In the pull request, each item is ticked only if it was actually verified, in a test or in the running app. Vague acceptance criteria become a clarifying question before any planning. And for a trivial change, the Definition of Done is one line.

04 — The approachWhat goes in a plan

Before planning, the agent investigates. The rule is that it should never ask what the code or the ticket already answers. Whatever is still genuinely open (scope, edge cases, design choices) goes into one batched round of questions. Then comes the plan, which is short and always has the same shape:

• Files to touch and the approach, in a few lines.
• Risks: what could break, and what the change sits next to.
• The Definition of Done, restated, so I can see the plan actually covers it.
• The test strategy: which new or updated tests will cover the change. New behaviour ships with tests that would fail without it. The only exemptions are changes with no testable logic (copy, styling values, config), and each one has to be stated with its reason in the PR. "This area has no tests yet" isn't an exemption; it's a reason to write the first one.

Two details make this work in practice. The first is batching every wait. Each time an agent stops to ask me something, it can sit there for hours while I'm busy elsewhere, so it gets one round of questions and one plan approval, never a trickle of stops.

The second is an honest check on effort. If the investigation shows the work is heavier than the ticket suggested, like a data-model change hiding behind a "small" ticket, the plan says so and suggests restarting at a higher tier. It's advice, not a blocker: I decide.

05 — A worked exampleA plan, reviewed

Here's what a plan for a refactor looks like. It's an illustration rather than a real ticket, but it's the kind of work my team does all the time at InSpace: several reporting screens in NOVA each grew their own copy of a date-range picker, and the task is to replace them with one shared component in the design system. A standard-tier task, so the plan waits for me:

task  Move the date-range picker into the design system

definition of done
- [ ] one DateRangePicker in design-system/date-range-picker/
- [ ] every reporting screen uses it; the local copies are deleted
- [ ] presets, keyboard use and focus order behave as before
- [ ] no visual change on any screen

files
  design-system/date-range-picker/
    new component, stories, tests
  features/reporting/*/filters.tsx
    swap to the shared picker
  features/reporting/lib/presets.ts
    delete, moved into the component

approach
  1. start from the most complete copy
  2. normalise the presets into one list
  3. compute ranges as [today − n days, today], in the browser's timezone
  4. swap one screen at a time, deleting each old copy after its swap

risks
  - screens pass dates in two formats (Date and ISO string)
  - while I'm here: align the picker with the new input styles

tests
  - unit: each preset's range, month boundaries, leap years
  - interaction: keyboard selection and focus return, in Storybook

open questions
  none

It looks thorough, and most of it is good. It also makes three decisions it had no business making on its own. They're highlighted above, and these are the comments I'd leave:

• A business rule, read as codenormalise the presets into one list · [today − n days, today]The copies aren't duplicates by accident. In this example, the product defines "Last 30 days" as the 30 complete days before today, because today's numbers are still coming in, and one screen's "This month" means month-to-date while another shows the full calendar month. "Normalising" them would pass every test the agent wrote, since the tests would encode the same assumption, and quietly change numbers clients look at. Keep each definition exactly as it is. Where two copies disagree, that's a question for product, not a refactoring decision.
• An assumption about something outside the repoin the browser's timezone · open questions: noneHow dates are interpreted, and which ranges the reporting API accepts, is decided in another service. The agent can't see it, so it shouldn't guess it. A refactor that touches an external contract and has no open questions is the tell. Send exactly the dates each screen sends today, and list the rest as questions.
• Scope creepwhile I'm here: align the picker with the new input stylesNot in this task. A refactor with a visual change in it is two changes in one diff, and the Definition of Done already says "no visual change". Separate ticket.

After one round of comments, the parts that changed read like this:

- 2. normalise the presets into one list
+ 2. keep every preset's definition exactly; list copies that disagree
- 3. compute ranges as [today − n days, today], in the browser's timezone
+ 3. send exactly the dates each screen sends today
- while I'm here: align the picker with the new input styles
+ out of scope: restyling (separate ticket)
+ tests: each screen sends the same query before and after the swap
- open questions: none
+ open questions:
+   - which timezone does the reporting API expect? (lives outside this repo)
+   - two screens define "This month" differently: which one is right?

Those are the two mistakes I look for first in any plan, and they're the same ones a capable new colleague makes: treating a business rule as an implementation detail, and filling a gap outside the repo with a plausible guess. Both look perfectly reasonable in code, and CI passes because the tests share the assumption. Reading the plan took a minute. Catching the same thing in review means reading a diff across every reporting screen. Catching it after release means explaining to clients why their numbers moved.

06 — ProportionalityScaling the ceremony

There's a trap in all of this. Apply the full process to every task and a one-line copy fix takes an afternoon. My first version did exactly that: small fixes went through the same heavyweight process as real features. The fix was to make depth scale with a complexity tier that I pick when I dispatch the task:

The tier also picks the model and how hard it thinks, from a light, fast model for trivial work to the strongest one at maximum effort for the rare critical change. When I'm torn between two tiers, I pick the higher one: under-powering a hard task costs more than a bit of extra thinking.

One iteration I'm glad I made: tier up for thinking, not for fleet size. Complex work used to fan out into several parallel agents. Now only critical work does, and even that is capped. One strong session plus an independent review catches more per unit of machine than a fleet, and keeps the laptop usable.

07 — Complex & critical workA cold second opinion

For complex and critical tasks, the draft PR gets a second reviewer before it reaches me. It's a fresh agent that is deliberately given only the PR and the repo's review checklist: no plan, no reasoning, no conversation history. It reviews what the diff is, not what the author meant. Its instructions put it better than I can:

“If something only makes sense with context you weren't given, that's a finding. A human reviewer won't have that context either.”

It works through a fixed set of lenses and actively tries to break the change rather than confirm the happy path:

• Claim versus diff. Does the code deliver every Definition of Done item the PR ticks off? An unmet ticked claim is the most serious kind of finding.
• Correctness. Edge cases, error paths, empty states, races and partial failures.
• Hidden coupling and the checklist. The caller the diff forgot, and this repo's known review traps, item by item.
• Test adequacy. Would the new tests fail without the change? Are failure paths covered, or only the happy path?
• Security and data integrity. Authorisation on new server paths, and checks that only exist in the client.

It has to try to refute its own findings, and anything it can't back with a concrete failure scenario gets dropped. The author fixes what's confirmed, one more cold review checks only the fixes, and if findings survive that, the task comes to me instead of looping. The reviewer is read-only: it never edits, pushes or approves, and its report is posted on the PR for the human reviewers.

08 — Trade-offsWhat it costs, honestly

The line from my task instructions that sums it up is this one:

“The deliverable is not a PR. It's a PR a human reviewer approves without rework.”

Everything before the code (the Definition of Done, the plan, the tier) exists to make that sentence true more often. It's not a new idea. It's what good teams have always done with a new colleague. The agents just made it impossible to skip.

01 — Where it startedOpinions are cheap

At YieldComputer I introduced product analytics and instrumentation to the team. Before that, we could see what we shipped but not how people used it, so prioritisation leaned on judgement, anecdotes and whoever made the strongest case in the room. That isn't a criticism of anyone. Without evidence, judgement is all you have.

The change I cared about most wasn't a dashboard. It was the team moving from pure development to product-oriented thinking: asking who a feature is for, what it should change, and how we'll know. Analytics gave that shift something to stand on. "I think users want this" became "here's what users actually do", and prioritisation got a basis the whole team could see.

02 — Decisions firstStart from the decision

The most common way to start is also the worst: install a tracker, switch on everything it can capture, and hope insight falls out. It doesn't. You end up with a large pile of events that nobody trusts and nobody reads.

I work backwards instead:

1. Decision
2. Question
3. Signal
4. Event
5. Review

First, name a decision the team will actually have to make. Then the question behind it, the signal that would answer that question, and only then the event that produces the signal. The last step is agreeing when you'll look at it again. A few illustrative examples:

My rule is simple: if I can't name the decision, I don't add the event. That alone keeps the tracking plan small enough to trust.

03 — A small vocabularyName things once

Events are an API between the product and everyone who reads the data, so I treat them like one: a small vocabulary, a consistent grammar, and changes that get reviewed like code.

# object_action · past tense · snake_case
report_exported            { format: "csv", surface: "dashboard" }
onboarding_step_completed  { step: "connect_site" }
filter_applied             { filter: "date_range", surface: "table" }

# properties describe the context, never the person:
# no emails, names, free text or anything that identifies someone

• Object, then action, in the past tense. Events record something that happened. export_clicked tells you about a button; report_exported tells you about an outcome.
• Properties add context, not identity. Which surface, which format, which step. They never say who the person is.
• One tracking plan, in the repo. It changes through pull requests, so a rename is a reviewed change rather than a silent break in every chart that depends on it.
• Instrumentation is part of "done". If a feature exists to change behaviour, the pull request that ships it also ships the events that show whether it did.

04 — FocusInstrument the path that matters

You don't need to measure the whole product on day one. You need to measure the path that decides whether someone gets value: from arriving, to the first moment it works for them, to coming back.

Activation is usually where the biggest and cheapest wins hide, because every new user walks through it. Everything that goes wrong there goes wrong for everyone.

So I start with one path, instrumented end to end and checked against reality before anyone draws conclusions from it. One funnel you trust beats ten you argue about. Then I widen, one question at a time.

05 — RitualsA metric nobody looks at is noise

The failure after launch is quieter than the one before it: dashboards that exist and nobody opens. A number only matters if it's attached to a moment when someone will act on it, so I tie metrics to the rituals the team already has:

• Planning. Every item meant to change behaviour says which signal it expects to move, and in which direction.
• Retros and release reviews. We look at what moved, and just as importantly at what didn't.
• An owner per metric. Someone who notices when it breaks, drifts or stops making sense.

Numbers need conversations

Quantitative data tells you what is happening and where. It rarely tells you why. For that I pair it with qualitative evidence: watching real sessions (with inputs masked), reading support conversations, and talking to the people who use the product.

“The numbers tell me where to look. The conversations tell me what I'm looking at.”

06 — Privacy by designTrack behaviour, not people

Privacy and security are long-standing interests of mine. In 2024 I took Cisco's Cybersecurity Foundations, which covers privacy and data confidentiality, and my own accounts live on Proton. So when I introduce analytics, privacy isn't a legal checkbox at the end. It's part of the design:

1. Consent first.No tracking before someone has said yes, and saying no is as easy as saying yes.
2. Collect the minimum.Every property has to earn its place against a question. If it can't, it goes.
3. No personal data in events.No emails, names or free text in properties, and identifiers that are pseudonymous rather than personal.
4. Mask by default.Session replays and heatmaps hide inputs and sensitive text unless someone deliberately decides otherwise.
5. Tooling that fits the jurisdiction.In Europe that means EU hosting, clear processing terms and sensible retention. PiwikPro, which we used at YieldComputer, is built for exactly that world.
6. Keep data only as long as the question needs it.Raw events aren't an archive. Retention should follow purpose.

Done this way, privacy and good analytics pull in the same direction. Fewer, better events are easier to trust, and easier to defend.

07 — How engineering changesSmall, observable steps

Once a team can see behaviour, the way it builds changes too. Features ship in smaller slices, because each slice can be checked. Risky changes go behind feature flags, so you can roll them out to a few accounts, watch, and then widen or roll back. When a question is genuinely open, you run an experiment instead of an argument.

The most valuable change is the least visible one: deciding what not to build. Evidence makes it much easier to push back, gently, when a feature is solving the wrong problem, because the conversation is about what users do rather than whose opinion wins.

08 — The honest partWhat can go wrong

• Vanity metrics. Page views and total sign-ups go up and to the right and tell you almost nothing. Prefer signals tied to a decision.
• Instrumentation debt. Events rot like code: buttons get renamed, flows get removed, naming conventions get half-migrated. Without a tracking plan in the repo and a review step, your charts quietly start lying.
• Over-reading small numbers. In B2B products especially, a handful of accounts can swing a chart. Treat small samples as a prompt for a conversation, not as a verdict.
• Correlation dressed up as causation. People who adopt a feature are often simply your most engaged users. Experiments or careful comparisons beat eyeballing a trend.
• Dashboards as theatre. A wall of charts can make a team feel data-driven without changing a single decision.

09 — TodayEvidence as a product

At InSpace, the Experience Team builds NOVA, where evidence is the product itself. Clients open it to see how their organic traffic, their rankings and their citations in AI answers are moving. That makes these rules doubly relevant. Every number we put on a client's screen should answer a question they actually have, mean the same thing everywhere it appears, and lead somewhere they can act.

For my own product work, these days I reach for PostHog. Having events, funnels, feature flags and session replays in one place makes the whole loop much easier to close.

01 — 2018 · A user firstA product you live in

A smart home is an unusual kind of product. You're the engineer, the product manager and the main user all at once, and the feedback loop is your own daily routine. When something is off, you don't see it in a dashboard. You notice it at home.

What keeps me on Home Assistant is simple: it runs locally, it's open source, and I can read how it works. Privacy and security are long-standing interests of mine, and a home that needs someone else's cloud to switch on a light has never sat right with me.

I've also never tried to build the "finished" smart home in one go. Like my work setup, it has changed in small steps over the years: make one change, live with it, and keep what earns its place.

1. 2018
   A user first. I started running Home Assistant, and I've been improving my setup a little at a time ever since.
2. Sep 2025
   First pull request. I forked the frontend and proposed synchronised zoom across the charts in the history panel.
3. Oct 2025
   Shipped. The feature went out in Home Assistant 2025.10 and made the release notes.
4. Autumn 2025
   Follow-ups and fixes. A fix for my own feature's rough edges, a bug left behind by a component migration, and a clearer energy card.
5. Dec – Jan
   Login and automations. Forgiving whitespace in 2FA codes, and fractions of a second in automation timings.
6. Today
   Still a user first. My own setup keeps changing, and the frontend is where I go when something could be better for everyone.

02 — Sep 2025 · Getting mergedThe first pull request

What turned me from user into contributor was the possibility itself. Home Assistant is one of the biggest open-source projects around, and its frontend is open to anyone willing to learn a corner of it. Understand one part well enough and you can improve it for a huge number of people who'll never know your name. For someone who builds interfaces for a living, that's a rare kind of leverage.

My first real contribution was a feature for the history panel. When you have several charts there, zooming into one now zooms all of them to the same time range, so you can compare what different entities were doing at the same moment.

Writing it was the easy part. Getting it merged taught me five things:

1. The process is part of the product.My first attempt didn't last a minute. The project's bot flagged commits that weren't linked to a GitHub account, so the contributor licence agreement check couldn't pass. I closed it and opened a clean one with properly linked commits. Reading the contribution guide first is part of the work.
2. Someone else might be building the same thing.Another contributor pointed out an earlier pull request that looked similar. Rather than compete, I offered to coordinate with its author. They ended up testing mine and caught a regression: the hover tooltips on the graphs had disappeared. I fixed it and posted a recording.
3. Use the system's components, at the right layer.A maintainer's review reshaped the code. Instead of dispatching zoom events from the parent, add a public zoom method on the base chart component and let each chart pass calls through to it. Use the project's own floating action button rather than a generic icon button. Respect the device's safe-area insets. Remove the props nothing reads. None of that was about whether zoom worked. It was about whether the code fitted a UI built by a very large community.
4. Performance on real devices is part of "done".Before approving, a maintainer asked how it behaved with lots of charts on a phone. I tested it on my phone with all of my own entities loaded. It was slow with that many charts, but usable, and another maintainer confirmed the slowness wasn't coming from the zoom sync.
5. Evidence beats argument.At one point a reviewer saw three bugs I couldn't reproduce. Instead of debating it, I posted a screen recording of everything working. Their build turned out to be the problem, and the next review was an approval.

It was labelled Noteworthy and shipped in Home Assistant 2025.10, where the release notes put it simply:

“When you have multiple charts in the history panel, zooming in on one chart will now automatically zoom in on all other charts as well.”

03 — After the mergeShipping is the start

After it merged, rough edges showed up. Graph lines were drawn over the new reset button, a second scrollbar could appear, and when several history graphs shared a panel, the wrong reset button responded. Within a week of the merge I opened a follow-up fix, and it was merged the next day.

The same thread was a lesson in scope. When I asked the contributor who'd reported the issues to test the fix, they asked for more: syncing charts on dashboards too, and moving the reset button into the toolbar. They were good ideas, but my pull request was a bug fix. Syncing dashboards would mean wiring the logic into every page, which deserved its own feature request rather than a PR too big to review and test. I checked the button on a small iPhone screen to answer the size concern. The double scrollbar turned out to be an existing issue in the virtualised list, not something I'd introduced, so I said so and left it for its own issue.

04 — The smaller onesSmall fixes, sharp lessons

After that I kept an eye out for small things. Not all of them merged, and the ones that didn't taught me just as much.

• Merged
  Sort installed add-ons by name on the logs page Add-ons in the logs picker now appear alphabetically, after the built-in log sources. A list in no particular order makes you read every item.
• Merged
  Fix the target picker's buttons after the tooltip migration A migration of the tooltip component had prefixed element IDs, so the target picker's remove and expand buttons received the wrong ID. I fixed it and asked a maintainer to check for the same pattern elsewhere. In a big component library, a migration's bugs rarely come alone.
• Merged
  Add total consumption to the energy usage graph card The solar and gas cards already showed a total, but this one didn't. A maintainer explained why: this chart also shows grid return and battery charging, so a bare number would be ambiguous. We made it read as energy used, and kept the card's layout in line with its siblings. A number without a label is a question.
• Merged
  Trim whitespace from 2FA input before validation A correct 2FA code with a stray space was being rejected. My first version trimmed input too broadly. Review pointed out it would affect far more than the 2FA field, so I moved it into the login functions. Keep the fix as small as the bug.
• Merged
  Accept decimal seconds in time inputs Automation triggers and conditions can now use fractions of a second. The discussion was all about details: whether to show a separate milliseconds field, and how to pad a value like 0.2. I proposed keeping the existing formatting for consistency, and a maintainer decided to skip padding when there are decimals. Bring options, and let the people who own the design make the call.
• Closed
  A friendlier error for duplicate dashboard URLs Another contributor had fixed the same thing in parallel while I was on holiday without my laptop, so I closed mine in favour of theirs. The review thread also found the real fix a layer down: the backend should return error codes the frontend can translate, not raw messages. Sometimes the right fix lives one layer below yours.
• Closed
  Back-button protection for unsaved changes Review showed my approach left an extra entry in the browser history, so leaving a page would take two presses of the back button. The pull request was closed. A closed PR can teach more than a merged one.

05 — LessonsWhat a big frontend teaches

Home Assistant's frontend is one of the largest open-source user interfaces I know of, maintained in public by people who don't know you. Contributing to it sharpened habits I now rely on every day:

1. Write pull requests for strangers.Reviewers don't know you, your context or your intentions. Before-and-after screenshots, a screen recording and a clear "why" do the persuading.
2. Consistency is a thousand small agreements.Use the project's own components, keep sibling cards in sync, respect safe areas. No single rule makes a UI feel coherent; following all of them does. It's the same work I now do with the Experience Team at InSpace, building components and patterns that scale across NOVA.
3. Fix things at the right layer.A public method on the base component, error codes from the backend: the best review comments moved my fix to where it belonged.
4. Scope is a kindness.Small, reviewable changes get merged. Bigger ideas become their own issues.
5. Maintainers make the call.Bring evidence and options, then accept the decision. It's their product, and their time is the project's scarcest resource.
6. Closed isn't failed.Two of my pull requests were closed without merging, not counting the one the bot caught, and both left me knowing something I didn't before.

06 — Still a userLocal-first, slowly

Contributing hasn't changed why I use Home Assistant. It still runs locally, I still improve my setup in small steps, and I still care more about it being dependable than clever.

It also connects to my day job more than I expected. At InSpace I lead the Experience Team, building the interface NOVA's clients use every day. Home Assistant shows what that looks like at the scale of a huge community: the details are the product, and the best interfaces are the ones nobody has to think about.

If you want to see the work, my pull requests are public. And if you're tinkering with a smart home of your own, I'm always up for swapping notes.

01 — 2019 · BarcelonaOwn the whole path

My first job in software came right after a web development bootcamp at Ironhack. I joined Nakima in Barcelona as a fullstack developer, and it was agency work at its busiest: web apps in React and Angular, mobile apps in React Native, backends on Firebase and MongoDB, and one project that ran facial recognition on the device itself.

What stayed with me had little to do with frameworks. I owned client requirements from start to finish (scoping, delivery, the next iteration), and I was often the person translating between designers, the backend team and the client. Two lessons came out of that. First, the job isn't writing code, it's shortening the distance between someone's problem and a working solution. Second, switching context is expensive. Every time you jump between projects you pay a re-entry cost, and nobody budgets for it.

02 — 2021 · RemoteTrust comes from tests

In 2021 I joined finsit, part of Wolters Kluwer, working remotely. I built frontend modules on top of internal libraries, contributed to C# services, and spent a lot of my time making critical flows dependable with Cypress and Jasmine. I also modernised shared components and tooling, and that sped up the whole frontend team more than any single feature I shipped.

That's where I grew from junior into someone the team relied on for critical processes. It's also where I learned that you can only hand work to someone else when tests and clear writing define what "correct" means. That someone might be a teammate, a new hire or, as it turned out, an agent. The other lesson was that shared tooling is some of the highest-leverage code you can write.

03 — 2024 · EindhovenPipelines over heroics

At YieldComputer, from 2024 to mid-2026, I automated the release pipeline, defined a testing strategy across unit, integration and end-to-end tests, and introduced product analytics so we could prioritise from evidence instead of opinion. The results are on my homepage, but the lesson is simpler: teams don't get fast by working harder. They get fast when shipping is safe and boring, and when that safety lives in the pipeline instead of in someone's memory.

It's also where I learned to lead without formal authority. You find the bottleneck, build something that removes it, and make it easy for people to adopt. Then you look for the next bottleneck.

04 — 2026 · InSpaceMake it effortless

On 1 July I left YieldComputer and joined InSpace. InSpace builds NOVA, an autonomous AI platform for SEO and GEO (generative engine optimisation). It researches, writes, optimises and publishes the content that gets brands found, both on Google and in the answers of ChatGPT, Gemini, Perplexity and Claude.

As a senior engineer, I lead the Experience Team. We build the platform our clients see and use every day, from their dashboards to the moment they approve a page. Interfaces that feel effortless take precision and taste. Much of my work is building components and patterns that scale across NOVA, keeping the whole product consistent as it grows.

I also try never to stop at "does it work?" I want to know who's using it, what they're trying to achieve, and what the interface is really asking of them. That's why I'm as comfortable in a product conversation as in a pull request.

NOVA's promise to clients is "AI does the work. You make the call." Nothing ships without the client's yes, and every correction teaches NOVA, so it needs less checking next time. That turns out to be a pretty good description of how I build it, too.

05 — 2026 · The workflowEnter the agents

Claude had been my daily co-pilot for a while, for pairing on architecture, drafting and refactoring. A new team, a new codebase and a product that is itself built on AI changed the question from "can it help me write this?" to "can it take this ticket, and can I trust what comes back?" Answering it took everything from the chapters above, and it didn't happen in one go:

1. June
   Make the base reproducible. Before my first day at InSpace, I turned the machine itself into code: one command rebuilds my Mac.
2. July
   One task, one worktree. In my first weeks on the team: first a script that gives every task its own worktree and dev server. Then a cockpit that sends each task to its own tab and agent session, and a monitor that shows which ones are waiting on me.
3. August
   Past the pull request. The bottleneck moved to CI and review. A loop now watches every PR and sends failures and comments back to the session that wrote the code. Complex work gets a cold second review, and real review comments became checklists that every future task reads.
4. September
   Respect the machine. With many sessions on one laptop, builds started fighting over the cores, so expensive commands now queue for a slot. Small fixes were going through the heavyweight process, so how deep a task goes now depends on how complex it is. The menu bar learned about meetings.
5. This week
   Review gets its own tools. A PR opens as a staged diff in lazygit, Claude's first pass lands in my pending review, and one key jumps from a PR to the session that wrote it.

None of this was planned up front. Each step dealt with the bottleneck the previous one exposed. That's the same loop I used to run with teams, only now some of the team is software.

06 — The tourThe setup today

Here's where it stands this month, from the bottom up.

The machine

A MacBook Pro, usually docked to an ultrawide monitor. Everything runs on that one laptop, including every agent session, and it's configured entirely from mac-setup, a public repo:

$ bash <(curl -fsSL https://raw.githubusercontent.com/birrejan/mac-setup/main/bootstrap.sh)
# preflight → homebrew → dotfiles → languages → git → ssh
# → vscode → iterm2 → wm → macos → touchid → doctor
✓ every step is idempotent, and re-runnable alone with --only <step>

A Brewfile lists every tool, app and font. GNU Stow symlinks the dotfiles, so editing a config means editing the repo. doctor checks the result, and dump.sh syncs back anything that isn't a symlink. It also handles the dull but important bits: SSH-signed commits, Touch ID for sudo and sensible macOS defaults.

The desktop

AeroSpace tiles every window, so nothing overlaps and I move around with ⌥ hjkl. Some workspaces have a fixed job (chat, calendar, email), apps are routed to them automatically, and switching to one that's empty opens its apps. JankyBorders outlines the focused window, since tiled windows have no title bar to tell you where your keystrokes will go.

The menu bar is SketchyBar, extended with a small native Swift helper:

• Machine load at a glance. CPU and memory cards stay out of the way until the machine is busy, then turn amber, then red. With agents building in the background, this is my early warning.
• Meetings that don't sneak up. A pill appears half an hour before a call, joins it in one click and can start a Granola recording. It reads my calendars and never writes to them.
• Screen-share safe. Presentation mode hides app, media and meeting titles. A mic/camera card lights up only while either is live.
• Display-aware. It works around the laptop's notch and switches layout profiles when I dock or undock.

The terminal

iTerm2, zsh with no framework, Starship for the prompt, mise and uv for runtimes, and modern replacements for the classics: eza, bat, ripgrep, fd, zoxide, fzf. My pull-request queue lives in gh-dash, grouped by what needs doing (CI failing, changes requested, ready to merge, needs my review), with a few keybindings I added:

The agents

~/Projects is a cockpit for NOVA's codebases: the app, its design system and the services around it. A Claude Code session started there doesn't write feature code: it starts tasks, tracks them and gets them merged. I describe the work, and the cockpit builds an isolated worktree from the latest base branch, registers the task and opens a new tab with a pre-briefed session. Every task starts read-only, in plan mode, and works through the same pipeline:

1. Ticket
2. Definition of Done
3. Clarify
4. Plan
5. Implement + tests
6. Gate
7. Self-review
8. Verify in the app
9. Draft PR
10. Second review
11. Ping me

How deep a task goes depends on a complexity tier. A typo fix gets a plan of a few lines that I can approve at a glance. Standard work gets a fuller plan and a full self-review. Complex work also gets an independent second review: a fresh agent sees only the PR and the checklist, never the author's reasoning, and reviews it cold.

Once a PR is open, a loop in the cockpit watches CI and review comments and sends anything actionable back to the session that wrote the code. When a human review comment applies more widely, it's added to that repo's review checklist, which every future task reads while coding and again at self-review. For example:

“Fail-open guards: never discard the error from a query used as a guard. A read error must fail the action, not let the write proceed.”

A lesson written there is a review comment no future PR needs. Around all of this, clorch shows which sessions are working, idle or waiting on me. A shared slot pool makes expensive builds and test runs queue instead of competing, so the laptop stays responsive while many tasks are in flight.

07 — Professional defaultsGuardrails I don't bend

Speed only counts if you can stand behind what ships. These rules hold for every task, whatever its size:

1. Plans before code.Every task starts read-only, in plan mode, and nothing changes until I've approved its plan. For a small fix that plan is a few lines, so approving it takes a glance.
2. Isolation by default.Each task has its own branch, worktree and environment. Nothing touches my main checkout, and nothing touches another task.
3. Evidence, not claims.A PR carries its Definition of Done, test output, a self-review summary and proof from the running app. "Done" is something you can check.
4. A human reviews every diff.Agents open drafts. I review, my teammates review, and people decide what merges.
5. Lessons get written down.Review feedback becomes a checklist, so the same comment never has to be made twice.
6. The machine is a shared resource.Expensive work queues for a slot rather than grinding the laptop for everyone, me included.

08 — People & fitWho it's for

First, who does what. The setup only works because the split is explicit:

And who should copy it:

09 — Benefits & trade-offsWhat it buys me

• More in flight, less in my head. Several tasks move in parallel, and each one keeps its own context, so picking one up again is T, not ten minutes of rereading.
• Time back for the product work. More of my day goes to deciding, shaping tickets, reviewing and talking to people: the parts of the job I think matter most.
• Quality that compounds. Checklists and cold reviews mean the same mistake isn't made twice, by me or by an agent.
• Reproducible by default. One command rebuilds the Mac, and every config change lands in a repo as I make it.
• Focus. The desktop gets out of the way. Load, meetings and the PR queue are visible without going looking for them.

The honest trade-offs

• The bottleneck moves to review. Reviewing well is most of the job now, which is why review has its own tooling.
• Agents are only as good as the ticket. Vague in, vague out. That's why every task starts by writing a Definition of Done.
• It's my own glue. Shell scripts, skills and config. That's powerful, but when something breaks, I'm the maintainer.
• Compute and tokens aren't free. That's why depth scales with complexity, and heavy multi-agent work is kept for the few tasks that need it.

10 — Always iteratingNever finished

This setup is never done, and I've stopped wanting it to be. It changes on two rhythms:

What makes that sustainable is the same discipline I'd expect from any production system. Everything lives in versioned files. Decisions sit next to the config they explain. And a change doesn't count until it's written down somewhere the next task, or the next version of me, will read it.

Next month, parts of this post will be out of date. That's the point.

Standing on shoulders

• AeroSpacetiling window manager
• SketchyBarthe menu bar
• JankyBordersfocus outline
• gh-dashPR dashboard
• lazygitgit & review UI
• clorchagent session monitor
• Claude Codethe agents
• Starship & miseprompt & runtimes

If you want to take something, start with mac-setup. It's public and it's meant to be forked. If you're building your own agent workflow, I'd love to compare notes.