Erik Kaunimaki

How to Build an ML Framework in Rust, from Scratch, in a Weekend

Fri, 06 Mar 2026 00:00:00 GMT

ZML is an ML framework written in Zig, and it's the only ML framework that fully focuses on inference. But how does it work, and what does it mean to focus on inference rather than training?

I wanted to understand the stack properly, so I built a minimal version of ZML in Rust. This post is a guided tour of what sits underneath, and how you can build your own ML framework to run a real model.

I'll start this blog by going through how ZML works under the hood and explaining the end-to-end pipeline from model definition to StableHLO to PJRT. Once we have a solid understanding of what it should look like, we'll build a toy/educational ML framework. The first version will be ugly, and the last part of this blog is devoted to cleaning it up.

What we'll cover:

Part 1: Reading — how ZML works under the hood
Part 2: Building — building a toy framework that emits StableHLO
Part 3: Running — compiling and executing via PJRT
Part 4: Cleaning — making the API feel like a real framework
Demo — running SmolLM2-135M end to end

The outcome of this blog is that we'll build a toy/educational ML framework that will run the SmolLM2-135M model, something like this:

❯ ./target/release/examples/smollm2 chat                                                       
No compiled artifact given, compiling from scratch (seq=256)...
Compiled in 728.99ms
Loaded weights in 91.99ms

SmolLM2-135M-Instruct ready. Type a message and press Enter. Type "exit" to quit.

You> Hi 👋
Assistant> Hello! I'm here to help with any creative writing needs. What's on your mind?
[24 prompt tokens, 19 generated | TTFT 306ms | 4.5 tok/s]

I assume you're comfortable with programming and have a basic understanding of neural networks: you know what a forward pass, a matmul, and a weight tensor are. You don't need to be an expert, but I'll cut to the chase pretty quickly.

Short intro to ZML

ZML is an ML framework for inference, written in Zig. It sits at roughly the same level as PyTorch, but it is optimized for inference only. That constraint shapes many of its design decisions and makes it feel quite different from PyTorch.

To understand what ZML is trying to solve, it helps to look at where PyTorch is less natural as an inference runtime. PyTorch defaults to eager execution: ops run immediately as your Python code executes them. That is excellent for model development and experimentation, where flexibility matters most. But for production inference, you often end up introducing a second stage such as export, tracing, or compilation, and that handoff is where edge cases and operational complexity tend to appear.

Inference has a different nature: the goal is not to support an interactive research workflow, but to produce a stable, reusable artifact that runs predictably in production. This is why ZML is built around a graph-compile-run pipeline: you first stage the computation as a graph, then compile that graph into an accelerator-specific executable, and finally run that executable with real inputs. In other words, the model definition is treated less like code to execute line by line, and more like a specification that can be analyzed, optimized, and compiled ahead of time.

That model fits inference well, where we usually care more about predictability, startup behavior, hardware targeting, and repeatable performance than maximum flexibility at runtime.

If you’re coming from a PyTorch world, three things stand out in ZML:

Graph-first: the model is staged as a computation graph up front, rather than executed eagerly op by op.
Model and weights are separate: you can validate and compile the model structure without loading the actual weights. When weights are tens of gigabytes, that makes iteration much faster.
Compiled for the target: ZML is designed to compile the model into an executable for a specific backend and deployment target, which makes it feel much closer to a serving stack than a research environment.

As someone who has worked on inference for several years, this resonated with me immediately. If you’re curious how a stack like this can even be built, follow along: we’ll start with a high-level overview of ZML, then build out the core pieces ourselves.

Part 1: Reading

The stack

There's a big stack involved here, and it's not immediately obvious what does what. But nothing here is difficult per se; there's just a lot of it.

The short version is:

Write the model in Zig, lower it to StableHLO (an MLIR dialect), then let OpenXLA compile and run it through PJRT.

Before we unpack each layer, here's the short explanation of each piece:

StableHLO is an IR (intermediate representation) that describes ML computations. It’s a dialect of MLIR, so in many places, including this blog, they’re used interchangeably.
PJRT is the runtime API that compiles and executes those computations on actual hardware.
OpenXLA is the umbrella project that ties them together.

The top of the stack is the easiest to understand, since it feels very similar to PyTorch. You write your model in Zig as a struct:

const Scale = struct {
    weight: zml.Tensor,

    pub fn forward(self: Scale, x: zml.Tensor) zml.Tensor {
        return self.weight.mul(x);
    }
};

The struct has a weight tensor and a forward method that does an elementwise multiply. You'd use it like:

const x = zml.Tensor.init(.{1, 4}, .f32);
const y = scale.forward(x);

This is somewhat pseudo-code, but you get the idea.

The core part to understand here is that there's no data attached to this yet. The data in the weight tensor isn't here, and it doesn't need to be. In ZML, a tensor is just some shape metadata plus an MLIR value that identifies the operation that produced it.

"What the hell is an MLIR value?" Fair question. It's tempting to first think of it as a pointer to data in memory. But it's not that, since there's no data to point to. Think of it as a name for a result. It's what's called a single static assignment (SSA) value: each operation in the computation graph produces one or more results, and each result gets a unique SSA name (like %0, %4). The operation itself is the node in the graph; the SSA value is the handle you use to refer to its output. In essence, it tells you where a tensor came from and how it flows through the computation, but it doesn't hold actual numeric data.

Let's visualize our multiplication. Both the weight and the input tensor x are tensors, so they get assigned an SSA value: %0 and %1. In the forward pass, the two values are multiplied, producing a new tensor with the id %2. So the new tensor with the id %2 is just the result of multiplying %0 and %1.

If the MLIR value doesn't fully click yet, don't worry, it will become clearer as we go deeper and start building things ourselves.

What's MLIR really? MLIR (Multi-Level Intermediate Representation) is a compiler infrastructure for building IRs. It provides the core machinery like types, operations, optimization passes, and lets you define "dialects" on top of it. StableHLO is one such dialect. When you see "MLIR" in the ZML context, it usually means "the framework that StableHLO is built on," not a separate layer.

StableHLO

One layer under the ZML graph, we have StableHLO (HLO standing for High-Level Operations). StableHLO is an intermediate representation for ML computations. It's an MLIR dialect, which is why "StableHLO" and "MLIR" are sometimes used interchangeably. The common confusion is to think StableHLO is MLIR, when really StableHLO is a vocabulary of operations defined within the MLIR framework.

The core value proposition is that StableHLO defines a standard, portable set of operations, like stablehlo.add, stablehlo.dot_general, stablehlo.broadcast_in_dim, etc. Plenty of frameworks already use StableHLO, like JAX. There's even a PyTorch XLA backend that works similarly. So what ZML is doing isn't entirely new; the difference is that ZML makes this the default and only path.

The StableHLO of our elementwise multiplication would look something like this:

module {
  func.func @main(%0: tensor<1x4xf32>, %1: tensor<1x4xf32>) -> tensor<1x4xf32> {
    %2 = stablehlo.multiply %0, %1 : tensor<1x4xf32>
    return %2 : tensor<1x4xf32>
  }
}

Not the nicest thing to read, but still pretty understandable. tensor<1x4xf32> is a 1x4 tensor of 32-bit floats, assigned to SSA value %0. This would be our weights. And the other 1x4 tensor with id %1 is x. The tensor with the id %2 is whatever comes out of the instruction stablehlo.multiply, where %0 and %1 are arguments to that function. And we can infer that %2 has the shape 1x4 as well.

We're building up a compute graph of the entire thing, all without actual data. As long as we know the shapes, this works.

Caveat StableHLO does actually support dynamic shapes, e.g., an unknown batch size `tensor`, but this is exactly what we'd like to avoid in order to compile ahead of time. ZML doesn't support it either and we'll skip it for our educational ML framework as well.

You might have noticed that our ZML code didn't specify any shapes for the weight tensor. Only x was defined as zml.Tensor.init(.{1, 4}, .f32);. So how did it become 1x4 in this case? We'll address this later when we build our own framework, but to peek into the future a bit: ZML (and our future framework) actually looks at the header of a .safetensor file to determine the final shapes of the weight tensor. All .safetensor files have a JSON part at the start of the file containing each tensor's name, dtype, shape, and byte offsets, all before the actual data blob. Our struct tells us what tensors our model consists of, and we map this to a .safetensor file which then tells us the final exact shape of everything.

This means that our modelling code is more flexible: the same model definition works for a 7B and 13B model. But we can still trace and compile the entire graph by just reading a few kilobytes of data, without loading the model weights.

PJRT

The last missing piece is how this actually gets executed on a machine. StableHLO is just an IR, it can't run by itself. The missing piece is PJRT. PJRT is honestly a big beast to tackle, and I've just scratched the surface, but the key part to understand is that PJRT defines a compilation entry point and different plugins (for GPU, CPU, TPU, etc.) do the heavy lifting.

In simple terms: we hand the StableHLO text to PJRT, and if we target CPU, the plugin goes through LLVM and produces native machine code. This is how our ZML defined multiply becomes something that actually runs on a computer.

Part 2: Building

In this part we'll build a small ML framework that lets us:

Build a high-level graph describing some computation
Turn that graph into valid StableHLO
Hand that StableHLO to PJRT and execute the graph on CPU

To keep the scope small, we'll focus only on a simple y = x·w + b layer. First we'll build the graph and emit StableHLO. The API will be ugly and nothing like PyTorch or ZML. Then we'll wire up PJRT to actually execute it. In Part 4 of the blog, we'll clean up the API to something that feels more like a real framework.

If we jumped straight to the nice API, we'd miss the learning. There's a fair amount of quality-of-life work that frameworks like PyTorch and ZML do that, while satisfying to build, can obscure the underlying concepts.

All the code is available at github.com/ErikKaum/fusebox.

Building tensors

I'm calling this library fusebox: "box" because it's small, "fuse" because there's still some fire in it.

We'll start with four small modules. These are simple, but having good intuition around them matters:

src/dtype.rs: just F32 for now, with a method to print the MLIR string ("f32")
src/shape.rs: Shape { dims: Vec<i64>, dtype: DType } dimensions plus dtype, with a method to produce the MLIR tensor type string (e.g. tensor<2x4xf32>)
src/value.rs: ValueId(u32) the SSA id in the graph. Instead of storing it as a string like %5 everywhere, we store the integer and only render it when printing
src/tensor.rs: Tensor { shape: Shape, value: ValueId } the core building block that combines all of the above

The tensor is essentially a symbolic handle. When you do something like matmul(x, w), the builder (which we'll build next) will:

allocate a fresh ValueId
append an instruction saying "this new value id is the result of DotGeneral(lhs=x.value, rhs=w.value, ...)"
and return a new Tensor pointing at that id

Which is exactly the same process that we had previously, in the elementwise multiplication example. No data, just a reference to a result in the computation graph.

I won't go through exactly all of the code since it would be way too verbose, but I'll show code examples with the aim that it'll improve your intuition around this.

To reiterate: a tensor has a shape, in this case 1x4, a datatype, and the SSA Value attached to it. This is how our high-level Rust struct maps very directly to StableHLO.

A tensor t like this:

let t = Tensor {
    shape: Shape {
        dims: vec![1, 4],
        dtype: DType::F32,   // → "f32"
    },
    value: ValueId(3),       // → "%3" in the StableHLO output
};

Would be represented like this in StableHLO:

%3 : tensor<1x4xf32>
 ^         ^  ^ ^
 |         |  | └── DType::F32
 |         dims: [1, 4]
 ValueId(3)

Building graphs

Now we're ready to start connecting tensors together into a graph.

First, we'll make our own intermediate representation (IR) in Rust, which then gets converted into StableHLO. "Another IR?!", I hear you say. Bear with me. ZML, for example, doesn't have its own IR; its tensors get directly converted into StableHLO, and that's probably what you'd do for a real framework. But for learning purposes, having a thin Rust representation of the graph before converting it to StableHLO lets us separate the logic of building the graph from the concerns of StableHLO syntax. And I really don't want to write a blog about StableHLO syntax.

So we'll have three new modules:

src/ir.rs: defines functions, parameters, and instructions
src/print_mlir.rs: takes our internal IR and prints it as StableHLO
src/builder.rs: defines a FuncBuilder that ties tensors together into a graph

Let's walk through this carefully, since there's a handful of moving parts here.

At the top level we have a module, which contains a list of functions. Think of a module as the entry point, in our case, the top-level forward of a neural network.

A function has three parts:

Parameters — the inputs to the function, each with an SSA value
Instructions — the operations inside the function, each producing an SSA value
A return value — an SSA value that becomes the output

To give an overview, these are the main structs & enums we're working with:

pub struct Module {
    pub functions: Vec<Function>,
}

pub struct Function {
    pub name: String,
    pub params: Vec<Param>,
    pub insts: Vec<Stmt>,
    pub ret: Option<ValueId>,
}

pub struct Param {
    pub name: String,
    pub shape: Shape,
    pub value: ValueId,
}

pub struct Stmt {
    pub result: ValueId,
    pub inst: Inst,
}

pub enum Inst {
    DotGeneral(DotGeneral),
    BroadcastInDim(BroadcastInDim),
    Add(Add),
}

So each Inst variant (like DotGeneral, Add and BroadcastInDim) carries the ValueIds of its inputs plus the output shape. If we look closer at the Add instruction:

#[derive(Debug, Clone)]
pub struct Add {
    pub lhs: ValueId,
    pub rhs: ValueId,
    pub out: Shape,
}

And let's say our left-hand side has the value id 0 and the rhs has id 1. Then we could look at the shape and dtype of tensors 0 and 1 respectively, and produce the following StableHLO:

"stablehlo.add"(%0, %1) : (tensor<1x4xf32>, tensor<1x4xf32>) -> tensor<1x4xf32>

This is how we essentially keep a mapping of each StableHLO instruction, and have a corresponding Rust struct for each one of them. Later we'll also see how we explicitly set the output shape and dtype.

If this doesn't fully make sense yet, I'd encourage reading it once more. Having a solid understanding of the IR made everything else click for me.

The full IR definitions are in the repo; they're straightforward once you see the pattern.

Building builders

Now the builder. We'll create a struct called the FuncBuilder. Each instruction we defined in the IR gets a corresponding method on the FuncBuilder: builder.add(...), builder.dot_general(...), builder.broadcast_in_dim(...), and so on.

But before those, let's look at the fresh() method. This will be the function that gives fresh ValueIds, and essentially the way we do bookkeeping of the ids. It's pretty simple, just incrementing a counter. But note that this also makes the FuncBuilder stateful. If we change the order from add(x, y) to add(y, x), the result is the same since addition is commutative, and the result tensor gets the same ValueId either way. But x and y themselves will get swapped ValueIds, whichever is added to the graph first gets the lower id. That means ValueIds aren't a stable way to reference a tensor: the same logical tensor can end up with different ids depending on construction order. It's fine for now, but this will come up later as a real issue when we want to produce a stable ABI on top of ValueIds.

pub struct FuncBuilder {
    func: Function,
    next_id: u32,
}

impl FuncBuilder {
    
    fn fresh(&mut self) -> ValueId {
        let id = self.next_id;
        self.next_id += 1;
        ValueId(id)
    } 
    
    pub fn matmul_2d(&mut self, x: &Tensor, w: &Tensor) -> Result<Tensor, Error> {
        ...
    }

    pub fn broadcast_bias_1d(&mut self, b: &Tensor, batch: i64) -> Result<Tensor, Error> {
        ...
    }

If we dive deeper in how the add() is actually implemented, we'll find that most of the ceremony is validating shapes and dtypes. Which I've omitted in this blog. But the core pattern is always the same:

pub fn add(&mut self, a: &Tensor, b: &Tensor) -> Result<Tensor, Error> {
    // ... shape/dtype validation ...

    let out_shape = a.shape.clone(); // how we manually determine output shapes
    let result = self.fresh();  // allocate a new ValueId (just a counter)

    self.func.insts.push(Stmt {
        result,
        inst: Inst::Add(Add {
            lhs: a.value,
            rhs: b.value,
            out: out_shape.clone(),
        }),
    });

    Ok(Tensor::new(out_shape, result))
}

We call self.fresh(), which gives us a new id. Then we create a new statement: this value id is the result of the add instruction on the two inputs. We append it to the function's instruction list and return a new Tensor pointing at the result.

The matmul_2d and broadcast_bias_1d methods follow the exact same pattern: validate shapes, allocate a fresh ValueId, push a statement, return a new Tensor. To keep things simple, I've kept the methods specific to a certain dimension, so matmul_2d instead of just matmul, we'll relax this later. Here you'll find the full builder code.

If this doesn't 100% click yet, this example should help. Here's the full y = x·w + b layer built with the current API of our framework:

let mut f = FuncBuilder::new("main");

let x = f.param("x", Shape::new(vec![2, 4], DType::F32));   // -> %0
let w = f.param("w", Shape::new(vec![4, 3], DType::F32));   // -> %1
let b = f.param("b", Shape::new(vec![3], DType::F32));      // -> %2

let y = f.matmul_2d(&x, &w)?;                               // -> %3
let bb = f.broadcast_bias_1d(&b, 2)?;                       // -> %4
let out = f.add(&y, &bb)?;                                  // -> %5

f.ret(&out);

let func = f.finish();
let module = Module { functions: vec![func] };
println!("{}", print_module(&module));

We instantiate the FuncBuilder, add three parameters (x, w, b), chain a matmul, a broadcast, and an add, set the return, and finish. Essentially the same thing as in this graph:

Each f.param() call does two things:

it allocates the next ValueId to each tensor; this is how x becomes %0
it registers the tensor as a function input

So our three params become the function signature @main(%0: ..., %1: ..., %2: ...), while the intermediate tensors (%3, %4) are produced by operations in the function body. The final result %5 is what gets returned. Once we print it, we get StableHLO (truncated for readability):

module { 
    func.func @main(%0: tensor<2x4xf32>, %1: tensor<4x3xf32>, %2: tensor<3xf32>) -> tensor<2x3xf32> {
        %3 = stablehlo.dot_general ...
        %4 = stablehlo.broadcast_in_dim ...
        %5 = stablehlo.add %3, %4 : tensor<2x3xf32>
        return %5 : tensor<2x3xf32> 
    } 
}

We can save this text as a .mlir file and use a tool from the StableHLO repo to verify that the output is valid. Running stablehlo-opt forward.mlir will catch any syntax or type errors.

So far we've:

Created a high-level way of representing tensors with shapes and dtypes
Built a small IR that can represent basic StableHLO operations
Tied them together with a function builder that creates a computation graph
Printed the graph as StableHLO

If you think the API feels weird compared to PyTorch or ZML, you're not alone. We're calling methods on a builder rather than doing tensor.add(). In Part 4 we'll clean this up and start building layers on top of the FuncBuilder, which will make the API feel more like a modern ML framework.

But this actually works! It produces real StableHLO, which means that we can move to the next part of the pipeline: compile it with PJRT and actually run it.

Part 3: Running

We're finally getting close to producing something. After all this plumbing, we've reached the step of actually executing a computation graph. If you've felt so far that we're not doing much ("it's just a StableHLO wrapper, right?"), you'll start to feel it now.

In plain terms, we now have a program that produces StableHLO (basically a text file). We'll hand this text file to another program, wire up the correct inputs, compile it, and run it. To really drive home the "two programs" point, I first wrote this runner in Go. There's no need for the graph-builder and the runner to be in the same language, and using a different one makes the separation palpable.

Quick and dirty in Go

We'll use a Go package called go-xla. The painful part of working with PJRT directly is keeping track of plugin versions (which you don't have to do in ZML); go-xla handles this with an installer.AutoInstall() function that auto-downloads the correct precompiled PJRT plugin for your platform.

The flow has essentially these three steps: 1) read the MLIR file, 2) compile it, and 3) execute it with input buffers.

