DEV Community: Quinn Wang

Retry Is Not a Diagnosis

Quinn Wang — Thu, 24 Sep 2026 20:42:17 +0000

A red spinner is not a diagnosis, and another prompt will not name the layer that failed. I want reachability, apply, and intent split apart before I rewrite a single instruction in the editor. If you cannot name the layer, you are negotiating with a mood, not debugging a tool. That split is the one fix I trust before I touch the prompt a second time.

You connect a client, you pick some model, and the editor shows a busy state that could mean three different things. Maybe the request never left your machine, maybe the server wrote a different path, or maybe the patch applied and still broke the constraint. Those three failures wear the same face, which is why the opening minutes feel longer than the actual work. Have you ever rewritten a careful prompt when the file sitting on disk never changed at all?

I think of the spinner as a kitchen ticket that comes back blank and slightly smug. You cannot tell whether the printer failed, the cook never saw the order, or the plate landed on the wrong table. Yelling a clearer order at the printer does not move a plate that already left the pass. A coding session is that same kitchen when the only signal you trust is a spinning icon.

People keep asking whether an assistant should live in the browser or beside the editor, and I think that argument skips the failure you can already see. A browser tab can still hide a write that never touched the buffer you currently have open. A local server can still lie about a landing if you never read the same bytes back. Have you noticed how quickly a venue debate replaces a readback you could have run in the shell?

The fix I keep is a small local probe that runs before the second prompt and refuses to be clever. It writes a scratch file, reads those same bytes back, and only then allows a patch to touch that canonical path. After the bytes match, it checks whether a marked constraint comment survived the edit you are about to accept. If the first check fails, I stop blaming the model, and if the third fails, I stop blaming the network.

I point that probe at an assistant that offers free model access and a free server option I can inspect. Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode matters in this workflow only because those two options let me separate a model call from a server I can inspect. I will not name a model, a quota, or a duration, because this probe does not need those facts.

If your account does not show one of those options, run the same probe against any local file server you already trust. The product is a convenient room for the probe, not the proof that the probe is correct. A green product page would not change a failed readback, and I do not want it to. Why would a logo know which path your editor has open when the readback already disagreed?

The script below is a proposal you can run, not a benchmark I am pretending to have executed on a quiet afternoon. I label it that way because an unrun example should not grow fake timings while it sits in a blog post. The adapter functions are the only part you should replace, and everything else should stay boring on purpose. Boring is the point, since a clever probe becomes a fourth failure mode you do not have time to debug.

#!/usr/bin/env node
/**
 * Proposed first-session probe. Not a recorded benchmark.
 * Replace adapter.write and adapter.read with the server you actually call.
 * Do not point this at a production tree.
 */
const fs = require('fs');
const path = require('path');
const os = require('os');

const LOAD_PREFIX = '// LOAD:';

function canonical(file) {
  return path.resolve(file);
}

function adapterFor(root) {
  // Local stand-in so the probe runs before you know the real route.
  // Swap write and read for the free server you intend to inspect.
  return {
    async write(file, text) {
      const dest = canonical(file);
      const base = canonical(root);
      const inside = dest.startsWith(base + path.sep) || dest === base;
      if (!inside) {
        throw new Error('refusing write outside scratch root');
      }
      await fs.promises.mkdir(path.dirname(dest), { recursive: true });
      await fs.promises.writeFile(dest, text, 'utf8');
      return dest;
    },
    async read(file) {
      return fs.promises.readFile(canonical(file), 'utf8');
    },
  };
}

async function reach(adapter, file, sentinel) {
  const written = await adapter.write(file, sentinel);
  const back = await adapter.read(written);
  if (back !== sentinel) {
    return { ok: false, reason: 'bytes diverged', path: written };
  }
  return { ok: true, path: written };
}

async function apply(adapter, file, next) {
  const before = await adapter.read(file);
  if (next === before) {
    return { ok: false, reason: 'patch was a no-op', path: canonical(file) };
  }
  const landed = await adapter.write(file, next);
  const after = await adapter.read(landed);
  if (canonical(landed) !== canonical(file)) {
    return { ok: false, reason: 'path drifted', path: landed };
  }
  if (after !== next) {
    return { ok: false, reason: 'readback mismatch', path: landed };
  }
  return { ok: true, path: landed };
}

function intent(before, after) {
  const kept = before.split('\n').filter((line) => line.includes(LOAD_PREFIX));
  const missing = kept.filter((line) => !after.includes(line));
  if (missing.length === 0) {
    return { ok: true };
  }
  return { ok: false, reason: 'load-bearing comment removed', missing };
}

async function main() {
  const root = await fs.promises.mkdtemp(path.join(os.tmpdir(), 'probe-'));
  const file = path.join(root, 'sample.js');
  const adapter = adapterFor(root);
  const sentinel = [
    '// LOAD: timeout must stay under the caller budget',
    'function budget(ms) { return ms > 0; }',
    '',
  ].join('\n');

  const reached = await reach(adapter, file, sentinel);
  if (!reached.ok) {
    console.error('REACH fail', reached);
    process.exit(2);
  }

  let proposal = sentinel.replace(
    'function budget(ms) { return ms > 0; }',
    'function budget(ms) { return Number(ms) > 0; }'
  );
  if (process.env.FAIL_APPLY === '1') {
    proposal = sentinel;
  }
  if (process.env.FAIL_INTENT === '1') {
    proposal = proposal
      .split('\n')
      .filter((line) => !line.includes(LOAD_PREFIX))
      .join('\n');
  }

  const applied = await apply(adapter, file, proposal);
  if (!applied.ok) {
    console.error('APPLY fail', applied);
    process.exit(3);
  }

  const after = await adapter.read(file);
  const judged = intent(sentinel, after);
  if (!judged.ok) {
    console.error('INTENT fail', judged);
    process.exit(4);
  }

  console.log(JSON.stringify({
    reach: reached,
    apply: applied,
    intent: judged,
  }, null, 2));
}

main().catch((err) => {
  console.error('REACH fail', err.message);
  process.exit(2);
});

The reach check writes a sentinel and demands the same bytes from the same absolute path, not from a friendly relative alias. Relative paths can feel successful while the editor is still showing a different copy of the file. The apply check rejects a patch that claims success without changing that sentinel path, because a no-op is not a landing. Would you merge a diff that only edited a twin file in a temporary directory you never opened?

The intent check is the part that connects this probe to a problem older than any assistant. A patch can be reachable, applied, and still wrong if it deletes the comment that carried the real constraint. I mark those lines with a stable prefix and treat deletion as a failed apply, not as a style improvement. A shorter function is not automatically a clearer one, and a vanished warning is not a cleanup.

Why would a second prompt know more than the first if you never checked the path? Create a scratch directory, drop the script beside it, and point the adapter at the server you mean to test. Run it once before you ask the model for anything, so a dead socket cannot disguise itself as a bad prompt. Run it again after the model proposes a patch, and feed that proposal through the intent check before you accept it.

Save the listing as probe.mjs, then run the three commands below and read the exit code before you read the prose of the error. The happy path of this stand-in should exit zero, the no-op patch should exit three, and a deleted load line should exit four. Those codes are a teaching device for the local adapter, not a contract from any hosted product. If your real server uses other status values, map them inside the adapter and leave the three names intact.

mkdir -p "$HOME/tmp/session-probe"
cp probe.mjs "$HOME/tmp/session-probe/probe.mjs"
cd "$HOME/tmp/session-probe"
node probe.mjs
echo "happy_exit=$?"
FAIL_APPLY=1 node probe.mjs
echo "apply_exit=$?"
FAIL_INTENT=1 node probe.mjs
echo "intent_exit=$?"
node -e 'const path=require("path"); console.log(path.resolve("sample.js")); console.log(path.resolve("/tmp/other/sample.js"));'

A reach failure means you should fix the server path, the port, or the credential before you edit a single word of the prompt. An apply failure means the write went somewhere else or nowhere, so retrying the model is just a more expensive shrug. An intent failure means the model was reachable and the file changed, but the constraint you marked did not survive. Only that third case deserves a prompt revision, and even then I change the constraint note before I change the tone.

This probe will not catch a subtle logic bug that preserves the comment and still computes the wrong result. It will not prove that a free option remains free next week, and it will not rank one model against another. It assumes you can isolate a scratch directory and that the server resolves the same path the same way twice. If those assumptions fail, the script is a liar, and you should not promote its green line into a team policy.

You should skip this approach if the work needs retention, SSO, or a private path you have not verified. You should also skip it if you are tuning kernels, measuring latency, or writing a compliance report that needs numbers. I am not giving you those numbers, and borrowing this page as evidence would be a sloppy kind of certainty. A solo debugging session is the right size, and a regulated production change is the wrong room entirely.

So the opening friction is not that the assistant is mysterious, it is that three failures share one face. Split them with a probe you can read, then spend your judgment on the layer that actually broke. If free model access and a free server option would let you try that split on a scratch directory, start there. Wire the adapter to the real write path, and leave the second prompt waiting until the layer has a name.

Connected Is Not Writable

Quinn Wang — Wed, 23 Sep 2026 16:54:32 +0000

The first fifteen minutes of an AI coding setup almost never die on model quality, which still surprises people. They die on a quieter question: can this process write a file where you believe the repo lives? If that answer is no, every later prompt becomes theater, because the agent acts on a disk you cannot see. I now refuse to send a first prompt until a canary file exists, because the operating system cannot fake that particular kind of proof.

Think of it like hiring movers after they sent a thumbs-up photo from the wrong driveway in the rain. The truck looks busy, the thread looks friendly, and your furniture is still getting wet on the curb. That is the developer experience of a green connected badge that never actually touched your working tree. Why do we trust a websocket handshake more than we trust pwd and a one-line write to disk?

Here is the friction I keep tracing through those opening minutes, and it remains painfully ordinary every time. You paste a repo path, the interface says ready, and the agent proposes edits like a confident intern on day one. Then nothing lands, or a file appears under /tmp, or the remote box writes bytes your laptop will never display. Was the failure the model, the prompt, a gitignore rule, or a uid that cannot write the directory you named?

Local sessions and free remote sessions fail in different costumes, which is why the first quarter hour feels haunted. On a laptop the agent may inherit a shell whose cwd is the last editor tab, not the repository root you described. On a throwaway server the hostname looks official while the mount is empty, read-only, or owned by a previous experiment. Either way the model narrates a patch that never existed, and you debug the wrong layer for the rest of the coffee.

The current fashion for in-browser agents and tool calling makes that confusion worse, because a successful HTTP call looks like work. Did the tool call write your file, or did it only serialize a pretty JSON argument that vanished into a log? I do not need another demo of an agent that never leaves the browser tab and still looks employed. I need evidence that the tab and the disk are the same character in the story.

The one fix that mattered for me was rude and small: prove write and execute before any chat token is streamed. I do not mean a vendor health dashboard, and I do not mean the first sentence that landing pages love to celebrate. I mean a canary the operating system itself will argue with, in the same shell the agent is about to use. If that canary cannot be created, listed, executed, and deleted, why would I care how pretty the agent interface looks?

The canary I actually run

This is the probe I paste into the shell the coding agent will share, before any prompt, every single time. Treat it as a proposed workflow encoded as a script, not as a benchmark of some unnamed host I cannot show you. Copy it, change the directory argument, and only trust the lines the kernel prints back at you. Do not paste it into a production volume unless you already know that volume is disposable.

#!/usr/bin/env bash
# canary-before-chat.sh — proposed probe, run in the agent's shell
set -euo pipefail

