Julio Merino's corner on Julio Merino (jmmv.dev)

I think AI is pushing me toward the AGPL

julio@meroh.net (Julio Merino) — Tue, 17 Mar 2026 16:00:00 +0100

Why agentic coding changes everything for the open-source craft and maintainership.

It has been two months since I’ve been using AI coding agents “for real”. In my previous article, I reflected on my experiment to vibe-code a full Emacs module from scratch. In there, I intentionally left one important question unanswered: what is the meaning and impact of agentic coding on the free software ecosystem we have all grown accustomed to?

Right now, I have many thoughts but no good answers, and the reason is that the more I use these tools, the more I doubt my long-held beliefs about open-source licensing. While I’ve found that agentic coding makes me more productive—provided I supervise the agents carefully, in some circumstances—it also distances me from the act of coding itself, stripping away the pride of craftsmanship and thus the desire to publish code as open source.

The bigger worry, however, is for the ecosystem as a whole. Let’s dive into what’s on my mind right now.

Reflections on vibecoding ticket.el

julio@meroh.net (Julio Merino) — Fri, 06 Mar 2026 08:00:00 -0800

It has now been a month since I started playing with Claude Code “for real” and by now I’ve mostly switched to Codex CLI: it is much snappier—who would imagine that a “Rewrite in Rust” would make things tangibly faster—and the answers feel more to-the-point than Claude’s to me.

As part of this experiment, I decided to go all-in with the crazy idea of vibecoding a project without even looking at the code. The project I embarked on is an Emacs module to wrap a CLI ticket tracking tool designed to be used in conjunction with coding agents. Quite fitting for the journey, I’d say.

In this article, I’d like to present a bunch of reflections on this relatively-simple vibecoding journey. But first, let’s look at what the Emacs module does.

Grumpy Julio plays with CLI coding agents

julio@meroh.net (Julio Merino) — Mon, 09 Feb 2026 09:30:00 -0800

Or the more tired “One week with Claude Code”-type article.

It’s no secret that I’ve been grumpy about the new AI-based coding trend. I’ve been grumpy about the “push from above to use AI or else”. I’ve been grumpy about the eye-rolling hype I see on LinkedIn. I’ve been grumpy about being on the receiving end of vibe-coded PRs that over-engineer solutions to simple problems. I’ve been grumpy about the thought that we are about to see an amount of bloat like we have never imagined before.

But, at the same time, I’ve been using LLMs to review my articles, to perform deep research, to generate cover pictures, and before last week, I had even dipped my toes into AI-based coding agents to help me with boring, repetitive tasks. And you know what? I see their promise of increased productivity, yet the amounts of slop I’ve witnessed make me skeptical and I have had little experience with coding agents myself to judge their promised usefulness.

So… surprise! Last weekend I decided to start a Claude Code subscription and, after spending a week on it, I am uncomfortably excited to use it more. How has this happened? Let’s take a look at how I ended here, the kinds of mini-projects I worked on throughout this past week, and the (semi-expected) downsides I encountered.

ssh-agent broken in tmux? I've got you!

julio@meroh.net (Julio Merino) — Fri, 26 Dec 2025 10:00:00 +0100

A little over two years ago, I wrote an article titled SSH agent forwarding and tmux done right. In it, I described how SSH agent forwarding works—a feature that lets a remote machine use the credentials stored in your local ssh-agent instance—and how using a console multiplexer like tmux or screen often breaks it.

In that article, I presented the ssh-agent-switcher: a program I put together in a few hours to fix this problem. In short, ssh-agent-switcher exposes an agent socket at a stable location (/tmp/ssh-agent.${USER?} by default) and proxies all incoming credential requests to the transient socket that the sshd server creates on a connection basis.

In this article, I want to formalize this project by presenting its first actual release, 1.0.0, and explain what has changed to warrant this release number. I put effort into creating this formal release because ssh-agent-switcher has organically gained more interest than I imagined as it is solving a real problem that various people have.

From Azure Functions to FreeBSD

julio@meroh.net (Julio Merino) — Sun, 07 Dec 2025 12:00:00 -0800