func main() {
    // 1. Auto-download PJRT plugin
    installer.AutoInstall("", true, installer.Normal)

    // 2. Read StableHLO and compile it
    mlirBytes, _ := os.ReadFile("forward.mlir")
    plugin, _ := pjrt.GetPlugin("cpu")
    client, _ := plugin.NewClient(nil)
    exec, _ := client.Compile().WithStableHLO(mlirBytes).Done()

    // 3. Create input buffers with REAL DATA and execute
    x := []float32{1, 2, 3, 4, 5, 6, 7, 8}
    w := []float32{1, 0, 0, 0, 1, 0, 0, 0, 1, 1, 1, 1}
    b := []float32{10, 20, 30}

    bx, _ := pjrt.ArrayToBuffer(client, x, 2, 4)
    bw, _ := pjrt.ArrayToBuffer(client, w, 4, 3)
    bb, _ := pjrt.ArrayToBuffer(client, b, 3)

    outs, _ := exec.Execute(bx, bw, bb).Done()
    outFlat, outDims, _ := pjrt.BufferToArray[float32](outs[0])

    fmt.Printf("output dims=%v\n", outDims)
    fmt.Printf("output flat=%v\n", outFlat)
}

Note the key moment: only now, at ArrayToBuffer, do we pass real data. Everything before this was purely symbolic. The full Go code with proper error handling is in the fusebox repo.

And once you run this with go run main.go, you'll get:

output dims=[2 3]
output flat=[15 26 37 23 34 45]

If you've come this far, you should congratulate yourself. You've understood the entire pipeline from start to finish. Everything from here onwards enhances and polishes this pipeline, but conceptually we won't change anything fundamental. This is it. But don't be fooled, there's still tons of work to do before we can call this a toy ML framework.

Moving the runner to Rust

The obvious shortcoming is that we can't handwrite input arrays in Go for every StableHLO program. As a silly solution, we could create a JSON file that would describe the inputs with shapes and dtypes. We'd have to generate this in the Rust code, and hand it over to the Go runner. Something like this:

{
  "entry": "main",
  "inputs": [
    {"name": "x", "dtype": "f32", "shape": [2,4]},
    {"name": "w", "dtype": "f32", "shape": [4,3]},
    {"name": "b", "dtype": "f32", "shape": [3]}
  ],
  "outputs": [
    {"dtype": "f32", "shape": [2,3]}
  ]
}

But wouldn't it be nice if the runner could infer the shapes and dtypes from the builder's params. Rather than having to type out things twice: once for building the graph and a second time for passing real data to the graph.

We'll do this, but not quite yet. First we need to have a runner in Rust. We'll use the pjrt crate, which doesn't have an autoinstaller like go-xla. Fortunately, ZML maintains a pre-compiled repo of the PJRT plugins. It took some trial and error to find which plugin version corresponds to the Rust bindings. Version 0.2.2 at least seems to match. Again, you don't have to think about this with ZML.

When moving the runner to Rust, we have an API that looks like this. We still set up host buffers manually:

fn main() -> Result<(), String> {
    let mlir = build_your_stablehlo_mlir_string();

    let runner = PjrtCpuRunner::from_mlir_text(&mlir, default_cpu_plugin_path())?;

    let x = HostTensorF32::new(vec![2, 4], vec![1.,2.,3.,4.,  5.,6.,7.,8.])?;
    let w = HostTensorF32::new(vec![4, 3], vec![1.,2.,3., 4.,5.,6., 7.,8.,9., 10.,11.,12.])?;
    let b = HostTensorF32::new(vec![3], vec![1., 2., 3.])?;

    let y = runner.run_f32(vec![x, w, b])?;
    println!("output dims={:?}", y.dims);
    println!("output flat={:?}", y.data);

    Ok(())
}

Link to the full code.

At this point we have a complete pipeline entirely in Rust: define the graph, emit StableHLO, compile via PJRT, execute, and get results back. The API is rough, but it works.

The next part is about making it feel like a real framework.

Part 4: Cleaning

So far we've built a framework that takes high-level tensors, builds a computation graph in StableHLO, compiles it via PJRT, and executes it on CPU. It works, but the API leaves a lot to be desired. We've been optimizing for learning instead of ergonomics, and now it's time to make this feel like a real framework.

If you've made it this far, you already have a solid understanding of the stack that ZML builds upon: which is the main goal of this blog. Feel free to call it a day. But if you're curious about the long tail of details that make a framework usable rather than just correct, read on. Nothing here changes the fundamentals, but these are the edges that separate a StableHLO wrapper from something you'd actually want to use.

From graph plumbing to model code

The FuncBuilder approach felt like building "from the outside." We pushed parameters into a builder, called graph-building helpers, and printed a StableHLO function. This was great for learning, but the code that describes a model doesn't look like a model: it looks like graph plumbing.

The shift we want to make is to go from manually constructing a graph to automatically tracing a forward pass. Enter the TraceCx (tracing context). You write a forward pass once, and it runs in a mode where tensor operations don't compute; instead, they're recorded. Similar to what's done in ZML and JAX.

pub struct TraceCx {
    builder: Rc<RefCell<FuncBuilder>>,
    prefix: String,
}

The TraceCx wraps our FuncBuilder and adds two key things:

hierarchical name scoping (the prefix)
a distinction between input parameters and weight parameters

We'll see why both of these matter shortly.

With TraceCx, a linear layer becomes a struct with a forward method. This looks a lot more like the modelling code we're familiar with from PyTorch. The big difference is that we're still manually writing the trace_init() method.

pub struct Linear {
    pub w: Tensor,
    pub b: Option<Tensor>,
}

impl Linear {
    pub fn trace_init(cx: &mut TraceCx, name: &str, in_dim: i64, out_dim: i64, bias: bool) -> Self {
        let _s = cx.push_scope(name);
        let w = cx.weight("w", Shape::new(vec![in_dim, out_dim], DType::F32));
        let b = if bias {
            Some(cx.weight("b", Shape::new(vec![out_dim], DType::F32)))
        } else {
            None
        };
        cx.pop_scope(_s);
        Self { w, b }
    }

    pub fn forward(&self, cx: &mut TraceCx, x: &Tensor) -> Result<Tensor, Error> {
        let y = cx.matmul_2d(x, &self.w)?;
        if let Some(b) = &self.b {
            let batch = x.shape.dim(0);
            let bb = cx.broadcast_bias_1d(b, batch)?;
            cx.add(&y, &bb)
        } else {
            Ok(y)
        }
    }
}

You'd use it like this:

let mut cx = TraceCx::new("main");

let x = cx.input("x", Shape::new(vec![2, 4], DType::F32));
let proj = Linear::trace_init(&mut cx, "proj", 4, 3, true);
let y = proj.forward(&mut cx, &x)?;

cx.set_ret(&y);
let func = cx.finish();

In practice, TraceCx is a nicer facade over the same essentials the builder had: it owns the function-under-construction, hands out ValueIds, provides ops, and produces StableHLO. The important shift is where the model logic lives. A module is a struct with weight fields; forward is a method that composes ops; tracing works by calling forward once with symbolic tensors.

That might just look like semantic changes, but it's the first step from "graph construction code" into "model code." And later, we can extract this pattern into a proc-macro, which is really when it starts to feel like magic.

Signatures: the bridge to PJRT

Now that we've cleaned up how the graph gets constructed by having a TraceCx, let's look at the next step.

Remember, the last line from the previous example:

let func = cx.finish();

func holds the StableHLO text that we want to pass to the PJRT runtime.

But we're still manually creating HostTensorF32 values that match the graph. Let's fix that. Instead, we want the TraceCx to produce a structured signature that the runtime can use directly.

pub struct ParamSpec {
    pub name: String,
    pub shape: Shape,
    pub value: ValueId,
    pub kind: ParamKind,
}

pub struct Signature {
    params: Vec<ParamSpec>,
    by_name: HashMap<String, usize>,
}

The Signature is extracted from the traced parameters: name, shape, dtype, and whether it's an input or a weight. It becomes the single source of truth for runtime binding. The runner can validate inputs, pack them in the correct argument order, and later separate which parameters are the model weights (which need to be bound once) from which parameters are the inputs (bound per request).

let runner = PjrtCpuRunner::from_function(&func, default_cpu_plugin_path())?;

let mut ins = runner.inputs();
ins.set("x", vec![1., 2., 3., 4., 5., 6., 7., 8.])?;
ins.set("proj/w", vec![1., 0., 0., 0., 1., 0., 0., 0., 1., 1., 1., 1.])?;
ins.set("proj/b", vec![10., 20., 30.])?;

let y = runner.run(ins)?;

Concretely, what happens is that we pass the &func into the PjrtCpuRunner::from_function(...) and then set the vectors as the runner inputs through ins = runner.inputs() and ins.set(). This is an improvement, but we're still not reading proj/w and proj/b from a safetensor file. And the inputs x are still bound to the runner the same way as the weights. But we're getting there.

Notice the scoped names: "proj/w" and "proj/b" came from the cx.push_scope("proj") call in trace_init(). We're starting to see the real difference between the TraceCx and the old FuncBuilder: the tracer produces an ABI, not just a graph.

Stable names and param kinds

Now that the tracer produces an ABI, we need to be more careful about naming. Remember the ValueId instability we discussed in Part 2? The SSA value id is not a stable identifier: add a new layer and all the indices shift. For an ABI, we need names that come from the model structure and match the checkpoint.

What we already saw earlier with the proj suffix, is the result of the push_scope/pop_scope mechanism, which gives us hierarchical names: a Linear inside an MLP named "proj" gets weights named "proj/w" and "proj/b". These names are stable. They don't change when you reorder operations, and they naturally match the naming conventions in safetensors weight files.

The practical approach is to align the naming of the struct fields (tensors) with the weight file. Meaning that the ultimate goal is that we can directly align the weights in a safetensor file to the tensors in our model. In a later section I'll add a rename macro #[module(name = "new_name")], for inevitable mismatches. Which is another one of these quality-of-life things you'd want in a real ML framework. But for now, we assume that the names are the same in the safetensor files as in the struct fields.

The other important distinction is ParamKind:

pub enum ParamKind {
    Input,
    Weight,
}

From the graph's point of view, all parameters are the same, just nodes. But from a model's point of view, there's a clear difference. Inputs are a runtime contract, they change per request. Weights are a checkpoint contract, loaded once. This separation matters because in a real serving system, the hot path is request execution. You bind weights once at startup and rebind inputs per request.

With this change we can avoid doing everything through the ins.set() which we did above.

Where do weight shapes come from?

Tracing requires knowing exact tensor shapes, and so far we've supplied those shapes manually, like:

let proj = Linear::trace_init(&mut cx, "proj", 4, 3, true);

where 4 and 3 become the in and out dimensions.

let w = cx.weight("w", Shape::new(vec![in_dim, out_dim], DType::F32));

Obviously, this is not the way.