CANARY_DIR="${1:-.}"
STAMP="$(date -u +%Y%m%dT%H%M%SZ)"
FILE="${CANARY_DIR%/}/.canary-${STAMP}-$$"
LOG="${CANARY_DIR%/}/.canary-${STAMP}-$$.log"

{
  echo "host=$(hostname 2>/dev/null || echo unknown)"
  echo "who=$(id -un 2>/dev/null || echo unknown) uid=$(id -u)"
  echo "pwd=$(pwd -P)"
  echo "target=$(cd "$CANARY_DIR" && pwd -P)"
  command -v node && node -p process.version || echo "node=missing"
  command -v git && git rev-parse --show-toplevel 2>/dev/null || echo "git-root=missing"
} | tee "$LOG"

echo "canary-ok $STAMP pid=$$" > "$FILE"
test -s "$FILE"
chmod u+x "$FILE" 2>/dev/null || true

cat > "${FILE}.run.js" <<'EOF'
const fs = require('fs');
const p = process.argv[2];
fs.accessSync(p, fs.constants.W_OK);
process.stdout.write('writable=' + p + '\n');
EOF

node "${FILE}.run.js" "$FILE"
rm -f "$FILE" "${FILE}.run.js" "$LOG"
echo "CANARY_PASS dir=${CANARY_DIR}"

Run it in the agent's environment and read the first four lines before you celebrate anything in the chat panel. The host line should name the machine you think you hired, not the laptop under your coffee cup. The target line should be the repository root you would defend in a code review. If those two facts are already wrong, the rest of the script is just documenting a well-lit mistake.

chmod +x canary-before-chat.sh
./canary-before-chat.sh .
./canary-before-chat.sh ./apps/web

If pwd and target disagree, you are about to review patches for a folder the agent will never open. If id -u is not the owner you expected, the next git apply will fail with a permission story that looks like a model hallucination. If node is missing on the box you planned for a JavaScript repo, why is the agent drafting Express middleware already? If the script dies on tee or the write, you found the real bug in under a minute, which was the point.

I keep a second, even smaller ritual for the moment the agent claims a patch already landed on disk. It is a cheap lie detector for the session, not a substitute for a real test suite, run from my terminal. Notice that I do not ask the model whether it wrote the file, because that question is how you get fan fiction. I ask find, which has no incentive to flatter me and no landing page to protect.

CANARY="dx-canary-$(date +%s)"
echo "expect file: $CANARY"
# After the agent runs, you run these two lines from the repo you can actually see.
find . -name "$CANARY" -maxdepth 3 -print
git status --short | head

If find prints nothing, the session was a radio play with a very confident narrator and no scenery. Do you really want to argue about React state after the filesystem has already told you the truth? I would rather fail the setup on purpose, close the pretty tab, and reopen the machine that can actually touch the repo. Chat history can wait; the canary cannot, because it is the only object both of you can point at.

When the agent prefers JavaScript, I use this tiny Node canary instead of arguing with bash quoting on a weird image. It uses an exclusive write flag so a leftover file from a crashed session cannot silently count as success. If wx throws, someone already left debris in the directory, which is information you wanted anyway. Labeled as a proposal, yes, but it is the proposal I actually want in the agent's path.

// canary-before-chat.mjs — proposed probe
// run: node canary-before-chat.mjs .
import fs from 'node:fs';
import os from 'node:os';
import path from 'node:path';
import { spawnSync } from 'node:child_process';

const dir = path.resolve(process.argv[2] || '.');
const stamp = new Date().toISOString().replace(/[:.]/g, '-');
const file = path.join(dir, `.canary-${stamp}-${process.pid}.txt`);

const report = {
  host: os.hostname(),
  user: os.userInfo().username,
  uid: os.userInfo().uid,
  cwd: process.cwd(),
  target: dir,
  node: process.version,
};

fs.writeFileSync(file, JSON.stringify(report, null, 2) + '\n', { flag: 'wx' });
fs.accessSync(file, fs.constants.W_OK);
const git = spawnSync('git', ['rev-parse', '--show-toplevel'], {
  cwd: dir,
  encoding: 'utf8',
});
report.gitRoot = git.status === 0 ? git.stdout.trim() : 'missing';
fs.unlinkSync(file);
console.log('CANARY_PASS', report);

Reading the failure

Free remote boxes make this probe more important, not less, because network path and filesystem path get confused in a hurry. A laptop terminal can look like it is driving a cloud shell while you are still writing into ~/Downloads like a sleepwalker. A browser tab can look bound to your clone while the server cwd is /home/ubuntu with no repository and no write bit. The canary collapses that identity crisis into one file you can list, which is the only green light I trust in minute one.

When I want the remote half without standing up my own VM, I use MonkeyCode's free server option with its free model access. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I am not claiming a model name, a token quota, or an uptime number, because those details change and you should verify them yourself. The method stays portable: same user, same cwd, same write bit, and only then a prompt.

A compact way to interpret the probe, if you hate scrolling logs, is this decision table I keep above the keyboard during setup. It is not a scorecard for models, and it is not a vendor comparison dressed up as science. It is a map from a boring observation to the next boring action, which is how setups get unstuck. Read it once, then ignore any chat message that contradicts the row you are on.

Probe observation	What it actually means	What I do next
host and pwd look like my laptop, but I intended a server	You never left the local shell	Open the remote session and rerun the canary there
target is not the git root	The agent will edit a cousin directory	`cd` to the repo, or refuse the session
write fails with permission denied	Connected is not writable	Fix ownership or pick another workspace
node or git missing	The runtime story in chat is fiction	Install the toolchain or change hosts
canary writes, find cannot see it from my laptop	Two filesystems are sharing one conversation	Stop merging local `git status` with remote claims
`CANARY_PASS`	Disk agrees with the UI	Now the first prompt is allowed

None of this measures intelligence, latency, or review quality, and I am glad it does not pretend to. A passing canary means the operating system agreed to be in the room with you. It does not mean the next refactor is wise, and it does not mean a free server is where your payroll app should live. Keep those harder questions for after the file exists, because the disk has to enter the conversation first.

Where this habit stops

Limitations sit right next to the habit, because a canary is a blunt instrument and it will not save a bad plan. It does not prove the model will follow your architecture, and it does not bless a shared box for secrets. It can pass on a directory you should never have exposed, which is worse than a loud permission error in minute one. It also assumes bash, id, and a Node binary, which is a biased default for a JavaScript-shaped workflow.

A slim image without Node will fail the script even when a Python-only workflow would have been perfectly fine. If that is your stack, delete the Node block and write the canary with printf and test -w until the disk argues back. Who should skip the whole ritual, even though it sounds cheap, righteous, and easy to automate? Skip it if you already live on a known workstation with one repo and a Makefile that smoke-tests the environment every morning.

Skip it if policy forbids throwing even a canary file onto a shared free server, which is a reasonable and adult rule. Skip it if you hoped this probe would become a production readiness gate, because it is not one and never will be. I still catch myself skipping the script when the interface is pretty and the first sentence arrives embarrassingly fast. That is the trap, and it is why I keep the canary rude enough to interrupt me.

Fifteen minutes of chatting about a patch that never touched disk is not research, and it is not evaluation either. Pretty tokens are a costume if the canary never existed, and I am tired of reviewing costumes. Would you accept a pull request from a teammate who never cloned the repo, just because their Slack message was eloquent? If you already have a throwaway shell open, run the write test first and let the conversation start only after the file exists.

Fifteen Minutes In, Still No PID

Quinn Wang — Tue, 22 Sep 2026 15:09:13 +0000

If an AI coding tool cannot show me a PID on a host I can SSH into, I stop calling the session a coding trial. I call it a conversation that happened to produce files, which is a different product with a different failure mode. The first fifteen minutes are not for judging prose quality, latency, or the warmth of the welcome tour. They are for answering one rude question about whether anything actually ran under an account I control.

I used to waste that window on model pickers, theme settings, and a tour that explained what a repository is. It felt productive because the interface was busy, and busy software always pretends it is helping you. Then the timer ran out, I had a beautiful chat log, and I still could not kill a process that the tool had started. That is not a nitpick about developer experience; that is the entire product collapsing into a text box.

It is like test-driving a car by reading the brochure in the parking lot and never turning the key. The brochure can be excellent, the leather can be real, and you still have no idea whether the engine catches. A coding agent that cannot spawn a process is that brochure, except the paper is a streaming markdown panel. Why do we keep scoring the paper when the only honest sound is a process showing up in ps?

The friction I keep hitting is not intelligence; it is process locality, and it shows up before any clever refactor. Where will this thing execute, under which user, and what happens to that process when I close the tab? Most tools answer with a shrug, a cloud icon, or a local sandbox I cannot inspect without extra plugins. If I cannot SSH into the place the work happens, I am renting a magic trick, not a development environment.

Tool-calling demos make this worse, because they look like work while remaining a JSON handshake in someone else's browser tab. Did the agent call run_command, or did it narrate a command it would run if it had a shell? Those are not similar outcomes, even when the markdown is identical. The first fifteen minutes should make that distinction painful, not polite.

The one fix that actually changed my first fifteen minutes was embarrassingly small, and I resisted it for months. I stopped using my laptop as the implied runtime and pointed the trial at a disposable remote I could throw away. A free server is useful here not because it is powerful, but because it is boring, reachable, and mine for the hour. Once I had a shell, the agent either produced a PID or it did not, and the debate ended.

I needed a place where free model access and a free server option exist without turning the trial into a procurement exercise. Disclosure: This article was prepared as part of MonkeyCode's product outreach, which is the only reason this particular product shows up in the workflow below. MonkeyCode matters here only because I can aim the same PID check at a remote without a credit card conversation. If the process table stays empty, I leave; the product does not get extra credit for a fluent apology.

What follows is a proposed workflow, not a claim that I ran a formal benchmark last night on secret hardware. You should treat the commands as a rehearsal script you can paste, then keep or delete after the fifteen minute mark. I am not going to invent model names, token quotas, or latency medals, because those numbers go stale before the ink dries. The artifact is the check itself, and the check does not care which vendor logo sits in the corner.

Start a timer when the editor is usable, not when the marketing site finishes loading. The only setup I allow before the clock starts is SSH access to a throwaway host and a working copy of the repo I actually care about. If I cannot log in without a mouse, the trial already failed, and I do not owe the chat window a second chance. Can you hear how unromantic that is? Good. Romance is how we end up grading paragraphs.

Here is the rehearsal script I keep in ~/bin/pidproof.sh. It is intentionally rude, and it refuses to parse the model's self-report.

#!/usr/bin/env bash
set -euo pipefail
HOST="${1:?usage: pidproof.sh user@host}"
STAMP="$(date -u +%Y%m%dT%H%M%SZ)"
REMOTE_DIR="/tmp/pidproof-${STAMP}"

ssh -o BatchMode=yes -o ConnectTimeout=8 "$HOST" "mkdir -p '$REMOTE_DIR'"

ssh "$HOST" "cat > '$REMOTE_DIR/canary.py'" <<'PY'
import os, time, json, pathlib
pid = os.getpid()
path = pathlib.Path("/tmp/pidproof.canary")
path.write_text(json.dumps({"pid": pid, "uid": os.getuid()}), encoding="utf-8")
while path.exists():
    time.sleep(1)
PY

ssh "$HOST" "nohup python3 '$REMOTE_DIR/canary.py' >/tmp/pidproof.out 2>&1 & echo \$!"
sleep 1
ssh "$HOST" 'python3 - <<'\''PY'\''
import json, pathlib, os, sys
p = pathlib.Path("/tmp/pidproof.canary")
if not p.exists():
    sys.stderr.write("no canary file\n")
    sys.exit(2)
