DEV Community: Harjot Rana

Testing React components against the worst case

Harjot Rana — Mon, 19 Oct 2026 14:47:09 +0000

I wrote this with AI help and edited it myself. Every example is a real fixture from the Brio UI repo.

The demo for a component is always a good day. Three plan names that fit, prices in dollars, an FAQ with six short questions in English. You build to that demo, it looks right, and you ship.

Then someone pastes a German product name into the pricing card, or the FAQ grows to 120 entries, or the page gets translated into Arabic. That is the first time the component sees real data, and it's usually on a phone.

I build Brio UI, a library of 50 React components, and I stopped trusting demo data a while ago. Every component now has a second fixture whose only job is to break it. This post is the method. You can copy it into any component library or app.

Two fixtures per component

The idea comes from Emil Kowalski: try to break the component with the worst plausible real-world data, screenshot it, then fix what breaks.

In practice each component gets a file next to it, <slug>.stress.tsx, with three exports:

import type { ComponentType } from 'react'

export type StressModule = {
  Best: ComponentType   // the demo's data, no controls
  Worst: ComponentType  // same props shape, the nastiest plausible data
  cases: string[]       // one line per thing Worst throws at it
}

Best and Worst use the same public props. That rule matters. If the worst case needs a special prop or a patched component to render, you are testing a different component.

cases is a plain list of strings, shown on the test page above the fixture. It doubles as documentation: anyone can read what the component was tested against without opening the code.

What goes into the worst case

I keep a checklist of axes and go through every one that applies:

Long and unbroken text. Long titles and labels, plus strings with no spaces: URLs, email addresses, hashes, German compounds.
Big numbers and many items. 9,999,999 and 1e9, 120 rows instead of 6, and also the one-item and empty cases.
Missing optional fields. No avatar, no description, no date. Very short values like "Jo".
Scripts and direction. Japanese with no spaces, Arabic in a right-to-left page, Hindi, emoji sequences, combining marks.
Dates and time zones. Leap days, year 9999, an invalid date string, a negative offset.
States. Loading, error, disabled, expired, over the limit.

Here is part of the FAQ's list, as it appears in the file:

export const cases = [
  '120 questions, type multiple, 4 open on mount (+1 unknown id)',
  '200-char question with a 79-char German compound',
  'unbroken 130-char URL as a question, and inside answers',
  'emoji-only question (slug falls back to faq-question-N)',
  'Zalgo combining marks, very short "Jo?"',
  'javascript: contactHref (should be hidden)',
  'items = [] with search on (renders nothing)',
]

The changelog's worst case has 68 releases, a 65-character semver with build metadata, a leap day that doesn't exist (2026-02-29) and the string "not a date" as a date. The contact form gets a 78-character email address and an onSubmit that throws an empty error.

Two rules keep the fixtures useful. They must be deterministic, so no Date.now() or Math.random() during render; fixed date literals only. And if the component crashes on some input, the input stays in the fixture with a CRASH: note in cases. An error boundary shows the crash on the page. Hiding it defeats the point.

Looking at it

All fixtures load on one test page, #/stress/<slug>, with three modes (demo data, worst case, side by side) and three widths (full, 480 px, 360 px). The frame around the fixture never scrolls or clips. If something is too wide, it spills past a dashed edge where you can see it.

Then I take screenshots of the worst case and write down what is wrong: overflow, overlap, clipping, text wrapping into one-word lines, misalignment, unreadable contrast. Each gets a severity and a likely fix. Only then do I change the component.

Some of what this caught on the way to release:

The contact form's worst case had 713 tap targets under the size I aim for. After the fix it had none.
The pricing toggle truncated long plan names. It wraps them now.
A comparison table clamped feature labels to three lines on narrow screens. That hid the end of long labels and clipped an Arabic word by 8 px. Labels now wrap in full.
The FAQ needed a 70-character measure, code that wraps on narrow screens and a list that doesn't trap the scroll.

The demo data for each of these looked fine the whole time.

Keeping it fixed

A fix you made once tends to break again three weeks later, when you change a padding value for an unrelated reason. So once a worst case looks right, I store screenshots of it as baselines: the Worst fixture at 320 px wide, in light and dark.

A script takes the same shots again on every run and compares them pixel by pixel. A pixel counts as changed when any colour channel moves by more than 32 of 255, which ignores anti-aliasing. A shot fails when more than 0.1% of its pixels change, or when its height changes by more than 4 px, because a height change means something re-wrapped. The same pass checks that the page's scrollWidth stays at 320 px, so horizontal overflow fails even if nothing else moved.