ZML's answer: read the shapes from the checkpoint file's metadata, compile the graph from shapes alone, and load the actual weight data separately (or in parallel). Importantly, we can compile the graph from just the shapes and dtypes, we don't need to load the entire safetensor file into memory for this.

Safetensors makes this convenient because its file header contains tensor names, dtypes, and shapes as JSON, before any of the actual data. You can read a few kilobytes of metadata from a multi-gigabyte file and know everything you need to compile. In fusebox, this became a ShapeProvider trait:

pub trait ShapeProvider {
    fn shape_of(&self, full_name: &str) -> Result<Option<Shape>, Error>;
}

And a SafeTensorShapes implementation that reads just the header. The model initialization step stops taking explicit (in_dim, out_dim) arguments and starts taking a shape provider.

Ops on tensors

Next, the biggest API change. So far all operations are done on the TraceCx, like:

let y = cx.matmul_2d(x, &self.w)?;

While this is fine, I just don't like it. I want to be able to do something closer to x.matmul_2d(&self.w). The change is that instead of passing &mut TraceCx through every forward method, tensors themselves carry a reference to the computation graph:

pub struct Tensor {
    pub shape: Shape,
    pub value: ValueId,
    pub(crate) graph: Rc<RefCell<FuncBuilder>>,
}

The graph reference is shared via Rc<RefCell<...>>. When you do &a + &b, the Add impl borrows the graph, appends the instruction, and returns a new Tensor pointing at the result. All operations become methods on Tensor, and operator overloads (+, -, *, /) work for all combinations of owned and borrowed tensors.

The TraceCx is now only used for declaring inputs and weights. All ops live on Tensor. Compare the before and after of Linear::forward:

Before:

fn forward(&self, cx: &mut TraceCx, x: &Tensor) -> Result<Tensor, Error> {
    let y = cx.matmul_2d(x, &self.w)?;
    if let Some(b) = &self.b {
        let batch = x.shape.dim(0);
        let bb = cx.broadcast_bias_1d(b, batch)?;
        cx.add(&y, &bb)
    } else {
        Ok(y)
    }
}

After:

pub fn forward(&self, x: &Tensor) -> Result<Tensor, Error> {
    let wt = self.weight.transpose(&[1, 0])?;
    let y = x.matmul(&wt)?;
    match &self.bias {
        Some(b) => y.add(b),
        None => Ok(y),
    }
}

No more cx parameter. Also I changed the add to handle broadcasting automatically, so that removes broadcast_bias_1d. Now this starts to feel like PyTorch.

Macros: removing the last boilerplate

Tracing works, ops are clean, but there's still boilerplate: the trace_init() method. For every module, you write "allocate w, maybe allocate b" with string names that must match checkpoint keys. We want code generation to handle this. The tracing should happen automatically, and tensor names should be aligned to struct field names.

I've never written a Rust proc-macro before, and that's still largely true; in this case I just let Opus 4.6 handle it. Learning Rust proc-macros would have been too much of a side quest.

Anyway. Before, every module had to manually implement this:

impl Linear {
    pub fn trace_init(cx: &mut TraceCx, name: &str, shapes: &dyn ShapeProvider) -> Result<Self, Error> {
        let _s = cx.push_scope(name);
        let w = cx.weight("weight", shapes.shape_of(cx.qualify("weight"))?.unwrap());
        let b = match shapes.shape_of(cx.qualify("bias"))? {
            Some(s) => Some(cx.weight("bias", s)),
            None => None,
        };
        cx.pop_scope(_s);
        Ok(Self { w, b })
    }
}

After, we just add the derive module macro, and our trace_init() method gets automatically generated:

#[derive(Module)]
pub struct Linear {
    pub weight: Tensor,
    pub bias: Option<Tensor>,
}

In more detail, the #[derive(Module)] macro generates a trace (yes I changed the name) method by inspecting struct fields:

Tensor fields become required weights, looked up via shapes.shape_of()
Option<Tensor> fields become optional weights, None if absent from the checkpoint
Any other type implementing Module becomes a nested submodule, basically recursive trace in a scoped name
Vec<T> where T: Module auto-discovers layer count by probing the checkpoint for "0/", "1/", etc.

I added two attributes that handle quality-of-life edge cases:

#[module(name = "gate_proj")] renames the checkpoint key, because checkpoints rarely 100% match the preferred Rust field names
#[module(skip)] ignores config fields like out_dim: i64 that aren't submodules

The macro doesn't touch forward, that stays ordinary Rust. It only automates the tedious part of tracing the graph and matching it with a checkpoint.

The final API

The last step is wrapping the lifecycle into clean types:

Device: wraps a PJRT plugin path. Entry point for compile() and load()
Checkpoint: loads a safetensors file once. Exposes both shapes (for tracing) and weight data (for binding)
CompiledModel: a compiled PJRT executable plus its signature. Can be saved to and loaded from disk
Session: a compiled model with pre-bound weights. The thing you call run on

Here's a small example, a gated MLP loaded from a safetensors checkpoint:

use fusebox::prelude::*;

#[derive(Module)]
pub struct Mlp {
    pub up: Linear,
    #[module(name = "gate_proj")]
    pub gate: Linear,
    pub down: Linear,
}

impl Mlp {
    pub fn forward(&self, x: &Tensor) -> Result<Tensor, Error> {
        let gate = self.gate.forward(x)?;
        let gate = gate.silu();
        let up = self.up.forward(x)?;
        let hidden = (&gate * &up)?;
        self.down.forward(&hidden)
    }
}

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let ckpt = Checkpoint::from_file("model.safetensors")?;
    let device = Device::cpu();

    let runner = device.compile("main", |cx| {
        let x = cx.input("x", Shape::new(vec![1, 8], DType::F32));
        let mlp = Mlp::trace(cx, "proj", ckpt.shapes())?;
        mlp.forward(&x)
    })?;

    let weights = ckpt.load_weights(runner.signature())?;
    let sess = runner.session(weights);

    let y = sess.run(|inputs| inputs.set_input("x", vec![1., 2., 3., 4., 5., 6., 7., 8.]))?;

    println!("shape: {:?}", y.shape());
    println!("data: {:?}", y.to_f32().unwrap());
    Ok(())
}

Every piece we built across Parts 2-4 is here, but hidden behind a clean API. Checkpoint::from_file() reads the safetensors header for shapes. device.compile() traces the closure, emits StableHLO, and compiles via PJRT. All from shapes alone, no weight data loaded yet. ckpt.load_weights() validates that weight names match the traced signature and extracts the data. runner.session(weights) binds weights once. And sess.run binds only the runtime inputs per request.

This is similar to the pipeline ZML uses: shapes define types → tracing defines programs → StableHLO is the portable representation → PJRT compiles and runs → good APIs fall out of separating compile time from runtime.

It's worth stepping back and acknowledging what fusebox doesn't do. We're making things easy by only supporting CPU. ZML maintains and ships plugins for GPU (CUDA, ROCBlas), TPU, and more. Getting the right plugin version, linking it correctly, and handling platform-specific quirks is a significant engineering effort that ZML handles for you. We've also done zero work on performance, even though we get some parts through PJRT automatically.

There are plenty more things to list here, but this is just to make the point that we're still far away from making a production-grade framework.

Demo

After having started from understanding what a simple add looks like in StableHLO, it's extremely satisfying to have a full transformer model implemented in fusebox.

I expanded the opset to support running a Llama-style LLM. The model definition uses everything we built, #[derive(Module)], nested submodules, Vec<TransformerLayer> auto-discovered from the checkpoint, operator overloads, the whole thing:

#[derive(Module)]
pub struct Attention {
    pub q_proj: Linear,
    pub k_proj: Linear,
    pub v_proj: Linear,
    pub o_proj: Linear,
}

#[derive(Module)]
pub struct Mlp {
    pub gate_proj: Linear,
    pub up_proj: Linear,
    pub down_proj: Linear,
}

#[derive(Module)]
pub struct TransformerLayer {
    pub input_layernorm: RmsNorm,
    pub self_attn: Attention,
    pub post_attention_layernorm: RmsNorm,
    pub mlp: Mlp,
}

#[derive(Module)]
pub struct SmolLM2Model {
    pub embed_tokens: Embedding,
    pub layers: Vec<TransformerLayer>,
    pub norm: RmsNorm,
}

The entire model, including embedding, 30 transformer layers, RoPE, causal masking, GQA, and tied lm_head, is traced with a single call to SmolLM2Model::trace(cx, "model", shapes)?. The derive macro walks the struct recursively, and the safetensors header provides every shape. It's nice to see everything coming together.

The compile and run lifecycle is the same pattern as in the MLP example:

let ckpt = Checkpoint::from_file("smollm2-135m-instruct.safetensors")?;
let device = Device::cpu();

let runner = device.compile("smollm2", |cx| {
    trace_smollm2(cx, ckpt.shapes(), batch, seq)
})?;

let weights = ckpt.load_weights(runner.signature())?;
let sess = runner.session(weights);

// Each generation step only binds the input tokens
let result = sess.run(|inputs| {
    inputs.set_input_i32("tokens", token_ids)?;
    inputs.set_input_i32("last_pos", last_pos)
})?;

Let's try the SmolLM2-135M-Instruct demo first:

clone the repo
download the PJRT CPU plugin (example in justfile)

Then download the weights and tokenizer:

uv run examples/smollm2/download-smollm2.py