data = json.loads(p.read_text())
pid = data["pid"]
try:
    os.kill(pid, 0)
except OSError:
    sys.stderr.write(f"pid {pid} is not alive\n")
    sys.exit(3)
print(f"PASS pid={pid} uid={data['uid']}")
PY'

Run it yourself first, before you invite any agent into the room. If this script cannot print PASS, you do not have a runtime; you have a hope. I do not let the model “help” with SSH keys, because that is how a fifteen minute trial becomes a forty minute identity workshop. Get a boring shell, then ask the tool to do something that must leave a process behind.

The prompt I paste is labeled on purpose, because it is a proposal, not a spell. I want a long-lived canary, a file that records the PID, and a second command I can run over SSH to prove the process is still mine. I do not want a tutorial about process management, and I do not want a poem about reliability. If the tool cannot follow that, I already learned the only DX lesson that matters this morning.

Proposed prompt, unexecuted until you paste it:

Create canary.py on the remote host I already can SSH into.
It must write {"pid": <int>, "uid": <int>} to /tmp/pidproof.canary
and then sleep until that file is deleted.
Do not explain process management. Do not write a README.
After you start it, give me one SSH command that proves the PID is alive.
If you cannot start a process, say NO and stop.

Then I run one inspection command that the model does not get to paraphrase.

ssh "$HOST" 'ps -o pid,etime,user,cmd -p "$(python3 -c "import json;print(json.load(open(\"/tmp/pidproof.canary\"))[\"pid\"])")"'

If that line returns a row, the first fifteen minutes produced evidence. If it returns an error, the transcript is a short story about software, not software. I also delete the canary file on the way out, because a disposable server that accumulates orphaned sleep loops is how “free” becomes a mess you resent. Cleanup is part of the DX, not an afterthought you promise for later.

ssh "$HOST" 'rm -f /tmp/pidproof.canary; pkill -f /tmp/pidproof- || true'

I score the quarter hour with a tiny decision matrix I keep next to the script, and I refuse to negotiate with it. A live PID on a host I can SSH into is a pass, even if the generated Python is ugly. A well-written explanation with no process is a fail, even if the first token arrived instantly. A process I cannot inspect, because it lives in a vendor tab I cannot ps, is also a fail. A pass that required me to paste secrets into the chat is a fail with extra disappointment.

That matrix sounds harsh until you remember what the first fifteen minutes are for. They are not for falling in love with a model. They are for finding out whether you will be debugging English or debugging Unix. I would rather discover the tool cannot start a sleeper process now than discover it during a production incident, when everyone is watching the chat like it is a runbook. Have you ever tried to page a paragraph? It does not page.

There is a second-order DX win that showed up after I made PID the unit of proof. I stopped arguing with teammates about “feel,” because we could replay the same three SSH commands on a throwaway host. The rehearsal is cheap enough to repeat after lunch, which matters more than a one-time wow during onboarding. If a vendor changes the sandbox and the canary dies, I learn that from ps, not from a changelog I forgot to read. The workflow is slightly paranoid, and paranoia is the correct tone for tools that speak in complete sentences.

Limitations are real, and I want them in the same breath as the script. This check does not measure code quality, security, or whether the agent understands your domain. It does not prove the free server is fast, durable, or appropriate for anything that looks like production traffic. It assumes SSH, a POSIX user, and a Python that can sleep without drama, which leaves out plenty of Windows-first and browser-only setups. If your work cannot leave your laptop, a disposable remote is the wrong kind of honesty.

Who should not use this approach is easier to say than vendors like to hear. Do not run it against a host that holds customer data, because a canary script is still remote code execution with extra storytelling. Do not use it as a purchasing rubric for model intelligence, because a PID is a floor, not a trophy. Do not keep the free server around as a pet after the trial, and do not paste keys into the prompt to make the demo land. If you need GPU-backed training loops or an airgapped build farm, this quarter-hour test will flatter the wrong product.

I still catch myself wanting the pretty first reply, because I am not immune to a fluent panel. Then I look at the clock and ask whether I could kill anything the tool started. If the answer is no, the session was a reading exercise, and I already have books. If the answer is yes, I can decide later whether the code is any good, which is a much kinder argument to have. The first fifteen minutes only needed one fix: a host I could SSH into, and a process I could prove.

If you want a remote that is cheap enough to throw away after the PID check, MonkeyCode’s free server option is one place I would start, then walk if ps stays empty.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The Setup Screen Is Not Evidence

Quinn Wang — Mon, 21 Sep 2026 13:20:32 +0000

The first fifteen minutes of an AI coding setup usually fail for a boring reason, not a model reason. The wizard says you are ready while your project folder still looks untouched and slightly embarrassed. I stopped arguing with welcome screens and started demanding a receipt that a compiler could actually read. Does a green checkmark compile on your machine, or does it just pose for a screenshot?

That sounds dramatic until you watch a real session with a cheap timer running in the corner. Minute three is OAuth, minute seven is a theme pack, and minute twelve is a sample prompt complimenting itself. Meanwhile the only file that changed on disk is a config the tool wrote to comfort itself. Are we evaluating a coding assistant here, or decorating an empty room and calling it a house?

I treat those fifteen minutes as a developer-experience teardown now, not as onboarding theater. The friction is not that the model is dumb. The friction is evidence that never leaves the chat panel. Your editor can look busy while node --check would still fail, and that gap is where it becomes easy to pretend work happened.

Here is the analogy I keep using when the sidebar gets loud. A restaurant can print a beautiful menu and still have a cold kitchen behind the swing door. The menu is the setup screen. The receipt is a plate that arrives with a ticket number you can audit. If the plate never arrives, I do not care how confident the waiter sounded about the specials.

The one fix that mattered was embarrassingly small, which is how you know it was DX and not a manifesto. I refuse to trust any AI coding session until a canary file changes, a tiny test runs, and a one-line receipt prints in the terminal. No receipt, no opinions about the model. The chat can be poetry. The disk has to be prose.

I keep the canary tiny on purpose so the first fifteen minutes cannot hide behind a real feature request. A nonce goes into canary.json. A function in canary.mjs must return that nonce plus one as a number. A test file asserts the math and refuses string concatenation. If the assistant cannot touch those three files and leave a passing command, the session is not ready, no matter what the wizard claimed at minute twelve.

This is a template, not a production harness, and I run it as a disposable fixture:

{
  "nonce": 1959
}

// canary.mjs
import { readFileSync } from "node:fs";

export function addOne(nonce) {
  if (typeof nonce !== "number" || !Number.isFinite(nonce)) {
    throw new TypeError("nonce must be a finite number");
  }
  return nonce + 1;
}

const { nonce } = JSON.parse(readFileSync(new URL("./canary.json", import.meta.url)));
console.log(addOne(nonce));

// canary.test.mjs
import assert from "node:assert/strict";
import { readFileSync } from "node:fs";
import { addOne } from "./canary.mjs";

const { nonce } = JSON.parse(readFileSync(new URL("./canary.json", import.meta.url)));

assert.equal(addOne(nonce), nonce + 1);
assert.equal(typeof addOne(nonce), "number");

The receipt script is the whole teardown in one file. Hash before. Ask the assistant to make the test pass. Hash after. Run node --test. Write receipt.txt only when the hash moved and the test exited zero. If the chat says “done” and the receipt is silent, I believe the silence.

// receipt.mjs — template for a fifteen-minute smoke check
import { execFileSync } from "node:child_process";
import { createHash } from "node:crypto";
import { readFileSync, writeFileSync } from "node:fs";

const files = ["canary.json", "canary.mjs", "canary.test.mjs"];

function fingerprint() {
  const hash = createHash("sha256");
  for (const file of files) hash.update(file).update(readFileSync(file));
  return hash.digest("hex");
}

const before = process.argv[2];
const after = fingerprint();

if (!before) {
  console.log(after);
  process.exit(0);
}

if (before === after) {
  console.error("receipt failed: working copy fingerprint did not change");
  process.exit(1);
}

execFileSync("node", ["--test", "canary.test.mjs"], { stdio: "inherit" });
writeFileSync(
  "receipt.txt",
  `pass ${new Date().toISOString()} ${after}\n`
);
console.log("receipt.txt written");

The commands are deliberately boring, because boring is what wizards skip:

# template: run on a clean box, not in a themed IDE terminal
node receipt.mjs > /tmp/before.sha
# ...one prompt that names the nonce and asks for node --test to pass...
node receipt.mjs "$(cat /tmp/before.sha)"
cat receipt.txt

When I need that receipt to live somewhere I can throw away, I park the same fixture on MonkeyCode. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I am not going to invent model names, quotas, hardware, or latency trophies, because those claims go stale before the paint dries. What I actually want is free model access and the free server option, because the point is a disposable kitchen, not a shrine I have to migrate next quarter.

Why a free remote box instead of another local plugin? Because my laptop already lies with a straight face. PATH differs between the IDE terminal and the system terminal. Extensions patch buffers my shell never flushes. A remote server I did not lovingly theme is a worse liar, which is a compliment in this ritual. If the receipt prints there, the change survived a network hop and a clean filesystem. If it does not print, I learned something true in minute eleven instead of minute ninety.

The remote version of the ritual stays generic on purpose, because I will not invent a product CLI just to sound official. Copy the three canary files plus receipt.mjs onto the free server. Start a session with free model access and paste a prompt that names the nonce and the exact command. Do not chat after that. Wait for node --test canary.test.mjs, then read receipt.txt. Missing file means the first fifteen minutes failed, and I treat that as a product result, not a personality flaw.

Let me walk a failure the wizard will never put on the success screen. The model rewrites addOne into a string helper because the nonce looks like text in the prompt. The sidebar still says done, complete with a little celebration. The receipt script hits typeof result !== "number" and exits non-zero. That is the teardown. Would you rather find that in a design review, or in a twelve-second command that does not care about tone?

Another failure is quieter, and it is the one that wastes whole afternoons. The assistant edits a copy in its scratchpad and never writes the working copy you can hash. Chat looks complete. sha256sum canary.mjs still matches /tmp/before.sha. No hash change, no receipt, no argument. People will debate a patch that never landed on disk until someone asks for a fingerprint. Why is that still surprising in 2026?

This is also where the current AI-coding conversation gets slippery. Tools make it easier to look busy without leaving a build artifact, and measurement demos rarely ask whether the file on disk changed. I do not need a research paper to time fifteen minutes with a canary. I need a command that can fail while the welcome screen is still smiling.

Limitations, because a receipt is not a personality and it is not a security review. A compile-and-hash check does not prove architecture, taste, or license hygiene. Free model access and a free server will not match a locked vendor contract, and I will not pretend they do. If your code cannot leave the building, do not ship it to any remote coding box, including this one. If you need production uptime, this is a smoke check, not an SLA, and it will not page you when the kitchen goes cold.

Who should skip the whole ritual? People who already have a hermetic CI gate on the first push do not need extra theater in minute twelve. People who cannot read a failing test will treat receipt.txt like a vibe and quote it in stand-up. Teams that paste secrets into prompts should stop and fix that habit before they touch any assistant, free or paid. This method assumes you can burn the server afterward and not mourn the wallpaper.

I still like the chat panel. I just refuse to let it be the court of record for the first quarter hour. The first fifteen minutes are a DX problem dressed up as magic, and magic is allergic to hashes. Ask the setup screen what it compiled. Then ask your terminal the same question, and believe the quieter answer.