Putting FreeBSD’s “power to serve” motto to the test.

On Thanksgiving morning, I woke up to one of my web services being unavailable. All HTTP requests failed with a “503 Service unavailable” error. I logged into the console, saw a simplistic “Runtime version: Error” message, and was not able to diagnose the problem.

I did not spend a lot of time trying to figure the issue out and I didn’t even want to contact the support black hole. Because… there was something else hidden behind an innocent little yellow warning at the top of the dashboard:

Migrate your app to Flex Consumption as Linux Consumption will reach EOL on September 30 2028 and will no longer be supported.

I had known for a few weeks now, while trying to set up a new app, that all of my Azure Functions apps were on death row. The free plan I was using was going to be decommissioned and the alternatives I tried didn’t seem to support custom handlers written in Rust. I still had three years to deal with this, but hitting a showstopper error pushed me to take action.

All of my web services are now hosted by the FreeBSD server in my garage with just a few tweaks to their codebase. This is their migration story.

BazelCon 2025 recap

julio@meroh.net (Julio Merino) — Sun, 23 Nov 2025 17:00:00 -0800

It has been just over two years since I started Blog System/5, and that means it’s time for the now-usual(?) BazelCon 2025 trip report!

The conference, arranged by the Linux Foundation, took place in Atlanta, GA, USA over three days: one for tutorials and two for the main talks. An extra hackathon day, organized by Aspect Build, followed. Unfortunately, a canceled flight meant I missed the tutorials, but I attended the rest of the events. As usual, it was a super-fun time to connect with old acquaintances and an energizing event that left me with plenty of new topics to research.

You are holding BUILD files wrong

julio@meroh.net (Julio Merino) — Fri, 26 Sep 2025 09:00:00 -0700

I’ve heard it from people new to Bazel but also from people very familiar with the Bazel ecosystem: BUILD files must go away. And they must go away because they are redundant: they just repeat the dependency information that’s already encoded in the in-code import/use statements.

Hearing this from newcomers to Bazel isn’t surprising: after all, most newcomers are used to build tools that provide zero facilities to express dependencies across the sources of your own project. Hearing it from old-timers, however, is disappointing because it misses the point of what BUILD files can truly offer.

Bazel and glibc versions

julio@meroh.net (Julio Merino) — Fri, 19 Sep 2025 00:08:00 -0700

Imagine this scenario: your team uses Bazel for fast, distributed C++ builds. A developer builds a change on their workstation, all tests pass, and the change is merged. The CI system picks it up, gets a cache hit from the developer’s build, and produces a release artifact. Everything looks green. But when you deploy to production, the service crashes with a mysterious error: version 'GLIBC_2.28' not found. What went wrong?

Trusting builds with Bazel remote execution

julio@meroh.net (Julio Merino) — Fri, 12 Sep 2025 08:00:00 -0700

The previous article on Bazel remote caching concluded that using just a remote cache for Bazel builds was suboptimal due to limitations in what can and cannot be cached for security reasons. The reason behind the restrictions was that it is impossible to safely reuse a cache across users. Or is it?

In this article, we’ll see how leveraging remote execution in conjunction with a remote cache opens the door to safely sharing the cache across users. The reason is that remote execution provides a trusted execution environment for actions, and this opens the door to cross-user result sharing. Let’s see why and how.

Understanding Bazel remote caching

julio@meroh.net (Julio Merino) — Fri, 05 Sep 2025 08:30:00 -0700

The previous article on Bazel action non-determinism provided an introduction to actions: what they are, how they are defined, and how they act as the fundamental unit of execution in Bazel. What the article did not mention is that actions are also the fundamental unit of caching during execution to avoid doing already-done work.

In this second part of the series, I want to revisit the very basics of how Bazel runs actions and how remote caching (not remote execution, because that’ll come later) works. The goal here is to introduce the Action Cache (AC), the Content Addressable Storage (CAS), how they play together, and then have some fun in describing the many ways in which it’s possible to poison such a cache in an accidental or malicious manner.

Bazel and action (non-) determinism

julio@meroh.net (Julio Merino) — Mon, 21 Jul 2025 08:00:00 -0700

