DEV Community: Mariano Álvarez

Why I choose Bun for my projects, for now

Mariano Álvarez — Tue, 11 Aug 2026 07:30:32 +0000

For most of my career "JavaScript runtime" meant Node, full stop. That stopped being true a while ago. Deno and Bun are both stable, both used in production somewhere, and both worth an honest look instead of a reflex "Node just works." This is where I landed after actually running Bun on my own side projects for a while: I like it, I'm keeping it, and I'm not calling it permanent.

What actually made me switch

It wasn't a benchmark. It was bun install.

The first time I ran it on a project with a few hundred dependencies, I assumed something had failed silently because it finished before I'd read the output. No node_modules progress bar to stare at, no coffee break. That single, boring, repeated-dozens-of-times-a-day interaction is what made the difference for me, not a single flashy number.

Everything else followed from there:

bun init
bun add hono zod
bun run dev      # runs .ts directly, no ts-node, no build step
bun test         # Jest-compatible API, no separate runner to install

One binary is the runtime, the package manager, the bundler, and the test runner. No tsconfig gymnastics to run a script, no jest.config to get a test suite going, no separate watcher. For a personal project I'm poking at in short bursts, every one of those is friction I used to just accept as the cost of doing JavaScript.

What I'm not claiming

I'm deliberately not repeating throughput numbers here. Every runtime's team publishes benchmarks that make their own runtime look best, measured on a workload they picked. That's true of Bun's marketing as much as anyone else's, and I have no independent way to verify the specific figures floating around comparison posts. What I can vouch for, because I've felt it directly:

Install and startup are consistently fast. Not "4x" fast in some universal sense, but fast enough that I stopped thinking about it.
TypeScript runs with zero setup. bun run script.ts just works — full syntax, no flags, no stripped-down subset.
The built-in test runner and bundler are genuinely usable, not toy versions you'll outgrow immediately.

Node.js has closed a lot of this gap on its own. node:test is stable, --watch replaces nodemon for most cases, and recent Node versions can execute TypeScript directly via type stripping — though only for "erasable" syntax; enum and namespace still need an experimental flag, and type stripping doesn't do actual type checking (keep tsc --noEmit in CI regardless of runtime). Node's permission model is also real, and it's something Bun doesn't have an equivalent for: Bun runs with full trust, no sandboxing, so anything your dependencies can do, they can do unrestricted.

Where I still don't reach for Bun

Deno's pitch is worth taking seriously precisely because it's different from Bun's: deny-by-default permissions. A Deno script can't touch the filesystem, network, or environment variables unless you explicitly grant it. That's a structurally different security posture than either Node or Bun offer, and for anything handling secrets or third-party code I don't fully trust, it's the one I'd reach for instead.

And for this portfolio specifically, I'm not touching anything — it stays on pnpm and Node, per the project's own conventions. Bun is where I run new personal tools, scripts, and small services I'm building from scratch, not where I migrate something that already works.

The actual decision process

The only test that matters is your own dependency tree and your own workload, not a chart. What I actually do before adopting Bun on something new:

Install the real package.json and run the test suite. If a dependency leans on a native addon Bun doesn't support cleanly, I find out in minutes, not mid-project.
Check where it needs to run. Bun's hosting support keeps growing, but it isn't Node's "supported literally everywhere." I confirm the target platform before writing a line of code.
Accept that this can change. If I hit a wall — a package that won't cooperate, an observability tool that only instruments Node, a project that needs Deno's sandboxing more than Bun's speed — I'll use whichever runtime the project actually needs. Nothing here is a rule, it's a default.

Conclusion

Bun wins my day-to-day right now because the friction it removes is the friction I hit constantly: installs, TypeScript, running a test. That's not the same as saying it's objectively the best runtime, or that it will still be my default in a year. For now, on my own projects, it's the one that gets out of my way — and that's the whole bar it had to clear.

Docs: Bun · Node.js · Deno

I tried stacked pull requests on my own portfolio

Mariano Álvarez — Tue, 11 Aug 2026 07:29:06 +0000

GitHub just announced stacked pull requests in public preview. Instead of reading the changelog and moving on, I decided to actually try it on this same portfolio repo.

The problem it solves

I've done the manual version of this before: branch off a big feature, realize it's too large to review in one shot, and split it into a chain of branches that each target the previous one. It works, but every rebase is manual, and if the bottom branch changes, you're rebasing the whole chain by hand.

Stacked PRs formalize that pattern:

   ┌── feat/frontend     → PR #3 (base: feat/api-endpoints)  ← top
  ┌── feat/api-endpoints → PR #2 (base: feat/auth-layer)
 ┌── feat/auth-layer     → PR #1 (base: main)               ← bottom
main

Each PR only shows the diff for its own layer. Merge the bottom PR and GitHub automatically retargets the one above it to main. The key rule: if a layer depends on code from another layer, that dependency has to live in the same branch or a lower one.

Setting it up

GitHub ships a CLI extension for the local workflow:

gh extension install github/gh-stack

It needs gh ≥ 2.90.0, and my local gh was still on 2.83.2, so an upgrade came first. Once that was sorted, starting a stack looks like this:

gh stack init blog-stacked-prs-scaffold
# ... write code, then:
gh stack add -Am "feat: scaffold blog post about stacked pull requests"

gh stack add either commits to the current branch (if it has no commits yet) or creates a new branch on top of the stack, depending on where you are. That's exactly the mechanic I used to write this post: this section you're reading is its own layer, sitting on top of the scaffold layer that added the post's metadata and title.