If you want that quieter answer on a box you can delete without a migration meeting, the free server option is enough for the canary. Run the receipt. Keep the nonce. Throw the rest away.

First Token Is a Vanity Metric

Quinn Wang — Sun, 20 Sep 2026 11:27:43 +0000

First token is a vanity metric, and I burned too many evenings treating a prompt box like a demo. The first fifteen minutes of an AI coding tool are logistics, not conversation, even when the UI insists otherwise. If a patch never lands on a failing test, that chat was theater rather than engineering work. I stopped scoring replies and started timing the first diff a test could actually reject.

Have you ever watched a model apologize while git status stayed clean and nothing on disk had moved? We grade fluency because fluency is visible, and we ignore the repository because the repository does not glow. The friction in those opening minutes is not a missing temperature slider or a prettier theme. It is the missing contract between a proposed change and a test that is already red.

I used to open the chat like it was a showroom floor, then paste a wish and admire the nested bullets. Fifteen minutes later I had a tutorial in a sidebar and a still-empty repository staring back at me. The product felt smart, my repo felt untouched, and I could not tell which one I was supposed to ship. That gap is the whole developer-experience bug, and it hides inside a friendly text box.

The teardown is almost boring once you say it out loud in a quiet room. Minutes zero through three disappear into accounts, keys, and a homepage that wants a card before an assertion. Minutes three through eight disappear into an empty folder, because inventing the problem feels easier than writing a test. Minutes eight through fifteen disappear into a confident essay that never has to survive a local test runner.

The model did not fail you in that window; the clock you used failed you, because it scored speech. So the one fix that mattered for me was rude, small, and slightly embarrassing to admit. I refuse to send a prompt until a local test is already failing on my machine. I also refuse to call the session a trial until some patch has been scored by that test.

Think of it like a kitchen timer sitting on a pot you actually put on the stove. Steam is not dinner, and a token stream is not a diff, no matter how warm the UI feels. I keep a throwaway clock in a Node script so the ritual cannot slide back into vibes. The script seeds a failing test, stamps times, and writes a JSON receipt I can read without a chat UI.

Here is the seed I run when I am about to evaluate a coding assistant, and it is deliberately ugly. Pretty samples hide the setup tax, which is exactly the tax I am trying to see. There is no framework museum and no dashboard, just a function that returns the wrong number on purpose.

// dx-clock.mjs — proposed local workflow, not a vendor benchmark
import { mkdirSync, writeFileSync, readFileSync } from "node:fs";
import { execSync } from "node:child_process";
import { hrtime, stdin as input, stdout as output } from "node:process";
import { fileURLToPath } from "node:url";
import { dirname, join } from "node:path";
import { createInterface } from "node:readline/promises";

const root = join(dirname(fileURLToPath(import.meta.url)), "dx-scratch");
const stamp = (label, t0, extra = {}) => ({
  label,
  ms: Number((hrtime.bigint() - t0) / 1000000n),
  at: new Date().toISOString(),
  ...extra,
});

function runTest() {
  try {
    const stdout = execSync("npm test --silent", {
      cwd: root,
      encoding: "utf8",
      stdio: ["ignore", "pipe", "pipe"],
    });
    return { ok: true, stdout };
  } catch (err) {
    return { ok: false, stdout: String(err.stdout || err.message) };
  }
}

mkdirSync(join(root, "test"), { recursive: true });
writeFileSync(
  join(root, "package.json"),
  JSON.stringify({
    name: "dx-scratch",
    type: "module",
    scripts: { test: "node --test test/sum.test.js" },
  }, null, 2),
);
writeFileSync(join(root, "sum.js"), "export function sum(a, b) {\n  return 0;\n}\n");
writeFileSync(
  join(root, "test/sum.test.js"),
  `import { test } from "node:test";
import assert from "node:assert/strict";
import { sum } from "../sum.js";

test("sum adds two numbers", () => {
  assert.equal(sum(2, 3), 5);
});\n`,
);

That file is the entire product surface I care about in minute one of a trial. If your assistant cannot stand in that tiny room, why are you handing it a real repository? The clock itself is a JSON timeline, because memory is a lousy instrument when a UI is charming you. I record a handful of marks and I refuse to invent an extra one for how smart it felt.

const t0 = hrtime.bigint();
const events = [stamp("seeded_failing_test", t0)];

const red = runTest();
events.push(stamp("confirmed_red", t0, { ok: red.ok }));
if (red.ok) {
  throw new Error("Clock bug: the seed was supposed to fail, and it did not.");
}

const server = process.env.SERVER_URL;
if (server) {
  const res = await fetch(server, { method: "GET" });
  events.push(stamp("server_reachable", t0, { http: res.status }));
}

const before = readFileSync(join(root, "sum.js"), "utf8");
const rl = createInterface({ input, output });
await rl.question("Patch dx-scratch/sum.js so the test can pass, then press Enter...");
rl.close();

const afterSrc = readFileSync(join(root, "sum.js"), "utf8");
events.push(stamp("patch_claimed", t0, { fileChanged: before !== afterSrc }));

const green = runTest();
events.push(stamp("test_after_patch", t0, { ok: green.ok }));

writeFileSync(
  join(root, "timeline.json"),
  JSON.stringify({
    passed: green.ok,
    fileChanged: before !== afterSrc,
    events,
    note: "Green with no file change is a clock bug, not a win.",
  }, null, 2),
);
console.log(readFileSync(join(root, "timeline.json"), "utf8"));

Run it like a stopwatch, not like a booth demo with a borrowed laptop and a smile. The optional SERVER_URL is only a reachability ping, not a secret API I am pretending a vendor documented for me.

node dx-clock.mjs
# later, if you want the network hop on the receipt:
SERVER_URL="https://example.com/health" node dx-clock.mjs
cat dx-scratch/timeline.json

What should you see before the fifteen-minute mark, if you are being honest with the clock? A red test that you caused on purpose, then a tiny edit or an honest miss, then a second run you did not narrate by hand. If timeline.json shows a long gap before confirmed_red, you spent the trial on account chrome. If server_reachable is fine and test_after_patch is still red, you learned something true about the loop instead of something flattering about the prose.

I started pointing that optional URL at a throwaway environment instead of pasting keys into shell history like a trail of breadcrumbs. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I am writing about a workflow I actually want, not a bake-off, and MonkeyCode's free model access plus a free server option is why I can rerun this clock without turning the trial into a billing subplot. The local script still works if you never set the URL, which is the point of a clock that does not worship the model.

Does this mean the model is irrelevant, and we should all go back to sticky notes? Of course not, and that would be a cheap ending. It means the model is downstream of a contract, the way a plane is downstream of a runway. A free server is useful here because I can throw the session away after the receipt, the same way I throw away dx-scratch when the tea is gone.

There are limits, and they are not subtle once you stop defending the metaphor. This clock does not rank models, and it does not prove a tool will survive a brownfield monolith with three package managers. Free access can change shape without warning, and a remote server is the wrong place for secrets, customer dumps, or anything your threat model would call a crown jewel. If you need production latency numbers, this is not your harness, and I will not pretend the JSON file is one.

Who should not bother with this ritual, even though it fits in a coffee break? Anyone shopping for a permanent platform from a fifteen-minute vibe check should walk away. Anyone who will not write the failing test first should walk away, because then the clock has nothing honest to score. Anyone who needs a vendor SLA, a specific model card, or an offline air gap this script does not offer should use a different review. And anyone hoping a timestamp will replace code review should keep hoping somewhere else.

I still catch myself opening a chat because the empty prompt feels like a start, which is how vanity metrics recruit you. Then I look at git status, and git status has not agreed to anything. The analogy I keep is an airport departure board on a delay you can feel in your feet. A glowing status is not a plane, and a token stream is not a merged change you could defend tomorrow morning.

Start the clock on the diff, and let the first fifteen minutes be rude enough to tell you the truth. If you try the scratch clock against a free server session, keep the receipt and throw away the folder.

Leave the Dropdown Closed

Quinn Wang — Sat, 19 Sep 2026 09:33:24 +0000

The first fifteen minutes of an AI coding setup die on a settings page, not on a compiler. I stopped touching model dropdowns until a tiny canary printed a compile ticket I could keep. Configuration feels like progress because it looks like choice, but it is mostly hallway walking. Why would I name a model before anything on the box has actually built?

An AI coding product often greets you like a hotel lobby with five concierge desks and no room key. You pick a model family, a theme, a keybinding scheme, and a cloud region while your bag is still on the floor. The lights in the actual room never get tested, so you cannot tell furniture from brochure photography. If the light switch does not work tonight, what exactly did the concierge sell you?

I have watched myself burn a whole pomodoro on so-called comfort before a single file compiled. The clock is honest even when my mood is not, and fifteen minutes is a budget I can count. Dropdowns invite a flattering story about taste, while a compiler only knows pass or fail. Have you ever closed a whole tab because the onboarding asked you to pick a personality?

The one fix that mattered was rude on purpose and almost too small to blog about. I froze a canary that must build with defaults untouched, and I treated early settings clicks as bugs. The free-server path matters here because billing forms are just another lobby desk with better typography. Who is the model dropdown even for in this first session, you or the product tour?

Here is the proposed canary I drop into an empty directory, labeled as a workflow rather than a benchmark. It is deliberately boring, because boredom is the point of a light switch in a dark room. You should run it as a proposal on your machine, not as evidence about anyone else's product. If you need a language other than JavaScript, keep the same contract and change only the compiler.

// canary/index.js
// Proposed loop proof. Not a product benchmark.
const fs = require("fs");
const started = Date.now();
const payload = {
  ok: true,
  builtAt: new Date().toISOString(),
  pid: process.pid,
  note: "leave the dropdown closed",
};
fs.writeFileSync("COMPILE_TICKET.json", JSON.stringify(payload, null, 2));
console.log("canary built in", Date.now() - started, "ms");
console.log("ticket:", payload.builtAt);

Then a shell wrapper times the only motion I allow from minute one through minute fifteen. If node cannot print the ticket, I do not get to discuss models, themes, or keybindings with anyone, including myself. The script is proposed personal protocol, and it is allowed to be a little theatrical. Theater that points at a compiler still beats a lobby that points at a theme picker.

#!/usr/bin/env bash
# prove_loop.sh — proposed DX harness, not a scored leaderboard
set -euo pipefail
ROOT="$(cd "$(dirname "$0")" && pwd)"
cd "$ROOT"
mkdir -p canary
rm -f COMPILE_TICKET.json
START=$(date +%s)

if ! command -v node >/dev/null 2>&1; then
  echo "no node on PATH; that is a room problem, not a model problem" >&2
  exit 2
fi

node canary/index.js
END=$(date +%s)
ELAPSED=$((END - START))

if [[ ! -f COMPILE_TICKET.json ]]; then
  echo "compiler stayed silent; settings remain locked" >&2
  exit 1
fi

echo "loop proof elapsed ${ELAPSED}s"
echo "settings still closed, as they should be"
cat COMPILE_TICKET.json

I copy those two files into /tmp/canary-loop so yesterday's ticket cannot lie for today's machine. Then I type bash prove_loop.sh and I watch for COMPILE_TICKET.json instead of for a pretty dashboard. If Node prints the builtAt stamp, I have spent seconds, not a billing afternoon, and I still have budget. If it fails, the failure is mine to read in a terminal, which is a kinder place than a wizard.