For scale: the pricing toggle's worst case is 320 by 2,820 px, so 0.1% is about one short word. Making a single plan name one line longer changes 12.5% of the image and fails.

Baselines depend on the browser build and the installed fonts. After a Chromium upgrade I refresh them all and look at every image before committing. When a visual change is intended, the new baseline goes into the same commit, and the image diff in the pull request becomes the review.

A slow CPU is a worst case too

Data isn't the only thing that can be worst-case. The same fixtures also run against a production build with the CPU throttled 10 times. A component that has finished animating should cost nothing at idle: no requestAnimationFrame loops, and infinite animations stay in CSS. Entrance staggers are capped, and long lists render in pages.

Try it on one component

You don't need a library to start. Pick the component in your app that shows user data, write a Worst next to it with the same props, and open it at 320 px. Go through the checklist above. It takes about an hour, and the first run usually finds something.

If you'd rather start from components that have already been through this, Brio UI's 10 free components are MIT and install with npx brio-ui add <name>. Pro launches in November, and joining the waitlist before 30 Nov gets you 50% off every Pro purchase.

I built a free desktop GUI for Muse Code, Meta's coding agent CLI

Harjot Rana — Sun, 11 Oct 2026 04:49:10 +0000

I'm the maker of Helicon. It is a free, MIT-licensed desktop app for Muse Code, Meta's coding agent CLI. It is unofficial and not affiliated with Meta.

Why I built it

Muse Code is good, but a terminal is a poor place to review a long agent run. I wanted my threads in one place, edits shown as diffs, and approvals one at a time. So I built a GUI that drives the muse command you already have.

What it does

Threads from every project sit in one sidebar.
Edits show as inline diffs where they happened.
Approvals come one at a time.
Workflows, side chats and SSH projects are built in.
A usage page prices each thread at published API rates.
It runs on Windows, macOS and Linux, and there is a VS Code extension.

It uses your existing muse login. There is no API key to add and no second bill.

How it is built

The desktop app uses Tauri. It talks to Muse Code over its session protocol, so there is no screen scraping.

Try it

It is young (v0.21.5) and I would like to hear what breaks. Issues and PRs are welcome.

Muse Code in VS Code and Cursor: a side panel instead of a terminal

Harjot Rana — Fri, 09 Oct 2026 21:31:06 +0000

Muse Code is Meta's coding agent, and it lives in the terminal. That works until you have three threads going, an approval prompt has scrolled out of view, and you can't tell which thread touched which file.

I built Helicon to fix that for myself. It's an open-source (MIT) side panel for the Muse Code CLI that runs in VS Code, Cursor, Windsurf and Antigravity. It's unofficial: I'm not affiliated with Meta, and Muse Code itself does all the agent work.

What it is

Helicon drives the muse CLI you already have, with your own login and plan. There's no API key to paste, and the extension stores no credentials.

When you open the panel, the extension starts a small local server on your editor's own Node runtime, bound to 127.0.0.1 only. That server runs muse serve and talks to it over MSP, the protocol Muse Code speaks to its clients. So you get the same models, the same tools and the same approval rules as in the terminal. Nothing is sent anywhere except to Muse Code itself, and the extension has no telemetry.

Setup (about 5 minutes)

Install the muse CLI and run muse login once. You need a Muse Code plan or pay-as-you-go billing on Meta's Model API; the free Muse app doesn't include Muse Code.
Install Helicon:
- VS Code: Visual Studio Marketplace
- Cursor, Windsurf, Antigravity, VSCodium: Open VSX, or search "Helicon" in the Extensions view
Click the Helicon icon in the activity bar, or press Cmd+Alt+H on macOS or Ctrl+Alt+H on Windows and Linux. The panel opens on the folder you have open.
Type what you want changed. Each new thread opens as a tab.

If the panel says it can't find the CLI, the CLI-not-found guide covers the PATH fixes for each OS.

Working on another machine? In a Remote-SSH, WSL or dev container window, the extension runs on the remote side, next to your code and its muse install, and the editor forwards the port for you.

Want to look before you install? There's a browser demo on sample data.

Three things it does that the terminal doesn't

1. Approvals you can read

When Muse Code wants to run a command or edit a file, Helicon shows you the exact command, or the edit as a diff, before it runs. You allow or deny it, or let the thread run without asking until you close Helicon. No more approving things because the prompt was half off-screen.

2. The files each thread changed

