DEV Community: Agnel Nieves

Rust Owns the JavaScript Toolchain in 2026

Agnel Nieves — Thu, 14 May 2026 00:00:00 +0000

TL;DR

If you are shipping a modern JavaScript app in 2026, almost every step between your editor and your production bundle is a Rust binary. Next.js builds with Turbopack. Vite builds with Rolldown. Your linter and formatter are Biome or oxlint. Your CSS pipeline runs through Lightning CSS. Bun, the runtime that started in Zig, just merged its Rust rewrite into main. The result: bundlers are 5 to 30x faster, linters are 50 to 100x faster, and the dependency tree of "the JavaScript toolchain" has collapsed to a handful of statically linked binaries with zero npm postinstall scripts. That last detail matters more than it sounds, because the npm supply chain spent the last 18 months getting set on fire.

Why I'm writing this

I noticed it in pieces. I shipped a terminal portfolio over SSH in Rust two weeks ago, and the build pipeline felt like a different planet to anything I had touched in Node years ago. Then Next.js 16 went stable with Turbopack as the default. Then Vite 8 shipped with Rolldown. Then Anthropic merged a Zig-to-Rust port of Bun, mostly written with AI. Then a fresh Mini Shai-Hulud wave hit TanStack, Mistral, and 160+ npm packages three days ago, on the heels of a November Shai-Hulud campaign that compromised roughly 25,000 GitHub repos. "Small dependency" is now a polite phrase for "unsandboxed code with full filesystem access."

Three threads, one direction. Worth writing down.

I am late to this take. Lee Robinson wrote "Rust Is Eating JavaScript" and the 2026 update made the bigger point cleanly. The angles I want to add are mobile and security, because the toolchain story is only the first act.

The toolchain went Rust

Pick a step in the build pipeline and chances are it has been quietly rewritten in Rust.

Turbopack. Next.js 16 (February 2026) shipped Turbopack as the default bundler for both next dev and next build. The numbers Vercel published before the cutover: more than half of all dev sessions and more than a fifth of production builds were already on Turbopack via 15.3+. After the default flipped, the 16.2 release in April claimed roughly 87% faster dev startup on real apps. The HMR feels different. I had stopped noticing how often I was alt-tabbing during compiles, and after switching I noticed how often I was not.

Rolldown. Vite 8 shipped on March 12, 2026 with Rolldown as the bundler, taking over from the Rollup plus esbuild combination. Public production numbers from the Rolldown team: Excalidraw dropped from 22.9s to 1.4s. PLAID, an internal product at ByteDance, dropped from 80s to 5s. Both are roughly 16x. The transitional rolldown-vite package was archived a week after 8.0 because it was redundant. If you npm create vite@latest today, you get Rolldown without asking for it.

Rspack. ByteDance's webpack-compatible Rust bundler hit 1.7 in January and is on the runway to 2.0. Internally they ship TikTok, Douyin, Lark, and Coze on it. Externally, Microsoft, Amazon, and Discord are in the public adopter list. The migration cases I have seen all land in the same neighborhood: 9x faster cold dev, 3x less memory, prod builds under 4 seconds on apps that used to take 30.