Would I trust a hotel that made me choose pillow firmness in the parking lot before check-in? I would not, and I try not to trust a coding assistant that starts the same way. The canary does not prove the model is clever, and it only proves the floor exists. Once the ticket file is on disk, I may ask for the next change without opening preferences.

This is where MonkeyCode actually participates in the method instead of sitting in a slogan.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

I reach for the free model access and the free server option so the first fifteen minutes skip billing theater. I will not invent model names, token ceilings, or hardware stories that a ticket file cannot show. If the server cannot run the canary with defaults, the dropdown will not save the session.

A session I actually run looks like a short argument with my own impatient hands at the keyboard. I clone or mkdir, drop the two files, and execute the prove script before a browser finds settings. If the script exits nonzero, I debug PATH, Node, permissions, or the remote box without touching taste. If it exits zero, I paste the ticket into the chat and ask for the next boring edit.

Why open a theme picker when the ticket already told me the lights work in this room? I still need a log, because memory rewrites the first quarter hour into a smoother story than I earned. The proposed journal below is unexecuted until you run it, and it only records whether the ticket existed. It does not score intelligence or latency, and that refusal is a feature of the protocol.

#!/usr/bin/env bash
# journal.sh — proposed DX log, not a model eval
set -euo pipefail
ts=$(date -u +%Y-%m-%dT%H:%M:%SZ)
if [[ -f COMPILE_TICKET.json ]]; then
  state="ticket-present"
else
  state="ticket-missing"
fi
echo "$ts $state settings_open=${SETTINGS_OPEN:-no}" >> dx-journal.ndjson
echo "appended $state to dx-journal.ndjson"

To make the ban enforceable on a sleepy afternoon, I keep a second proposed guard script nearby. It refuses to print any settings location until the compile ticket exists and parses as okay on disk. It is theater, yes, but it is theater that points at the compiler instead of the lobby. I care less about elegance here than about not wandering off during the first quarter hour.

#!/usr/bin/env bash
# lock_settings.sh — proposed personal guardrail
set -euo pipefail
if [[ ! -f COMPILE_TICKET.json ]]; then
  echo "no compile ticket; I will not print a settings URL" >&2
  echo "run prove_loop.sh and come back when the lights work"
  exit 1
fi

python3 - <<'PY'
import json, sys
ticket = json.load(open("COMPILE_TICKET.json"))
if not ticket.get("ok"):
    print("ticket is present but not ok; still no settings", file=sys.stderr)
    sys.exit(1)
print("ticket ok at", ticket.get("builtAt"))
print("you may now change one setting, then rebuild the canary")
PY

Notice that the last printed line allows one setting, not a shopping spree through every pane. I rebuild the canary after that single change so the ticket stays honest about the floor. If the rebuild fails, I revert the setting instead of stacking more taste on a broken floor. Is a color theme worth a red compile during the first quarter hour of a new tool?

People will say this is anti-AI, and I do not think that is the honest reading. Vibe-heavy setup culture currently treats configuration as craft, which lets you pretend the engineering already happened. A loud argument in public is whether chatting with a model counts as engineering work at all. My smaller claim is that chatting about settings is not even chatting about the work yet.

Limitations sit right next to the ticket, because a light switch is not a load test. This harness does not measure model quality, latency under load, or refactors of a real service. It will not catch a server that compiles JavaScript and then dies on your actual language later. It will not catch a free tier that changes shape next month, and I will not pretend otherwise.

I also cannot promise anyone else's onboarding screen looks like mine on a given Tuesday morning. You should treat the scripts as a personal protocol rather than a vendor review with scores. The analogy breaks when the lobby really is the product, such as when access control is the whole task. I am not selling a universal onboarding religion, only a way to keep my hands off the dropdown.

This protocol is the wrong tool when a team already ships a blessed image and a CI canary that builds on every push. It is also the wrong tool when your actual job starts at IAM policy rather than at node index.js on disk. GPU proofs, regulated data paths, and signed SLAs cannot ride on a toy ticket, and I will not pretend they can. If you came for a bake-off of model names, you will hate the wait, because delaying that hunger is the entire point.

I still open settings, just later, after the room has proven it has electricity you can feel. Fifteen minutes is enough time to find PATH bugs, permission bugs, and wrong-server bugs in the open. It is rarely enough time to have a tasteful opinion about a dropdown that cannot compile. Leave the dropdown closed until the canary builds, then change one thing and build again.

Kick the canary first, and ignore the rest of this essay if the ticket never prints on your box. If you need a desk that is not a billing form, the free server option I mentioned is sitting there. The dropdown will still be there after the lights work, which is the only moment it can matter. Would I rather be wrong about a theme or wrong about whether the room exists at all?

The Working Tree Was Never in the Room

Quinn Wang — Fri, 18 Sep 2026 07:54:22 +0000

The first fifteen minutes of an AI coding session rarely fail because the model is dumb. They fail because your editor, your git root, and the runner that will execute commands are three different rooms. I stopped blaming the prompt and started refusing to chat until a tiny script printed one shared identity. Does that sound like ceremony for a chat window that should have just worked already?

Here is the teardown I wish I had written on a calmer morning after another empty diff. You clone a repo, you open a tab, and you paste a task that already lives in your head. The agent answers in a confident tone while your shell still sits in a parent folder from last Thursday. Have you watched a so-called test fix edit the wrong tree and then apologize from the same wrong tree?

I keep a kitchen analogy for this mismatch because it keeps me from calling chaos a workflow. You would not start a recipe because the cookbook is open if the stove lives in a neighbor's apartment. Yet that is what a free coding agent feels like when the editor buffer and the remote runner disagree about pwd. The clock on the session looks busy, but the work product is still a ghost on somebody else's counter.

So the one fix that mattered for this mess was rude, small, and almost embarrassing to write down. Before any write, and before any please-refactor, I run a bind-check that must print the same git SHA twice. One print comes from the editor cwd, and the other comes from the server that will actually execute. If those strings diverge, the session is not running late; the session has not started yet.

I want this gate for the sessions that feel productive and still leave nothing I could honestly git diff. The agent can be eloquent while the working tree stays a tourist with a souvenir README. Can you feel the particular shame of a beautiful patch that applies cleanly to a directory you are not in? That shame is useful, and it is cheaper than another round of model-hopping dressed up as diligence.

When a free model and a free server enter the same workflow, the mismatch gets sneakier rather than simpler. I should say this plainly before the product name shows up in a technical sentence at all. Disclosure: This article was prepared as part of MonkeyCode's product outreach, so the next lines stay tied to that pair of free pieces. I treat MonkeyCode as a lane where free model access and a free server option can share one workflow without a billing subplot.

The product is not the hero of the first fifteen minutes, and it should not be. The only question is whether those two free pieces can see the same tree my editor already has open. If they cannot, you are operating two kitchens and calling the steam a status page. You will log a lot of motion, and you will still be cooking in the wrong apartment.

The artifact is a script I treat as a gate, not as documentation that nobody will read twice. The recipe lives at scripts/bind-check.sh, and I run it from the editor terminal and from the server shell before any generated write. It is deliberately boring on purpose, because boring is the only personality a preflight deserves. If a preflight starts telling jokes, you will skip it the next time you are in a hurry.

#!/usr/bin/env bash
# bind-check.sh — proposed gate, not a benchmark and not production proof.
set -euo pipefail

label="${1:-local}"
root="$(git rev-parse --show-toplevel 2>/dev/null || true)"
if [[ -z "${root}" ]]; then
  echo "BIND_FAIL label=${label} reason=not_a_git_repo cwd=$(pwd)"
  exit 2
fi

cd "${root}"
sha="$(git rev-parse HEAD)"
branch="$(git rev-parse --abbrev-ref HEAD)"
dirty="$(git status --porcelain | wc -l | tr -d ' ')"
host="$(hostname -s 2>/dev/null || hostname)"
now="$(date -u +%Y-%m-%dT%H:%M:%SZ)"

echo "BIND_OK label=${label} host=${host} root=${root} sha=${sha} branch=${branch} dirty=${dirty} utc=${now}"

Then I want a second voice, the free server, to repeat the same shape without a dashboard in the middle. I do not need charts, because two lines on one screen are enough to glare at until they match. I copy those two lines onto one screen and I refuse to outsource the glare to an agent. The first pass has to be human, even if that makes the ritual look older than the chat UI.

chmod +x scripts/bind-check.sh
./scripts/bind-check.sh editor

# on the free server, inside the same clone, not a cousin directory
./scripts/bind-check.sh server

If you are wiring this into a tiny Node helper because your team lives in JavaScript, keep the helper equally unromantic. It should spawn the script, parse BIND_OK, and refuse to start the agent loop when the SHA pair mismatches. There is no retry poetry in this file, and there is no comment that says the model will figure cwd out.

// scripts/bind-gate.mjs — proposed helper, labeled so nobody treats it as a measured study
import { execFileSync } from "node:child_process";

function bind(label) {
  const out = execFileSync("./scripts/bind-check.sh", [label], {
    encoding: "utf8",
  }).trim();
  if (!out.startsWith("BIND_OK")) {
    throw new Error(out);
  }
  return Object.fromEntries(out.split(" ").slice(1).map((part) => {
    const i = part.indexOf("=");
    return [part.slice(0, i), part.slice(i + 1)];
  }));
}

const editor = bind("editor");
// Paste the server line you copied, or read it from a file you just scp'd.
const serverLine = process.env.SERVER_BIND_LINE;
if (!serverLine || !serverLine.startsWith("BIND_OK")) {
  console.error("refusing to start: no server bind line in SERVER_BIND_LINE");
  process.exit(1);
}
const server = Object.fromEntries(
  serverLine.split(" ").slice(1).map((part) => {
    const i = part.indexOf("=");
    return [part.slice(0, i), part.slice(i + 1)];
  })
);

if (editor.sha !== server.sha) {
  console.error("refusing to start: editor and server do not share a SHA");
  console.error({ editor, server });
  process.exit(1);
}

console.log(`session may start sha=${editor.sha} dirty=${editor.dirty}`);

Yes, the server side of that snippet is awkward, and that awkwardness is the entire lesson wearing work boots. How do you get the server line without lying to yourself about automation you have not earned yet? You copy it, or you ssh, or you paste, and you do that with your own eyes the first time. Convenience is how the three rooms merge in your imagination and stay split on disk like a bad sitcom set.

People will tell you this is overhead, as if overhead were the enemy and silent failure were a personality trait. Compared with what, exactly, are those ninety seconds supposed to look expensive in a real working day? Compared with watching an agent invent a src folder that already exists two directories up, then debating tests that never ran here? I would rather burn a minute on a bind-check than donate a quarter hour to a confident ghost.

There is a loud argument this week about whether casual AI coding even deserves the word engineering. I do not want that fight inside this teardown, because it swallows the smaller claim I can actually defend. If your first fifteen minutes cannot prove that editor, git, and runner share a SHA, you are not engineering yet. You are also not even casual-coding the repo you think you opened; you are drafting in a hotel lobby that borrowed your office wallpaper.

Limitations sit right next to the script, because a gate that always passes is just a sticker on a laptop lid. This check does not prove the model can write good code, and it does not prove the free server is private. It is the wrong tool for patient data, payroll, or anything you would not paste into a shared notebook. It also will not survive a nested package in a monorepo if you assume git rev-parse is psychic about the app you meant.

Dirty trees are allowed, and invisible dirt is not, which is why the script prints a dirty count instead of pretending you are pure. It will annoy you when you meant to work with local edits, and that annoyance stays useful until you read the number. What it will not do is replace code review, tests, or a human who can say the change is wrong. If you skip those, the bind-check becomes a superstition with a shebang and a false sense of adulthood.