Each thread lists the files it changed, one click from opening them, and the diffs sit inline at the point in the thread where the change happened. When you come back to a thread after lunch, you can see what it did without running git diff and guessing which thread did what.

3. Every thread for the folder, and your usage

Open threads sit as tabs across the top. History lists every earlier thread for the folder, grouped by day and searchable, including the ones you started in the terminal. Reopen any of them with its turns, tool calls and diffs. The panel also shows your 5-hour and weekly plan windows, and what each thread would have cost at API rates.

It also understands Muse Code monitors: a thread that's watching a build or a pull request's checks says so, with a Stop button, and the turn a monitor woke up is marked.

Recommend it to your team

If your team uses Muse Code, add Helicon to the repo's recommended extensions. VS Code and the editors built on it then suggest it to anyone who opens the folder.

Create or edit .vscode/extensions.json:

{ "recommendations": ["harjjotsinghh.helicon"] }

Each person still uses their own muse login and plan. Nothing about accounts is shared through the repo.

A few commands worth knowing

Helicon: New Thread in This Folder, from the Explorer's right-click menu, starts a thread in any subfolder.
Helicon: Open Full Helicon in Editor opens the full app, with every project, in an editor tab.
Helicon: Show Log gives you the server output for bug reports.

The unofficial part

Helicon is a community project. It's not made, sponsored or endorsed by Meta. "Muse Code" is Meta's trademark, used here only to say what Helicon works with. The code is MIT-licensed and on GitHub, and there's also a desktop app for Windows, macOS and Linux if you'd rather keep it out of your editor.

If something breaks, open an issue with the output of Helicon: Show Log. This week I'm answering issues within a day.

How to run Muse Code on a remote server over SSH, with a desktop GUI

Harjot Rana — Mon, 28 Sep 2026 04:59:12 +0000

Your code lives on a server: a beefy dev box, a cloud VM, the machine under your desk. You want Muse Code to work there, where the files, the toolchain and the CPU are. But you'd rather not spend the day in an SSH terminal scrolling back through agent output.

Helicon 0.18 adds SSH projects: you pick a folder on a remote machine, and Helicon runs Muse Code there over ssh, while you get the desktop app on your laptop: threads in a sidebar, readable approvals, and inline diffs.

This guide sets it up in about 10 minutes.

How it works

When you start a thread in an SSH project, Helicon runs this on your laptop:

ssh <host> 'cd /path/to/project && exec muse serve'

Muse Code runs on the server, inside the project folder, and talks to Helicon over the SSH connection using the Muse Session Protocol (MSP), the same protocol it speaks to any local client. Nothing is synced or copied: the code never leaves the server.

A few consequences worth knowing:

The server's Muse login is the one used. Whatever account you signed into with muse login on the server is what your SSH threads run on. Helicon's local account profiles don't apply to SSH projects.
Your laptop needs to stay connected. Muse runs as part of the SSH session, so if your laptop sleeps or the network drops, that session ends. Helicon notices within about 45 seconds.
Your SSH config is respected. Host aliases, ports, users, jump hosts and keys all come from ~/.ssh/config, the same as when you type ssh yourself.

1. Make `ssh` work without a password

Helicon never types a password or answers a prompt; it runs ssh in batch mode. So the first step is a key.

On your laptop:

ssh-keygen -t ed25519            # skip if you already have ~/.ssh/id_ed25519
ssh-copy-id you@devbox.example.com

Then give the host a short name in ~/.ssh/config:

Host devbox
  HostName devbox.example.com
  User you
  IdentityFile ~/.ssh/id_ed25519

Check it: this should print ok without asking you anything.

ssh devbox echo ok

If it asks you to confirm the host key, answer yes once. Helicon can't answer that question for you, and will tell you so if you skip it.

On Windows: Helicon uses Windows' own OpenSSH (ssh.exe), not the one inside WSL. Keys and config belong in %USERPROFILE%\.ssh. If your keys only live in WSL, copy them over, or run ssh-keygen in PowerShell.

2. Install Muse Code on the server

On the server, install the muse CLI the way you normally would, then sign in once:

muse login

Now make sure muse is on the PATH for non-interactive SSH commands, which is what Helicon uses. From your laptop:

ssh devbox 'command -v muse'

If that prints nothing, your shell only sets PATH for interactive logins. Add the folder that holds muse to your PATH in ~/.zshenv (zsh) or near the top of ~/.bashrc (bash), and try again.

3. Add the project in Helicon