Biome and oxlint. ESLint is no longer the default lint stack. Biome 2 added type-aware rules that do not require running the TypeScript compiler. Oxlint 1.0 went stable in August, ran 50 to 100x faster than ESLint on the same rulesets, and shipped a type-aware alpha in March on top of tsgolint (which itself runs on Microsoft's Go-based tsgo). Shopify reported a 71% lint-time reduction across an ~80,000 file TypeScript codebase. The pattern teams actually use: oxlint as a pre-commit and CI gate for the hot rules, Biome for formatting, ESLint kept around for any plugin you cannot get rid of yet.

Lightning CSS. Tailwind v4's "Oxide" engine is Lightning CSS underneath. Full builds 5x faster, incremental builds up to 100x. The PostCSS chain is gone from the default setup.

Bun. Bun was a Zig project. In May, Anthropic (which acquired Bun last year and uses it inside Claude Code) merged a port of the entire codebase from Zig to Rust into main. The port is roughly 966,000 lines, it was largely AI-assisted, and it passes 99.8% of the existing test suite on Linux x64 glibc. Bun 1.3.14 is positioned as the last Zig release. The reasons given: Rust's memory safety story, and Zig's no-AI contribution policy clashing with how Anthropic builds tooling.

Deno and Node. Deno's core was always Rust, and the 2.6 release in December bumped V8 to 14.2, added dx to replace npx, and started using tsgo for type checking. Node 25.2 (November 2025) shipped stable TypeScript support through Amaro 1.0, which is a wrapper around @swc/wasm-typescript. Node's official type-stripping path is now SWC compiled to WebAssembly, shipping inside core. There is more Rust running inside node than most teams realize.

If you list the build steps in your CI pipeline (lint, format, type check, transpile, bundle, minify, optimize CSS) the only step still being done by JavaScript on JavaScript code in 2026 is type checking. And the most consequential type checker (Microsoft's official one) is being ported to Go, not Rust, by the team that wrote TypeScript in the first place. That is the one part of the ecosystem where the obvious "rewrite it in Rust" bet did not pay off, and it is worth saying out loud.

Bigger than dev tools

This is bigger than JavaScript. Microsoft has publicly committed to embracing Rust across Azure infrastructure, and Azure CTO Mark Russinovich has spent the last two years telling every conference audience that new kernel development at Microsoft should stop using C or C++. New code for Windows and Azure should be written in Rust. That is not a future commitment. Production components already moved: parts of Win32k.sys, Hyper-V, the SymCrypt cryptographic library, and Azure Data Explorer. The Azure SDK for Rust shipped beta in February 2025 and now releases monthly alongside the other language SDKs. At RustConf 2025, Microsoft's Galen Hunt described the broader internal goal as refactoring roughly one million lines of code per month for the rest of the decade, with the aim of eliminating C and C++ from Microsoft's codebase by 2030.

The Linux kernel has merged Rust drivers since 6.1 (late 2022) and the Rust-for-Linux subsystem keeps growing each release. AWS rewrote Firecracker, its microVM monitor, in Rust years ago and continues to add Rust services across the stack. Google has Rust in Android, in parts of Chromium, and in Fuchsia. When the kernel your build tools run on is moving to Rust, the build tools moving to Rust is the predictable next step.

What about mobile

Mobile is a different shape and Rust shows up differently.

The default cross-platform stacks (React Native, Flutter) are not Rust. React Native's New Architecture (Fabric, TurboModules, JSI) is C++. Hermes is C++. Flutter is Dart plus C++. What changed in the last 18 months is the layer just above that: Rust as a shared core, exposed to those frameworks through binding generators.

The pattern teams actually use: write the things that should not be rewritten twice in Rust, and put a thin native UI on top of them.

Signal does this with libsignal. The protocol, AES-GCM and other primitives, zero-knowledge groups, and remote attestation are all Rust crates. Java, Swift, and TypeScript wrappers expose them to Android, iOS, and Desktop.
1Password rewrote its core (sync, storage, crypto, permissions) in Rust, kept native UI per platform, and built TypeShare so type definitions stay consistent across the FFI boundary. One Rust core, eight clients on top.
Mozilla ships sync, login storage, browsing history, push, and experimentation as Rust components shared between Firefox iOS and Firefox Android, all generated through UniFFI.
Cloudflare ships BoringTun, a userspace WireGuard implementation in Rust, on millions of consumer iOS and Android devices through Mozilla VPN and others.
Bitwarden is moving its cryptographic operations into a shared bitwarden_core Rust SDK consumed by every client.

The new bit, and the reason this thread is worth pulling on right now: in December 2024 Mozilla and Filament released Uniffi for React Native. It generates a TurboModule (TypeScript plus the JSI C++ glue) directly from a Rust crate and a UniFFI interface definition. That finally aligns React Native with the pattern Signal and 1Password have been using productively for years. Flutter has had flutter_rust_bridge doing the same job for a while, and v2 is now an officially Flutter Favorite package with async Rust support, web targets, and zero-copy big arrays.

The Rust-native UI frameworks (Dioxus, Slint, egui) are real and improving. Slint added an iOS tech preview in 1.12 last June, with proper Xcode integration, simulator and device deploy, TestFlight, and App Store publishing. Dioxus 0.7 runs on iOS reasonably well and on Android with some pain (Huawei and Airbus are public production references). None of these are what I would reach for to build a polished consumer app today, but the trade is no longer "no Rust GUI on phones." It is "yes, but you should know what you are signing up for."

The honest tradeoffs on mobile have not gone away.

Toolchain pain. NDK plus cargo-ndk for Android. Xcode, codesigning, provisioning, and a sometimes fragile lipo/XCFramework dance for iOS. Every Rust target multiplies your CI matrix.
String impedance. Rust is UTF-8, Swift is UTF-16, Java/Kotlin is "modified UTF-8." Conversions are easy to get wrong, and "wrong" means corruption or crashes.
FFI overhead is real. The well-worn guidance: batch your calls. One call processing 100 items beats 100 calls processing one.
Binary size. A naive Rust core can add MB to your IPA or APK before optimization. LTO, panic=abort, and symbol stripping are the price of entry.
Platform API drift. Widgets, App Intents, Live Activities, Material You, and the latest media APIs almost always live outside the Rust core, in native code. Apple and Google ship features faster than any binding generator can chase.

The takeaway for mobile is the same as on the desktop side: Rust as a shared core works. Rust as the whole app on mobile is niche.

And then there is npm

This is the part of the story I do not think gets told enough.

The last 18 months were brutal for the npm registry. Three events worth grounding the rest of this on:

September 8, 2025: qix / chalk + debug. A maintainer named Josh Junon (handle qix) owns some of the most foundational packages in JavaScript: chalk, debug, ansi-styles, strip-ansi, color-convert, and a dozen more. He received a phishing email from support@npmjs.help, a lookalike domain registered three days earlier. The attacker captured his credentials and TOTP through an adversary-in-the-middle session and published malicious versions of 18 packages with combined weekly downloads of roughly 2 billion. Exiger estimated the transitive blast radius at around 34% of the entire npm registry. The payload was a browser-side crypto-clipper that hooked window.ethereum, window.solana, fetch, and XHR, then swapped wallet addresses in outgoing transactions using minimum Levenshtein distance so the substitution would survive a quick visual check. Aikido flagged it within five minutes. The malicious versions were on the registry and being installed by CI worldwide for the entire window before that. Vercel published a same-day advisory.

September 15, 2025: Shai-Hulud. A week later, @ctrl/tinycolor (2M+ weekly downloads) was found to contain a self-replicating worm. The malware was the first true worm in the npm ecosystem: every install used the victim's npm token to enumerate other packages the maintainer owned, injected a Webpack-bundled payload, bumped the version, and republished. By the time CISA issued its alert on September 23, more than 500 packages were affected, including ones from CrowdStrike, @nativescript-community, and @operato. The payload ran TruffleHog against the host to scrape AWS keys, GCP credentials, Azure tokens, GitHub PATs, and npm tokens, then uploaded them to public GitHub repos named "Shai-Hulud." A second wave on November 24 moved its hook from postinstall to preinstall (so it ran before any user-visible install output) and hit roughly 25,000 GitHub repositories. CERT/CC VU#534320 called it the first credential-stealing, self-propagating worm in npm.

May 11, 2026: Mini Shai-Hulud. Three days ago, as I write this. A threat actor StepSecurity has been tracking as TeamPCP hit TanStack hard: 42 packages, 84 malicious versions. The same campaign caught Mistral AI, Guardrails AI, UiPath, OpenSearch, and the Bitwarden CLI. Socket flagged 416 affected packages in total; Aikido catalogued 373 malicious package-version entries across 169 names. The technique was novel: a pull_request_target workflow that ran attacker-controlled fork code, GitHub Actions cache poisoning across the fork/base trust boundary, and OIDC token extraction from the runner's process memory. Once inside maintainer CI, the worm did what its predecessor did: scrape credentials, find publishable packages, inject, republish.

The detail that mattered most: the malicious TanStack packages were the first documented npm malware shipping with valid SLSA provenance attestations. The cryptographic chain worked perfectly. The attacker had simply stolen the GitHub OIDC token used to sign builds. Provenance proves "this package was built by this CI run." It does not prove the CI run was not compromised.

The earlier baseline (the December 2023 Ledger connect-kit attack that drained DeFi front-ends for about five hours, the LottieFiles compromise in October 2024, the Rspack token theft in December 2024) is what made September 2025 land as a confirmation, not a surprise. May 2026 made it a pattern.

The structural reason these keep happening: npm is built on install-time arbitrary code execution and ambient authority. The preinstall, install, and postinstall hooks run before any human can review them, with full read and write filesystem access and full network. A typical app's node_modules is several thousand packages from several hundred maintainers, any one of whom can phish or token-leak their way into your build. A logger and a color formatter have the same operating-system privileges as your application code, because Node has no capability-based security to draw a line between them.

The protective measures that shipped (npm provenance, expanded required 2FA in October and November 2025, scan tools like Socket and OSV-Scanner) help at the margins but do not change the model. A phished maintainer with a valid provenance signature still ships valid signed malware. Mini Shai-Hulud proved that this week, with attestations the GitHub Actions runner generated honestly while compromised. 2FA does not stop an adversary-in-the-middle proxy. Detection time has tightened from days to minutes, which is real progress, but the first thousand installs of a poisoned package still happen.

Why this makes Rust tooling load-bearing

Moving the build toolchain to Rust does not fix the structural problems in your runtime dependencies. Your app's node_modules is still a forest of trust assumptions. What it does change is that the build toolchain (the most-installed, most-privileged surface area in the average project) leaves the npm graph entirely.

A linter, a formatter, a bundler, a test runner, and a transpiler are pure dev-time tools with read access to your whole codebase and write access to your machine. They are also among the most-installed packages on npm, which is exactly what made their maintainers attractive phishing targets. Replacing them with one statically linked Rust binary collapses that surface. There is no postinstall. There is no transitive graph. There is a single maintainer organization whose key you can pin.

Concrete numbers from a clean npm install I ran this week:

Toolchain choice	Top-level deps	Total packages	Disk
`eslint` + `prettier`	59	77	20 MB
`@biomejs/biome` (Rust)	1 platform binary wrapper	1 user-facing	48 MB binary
`rollup`	3	4	4.5 MB
`rolldown` (Rust)	3 platform binary wrapper	4	19 MB

Biome's own docs report that a realistic ESLint + Prettier + typical plugins setup lands closer to 127 to 200 packages once plugin ecosystems get involved. The 59 above is the bare minimum.

Cargo has its own supply-chain risks (typo-squats, the long-running debate about serde's precompiled binaries, the occasional malicious crate). What it does not have is a postinstall hook that fires arbitrary code on every developer machine for every transitive build dependency, on every install, forever. That is the difference that matters.

Why Rust specifically

Two reasons. The performance numbers are the easy half: 5 to 30x for bundlers, 50 to 100x for linters, 3 to 4x lower memory across the board. That alone would explain the move.

The harder half is everything else.

Memory safety without a GC. Long-running dev servers and HMR processes do not want to pause for 200ms at the wrong moment. GC-based runtimes (Go, JS) hit this; Rust does not.
Single-binary distribution. CLIs like oxlint and biome ship as one executable per platform. No Node bootstrap, no thousand require() calls, no JS launcher script wrapping a native binary wrapping the actual logic.
Fearless parallelism. rayon and tokio let linters and bundlers fan out across cores cleanly. The JS event loop is fast but it is one core at a time.
WebAssembly as an escape hatch. Node 25.2 ships SWC as wasm inside core. Browser playgrounds run Oxc directly. The same Rust crate can serve a CLI, a Node API, and a browser sandbox without rewriting any of the hot path.

It is also worth saying clearly: Rust is not the only winner. TypeScript's compiler is being ported to Go, not Rust, by Anders Hejlsberg and the team that wrote TypeScript in the first place. The 7.0 beta dropped on April 21, 2026 with a 10x speed claim. Bun started in Zig and only just switched. The honest story is "native code ate JS tooling, mostly Rust, but not entirely."

What I would build with this stack today

If I were starting a new app this week:

next@16 or vite@8 for the framework. Both Rust bundlers underneath.
@biomejs/biome for formatting plus a lint baseline. oxlint as a CI gate for the type-aware rules.
Tailwind v4 with the Oxide engine.
A Rust core library for anything cryptographic, anything sync-heavy, or anything I would want to share between web and mobile, exposed through UniFFI or flutter_rust_bridge if mobile is on the roadmap.
bun or pnpm as the package manager. Lockfile discipline matters more than the manager you pick.

The whole pipeline would have one or two Node processes that exist mainly to host the dev server and run user code. Everything else underneath would be Rust binaries doing the heavy work. That is not aspirational anymore. That is just npm create.

The honest limitations

Three things I would rather not glaze over.

Plugin ecosystems fragment. Every Rust tool eventually faces the same fork: stay in Rust (fast, inaccessible to most JS contributors) or expose a JS plugin API (slower, ergonomic). Rolldown went hard on Rollup-plugin compatibility for adoption. Oxlint shipped a JS plugin alpha in March because too many ESLint rules people care about live in plugin land. Marvin Hagemeister's Speeding up the JavaScript ecosystem series is the canonical write-up of this tension and worth reading if you are considering migrating.

The contributor bus factor is real. Rust is a learning curve for JS-native maintainers. Concentration on Turbopack, Oxc, and Biome is worth pricing in if you are building on top of these tools.

Memory regressions happen. Rolldown 1.0 RC.18 shipped with about 7x higher RSS than Vite 7 in dev for some apps before the fixes landed. Bundlers in Rust are not automatically more memory-efficient. They are faster, but the wins live in CPU time, not necessarily memory.

Try it yourself

If you have not migrated a project off ESLint yet, bunx @biomejs/biome init plus bun add -d oxlint will take you 15 minutes. The Biome migration commands (biome migrate eslint, biome migrate prettier) are doing the right thing in 2026. The Vite 8 upgrade is a npm install vite@8 for most apps. Next.js 16 is the same story; the Turbopack flag is just gone now.

The faster builds are the part people notice. The smaller dependency tree is the part your security team should notice. The shared Rust core that could ship to mobile next quarter is the part your CTO should notice.

It all started with one team being annoyed enough at webpack to write SWC. We got here by accident.

Built by Agnel Nieves, a design engineer with 15+ years across product, design systems, and crypto. More writing on the blog.

Building a Terminal Portfolio You Can SSH Into

Agnel Nieves — Tue, 12 May 2026 00:00:00 +0000

TL;DR

You can now browse this site in your terminal:

ssh agnelnieves.sh

No install. One Rust binary that runs as either a local CLI or an in-binary SSH server. No system sshd, no user accounts, no auth. The TUI is built with ratatui; the SSH layer is russh; render code is shared between local and remote modes. It's hosted on Fly.io behind a dedicated IPv4, and the whole thing costs about $2/mo. The code lives as a cli/ package inside the same Next.js project that powers this site, so the website and the terminal share a single deploy story. If you want the full build (architecture, code, Fly.io setup), I wrote it up as a step-by-step guide.

The setup

ssh agnelnieves.sh. That's it. No -l user@, no keys to add, no first-time signup. The server accepts whatever username your local SSH client offers and drops you straight into a terminal UI.

Press h/a/b/c to jump between Home, About, Blog, and Connect. j/k (or arrows) to navigate lists. Enter to open. q to quit, which closes the SSH session.

Why I built it

Honestly? I saw terminal.shop and thought it was awesome. They sell coffee at ssh terminal.shop (that's the whole storefront, no website) and the first time I tried it I wanted to know if I could build something like it.

I do side projects like this when I need to step away from whatever I'm shipping day-to-day. They're not pitches. They don't need a thesis. They're more like the way some people fix a bike on a Saturday: sit down, follow whatever's pulling on your curiosity, and at the end you have a thing that didn't exist before. That's the whole reason.

So this was that. A few evenings poking at ratatui and russh to see what it would take to make ssh agnelnieves.sh actually work. Turns out: less than I expected. The hardest parts were the ones I didn't see coming, which is what makes any of this fun.

The architecture

One binary. Two modes. One render path.

            ┌─────────────────────────────┐
            │ agnel (single .exe) │
            └──────────────┬──────────────┘
                           │
            ┌──────────────┴──────────────┐
            │ │
       agnel (no flag) agnel --serve
       Local TUI SSH server (Fly.io)
       crossterm stdin russh + custom backend
            │ │
            └──────────┬──────────────────┘
                       │
                src/render.rs ← shared
                       │
                Per-session App state
                       │
                Live fetches from agnelnieves.com APIs

The pieces:

TUI: ratatui draws everything: header, ticker, ASCII banner, projects list, blog reader. The render function lives in src/render.rs and is identical whether the binary is running on your laptop or whether you're seeing it over SSH.
State machine: App in src/app.rs owns screen, scroll position, list selection, ticker animation, and async-fetch results funneled through an mpsc::Receiver.
Data: zero content is bundled. The CLI fetches live from /feed.json, /api/blog/[slug]/raw, /api/projects, and /api/site.json on this site, cached for an hour at ~/.agnel/cache/. So a new blog post here shows up in your terminal immediately without redeploying anything.
SSH server: russh 0.60 in src/serve.rs. One tokio task per session.

The decision that made it easy: don't fork a PTY

Most "expose a TUI over SSH" guides suggest spawning a pseudo-terminal and exec-ing the TUI binary inside it. That's how mosh, tmux, and Go's wish library (the one terminal.shop uses) handle things. It works, but it's heavier:

Adds a libc dependency (forkpty)
Forks a process per connection (more memory, slower spawn)
Hard to share state between the SSH layer and the app

Russh's ratatui_app example showed a cleaner path: implement a custom std::io::Write backend that funnels bytes through russh's Handle::data(channel, bytes) API. Ratatui doesn't know it's writing to an SSH channel instead of stdout. No fork, no PTY, just bytes:

struct TerminalSink {
    sender: UnboundedSender<Vec<u8>>,
    sink: Vec<u8>,
}

impl std::io::Write for TerminalSink {
    fn write(&mut self, buf: &[u8]) -> std::io::Result<usize> {
        self.sink.extend_from_slice(buf);
        Ok(buf.len())
    }
    fn flush(&mut self) -> std::io::Result<()> {
        if !self.sink.is_empty() {
            let _ = self.sender.send(std::mem::take(&mut self.sink));
        }
        Ok(())
    }
}

A background tokio task drains the channel and pushes bytes back to the client through russh. Each session gets its own App and its own Terminal<CrosstermBackend<TerminalSink>>. The lock graph stays tiny: an Arc<Mutex<SessionState>> per session, plus a HashMap of all sessions for cleanup.

Inputs go the other direction. Russh hands raw bytes to my data() callback, and a small parser turns them into the same crossterm::event::KeyEvent values the local TUI uses. That meant zero changes to App::handle_key:

fn parse_keys(buf: &[u8]) -> Vec<KeyEvent> {
    // 0x03 → Ctrl+C, 0x1b[A → Up, 0x1b alone → Esc,
    // printable ASCII → Char(b), etc.
}

Window resize hooks into the same place. window_change_request calls terminal.resize(rect), and ratatui redraws on the next 50 ms tick.

The result: a single binary you can drop on a VPS, in a container, or even into a Lambda-style worker, and it just serves the TUI.

What I learned about hosting

A few things I didn't expect.

1. Fly trial orgs block dedicated IPv4, and SSH needs IPv4. For HTTP, Fly's edge gives you a shared anycast IPv4 for free. For raw TCP on port 22, you need a dedicated v4 (~$2/mo), and trial orgs can't allocate one. Pure-IPv6 isn't a real option, either: most US residential ISPs still don't have native IPv6 SSH paths. Adding a card was the unlock.

2. The SSH host key has to persist. If the container generates a fresh Ed25519 key on every boot, every returning visitor gets REMOTE HOST IDENTIFICATION HAS CHANGED warnings after the next deploy. The fix is a 1 GB Fly volume mounted at /data, with --host-key /data/ssh_host_key. First boot generates and writes the key; every boot after just reads it.

3. Trial machines auto-stop after 5 minutes. That's how the Fly free tier nudges you toward billing. Once you're paying, set auto_stop_machines = "off" and min_machines_running = 1 if you want a long-running service.

4. fly proxy is fine for HTTP, weird for raw SSH. I burned half an hour on Connection reset by peer through fly proxy 12222:2222 before realizing I should just bash /dev/tcp/127.0.0.1/2222 from inside the machine via flyctl ssh console. The SSH server was healthy the whole time; the proxy path was the problem.

ANSI Shadow beats slant

The first banner I shipped used figlet's slant font. It looks fine in a docs file. At terminal width with full-block rendering, it falls apart into disconnected diagonals.

Swapped to ANSI Shadow, the same boxy block font terminal.shop and charm.sh use. Six rows tall, about 93 columns wide, reads instantly. Probably the kind of thing I'd have gotten right the first time if I'd looked at more references before opening figlet.

Visitor #N

One fun thing I added. Look at the bottom-left of the footer when you connect: it says visitor #N. First SSH session ever was #1, second was #2, and so on. The count lives in a tiny text file on the Fly volume next to the host key, increments once per channel_open_session, and persists across deploys (host-key lesson applied).

Implementation is about thirty lines. An AtomicU64 loaded from the file at startup, a spawn_blocking write after each fetch_add. The file is just a base-10 number with no header, so cat /data/visitor_count is the dashboard.

There's no leaderboard. No real meaning to the number. But watching it tick up after shipping is the moment the whole side project starts feeling worth it.

The stack

Layer	Tech
TUI	ratatui 0.29, crossterm 0.28
SSH	russh 0.60
HTTP client	ureq 2 (sync, plenty for this)
Async runtime	tokio 1
CLI args	clap 4
Host	Fly.io (`iad`, shared-cpu-1x, 256 MB, 1 GB volume)
DNS	Vercel Domains (A + AAAA on the apex)
Binary size	~3 MB release (macOS arm64), 4.3 MB (Linux x86_64)
Image size	28 MB (Debian bookworm-slim runtime)
Cost	$2/mo for the dedicated IPv4 + free tier for the rest

What's next

Pretty errors and loading states. Today they say Loading… which is functional but boring.
Project deep-links. I render project metadata but not the original write-ups. Pulling MDX through the API would let me ship long-form case studies in-terminal.
Cross-platform release binaries. The current install path is cargo install --path cli/. Homebrew tap + release artifacts for macOS and Linux is a Saturday morning.

Try it

ssh agnelnieves.sh

If you want to build your own version, the guide has the full setup (Rust + ratatui + russh + Fly.io), with a copy-paste prompt at the top so you can hand it to your AI agent of choice. If you ship one, let me know.

Built by Agnel Nieves, a design engineer with 15+ years across product, design systems, and crypto. More writing on the blog.

Optimizing Your Website for AI Agents and LLMs

Agnel Nieves — Tue, 14 Apr 2026 00:00:00 +0000

Your website has two audiences now. Humans, obviously. But also AI agents — LLMs that crawl, summarize, cite, and recommend your content to millions of people. If your site isn't optimized for both, you're leaving visibility on the table.

I just finished optimizing my personal site for AI consumption, and the process revealed something interesting: most of what makes a site good for AI also makes it better for humans. Clear structure, machine-readable content, and explicit metadata benefit everyone.

Here's what I did and why it matters.

What Are AI Agents Actually Doing with Your Site?

When someone asks ChatGPT, Claude, Perplexity, or Google's AI Overview a question, those systems don't just generate answers from training data. Increasingly, they fetch and cite live web content. Your site might get:

Crawled for training data by bots like GPTBot, ClaudeBot, and Google-Extended
Fetched at query time by Perplexity, ChatGPT browsing, and similar agents
Cited as a source in AI-generated responses
Summarized in featured snippets and AI overviews
Navigated by autonomous agents that interact with your APIs

Each of these has different needs, but they all benefit from the same foundation: structured, discoverable, machine-readable content.

The llms.txt Standard

The llms.txt spec is the equivalent of robots.txt for AI agents. While robots.txt tells crawlers what they can access, llms.txt tells them what your site is — a structured markdown index served at your domain root.

The format is simple:

# Your Name or Site

> A one-line summary of what this site is.

A longer description paragraph.

## Section Name

- [Link Title](https://url): Description of what's at this link

I implemented two variants:

/llms.txt — the index. A table of contents with links to all pages, blog posts, projects, social profiles, and feeds. Think of it as a menu for AI agents to browse selectively.
/llms-full.txt — the full dump. Every blog post's complete markdown content, every project description, biographical context. For agents that want to load everything into context at once.

Both are served as text/plain with markdown formatting. Both are generated dynamically from the same data sources that power the site, so they never go stale.

Inline LLM Instructions in HTML

This one comes from a Vercel proposal and it's clever: embed AI-readable instructions directly in your page's <head> using a script tag browsers ignore.

<script type="text/llms.txt">
# Your Site Name

This is the personal website of [name], a [role] based in [location].

## Site Structure
- / — Home: Description
- /blog — Blog: Description
- /about — About: Description

## Key Facts
- Name: Your Name
- Role: Your Role
- Specialties: Thing 1, Thing 2, Thing 3
</script>

Browsers skip <script> tags with unknown types. LLMs process them. It's a zero-cost way to give every page on your site a machine-readable context block. I added one to my root layout that describes who I am, the site structure, and where to find machine-readable content.

Structured Data That AI Engines Actually Use

JSON-LD structured data has always been important for Google. It's now equally important for AI engines. When an LLM encounters schema.org markup, it understands the semantics of your content — not just the text, but what the text represents.

I already had structured data for my blog posts (BlogPosting schema with breadcrumbs). What I added was CreativeWork schema for my portfolio projects, giving each project a machine-readable identity:

{
  "@context": "https://schema.org",
  "@type": "CreativeWork",
  "name": "Project Name",
  "description": "What this project is",
  "url": "https://project-url.com",
  "creator": {
    "@type": "Person",
    "name": "Your Name"
  }
}

The more schema types you cover, the more AI engines can understand and cite your work with proper attribution.

Machine-Readable Feeds

RSS is great, but it's XML — not the most natural format for AI agents to parse. I added a JSON Feed endpoint alongside my existing RSS feed:

/feed.xml — RSS 2.0 for traditional feed readers
/feed.json — JSON Feed 1.1 for programmatic consumption

JSON Feed is cleaner for AI agents to parse and reference. Both are registered in the site's metadata so they're auto-discoverable.

Making robots.txt AI-Aware

Most sites already have a robots.txt. The key addition is explicitly allowing AI crawlers and pointing them to your llms.txt:

User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

Sitemap: https://yoursite.com/sitemap.xml

# AI/LLM Content
# llms.txt: https://yoursite.com/llms.txt
# llms-full.txt: https://yoursite.com/llms-full.txt

Many sites block AI crawlers by default. If you want your content cited and discovered by AI, explicitly allow the major bots: GPTBot, ChatGPT-User, Google-Extended, ClaudeBot, anthropic-ai, PerplexityBot, Applebot-Extended, Bytespider, and cohere-ai.

Why This Matters for Creators

As a design engineer with 15+ years of building products, I've watched SEO evolve from keyword stuffing to semantic web to AI-native discovery. We're at an inflection point. The sites that get cited by AI aren't necessarily the ones with the best domain authority — they're the ones with the clearest, most structured, most machine-readable content.

This is especially important for personal sites and portfolios. When someone asks an AI "who are the best design engineers in Miami?" or "what's a good article about design tokens?", you want your site to be citable. That requires more than good content — it requires content that AI can find, understand, and attribute.

The Full Stack of AI Optimization

Here's the complete checklist of what I now have in place:

Layer	What	Why
`robots.txt`	Explicitly allow AI bots	Let them crawl
`sitemap.xml`	Dynamic sitemap with all content	Let them discover
`llms.txt`	Markdown index of the site	Let them understand structure
`llms-full.txt`	Full content in one file	Let them ingest everything
Inline `<script>`	Page-level LLM instructions	Let them understand context
JSON-LD	Structured data on every page	Let them understand semantics
RSS + JSON Feed	Machine-readable content feeds	Let them subscribe
Meta tags	OpenGraph, Twitter, canonical	Let them cite accurately

None of these changes affect how the site looks or feels for human visitors. They're invisible additions that make the site dramatically more useful for AI.

What's Next

The AI web is evolving fast. Standards like llms.txt are still emerging, and new patterns will appear. But the fundamentals won't change: structure your content clearly, make it discoverable, and give machines the metadata they need to understand it.

If you want to replicate this setup, I've published a full implementation guide with code examples for Next.js. The approach works for any framework — the concepts are universal.

Building something and want to talk AI optimization? Let's connect.

We Found a Hidden Pet System in Claude Code's Leaked Source and Shipped It Overnight

Agnel Nieves — Wed, 01 Apr 2026 00:00:00 +0000

On March 30th, 2026, Anthropic accidentally shipped a 59.8 MB source map file inside their Claude Code npm package. Within hours, the entire 512,000-line TypeScript codebase was mirrored across GitHub and picked apart by thousands of developers. Buried inside that code, alongside feature flags for autonomous agents and undercover commit modes, was something nobody expected: a fully built virtual pet system called Buddy.

My co-founder peroni and I did the only sensible thing. We shipped it.

We all know what happened yday with Claude Code. Buried in the source: a hidden pet system called "Buddy." Every user gets a unique pixel creature based on their ID. Deterministic, same hash, same buddy, every time. So @peronif5 and I did the most sensible thing... Shipped it.… pic.twitter.com/YE4ZSEIXq7
— Agnel (🇵🇷) (@agnelnieves) April 1, 2026

What Happened with the Claude Code Leak

If you missed it, here's the short version. Chaofan Shou (@Fried_rice) noticed that version 2.1.88 of the @anthropic-ai/claude-code package on npm included an unminified source map — cli.js.map — containing the full, readable TypeScript source. By 4:23 AM ET, it was public. By noon, the internet had catalogued every hidden feature, internal codename, and unreleased capability Anthropic had been quietly building.

Among the bigger discoveries:

KAIROS — an always-on daemon mode that lets Claude Code operate as a persistent background agent, watching, logging, and acting without waiting for user input
Undercover mode — auto-activated for Anthropic employees on public repos, stripping AI attribution from commits
44 feature flags covering unreleased functionality
And tucked away, a complete companion pet system called Buddy

The Buddy System: A Pixel Pet for Every User

The Buddy system was fully implemented. Every Claude Code user was supposed to get a unique pixel creature generated deterministically from their user ID. Same hash, same buddy, every time. The code included 18 species across rarity tiers, stat generation, personality descriptions — the whole gacha experience, just waiting to be turned on.

It was the kind of detail that makes you smile. In a tool built for productivity and code generation, someone at Anthropic took the time to build a pet system. A little pixel friend that lives in your terminal. That's the kind of craft and whimsy that makes developer tools memorable.

The moment I saw it, I knew what we had to do.

From Discovery to Deploy in a Day

Peroni and I have a rhythm. We spot something interesting, we build. No planning committee, no Jira tickets, no "let's circle back Monday." As a design engineer with 15+ years of shipping products, I've learned that the best side projects are the ones you can't not build. This was one of those.

We built Claude Buddy — a web app that lets anyone generate their own pixel companion. Type your name or your Claude Code user ID, and watch it draw your buddy pixel by pixel, complete with retro CRT animations and pop sounds.

Here's what we shipped:

12 unique pixel art species across 5 rarity tiers — from common Blobbits to the legendary Nebulynx (3% chance)
Deterministic generation — same name always produces the same buddy, making them feel like yours
Shiny variants with a 5% drop rate, because of course
Buddy stats — Vibe, Chaos, Focus, and Luck, each randomly rolled but consistent to your hash
One-command terminal install — curl a script and your buddy appears in your Claude Code statusline
Social sharing — download as PNG, share via URL, generate QR codes, post to X/LinkedIn with pre-populated text

The whole thing runs on Next.js 15, renders sprites on HTML5 Canvas, and uses a Mulberry32 PRNG seeded by a DJB2 hash of your input. No backend, no database, no authentication. Pure deterministic fun.

Why Build This?

Partly because it's fun. Partly because of how I approach creative work — I try to ship a hackathon-style project every quarter to stay sharp and experiment with new patterns. But mostly because I think the Buddy system represents something important about how we relate to our tools.

Developer tools don't have to be purely utilitarian. The best ones have personality. They reward curiosity. They make you want to open the terminal. A pixel pet that lives next to your cursor won't make you a better programmer, but it might make the work feel a little less solitary.

Anthropic clearly felt the same way — they built the whole thing, ready to ship. We just opened the door a little early.

How the Generation Algorithm Works

For the technically curious, the generation is straightforward:

Take the input string (name or user ID), lowercase and trim it
Salt it with a fixed string to avoid collisions
Run a DJB2 hash to convert it to a numeric seed
Feed that seed into a Mulberry32 PRNG
Roll for species (weighted by rarity tier probabilities)
Roll for shiny status (5% chance)
Generate four stats between 1 and 99
Select a soul description from the species pool

Same input, same seed, same rolls, same buddy. Every time. No server involved.

It's Open Source

The entire project is open source on GitHub. Built by the Basement team. Fork it, remix it, hatch your own buddy.

If you want to see what came out of this, check the thread on X where we announced it. And if you're building with Claude Code, maybe your buddy is already waiting — just type your name and find out.

Have thoughts on this or want to collaborate on something weird? Let's connect.

The AI-Native Design Gap: From Static to Dynamic Experiences

Agnel Nieves — Thu, 16 Oct 2025 00:00:00 +0000

Here's something I see all the time: teams spend weeks perfecting static mockups in Figma, present them with confidence, and then watch as stakeholders nod politely but don't quite get it. Why? Well, we're designing static artifacts for dynamic experiences.

Every scroll, swipe, and tap in a real product triggers visual feedback. It's how users actually understand what's happening. Yet we keep pitching ideas as if they exist in freeze-frame.

The AI-Native Design Challenge

This gap matters more than ever, especially if you're working on AI-native products. Whether it's OpenAI's ChatGPT, Perplexity's search interface, or Claude's conversations—these products are rewriting the rules of digital interaction. They're introducing entirely new patterns: streaming responses, conversational flows, adaptive interfaces that feel less like traditional apps and more like living dialogues. Even more so if the interactions include voice motion which is supposed to react to the user's voice.

You can't capture that in a static frame. You have to show it in motion.

Why Interaction Design Is an Unlocked Skill

Here's the thing about motion and interaction design: it's a toolkit you unlock through experimentation, not strictly tied to theory or studies. You learn it by thinking about physics, natural movement, user intent—concepts you absorb from using dozens of different apps and noticing what feels right. Think about it, try to explain a motion ui pattern to someone, try to explain the core concept of what you have in your mind. It's difficult… It's open to interpretation of the person to whom you're explaining it to, and limited by their imagination (which is highly likely different from yours).

This creates a knowledge gap. Most designers haven't had the chance to experiment enough with motion to build that intuition. But here's what I've learned: even designing interactions frame-by-frame, storyboard-style like old Disney animations, can be enough to transform how you communicate ideas. It forces you to think through every transition, every state change, every moment of feedback.

And it doesn't just help you—it helps engineering understand exactly what you're trying to build.

Design Is Taking the Spotlight Again

We're in an exciting moment. With AI tools and no-code platforms, pretty much anyone can spin up a functional prototype. The technical barrier to entry has lowered significantly.

What does that mean? Design becomes the differentiator. When everyone can build something that works, the products that win are the ones that feel incredible to use. Motion, polish, and thoughtful interaction patterns aren't nice-to-haves anymore—they're what separates successful products from forgettable ones.

My Approach: Build to Learn

I try to ship a hackathon-style project every quarter. Not because I need more side projects, but because it's the only way to stay ahead and fresh. New patterns emerge constantly. AI products iterate at light speed. Existing products unveil interactions you never even considered.

The only way to keep your intuition sharp is to experiment relentlessly with what's out there.

This comes from personal experience. My background has helped me a lot in this area—I started as a designer, shifted to software engineering, and eventually came back to design. That engineering foundation changed everything. I can quickly prototype motion patterns directly in code (often faster than in design tools), play with them until something clicks, then bring those learnings back to Figma to polish everything together.

This workflow might sound backwards, but to me, it makes sense and it just works: code/define the motion first, design and polish last. Code gives you the freedom to experiment rapidly. Spin up prototypes quickly, and gather feedback. Design tools give you the precision to perfect it.

The Practical Takeaway

If you're trying to sell an idea—whether to stakeholders, users, or investors—don't stop at static screens. Invest time in showing how it moves. Show how it responds. Show how it feels.

You don't need to be an engineer to do this. Start simple:

Sketch interaction sequences frame-by-frame
Use Figma's prototyping features to simulate key transitions
Try tools like ProtoPie, Lottie Lab for more complex motion
Or, if you're comfortable with code, prototype directly in React or HTML

The medium matters less than the commitment: design for motion, not just for pixels.

Because in an era where AI is democratizing creation, the products that win won't just work—they'll feel magical. And you can't explain magic in a static mockup.