Build a release binary (shouldn't take more than a minute):

cargo build --release --example smollm2

Compile the model graph:

./target/release/examples/smollm2 compile

Tracing + compiling (seq=256)...
Compiled in 688.00ms
Saved to examples/smollm2/artifacts/smollm2.compiled

And chat:

./target/release/examples/smollm2 chat --compiled examples/smollm2/artifacts/smollm2.compiled

Loaded compiled model in 207.73ms
Loaded weights in 85.29ms

SmolLM2-135M-Instruct ready. Type a message and press Enter. Type "exit" to quit.

You> Who was Charlie Chaplin?
Assistant> Charlie Chaplin was a renowned American silent comedy actor, known for his distinctive voice and innovative style. Born on July 28, 1889, in New York City, Chaplin was raised in a family of modest means.

Chaplin's early life was marked by poverty and hardship. He was born into a working-class family, and his parents were struggling to make ends meet. Chaplin's parents were also struggling to make ends meet, and they were often forced to live on the streets.

Chaplin's early years were marked by poverty and hardship. He was born into a working-class family, and his
[27 prompt tokens, 200 generated | TTFT 316ms | 5.0 tok/s]

If you omit the --compiled flag, the model compiles on the fly, about 630ms extra. As mentioned earlier, ZML allows you to compile the graph and load the weights in parallel, which hides this latency.

At this stage, I'm going to come out of my rabbit hole. It's been a deep enough dive, and we have a model that works. If you enjoyed reading this, please share!

Thanks to Chris, David, Amine and Moritz for helpful feedback 🙏

Let's predict

Wed, 24 Dec 2025 00:00:00 GMT

This is my twenty-fourth and final post in the Advent of Writing series.

It's been a good journey. For this last post, I want to end with a few deliberately cheesy predictions about AI and the state of tech in 2026.

Before that, an appeal to authority:

Prediction is very difficult, especially about the future. Niels Bohr

Predictions are easy to dismiss because they so often fail. When they do succeed, it frequently feels accidental, or correct for the wrong reasons. A random guess at best.

I think that misses the point. Predictions are rarely useful as literal forecasts. They are useful as tools to understand the present, and to surface what people believe about where things are heading.

A prediction, here and more generally, is an attempt to make sense of what is going on right now, and to sketch how those forces might continue, stall, or break.

With that framing in mind, here are a few predictions for 2026.

1. More specialized AI models

What does the present look like? So far, general-purpose LLMs have generated most of the revenue and driven the field forward. ChatGPT was the breakthrough that pulled AI out of a niche and into everyday conversation.

How will this continue? I expect general LLMs will remain the backbone of AI as most people understand it. But I expect smaller, more specialized models to become far more common.

The first hype wave has passed. Many companies are now confronting the actual cost of building and running LLM-based systems. That forces the question: can the same task be done with a smaller, cheaper, more focused model? And if a product cannot clearly demonstrate value or productivity gains, it becomes hard to justify anything beyond an MVP.

Audio models, embedding models, and other task-specific systems are tiny compared to general LLMs. I expect that logic to spread.

2. Inference will catch up to training

What does the present look like? Today, most GPUs are still used for training. Reliable numbers are hard to find, but estimates often suggest that 60-80% of GPU spend goes toward training rather than inference. That figure should be treated with skepticism, but it's probably in the right ballpark.

This makes sense. We are still experimenting aggressively with architectures, scaling laws, and training techniques. New models are released constantly.

How will it continue? Training will remain important, and large investments will continue. But a rebalancing feels inevitable.

Once you spend enormous resources training a model, you want to deploy it widely and cheaply. We already see this pressure showing up. Google's TPUs make long-context inference significantly cheaper for them than for competitors. Nvidia's aquisition of Groq points in the same direction.

Inference is where models meet reality. That's where cost, latency, and reliability start to matter more than benchmark scores.

3. 2026 won't be revolutionary

What does the present look like? Since ChatGPT's release in 2022, we've grown accustomed to model launches that feel revolutionary. It's easy to forget how much progress has actually happened. ChatGPT was built on GPT-3.5, and today models like Llama 3 70B outperform it on most benchmarks.

The constant pace of “breakthroughs” has numbed us. If a new model doesn't double some benchmark score, it barely registers online. This creates strong incentives to optimize for benchmarks rather than real-world usefulness, leading to impressive releases that sometimes disappoint in practice.

How will it continue? I expect impressive new models to keep coming, but with a noticeable plateau, especially for general-purpose LLMs.

At the same time, we still have a lot of work to do integrating existing models into the real world. Outside the AI bubble, adoption is slower and messier than it looks on Twitter/X. That gap won't close through flashy releases, but through boring, friction-filled engineering and organizational change.

That work takes time.

These predictions are not meant as my future bragging rights. The point is not to post something today and return in a year to highlight the one thing that I happened to get correct.

I want to provoke thought. For you to reflect on what you believe is true about the world right now, and to ask how that trajectory might continue.

So think for yourself. What do you believe is happening today, and where do you think it leads?

Performing Performative Performances

Tue, 23 Dec 2025 00:00:00 GMT

This is my twenty-third post in the Advent of Writing series.

Today I'm doing what I'd call my first rant. It's about online nonsense and viral ideas that don't make much sense to me. I'll complain a bit, but I'll also try to make sense of it by the end.

If you don't work on the holidays you're ngmi

When I studied at uni, we had these unspoken pissing contests about who spent the most hours in the library before exams. Staying late at night was a flex. That later turned into flashy internships and bragging about how deep into the night you had to grind at the office.

It was, by any reasonable definition, extremely performative. Most of the studying wasn't efficient, nor particularly meaningful. Anyone looking at it from the outside would have called it a waste of time. It was mostly driven by peer pressure and mimetic games.

We were hungry, in our early twenties, and this kind of behavior fit the picture. I didn't think it made much sense even back then, but I played along anyway.

The unfortunate part is that some people carry this mindset far beyond their uni days.

Before going further, let's address the obvious objections. I can already hear them forming.

Without hard work, you'll never do anything remarkable. True.

Plenty of successful people in sports, business, and art worked insane hours to get where they are. Also true.

None of this argues against hard work itself. It argues against what hard work often looks like.

I'll quote Karri Saarinen, CEO of Linear here:

Working 80 hours on low-quality tasks isn't the hard part. The hard part is driving meaningful growth by finding leverage, building systems, and advantage.

Putting in the hours matters. Walking the extra mile when no one else does matters. Pushing yourself to the limit can matter if you want to achieve something exceptional. But that alone isn't enough, and it's not the hardest part.

The harder and more important question is what you're working hard on. Which direction you choose. Where you're actually applying effort.

Finding real competitive advantages and building systems that outlive you are what compound over time. At least for me, those ideas rarely appear during long grinding sessions. They show up while walking, sitting on the metro, brushing your teeth.

Those moments of thinking, not grinding, tend to be the ones that matter most.

And those are the factors that will ultimately determine whether you're going to make it or not, however you define making it.

The company's AI enablement is through the roof

This leads naturally to vanity metrics. Measuring hours worked is one of the most common ones, but it's far from the only example.

If this story from this tweet/X post sounds familiar, you know what I'm talking about:

Last quarter I rolled out Microsoft Copilot to 4,000 employees.

$30 per seat per month.

$1.4 million annually.

I called it "digital transformation."

The board loved that phrase.

They approved it in eleven minutes.

No one asked what it would actually do.

Including me.

I told everyone it would "10x productivity."

That's not a real number.

But it sounds like one.

HR asked how we'd measure the 10x.

I said we'd "leverage analytics dashboards."

They stopped asking.

Three months later I checked the usage reports.

47 people had opened it.

12 had used it more than once.

One of them was me.

I used it to summarize an email I could have read in 30 seconds.

It took 45 seconds.

Plus the time it took to fix the hallucinations.

But I called it a "pilot success."

Success means the pilot didn't visibly fail.

The CFO asked about ROI.

I showed him a graph.

The graph went up and to the right.

It measured "AI enablement."

I made that metric up.

He nodded approvingly.

We're "AI-enabled" now.

I don't know what that means.

But it's in our investor deck.

A senior developer asked why we didn't use Claude or ChatGPT.

I said we needed "enterprise-grade security."

He asked what that meant.

I said "compliance."

He asked which compliance.

I said "all of them."

He looked skeptical.

It's easy to make fun of large corporations for chasing vanity metrics like this. But startups and individuals fall into the same trap all the time.

Chasing the next funding round instead of actual customers. Comparing who in the friend group has the best 10k PR instead of focusing on long-term health. Optimizing for numbers that look good rather than outcomes that matter.

The examples are endless.

If you think during the holidays you're gmi

This brings me to the final point.

If you deliberately create time and space to think about your life and your actions, you'll be better off.

I don't literally mean that this has to happen during the holidays. If you only do it once a year, you're probably not doing it often enough. Do it whenever it makes sense for you.

Imagine being one of the first humans to sail across the Atlantic and measuring your course once before departure, then just committing to it. That would be a terrible strategy. A better strategy is to check your position regularly. Adjust if you realized your initial measurements were off.

Your life isn't much different.

When was the last time you course-corrected?

If you don't have a clear answer, maybe now's a good time.

Collection of Quotes, part 3

Mon, 22 Dec 2025 00:00:00 GMT

This is my twenty-second post in the Advent of Writing series.

This is part 3 of my fallback format. I've been collecting quotes on my phone since I was 15 or 16. Here I'm sharing a few fun and hopefully interesting ones with you. You can read part part 2 here.

Wise men talk because they have something to say; fools, because they have to say something

Usually attributed to Plato. The key takeaway here is the power of listening. Listen more.

Fighting for peace is like screwing for virginity

By George Carlin. This is probably intended as a criticism against war and armed conflict, but I've started to interpret it more generally. There's a tendency to describe one's journey as a fight or struggle of some kind. A fight against an institution or a system. But I've found life easier when abstaining from framing things this way. Fights are brutal, hard and always have a winner and loser. Difficult things can be enjoyable and life is full of non-zero-sum games. I prefer to play them.

I would never die for my beliefs because I might be wrong

Bertrand Russell. Put simply, don't take yourself too seriously.

We devote our intelligence to anticipating what average opinion expects average opinion to be

John Maynard Keynes. We really have an obsession with the normal distribution. And I don't know why. Maybe there's something inherently appealing in it. Or maybe it's because of education? I think a lot of valuable lessons come from unlearning the normal distribution and understanding how a world works which operates under different distributions.

If you only read the books that everyone else is reading, you can only think what everyone else is thinking

By Haruki Murakami. More generally: be aware of your information diet. And this extends to social media as well. If you read Twitter/X day in and day out, your thinking will be affected by your feed. For better or for worse.

You will never do anything remarkable

Sun, 21 Dec 2025 00:00:00 GMT

This is my twenty-first post in the Advent of Writing series.

Today has been busy: preparing for Christmas and spending time with family. So I don't have a full post of my own thoughts to share. But fortunately, I have something better: someone else's thoughts. This is a partially and slightly edited transcript from the video "You Will Never Do Anything Remarkable" by exurb1a.

It had a huge effect on me when I first watched it, about five years ago.

It's witty, clever, and delivers an important message with a beautiful story. I won't include the entire story here, just the culmination.

By all means, you should watch the video, but let this be a small glimpse into it.

Enjoy:

For the longest time I believed that there were two types of people:

The knowers, who knew what they were doing with their lives, and then the feckless plebs like me, who were just wandering idiots going from plan to misguided plan. Thirty is now spitting distance away from me, and, you know, the most traumatic part of exiting one's twenties isn't the sudden random failure of body parts, nor the blissful crushing hug of student debt, or even losing the ability to party past six in the morning and not die. It is the realization that this model is bollocks, because these people do not exist. Now, clearly, expertise exists, don't trust a barista to fly your plane, nor a pilot to make your double frothy laxative anxiety juice. But when it comes to wisdom, or working out how to be happy, or big boy and big girl meaning of life stuff, no one has a damn clue what they're doing. Not your heroes, not the smartest among us. When it comes to matters of the soul, it is open season. And this is a wonderful thing, because it means that as far as art or innovation goes, the world is anarchy.

And while you may have convinced yourself that there's no point trying to do anything groundbreaking or novel because someone will do it better. Whoever the greats are that you respect, obviously they had the same doubts, and they pushed through it. They were intensely interested in or devoted to something, while simultaneously feeling lost all the time. A long period of confusion isn't a side effect of trying to do something radically interesting, it's the price of admission. We forget that Van Gogh was 27 before he even bothered trying to paint properly, that Darwin told us: "I was considered by all my masters and my father a very ordinary boy, rather below the common standard of intellect", that Emily Dickinson was barely even recognized during her lifetime, that it wasn't until a hundred years after Melville's death that anyone really gave a damn about Moby-Dick. They were beset on all sides by mean critics, or the worst critic of all: themselves.

Cthulhu's dick, I have heard of art classes where the teacher begins the first semester by assuring the students they'll never break through, and it's pointless to try; rejection letters writers received, instructing them to put down their pens and never bother at it again; vacuous jaded bollocks that convinces young artists to give up, but may I humbly recommend that if one is informed you will never do anything remarkable with your life, perhaps the most appropriate response isn't "Yeah, you're probably right", but rather, "Fuck off! And who the fuck are you anyway?!" The shit they will tell you: "you've had all your good ideas", "it's all been done before", "you're too old, too young, too dumb", "there's nothing new under the sun".

Let's say your lifespan is 80 years, or about 29,200 days. If you're 18, you're about 6,500 days through. 28 about 10,000 days through. 38 about 14,000 days through. Regardless of whether one believes in an afterlife or not, these days are not coming back, and there is not enough time to listen to cynics. By the power of Grayskull, look at where we are. Historically, technologically, galactically, the whole game! This isn't normal, is it?

Act without expectation. Make cool stuff just because. Give cats fishies always.

Today, this week, this month, year, decade, and century. Will occasionally be referenced in history, and that will be that. If one is cautious about pursuing an unusual path, it may help to remember that the cynics will be forgotten just as readily as your failures will be, too. There has never been a better time to do a thing. And just by virtue of how weird existing is in the first place, there are a trillion interesting things still undone, unmade, and unsaid. Those areas have not been drilled, Eli. It is a wilderness out there for everyone. It always was.

The greats didn't know they were greats, they were just mortal humans who refused to bow to cynicism. And were we to draw some collective lesson from their lives, it might sound something like: in your projects, in your silly pursuits, in your unlikely follies, and your expeditions into the abyss to recover those strange mental metals you will fashion into something no one has ever made before. I wish you the very, very best of luck.

Now sod off and be remarkable please.

Advent of Writing Reflections

Sat, 20 Dec 2025 00:00:00 GMT

This is my twentieth post in the Advent of Writing series. Today I'll do some reflections on this challenge, what I've learned so far and what the experience has been.

You can read the first post Why I'm joining this challenge but I'll give a short tl;dr:

Being a really good communicator, written and spoken, is extremely valuable.
You can become a great communicator simply by practicing.
I've wanted to write more for years but never managed to stick with it. Maybe this time will be different.

Writing every day is challenging

I've tried to do Advent of Code before, so I kind of knew from experience that sticking to something everyday is hard. It's easy to get a 5 to 7 day streak. But as you get closer to the 12 to 14 day mark, it's very likely that "life just happens". Something unexpected comes up, work takes longer, etc. During these days it's extremely easy to fall off the wagon and miss a day.

In the scope of an Advent challenge, missing a day isn't ideal, so I've really made sure that I write every single day. No excuses. But honestly, if you're trying to build a longer, sustained habit of writing, you should probably be a bit more lenient. Missing one day isn't that bad, just get back to it.

Writing every day is easy

Paradoxically, it's not that hard to sit down and scribble your thoughts every day. Most of them aren't worth publishing, but you probably won't know in advance which are and which aren't.

This challenge has been incredibly helpful for me with regards to the last bullet point: I've never been able to stick with it. Having a forcing function that just makes me write, and get it out, has helped a lot. I've written pieces that I've had in my head for ages, and pieces I never imagined I could write. The advice is so obvious that it's silly. Just start doing it and you'll improve. I've heard it over and over again, but acting on obvious advice is one of life's hardest parts.

And I'll be honest about it: some days writing felt so easy and the words just flew. Other days it felt like being stuck in a tar pit.

Editing is divine

To write is human, to edit is divine.

Stephen King.

Editing text is probably the most cumbersome part. It's easy to spew ideas on a paper or screen. But reading your article for the fifth time, thinking through the logic, is it interesting enough, could I tweak the intro? Honing in on these things is the real work.

Some of my texts are more edited than others, due to time constraints. And at least to me it shows. Edited texts get to the point faster and have a clearer structure and build-up, usually without losing that personal touch. Editing shouldn't take away your own tone and style. It should enhance and polish it.

I think this has been the biggest learning so far: learn to edit and polish to improve my texts. At the same time, set a hard deadline so I don't polish the blog for ages and end up never publishing it.

Write more

The bigger question for me is: how will I continue my writing once the challenge is over. Will I just stop and go back to basics? Or do I find a nice balance by publishing a blog once a month or once a week?

I'll set myself the goal of maintaining some form of cadence, but a lot less intense than so far. I'd like to write longer and more in-depth texts and publish less frequently. The benefit and drawback of this challenge is that most of my texts have been pretty short. Just one argument, to the point.

Finally, I'd like to direct a huge thanks to Tereza for setting up this challenge. It's been, and still is, a good journey. You should do this to.

Feature Design with Mitchell Hashimoto

Fri, 19 Dec 2025 00:00:00 GMT

Welcome to my nineteenth post in the Advent of Writing series.

Today Mitchell Hashimoto posted on Twitter/X a 17 minute video on "feature design", or rather, the lack of it. The core idea is that feature design is the "planning step behind how you're going to solve one or more user problems with a product feature". It's explicitly not visual or architectural design.

I watched the video, found it brilliant, and want to share it more widely. That's why I'll try to condense it into a short post with the key points and add my own thoughts and commentary. You should still watch the original video, don't think of this as a replacement, but rather a complement to it.

Ketchup and Ice-Cream

When I was a kid or teenager, someone taught me about the ketchup and ice-cream compromise. One kid wants to eat ketchup and the other one wants to eat ice-cream, so both get ice-cream with ketchup. A combo that, unsurprisingly, no one likes. Unfortunately, this is what a lot of products look like without feature design.

And this is also the first point that Mitchell makes, using two feature requests for Ghostty. Users wanted a dedicated "copy mode" (Vim-like selection and copying) and Vim-like navigation (e.g., hjkl keys for moving around). As he says, the naïve approach would be to go ahead and implement these features separately. After all, users requested them. If you do this, you should stop, take a break, and take a step back.

We don't want to eat ketchup with ice-cream.

Instead, we should figure out if there's a way to solve both of the underlying problems those two users have with a more general approach that fits into the product more natively. In Mitchell's case, he designed "key tables"—named sets of key bindings that act like switchable scopes or modes. This solves both requests generically, allows users to define their own modes, and sets the stage for future features like chained keybinds. Maybe there is such a unifying solution; maybe there isn't. But it's worth looking for.

And importantly, you shouldn't expect users to be able to figure this out. Users won't have a holistic understanding of your application or of other users' requests. It's up to you to look for patterns and opportunities to solve multiple related problems with one underlying system.

What does good feel like?

Once you have an understanding of 1) what needs to be solved and 2) what's the general approach to solve it, it's time to play around. Mitchell uses the example of doodling a configuration syntax for Ghostty in a throwaway file. But you should apply this to whatever is the relevant place for you: mock your UI, quickly prototype a rough interface in code, sketch out function skeletons without implementing them, and write some code where you're pretending to call them. Whatever the correct playground is for you.

The key point is that humans interact with software emotionally; good design evokes positive feelings. So keep on doodling until it makes you feel good.

I'd optimize for quick iterations and focus on having an environment where you can throw stuff away fast and recreate it from scratch. Also, as Mitchell points out, just because it feels good doesn't mean the feature makes sense yet. And it's easy to confuse the two.

Cohesive integration

At this stage it's tempting to say: "I've got it." I know what this should look and feel like. I have a doodle that feels good, let's implement it. But this is the crucial place to hold your horses. Not yet.

The key question now is: how does this fit in the big picture? The example Mitchell brings up in Ghostty is a new way to configure keybindings for reusable key tables. And Ghostty already has a whole section and way to configure keybindings; so how does the newly proposed feature fit the existing keybindings?

Similarly you could think of a product where you can configure dark/light mode, but now you introduce completely new themes. So are themes a separate thing, each with a light and dark mode implementation, or are light and dark modes themselves themes, just like any other?

Or maybe your new feature is a completely novel thing that doesn't fit with anything you have so far.

Whichever it is, it's crucial to integrate the feature smoothly. The last thing you want is to have made all this effort, only to slap the feature in a place where no one finds it, where it doesn't make sense, or even worse where it contradicts the current way of using your product.

It's easy to kill a good, well-made feature by putting it in an awkward spot.

Implementation time

Finally we get to the part that we as engineers know and love: implementation. What's the technical spec, what database do we use, which algorithm is best here? This is the place we're comfortable with and the space we know how to navigate.

No feelings or emotions to evaluate, just execute and use good judgement. I won't put much thought here, since I think many find this place easy to work in.

But two important things to note:

This stage isn't trivial. Just because it's the one engineers are most familiar with doesn't mean you can handwave it. Good technical implementation still matters, and failing here can easily kill the feature.
Implementation details are conditioned on every previous step. If you happen to change your view in one of the previous steps, you might need to revise.