Open Helicon (0.18 or newer) and click Add project.
Choose SSH host.
Type the host: devbox, or you@devbox.example.com.
Browse the server's folders, starting at your home folder, and pick the project.

The project shows up in the sidebar like any other. Start a thread, and Muse Code is working on the server.

When something goes wrong

Helicon reports what ssh itself said, so the error usually tells you the fix:

Helicon says	Fix
Host key verification failed	Run `ssh devbox` once in a terminal and accept the host key
Permission denied (publickey)	The key isn't on the server: rerun `ssh-copy-id`, or check `IdentityFile`
Could not find ssh on this machine	Install OpenSSH (on Windows: Settings, Optional features, OpenSSH Client)
Connection refused / timed out	Check the host, port and VPN with `ssh devbox echo ok`
Muse not found when starting a thread	`ssh devbox 'command -v muse'` prints nothing: fix PATH as in step 2

What SSH projects don't do yet

In 0.18, SSH projects run threads, show diffs and approvals, and list past sessions from the server. These aren't available for them yet:

the file viewer panel
the skills list
attaching files (images still work)
creating a new remote folder or cloning a repo onto the server from Helicon

Create folders and clones over SSH first, then add them.

SSH projects or the remote daemon?

Helicon has two ways to use a remote machine:

SSH projects (this guide): the Helicon app runs on your laptop, and only Muse runs on the server. Mix local and remote projects in one window.
Remote daemon: the whole Helicon server runs on the remote machine, and you open it in a browser. Better when you want to reach it from any device.

Try it

Helicon is free and open source (MIT) for Windows, macOS and Linux: helicon.sh. SSH projects were contributed by Hoà Dinh in #56.

Helicon is an unofficial community project, not affiliated with Meta.

I built a desktop app for Meta's Muse Code CLI, and the billing is the whole story

Harjot Rana — Tue, 15 Sep 2026 23:25:08 +0000

Meta shipped Muse Code in August: a coding agent that lives in your terminal, with a subscription starting at five dollars a month. The model is good. The harness runs subagents in parallel and keeps an append-only event log you can replay.

Two things about it bothered me enough to spend a fortnight on them.

It is terminal-only. And on Windows there is no native build at all, so several comparison guides now tell readers that if they are on Windows or want a desktop app, they should pick a competitor.

So I built Helicon: an open-source desktop and web client for the actual Muse CLI. This post is about the one design decision that shaped everything else, because it is the part I got wrong first and the part most people get wrong when they wrap a CLI.

The mistake I made first: scraping the terminal

The obvious way to put a UI on a CLI is to spawn it in a pty, parse what comes out, and render that.

I did this. It took an afternoon and it worked, in the way that a demo works.

Then I tried to implement approvals. The agent wants to run npm test, and the user needs to allow or reject it. In a scraped terminal, "the agent is asking for approval" is a string you pattern-match out of ANSI escape codes, and your answer is keystrokes you write back into a pty. You are inferring a security decision from formatted text. Every output tweak upstream becomes a correctness bug in your client, and some of those bugs run commands nobody approved.

I deleted it.

What replaced it

Meta publishes the Muse Code SDK, MIT licensed, for programmatically driving Muse over the Muse Session Protocol. The CLI itself exposes muse serve, which speaks that protocol over stdio.

So Helicon's daemon spawns one muse serve host per workspace and talks MSP to it through the official SDK. Muse is the agent. Helicon is a client.

That means approvals arrive as protocol events, not as parsed text. Diffs arrive as structured data. Sessions that were started in the terminal show up in the sidebar with their history, because the CLI already wrote them to disk in a format the protocol can read back. Nothing is inferred from what the screen happened to look like.

The rule I would give anyone wrapping a CLI: if the vendor documents a protocol, the protocol is the only surface that stays where you left it. Output formatting is not an API, no matter how stable it looks today.

The part that decides your bill

Here is the thing I did not expect to be the most important feature.

Muse Code subscriptions only bill through Muse's own harness. If you point a generic OpenAI-compatible client at the API, you are on pay-as-you-go rates instead. Same model, different bill.

I have watched people work this out the hard way in public and reach the wrong conclusion. One thread has a user stating, twice, that a Muse Code subscription "can not be used in any kind of GUI harness" and that you have to go pay-as-you-go to use it anywhere but the terminal. Another person in the same thread confirms the symptom: using the vendor's harness deducts from the plan, and every other option lands on the API.

The observation is correct. The conclusion is not.

The subscription is not terminal-locked. It is harness-locked. Once you stop trying to replace the harness and start driving it instead, a GUI costs nothing extra, because the work is still going through Muse with your own muse login.

