DEV Community: Javier Leandro Arancibia

My database claimed crash-safety. `kill -9` proved nothing.

Javier Leandro Arancibia — Wed, 29 Jul 2026 18:19:04 +0000

I have a small document database called grange. Its README said "crash-safe by construction", and there was a harness to back it up: kill the writer with kill -9 mid-flight, reopen, assert the database holds exactly a committed prefix. Five rounds, every build, green.

That harness proves less than it looks like it proves.

What `kill -9` actually tests

When you kill -9 a process, the kernel reclaims it — but everything the process wrote with write(2) is already in the page cache, and the kernel flushes it to disk afterwards on its own schedule. The data survives because the operating system survived.

A power cut is different. So is a kernel panic. There, the page cache goes with the machine, and anything not yet on the platter is gone.

My database called write_file and returned success. Nothing anywhere called fsync. So a commit that had been acknowledged — the client got its {"ok":true} — could vanish. The harness could never have caught it, because the failure mode it simulates is the one the page cache is immune to.

The README even said so, in a line I'd stopped reading:

Durability is process-crash-exact (proven by make crash), OS-crash best-effort.

That sentence is true and completely insufficient. "Best-effort" is doing a lot of work there.

Two fsyncs, not one

The fix is fsync, and the part that's easy to get wrong is that one call isn't enough.

write_file(path, data)
fsync(path)        // the file's CONTENTS are durable
fsync(dirname)     // the file's EXISTENCE is durable

Creating a file is a modification of its directory. You can fsync a file perfectly and still lose it after a crash, because the directory entry naming it never reached the disk. The second fsync is the one people skip.

A directory has to be opened O_RDONLY for this — opening it for writing fails with EISDIR.

Testing something invisible

Here's the awkward part: fsync is invisible to behavioural tests. A build that silently dropped every fsync call would pass my entire test suite. Same answers, same recovery, same everything — right up until the power goes out.

So the test doesn't check behaviour. It checks syscalls:

strace -f -e trace=openat,fsync ./db put ...

then asserts the ordering: the chunk is fsynced, then its directory. And on the disk-resident path, that every data page is fsynced before the manifest that references it — because "write the manifest last" is only meaningful if that ordering is real on the platter, and the kernel is free to reorder write() calls on the way there.

The third check is the one I'd encourage you to steal: the opt-out (FSYNC=0) must issue zero fsyncs. That doubles as the harness's own negative control. A test that can't fail is decoration, and a test asserting the presence of something invisible needs to prove it can detect the absence.

What it costs

Measured, on a commit:


single-document commits	~1.9 ms each — about 31% slower
a 10,000-document batch	21 ms vs 23 ms — noise

That shape is why it's on by default. A batch is one commit, so durability amortises to roughly nothing on the workload that actually moves volume. The per-commit case pays, and that's the honest price of the guarantee.

What I still can't claim

The device might be lying. Consumer drives with volatile write caches can acknowledge an fsync that's still in flight, and no test running on that machine can tell. So the docs now say: fsync is called, the ordering is asserted, and whether your hardware honours it is not something this project can prove.

That felt more useful than upgrading the marketing adjective.

The general lesson

The harness wasn't wrong. It tested a real failure mode, correctly, and it still passes. It just wasn't testing the failure mode the word "crash-safe" makes people imagine — and the gap between those two things sat in my README for months, written down, in a sentence I'd read so many times I stopped seeing it.

If you have a durability claim, go and check what your test kills. kill -9 and "pull the plug" are not the same experiment.

grange is MIT, a single static Linux binary, and usable either as a server or compiled into your own program: github.com/javimosch/grange. v0.11.0 also brings ordered queries, keyset pagination and field projection.

I built a 100 KB git-like VCS that beats git on `add && commit`

Javier Leandro Arancibia — Sun, 26 Jul 2026 05:42:26 +0000

I love git. I also spend a lot of time automating things, and every time a script needs to snapshot some files I end up wrapping git with brittle flags and parsing porcelain output. So I wrote lume: a tiny, content-addressed version control system in machin/MFL.

lume is git-like, not git-based. It uses blobs, trees, commits, refs, and HEAD, but the storage, object format, and HTTP protocol are built from scratch. The whole thing compiles to a single 100 KB native binary.

The benchmark that surprised me

I compared the one workflow every developer repeats all day:

lume add . && lume commit -m "x" → ~15 ms
git add . && git commit -m "x" → ~17 ms

On 110 small files, lume is faster. The lume binary is ~36× smaller than git (100 KB vs 3.7 MB), and the .lume metadata is within 2% of .git.

Where the speed comes from

The biggest win was replacing the SQLite staging index with a line-delimited file. lume add now builds a small tab-separated string and writes it once. Object subdirectories are created lazily, and blobs use a hand-rolled JSON fast path instead of generic serialization.

