Kurashizu's Blog

I keep a short list of rules for how I set up my tools and how I expect any assistant working with me to behave. None of them are exotic. Taken individually, most look like ordinary preferences — use this package manager, use that CLI, prefer this framework. But they all come from the same place, and I think that place is worth explaining, because the reasoning matters more than any single rule does.

The short version: I only do things one way if there's a reason to do them another way. Complexity doesn't disappear when you ignore it — it moves. It moves from "solved once, upstream, by someone who has time to solve it properly" to "re-solved, badly, by me, under time pressure, at the exact moment I least want to be debugging a tool instead of using it." Every rule below is an attempt to keep complexity on the far side of that line.

Case study: why I don't touch the AUR

The clearest example is Arch Linux package management. I use pacman and nothing else — no AUR helpers like yay or paru, not without a deliberate, conscious exception.

pacman on its own is a well-scoped tool: it installs, upgrades, and removes signed binary packages from a small set of trusted repositories. The hard part — does this build correctly, with the right dependencies, in a clean environment — gets solved once, by a maintainer, before the package ever reaches me. That's complexity paid for a single time and amortized across everyone who uses the package.

The AUR breaks that model. It isn't a repository of packages; it's a repository of build scripts that anyone can submit and that run arbitrary code on your machine at install time. Worse, because AUR packages are compiled locally instead of distributed as binaries, every cost the official repos absorb once gets paid again on every machine, every time: bloated build dependencies that never get cleaned up, build environments that silently drift and break PKGBUILDs that worked yesterday, and routine -Syu upgrades that turn into unpredictable compile queues. And because makepkg alone can't resolve AUR-to-AUR dependencies, using the AUR in practice means adopting an unofficial helper with its own defaults and its own trust model, bolted onto pacman from outside.

None of that means AUR packages are bad software — "not in the official repos" mostly reflects who had time to maintain a package, not its quality. But the AUR as a mechanism asks every user to re-absorb complexity that a well-designed system should have resolved once. My answer is to stay entirely inside official repositories and Flatpak. Flatpak, for anything precompiled, gets you sandboxing and clean removal without the build uncertainty — the same convenience the AUR's binary packages promise, without the trust problem.

The same logic, once you see it in one place, turns out to explain most of the other rules too.

Same logic, different tools

SvelteKit, and only SvelteKit, for the web. Not because Next.js or Nuxt are bad frameworks, but because maintaining fluency across multiple meta-frameworks is complexity with no payoff if I'm only ever going to ship in one of them. Picking one and going deep beats staying "flexible" across three.

uv, and only uv, for Python. pip, poetry, and pipenv each solve dependency management differently, with different lockfile formats and different failure modes. Committing to uv for init/add/run/lock means there's exactly one dependency resolution model to reason about, ever, instead of remembering which project uses which.

brew on macOS, the same instinct as pacman on Linux. One package manager, one trust boundary, no exceptions without a reason — the platform changes, the principle doesn't.

A fixed, non-overlapping toolchain for everything else. Web search goes through ddgr, page content through r.jina.ai, and library documentation through ctx7 — three tools with three distinct jobs, not one tool trying to do all three badly. gh, hf, wrangler, and aws are the defaults for their respective platforms because they're already authenticated and already the canonical client — reaching for a raw API call or a third-party wrapper when the official CLI exists is complexity with no upside.

One tool per media job. edge-tts for text-to-speech, ffmpeg for literally everything else audio, video, or image — converting, trimming, concatenating, muxing, extracting, thumbnailing. ffmpeg already does all of this in one line; writing a custom script to replicate what a single, well-tested flag combination already does is exactly the kind of self-inflicted complexity the rest of this list exists to avoid.

Time-sensitive questions get searched, not guessed. Prices, versions, news — anything that changes — gets checked rather than answered from memory. This one isn't about tooling at all; it's the same principle applied to knowledge instead of software: don't let stale, unverified state quietly stand in for a five-second check.

Long tasks get estimated and polled, not blocked on. And background work goes in tmux, not nohup — because tmux gives you a session you can reattach to and actually observe, while nohup gives you a process you've fired and can only hope is still working. Predictability over convenience, again.

Why bother writing this down

None of these rules are individually interesting. What's worth defending is the discipline of applying the same test to all of them: does this choice make complexity someone else's problem, solved once, or does it make complexity my problem, solved repeatedly? The AUR fails that test structurally. So does using three Python package managers because three different tutorials happened to use three different ones. So does writing a bespoke video-processing script because ffmpeg's one-liner wasn't immediately obvious.

Keeping a written list forces the discipline to outlast the mood I was in when I made the decision. It's easy to justify "just this once" in the moment — one AUR package, one curl | sh install, one custom script instead of the boring existing tool. The list exists so that "just this once" has to be a deliberate, visible exception, not a default I drift into because it was slightly more convenient at 11 PM. Simplicity isn't the absence of rules. In my experience it's the presence of a few rules I actually keep.