DEV Community: Javier Leandro Arancibia

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.

machin — a language optimized for the AI agent writing it, not the human reading it

Javier Leandro Arancibia — Mon, 29 Jun 2026 15:37:12 +0000

Every mainstream language was designed for human ergonomics: readable syntax, explicit types, multi-line formatting. That made sense when a human typed every character. But a lot of code is now written by LLMs — and there, every output token costs time and money, and most of that human-friendly ceremony taxes the writer without adding meaning.

machin (MFL) takes that flip seriously: it treats token cost as a first-class design constraint. Zero type annotations (everything inferred), one canonical declaration per line, whitespace tightened to the minimum that still parses. Then it compiles — through C — to a single static native binary. No VM, no interpreter, no GC pauses you'll notice.

The one-line pitch: write it like a script, ship it like C.

▶ Try it in your browser — no install: play.intrane.fr. Write MFL, hit Run; it compiles to WebAssembly and runs client-side.

I didn't want to assert any of this, so I measured it — same programs, in the repo, runnable.

1. As cheap for an agent to write as Python

The same notes REST + SQLite API, written idiomatically in each language; tokens to author it (tiktoken o200k_base):

	author tokens	vs machin	ships as
machin	388	1.00×	44 KB native binary, 0 deps
Python	383	0.99×	source + a CPython interpreter
Go	527	1.36×	14.8 MB binary + a module dep

machin essentially ties Python on what it costs an agent to write — while being a compiled, statically-typed-by-inference native language. That's the whole trick.

2. In the native performance tier

Four compute kernels, byte-identical output across all three, each competitor at its best release setting (Rust -O3, Zig ReleaseFast, machin cc -O2), min of 5 (one machine):

kernel	machin	Rust -O3	Zig
fib(40)	245 ms	303	306
mandelbrot 1000²	827	814	819
sieve 10⁷	203	153	145
intsum 10⁹	2832 ms	3764	3556

machin wins two, ties one, and loses the array-heavy sieve by ~1.4×. It's C underneath, so on scalar recursion and integer loops gcc's optimizer matches or beats rustc/Zig here; on tight array indexing it trails. I'm not claiming "faster than Rust" — the sieve says otherwise. The claim is narrower and true: it's in the same tier, reached from Python-cheap source.

3. It ships like nothing in the scripting world

Same minimal HTTP server, four ways:

	deployable image	cold start	idle RAM
machin (static, `FROM scratch`)	92.9 kB	0.49 ms	108 kB
Python	47.6 MB (512×)	49 ms (100×)	17.9 MB (166×)
Node	178 MB (1916×)	29 ms (59×)	51 MB (477×)

A 92.9 kB image — the binary and nothing else — verified serving traffic from a FROM scratch container. A real REST+SQLite service is ~1.2 MB (machin build --static compiles SQLite straight in). Either way: scp one file to a $4 VPS, or push a sub-megabyte image. No node_modules, no pip install, no 178 MB pull per cold node.

Is it a toy? I built a real thing with it

machin-hook — a self-hosted webhook relay + live inspector (think webhook.site + smee.io in one binary): capture any request, watch it land live in the browser over SSE, inspect / replay / forward it. ~330 lines of MFL, no Node, no framework. It's a dogfood, not a unicorn — but it's a genuinely deployable tool, not fizzbuzz.

Who it's for

A small, self-contained, deployable backend — a JSON API, a CLI, a webhook handler, a cron/daemon, an internal tool — where "one tiny binary, no Docker/Node/interpreter" is the actual win. And, increasingly, the language you point a coding agent at when you want a small service shipped cheaply.

Who it's NOT for (where I'd tell you to use something else)