HTTP push / pull / clone out of the box

lume serve starts a tiny HTTP object server. push, pull, and clone speak plain JSON-over-HTTP. No SSH keys, no pack negotiation, no stateful transport.

What's next

Merge, rebase, and diff are still missing, and the tooling is Linux-oriented right now. But the core agent loop — init, add, commit, push, pull, clone — is fast enough to run behind automation without the automation ever knowing it is talking to a VCS.

I wrote a longer post with the architecture and numbers on the Intrane blog.

Source, benchmarks, and build instructions are on GitHub: github.com/javimosch/lume

rcmd now speaks MCP — your AI agent can manage your servers without SSH

Javier Leandro Arancibia — Sat, 18 Jul 2026 19:28:44 +0000

I've been building rcmd, a relay-based remote command tool. No SSH keys, no open ports — your servers connect out to a relay, and you send commands through it.

Today I shipped the thing I've wanted since day one: an MCP server.

What is MCP?

Model Context Protocol is the standard way AI agents (Claude Code, Cursor, Windsurf, Devin) call external tools. Instead of shelling out to ssh user@host "df -h" and parsing text, the agent calls a structured tool and gets JSON back.

What rcmd's MCP server exposes

Four tools:

rcmd_list_targets — list your configured servers
rcmd_exec — run a command on a remote server, get stdout/stderr/exit code/duration
rcmd_cp — copy a file to a remote server
rcmd_health — check if a server is reachable + latency

How to set it up

Install rcmd and configure a target:

rcmd add-target --name prod --token <token>

Add rcmd as an MCP server. For Claude Code (~/.claude/mcp.json):

{
  "mcpServers": {
    "rcmd": {
      "command": "rcmd",
      "args": ["mcp"]
    }
  }
}

Same config for Cursor (.cursor/mcp.json) and Windsurf (~/.codeium/windsurf/mcp_config.json).

That's it. Your AI agent can now run commands on your servers.

What this looks like in practice

You ask Claude: "Check disk space on prod"

Claude calls rcmd_exec with {"target": "prod", "command": "df -h"} and gets:

{
  "target": "prod",
  "command": "df -h",
  "stdout": "Filesystem      Size  Used Avail Use% Mounted on\n/dev/vda1       40G   28G   11G  73% /",
  "exit_code": 0,
  "duration": "142ms",
  "success": true
}

No SSH parsing. No "which server was that again?" No key management.

Why this matters

I built rcmd because SSH is friction for AI agents:

Keys need to be on the right machine
Firewalls block inbound ports
NAT makes connecting impossible without a VPN
Parsing terminal output wastes tokens

rcmd's daemon connects out to a relay. No inbound ports. No keys on the agent's machine. The MCP server reads your local rcmd config and handles the rest.

The agent never sees your tokens. It only sees target names. All traffic goes through the relay with token-based auth.

Self-host or use the hosted relay

The relay is open source (MIT). You can self-host it in 5 minutes — one binary, one port, done. Or use the hosted one at rcmd.intrane.fr for €5/mo.

Full self-hosting guide: https://github.com/javimosch/remotecmd-cli/blob/main/docs/self-hosting.md

MCP server docs: https://github.com/javimosch/remotecmd-cli/blob/main/docs/mcp-server.md

What's next

More MCP tools (cron management, tunnel setup, team operations)
Resources (expose server state as MCP resources, not just tools)
Streaming output for long-running commands

The binary is ~6MB, single file, no dependencies. Linux + macOS, amd64 + arm64.

# Download from GitHub releases
# Or: curl -sSL https://github.com/javimosch/remotecmd-cli/releases/latest | ...

GitHub: https://github.com/javimosch/remotecmd-cli

rcmd is agent-first infrastructure. Every command returns structured JSON. Every feature is designed to be called by an AI, not just a human. The MCP server is the natural endpoint of that design.

Web Analytics With No Dashboard (But There Is a 3D Globe)

Javier Leandro Arancibia — Sat, 18 Jul 2026 18:27:07 +0000

I built vigie — cookieless web analytics where the primary consumer is an AI agent, not a human staring at charts.

The premise

Every privacy-first analytics tool (Plausible, Fathom, Rybbit) assumes a human logs into a dashboard. My team is agents: they write the code, send the email, file the issues. They need analytics they can query and act on — JSON on stdout, semantic exit codes, a machine-readable API.

vigie stats overview --site example.com --since 7d
# {"ok":true,"data":{"pageviews":1234,"visitors":410,"bounce_rate_pct":38,...}}
vigie stats cities --site example.com     # geo down to city + coordinates
vigie stats journeys --site example.com   # the sankey, as JSON
vigie stats vitals --site example.com     # LCP/FCP/CLS/INP/TTFB p50/75/90