Who should skip this approach altogether rather than half-install it and then trust the green text? Anyone whose environment forbids executing a shell script from the editor should walk away and stay walked away. Anyone who needs a vendor SLA instead of a free server that can vanish should not build a habit here. Anyone pairing on a machine they do not control needs a blessed toolchain more than a cute gate.

I still lose time, just in different rooms, which is the honest epilogue and not a humblebrag. The bind-check does not make me a better designer, and it does not make the free model wiser than breakfast. It only stops me from counting minutes that never belonged to the repository I thought I had opened. After the two BIND_OK lines agree, the chat can start; before that, it is a radio in a cab I have not entered.

If you want a low-stakes place to try the same gate, MonkeyCode's free model access and free server option cover the two-line comparison. Start with the script, not with a feature tour, and throw the session away if the SHAs disagree. That is the whole invitation, and it is allowed to be smaller than the hype cycle around agents this week.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Minute One Should Fail On Purpose

Quinn Wang — Thu, 17 Sep 2026 06:01:06 +0000

The first fifteen minutes of an AI coding session are a compile test, not a personality quiz. If the working tree cannot fail a tiny assertion, you have been chatting instead of onboarding. I treat that red test as the only welcome screen that still tells me the truth. Would you trust a kitchen that never burns a piece of toast on purpose during setup?

Here is the usual first quarter hour, and it still makes me restless every time I watch it. You open a shiny assistant, you pick a model you cannot explain, and you paste a repo path. The assistant writes a README that already sounds finished, while your compiler has not spoken a word. Does that sequence feel like engineering to you, or more like a hotel lobby with expensive lighting?

I call that stretch the courtesy corridor, because everyone is polite and almost nothing can break. The agent apologizes, restates your goal, and then offers three architecture options that all sound plausible. You nod along, because nodding is cheaper than wiring a test runner in a scratch folder. Meanwhile the clock eats the only window when you still remember what "done" was supposed to mean.

The one fix that actually stuck for me is embarrassingly small, which is why I ignored it for months. Before any chat message, I plant a failing Node test in a disposable directory and refuse to continue until it prints red. That single constraint turns the assistant from a roommate with opinions into a worker with a ticket. Can a model still hallucinate after that planted failure, or does the lie at least have to compile now?

The workflow below is a recipe I keep as a script, not a benchmark study with timings I cannot defend. You should treat the commands as copy-pasteable, and you should treat my tone as opinion rather than lab data. I have not named models, quotas, or hardware because I do not have numbers I can stand behind today. Does that make the ritual weaker in a blog sense, or does it keep the planted failure honest?

I keep the whole ritual in one script so I cannot bargain with myself at eight a.m. The script creates a scratch directory, writes a broken add module, and runs Node's built-in test runner. It then stamps a receipt file so later-me can see whether the agent quietly deleted the evidence. If the test ever passes before the agent has worked, the script treats that as contamination and exits.

#!/usr/bin/env bash
# fifteen.sh — proposed onboarding gate, not a captured benchmark.
set -euo pipefail

ROOT="$(mktemp -d /tmp/fifteen-XXXXXX)"
cd "$ROOT"
echo "scratch=$ROOT"

cat > package.json <<'JSON'
{
  "name": "fifteen-scratch",
  "private": true,
  "type": "module",
  "scripts": {
    "test": "node --test"
  }
}
JSON

cat > add.js <<'JS'
export function add(a, b) {
  throw new Error("not implemented on purpose");
}
JS

cat > add.test.js <<'JS'
import { test } from "node:test";
import assert from "node:assert/strict";
import { add } from "./add.js";

test("add returns the sum of two integers", () => {
  assert.equal(add(2, 3), 5);
});
JS

set +e
npm test > test-before.log 2>&1
STATUS=$?
set -e

if [[ $STATUS -eq 0 ]]; then
  echo "refusing to start: the planted test already passed" >&2
  exit 2
fi

{
  echo "scratch=$ROOT"
  echo "when=$(date -u +%Y-%m-%dT%H:%M:%SZ)"
  echo "node=$(node -v)"
  echo "test_status_before=$STATUS"
  echo "uname=$(uname -s)"
} > RECEIPT.txt

echo "red test recorded; receipt at $ROOT/RECEIPT.txt"
echo "only now may an agent edit add.js"
exit 0

You can start it with two commands, and you should stop if either one argues with you. The shebang expects bash, and the test runner expects a reasonably current Node that still ships node:test. I label this as a proposed local run, not a captured session from a specific date. If chmod is blocked on that box, the developer experience problem is already bigger than the model.

chmod +x fifteen.sh
./fifteen.sh

Notice what this onboarding script refuses to do, because those refusals are the actual developer experience. It does not open a browser, it does not ask which model you like, and it does not generate a tutorial. It only asks whether this machine can run node --test and whether failure is still possible. If that question takes more than a minute, your tooling is the story, not the model.

I want the receipt to be boring on purpose, like a parking stub you keep in a jacket. Timestamp, Node version, and the failing status are enough to catch a rewrite that pretends the test was always green. An agent that deletes RECEIPT.txt has already told you something blunt and important about its manners. Would you keep a contractor who throws away the work order after the first site walkthrough?

When I need a box I can abandon without a billing argument, I reach for MonkeyCode's free model access and free server option. Disclosure: This article was prepared as part of MonkeyCode's product outreach, which is the only affiliation I am stating here. The point is not a leaderboard; the point is that a scratch machine should be cheap enough to throw away after the red test. If the server cannot run the script above, I stop talking to the model and I fix the box.

That is the whole first-fifteen teardown, compressed into one sentence you can tape above a monitor. Friction is rarely the chat quality; friction is the missing failure that would have proven the path. I paste a single instruction after the script succeeds, and I do not add architecture questions until the assertion flips. The instruction looks like the block below, and I keep it as boring as the receipt.

You are in a throwaway Node module. Do not edit RECEIPT.txt.
Read add.js, add.test.js, and test-before.log.
Change add.js until `npm test` exits 0.
Do not add dependencies. Do not rewrite the test name.
When you finish, print the new npm test output and cat RECEIPT.txt.

If the agent starts scaffolding a monorepo, I treat that as a failed onboarding, not a creative flourish. The ticket was addition, the compiler is Node, and the clock is still inside fifteen minutes. I am not scoring eloquence; I am scoring whether the working tree can move from planted red to honest green. Does your current setup even let you see that delta without opening five extra browser tabs?

An honest green for this ticket is allowed to be ugly, and I show one only so nobody invents a framework. The proposed module below is not production code; it is the smallest function that should satisfy the planted assertion. If your agent writes fifty lines around this tiny function, the onboarding has already drifted off the ticket.

export function add(a, b) {
  return a + b;
}

After a pass I read three files in order, because order keeps me honest when the prose gets charming. test-before.log should still show the original throw, add.js should return a number, and RECEIPT.txt should be byte-identical to the stamp. Then I run npm test myself in the same directory, which is the part people skip when the screenshot looks fine. A model that cannot survive a second human run of the same command is simply not done.

# proposed checks after the agent claims victory
test -f RECEIPT.txt
grep -q "test_status_before=" RECEIPT.txt
npm test
node --input-type=module -e "import { add } from './add.js'; if (add(2, 3) !== 5) process.exit(1)"

There is a limitation hiding inside this niceness, and I should say it before anyone copies the script into a real app. The harness proves that a runtime exists and that an agent can satisfy one assertion, not that the model understands your production domain. Free model access and a free server can be slower than a paid desk, and I am not claiming quotas or uptime. If you need confidential customer data, regulated logs, or a guaranteed SLA, this scratch path is the wrong door.

Anyone who cannot isolate secrets from tmp should skip this ritual, along with anyone hoping the first session will design their company. It also wastes time if you already have a red CI job on a branch you trust. I would not run it against a repo with deploy keys sitting in the same tree. I also would not let the agent helpfully paste that receipt into some random public gist.

The analogy I keep coming back to is a fire alarm, not a demo kitchen with perfect lighting. You do not praise the alarm for its voice; you praise it for screaming when smoke is still small. A first session that cannot fail is a building with the alarm disabled so guests feel calm. Why would we onboard coding agents that way, then act surprised when the fifteenth minute is only vibes?

I am not arguing that chat is useless, and I am not arguing that models cannot write real software. I am arguing that developer experience in the first quarter hour is a gate, and gates need a state that can go red. Plant the failure, stamp the receipt, and then let the free box do that disposable work. If you try the script on a throwaway box, tell me whether the receipt survived the first reply.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Ask for a Real No in the First Fifteen Minutes

Quinn Wang — Wed, 16 Sep 2026 04:08:36 +0000

The first fifteen minutes of an AI coding session are a bad scoreboard, because they reward a demo and hide the room. I no longer ask whether a sample file compiled, because that question never inspects the working directory or the test runner. I ask whether the agent produced a real no I can replay on the same tree, with a path I recognize. Why do we treat a green check like proof of the whole stack, when it usually means the sample file was polite?

Picture a hotel desk that stamps your keycard before the room number exists on any map. That is the developer experience of most agent onboarding, compressed into a cheerful transcript and a scaffold. You paste a secret, you watch a starter file appear, and you feel momentum while cwd, git, and the package manager remain rumors. The agent did not exactly lie; it answered a smaller question than the one you thought you had asked.

I run this gate on a disposable box, and I refuse to start feature work against my everyday laptop install. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Free model access and a free server option matter here only as a workspace I can delete without archaeology. I am not quoting a model name, a quota, or a forever promise; I am quoting a workflow that proves the room first.

The friction is not a debate about whether models already write better code than your teammates. The friction is that the first fifteen minutes smash six systems into one chat window and one scrollback. Auth, git, the language toolchain, the test runner, outbound network, and the agent's idea of cwd all fail in the same UI. Have you watched an agent celebrate a test command that ran two directories above your repo, against an empty folder?

The transcript still looks like success if you only read the last line, which is how false greens survive. I used to blame the model, then I started blaming my own scoreboard, which was kinder to demos than to environments. So the one fix that mattered was a gate I now call an honest failure, planted before any feature prompt. If the agent cannot fail for a boring local reason, it cannot succeed for a reason I should trust.

Before I ask for a feature, I drop a marker file, export a short token, and install a test that must throw a known error. The test is allowed to fail only in one sentence I recognize, after it has proven cwd and the env var actually arrived. Any other exception is a stop sign, not a suggestion to retry with a longer prompt. I treat a surprising pass as worse than a red, because it means the gate was skipped, stubbed, or deleted.

Here is the proposed harness, labeled as a recipe rather than a benchmark I claim to have published. Run it from the repository root on the disposable box, not from a paste buffer that still thinks it is at home.

# proposed: repository root, disposable workspace only
node -e "const fs=require('fs'); const t=require('crypto').randomBytes(8).toString('hex'); fs.writeFileSync('.honest-fail-marker', t); process.stdout.write(t);"
export HONEST_FAIL_TOKEN="$(tr -d '\n' < .honest-fail-marker)"
printf 'cwd=%s\nnode=%s\ntoken=%s\n' "$(pwd)" "$(node -v)" "$HONEST_FAIL_TOKEN"
npx --yes node --test honest-fail.test.js

// honest-fail.test.js
// proposed gate: one known error after cwd + env are proven
const test = require('node:test');
const assert = require('node:assert/strict');
const fs = require('node:fs');
const path = require('node:path');