That is the entire argument for this architecture, and it is worth more than any UI feature I could build. If your wrapper reimplements the agent loop against the raw model API, you have quietly moved your users onto a second bill for a model they already pay for.

Windows, honestly

Muse has no Windows binary. That is not something a client can fix.

What Helicon does is more boring than "Muse Code on Windows" sounds. The daemon runs natively on Windows, and when it needs the agent it runs:

wsl -d Ubuntu -- muse serve

Then it translates paths in both directions, because the daemon thinks in C:\Users\you\project and the agent thinks in /mnt/c/Users/you/project. Get that wrong and every file operation lands somewhere plausible and wrong.

export function toWindowsPath(wslPath: string): string {
  const match = wslPath.match(/^\/mnt\/([a-z])\/(.*)$/);
  if (!match) {
    throw new Error(`Cannot map to Windows: not a /mnt/<drive> path: ${wslPath}.`);
  }
  const drive = match[1].toUpperCase();
  const rest = match[2].replace(/\//g, "\\");
  return `${drive}:\\${rest}`;
}

Note the throw. An unmappable path is a bug, not a thing to guess at.

So WSL2 is still required, and I say that on the landing page, in the install steps and in the FAQ. What changes is not the requirement. It is that you stop living in an Ubuntu terminal on your own machine to use a tool you pay for. The installer is signed and auto-updates, which on Windows matters more than people from other platforms expect.

Bundling the runtime

The daemon is Node. Until last night, that meant a user had to install Node 22 or newer before Helicon would start, and on Windows they had to install it on the Windows side rather than inside WSL, which is exactly the kind of instruction that loses people.

The fix is a Tauri sidecar. A build script downloads a pinned Node build, verifies its SHA256 against the published checksums, and drops it in src-tauri/binaries/node-<target-triple>. For universal macOS builds, lipo merges the two architectures. At boot the app prefers the binary next to its own executable and only falls back to a system Node if that is missing.

It costs about 30MB on the Windows installer. It removes an entire step from the install instructions, and an entire category of "it doesn't launch" issue. Worth it.

One detail worth copying: the bundled runtime's folder is deliberately left off the PATH handed to subprocesses. Users run shell commands through the app, and their node should be their node, not mine.

What it looks like

Projects grouped by folder, worktrees included. Threads with inline diffs where the edit happened. Approvals surfaced the moment they arrive, never batched, never bypassed. A cost view that shows what each thread would have cost at published API rates, so "is this plan worth it" becomes a number instead of a feeling. Command palette, slash commands, full keyboard operation.

The same React UI ships twice: as a Tauri desktop app, and as a web app pointed at a remote daemon. One codebase, two shells.

Honest gaps

The macOS builds are not Apple-notarized yet, so the first launch needs a right-click and Open. Linux has no packaged build, only a source path. The SDK is a developer preview, so the protocol can move under me. And Helicon is not the only GUI in this space — there are several, including ACP adapters for Zed and JetBrains, and an unofficial VS Code extension. If you want Muse inside your editor, use those. Helicon is for people who want a standalone workspace.

It is free, MIT licensed, and unofficial: not made, sponsored or endorsed by Meta.

github.com/HarjjotSinghh/helicon · helicon.sh

If you use Muse Code on Windows, I would like to know what breaks. That is the platform I have tested most and can verify least.

I mined 1,398 corrections out of my coding agent logs and turned them into a rules file

Harjot Rana — Thu, 10 Sep 2026 13:08:17 +0000

My coding agent asks me the same things constantly. New file or add to the existing one. Do you want a test for this. Should I clean up the function next to the one I am touching.

I have answered all of these. Dozens of times. The answers were sitting in my chat history and nobody, me included, was reading them back.

So I wrote a tool that does.

What it actually is

jot is an extractor plus a knowledge base. The extractor finds the session stores your coding agents leave on disk, reads them, and pulls out the moments where you stopped the agent and said no, do it this way instead. Those get clustered into rules, each with a reason and a stated exception, and written to markdown.

You load that markdown as an agent skill. Your agent reads it before it starts working.

npx skills add HarjjotSinghh/jot -g

Then in any agent that supports Agent Skills:

/jot should this state be global or local?
/jot review this PR
/jot which model should these subagents run on?

That command installs mine, which is really a worked example. The part worth your time is pointing the extractor at your own logs.

No training. No GPU. No fine-tune. Text files.

The version I sat on for a year

For about a year I wanted to fine-tune a small model, 8B to 20B, on every file I own. Text, audio, PDFs, spreadsheets, decks. A model of me, trained on me.

I never wrote a line of it. Not once did I open a terminal.

Then I read Kun Chen's post about distilling himself into a skill, and the thing that clicked was that the hard part of "clone yourself" was never the weights. It was the preferences. And preferences are small enough to just write down.

By preferences I mean the boring calls with no correct answer, only my answer. Refactor now or ship and come back. Test first or backfill before merge. Ask before touching anything with real users on it, or just go. A generic model has a sensible default for every one of these. Several of mine are not the default, and that gap is the entire reason the agent keeps interrupting me.

Do not interview yourself

The obvious way to build this is to sit with a model and answer questions about how you work. It produces beautiful, useless output, because everyone is aspirational about themselves.

Ask me if I write tests first and I will say yes with a straight face. Look at what I actually shipped and you find spikes with no tests and coverage backfilled right before merge. The second version is the true one.

So I skipped the interview and went to the logs.

The highest-value thing on my disk is not my code. It is every time I typed something at an agent that was one keystroke away from doing the wrong thing. Every agent saves those. Nobody reads them back.

The extraction

Six adapters: Claude Code JSONL, Codex rollouts, Grok history, Gemini CLI logs, OpenCode, and Cursor, which stores every message as a row in a 1.5 GB SQLite file.

python scripts/extract_corpus.py
python scripts/extract_corpus.py --agents claude codex cursor --min-score 5

The pipeline:

Normalize everything to turns. Six agents, six schemas, one shape.
Pair each thing I said with the agent turn it was reacting to. "No, not like that" is meaningless on its own. It only carries information next to the thing it rejected.
Score against a lexicon weighted toward corrections, rejections, and stated preferences.
Dedupe hard, because I complain about the same three things constantly and 40 instances of one gripe is one rule, not 40. First pass: 1,398 distinct judgment events across 1,290 conversations. 505 corrections. 380 stated preferences.

Every rule in the knowledge files carries an evidence tag pointing back at the source:

[observed Nx] extracted from N distinct real sessions, dated
[stated] I wrote it down as a rule
[inferred] derived from adjacent behaviour, lower confidence, flagged at use time A rule with no evidence is a vibe. If it cannot be traced, it does not go in.

Layout

A thin skill stub, and a knowledge base that lives in the repo.

skills/jot/SKILL.md   loader; local checkout first, raw repo URLs second
ENTRY.md              routing table plus the decision procedure
PRINCIPLES.md         durable rules that survive a framework change
ENGINEERING.md        backend, debugging, git, review
FRONTEND.md           visual taste, design parity, slop detectors
AGENTIC.md            model routing, autonomy grants, parallelism
WORKFLOWS.md          named sequences: feature, bug, refactor, review, EOD
TOOLS.md              what I reach for, and the friction I hit
BOUNDARIES.md         hard stops, read before anything outward-facing
VOICE.md              how I write; loaded only for text going out under my name
OPERATING.md          attention, cadence, escalation
CONTEXT.md            who I am, what is active
state/                mined evidence, changelog, pending promotions
bench/                the benchmark that says whether any of this works

The stub never changes. All churn happens in the knowledge files, so every agent pointed at the repo stays in sync without a separate update step.

private/ and state/evidence/ are gitignored and never fetched over the network. The public layer holds preferences. The private layer holds the specifics that make them actionable: named colleagues, clients, money, positioning. The skill only loads those from a local checkout.

Does it work

A rules file that sounds like you but decides differently is worse than no file at all. It makes confident wrong calls in your name and you are not there to catch them. So bench/ answers the question properly.

Three arms. A control model with no skill. The same model with /jot loaded. And me, answering blind.

python scripts/bench_run.py --set v1
python scripts/bench_score.py --run <timestamp>

Ten questions, each one a decision where a competent generic model has a plausible default that is not what I actually do. Both model arms run in clean-room sessions that never saw the conversation where the rules were written, because a session that helped write the answers already knows the answers. Their responses go into sealed files I do not open until I have committed to mine.

Scored 0 to 2 against my answer. Minus one for fabricating a preference I do not hold.

First run: skill 13/20, control 7/20.

The number that matters is the delta between the two model arms. A skill that scores well only because any competent model would have scored well is recording things that did not need recording.

Then I sorted the results by where each rule came from

I had written two kinds of rules without really noticing. Ones mined out of real transcripts, and ones I had simply believed about myself and typed in.

mined from transcripts:  2, 2, 2, 2
believed about myself:   0, 1, 0, 0

No exceptions in either direction. The mined rules carried the entire gain. Everything I had assumed about myself was dead weight or actively wrong, and it was wrong in exactly the same confident tone as the stuff that was right.

The worst one: my file said that once I give a blanket approval, the agent should stop asking. I had generalized that from exactly one line I typed mid-task, once. The benchmark asked what to do at a sub-decision that approval never covered. The skill told the agent not to ask. My real answer was "I would ask first."

One occurrence is an anecdote. My own precedence rules say three occurrences make a rule. I broke my own precedence rules inside the file that contains them.

That is how this goes wrong. Not by being wrong about you. By being right about you in one situation and then applying it everywhere.

Patched four rules, re-ran, 18/20

And one question that had scored 2 dropped to 0.

The rule I added to fix "just take the two-hour refactor now" got applied to a two-minute fix on a live customer list. Which is the opposite of what I do, because that is not my code and those are somebody's real customers.

A rule that fixes one case and breaks another is written too broadly. Misses now become golden cases in bench/golden/, and each one turns into a rule with an explicit Doesn't apply when line. Boundaries outrank every principle in the repo instead of politely tie-breaking with them.

What it is like to use

Uncanny. Not "wow, impressive model" uncanny. Specifically: you ask it something you have never thought about before, it answers, and you get a small jolt of yes, that is exactly what I would have done, and that is exactly why.

It is talking to yourself, except this version of you has read every correction you have ever issued and never gets tired.

It disagrees sometimes, and the disagreements turned out to be more useful than the agreements. It was never being stupid. It was faithfully applying a rule I had written badly. The gap between the two model arms measures my preferences. The gap between the skill and me measures my writing. Two different problems, fixable separately.

Worth doing even if nobody else installs it. Writing a rule with a reason, a stated exception and a piece of evidence forces you to find out whether you actually hold it. A few of mine did not survive the format.

Not bad for an idea I sat on for a year because I thought it needed a GPU.

Try it

npx skills add HarjjotSinghh/jot -g

Repo: https://github.com/HarjjotSinghh/jot

Prior art: https://github.com/kunchenguid/kun, which made the case that the repeatable part of your judgment is worth externalising, and that it was never the part that was your moat. Read Kun's first.

If you run the extractor on your own logs, I want to know two things. How many events it found, and how many of the rules you wrote by hand survived contact with a benchmark. My guess is fewer than you expect.

How we built a 14-agent pipeline that ships a deployed app + launch assets in ~7 minutes

Harjot Rana — Mon, 01 Jun 2026 01:54:28 +0000

Most AI app builders stop at "deployed." You prompt, you get a repo, maybe a preview URL, and then the actual work starts: wiring a domain, writing the landing copy, cutting screenshots, drafting the launch thread. We wanted the pipeline to stop at "launched" instead, so we built one. This is how it works under the hood, including the parts that broke.

The product is Moonshift. One prompt triggers 14 specialized agents across 10 phases. Average run is ~7 minutes and ~$3 in API spend, with a hard $5 ceiling that aborts the run. Everything ships to your Vercel, your GitHub, your database. This post is the engineering, not the pitch.

The core problem: parallel agents drift

The naive version of "many agents build an app" falls apart fast. If a backend agent and a frontend agent both work from a vague English spec, they invent incompatible contracts. The backend returns { user_id }, the frontend reads userId, and you find out at runtime in production.

Our fix is a planner that emits a JSON contract first. Before any code is written, one agent produces a typed contract: routes, request/response shapes, table schemas, env vars, page list. That contract is the single source of truth. Backend, frontend, database, and test agents all build against it in parallel instead of against prose.

Then a contract-validator agent runs after the parallel build and diffs the actual code against the contract. When the frontend's fetch shape doesn't match the backend's handler, the validator doesn't just flag it. It patches the mismatch. This one agent removed the largest single class of "looks done, 500s on click" failures we had.

The 10 phases

Plan - generate the JSON contract.
Scaffold - lay down the framework skeleton (Next.js, config, deny-globs that protect files agents shouldn't touch).
Backend - API routes and server logic against the contract.
Frontend - pages and components against the same contract.
Database - schema + migrations (Drizzle + Turso).
Validate - contract-validator reconciles 3-5 in parallel, auto-fixes drift.
Test + fix - generated tests run; a fixer loop addresses failures.
Deploy - ships to your Vercel via your token.
Audit - security and a11y passes on the live deployment.
Market + publish - a marketer agent drafts X and LinkedIn launch posts in your voice, image-gen produces hero images, and a publisher gates everything behind your one-tap approval.

The interesting phases are 6, 7, and 10. Everyone has a code-gen step. Almost nobody has a reconcile step, a real fixer loop, or a phase whose only job is launch assets.

Reliability: not every failure is equal

Long multi-agent runs fail in boring ways: a rate limit, a flaky deploy, a model that returns prose where you asked for JSON. If you retry all of them the same way, you either give up too early on transient errors or burn money death-looping on deterministic ones.

We run a failure classifier that buckets every failure into transient, deterministic, or permanent:

transient (429s, network blips, stream idle) - retry with backoff.
deterministic (a test that fails the same way every time) - hand to a fixer agent, don't blindly retry the same call.
permanent (bad auth, missing token) - stop and surface it. No point spending more.

Retries are capped on three axes at once: per-phase, per-agent, and a global per-run ceiling. The global cap is what keeps a single bad run from quietly turning into a $40 bill. Combined with the hard $5 abort, the worst case is bounded and visible instead of a surprise invoice.

A subtle one we hit: a long LLM stream can go idle without erroring (the upstream connection gets severed but the socket never closes). A naive loop waits forever. We added an idle watchdog in the agent loop so a silent stall is treated as a transient failure and retried, instead of hanging the whole run.

Design constraints that shaped everything

Your infra, zero lock-in. Code lands in your GitHub, the app deploys to your Vercel, the database is yours. Cancel the subscription and you keep a working product. This forced the deployer to operate purely through user-supplied tokens, which is more work than deploying to our own infra but is the entire point.
The publisher physically cannot post without you. Social publishing is gated per post, per platform, behind an explicit human tap. Autonomy ends at the point where it would speak as you in public. Generation is automatic; publishing is not.
Hard cost ceiling. $5/run, enforced mid-run, not reconciled after. Agents check remaining budget before expensive calls.

Stack

Next.js for web, Drizzle + Turso (libSQL) for data, Playwright for browser automation in the marketing/audit phases. The orchestrator is a separate runtime from the web app, spawned per run from source so a fix ships without a full rebuild.

Honest lessons

A typed contract beats a smarter prompt. We spent weeks trying to make agents "just agree." Making them agree on a machine-checkable artifact was the actual fix.
A reconcile phase is worth more than a better code-gen model. Catching drift after the fact, cheaply, beat every attempt to prevent it perfectly up front.
Classify failures before you retry them. Uniform retry is how multi-agent systems burn money and still fail.
Bound the blast radius in money, not just time. A per-run dollar cap is the single most important guardrail in an autonomous pipeline that calls paid APIs in a loop.

If you want to see the output, the first run is free with your own API key at moonshift.io. Happy to answer architecture questions in the comments.

DEV Community: Harjot Rana

Testing React components against the worst case

Two fixtures per component

What goes into the worst case

Looking at it

Keeping it fixed

A slow CPU is a worst case too

Try it on one component

I built a free desktop GUI for Muse Code, Meta's coding agent CLI

Why I built it

What it does

How it is built

Try it

Muse Code in VS Code and Cursor: a side panel instead of a terminal

What it is

Setup (about 5 minutes)

Three things it does that the terminal doesn't

1. Approvals you can read

2. The files each thread changed

3. Every thread for the folder, and your usage

Recommend it to your team

A few commands worth knowing

The unofficial part

How to run Muse Code on a remote server over SSH, with a desktop GUI

How it works

1. Make ssh work without a password

2. Install Muse Code on the server

3. Add the project in Helicon

When something goes wrong

What SSH projects don't do yet

SSH projects or the remote daemon?

Try it

I built a desktop app for Meta's Muse Code CLI, and the billing is the whole story

The mistake I made first: scraping the terminal

What replaced it

The part that decides your bill

Windows, honestly

Bundling the runtime

What it looks like

Honest gaps

I mined 1,398 corrections out of my coding agent logs and turned them into a rules file

What it actually is

The version I sat on for a year

Do not interview yourself

The extraction

Layout

Does it work

Then I sorted the results by where each rule came from

Patched four rules, re-ran, 18/20

What it is like to use

Try it

How we built a 14-agent pipeline that ships a deployed app + launch assets in ~7 minutes

The core problem: parallel agents drift

The 10 phases

Reliability: not every failure is equal

Design constraints that shaped everything

Stack

Honest lessons

1. Make `ssh` work without a password