A few good tips that Mitchell also mentions:

Write out the design: Writing isn't just documentation, it's a forcing function for clarity. It forces you to take a breath, reveals flaws, and uncovers overlooked edge cases or incompatibilities with planned features (like how key tables interact with upcoming chained keybinds). Do it.
Use AI as a rubber duck: It's a solid way to double-check your logic and have it play devil's advocate. But remember, you can't outsource your judgement and cirtical thinking.

Last touch

Finally, I think this is something you have to practice a lot to become good at. And I try to practice it myself every time I get an opportunity. The difficult part is that feedback is sparse and unclear. Once you implement a feature, you won't automatically know if your process led to a good decision. You have to set that system up: qualitative user feedback, revenue metrics, usage statistics. Whatever metric is relevant for your case. And it might take a long time before you actually receive any real signal. Try to pull that feedback forward as much as possible.

For Mitchell, this stuff is second nature, as he mentions, but it comes from years and years of practice.

So if there's any takeaway from this blog and video, it's that you should get into real scenarios as much as possible and practice building things that truly solve people's problems. There's no shortcut to learning that.

Huge thanks to Mitchell for making the video.

The Next Subject

Thu, 18 Dec 2025 00:00:00 GMT

This short story is the continuation of Time for Trinitus, which was my blog on day 13 for Advent of Writing. I highly recommend reading it first before going into this one.

[12:32:54 Universal Standard Time] Trinitus felt the sun on his cheek and the wind rush through the open window as he drove along the winding road through the Peaks. The car hugged the asphalt effortlessly. Broken by Tears for Fears played louder than it needed to.

Winning hadn't gone the way he imagined.

Lilly had come with him, but only because there hadn't been time to explain. She moved through this new life as if she were visiting someone else's house. The rooms were too large. The silence too clean. She didn't touch the things he bought. She didn't enjoy the view. Everything felt foreign to her, and wrong.

That evening he found her sitting at the dining table, hands folded, staring at nothing.

“Is everything alright?” he asked.

“Why did you do it?” she said.

“Do what?”

“You know.”

“To save you,” he said. “To get us out. To give you a better life. Isn't this what we always wanted?”

She looked up at him then, calm and steady.

“I didn't ask for this. I didn't choose it. Every time I wake up, I know there are versions of me in pain. Versions you left behind.”

“You're here,” Trinitus snapped. “You're safe. This is the future that matters.”

“Yes,” she said. “And I know that in other futures I'm abandoned. Not by accident. By design. By the consequences of your choice.”

He stared at her, unable to understand how she could say this. He had risked everything. He had won. Other Lillys would do anything to be where she was now. She should be grateful. She should enjoy it.

Instead, she sat there unmoved.

Trinitus turned and walked out of the room.

All of this suffering, for what? To sit in a chair worth more than their old yearly income and think about versions of themselves that didn't make it. How could she be so selfish?

[12:32:54 Universal Standard Time] There had been robberies in the district again, so Lilly stayed inside. It was easier that way. The streets felt unpredictable now, as if something in them had shifted, even though nothing really had. She spent most of her time moving between the same rooms, listening to the same distant noises, waiting for the days to pass.

Trinitus was everywhere in her thoughts. Not as a memory she wanted, but as a presence she couldn't get rid of. She replayed the decision again and again, the knowledge that he had known exactly what he was doing. He had sat in that room, watched the futures line up, and accepted this one as an outcome. As something tolerable.

If he had truly loved me, she thought, he wouldn't have made my suffering so likely.

The idea lodged itself in her mind and refused to leave. It followed her through the apartment, settled next to her when she tried to sleep, resurfaced whenever she caught herself imagining him somewhere else. Because somewhere else, he was alive. Somewhere else, he had won. Somewhere else, another version of her was safe, living the life he had chosen to save.

She hated him for it.

One evening, as she sat alone with the lights off, a different thought surfaced, calm and unmistakable.

He died conditional on me being here.

The thought didn't shock her. It settled in quietly, the way obvious things do when you finally stop avoiding them. Trinitus hadn't gambled blindly. He had accepted outcomes like this one. He had looked at futures where she sat alone in this room and decided they were worth it.

She realized then that nothing had failed her. The world was working exactly as designed. People escaped when they could. Others didn't. The difference wasn't virtue or love. It was access.

Trinitus hadn't been special. He had just taken the door that was offered to him.

That was the moment something in her loosened. Not relief, not forgiveness, but understanding. Cold and steady.

Lilly smiled, alone in the dark.

[12:32:54 Universal Standard Time] The droid powered up after fifteen standard time units of charging. Its systems initialized without error. It left the charging cabinet and moved toward the injection table, where the subject lay motionless. The treatment had already been administered. Branch separation was expected within seconds.

At 12:32:56 Universal Standard Time, the first outcome was registered. The subject's vital signs ceased. The droid recorded the termination, sealed the body in a containment bag, and followed the disposal procedure. The bag was transferred into the chute. Pickup was scheduled automatically.

At 12:32:56 Universal Standard Time, the second outcome was registered. The subject remained alive. The droid logged the elevation and initiated the post-treatment protocol. It delivered the standard instructions and security recommendations. The subject appeared confused and physically exhausted.

“I made it?” the subject asked.

The droid did not respond. The schedule allowed no deviation. It escorted the subject out of the room and instructed him to leave the facility immediately.

After the subject exited, the droid cleaned the room and reset the equipment. All materials were returned to their default state. The logs were updated.

The droid advanced the schedule.

Next subject: Lilly Wunderbaum.

The Year 2025 in writing

Wed, 17 Dec 2025 00:00:00 GMT

Welcome to my seventeenth post in the Advent of Writing series.

Similar to quotes, I usually take pictures or screenshots of interesting things I read and see. Today I'll do a wall of these. And I'm not going to explain any of them. When I made this I immediately had the urge to add some context, but I think that might spoil some of the mystery.

I'll just leave you with these, and let you think for yourself.

Enjoy!

A Mental Model About Nuance

Tue, 16 Dec 2025 00:00:00 GMT

Welcome to my sixteenth post in the Advent of Writing series.

Today we will analyze this graph:

[*link to source*](https://kieranhealy.org/files/papers/fuck-nuance.pdf)

If you have not read the article, you should. The graph is from the brilliantly titled paper "fuck nuance", where Kieran Healy identifies three distinct types of nuance traps:

Fine-Grain: the urge to add just one more detail because it creates a sense of progress. We try to make a theory defensible from all points of view rather than broadly explanatory.
Conceptual Framework: building a theory so large and vague that it escapes criticism by reinterpreting any claim.
Connoisseur: culturally signaling that you are enlightened or intelligent by invoking nuance at every opportunity.

Healy discusses these traps in the context of science, but they are equally prevalent in business and many other parts of society. That is what I want to focus on here.

Nuance vs Compression

Charlie Munger was famous for his mental models of the world. In a very real sense, a mental model is a compression of reality.

Nuance is information-adding. It introduces new dimensions, exceptions, caveats, and edge cases. Compression does the opposite. It reduces while preserving meaning. It throws things away on purpose to keep only what matters. That is the interesting axis to explore.

A good mental model, meaning good compression, is a refusal to be nuanced. It commits to a dominant causal story and ignores details until they break the model. A mental model is lossy, and that is the point. You want to be approximately correct rather than precisely wrong.

Why Nuance Feels Like Progress

Nuance feels productive because it looks like movement. There are more words, more diagrams, more discussion. Something is happening.

Compression feels different. It forces you to say that this matters and that does not. Which is uncomfortable because it creates an easy way to attack your thesis. Once you compress, you are exposed.

This is why nuance is often mistaken for rigor. Nuance feels careful and sophisticated. Compression demands commitment. It asks you to bet that a small number of variables dominate the outcome.

Progress in understanding often looks like removal, not addition. A better model usually explains more with less. What changes is not the number of details included, but which details are deemed irrelevant.

Compression as an Escape from the Nuance Traps

Look again at the three nuance traps through the lens of compression. Each of them is a failure to throw information away.

The fine-grain trap is the belief that adding detail brings you closer to the truth. Each new exception feels like progress. Compression forces a more direct question: what dominates the outcome? Most systems are driven by a small number of first-order effects. Nuance lives in the margins. If you need more than a handful of variables to understand a phenomenon, you are not compressing.

Large conceptual frameworks fail by design. They are flexible enough to reinterpret any result as confirmation. Compression keeps the surface small and focuses on one clear claim. A good mental model makes statements that can fail. It tells you not only what it explains, but what would prove it wrong.

Nuance connoisseurs favor:

jargon over plain speech
complexity over dominance
social validation over transfer

Compression thinkers emphasize:

simple language
first-order effects
teachability

If an idea does not travel, it is probably not compressed.

Closing

Perfection in design is achieved not when there is nothing more to add, but when there is nothing left to remove.

Antoine de Saint-Exupéry

You do not make explanations better by adding layers and layers. You make them better when you arrive at an explanation from which you cannot remove a single sentence without rendering it wrong.

That is what good compression looks like.

Being a good Programmer

Mon, 15 Dec 2025 00:00:00 GMT

To the careless reader this blog might look like yet another post discussing how A.I. may or may not be the end of software engineering and programming.

But that's only if you read it on the surface. The underlying question we'll actually tackle is what makes a good programmer in the first place, regardless of A.I. or not. I'll argue that the underlying principles of being a good programmer in the age of A.I. are very much the same as they were before A.I.

What is different today is the rate of change. It's extremely rapid, and therefore the gap between good and bad programmers is growing even wider. Good programmers will be a lot more productive than before, while bad programmers will stagnate.

Note that I don't think the current level of A.I. will lead to a fundamental shift where we all go on holiday to the beach and let A.I. overlords write code for us and run our companies. Rather, I think this progress will lead to a huge acceleration in programming itself and in the potential capabilities of programmers.

Welcome to my fifteenth post in the Advent of Writing series.

Let's dive in.

Programming is building theories

Let's start with this quote:

...the proper, primary aim of programming is, not to produce programs, but to have the programmers build theories of the manner in which the problems at hand are solved by program execution.

link to source

If there's only one thing you remember from this blog, let it be this.

Unfortunately, when we learn programming as a craft and as a tool, we immediately skip over the step where we build a theory. You're given an assignment: “build a note-taking app using React and MongoDB,” or something more theoretical like “how can we improve the worst-case O(n) time complexity here?”

None of these assignments are bad per se. Both are important things to know and understand how to solve. The problem is that theory building is rarely exercised in formal education. Unfortunately, it's rarely exercised on the job either.

But the best companies require you to do it all the time, especially in more senior roles. Your job is to understand the world of the user: their needs, desires, and problems. And importantly, whether there's any business value in solving those problems at all. Only once you have a theory and a solid business case do you proceed with the actual technical implementation.

Then you discover that your theory was somewhat wrong, and you iterate the software with your updated beliefs. And in some cases you need to build first to even have a theory. However you form your theory doesn't matter much.

Just to remove any ambiguity: the technical implementation does still matter, a lot. You can't just hand-wave it away. The important takeaway is that theory building precedes technical implementation. A technical implementation without a theory is nothing. But equally, a theory with a bad technical implementation won't get you very far either. It might even send you down the wrong path, where you think you've (dis)proved your theory, but in reality you just built something that never properly expressed it.

A.I. is another layer (albeit a powerful one)

In the early days people wrote programs on punch cards, then machine code and assembly. From the 50s onward, high-level languages like Fortran, COBOL, and later C emerged. In the 90s we started developing even higher-level languages like Java and Python. Nowadays, a web developer rarely even writes plain JavaScript, but instead TypeScript inside a framework, which then gets compiled down to plain JS.

For better or worse, we've abstracted ourselves very far away from punch cards and assembly.

The modern programmer doesn't (mostly) need to think about memory allocations in JavaScript. It's all abstracted away by the runtime and engine you're using. Occasional memory leaks might happen, so it's good to understand the concept and how to debug them. But for most of the day, you can ignore it. And this is a good thing, it allows us to focus on delivering software faster to users without worrying about lower-level details.

The important aspect is trust. If V8 had memory corruption issues once per hour, it wouldn't work as a reliable building block in our tower of abstractions. A.I. is another building block in this tower. Just another layer up again. Now we don't even need to write the React code ourselves anymore, we can instruct the A.I., review the output, and maybe nudge it in the right direction.

Unfortunately, A.I. isn't yet as reliable as something like the V8 engine. In some cases we're simply thrown back down the stack and end up wasting time fixing what the A.I. wrote. But this isn't inherently an A.I. problem. There are still cases where C compilers don't produce performant enough code, and programmers drop down to analyzing assembly output or resort to intrinsics.

This problem exists at every level of the abstraction tower.

Don't mind the tower

The point of the examples above is this: if you were a programmer who was good at building theories from the beginning, you'll realize that it doesn't really matter which part of the abstraction tower you're working in.

At every layer, you still need to decide, judge, and apply taste to what should be built. And importantly, you need to be able to revise and change your opinion. Judgment survives abstraction.

What A.I. does change:

Iteration speed: you can verify and test theories much faster.
Tooling: learning new tools and programming languages becomes significantly easier.

Build theories

This would be a flat blog, ranting endlessly about the importance of building theories, if I didn't at least give some concrete action points on how to actually do that.

Needless to say, I'm not an expert in this area. I'm just a programmer with an opinion, which I guess is the first step in building theories. For many things, you probably have better intuition than you think. We've all used software that sucks to use, and software that's invisible and just works.

Next time something does, or doesn't, get in your way, ask why. Then dig deeper.

Beyond that, books like The Mom Test are quite good. They help you learn how to ask better questions and uncover what people really want, as opposed to what they say they want.

Keep building!

Collection of Quotes, part 2

Sun, 14 Dec 2025 00:00:00 GMT

Welcome to my fourteenth post in the Advent of Writing series.

This is part 2 of my fallback format. I've been collecting quotes on my phone since I was 15 or 16. Here I'm sharing a few fun and hopefully interesting ones with you. You can read part part 1 here.

If you have an umbrella up your ass, don't open it.

Translation is mine, and it was originally delivered by Jonas Gardell. The moral of the story is: if you're in trouble, don't make it worse by doubling down. Instead, get out of the trouble.

To write is human, to edit is divine.

By Stephen King. During this Advent of Writing I've experienced this firsthand. It's not that difficult to get something jotted down and write out your idea. But to edit, re-edit, again and again is the real work. Could I express this idea shorter, more succinctly? That's the real work.

There's more fiction written in excel than in books.

Shaan Puri. Next time someone comes with their business plan or spreadsheet calculations, apply salt.

If you're arguing with a fool, he is probably doing the same

By Mikhail Zhvanetsky. There's an idea here. I read it on Twitter/X a long time ago and can't remember who wrote it. Two people have an argument, but before they actually start defending their positions, they have to explain them really well. In fact, so well that the opposing party is able to recite the other's standpoint, and you confirm that this is indeed correct. You can only start debating once you both understand each other's points well.

Likely this would avoid a lot of debates in the first place.

For every complex problem, there is an answer that is clear, simple and wrong

By H. L. Mencken. Now there's a fine line: there are obviously many bad and simplistic takes about genuinely difficult problems. But at the same time, in the spirit of the midwit meme and fuck nuance, some things are made more complicated for gatekeeping or trying to sound smart, etc.

I still really like the quote. I'm not a fan of claiming simple "truths" about complex areas I'm not familiar with.

Truth is like poetry. And most people fucking hate poetry

Not sure this is actually attributed to any one person. Just a really good one-liner.

And lastly a wonderfully confusing and simulateously beautiful quote:

I, a universe of atoms, and atom in the universe

Richard Feynman

Today's lesson is that once you start writing, things usually begin to flow. I thought for so long about what to write today, tried to prompt ChatGPT for good ideas, sparred with my wife for inspiration, and nothing seemed good. But once I sat down and started writing, the tension was gone, and I remembered that writing is actually quite fun.

Remember to enjoy your day!

Time for Trinitus

Sat, 13 Dec 2025 00:00:00 GMT

Trinitus collapsed onto the bench, hands slick with sweat, heat and cold washing through him in uneven waves. The sound of boots still echoed in his head. Somehow, he had lost them. A service door. A corridor no one used anymore. His time was scheduled for five o'clock Universal Standard Time. He had been instructed to arrive early. The facility forced every patient to sit one hour in the contemplation room before allowing them in. Most people chose to leave early and bail out.

Trinitus had chosen to take the treatment. A newly developed drug which alters your body based on real world outcomes. They said the trigger was tied to quantum noise, true randomness, beyond any classical prediction. There was no way to cheat it. The rules were clean: win the draw and the drug did nothing; lose, and his heart would quietly shut down. Survival and wealth were inseparable. That was what he was buying. The chances of winning the lottery were infinitesimally small, but there would be futures in which he got out of this shithole, out of this misery. Finally a man of means. He had tried every other way but failed.

He was thinking of all the things he had planned to do in this bright future. New house, private chef, elite school for the kids. The facility had put him in contact with a real estate agent specialized in post-treatment winners. Privacy wasn't luxury. It was how winners survived the first years. Not even Trinitus was allowed to know the location of the mansion. He stared at the pale ceiling and wondered whether the man who woke up rich would remember this room at all. Whether that future Trinitus would feel gratitude or only regret. The crimes would already be paid for. What followed was his to justify.

His phone rang, it was Lilly. Fuck. She was probably wondering what's taking him so long. He didn't want to deal with this right now, he's so close. He put the phone in silent mode and let it ring. Closed his eyes and rested his head against the wall, let out a deep sigh. Am I really going to go through with this? He looked once more at the future projector to get an approximate reading of T+6, one of the likeliest paths. In the reading the police arrived at their apartment (if you could call that shithole an apartment). At first Lilly was confused. She knew what they were about to say but her body fought to deny it. It couldn't be true. They told her what everyone already assumed. Lilly sank to the floor. The scream came later, carrying through the identical gray houses. She would now live, in this universe, poor and alone. In a few select universes he ran home to her with more money than they could ever imagine. But she didn't care, she's not in one of those.

Trinitus stopped the future projector and looked at his phone, 30 minutes left. There had been an article in the news the other day about the treatment. A man had allegedly undergone the treatment and woken up. The article said he went home and told his family to start packing. They were going to escape this hellhole of a district, move to the other side of the city, where the other rumored winners lived. The neighbors noticed the change and understood it immediately. In a place like this, luck looked like theft. They broke in without hesitation and stripped the place bare. Trinitus read it twice, then a third time, as if repetition could turn it into a warning he could actually use. His plan was to acquire a private safety company and get Lilly out of there before anyone noticed the change. He had the phone number ready to go in his phone. Everything had been prepared. He wanted to save her.

He imagined Lilly answering the door. He imagined a future Trinitus opening his eyes in a place like this, but brighter, quieter, untouched. He had fought so hard to live in a better place. He deserved an escape. What about Lilly? The endless versions of her collapsing in doorways, holding phones that would never ring again. They would understand, he told himself. He had decided they would have to. Trinitus pushed himself upright, heart racing, the thought still echoing.

The droid came into the contemplation room and said "time for Trinitus". This was it. The last moment where all futures still existed.

Writing without Backspace

Fri, 12 Dec 2025 00:00:00 GMT

Today's Advent of Writing post will be written without backspace. Sorry in advance.

Writing without backspace is a common strategy to improve on ones writing, the core idea is that you focus on the flow, and don't interrupt yourself with small details. A way of just getting something out there, a draft, and then edit later. Don't think ahead, just go.

Ironically, as I'm writing this, I'm more hesitant than ever with each keystroke. I guess most people don't intend to publish their drafts 😅

Life has no Backspace

In life you very much have to adapt a similar mentality. What you once say cannot be erased. Your only option is to say something new to try to correct your earlier statement. Some actions are so severe that there's no new statement to revert them. A new bungy jump can't fix a failed one. So thinking before acting really pays off.

Which is at the hart of the paradox. At the same time we should make more mistakes and be more brave. Quit your job to build your company, pursue your career in acting, build houses if that's what you want to do! But at some point we reach a fine line. Naval Ravikant talks about taking more risk but avoid things that with a high chance lead to death, ruin or jail.

Distinguishing between these in theory is trivial but in practice we (or at least I) fail all the time.

Own up to your mistakes

Once you say something silly (especially on the internet) there's no denying that you said it. When I wrote my blog on probability I wanted to make sure most of the wordings and expressions were correct, that there's no way to, by purpose or mistake, to misunderstand the argument I'm trying to deliver. Honing in on even small nuances to make the blog better and more correct.

This blog is the complete opposite, I knew in advance that I'm going to say something I wont be able to defend in the future. But so what? It's kinda liberating actually, having that attitude, it frees me from any stress of trying to be as correct as possible.

Once you own up to a mistake, move on with your life, you'll feel the burden lift away.

Authenticity is scarce, performance is abundant

In today's world with social media there's very little authentic takes out there. Most people post stuff for performative reasons. You post how long you stayed at the office, how fast you ran that 10km, how enlightening that trip to south-east Asia was. Even if I dislike the performative aspect of social media I fall for it as fast as the next guy. Not caring what other's think is really difficult, not seeking social validation is really difficult, being authentic publicly is really difficult.

This post is a humble attempt to be even just a little bit more authentic.

This actually came out better than I imagined in the beginning. I think I made three solid points, nothing revolutionizing but solid arguments. Wording and grammatical edits would improve the text, but that's not what we're here for.

I probably won't do this again in a blog post, but it's for sure a nice breath of fresh air.

Try!

What Makes an Idea Worth Building

Thu, 11 Dec 2025 00:00:00 GMT

I've done a lot of side projects over the years, which will be the topic of today's Advent of Writing post.

Friends have asked in various forms: "What makes a good side project?" and "How do you have the energy or stay motivated?"
Honestly, I don't have a fully baked five-step framework, but I'll share a few thoughts on what works for me.

In case you're interested, here are a few projects that still have some decent public repos:

2022: zero-knowledge app on Ethereum
2022: Figma plugin that let people generate images with Stable Diffusion
2024: a locally running virtual machine for pair-coding with an AI
2024: sandbox for executing Python in an isolated wasm32-unknown-wasi runtime
2025: building MLX with Zig instead of CMake

My ~/Documents/testing has a solid 129 more.

1. Pull is everything

Obvious, but worth stating explicitly. Don't start a side project for internet points. Don't chase whatever the hot new thing is. It's just not motivating enough. Do what you actually find interesting. You're literally not getting paid for this, and in the grand scheme of things no one really cares about your side projects. So for once, do something for your own pure, egoistic joy.

2. Momentum is the filter

Understanding something new.
Making something work.
Creating something beautiful.

These are the most addictive forces, use them.

The key is doing something that's not trivial for you, but where you get (or rather, set yourself up for) an early win. If the task is too easy, you'll get bored. If it's too difficult, you risk not getting a small reward to feed the prefrontal cortex enough to do it again tomorrow.

3. Produce > Consume

Instead of reading a blog on SIMD programming, try doing it yourself. The knowledge will stick longer, you'll learn it more intuitively, and you'll know for the future whether you even enjoyed SIMD programming.

If the last point wasn't enough of a cue for you to stop reading, here it is:

Close your browser.
Open your terminal.
Grab your paintbrush.
Dust off your piano.

Whatever your craft is, exercise it, and you'll become a master.

Now go and build!

Why Probability is Misunderstood

Wed, 10 Dec 2025 00:00:00 GMT

Most people think probability predicts the future; in reality, it measures our ignorance about the present.

People love to talk about elections in probabilities: “There's a 70% chance Candidate X wins.” But when the less likely outcome happens, they react as if the prediction was broken. To them, 70% sounds like a guarantee rather than a statement of uncertainty. The misunderstanding isn't about politics; it's about what probability actually means.

Probability is not a property of the world: it's a model of our uncertainty (let's disregard quantum physics for now).