A key feature of Bazel is its ability to produce fast, reliable builds by caching the output of actions. This system, however, relies on a fundamental principle: build actions must be deterministic. For the most part, Bazel helps ensure that they are, but in the odd cases when they aren’t, builds can fail in subtle and frustrating ways, eroding trust in the build system.

This article is the first in a series on Bazel’s execution model. Having explained these concepts many times, I want to provide a detailed reference before explaining a cool solution to a problem I recently developed at work. We will start with action non-determinism, then cover remote caching and execution, and finally, explore the security implications of these features.

This first article explains what non-determinism is, how it manifests, and how you can diagnose and prevent it in your own builds. Let’s begin.

Lessons along the EndBOX journey

julio@meroh.net (Julio Merino) — Tue, 17 Jun 2025 09:00:00 -0700

About six months ago, during one of my long runs, I had a wild idea: what if I built an OS disk image that booted straight into EndBASIC, bundled it with a Raspberry Pi, a display, a custom 3D-printed case, and made a tiny, self-contained retro BASIC computer? Fast-forward to today and such an idea exists in the form of “the EndBOX prototype”!

This article isn’t the product announcement though—that’s elsewhere. What I want to do here is look back at the Blog System/5 articles I’ve written over the past months because what might have seemed like scattered topics were actually stepping stones toward the EndBOX.

Let’s look at what I learned along the way and why, even though developing EndBASIC may sound like a “useless waste of time”, it’s a great playground and the source of inspiration for the articles you’ve come to appreciate here.

Whatever happened to sandboxfs?

julio@meroh.net (Julio Merino) — Wed, 11 Jun 2025 10:00:00 -0400

Back in 2017–2020, while I was on the Blaze team at Google, I took on a 20% project that turned into a bit of an obsession: sandboxfs. Born out of my work supporting iOS development, it was my attempt to solve a persistent pain point that frustrated both internal teams and external users alike: Bazel’s poor sandboxing performance on macOS.

sandboxfs was a user-space file system designed to efficiently create virtual file hierarchies backed by real files—a faster alternative to the “symlink forests” that Bazel uses to prepare per-action sandboxes. The idea was simple: if we could lower sandbox creation overhead, we could make Bazel’s sandboxing actually usable on macOS.

Unfortunately, things didn’t play out as I dreamed. Today, sandboxfs is effectively abandoned, and macOS sandboxing performance remains an unsolved problem. In this post, I’ll walk you through why I built sandboxfs, what worked, what didn’t, and why—despite its failure—I still think the core idea holds promise.

Beginning 3D printing

julio@meroh.net (Julio Merino) — Wed, 28 May 2025 09:00:00 -0700

Hello readers and sorry for the 2-month radio silence. I’ve been pretty busy at work, traveling during school breaks, hacking on EndBASIC when time permitted, and… as of two weeks ago… tinkering with 3D printing as a complete beginner. So, today, I’d like to walk you through the latter because it has been a really fun and rewarding journey, albeit frustrating at times.

You’d think that to use a 3D printer, you’d design a 3D model and then… just… send it to the printer? That’s almost true, but it ignores the realities of producing a physical object from an “abstract” model: when designing such a model, you need to take into account the limitations of 3D printing and you need to translate your model into something the 3D printer can understand via a process called slicing.

Let’s take a brief peek at all of these steps. I’ll assume you are a complete beginner like I am. The pictures I’ll show are all for a “first project” I did to remake the bars of a bird cage I have, as the birds had fully destroyed the previous ones.

The next generation of Bazel builds

julio@meroh.net (Julio Merino) — Mon, 24 Mar 2025 08:00:00 -0700

Today marks the 10th anniversary of Bazel’s public announcement so this is the perfect moment to reflect on what the next generation of build systems in the Bazel ecosystem may look like.

I write this with the inspiration that comes from attending the first ever conference on Buildbarn, one of the many remote execution systems for Bazel. In the conference, Ed Schouten, the creator of Buildbarn, presented Bonanza: a skunkworks reimagination of Bazel for truly large builds.