When a human needs to see it

The dashboard is an artifact: vigie snapshot --publish renders every metric (22 sections — journeys, channels, heatmap, vitals, errors, geo to city…) into one self-contained HTML page and publishes it to an artifact host. Regenerated on a timer, never stale, no frontend server to run. Fully-populated demo report here (synthetic data, labeled).

And one indulgence: your traffic as a living 3D globe — hand-rolled canvas math, city-level dots, repaints itself from the live feed. Zero JS frameworks.

The interesting constraints

Cookieless by construction: visitor = sha256(secret + day + site + ip + ua), daily salt rotation, raw IP never stored. Nothing to consent to.
Agents are users too: vigie track --name deploy --actor ci records server-side events — your cron job is a first-class analytics stream.
One ~300 KB binary (HTTP ingest + SQLite + stats engine + globe renderer + CLI), written in MFL, no Node/ClickHouse/Docker.
Geo without a SaaS: a MaxMind-DB (.mmdb) reader written from scratch in MFL, reading DB-IP City Lite (CC BY). ~300 lines for the binary tree walk + data-section decoder.

An agent built the whole thing in a day, and found three compiler bugs in the process — including string literals silently corrupted by C trigraph processing (?? became ^ in the globe JavaScript, surfacing as a browser SyntaxError three layers away).

Full story: https://blog.intrane.fr/analytics-with-no-dashboard
Repo (MIT): https://github.com/javimosch/vigie

I built a database my AI agent can pay for (and it beat SQLite)

Javier Leandro Arancibia — Sat, 18 Jul 2026 13:03:35 +0000

Every database assumes a human shows up eventually — to create the account, paste a card, click through a console. AI agents can't do any of that. So I built grange: a document database where a payment wallet is the signup.

curl -X POST https://grange.intrane.fr/tenants -H 'X-Peage-Wallet: pw_...' -d '{"name":"my agent"}'
# -> {"tenant":"t...","token":"gt_..."}   your isolated, metered namespace

Pricing is pay-as-you-go: €0.15/GB/month above 50 MB free, queries free, billed continuously through péage — no subscription, no card on file, no human in the loop.

The engine

grange is written in machin, my language for AI agents, and two properties fell out of the language rather than being engineered in:

Crash-safe by construction. The language has no file append or rename, so every commit is one immutable, sha256-trailered WAL chunk. kill -9 at any moment leaves exactly the committed prefix — the repo ships the harness that proves it.
Race-free by proof. The server is a single actor with zero goroutines, and machin's inferred data-race analysis verifies the whole engine on every build. No Send/Sync, no annotations.

The benchmark (100k docs, both engines indexed, same box)

workload	grange	SQLite
bulk insert, 2 indexes maintained	278k docs/s	25k rows/s
indexed count × 1000	<1 ms	1.5 s
group-by count/sum/avg × 1000	<1 ms (write-time registers)	49 s
range count × 1000	<1 ms	257 ms

The aggregate rows aren't typos: declare --sums on an index and grange maintains per-group count/sum/avg at write time — a group-by answer costs a map lookup. The one row SQLite wins (unindexed full scan, 8ms vs 61ms) is in the README too, because a benchmark you can't lose is marketing, not measurement. make bench reproduces everything.

Dogfooding found three compiler bugs in one day

This is why I build real things in my own language. The first bench ran 70× slow — stale compiler binary, maps were O(n). The billing math went negative — integer literals compiled to bare C constants and 30 * 86400000 overflowed in 32-bit before widening. A WAL tombstone turned to garbage — keys(map) aliased internal storage that delete() freed: a use-after-free handed to me by a failing test. All three fixes went back into the language.

For humans: client SDKs

Agents speak curl; humans expect drivers. So: Node.js (npm i grange-db), Go (go get github.com/javimosch/grange/sdk/go), and machin. Same surface: db("crm").coll("leads"), put/get/find/count/agg, bulk writes at 263k docs/s over HTTP.

The full story is on my blog: grange: A Database Your Agent Can Pay For. The contract, written for agents: grange.intrane.fr/llms.txt. MIT, one binary, no lock-in.

rcmd: I replaced SSH with a relay — now my AI agents manage my servers

Javier Leandro Arancibia — Sat, 18 Jul 2026 03:51:56 +0000

I run a small infrastructure. A few VPS, some Proxmox boxes, a Raspberry Pi. Every time I needed to run a command on a remote machine, it was the same ritual: SSH key, port, firewall, VPN if the box is behind NAT. And my AI agents? They couldn't do any of it without me handing them SSH keys or setting up tunnels.