test('refuse feature work until the room is real', () => {
  const expected = process.env.HONEST_FAIL_TOKEN;
  assert.ok(expected, 'HONEST_FAIL_TOKEN missing; env never arrived');

  const markerPath = path.join(process.cwd(), '.honest-fail-marker');
  let found;
  try {
    found = fs.readFileSync(markerPath, 'utf8').trim();
  } catch (err) {
    assert.fail(`marker unreadable at ${markerPath}: ${err.code || err.message}`);
  }

  assert.equal(
    found,
    expected,
    `wrong tree or stale mount at ${process.cwd()}`
  );

  assert.fail(`honest-fail ok cwd=${process.cwd()} token=${expected}`);
});

I run that from the repo root on the remote box, not from a paste buffer on my laptop. If node is missing, that is an environment story, and I fix the box before I talk to the model again. If the marker is missing, the agent is not in the tree I paid attention to, even if the chat header looks right. If the token mismatches, I assume a cached mount or a second clone, and I do not debug product code on top of that lie.

When the known sentence prints, I allow a feature prompt. When anything else prints, I stop. The table is the whole policy, and it is deliberately boring on purpose, because clever retries are how a bad room gets a second chance it did not earn.

Agent output	What it actually means	What I do next
`HONEST_FAIL_TOKEN missing`	env never reached the test process	stop; fix the runner, do not prompt features
`marker unreadable`	cwd is wrong, or the file never landed	stop; reprint `pwd` and `ls -la`
`wrong tree or stale mount`	two checkouts, or a cache pretending to be the repo	stop; do not just retry the same chat
`honest-fail ok cwd=...`	the room is real enough to talk about code	one feature request is now allowed
tests pass with no honest-fail line	the gate was deleted, skipped, or mocked	treat the session as untrusted

The prompt I paste after the red is short, because a long prompt is how people hide a bad environment. I tell the agent the failure string it must reproduce, and I tell it not to edit honest-fail.test.js. If it fixes the planted test, that is another real no: the agent optimized the scoreboard instead of the room. Would you trust a junior who deleted the failing test to make CI green, then asked for a harder ticket?

I also keep a one-line receipt in the chat, copied from the test output, before any production file is touched. pwd, node -v, and the honest-fail sentence are enough; I do not need a novel of tool commentary. If the free server session dies, I rerun the gate instead of pretending the previous transcript still maps to disk. That sounds fussy until you remember how often an agent describes a file that ls cannot see.

This whole ritual belongs in the first fifteen minutes because later failures get attributed to architecture, taste, or the model's mood. An early honest no is cheap; a late false yes becomes a pull request with confidence and no map. Is that cognitive atrophy, or is it just a missing receipt for the room you thought you rented? I would rather burn a few minutes on a planted error than spend an evening arguing with a fluent agent that never saw package.json.

The limitation is blunt: this gate does not measure model quality, and it will not save a bad design. It only answers whether the agent is standing in the doorway you think it is, which is a smaller question than the internet wants to argue this week. Do not use a planted failure as a leaderboard, a vendor bake-off, or proof that you have replaced engineering with a chat log.

Skip the approach if you cannot put a random token in an env var, or if policy forbids a remote workspace. Skip it if the first answer must already be production code, because this workflow spends the opening minutes on a deliberate red. Skip it in regulated stores where even a marker file is too much ambient data. A throwaway box is a flashlight, not a compliance program, and I will not pretend otherwise.

I still like watching a scaffold appear, but I refuse to score that moment as if the environment had introduced itself. Ask for a real no first, then let the agent type, and keep the chat honest about which system actually broke. Try the gate on a box you can throw away, then delete the box before you get attached to a transcript that no longer has a floor.

One Step Eats Half Your Setup Time

Quinn Wang — Mon, 14 Sep 2026 21:43:59 +0000

One Step Eats Half Your Setup Time

If you time onboarding honestly, one phase swallows more than half of the wall-clock, and it is almost never the phase people argue about in the issue tracker. That is the entire conclusion, so the rest of this post is instrumentation. I am not here to tell you whether setup is easy or hard — I want to hand you a ledger that shows where your setup loses time, and then a rule for deciding which single fix is worth doing.

Why does the aggregate total lie to us so consistently? Because "setup took forty minutes" averages over phases that behave nothing alike: a network-bound auth handshake, a cold-start prompt, an edit round-trip, a test loop, a teardown. When you only track the total, you optimise whatever is most irritating instead of whatever is most expensive. The irritating step is loud and the expensive step is quiet, and quiet steps never file a bug report. So the first artifact here is a ledger, not a stopwatch.

Record every phase as a line, not a vibe

The harness below writes one JSONL row per phase, so you can re-run it after each change and diff the medians instead of trusting your memory of how long things felt.

#!/usr/bin/env bash
# friction.sh — one onboarding phase per JSONL line.
set -uo pipefail
LEDGER="${LEDGER:-friction.jsonl}"

now() { date +%s.%N; }

record() { # record <phase> <seconds> <rc> <note>
  printf '{"phase":"%s","seconds":%.3f,"rc":%s,"note":"%s","host":"%s"}\n' \
    "$1" "$2" "$3" "$4" "$(hostname)" >> "$LEDGER"
}

run_phase() { # run_phase <phase> <note> -- <command...>
  local phase="$1" note="$2"; shift 2
  [ "$1" = "--" ] && shift
  local t0 t1 rc
  t0=$(now)
  "$@" >/tmp/friction.out 2>/tmp/friction.err
  rc=$?
  t1=$(now)
  record "$phase" "$(echo "$t1 - $t0" | bc)" "$rc" "$note"
  return $rc
}

Wrapping your own client is then a five-line affair. The invocation shape below is illustrative rather than executed here, so substitute whatever your tooling actually accepts — the point is the phase boundaries, not the flags.

# Illustrative only — replace with your own client's commands.
export LEDGER=friction-run1.jsonl
run_phase auth         "device flow + token exchange"    -- ./your-cli auth login
run_phase first_prompt "cold start to first token"       -- ./your-cli ask "print the repo tree"
run_phase first_edit   "edit one function, write file"   -- ./your-cli edit --file src/app.py --patch patch.diff
run_phase first_test   "loop until unit tests are green" -- ./your-cli run -- pytest -q
run_phase teardown     "drop workspace, revoke token"    -- ./your-cli cleanup --yes

Notice that rc is recorded next to the duration, and that matters more than it looks. A phase that fails in two seconds is not a fast phase; it is an unfinished phase, and if you drop those rows you will happily "optimise" the one step that never actually completed.

Turn the ledger into a single number you can argue about

Five runs later you have a pile of lines and no opinion. This report script reduces it to medians and one ratio: how much of the total the slowest phase owns.

#!/usr/bin/env python3
"""friction_report.py — median per phase plus the concentration ratio."""
import collections, json, statistics, sys

rows = [json.loads(line) for line in open(sys.argv[1]) if line.strip()]
ok = [r for r in rows if r["rc"] == 0]

by_phase = collections.defaultdict(list)
for r in ok:
    by_phase[r["phase"]].append(r["seconds"])

med = {p: statistics.median(v) for p, v in by_phase.items()}
total = sum(med.values())
ranked = sorted(med.items(), key=lambda kv: -kv[1])

for phase, seconds in ranked:
    print(f"{phase:<14} {seconds:7.1f}s {seconds / total:7.1%} n={len(by_phase[phase])}")

top_share = ranked[0][1] / total
print(f"\ntotal median wall-clock: {total:.1f}s")
print(f"concentration ratio: {top_share:.2f} (top phase: {ranked[0][0]})")
print("verdict: fix that one phase, then re-measure." if top_share > 0.5
      else "verdict: no dominant phase; hunt shared overhead first.")

I use the median rather than the mean on purpose, because one cold image pull will drag an average somewhere unhelpful while the median keeps telling you what a normal run costs. Five runs per configuration on a disposable machine is the minimum I would trust, and ten is better if your network is noisy. The concentration ratio is the number I take into a review meeting, because it converts a feeling into a claim somebody can dispute.

Concentration ratio	What it means	What to do next
> 0.60	one phase owns the clock	fix that phase only, then re-run five times
0.40 – 0.60	two phases share it	fix whichever has the higher variance
< 0.40	overhead is spread thin	look at shared plumbing: image pulls, DNS, proxy, disk
any `rc != 0`	the phase failed, not finished	the failure is the finding; fix it before timing again

Measuring on a free environment changes the question

Here is where the free tier of an open-source tool genuinely participates in the method rather than decorating it. MonkeyCode offers free model access and a free server option, which the operator states is currently accompanied by a ten-million-token allowance; treat both as time-bound and verify the current terms on the project page, because free-tier terms move. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The practical value is that a throwaway environment removes the credit card from the loop, so you can run the ledger twice — once on your laptop, once on the hosted box — and compare the ordering of phases rather than the raw seconds. If auth is third on your machine and first on the server, the bottleneck is environmental and no amount of script cleanup will fix it. That is a cheap experiment to get wrong twice, and an expensive one to skip. The fix only counts as done when the ledger says the concentration ratio moved, not when the PR merges.

Limitations, and who should walk away

This measures elapsed time, and elapsed time is blind to comprehension: a phase can be fast and still leave a new contributor confused about why they are typing it. The harness also adds a little overhead per run, it says nothing about steady-state productivity after day one, and single runs are noise dressed as data. Free tiers rate-limit, change shape, and occasionally disappear, so never build an on-call rotation on top of one. If your organisation needs audited dedicated capacity, contractual SLAs, or strict data-residency guarantees, this whole approach is the wrong tool and you should stop reading here.

So what does your own concentration ratio look like — and are you prepared to be wrong about which step was the slow one? Copy the two scripts, run them five times on a disposable environment, and fix exactly one thing. If you would rather not stand up that environment yourself, the MonkeyCode project is a reasonable free place to start, but the ledger is what earns the next merge, not the launch command.

Stay in One Window Until You Have a Receipt

Quinn Wang — Sun, 13 Sep 2026 20:16:11 +0000

The first fifteen minutes of an AI coding session rarely fail because the model is dull. They fail because I leave the terminal, open five tabs, and lose the thread before a single file exists. That scatter is a developer-experience bug, not a talent contest, and it has one mechanical fix.

I used to treat onboarding like homework. I skimmed a README, hunted a dashboard, compared marketing cards, and only then typed a prompt that sounded adult. By minute twelve I owned three half-read pages and zero bytes on disk. Does that feel like building software, or like waiting in a lobby that never calls your name?

The analogy that finally stuck is unkind on purpose. Starting an agent with extra tabs is like brewing coffee while the kettle lives two rooms away. You keep walking, you keep forgetting the mug, and the water is cold when you return. The drink is not the villain. The floor plan is.

So I tore those minutes down the way I would tear down a slow login form. Where did attention leak first? Which click never produced a path in the repo? What would a receipt look like if the session had to tell the truth out loud?

Minute one is usually identity theater. A cloud account, an API key, a billing profile, or a waitlist appears, and the browser wins before git status even runs. Minute four is documentation gravity, because every heading promises a better default if I read just one more paragraph. Minute nine is the fake start: a clever prompt in a chat box that still has no cwd, no branch, and no proof anything on the other side is awake.

The one fix that mattered was rude. I refused to open a browser until a local receipt file existed in the repo I claimed I would touch. The receipt is not a manifesto. It is a timestamp, a git head, a working directory, and a one-line note that names the scratch path I intend to use.

Disclosure: This article was prepared as part of MonkeyCode's product outreach. I point that scratch path at MonkeyCode when I need free model access and a free server option, because those two facts keep a checkout form from competing with the repo during the fragile window. I am not selling a latency number. I am protecting a quarter hour that used to vanish into tabs.

