---
title: ['Build Your Own', 'Lightsaber']
description: 'Vibe code your own harness tools. Like building your own lightsaber, it teaches you how the thing actually works, and it should be cheap enough to throw away.'
---

I'm going to make a _painfully_ dorky analogy. Vibe coding your own harness tools is like building your own lightsaber.

There are really three core beliefs behind this.

(1) One is that building it teaches you how it works. A Jedi builds their own saber so they understand it, not because the borrowed one doesn't cut. Writing a hook teaches you exactly when it fires, what the model sees, and what it quietly ignores. When a borrowed tool fails you're debugging a black box. When your own fails, you can reason about why (and perhaps find a better way).

(2) The second is that it's a key accelerant. I put half my day into [supporting tools](/sharpening-the-axe/) and still target 100 PRs a day. That only works because the tooling pays for itself. It's painful at first (because it's slower), then it starts to compound, and every model release compounds _again_ on another axis. Treeline is just one example: a menu bar app that drops me straight into the PRs that need attention and keeps score against the hundred.

<figure style="margin: 2rem auto; text-align: center;">
  <img src="/images/2026-10-16-build-your-own-lightsaber-treeline.png" alt="Treeline, a vibe-coded macOS menu bar app showing a 24-hour chart of open and merged pull requests, merge counts, and a burndown list of PRs with review and CI status." width="982" height="1664" style="width: 100%; max-width: 360px; height: auto; display: block; margin: 0 auto;">
  <figcaption style="font-size: 0.9em; opacity: 0.75; margin-top: 0.75rem;">Treeline, my menu bar tool for quickly jumping into PRs and tracking against my 100-a-day goal.</figcaption>
</figure>

(3) Finally, it's the piece that should be vibe coded. You can really cut loose when the only customer is you, and I've learned more about the potential (and limitations) of vibe coding from building out my own harness than from anything else. As long as they're secure, I don't need to be particular about how they're built, and I'll happily build them in Swift (like Treeline) or whatever else fits. Things are moving _fast_ in this space, and harnesses [turn over fast](/vibe-coding-dev-tools/) too. More than once I've built something only to find it shipped as a [standard feature](/the-pace-of-ai-tools/) shortly after. I had a tool that automatically detected comments on a PR and got Claude to respond. It was a standard feature in Claude Desktop three months later. Don't get attached. If something better comes along, eject the code and move on.

Even when nobody ships your tool as a feature, it goes stale on its own. Every model update shifts what the AI gets wrong, so a hook that was essential one quarter is pure noise the next. And tooling can become its own distraction; it's easy to lose an afternoon perfecting something you'll barely use. So build the tool when you hit the same bump twice, use it on the next PR, and delete it as freely as you built it. The test isn't whether it was satisfying to make, it's whether it earned its place in today's work.

Borrow a saber to get started. But if you live in the harness all day, build your own, and build it cheaply enough that you'll happily build the next one.