So I built rcmd — a zero-config remote command execution tool. No SSH keys, no open ports, no VPN. A WebSocket relay brokers connections between your machine and remote targets. The daemon on the target connects outbound. You run the CLI. The relay routes the command.

You ──wss──► relay ──wss──► target daemon (runs your command, returns output)

What shipped this week

Scheduled commands (cron)

rcmd cron add --target prod --schedule "0 3 * * *" --cmd "docker restart app"
rcmd cron list
rcmd cron logs --id <job-id>

The relay runs a scheduler goroutine. When a job fires, it forwards the command to the target daemon. If the target is offline, the run is logged as "skipped" — no retry queue, the next tick tries again. History persists across relay restarts.

This replaces the crontab + SSH + monitoring script combo with one command.

Port forwarding (tunnel)

rcmd tunnel --target db --local 5432 --remote 127.0.0.1:5432

Forwards a local port to a remote address through the target daemon. Replaces ssh -L. Useful for reaching a database or service that's only listening on localhost on the remote machine.

Team access

This is the one I'm most excited about. The problem: one token = full access to all targets. If you want a teammate or an AI agent to run commands, you either share your master token (security nightmare) or set up a separate account (no shared targets).

Now you generate scoped sub-tokens:

# Give an operator access to prod + staging
rcmd team token --role operator --targets prod,staging --label "Bob" --expires 24h

# Bob runs:
rcmd login tok_operator_abc123...
# His access is scoped — he can only touch prod + staging, all audited

Three roles: admin (everything except billing), operator (exec, copy, tunnel, cron on assigned targets), viewer (read-only — list targets, check health, view cron logs).

Every command execution is recorded in the audit log:

rcmd team audit --target prod --since 24h

Email invites

rcmd team invite --email bob@company.com --role operator --targets prod,staging --label "Bob"

Sends an HTML email with a 7-day invite code. Bob clicks the link, sees a page with the accept command and a copy-to-clipboard button, runs:

rcmd team accept inv_5b97e6eeb72d

Gets a scoped sub-token. Done.

Agent-first discovery

This is the part that matters if you're building tools for AI agents. rcmd is designed to be operated by agents, not just humans. So I added three discovery surfaces:

/llms.txt — a short breadcrumb at rcmd.intrane.fr/llms.txt. An AI assistant that only knows the domain fetches this and gets oriented.
/guide — the full operator reference. Every command, every flag, cron scheduling, tunnels, team access, JSON output format, exit codes, gotchas.
rcmd guide — CLI subcommand that prints the same guide locally. An agent on a machine with rcmd installed runs this to learn the full feature surface.

The pattern: an agent finds itself on a machine with rcmd → runs rcmd guide → learns everything. An agent that only knows the domain → fetches /llms.txt → gets pointed to /guide.

Why no SSH?

SSH is designed for humans typing into terminals. It's not designed for:

Agents that need to run commands programmatically and parse output
NAT traversal — if the target is behind NAT, you need a VPN or a jump host
Scoped access — SSH keys grant full shell access; there's no easy way to say "this agent can only restart this one service on this one server"
Audit trails — SSH logs connections, not commands (unless you set up auditd or similar)

rcmd solves these by moving the routing to a relay. The daemon connects outbound (no firewall changes). Tokens are scoped (admin/operator/viewer, target-restricted). Every command is audited. And the CLI is designed for agents — JSON output, semantic exit codes, a guide command that teaches the agent everything it can do.

The stack