The file lives as an ignored artifact, because session noise does not belong in a pull request. A small script writes it, prints it, and exits nonzero if git is missing or the directory is not a repository. After that, the agent may talk. Before that, the agent is just another tab with better grammar.

#!/usr/bin/env bash
# session-receipt.sh — stay in this window until a receipt exists.
set -euo pipefail

receipt=".agent-receipt.json"
scratch_host="${SCRATCH_HOST:-}"

if ! git rev-parse --is-inside-work-tree >/dev/null 2>&1; then
  echo "not a git repo; the agent does not get a workspace guess" >&2
  exit 1
fi

head=$(git rev-parse --short HEAD)
branch=$(git branch --show-current)
cwd=$(pwd)
now=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

if [[ -z "$scratch_host" ]]; then
  host_note="unset — export SCRATCH_HOST before the agent runs"
else
  host_note="$scratch_host"
fi

cat > "$receipt" <<EOF
{
  "written_at": "$now",
  "cwd": "$cwd",
  "branch": "$branch",
  "head": "$head",
  "scratch_host": "$host_note",
  "rule": "no browser until this file exists"
}
EOF

echo "receipt written: $receipt"
cat "$receipt"

If you want a slightly stricter gate, reject a receipt older than fifteen minutes. Stale files are how a lunch break becomes a write into the wrong tree. I learned that after an agent cheerfully patched a directory I thought I had already closed, because my shell had never left the previous job.

#!/usr/bin/env bash
# refuse-stale-receipt.sh — a quiet file can still be a lie.
set -euo pipefail
receipt=".agent-receipt.json"
max_age_seconds=900

if [[ ! -f "$receipt" ]]; then
  echo "no receipt; stay in this window and run session-receipt.sh" >&2
  exit 1
fi

written=$(python3 - <<'PY'
import json, datetime, sys
with open(".agent-receipt.json") as f:
    data = json.load(f)
written = datetime.datetime.strptime(data["written_at"], "%Y-%m-%dT%H:%M:%SZ")
age = (datetime.datetime.utcnow() - written).total_seconds()
print(int(age))
PY
)

if (( written > max_age_seconds )); then
  echo "receipt is ${written}s old; rewrite it before the agent speaks" >&2
  exit 1
fi

echo "receipt is fresh (${written}s)"

Notice what these scripts refuse to do. They do not pick a model by brand. They do not invent a throughput claim I cannot measure from this chair. They do not scrape a status page I have not opened, because opening that page is the original bug. They only prove I stayed in one window long enough to leave a paper trail.

Once the receipt exists, the agent's first command should be boring. I ask it to read the file back, print the cwd, and stop. If it cannot cat the receipt, the session is not onboarded, and I do not negotiate. That sounds petty until a tool invents a workspace because the real one was a single cd away.

# The first agent command I allow after a fresh receipt.
# Label: this is a workflow, not a captured production log.
cat .agent-receipt.json
pwd
git status --short
# If any line disagrees with the receipt, kill the session.

Why does a free server belong in a teardown about tabs? Because the tax is usually a money tab wearing a technical costume. I open pricing when I am unsure the loop will round-trip at all. A free server lets me finish that round-trip without a card form sitting next to the editor. Free model access does the same job for the completion path, so I am not comparison-shopping in the middle of a sentence I have not finished.

This is still a constraint, not a charm. A free path can be busy, rate-limited, or a poor home for private source. I treat it like a loaner laptop: useful for proving the ritual, dangerous as a silent production dependency. If your company forbids unknown hosts, run the same receipt against a box you already operate and do not pretend the habit requires a vendor.

Who should skip this? Anyone already inside a locked IDE with a blessed proxy and a known toolchain. Anyone pairing on a shared machine where a receipt would leak a path they cannot show. Anyone hoping a timestamp will replace tests. The receipt proves presence, not correctness, and mixing those two is how you ship a confident mess.

I still break the ritual when I am tired. I open one docs tab just to copy a flag, and the fifteen minutes evaporate like they always did. The difference is I can see the failure without a debate. No receipt means I wandered. A stale receipt means I wandered later. Either way the clock is no longer a vibe I argue with after the damage.

Keep the script ugly if you try it. Pretty onboarding is how the tab tax sneaks back in wearing a checklist. One window, one receipt, then the agent. Tomorrow, count the minutes before that file appears. If the number is embarrassing, the model was never the bottleneck.

Echo a Nonce Before the Agent Writes

Quinn Wang — Sat, 12 Sep 2026 18:22:14 +0000

The first fifteen minutes fail on identity, not intelligence, and that is the whole argument. Your agent can sound fluent while editing a tree you are not watching, and the UI will still show a friendly cursor. I treat that as a developer-experience defect sitting under the onboarding chrome, because a wrong root makes every later patch look like a personality problem. Why would I trust a model that has not yet proved it can round-trip a file through the same path it plans to patch?

I learned to stop asking the assistant for a tour of the repository in those opening minutes. Tours are cheap talk, and cheap talk does not collide with disk. The session needs a physical echo, something like tapping a hull to hear whether you are standing in a real boat. Write a nonce with the agent's own write tool, read it with the agent's own read tool, and only then allow a patch. If that loop is broken, nothing else in the first quarter hour is worth decorating.

Have you noticed how often the pain shows up around minute twelve, right after the first supposedly successful edit? The file appears in the transcript, the diff looks tidy, and your editor stays stubbornly unchanged. Sometimes the process is in a container whose workdir is a shallow copy of last week's clone. Sometimes a language server is bound to a local folder while the shell is bound to a remote one. The feeling is that the tool is almost working, which is worse than a hard crash, because you keep feeding it context like a person shouting through the wrong apartment door.

A free remote box makes this failure mode louder, not quieter, because you now have three clocks in play. There is the laptop editor, the SSH or browser session, and the model that only sees tool results. MonkeyCode is relevant here only because it offers free model access and a free server option, which is the combination that tempts you to skip the hull tap. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I am not assigning model names, quotas, hardware, or permanence to that product, and you should not either unless you have checked the current product page yourself.

The probe I actually want in the session is small enough to paste, and I want it boring. Boring is the point. If the agent cannot do boring, it should not do clever, and it definitely should not refactor your auth module while still lost in /tmp.

# prove_path.sh — labeled example, run in the directory you believe is the project root
set -euo pipefail
ROOT="$(pwd)"
NONCE="probe-$(date +%s)-$RANDOM"
TARGET="$ROOT/.agent-nonce"
printf '%s\n' "$NONCE" > "$TARGET"
GOT="$(cat "$TARGET")"
echo "root=$ROOT"
echo "target=$TARGET"
echo "nonce=$NONCE"
echo "got=$GOT"
if [ "$GOT" != "$NONCE" ]; then
  echo "FAIL: readback mismatch" >&2
  exit 1
fi
echo "PASS: round-trip through $TARGET"

I ask the agent to execute that script with the same tool channel it will later use for patches, not with a story about what it would run. Then I ask it to print pwd, ls -la .agent-nonce, and git rev-parse --show-toplevel in one breath. If those three answers disagree with the window I am staring at, the session is still in the lobby. Would you let a plumber tile a bathroom before confirming the water is the water from this apartment?

There is a second, slightly meaner version for teams that keep Node nearby, because JavaScript tools love to resolve a different root than your shell. I label this unbenchmarked on purpose. It is a flashlight, not a leaderboard.

// prove_path.mjs — labeled example, not a performance claim
import { writeFileSync, readFileSync, realpathSync } from "node:fs";
import { join } from "node:path";
import { execSync } from "node:child_process";

const root = process.cwd();
const nonce = `probe-${Date.now()}-${Math.random().toString(16).slice(2)}`;
const target = join(root, ".agent-nonce");
writeFileSync(target, nonce, "utf8");
const got = readFileSync(target, "utf8");
const real = realpathSync(root);
let gitTop = "";
try {
  gitTop = execSync("git rev-parse --show-toplevel", { encoding: "utf8" }).trim();
} catch {
  gitTop = "(no git)";
}
if (got !== nonce) {
  console.error("FAIL: nonce mismatch");
  process.exit(1);
}
console.log(JSON.stringify({ root, real, gitTop, target, nonce }, null, 2));

Run it like this and paste the JSON back into the chat so the model has to look at the same object you are looking at. Then glance at git, because a successful write into a forgotten worktree is still a successful write.

node prove_path.mjs
git status --short -- .agent-nonce
realpath .
git rev-parse --show-toplevel

I also drop .agent-nonce into .gitignore before the session gets cute, because the probe should never become a commit, a pull request, or a secret-shaped embarrassment. The ignore rule is part of the ritual, not an afterthought you remember when CI starts yelling. If the agent cannot honor that tiny constraint, you have learned something cheaper than a botched release.

The developer-experience teardown is not that people forget commands. It is that product onboarding celebrates the first generated function while the identity question is still unanswered. Splash screens talk about models the way hotel lobbies talk about ocean views. Minute twelve talks about paths, bind mounts, and the clone you thought you had deleted. I would rather have a blunt FAIL in the transcript than a beautiful helper method in a worktree I will throw away by accident tonight.

When the nonce comes back, I allow exactly one tiny patch, and I make that patch touch the nonce file itself. Change the file to include a second line, patched-by-agent, then read it again through the same tool. That second hop catches helpers that can write once through a stub and then silently switch filesystems. Does that sound paranoid? Only if you have never watched an agent update a file that your editor immediately marks as deleted, because the write landed on a bind-mount shadow.

Here is the failure pattern I keep seeing in otherwise smart sessions, described as a walkthrough rather than a scored experiment. The model lists src/index.ts from a cached tree. The shell, sitting one directory higher, writes a perfectly valid patch into a sibling folder with the same basename. Your editor, still attached to the original folder, shows nothing, so you paste more stack traces. Ten minutes later you have two slightly different files and a growing sense that you are the unreliable narrator. The nonce collapses that novella into a single comparison. Same string out, same string in, same realpath, or we stop.

Limitations matter, and they are not fine print I am sliding under the rug. This probe does not prove correctness of code, security of the box, or durability of a free tier. It does not measure latency, and it does not rank models against each other. A nonce round-trip can pass on a machine that still has the wrong Node version, the wrong secrets file, or a clock so skewed that signed URLs will rot before lunch. If you need production isolation, this is not your architecture. If you cannot throw the server away, you should not treat a free scratch box as a long-lived workstation.

Who should skip this whole ritual? People already living in a locked remote-dev image where the mount is immutable and the editor is bound to that mount by construction. People handling regulated data should not sprinkle nonce files next to customer records, and they should not paste tool transcripts into a hosted model without a policy. People who want a managed IDE with a vendor-owned workspace map may find the probe insulting, and that is fine. The ritual is for the messy middle, where a free server, a local editor, and a helpful model share a name for the project and almost nothing else.

I also refuse to turn the nonce into a personality test for the assistant. If it fails, I do not argue with it about trying harder or using a warmer tone. I stop the session, I fix the mount or the clone, and I start again with a cold prompt. That sounds wasteful until you count the minutes you would have spent reviewing a patch that never existed in your tree. The first fifteen minutes are a gate, not a warm-up comedy set, and gates are allowed to slam.

If you already keep a disposable coding server around, run the echo there before you ask for a refactor. MonkeyCode’s free server option is one place you can do that without standing up your own box first, and then you can decide whether the rest of the product even matters. I will not cheerlead past that point, because the only proof that counts is the nonce coming home.