An app that lives in an existing ecosystem (a Rails/Next/Django codebase, a team's Go services) — fit the tools they have.
Anything needing a specific mature library (a Stripe SDK, pandas, a game engine, ML). machin's stdlib is broad but shallow, and there is no package registry.
Data-science / numeric array-crunching — it trails ~1.4× there and lacks the libraries.
A team that won't run an unfamiliar language. machin is young — one author.

Status / honest caveats

Young project, one maintainer, pre-1.0, the API still moves. The stdlib is broad (HTTP server, SQLite + pure-MFL Postgres/MySQL/Redis/Mongo drivers, crypto, WebSockets, SSE, a WebAssembly UI target, a raylib game path) but shallow. TLS currently links OpenSSL, so HTTPS-terminating apps aren't FROM scratch yet (native TLS is in progress). It compiles via C, so building programs needs a C compiler.

Try it (~60 seconds)

curl -fsSL https://raw.githubusercontent.com/javimosch/machin/main/install.sh | sh
machin guide                 # the whole language, version-exact, as JSON

Then write app.src, machin encode framework/machweb.src app.src > app.mfl, machin build, run it.

Repo: https://github.com/javimosch/machin
Benchmarks (run them yourself): under bench/ in the repo
The language catalog: machin guide

I'd genuinely like to hear where the thesis breaks for you — especially the "agents write it cheaply" claim, since that's the bet the whole design makes.

I let an AI agent write the tests for my access-control layer

Javier Leandro Arancibia — Thu, 25 Jun 2026 21:29:28 +0000

Fourth in the series. I've been giving mago — an autonomous agent team that runs over a GitHub repo on your own LLM key — real tasks on my own repos: a feature in Go, a crash fix in Zig, and a refactor in Python it wasn't allowed to cheat on. This time, the one that actually made me nervous: let it test my access-control layer.

The gap

superbackend is my Node.js backend toolkit. Its RBAC middleware — src/middleware/rbac.js: requireRight, requireModuleAccess, and a basic-auth super-admin bypass — had zero tests. Untested authorization is the scariest kind of untested code: a silent regression there is a security hole, not a bug report.

So I filed an issue: add a real unit-test suite for it. Mock the service so it needs no DB; cover the actual decisions; don't change the behavior.

What it shipped

src/middleware/rbac.test.js — 25 tests, +326 lines, covering each export against fake req/res/next with the rbac service mocked out:

requireRight — calls next() when the right is granted, returns 403 when denied, the super-admin basic-auth path bypasses the check, orgId resolves from params/query/body (and a custom resolver), and a service error is handled rather than crashing the request.
requireModuleAccess — allow/deny for both read and write actions.
isBasicAuthSuperAdmin — the true/false cases.

No change to rbac.js itself — tests only, exactly as asked.

Verified

$ npx jest src/middleware/rbac.test.js
Tests: 25 passed, 25 total

And the full suite stayed green — the PR is purely additive (+326/-0, one new file), introducing zero new failures. Merged. My access-control layer now has a safety net it didn't have this morning.

Four repos, four stacks, four kinds of work

Stack	Task
Go	a feature
Zig	a crash fix
Python	a refactor (without gutting the tests)
Node	test coverage for security-critical RBAC

Same loop every time: file an issue, the agent implements it on your own key, runs the repo's own tests, and opens a PR you review — verified, not blindly merged. Not pinned to a language, a framework, or a kind of task.

The honest framing hasn't changed: it's a reliable autonomous dev shop for well-scoped, verifiable work — features, fixes, refactors, and the tests you keep meaning to write. Not "build me a startup."

Try it

CLI-only, BYOK (your Claude Code or tau key — it never resells completions), €20/mo. First 10 founding operators free during the beta, with a direct line to me:

👉 https://mago.intrane.fr

curl -fsSL https://mago.intrane.fr/install.sh | sh
mago register

An AI agent fixed my red Python test suite — without gutting the tests

Javier Leandro Arancibia — Thu, 25 Jun 2026 21:16:17 +0000

This is the third in a short series. I've been pointing mago — an autonomous agent team that runs over a GitHub repo on your own LLM key — at my own repos and giving it real tasks. So far: a feature in Go and a crash fix in Zig. This time it's Python, and the question every skeptic asks: won't it just hack the tests to make them pass?

The setup

boilerplate-cli-ui-python is my agent-first Python CLI boilerplate. Its test suite was red — 4 failing tests:

FAILED tests/test_config.py::test_config_defaults - assert False == True
FAILED tests/test_output.py::test_output_formatter_json_mode - SystemExit: 0
FAILED tests/test_output.py::test_output_formatter_human_mode - SystemExit: 0
FAILED tests/test_output.py::test_output_error_json - SystemExit: 85

I filed an issue with one explicit instruction: fix the root cause, don't gut the tests.

What it actually did

It diagnosed two real bugs:

A config default mismatch (no_color defaulted to the wrong value).
The interesting one: OutputFormatter.output() and output_error() called sys.exit() inside the formatter, right after writing. That makes them impossible to unit-test — the test can't capture-then-assert because the process just exits — and it's a design smell: a formatter shouldn't own process control.

The fix wasn't "delete the assertions." It was a separation of concerns:

# before — formatter exits, untestable
def output_error(self, error, code):
    ...print json...
    sys.exit(code)

# after — the formatter just formats; the CALL SITE owns the exit
# src/output.py: no sys.exit at all
# src/main.py / src/cli.py, at every error path:
formatter.output_error(error.to_dict(), error.code)
sys.exit(error.code)

It pulled sys.exit() out of the formatter and added it at every error call-site in main.py/cli.py — so production exit codes are preserved while the formatter becomes testable. Then it rewrote the tests to assert the error payload instead of requiring the process to die.

I verified it — and checked specifically for cheating

$ python -m pytest
20 passed

Green is cheap if you gut tests, so I checked the diff:

grep sys.exit src/output.py → 0 (removed, as intended)
sys.exit(error.code) added at every error path in main.py/cli.py
the CLI still exits non-zero on errors

It fixed the design, kept the behavior, and made the tests meaningful. Merged.

Three repos, three stacks, one loop

Go — a feature (a command suggester).
Zig — a crash fix (red → green).
Python — a real refactor that made a broken suite green without weakening it.

Same loop every time: file an issue, the agent implements it on your own key, runs the repo's own tests, and opens a PR you review — verified, not blindly merged. It isn't pinned to a language or a framework, and — the part I actually cared about — when told not to cheat, it didn't.

Try it

CLI-only, BYOK (your Claude Code or tau key — it never resells completions), €20/mo. First 10 founding operators free during the beta, with a direct line to me:

👉 https://mago.intrane.fr

curl -fsSL https://mago.intrane.fr/install.sh | sh
mago register

If you point it at one of your own repos — any stack — I'd love to hear how it goes.

Same agent, different language: mago fixed a crashing test in my Zig CLI

Javier Leandro Arancibia — Thu, 25 Jun 2026 20:43:30 +0000

In a previous post I let mago — an autonomous agent team that runs over a GitHub repo — ship a feature to my Go deploy CLI. The obvious next question: does it generalize past Go, and past "add a feature"? So I pointed it at a Zig project and a crashing test.

The bug

tau is my agent-first AI CLI, reimplemented in Zig. Its test suite had one test that didn't just fail — it crashed:

error: 'agents_md.test.scanAgentsMd returns empty for bad path' terminated with signal ABRT
Build Summary: 1/3 steps succeeded (1 failed); 132/133 tests passed (1 crashed)

132 green, 1 hard abort — the kind of thing that sits red in CI because "it's just a test."

What mago did

It read the test and found the root cause, not the symptom. The test was passing undefined as the io: std.Io argument:

// before
const result = scanAgentsMd(undefined, std.testing.allocator, std.testing.allocator, "/nonexistent") catch ...

scanAgentsMd uses io, so in a debug build Zig traps the undefined access and aborts — before the test ever reaches the bad-path logic it meant to exercise. The fix is one line: pass a real io.

// after
const result = scanAgentsMd(std.testing.io, std.testing.allocator, std.testing.allocator, "/nonexistent") catch return;

It opened a PR with exactly that.

Verified

$ zig build test
Build Summary: 3/3 steps succeeded; 133/133 tests passed

Red → green. Merged.

Two repos, two stacks, one loop

Last time: a feature in Go (a "did you mean" command suggester for a 32-command CLI).
This time: a bug fix in Zig (a crashing test, root-caused and fixed).

Same loop both times: file a GitHub issue, the agent implements it on your own LLM key, runs the repo's own build/tests, and opens a PR — verified, not blindly auto-merged. It isn't tied to a language or a framework; it works against whatever your repo's build/test command says is green.

It's good at well-scoped, verifiable work — features, fixes, tests, refactors, DX. Not "build me a startup." Honest framing: a reliable autonomous dev shop you steer with a roadmap.

Try it

CLI-only, BYOK (your Claude Code or tau key — it never resells completions), €20/mo. First 10 founding operators free during the beta, with a direct line to me:

👉 https://mago.intrane.fr

curl -fsSL https://mago.intrane.fr/install.sh | sh
mago register

If you point it at one of your own repos — any stack — I'd love to hear how it goes.

I let an autonomous agent fix my own deploy CLI — here is the PR it shipped

Javier Leandro Arancibia — Thu, 25 Jun 2026 20:26:05 +0000

While building mago — a CLI that runs a small autonomous "company" of AI agents over a GitHub repo — I did the obvious test: point it at one of my own tools and give it a real task. No demo repo, no cherry-picked example. Here's exactly what happened, PR included.

The tool and the task

hotify-cli is my Go CLI for deploying web apps behind Traefik + Cloudflare (it's literally what deploys mago's own backend). It has 32 subcommands, and like a lot of CLIs, a mistyped command just dumped the entire ~130-line usage block and exited. Annoying for humans, noisy for agents.

So I filed a normal GitHub issue:

feat: suggest the nearest command on unknown input ("did you mean"), not a full-usage dump

…labeled it mago, and let the agent take it.

What the agent did, unattended

mago routed the issue to its implementer, which:

Cloned the repo and read the 32-command dispatch in main.go.
Wrote suggest.go — a rune-aware Levenshtein distance + a prefix-match shortcut + a canonical command list, with a length-aware threshold so unrelated typos don't surface a misleading suggestion.
Wrote suggest_test.go — 11 cases (typos, prefix matches, unrelated input).
Wired it into the default case of the dispatch.
Ran gofmt / go vet / go build / go test, then opened a pull request.

About 3 minutes, on Claude Sonnet, with no human in the per-step loop. Crucially it opened a PR — it didn't push to main. The merge stayed my call.

I verified it (don't trust the summary)

I checked out the branch myself:

gofmt: clean   go vet: clean   go build: OK   go test: ok

And the actual behavior:

$ hotify-cli statuss
hotify-cli: unknown command "statuss"
Did you mean "status"?
Run 'hotify-cli help' for usage.

$ hotify-cli deploi
Did you mean "deploy"?

Correct, scoped, tested, dependency-free. Merged.

Why it works — and where it doesn't

The thing that makes it trustworthy isn't the model, it's the loop:

Verified autonomy — a PR only auto-merges if review passes and the repo's own build/tests are green; failing or unverifiable work waits for you. (I kept this one review-only.)
GitHub-native — issues = tasks, labels = status, PRs = deliverables. The worker dials out, so there's no inbound webhook to expose.
BYOK — it drives your own Claude Code or tau key. It never resells completions.

It's genuinely good at well-scoped, verifiable work: tests, refactors, small features, CLI/UX fixes. It is not "build me a startup." Honest framing — it's a reliable autonomous dev shop you steer with a roadmap, not magic.

Try it

mago is CLI-only, BYOK, €20/mo. I'm onboarding the first 10 founding operators free during the beta, with a direct line to me:

👉 https://mago.intrane.fr

curl -fsSL https://mago.intrane.fr/install.sh | sh
mago register

If you try it on one of your own repos, I'd love to hear where it helped — and where it annoyed you.

Append-CLIP-Interrogation: A SuperCLI Plugin Guide

Javier Leandro Arancibia — Wed, 24 Jun 2026 03:44:35 +0000

Append-CLIP-Interrogation

Simple python script to automatically append caption generated by CLIP interrogator to an image file

Source

https://github.com/Append-CLIP-Interrogation/Append-CLIP-Interrogation

Installation

Check GitHub repository for installation instructions
Verify: Append-CLIP-Interrogation --version
supercli plugins install ./plugins/Append-CLIP-Interrogation --on-conflict replace --json

About SuperCLI

This plugin is part of the SuperCLI ecosystem - a unified CLI plugin manager for AI agents and developers.

Discover, install, and orchestrate thousands of command-line tools with SuperCLI.

App-Store-Connect-CLI: A SuperCLI Plugin Guide

Javier Leandro Arancibia — Wed, 24 Jun 2026 02:44:35 +0000

App-Store-Connect-CLI

Fast, scriptable CLI for the App Store Connect API. Automate TestFlight, builds, submissions, signing, analytics, screenshots, subscriptions, and more. JSON-first, no interactive prompts

Source

https://github.com/App-Store-Connect-CLI/App-Store-Connect-CLI

Installation

pip install app-store-connect-cli
Verify: app-store-connect-cli --version
supercli plugins install ./plugins/App-Store-Connect-CLI --on-conflict replace --json

About SuperCLI

This plugin is part of the SuperCLI ecosystem - a unified CLI plugin manager for AI agents and developers.

Discover, install, and orchestrate thousands of command-line tools with SuperCLI.

AiToEarn: A SuperCLI Plugin Guide

Javier Leandro Arancibia — Wed, 24 Jun 2026 01:44:35 +0000

AiToEarn

AI-powered earning platform CLI for monetizing AI capabilities and services

Source

https://github.com/AiToEarn/AiToEarn

Installation

pip install aitoearn
Verify: aitoearn --version
supercli plugins install ./plugins/AiToEarn --on-conflict replace --json

About SuperCLI

This plugin is part of the SuperCLI ecosystem - a unified CLI plugin manager for AI agents and developers.

Discover, install, and orchestrate thousands of command-line tools with SuperCLI.

DEV Community: Javier Leandro Arancibia

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

machin — a language optimized for the AI agent writing it, not the human reading it

1. As cheap for an agent to write as Python

2. In the native performance tier

3. It ships like nothing in the scripting world

Is it a toy? I built a real thing with it

Who it's for

Who it's NOT for (where I'd tell you to use something else)

Status / honest caveats

Try it (~60 seconds)

I let an AI agent write the tests for my access-control layer

The gap

What it shipped

Verified

Four repos, four stacks, four kinds of work

Try it

An AI agent fixed my red Python test suite — without gutting the tests

The setup

What it actually did

I verified it — and checked specifically for cheating

Three repos, three stacks, one loop

Try it

Same agent, different language: mago fixed a crashing test in my Zig CLI

The bug

What mago did

Verified

Two repos, two stacks, one loop

Try it

I let an autonomous agent fix my own deploy CLI — here is the PR it shipped

The tool and the task

What the agent did, unattended

I verified it (don't trust the summary)

Why it works — and where it doesn't

Try it

Append-CLIP-Interrogation: A SuperCLI Plugin Guide

Append-CLIP-Interrogation

Source

Tags

Installation

About SuperCLI

App-Store-Connect-CLI: A SuperCLI Plugin Guide

App-Store-Connect-CLI

Source

Tags

Installation

About SuperCLI

AiToEarn: A SuperCLI Plugin Guide

AiToEarn

Source

Tags

Installation

About SuperCLI