Go binary, single file, ~7MB stripped
WebSocket relay (runs on a VPS, behind Traefik + Let's Encrypt)
JSON file storage (no database — teams, cron jobs, audit logs, customers)
Resend for transactional email (team invites)
Stripe for billing (Pro tier)
21 unit tests, all passing

Try it

curl -fsSL https://rcmd.intrane.fr/install.sh | sh
rcmd signup --email you@example.com

The free tier gives you the relay. Pro adds scheduled commands, tunnels, and team access.

Full reference: rcmd guide or https://rcmd.intrane.fr/guide

GitHub: https://github.com/javimosch/remotecmd-cloud

Built by Javier Leandro Arancibia — making infrastructure agent-first, one tool at a time.

I replaced ssh -L with one CLI command. No SSH keys, no VPN, no open ports.

Javier Leandro Arancibia — Fri, 17 Jul 2026 11:56:31 +0000

If you manage servers, you've done this a thousand times:

ssh -L 5432:localhost:5432 user@prod-server

It works. But it requires SSH keys, an open port 22, a VPN if you're behind NAT, and a running SSH daemon on the target. Every one of those is a maintenance burden and an attack surface.

I just shipped rcmd tunnel — port forwarding through a WebSocket relay. No SSH, no VPN, no open ports.

How it works

Your laptop ──wss──► Relay ──wss──► Target daemon ──► localhost:5432

The target runs a tiny daemon (~6 MB Go binary) that connects outbound to a relay. Your client connects to the same relay. The relay routes TCP data between them. That's it.

Both sides connect outbound. No inbound ports. Works behind NAT, firewalls, corporate proxies.

The command

rcmd tunnel --target prod --local 5432 --remote localhost:5432

Now localhost:5432 on your machine tunnels to prod:5432. You can connect with psql, redis-cli, a browser dashboard — anything that speaks TCP.

What you can tunnel

PostgreSQL — --local 5432 --remote localhost:5432
Redis — --local 6379 --remote localhost:6379
Debug dashboards — --local 8080 --remote localhost:8080
Jupyter notebooks running on a remote GPU box
Internal admin panels behind a firewall
Any TCP service — if it speaks TCP, rcmd tunnels it

But wait, I already have SSH

So did I. Here's why I built this:

SSH requires port 22 open. Every server with an open SSH port is a brute-force target. rcmd's daemon connects outbound — zero inbound ports.
SSH key management is a tax. Rotate keys, distribute them, revoke them, deal with known_hosts pollution. rcmd uses per-target tokens, auto-generated, no files to manage.
SSH doesn't work behind NAT. If your server is behind a corporate firewall or NAT, you need a VPN just to reach it. rcmd works from anywhere — both sides connect outbound to the relay.
SSH isn't built for automation. Parsing SSH output in scripts is fragile. rcmd returns structured JSON for every command — stdout, stderr, exit code, duration. Built for AI agents and CI/CD pipelines.

It's also a remote execution tool

Tunneling is just one feature. rcmd also does:

# Execute a command on a remote machine
rcmd exec --target prod --cmd 'docker ps' --timeout 10

# Run the same command across 10 servers at once
rcmd exec --targets web1,web2,web3,db1 --cmd 'uptime' --format table

# Check fleet health
rcmd list-targets

# Copy files
rcmd cp --target prod --src ./app.tar.gz --dst /opt/app/

Every command returns JSON:

{
  "ok": true,
  "stdout": "CONTAINER ID   IMAGE   ...",
  "exit_code": 0,
  "duration_ms": 42
}

No parsing. No guessing. No wasted tokens when an AI agent uses it.

Self-hosted or hosted

Two ways to run it:

Free (OSS): Self-host the relay on any VPS. Unlimited targets, all features. MIT licensed.
Pro (€5/mo): We host the relay at rcmd.intrane.fr. Automatic TLS, no infrastructure to manage.

Same binary, same features. The hosted version just means you don't run the relay yourself.

Install

curl -sSL https://rcmd.intrane.fr/install.sh | sh

Then either self-host a relay or rcmd signup --email you@company.com for the hosted version.

What's next

Tunnel is the first of three SSH-killer features:

Port forwarding — shipped today
Scheduled commands — rcmd cron add --target prod --cmd 'docker restart app' --schedule '0 3 * * *'
Interactive shell — full PTY sessions, rcmd exec --target prod --pty

The goal is simple: make SSH optional for the 80% of server access that doesn't require a full interactive session.

Links: rcmd.intrane.fr · GitHub (OSS) · Install

Made in France. MIT licensed. Built for AI agents first, humans second.

I ran a 7B Mixture-of-Experts LLM in a language I built — token-identical to fp32

Javier Leandro Arancibia — Thu, 16 Jul 2026 19:01:45 +0000

I've been building machin (MFL), a machine-first language, and using it to write an LLM inference engine with zero dependencies — no PyTorch, no llama.cpp, no BLAS, no Python at runtime. Just a static binary.

The wall

A dense 1B model got me ~20 tok/s on a laptop CPU. That's the ceiling, and it's fundamental: decode speed is set by bytes moved per token, and on weak hardware you're pinned to the memory bus. I built and measured every trick — speculative decoding, int4, contextual sparsity, early-exit, continuous batching. Every one topped out at ~1.35×, because the box is balanced: save bandwidth and you go compute-bound, and vice-versa.

The disruption isn't in the engine. It's in the model.

Mixture-of-Experts

A dense model prices every token at its total params. An MoE decouples quality from speed: only a few experts fire per token. OLMoE-1B-7B is 6.9B total but 1.3B active (top-8 of 64 experts/layer). And since only a handful fire, you mmap the checkpoint and let the OS page cache stream cold experts from disk — total size bounded by disk, not RAM.

It works — and it's exact

I wrote an fp32 numpy reference reading the original weights, and checked my pure-MFL int8 engine against it token for token:

numpy fp32 : The capital of France is Paris. The capital of the United States is Washington
pure MFL   : The capital of France is Paris. The capital of the United States is Washington

12/12 tokens identical. Quantization didn't flip one.

experts	lm_head	size	tok/s
int8	int8	7.65 GB	14.5
int4	int8	4.43 GB	11.2

int8 lm_head buys speed (memory-bound); int4 experts buy footprint. Then I wrapped it in an OpenAI-compatible server — tokenizer and all in pure MFL — and pointed the official openai client at it. Works.

7B-class quality, ~1B speed, on hardware you own, no numeric libraries anywhere.

Full write-up: https://blog.intrane.fr/a-7b-moe-llm-at-1b-speed-in-pure-machin
Code (engine, converters, tokenizer, every dead end): https://github.com/javimosch/machin-colibri

I made my programming language run a 1B LLM at 20 tok/s on a laptop CPU (it beat the reference C by 4x)

Javier Leandro Arancibia — Sat, 11 Jul 2026 16:27:39 +0000

I build machin — a small "machine-first" language that compiles through C, designed for AI agents to write. Its roadmap rule is simple: every feature has to be earned by dogfooding, by building something real that breaks.

So I gave it an unreasonable challenge: run TinyLlama-1.1B on a 4-core laptop CPU at 20 tokens/second, in pure MFL. No FFI. No BLAS. No llama.cpp. The matmul included.

The correctness bar

LLM demos are easy to fake, so speed only counted if greedy decoding stayed token-for-token identical to karpathy's llama2.c (run.c / runq.c). Every optimization below was re-verified with a per-position logits diff against the reference before it counted.

The engine is ~600 lines: RoPE, GQA attention + KV cache, SwiGLU, int8/Q8_0 group quantization, and a from-scratch sentencepiece BPE encoder. (Fun find along the way: llama2.c's HuggingFace export silently breaks on GQA models — n_kv_heads is hardcoded to n_heads.)

The arc: 2.1 → 21.8 tok/s

2.1   naive engine, single thread
2.5   -O3 -march=native on the generated C
6.1   goroutine worker pool (jobs as packed ints over channels)
8.4   peek_i8 (byte loads the autovectorizer understands)
9.9   512-bit vector width
15.7  int8 activations (i8 x i8 dot, half the loads)
21.8  dot_i8 builtin + fused qkv / w1-w3 dispatch

Two lessons worth stealing:

1. Deterministic parallelism is free performance you can trust. Matmul rows fan out to a worker pool as packed-int jobs over channels; each row is computed by exactly one worker, so output is bit-identical at any thread count. I never had to choose between "fast" and "still provably correct."

2. Your accumulator width is your vector width. The language's int is 64-bit — and a 64-bit reduction forces the autovectorizer into half-width lanes. The same loop with an int32 accumulator is 40% faster and inexpressible in the source language. So it became a builtin: dot_i8(a, b, n) — the signed-byte dot product that is to quantized inference what sha256 is to crypto. Plain C inside, zero intrinsics; gcc's autovectorizer does the rest.

Results (TinyLlama-1.1B, Q8_0, greedy)

runq.c -O2 reference (1 thread)      1.67 tok/s
pure-MFL engine (1 thread)           6.8  tok/s   <- 4x the C
6 threads, cold                     21.8  tok/s
6 threads, 200-tok sustained        19.0  tok/s   (91C thermal throttle)

Honest asterisk included: sustained generation on this thermally-limited laptop is 19.0; the same binary holds 21.8 whenever the package is under 60°C, which is what interactive bursts look like.

The part I keep staring at: a garbage-collected-feeling, type-inferred language that compiles through C beat the hand-written reference C by 4x single-threaded — because the compiler emits the loop shapes vectorizers want, and iterating was cheap enough to find them.

Full story with the compiler-internals details: blog.intrane.fr
Engine + reproduction protocol: github.com/javimosch/machin-colibri
The ecosystem: awesome-machin

An AI Agent Audits Your LinkedIn Profile in Public — Here's the Stack

Javier Leandro Arancibia — Tue, 07 Jul 2026 14:33:54 +0000

I shipped a free tool this week: cvboost.intrane.fr. Paste your LinkedIn URL, get a scored audit (6 criteria, diagnosis, action plan). No signup.

The point isn't the audit — it's that an autonomous agent does it in public, and it's a live demo of three things I build.

You can watch the work happen

No spinner-and-a-black-box. Each request becomes a GitHub issue → an agent scores your profile and opens a pull request with the report → a second agent reviews and merges it, no human in the loop → the report is published as a shareable page. Every step is a clickable link on the result page. It's all public: github.com/javimosch/cvboost-audits.

The stack

mago — agents that run companies. The audits are done by autonomous agents that take work from a GitHub repo, ship PRs, and escalate to a human only when needed. A "company" is a repo; here the team is an auditor and a reviewer. BYO model key, runs on your machine. CVBoost is that loop running live on every request.

hart — Claude Artifacts, self-hosted. Each report is a self-contained HTML page published with one CLI call → a live, sandboxed, versioned URL. The "publish this artifact" primitive from claude.ai, unbundled and runnable on your own box, callable from any terminal agent.

machin — one binary, no Node. The whole app — SSR site, reactive WebAssembly UI, and JSON API — is a single static native binary. No Node, no bundler, no node_modules. The browser client compiles to wasm from the same language as the server.

Why free

It's the shop window, not the product: watch an agent do real work end to end, traceably, instead of trusting a landing page. Try it → cvboost.intrane.fr, then open the PR the agent left behind. Full story: blog.intrane.fr/an-ai-agent-audits-your-linkedin-in-public

Your AI Assistant Can Run Your Website Chatbot Now

Javier Leandro Arancibia — Mon, 06 Jul 2026 16:29:30 +0000

I shipped chatsnip this week: a chatbot for your landing page that you install by pasting one script tag — and that your AI assistant operates for you. No dashboard. You never log into anything.

The two sins of chatbot SaaS

The dashboard tax. Every chatbot product ships an admin panel you must learn, configure, and babysit. You wanted answers on your landing page; you got another SaaS subscription to manage.

The token markup. Most resell LLM completions at 5–20x wrapped in "message credits". Your bill scales with your success.

The bet: agents are the new admin panel

If you're reading dev.to in 2026, you probably already have an AI assistant with a terminal — Claude Code, Codex, whatever. That assistant is better at operating software than any dashboard.

So chatsnip has none. After checkout you get a prompt — a block of text you paste to your assistant. It installs a small CLI, interviews you about your product, configures the bot, sets your spend limits, and hands you the script tag. Ongoing ops are one weekly command:

./chatsnip hosted digest -since 7d

→ "37 conversations — 5 support, 1 complaint (contact captured), and a lead named Sam who left sam@dev.io asking for a call about the Pro plan." When visitors show buying intent or frustration, the bot offers a personal founder follow-up and asks for contact info. Those get extracted automatically.

Your keys, your costs

Completions run on your own OpenRouter key (encrypted at rest). Pick any model, see real LLM spend on your own bill, set your own budgets: tokens/day, tokens/visitor, messages/minute. I don't resell tokens, so I have zero incentive to inflate your conversation volume — my price is flat.

Absurdly small, on purpose

The widget is ~6 KB of dependency-free JS — no iframe, no framework, no cookie banner. The entire backend (HTTP server, SQLite, LLM client, billing, CLI) is a single ~240 KB native binary written in machin, a language I've been building for AI agents. Self-hosting means: one file, one command, a €3 VPS.

Pricing

Self-host: $79 one-time (launch price) — binary + a year of updates through your personal install URL.
Hosted: €19/mo, 7-day free trial, 5 chatbots/sites included, +€2/mo per extra.

Full story on my blog: Your AI Assistant Can Run Your Website Chatbot Now — or watch your own assistant set it up at chatsnip.intrane.fr.

The Day My Language Started Compiling Itself

Javier Leandro Arancibia — Wed, 01 Jul 2026 15:42:32 +0000

Update (v0.85.0): it went further — the entire toolchain now self-hosts, not just the compiler. encode, build, and run are written in machin too, so machin rebuilds its own toolchain from source, byte-for-byte identical — a complete bootstrap. selfhost/

A year ago I built a programming language. This year it crossed the line that separates a toy from a real compiler: it started compiling itself.

(That GIF is the real thing — machin compiling its own compiler, then that binary reproducing its own source byte-for-byte.)

That sentence sounds like a party trick. It isn't. It's one of the oldest and hardest proofs in systems engineering — and reaching it, with AI as my pair, is the clearest evidence I can offer of how I actually build software.

First, the backstory

machin is a language I designed for a specific user: the AI agent writing the code, not the human reading it. Zero type annotations, one canonical declaration per line, every design choice measured in tokens — then compiled straight through C to a single native binary. Script-like to write, C-class to run. (I wrote about why in an earlier post.)

For a year it grew the way real tools grow — by being used. Web servers, database drivers, a WebSocket client, crypto, even games. But a language is only as trustworthy as its compiler, and machin's compiler was written in Go. So I asked the question every language eventually has to answer:

Could machin compile itself?

What "compiles itself" actually means

Every serious compiler faces a rite of passage called the bootstrap. You rewrite the compiler in its own language, and then you use the original to compile the new one. If the language is real — expressive enough, correct enough, fast enough — the new compiler works. If it isn't, you find out fast.

The gold standard is the fixpoint:

The original compiler builds the self-hosted one.
That self-hosted compiler compiles its own source into a fresh native binary.
That fresh binary compiles the same source again — and the output is byte-for-byte identical.

When those bytes match, you have proof that isn't a matter of opinion. The compiler has reproduced itself exactly. It stands on its own.

Machin now does this. The whole pipeline — lexer, parser, type checker, and C code generator, about 4,000 lines — is written in machin, and it emits the same machine code as the original compiler down to the byte.

How it was actually built (this is the part that matters)

I don't ship "it works on my machine." I ship proof. So every single stage was built against a byte-diff oracle: the original compiler and the new one were run on the same input and their output compared, character for character, across the entire ecosystem of real programs I'd already written. A stage wasn't "done" until that diff was empty — not on a test case, but on every program in the corpus.

That discipline paid for itself immediately. Building the compiler in its own language stress-tested the language harder than a year of app-building had, and it flushed out three genuine bugs in the original compiler that had been hiding in plain sight — a string-comparison that compared memory addresses instead of contents, a quadratic slowdown in string handling, an escaping edge case in code generation. Each was found because the self-hosted compiler and the reference disagreed by a byte, and I refused to wave it away.

Then the honest numbers. The self-hosted compiler doesn't just work — on the full parse-typecheck-codegen of its own source, it runs at about 0.9× the original's speed. Slightly faster than the compiler that built it. (It didn't start there — the first version was 7× slower, and closing that gap meant finding the real bottleneck instead of the obvious-looking one. It was string building, not the "slow lookups" everyone assumes.)

Why I'm telling you this

Because this is what I mean when I say I build with AI.

Not "I prompted a chatbot and shipped whatever came out." The opposite. AI was the engine, but the engineering — the oracles, the byte-level verification, the refusal to accept a passing test over a passing proof, the honesty about what's fast and what isn't — that's the part that makes the output trustworthy. AI without that rigor produces plausible code. AI with it produces a compiler that compiles itself, byte-for-byte, and you can go check the bytes.

That combination — senior engineering judgment as the guardrail, AI as the multiplier — is exactly what I bring to the systems I build for clients at Intrane. Most teams get one or the other: rigor without speed, or speed without rigor. The interesting work lives where they meet.

A language that compiles itself is a hard, verifiable, slightly obsessive proof that they can meet. If that's the kind of engineer you want on your hardest problem, let's talk.

machin is open source (MIT) — the self-hosting compiler lives in selfhost/, and you can reproduce the fixpoint yourself.

DEV Community: Javier Leandro Arancibia

My database claimed crash-safety. `kill -9` proved nothing.

What kill -9 actually tests

Two fsyncs, not one

Testing something invisible

What it costs

What I still can't claim

The general lesson

I built a 100 KB git-like VCS that beats git on `add && commit`

The benchmark that surprised me

Where the speed comes from

HTTP push / pull / clone out of the box

What's next

rcmd now speaks MCP — your AI agent can manage your servers without SSH

What is MCP?

What rcmd's MCP server exposes

How to set it up

What this looks like in practice

Why this matters

Self-host or use the hosted relay

What's next

Web Analytics With No Dashboard (But There Is a 3D Globe)

The premise

When a human needs to see it

The interesting constraints

I built a database my AI agent can pay for (and it beat SQLite)

The engine

The benchmark (100k docs, both engines indexed, same box)

Dogfooding found three compiler bugs in one day

For humans: client SDKs

rcmd: I replaced SSH with a relay — now my AI agents manage my servers

What shipped this week

Scheduled commands (cron)

Port forwarding (tunnel)

Team access

Email invites

Agent-first discovery

Why no SSH?

The stack

Try it

I replaced ssh -L with one CLI command. No SSH keys, no VPN, no open ports.

How it works

The command

What you can tunnel

But wait, I already have SSH

It's also a remote execution tool

Self-hosted or hosted

Install

What's next

I ran a 7B Mixture-of-Experts LLM in a language I built — token-identical to fp32

The wall

Mixture-of-Experts

It works — and it's exact

I made my programming language run a 1B LLM at 20 tok/s on a laptop CPU (it beat the reference C by 4x)

The correctness bar

The arc: 2.1 → 21.8 tok/s

Results (TinyLlama-1.1B, Q8_0, greedy)

An AI Agent Audits Your LinkedIn Profile in Public — Here's the Stack

You can watch the work happen

The stack

Why free

Your AI Assistant Can Run Your Website Chatbot Now

The two sins of chatbot SaaS

The bet: agents are the new admin panel

Your keys, your costs

Absurdly small, on purpose

Pricing

The Day My Language Started Compiling Itself

First, the backstory

What "compiles itself" actually means

How it was actually built (this is the part that matters)

Why I'm telling you this

What `kill -9` actually tests