Probability for One-Off Events

The key issue with the election example is wanting to assign a probability to the winner of a single election as if it's a coin flip. A coin flip's probability is grounded in repeatable experiments, whereas elections aren't repeatable; we can't sample the 2024 election 10,000 times. So from a frequentist view, election predictions aren't probabilities; they're belief distributions over unknown variables (like polling error, turnout, etc.).

When a model says “Candidate A has a 70% chance,” it means “based on current data and assumptions, in 70% of possible worlds consistent with the model, A wins.”

And no, this isn't a sci-fi argument or a stance on the many-worlds interpretation in quantum physics. In probability modeling, the “worlds” are a hypothetical idea, not a literal physical thing. But importantly, the math is identical to thinking in many-worlds quantum physics. The difference is:

In quantum systems, probability arises from superposition (the system actually exists in a blend of states).
In everyday uncertainty, probability arises from ignorance (we don't know the true state).

Let's use the election prediction example:

Let's say we run 10,000 simulations of how the election might turn out, taking into account sentiments on social media, demographic details, economic trends, and what not. Importantly, each simulation yields an outcome that's consistent with how our model of elections works. In most of the simulations, it's one of the two most popular candidates that wins. But every once in a while, the simulation generates a scenario where a third candidate, an underdog, wins. After the simulations, we have real elections, and most importantly, only one outcome out of all the possible outcomes will happen.

All the possible outcomes could have happened (with different degrees of likelihood), but only one did, which is the world we end up living in.

What Probability Really Is

Probability is a mathematical way of describing our uncertainty about reality; it's not reality itself.

How you choose to describe this uncertainty depends on your point of view. We already looked at the distinction, but let's put it more formally:

Frequentist probability describes uncertainty in repeatable experiments.
Bayesian probability describes uncertainty in knowledge.
Quantum probability describes uncertainty in the underlying physical state.

Elections cannot be handled in a purely frequentist framework because there is no notion of sampling repeated elections under identical conditions. Therefore, any probability applied to a single election is necessarily Bayesian in nature. Sometimes we unintentionally confuse the two. Say you were applying for a job. You could think: “What's the chance that I'll get this job?” In doing so, you are assigning a degree of belief given limited information. But ten minutes later you might say: “Well, it's either going to be a yes or no,” treating it like a coin flip.

Let's take another example:

What's the probability that Shakespeare wrote a poem we haven't discovered?

First of all, a poem either was or was not written by Shakespeare, but we don't know which. There's no coin to flip or dice to throw; we can't run an experiment to sample “alternate timelines.” The probability we assign is entirely about our uncertainty, not about the world itself generating randomness.

Interestingly, I think LLM hallucination risk follows the same pattern. We could say “the model hallucinates 5% of the time,” and it's not like there's literally a randomizer inside the model deciding “This time I hallucinate.” Instead, we're describing our uncertainty about the model's behavior on future, unseen prompts, based on observations of the past. It's exactly like asking the Shakespeare question but about a model's future output instead of authorship.

The common mistake in both of these cases is that they treat the probability as if it were describing a physical random event, like rolling a die, obeying frequentist principles. In reality, they are Bayesian: the number is about our knowledge, not about an inherent frequency. Even if the world is fully deterministic, Bayesian uncertainty still applies whenever you don't know the true state.

How To Think About Probability

So how can you turn the words from this blog into something actionable? Let's do some Bayesian updating on our mental models, shall we?

Instead of thinking in terms of “what will happen?”, think: “given what I know, how should I bet?”

Additionally, don't think about probability as some sort of prophecy. It's a tool for decision-making under uncertainty. Every statement about probability will be based on your assumptions about reality; understand those assumptions and question them.

Simple Intro to RISC-V Assembly

Tue, 09 Dec 2025 00:00:00 GMT

In my 5th Advent of Writing blog I mentioned that I'd eventually need to write an introduction or tutorial on basic assembly. Well—this is it! I'll go through the fundamentals with two goals in mind:

provide a genuinely helpful guide for anyone trying to understand assembly, and
refresh the basics for myself.

I think every programmer should be able to read at least some assembly. Very few people need to write assembly regularly, but everyone benefits from having an intuition for how things work beneath all the layers of abstraction. Modern software stacks hide so much of the machine that we easily forget what actually happens under the hood. This post is meant to be a reminder.

What is assembly?

In short: assembly is a human-readable representation of machine code. Here's a tiny example:

mv a5, a4

mv means “move,” and a5 and a4 are registers, small pieces of storage inside the CPU that you can access very quickly. This instruction copies whatever is in a4 into a5.

Most assembly instructions follow a pattern like this: instruction, destination, source(s). In general, what you do in assembly boils down to:

loading and storing values in registers and memory
arithmetic and comparisons
branches and jumps
a handful of other simple operations

RISC-V is a great architecture to learn on because it is very minimal: around a few dozen basic integer opcodes in the RV64I base ISA. By comparison, x86 has thousands of instructions thanks to 40+ years of backward compatibility.

Example

Let's look at what assembly this small C program produces:

#include <stdio.h>

int magic(int a, int b) {
    return a + b;
}

int main() {
    int c = magic(3,5);
    printf("%d\n", c);
    return 0;
}

I'm compiling this using a riscv64 toolchain, but any C compiler targeting RISC-V will give similar results:

riscv64-unknown-linux-gnu-gcc -static -o demo demo.c
riscv64-unknown-linux-gnu-objdump -d demo > demo.txt

We're going to zoom in on the magic function. Its assembly begins like this:

0000000000010406 <magic>:
   10406: 1101                 addi sp, sp, -32
   10408: ec06                 sd   ra, 24(sp)
   1040a: e822                 sd   s0, 16(sp)
   1040c: 1000                 addi s0, sp, 32

Let's go through this line by line.

`addi sp, sp, -32`

addi means “add immediate”: add a constant to a register. So this does:

sp = sp - 32

So whatever sp was before this function, it's now that minus 32. This allocates 32 bytes of stack space for the function. On RISC-V (like most architectures), the stack grows downward in memory, so subtracting from sp makes the stack larger. The image below illustrates this: where we imagine that the previous value of sp was 32. And that means after this instruction sp is at zero. And we've grabbed our stack.

`sd ra, 24(sp)`

sd means “store double-word” (8 bytes on RV64).
ra is the return address register: where execution should continue once this function returns. So essentially: “where should I go once I'm done with this function?”. In our case this would be the place where main called this function.

24(sp) means sp + 24. Therefore the entire thing is:

whatever is in ra
store those 8 bytes in sp+24, which is 0+24=24

And that goes inside our newly allocated 32-byte stack frame, like so:

`sd s0, 16(sp)`

This is a similar thing in that it stores something on the stack. But this time it's the caller's frame pointer (s0). And we store it at sp + 16.

A frame pointer is a stable reference to the start of a function's stack frame. So for the magic function this would be 32. But remember now we're storing the caller's framepointer. Why? The reason is that we can't just override s0 with our frame pointer, otherwise we'd lose whatever was there before. That's why we:

store the caller's frame pointer on the stack (this instruction)
override s0 with our frame pointer (next instruction)
and before exiting the function, we restore the caller's frame pointer into s0

Also it's good to note that not all functions need or use a frame pointer, but compilers often generate one because it simplifies debugging and stack unwinding.

`addi s0, sp, 32`

Now we can proceed to the next step, and safely create our own frame pointer. Remember, add immediate means:

s0 = sp + 32

in our case

s0 = 0 + 32 = 32

From here onward, the compiler typically accesses local variables relative to s0 rather than sp. You'll see that soon!

Okay so hopefully that makes sense. It's a bit of a weird pattern at first, but this is the most common one you'll see a lot in assembly. And it's pretty similar in arm and x86 as well. What we're doing is setting up the function by making sure we have enough space on the stack, storing all the references to our caller and we're basically getting ready to execute the function itself.

This next part will be a lot easier to wrap your head around, I promise.

Moving the function arguments

1040e: 87aa   mv a5, a0
10410: 872e   mv a4, a1

a0 and a1 hold the first two integer arguments, int a and int b. Here the compiler copies them into temporary registers (a5 and a4). In optimized builds this usually disappears, because the moves are actually unnecessary as we'll see later.

Saving locals and performing the addition

10412: fef42623   sw a5, -20(s0)
10416: 87ba       mv a5, a4
10418: fef42423   sw a5, -24(s0)
1041c: fec42783   lw a5, -20(s0)
10420: 873e       mv a4, a5
10422: fe842783   lw a5, -24(s0)
10426: 9fb9       addw a5, a5, a4

Piece by piece what's happening is:

Store whatever is in a5 (which is the function argument int a) to s0 - 20. sw means “store word”. Remember s0 was 32. So 32-20=12. And if you recall "double-word" was 8 bytes, logically a word is then 4 bytes.
Move the value in a4 (which is int b) into a5.
Store the value in a5, a.k.a our int b, to s0 - 24, which is 32-24=8.

lw means “load word”. So now we're taking the value at s0-20, back from the stack into a5. Remember this was our int a.
And now move that value from a5 into a4. So now int a is in a4. Confused? Don't worry.
Load from s0-24 into a5. This is where we stored int b.
addw means “add word”. So it adds the 32-bit values in a4 and a5. Finally 🎉

Phew 😅 now that's a lot of moving data for just adding two numbers. If you think this is silly and inefficient, you're right! We'll later look at the optimized assembly for this function, so stay tuned!

Sign-extend and prepare the return value

10428: 2781   sext.w a5, a5
1042a: 853e   mv a0, a5

This is not super important, but sext.w sign-extends the lower 32 bits to a full 64-bit value, because addw produces a 32-bit result (with RV64 semantics). And the return value must be in a0, so we move it there.

Restoring the caller's state

Remember the ceremony we did in the beginning with setting stack and frame pointers? Now it's time to unwind those.

1042c: 60e2   ld ra, 24(sp)
1042e: 6442   ld s0, 16(sp)
10430: 6105   addi sp, sp, 32
10432: 8082   ret

So first we take the return address of the caller, which is at the top of the stack at sp+24. And we put that into the ra register, this is where we need to go back, it's the address of our caller.

Then we restore the frame pointer to the caller's. This is so that when we go back into the function that called us, it can continue to reference its local variables from the correct reference point. Similarly to how we moved int a and int b always relative to s0.

And then we give back the stack we allocated in the beginning, now the stack pointer is at 0 + 32 = 32, which is what it was when we started this function.

Finally, return!

The optimized version (-O3)

I promised you that I'd show the optimized version as well, here's the entire function when compiled with -O3.

000000000001040a <magic>:
   1040a: 9d2d   addw a0, a0, a1
   1040c: 8082   ret

That's it! No frame pointer, no stack usage, nothing extra. The addition happens directly in the return register.

And the compiler goes even further when we look at the main function:

000000000001030e <main>:
   1030e: 00050537   lui a0,0x50
   10312: 1141       addi sp,sp,-16
   10314: 95850513   addi a0,a0,-1704 # 4f958 <__rseq_flags+0x4>
   10318: 45a1       li a1,8
   1031a: e406       sd ra,8(sp)
   1031c: 143000ef   jal 10c5e <_IO_printf>
   10320: 60a2       ld ra,8(sp)
   10322: 4501       li a0,0
   10324: 0141       addi sp,sp,16
   10326: 8082       ret

Notice anything missing? There is no call to magic at all.

The compiler realized that magic(3,5) is always 8 and simply folded the constant, which is the line with li a1, 8, into the call to printf. This sort of optimization is extremely common in modern compilers.

Wrap-up

Hopefully this tutorial helped you get a better grip on reading assembly, especially how function prologues and epilogues work, how registers are used, and why unoptimized code looks so strangely verbose.

Happy hacking!

Collection of Quotes, part 1

Mon, 08 Dec 2025 00:00:00 GMT

Welcome to my eighth post in the Advent of Writing series.

Today I'll need to do something rather quick, I don't have time to write a full blog post. Fortunately, I have an ace up my sleeve. I've been collecting quotes on my phone since I was 15 or 16. Time to go through them and list a few interesting and fun ones.

If you're not prepared to be wrong, you will never come up with anything original.

A quote from Sir Ken Robinson's famous TED Talk. The video was apparently uploaded 18 years ago, so I wrote down the quote around that time, maybe 16 years ago. The video had a big impact on me back then, it made me confident in pursuing what I personally wanted to do and not seeking validation from others.

I'm too fucking busy, and vice versa.

By Dorothy Parker. I've always just found this one really hilarious. That's why it's on the list.

Some pursue happiness, others create it.

Origin unknown. It's a bit cheesy, but hey, I was maybe 17 or 18 when I wrote it down. It was the first time I remember thinking more deeply about agency. I have the power to change things in my life and create them, rather than needing to chase them.

Have you ever imagined a world without hypothetical situations?

By Steven Wright. I just really enjoy paradoxes and things that seem contradictory.

A person is a person by means of other persons.

I think the origin of this one is unknown. It seems to be a paraphrase of the Ubuntu philosophy. It's a more poetic version of the common saying "You're the average of the five people you spend the most time with".

Every day above ground is a good day.

Said by the almighty and great thinker Pitbull. And even though I'm not at all a fan of his, this is actually quite well said.

Pessimists sound smart. Optimists make money.

This is by Nat Friedman (or Naval Ravikant, not sure who coined it) and is one of the later additions to my collection. I wrote it down as a reminder to myself not to be Mr. Actually-It's-More-Complicated-Than-That guy.

And I'll leave you with:

In theory, there's no difference between practice and theory. In practice, there is.

Yogi Berra

Post Run Reflections

Sun, 07 Dec 2025 00:00:00 GMT

Welcome to my seventh post in the Advent of Writing series.

Today I ran the Paris Saucony 10km race. Since I spent the week preparing for it and it took up most of today's headspace, I don't really have the capacity to write about much else. So this post is a bit of an experiment. I'm not entirely sure what it will become.

Context

I usually run 5-6 times a week, with a few gym sessions in between. I'm not training with any competitive goal in mind; it's mostly about staying healthy. The last time I ran a race was a marathon before Covid, so it's been a while. But a few colleagues signed up for the Saucony 10km, and it seemed like a fun challenge, so I joined them.

Outcome

I ran a personal best on the 10km: 46 minutes and 21 seconds. I'm pretty happy with that.

Reflections

The first few kilometers went by quickly, and around the third kilometer I settled into a solid pace. I could feel that I was pushing myself, but I was confident I could hold it until the end. Kilometers five to seven were the mentally toughest. I noticed I was slowly dropping speed, so I had to remind myself not to slack. My pace fluctuated more than I would have liked.

From the eighth kilometer to the finish line, it was simultaneously euphoric and agonizing. It was only a ten-minute window, but it somehow felt like an eternity. The music got louder and the cheering crowd gave me energy, but I was tired and my legs felt heavy. I knew this was the moment to push. I'd made it this far at this pace, and now it was just a mental game to bring it home. Yet it's so easy to drop the pace without noticing and lose valuable seconds.

One epiphany I had is that this kind of mental battle is very different from what I'm used to in startups and building software. A race like this is a short burst where you really have to drive yourself to the end. Needless to say, I have nothing else planned for today, and I'm wiped out. Building companies looks more like how I trained for the race: go out for a run almost every day, focus on foundational zone-2 cardio with a few interval sessions, emphasize recovery, and don't push too hard. Otherwise you can't sustain it for years.

Startups aren't won in a ten-minute sprint. They're won in the quiet, unglamorous miles no one sees.

Summary

A friend just reminded me of a quote we used to say in the military:

The only easy day was yesterday

I love it. The easiest race is the one that's already over. It definitely feels like that now. I can already feel my brain rewriting the pain, convincing me it wasn't that bad, even though I know I'm fooling myself. But that self-deception is what makes us do it again. And I will.

The Cult of Caring

Sat, 06 Dec 2025 00:00:00 GMT

Welcome to my sixth post in the Advent of Writing series.

The world isn't divided between geniuses and the rest. It's divided between people who care and people who don't. In one of my tweets/X posts, I declared that I'm founding the Cult of Caring. I'd always felt there was something there, but I never really knew how to express it. Grant Slatton's blog, Nobody Cares, really nailed it and helped me dress my thoughts and feelings in words.

As Grant lays out, plenty of things in the world just suck. The DMV, Jira, most public transportation, etc. And the thing is, most of these could be excellent with just a little more effort. But they're not, because nobody cares enough to make that effort.

To hammer the point home, here's a wonderful quote from Tobias Lütke, CEO & Co-Founder of Shopify:

The quality at the end of the day is simply a reflection of how much the people who created it gave a shit about the product.

I strongly subscribe to valuing quality. Honestly, I don't really know why. Maybe it's guilt, or maybe I simply don't find it fun to work on things where I can't go all in and really hone them.

Anyway, here's my thesis. It's biased toward building software, but you can generalize it.

If you want to be in the top 1% of anything, you have to start by caring. Skill, talent, a good education, or other circumstantial advantages give you a decent foundation. But beyond that, you need persistence and caring. Show up every day and let it compound. When you feel like you're done, ask yourself: Can I add a tiny polish that makes this even 1-2% better? But note, caring and grinding aren't the same thing, which brings me to my next point.

Caring comes from having honest empathy for the person using your product. Grinding doesn't. Grinding is effort without intention. Caring is intention that shapes effort. You put in five more minutes because you genuinely want someone to have a good experience. You care how they'll feel when they use what you built. Simultaneously, caring doesn't mean perfectionism. It doesn't mean burnout. It means refusing to ship something you wouldn't enjoy using yourself.

Caring makes you cut the bullshit. It forces you to focus on what matters and prioritize brutally. You're aiming for greatness in one area, so drop the distractions. Do one thing and do it well. The rest won't matter. Look at Google or now ChatGPT: one box, one input, no distractions.

Now, I'm not perfect. I don't live by these principles 100% of the time, unfortunately. But this mindset is something I strive toward. Could I have pushed more on this blog post and made it even better? Probably. Use your common sense and keep things in balance and perspective.

Tomorrow, whatever you do, do it with care. That's how the Cult of Caring grows.

Compiling Zig to RISC-V

Fri, 05 Dec 2025 00:00:00 GMT

In my second Advent of Writing post I described the reading group we have where we learn to build performant components used in neural networks to run on a small RISC-V computer.

So far I've just booted it, but now let's look at actually running some code on it. Most of the examples out there are C, so I thought I'd take on the challenge of using Zig instead to see what it's like. Turns out, getting some basic things working is super easy.

For this, I'm using Zig version 0.15.2. If you're using older versions of Zig, things might look different.

The first thing is to create a repository and run zig init to get the basic scaffolding. We're doing a simple ReLU, and after changing some file names, this is what I have:

tree
.
├── build.zig
├── build.zig.zon
└── src
    ├── main.zig
    └── lactose
        ├── nn
        │   └── relu.zig
        └── root.zig

Since we're using the Milk-V Duo, the name of my neural networks library will naturally be Lactose.

As a quick reminder before we dive in, this is the ReLU function: if the value x is greater than 0 we leave it be, otherwise we set it to zero.

So in code the relu.zig would be:

pub fn relu(comptime T: type, x: []T) void {
    for (x) |*elem| {
        if (elem.* < 0) elem.* = 0;
    }
}

Nice!

Now our root.zig just exports this function like so:

pub const relu = @import("nn/relu.zig").relu;

And we can write an executable which uses this ReLU function on a slice. Something like this:

const std = @import("std");
const lactose = @import("lactose");

pub fn main() !void {
    var prng = std.Random.DefaultPrng.init(42);
    const rand = prng.random();

    var data: [512]f32 = undefined; // 1K floats

    for (&data) |*x| {
        x.* = rand.float(f32);
    }

    lactose.relu(f32, &data);

    std.debug.print("{any}\n", .{data});
}

I've also made my build.zig file very convenient so that I can just run zig build and it does all the correct things for me. Honestly, the build file is probably where I spent most of my time. Since it's quite long, I'll just leave it here so you can inspect it later if you want. Note that some of the choices I've made are dependent on how I set up my Milk-V Duo. For example, if you're using libc instead of musl, you'll need to change that.

Click to view the full build.zig

const std = @import("std");

pub fn build(b: *std.Build) void {
    const target = b.standardTargetOptions(.{
        .default_target = .{
            .cpu_arch = .riscv64,
            .os_tag = .linux,
            .abi = .musl,
        },
    });
    const optimize = b.standardOptimizeOption(.{});
    const mod = b.addModule("lactose", .{
        .root_source_file = b.path("src/lactose/root.zig"),
        .target = target,
        .optimize = optimize,
    });

    const exe = b.addExecutable(.{
        .name = "main",
        .root_module = b.createModule(.{
            .root_source_file = b.path("src/main.zig"),
            .target = target,
            .optimize = optimize,
            .imports = &.{
                .{ .name = "lactose", .module = mod },
            },
        }),
    });

    b.installArtifact(exe);

    const run_step = b.step("run", "Run the app");

    const run_cmd = b.addRunArtifact(exe);
    run_step.dependOn(&run_cmd.step);

    run_cmd.step.dependOn(b.getInstallStep());

    if (b.args) |args| {
        run_cmd.addArgs(args);
    }

    const mod_tests = b.addTest(.{
        .root_module = mod,
    });

    const run_mod_tests = b.addRunArtifact(mod_tests);

    const exe_tests = b.addTest(.{
        .root_module = exe.root_module,
    });

    const run_exe_tests = b.addRunArtifact(exe_tests);

    const test_step = b.step("test", "Run tests");
    test_step.dependOn(&run_mod_tests.step);
    test_step.dependOn(&run_exe_tests.step);
}

Anyhow, simply running zig build gives me the main executable which I can copy into the Milk-V with this command: scp zig-out/bin/main root@192.168.42.1:/root/

And ssh:ing to the Milk-V, voilà:

Now to understand if this is performant or not, one crucial part is to analyze the assembly. Did the compiler generate something clever or naive for us? You can run something like riscv64-elf-objdump -d -C -S zig-out/bin/main to disassemble the binary. It's quite messy, so I recommend piping it into a text file.

If you search for “relu” and hit enter a few times you should be able to find our function looking something like this:

pub fn relu(comptime T: type, x: []T) void {
 1080f04:	715d                addi	sp,sp,-80
 1080f06:	e486                sd	    ra,72(sp)
 1080f08:	e0a2                sd	    s0,64(sp)
 1080f0a:	0880                addi	s0,sp,80
 1080f0c:	852e                mv	    a0,a1
 1080f0e:	fca43023          	sd	    a0,-64(s0)
 1080f12:	fcc43c23          	sd	    a2,-40(s0)
 1080f16:	fcb43823          	sd	    a1,-48(s0)
 1080f1a:	4501                li	    a0,0
 1080f1c:	fea43023            sd	    a0,-32(s0)
 1080f20:	fcc43423          	sd	    a2,-56(s0)

And that's the start of the function.

Now this isn't optimized at all, we compiled with Debug. A few things that stand out without going too deep:

The first instruction allocates 80 bytes for us on the stack; we don't really need that much.
Second is that there's a lot of register spill and redundant operations. Meaning that we're moving and storing a lot of stuff in memory which could have lived in the registers.

Here for example we're storing the same thing twice in memory 🤷‍♂️

1080f12:    fcc43c23    sd a2, -40(s0)
…
1080f20:    fcc43423    sd a2, -56(s0)

Then later on the loop itself is very unoptimized, but I'll get to that in another post!

This ended up being just a scratch on the surface, but at least it's an end-to-end example. Hopefully, this helps you if you're building on RISC-V machines as well. In some upcoming post, I'll need to go more in-depth into the assembly and how to optimize this ReLU function.

Happy hacking!

People believe in Secrets

Thu, 04 Dec 2025 00:00:00 GMT

Chapter 8 of Zero to One opens with a striking line:

Most people act as if there were no secrets left to find.

If you've read the book, you know how central “secrets” are to Peter Thiel's worldview. His famous question: “what valuable company is nobody building?”, rests on the assumption that hidden truths still exist. Every major breakthrough once began as a secret: the Pythagorean theorem, the abolition of slavery, and countless others.

But the book was written in 2013-14, and the world has changed dramatically since then. I think it's time to revisit the chapter. My intuition is that more people today do believe in secrets again.

Thiel and Masters lay out five reasons why society stopped believing that hard secrets remain. Let's walk through them one by one.

1. Geography

The first argument is that the age of exploration is over. The world has been mapped; the frontier is closed; “the unknown seems less accessible than ever”.

My counterargument today is straightforward and stupidly simple: space.

Space travel has become cheaper, more frequent, and more culturally relevant since 2014. Reusable rockets land themselves. Mainstream news outlets livestream SpaceX launches. Companies are building data centers in orbit. We're exploring again.

2. Incrementalism

Incrementalism is the idea that progress happens step-by-step: grade by grade, rung by rung. In many ways, that still describes how schools, universities, and careers work.

The rise of AI is the clearest counterpoint. One day, essentially overnight, society gained access to a chat interface that wasn't an incremental improvement on existing tools; it was a fundamentally new kind of technology. This sort of leap breaks the incrementalist worldview entirely.

3. Risk aversion

Most people are risk-averse, and that's probably fine for the human species as a whole.

But the landscape of risk has changed dramatically in my opinion. Since 2014, we've lived through multiple shocks: COVID-19, the war in Ukraine, and a general geopolitical realignment. These events revealed just how fragile many of our institutions are. Systems we assumed were stable turned out to be brittle.

Risk and disturbances often reopen the search for secrets.

4. Complacency

This one is probably still mostly accurate. Many people continue to assume that the path to a good life is fixed: get into a respected university, follow a predictable career, secure stability.

But I'd like to hope that things like AI have shaken the ground a little bit. It's harder now to believe that the world is fully known or that your future is guaranteed by simply getting into an elite institution.

5. Flatness

The argument of flatness is that as the world globalizes and becomes a talent pool of similar people, why bother trying to find something new? There's most likely someone brighter than you already figuring it out.

Again, this ties to the global situation. I think we've somewhat reverted from the path of globalization we expected to have in 2014. There are again Cold War-style dynamics of "us vs them." Which nation wins the AI race? Who can produce the best hardware?

You should believe in secrets

Maybe these are reasonable arguments. Or maybe I'm simply optimistic. I hope to see people believing in secrets. And I think you should. Remember the excitement around the alleged room-temperature superconductor LK-99? And self-driving cars: it seems so close, but still far from solved.

There's tons of gold to mine for the one who wants to search.

A pool of infinite opportunities.

A world filled with secrets to uncover.

It's time

Wed, 03 Dec 2025 00:00:00 GMT

Today I'm writing post of Day 3 in the Advent of Writing challenge. Honestly, I don't have much to say today, so I'll keep it short and concise.

One of the suggested topics was “Write about one key photo, code snippet, graph, etc., and make a story about it.” Instead, I'll go with a quote from one of Paul Graham's blogs, “Life is Short”:

Having kids showed me how to convert a continuous quantity, time, into discrete quantities. You only get 52 weekends with your 2 year old. If Christmas-as-magic lasts from say ages 3 to 10, you only get to watch your child experience it 8 times. And while it's impossible to say what is a lot or a little of a continuous quantity like time, 8 is not a lot of something. If you had a handful of 8 peanuts, or a shelf of 8 books to choose from, the quantity would definitely seem limited, no matter what your lifespan was.

To me, the core message of his essay is this: finiteness sharpens value.

But not all finiteness is obvious or predictable. Some things, like how many Christmases are left or how many holidays you'll have with a loved one, can more or less be estimated. Others end abruptly and without warning. You rarely realize, for example, when it's the last time your child falls asleep on your chest, or the last time a friend lives in the same city. These “last times” only become clear in retrospect.

We shouldn't also be discouraged by the fact that valuable moments are finite. There might only be 8 Christmas-as-magic times, but you have all the power in the world to produce more of similar events. Similarly, if everything is precious, nothing is. Don't be afraid of scarcity.

We also shouldn't be discouraged by the fact that valuable moments are finite. There might only be eight “Christmas-as-magic” years, but you have the power to create new rituals just as meaningful. Scarcity heightens appreciation, but it doesn't have to create anxiety. If everything is precious, nothing is. Don't be afraid of scarcity.

Now my question to you is: what do you want to do today?

Hacking on small computers

Tue, 02 Dec 2025 00:00:00 GMT

Today's suggested topic for the Advent of Writing challenge was “A tech or concept you've postponed learning”. Quite perfectly, I've been part of a small reading group with a bunch of colleagues focused on understanding computer performance. We decided to ditch the book and instead get practical. We all ordered Milk-V Duo 256M (or equivalent) boards and decided to build up the fundamental blocks of neural networks on this device.

As it happens, mine arrived in the mail today. So let's boot it up together. Here's a small picture of it. It's literally the size of my thumb.

The Milk-V Duo 256M board is a small, Linux-capable SoC board. So it's not a microcontroller. This thing actually runs Linux; you can ssh into it and so on. It also has a 1 TOPS-class neural processing unit! 👀

So, the setup. It was a bit gnarlier than I'd wanted, but in the end, pretty smooth.

First, we need to flash a micro-SD with the OS. Grab a release from here: https://github.com/milkv-duo/duo-buildroot-sdk-v2/releases/. I used the milkv-duo256m-musl-riscv64-sd_v2.0.1.img.zip. Unzip it, and let's move on. You can also choose to use arm64 with glibc, but in my case we're learning risc-v in our reading group, so that's the motivation for my choice.

Note that this setup is specific to a Mac since that's what I'm using. Connect the SD card to your laptop and find it with:

diskutil list

This will give something like:

/dev/disk8 (external, physical)
#:

Which is the SD card. Then unmount it:

diskutil unmountDisk /dev/disk8

and run:

sudo dd if=milkv-duo256m-musl-riscv64-sd_v2.0.1.img of=/dev/rdisk8 bs=4m status=progress

and eject the card:

diskutil eject /dev/disk8

I made the mistake of not properly ejecting this, and it led to some really hard-to-debug situations 😅

You can also reinsert the card and run diskutil list again, which should show you something with FDisk_partition_scheme etc.

Cool, now put the SD card into the Milk-V and plug it into your computer. Again, a pro tip: make sure your USB-C cable supports data transfer and isn't just a power cable. Luckily, I keep a box at home where I've stored every cable since my teenage years, so I naturally had one.

After this, you should see a blue light popping up and blinking. If you only see a red light, Linux isn't booting correctly, and you need to go back to the previous step to figure out what you did wrong.

The device should be now accessible just through ssh:

ssh root@192.168.42.1

The password is always by default milkv.

If you're successful, you should now see this in your terminal:

[root@milkv-duo]~#

Congratulations 🎉

Next, let's run something on it. Since it's a small device, it's advised to do all the development on your main machine, cross-compile, and just move the final binary to the Milk-V. Thankfully, the Milk-V Duo crew have made it quite easy to do this. Let's do a quick example!

Edit: Later on I learned that Zig ships with a risc-v toolchain, so you can just do zig build -Dtarget=riscv64-linux-musl and it'll work on the Milk-V.

I cloned the https://github.com/milkv-duo/duo-examples repo and used it to get running. Note that these are for x86 Linux, so if you use a Mac like me, you'll need to set up your environment in Docker. No problem. CD into the duo-example and run something like:

docker run --platform linux/amd64 -it -v /Users/youname/…/testing/duo-examples:/work  ubuntu:22.04 /bin/bash

This will create a running docker container and let you mount the examples directory into it, neat.

From there, you'll need to run apt-get update and apt-get install -y wget git make to have the basics in the docker container.

Now there's a nice setup script for you so you don't need to understand the nuances of the toolchain. The readme is also really good here. But in short run:

source envsetup.sh

And choose 2 and 2 when prompted. Now you should have the correct toolchain installed to be able to cross compile programs for the Milk-V Duo!

Let's do the hello world! Run cd hello-world and run make. This compiles the helloworld executable for you, and you can copy it to the Milk-V by running scp helloworld root@192.168.42.1:/root/.

Go back, or ssh again, to your Milk-V, and now you should be able to find the program and run it ./helloworld Which gives you:

[root@milkv-duo]~# ./helloworld
Hello, World!
[root@milkv-duo]~#

And that's it 😄👍

But let's do something extra. After all, we want to do some neural network stuff on this machine, so why not do a small dot product? In the root of the duo-examples dir I've made a directory called dotprod and wrote this small program:

#include <stdio.h>
#include <stddef.h>

static int dot_product(const int *lhs, const int *rhs, size_t len) {
    int sum = 0;
    for (size_t i = 0; i < len; ++i) {
        sum += lhs[i] * rhs[i];
    }
    return sum;
}

int main(void) {
    const int vector_a[] = {1, 3, -2, 4, 5};
    const int vector_b[] = {4, -1, 0, 7, 2};
    const size_t length = sizeof(vector_a) / sizeof(vector_a[0]);

    if (length != sizeof(vector_b) / sizeof(vector_b[0])) {
        fprintf(stderr, "Vector length mismatch\n");
        return 1;
    }

    int result = dot_product(vector_a, vector_b, length);

    printf("Dot product: %d\n", result);
    return 0;
}

And the accompanying Makefile:

TARGET=dotprod

ifeq (,$(TOOLCHAIN_PREFIX))
$(error TOOLCHAIN_PREFIX is not set)
endif

ifeq (,$(CFLAGS))
$(error CFLAGS is not set)
endif

ifeq (,$(LDFLAGS))
$(error LDFLAGS is not set)
endif

CC = $(TOOLCHAIN_PREFIX)gcc

SOURCE = $(wildcard *.c)
OBJS = $(patsubst %.c,%.o,$(SOURCE))

$(TARGET): $(OBJS)
	$(CC) $(CFLAGS) -o $@ $(OBJS) $(LDFLAGS)

%.o: %.c
	$(CC) $(CFLAGS) -o $@ -c $<

.PHONY: clean
clean:
	@rm *.o -rf
	@rm $(OBJS) -rf
	@rm $(TARGET)

But simply cd:ing to the directory, running make, and again copying it to the Milk-V, I can do some simple dot products on the device:

Neat! This is it for today. Maybe this is useful for you if want to dive into this stuff as well, maybe not 😄

Why I'm joining this challenge

Mon, 01 Dec 2025 00:00:00 GMT

I'm joining this challenge for two reasons: a few deeply held beliefs about communication, and a spontaneous fuck-it-why-not impulse.

Tl;dr:

Being a really good communicator, written and spoken, is extremely valuable.
You can become a great communicator simply by practicing.
I've wanted to write more for years but never managed to stick with it. Maybe this time will be different.

Writing is one of those obviously good things everyone knows they should do, yet most people don't. It's like living a healthy lifestyle: knowing what to do and actually doing it are two completely different worlds.

The first thing people overlook is that writing follows a power law: one with massive, uncapped upside and basically no downside. Once you publish something online, it stays there. It gathers views for years. You write once, and the benefits compound like interest.

Most pieces get a handful of readers, some get a bit more, and a tiny fraction get almost all the attention. Again, a power law. If you know how they work, you now realize now important it is to put your writing out there. If you don't, you should watch this Veritasium video to get a better intuition of what happens in a game governed by a power law.

The second overlooked point is how much writing improves your thinking. Even as I'm writing this out, I'm already questioning I arguments made a paragraph earlier. It is ridiculously easy to fool yourself. Writing gives you a third-person perspective on your thoughts, a way to take distance and scan them. Do it. You'll refine your ideas, thoughts, and feelings. Btw this is also why writing is so central in successful organizations; Stripe and AWS are famous for it.

Finally, you just have to get over the embarrassment of sharing your thoughts publicly. A challenge like this helps. It feels awkward, what if I say something stupid? But honestly, who cares? You're almost always your own harshest critic. So push yourself. Do it. And once it's done, you'll be glad you did.

Honesty

Tue, 22 Aug 2023 00:00:00 GMT

Let's do a test.

This only works if you're 100% honest with yourself.

Can you tell your colleague or boss that they've done a bad job?

And I don't mean the trivial "could you improve on some random trivial thing". I mean giving really difficult, you-didn't-do-well-at-your-work type of feedback.

Getting real & honest feedback from your peers isn't a humanitarian right. It's a privilege. For others to be able to give you real & honest feedback, they have to trust you. They have to be 100% sure that you can take it. That you won't hold a grudge. That you won't get defensive. That you're actually able to take in the feedback and are capable of having a civilised discussion.

Ergo, you can't force a culture of honesty. Companies that schedule sessions of "let's all give constructive feedback" miss the point. They are likely to have sessions of people giving feedback in the form of made-up petty items. Not real feedback. Because by giving & receiving real & honest feedback, you are making yourself vulnerable. Most likely people won't do that just because HR says so.

Real & honest feedback isn't some barbaric roast, it's a deeper form of care for another. Your friend is a reckless driver. You worry the manoeuvres might one day become detrimental. You voice this concern even tough your friend finds this annoying. Because you care.

It's a silly example but hopefully the message comes through.

A leader isn't someone who gives people orders. A leader is someone who elevates other people to their maximum potential and beyond. Such growth can only be achieved by giving others real & honest feedback.

Focus

Mon, 21 Aug 2023 00:00:00 GMT

People say that startups should have a very narrow focus. Like do one thing - and one thing only - and do it well. People know this but fully internalising it is hard. It should be done:

Like this.