What I actually stacked

For this post I split the work into three layers instead of one big commit:

Scaffold — the entry in data/blog-post.ts and the skeleton page.mdx with just the title and intro.
Content — this section, the actual body of the post.
Closing — conclusion and cleanup.

It's a small example, but it maps to the real reason I'd reach for this on a bigger change: shared types or data first, the logic that depends on them next, and UI last. Each layer becomes a PR that's small enough to actually review carefully instead of skimming a 40-file diff.

What I'd watch out for

Stacked PRs aren't free. A few things worth keeping in mind:

Ordering discipline matters. If you put a dependency in the wrong layer, you'll notice fast: the PR below won't build, or the one above will show changes that don't belong to it.
It's a solo-repo-friendly workflow too. I don't have reviewers on this portfolio, but splitting the work still forced me to think in terms of "what does this layer actually depend on," which is the same discipline that makes stacks worth it on a team.
Cross-fork stacks aren't supported. Everything has to live in the same repository, so this doesn't help for external contributions to a project you don't have write access to.

Conclusion

The manual version of this — chained branches, hand rebasing — always worked, but it was tedious enough that I'd only bother for genuinely large changes. gh stack removes enough of that friction that I'd consider using it for something as small as this post. The mechanism is simple: each layer is a branch, each branch is a PR, and the tool keeps the base branches in sync as the stack changes underneath.

Next time I have a change that's too big for one clean review, I know exactly where to start.

Docs: Stacked pull requests · Extension: github/gh-stack

I ran Claude Code unattended, all night

Mariano Álvarez — Tue, 11 Aug 2026 07:25:45 +0000

I keep a running list of small, well-defined tasks I never get to: a missing health-check endpoint, a flaky test, a config file that could use a default. None of them are hard. All of them lose every day to whatever is actually on fire. So I built auto-claude, a bash loop that picks tasks off a queue, runs Claude Code against each one in isolation, and only keeps the result if a command I chose says it passed.

The bottleneck isn't the model

The premise I started from: if the work is specified precisely enough, and something other than my judgment at 3 a.m. decides whether the result is acceptable, there's no reason a human needs to sit in the loop approving every step. That "something else" is a verification command — a test suite, a build, a lint pass, whatever proves the task worked. It either exits 0 or it doesn't. No vibes.

That reframes the actual bottleneck. It's not model capability, it's task specification. A vague task produces a vague result regardless of how good the model is. A task with a closed objective, verifiable acceptance criteria, and pointers to the right files is bounded by the model's competence, not by how many hours I spend babysitting the terminal.

How the loop works

queue/todo/*.md --> for each task:
                      git worktree from BASE_BRANCH   (my checkout stays untouched)
                      claude -p  <- prompts/build.md + the task
                      VERIFY_CMD
                        |- pass -> commit on branch auto/<task> [push] [PR]
                        |- fail -> claude -p --resume <- prompts/fix.md
                                   (bounded by MAX_FIXES)
                    --> queue/done/ or queue/failed/
                    --> logs/report-<timestamp>.md

One task at a time, each in its own git worktree so a bad run can't touch my actual checkout. If verification fails, Claude gets one more shot with a fix prompt, bounded by MAX_FIXES so a stubborn task doesn't burn the whole night. In the morning I read one report file: pass or fail per task, branch, diffstat, duration, cost.

The guardrails are the point

The loop itself is maybe 300 lines of bash. Nothing clever. Where the actual engineering went is the list of things that go wrong when nobody's watching, and what stops each one:

A run dying on a usage limit doesn't lose the task — it sleeps and resumes.
A hung verification command doesn't freeze the night — it gets killed after a timeout.
Two runs starting at once (a cron overrun plus me starting one manually) — a lock file refuses the second and recovers automatically if the first died mid-run.
Nothing gets marked done without VERIFY_CMD actually passing, and the prompts explicitly forbid deleting or skipping tests to get there.
MAX_BUDGET_USD caps spend per invocation; the report totals the real cost.
Everything defaults to not pushing and not opening a PR. The loop stops at a local branch until I've read enough mornings of reports to trust it.

None of this makes the model more capable. It makes an incapable or confused run fail loudly and cheaply instead of quietly doing something wrong on a shared branch.

What I'm not pretending

PERMISSION_FLAGS defaults to --dangerously-skip-permissions, because that's what unattended operation actually requires — Claude runs shell commands, edits files, and reaches the network without asking. The worktree isolates my source tree, not my machine or my credentials. Anything inside that worktree can see whatever SSH keys, cloud sessions, and tokens my shell can see. I'm not describing that as a sandbox, because it isn't one. If I were pointing this at something I actually cared about protecting, I'd run it inside a container with only the credentials that specific task needs, and I'd replace the permission flag with an explicit allowlist instead of skipping the check entirely.

Right now I run it against throwaway repos and side projects, PUSH_BRANCH and OPEN_PR both off, and I read every branch before it goes anywhere. That's not a limitation of the tool so much as the appropriate amount of trust for a script that executes AI-generated shell commands while I'm asleep.

What actually changed

Writing the task file is now the part that takes effort, which is the correct place for effort to go. "Add GET /health returning {"status":"ok"}" survives an unattended run. "Improve observability" does not — there's no verification command that can judge that, so it either loops forever trying to guess what I meant or passes something I didn't ask for. Once I started writing tasks like the first kind, the backlog of small annoying things actually started shrinking overnight instead of accumulating.

Repo: auto-claude on GitHub