DEV Community: Quinn Wang

Onboarding Budgets Leak Before the First Commit

Quinn Wang — Fri, 16 Oct 2026 05:13:04 +0000

The fifteen minutes you budget for a new AI coding setup rarely die from a missing feature, and they almost never die from a slow model. They die from three unnamed waits: a key you hold but have nowhere to put, a command that technically succeeds while producing nothing you can verify, and the absence of any rule telling you when to stop. I have watched those three waits eat entire afternoons, and I stopped trusting my memory about them a long time ago.

So this is not another review of what a tool can do. It is a measurement instrument you can run in your own terminal, plus the one fix that actually moved the needle for me. Call it a friction ledger, and yes, it is less exciting than a benchmark table, which is exactly why it works.

Name the three leaks before you time anything

Placement friction is the cost of getting a credential, an endpoint, and a model identifier into the same place at the same time. Verification friction is the cost of turning a successful HTTP response into something a human can inspect and replay. Recovery friction is everything you pay after a mistake, including the four minutes you spend wondering whether the mistake was yours or the tool's.

None of those show up in a "time to first token" chart, because a token is not a diff and a 200 is not evidence. What do you actually have after the happy path returns? If the answer is "a feeling," you have measured nothing, and the next person on your team will pay the same tax you just paid.

The ledger itself: forty lines of bash

A friction ledger records one row per step, with a monotonic-ish millisecond timestamp at the start and the end of that step. The point is not precision; the point is capturing the shape of the wait while you are still annoyed by it. Save this as friction.sh, then chmod +x friction.sh.

#!/usr/bin/env bash
set -euo pipefail

LEDGER="${LEDGER:-./friction.csv}"
STATE="${STATE:-./.friction.state}"

now_ms() { date +%s%3N; }

init() {
  [ -f "$LEDGER" ] || printf 'step,start_ms,end_ms,elapsed_ms,outcome,note\n' >"$LEDGER"
}

start() {
  init
  local step="${1:?usage: friction.sh start <step>}"
  printf '%s %s\n' "$step" "$(now_ms)" >"$STATE"
  echo "started: $step"
}

end() {
  local outcome="${1:-ok}" note="${2:-}"
  local started_step started_at
  read -r started_step started_at <"$STATE"
  printf '%s,%s,%s,%s,%s,"%s"\n' \
    "$started_step" "$started_at" "$(now_ms)" \
    "$(( $(now_ms) - started_at ))" "$outcome" "$note" >>"$LEDGER"
  echo "$started_step: $(( $(now_ms) - started_at ))ms ($outcome)"
}

summary() {
  awk -F, 'NR>1 {t+=$4; n++} END {printf "%d steps, %d ms total, %.0f ms mean\n", n, t, t/n}' "$LEDGER"
}

"$@"

Usage is deliberately boring, because a tool you have to think about is itself friction:

./friction.sh start credential-placement
# ... paste the key, wire the endpoint, pick the model ...
./friction.sh end ok "key in env file, not shell history"

./friction.sh start first-verifiable-output
./friction.sh end blocked "response arrived, no artifact on disk"

./friction.sh summary

One honest caveat about the instrument: it measures your environment and your habits, not the provider's engineering. A slow step might be your proxy, your laptop, or a corporate VPN doing what corporate VPNs do, and the ledger will happily record that as the product's fault. Keep the note column populated and you will at least remember which one it was.

Where a free tier fits into this, without the fantasy math

Free access changes the calculation because the cost of a wrong turn drops to nearly zero, which is precisely when people stop being careful. I have been using MonkeyCode, an open-source project whose operator describes it as offering free model access together with a free server option, and a free allowance he puts at ten million tokens. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Because that arrangement is described to me rather than audited by me, I treat it the way I treat any free tier: useful for measuring, dangerous for assuming. Verify the current terms on the project page before you plan a sprint around them, since free allowances move and nobody owes you a grandfather clause.

What the free server option is genuinely good for is the boring middle of the ledger. You want a place to run the first-verifiable-output step that is not your work laptop with three expired tokens in a config directory. What it is not good for is proving that your production topology will behave the same way, because it will not, and pretending otherwise is how teams ship surprises.

The one fix that mattered

Here is the change that cut my own ledger the most, and it had nothing to do with models. I collapsed three separate touchpoints — key, base URL, and model identifier — into one sourced file, so that there was exactly one place where a stale value could hide. Before that, every step in the ledger was quietly paying a config-hunting tax I had been blaming on the network.

# ~/.config/ai/env.sh — sourced, never copy-pasted into a shell history
: "${AI_KEY:?set AI_KEY before sourcing this file}"
: "${AI_MODEL:?set AI_MODEL before sourcing this file}"
export AI_BASE_URL="${AI_BASE_URL:-https://your-endpoint-here}"
export AI_KEY AI_MODEL

Then a preflight that fails loudly and early, before the fifteen-minute clock starts rather than nine minutes into it:

preflight() {
  local start elapsed
  start=$(date +%s%3N)
  for v in AI_BASE_URL AI_KEY AI_MODEL; do
    [ -n "${!v:-}" ] || { echo "missing: $v"; return 1; }
  done
  curl -sS -o /dev/null -w 'http %{http_code}\n' \
    -H "Authorization: Bearer $AI_KEY" "$AI_BASE_URL/models" || return 1
  elapsed=$(( $(date +%s%3N) - start ))
  echo "preflight ok in ${elapsed}ms"
}

Pair it with a step budget, and the ledger stops being a diary and becomes a decision. I use two thresholds: placement must finish inside one minute, and first verifiable output must finish inside five. If either blows past its budget twice in a row on the same step, I stop debugging and change the approach instead of the parameter.

Ledger observation	Read it as	Action
Placement under 60s, first artifact under 5 min	The seam is clean	Keep going, record the winning sequence
Same step over budget twice	Not a typo, a design gap	Switch approach or switch tool
`blocked` outcome with `no artifact on disk`	Verification friction	Write the expected file path down before the call
Fast `ok` rows, unreadable later	Theater	Add the `note` column or stop measuring

Limitations, and who should skip this entirely

The numbers in that table are placeholders from my own template and not measurements of any specific product, so please do not quote them as benchmarks. A CSV kept by one developer also hides the failures that matter at scale, like the teammate who never tells you they were blocked for three days. And if your code cannot leave your network for compliance reasons, no free server option is a relevant input, no matter how generous the allowance looks.

Who should not use this? Teams that need contractual guarantees, anyone unwilling to re-run the ledger after an environment change, and people who want a benchmark score to paste into a slide. A single measurement run is theater; the ledger earns its keep when it is boring and repeated.

If you want a cheap place to try the whole loop, the MonkeyCode project is open source and its free model access plus free server option is a reasonable sandbox for the first two ledger steps. Bring a stopwatch, trust your own rows over anyone's summary, and tell me which step ate your fifteen minutes — I suspect it was never the model.

# the whole article in two lines
./friction.sh start first-verifiable-output && ./friction.sh end ok "artifact on disk, path recorded"
./friction.sh summary

Time to First Verifiable Diff

Quinn Wang — Thu, 15 Oct 2026 11:23:50 +0000

Time to First Verifiable Diff

The onboarding number I actually trust is not how long the install takes, but how long it takes before a tool hands me a diff I can verify. Total install time tells you that something went wrong somewhere in the chain; it never tells you which link to cut, and that gap is why so many evaluations end in vibes. I keep running into conversations about AI fatigue, and I think a large share of it is not model quality at all, but onboarding friction that nobody bothered to localize. So I built a small instrument that localizes it, and the number it produces changed how I trial tools.

Earlier I wrote about clocking the first fifteen minutes, and I still believe the clock is worth holding. The problem is that a duration without a per-step ledger is a verdict, not a diagnosis. If the whole run took eleven minutes, do I fix the signup, the runtime, the docs, or my own prompt? You cannot answer that from a single stopwatch reading, and guessing wrong is how people conclude a tool is slow when it was actually their network.

Record the steps, then rank them

The harness below is a template, not a product wrapper, and I am not going to pretend I measured anything for you here. Every number it prints comes from your own first run, on your own machine, against your own network, which is the only measurement that transfers. It writes one JSON line per phase transition, so the ledger is append-only and replayable after the fact. Here is the recorder, with placeholder commands where the vendor-specific work would go.

#!/usr/bin/env bash
# step-ledger.sh — illustrative harness, not tied to any vendor CLI.
set -euo pipefail
LEDGER="${LEDGER:-./onboarding.jsonl}"
RUN_ID="$(date -u +%Y%m%dT%H%M%SZ)"

stamp() { # stamp <step> <phase> [note]
  printf '{"run":"%s","step":"%s","phase":"%s","ts":"%s","note":"%s"}\n' \
    "$RUN_ID" "$1" "$2" "$(date -u +%Y-%m-%dT%H:%M:%S.%3NZ)" "${3:-}" >> "$LEDGER"
}
begin() { stamp "$1" begin "${2:-}"; }
end()   { stamp "$1" end   "${2:-}"; }

begin signup  "no card, real email"
# ... whatever the tool asks for ...
end   signup

begin install "docs command, copy-pasted verbatim"
# ... paste the installer line from the docs ...
end   install

begin firsttask "ask for a one-line fix, nothing else"
# ... send the request and wait for output ...
end   firsttask

The rules matter more than the code. Copy the documented command verbatim, because paraphrasing from memory hides the moment the docs failed. Tag each step with a short note about what happened, since the note is what turns a bar on a chart into an actionable complaint. Never edit the ledger by hand, because a hand-edited measurement is a story, and stories are exactly what this exercise exists to replace.

Turn the log into a ranked complaint

A raw log is still just a log, so the second half of the instrument ranks the steps by cost and prints a total. Sorting descending is deliberate: the top line is the fix you should try first, and everything below it is noise until that one is addressed. The printer is short enough to read in one pass, which matters because you will want to trust it.

#!/usr/bin/env python3
"""ledger.py — turn onboarding.jsonl into a ranked friction ledger."""
import json, sys
from collections import defaultdict
from datetime import datetime

def ts(s): return datetime.strptime(s, "%Y-%m-%dT%H:%M:%S.%fZ")

rows = [json.loads(l) for l in open(sys.argv[1]) if l.strip()]
runs = defaultdict(dict)
for r in rows:
    runs[r["run"]].setdefault(r["step"], {})[r["phase"]] = (ts(r["ts"]), r["note"])

run = sys.argv[2] if len(sys.argv) > 2 else next(iter(runs))
total, ranked = 0.0, []
for step, phases in runs[run].items():
    if "begin" in phases and "end" in phases:
        d = (phases["end"][0] - phases["begin"][0]).total_seconds()
        ranked.append((d, step, phases["begin"][1]))
        total += d

for d, step, note in sorted(ranked, reverse=True):
    print(f"{d:7.1f}s  {step:<12} {note}")
print(f"{total:7.1f}s  TOTAL")

Run it and you get a shape like signup 3.9s, install 214.0s, firsttask 41.2s, and those figures are illustrative of the format rather than a claim about any tool. The interesting part is how often the largest line is not the model, not the signup, but the local runtime install. It is also the step people skip when they retry, which is why they conclude the second attempt was faster when the machine was simply warm.

The one fix that mattered

Here is the change that moved the number more than any other, and it has nothing to do with which model answered. Replace the first task with a task that must end in a verifiable diff, using a two-file fixture you already know the correct answer to. A chat reply is unfalsifiable in the first fifteen minutes; a diff against a failing test is not. So I start every trial like this.

mkdir -p fixture && cd fixture
printf 'def add(a, b):\n    return a - b\n' > calc.py
printf 'from calc import add\nassert add(2, 3) == 5\n' > test_calc.py
python -m pytest -q   # fails: this failure is your baseline

Now the first prompt is boring on purpose: fix the failing assertion and return a patch, not an explanation. You apply the patch, you rerun pytest, and the run either passed or it did not, which means the onboarding measurement ends with a boolean instead of an impression. I label this metric time to first verifiable diff, and it collapses a dozen vague first-run complaints into one number you can compare across tools without arguing about style. Should you trust a tool that needs forty minutes to reach a green test more than one that needs four, when the second one also answers every unrelated question beautifully?

Where a zero-cost tier changes the ledger

Two of the steps in that ledger are pure overhead, and neither of them teaches you anything about the tool. One is billing setup, and the other is provisioning a machine before you can see whether the edit loop even works for you. MonkeyCode, which I encountered as an open-source coding agent project, addresses both by being reachable without a payment step and by offering a free server option, so the first pass of the ledger can run without either of those entries. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The free model access is the part that keeps an evaluation cheap enough to abandon, which honestly is the property I care about most.

I am not going to quote a token allowance, a model list, or a server specification here, because I cannot verify those from where I sit and free tiers change quietly. The project's own pages are the only honest source for current limits and terms, so read them before you build anything that depends on them. Treat the free path as a way to get a first data point, never as the foundation of a pipeline whose reproducibility you actually need. A ledger you can rerun tomorrow is worth more than a discount you cannot predict.

Who should skip this approach

If your code cannot leave your network, the free-server path is irrelevant and the harness only helps you measure friction you were never going to pay. If your team needs SSO, audit logs, and deterministic model pinning, optimizing first-run minutes is optimizing the wrong axis, and the ledger will just document the wrong constraint. And if you already have a working loop you trust, the instrument is unnecessary, because you are no longer onboarding and there is nothing here to localize.

For everyone else, the transferable artifact is about sixty lines of shell and Python, and it survives whichever tool you abandon next quarter. If a zero-cost first pass makes that instrument cheap to run, start there, keep your own copy of the numbers, and let the top line of your ledger decide what you fix tomorrow.

Clock the First Fifteen Minutes

Quinn Wang — Sun, 11 Oct 2026 21:30:56 +0000

The first fifteen minutes of an AI coding session are the product test, not a warm-up you can skip. If you cannot name the friction in that window, you should not trust the diff that follows it. I treat that opening as a drill, because chatter is an easy way to lose an afternoon without a diff. Have you ever closed a setup feeling productive, only to find that nothing reviewable landed in the tree?

Models keep getting louder in public, while the first edit on a real repository stays oddly quiet. I would run those minutes like a short drill, with a clock I own and a budget set before any prompt. A model can sound clever and still burn the window on a wrong directory or a silent authentication hop. The one fix I would bet on is not a smarter prompt, and it is not a longer context window either.

It is a friction ledger that refuses the first real edit until four cheap checks each have a timestamp. Think of that opening quarter hour as a kitchen in the tense minutes just before service begins. You can hire a famous chef and still miss the plate if the oven is cold and the ticket is blank. The coding assistant is the chef in this picture, and the oven is the working tree you meant to change.

The ticket is the task you can replay later, and the clock is the only judge that does not flatter you. I split the drill into four beats, and I give each beat a budget before I type a single prompt. Reach means I can talk to a model without guessing which door actually opened underneath me. Place means the process cwd is the repository I intend to change, not a parent folder I opened by habit.

Read means git status is clean enough that a later diff belongs to this session and not to yesterday. Touch means a throwaway branch can be created and deleted, which puts git state back where it started. If any beat blows the budget I chose, I stop and write down why before I try the next door. Have you ever restarted a tool three times and still been unable to say which minute failed?

An unlabeled restart just moves the same fog forward, which is how a short setup becomes an afternoon. The script below is a proposal I have not executed against any vendor dashboard, so the numbers are your budgets. It writes a ledger outside the work tree, then checks place, read, and a reach note you measured by hand. Only after those beats pass does it create and delete a scratch branch, so touch is proof rather than a guess.

#!/usr/bin/env node
// Unexecuted proposal: time the first fifteen minutes. Not a vendor benchmark.
// node dx-drill.mjs --reach-ms 8000 --reach-note "plain reply, no file yet"
import { execFileSync } from "node:child_process";
import { appendFileSync } from "node:fs";
import { tmpdir } from "node:os";
import { join } from "node:path";

const args = new Map();
for (let i = 2; i < process.argv.length; i += 2) {
  args.set(process.argv[i], process.argv[i + 1]);
}

const budgetMs = {
  place: Number(process.env.BUDGET_PLACE_MS || 30000),
  read: Number(process.env.BUDGET_READ_MS || 30000),
  reach: Number(process.env.BUDGET_REACH_MS || 120000),
  touch: Number(process.env.BUDGET_TOUCH_MS || 180000),
};

const ledgerPath = process.env.FRICTION_LEDGER || join(tmpdir(), "friction-ledger.jsonl");
const started = Date.now();

function stamp(step, ok, detail, measuredMs) {
  const wallMs = Date.now() - started;
  const elapsedMs = measuredMs ?? wallMs;
  const budget = budgetMs[step] ?? null;
  const row = {
    step,
    ok,
    elapsedMs,
    wallMs,
    budgetMs: budget,
    overBudget: budget != null && elapsedMs > budget,
    detail,
    at: new Date().toISOString(),
  };
  appendFileSync(ledgerPath, JSON.stringify(row) + "\n");
  if (!ok || row.overBudget) {
    console.error("stop:", step, JSON.stringify(row));
    process.exit(2);
  }
  console.log("pass:", step, elapsedMs + "ms");
}

function git(gitArgs) {
  return execFileSync("git", gitArgs, { encoding: "utf8" }).trim();
}

const cwd = process.cwd();
const top = git(["rev-parse", "--show-toplevel"]);
stamp("place", cwd === top, { cwd, top });

const status = git(["status", "--porcelain"]);
stamp("read", status.length === 0, { status: status || "clean" });

const reachMs = Number(args.get("--reach-ms"));
const reachNote = args.get("--reach-note") || "";
stamp(
  "reach",
  Number.isFinite(reachMs) && reachMs >= 0 && reachNote.length > 8,
  { reachNote },
  reachMs
);

const branch = "dx-drill-scratch";
let created = false;
try {
  git(["switch", "-c", branch]);
  created = git(["branch", "--show-current"]) === branch;
} finally {
  if (created) {
    git(["switch", "-"]);
    git(["branch", "-D", branch]);
  }
}
stamp("touch", created, { branch, restored: created });
console.log("ledger", ledgerPath);

Save that file as dx-drill.mjs at the repository root, and run it only after you have timed a plain reply. Pass your own latency and a short confession in --reach-ms and --reach-note after that plain reply. If you launch the file from a parent folder, place should fail before any scratch branch is created. I would read the stop line, then open the ledger path the script prints, instead of guessing from memory.

The reach flag is a confession, not a probe, and that is why the script refuses a note that is too short. A green HTTP status can still mean you reached a model you did not choose, or a queue that will miss your window. I want the note to say what I asked, how long the reply took, and whether any file or branch changed. Have you watched a fluent answer land in the wrong tree and then blamed the weights for a path mistake?

The operator asked me to time this drill against MonkeyCode's free model access and its free server option. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The operator also describes the project as open source, which you should confirm on the project page itself. I do not have a measured quota, a hardware sheet, or a permanence promise here, so I will not invent figures.

I would not start that session by asking for a feature, a migration, or a clever refactor of a large file. I would start the ledger, confirm which door I opened, and only then ask for the same scratch branch and nothing else. If the free server path spends most of the fifteen minutes on provisioning, that is a useful result rather than a model failure. If the free model path answers quickly but never changes git state, the ledger keeps that failure apart from the server story.

The same drill still helps if you swap the product name for any other assistant you already have installed. That portability is deliberate, because a first-fifteen-minute test that only flatters one brand is not a test. I also will not claim that this setup is faster, cheaper, or more accurate than tools I have not measured side by side. Have you noticed how a smooth landing page can hide a slow first edit, and how a plain ledger makes that swap visible?

I would not use this approach if you need a compliance sign-off, a published benchmark, or a promise about free-tier duration. The script does not prove quality, safety, or cost, and the local budgets mostly catch a hung git. Teams without local git, a current Node, or git switch should skip it, because the drill assumes a repository you control. If your host forbids new branches, pick another reversible touch, and do not let the assistant choose that touch.

If a previous scratch branch is still around, touch will fail, and that failure is the drill doing its job. Point FRICTION_LEDGER outside the repository, delete the leftover branch, and rerun git status --porcelain until it is empty. Then time the two doors separately, once for free model access and once for the free server option, without averaging them. A blended score is how the first fifteen minutes become a story instead of a record you can argue with later.

If you want a next step, run the drill once on the free model door and the free server door you already have. Keep the ledger, then decide from your own timestamps whether those first fifteen minutes earned a second session. I would rather read a messy ledger than hear that a demo felt smooth, because smoothness is not a diff. The clock will not make the model wiser, but it will stop you from paying an afternoon for a setup you never named.

Echo the Marker Before You Edit

Quinn Wang — Sat, 10 Oct 2026 17:54:29 +0000

I do not trust an assistant in the first fifteen minutes until it can echo a marker I just wrote into the tree. A lively chat only proves that tokens can travel, which is a different question from whether this workspace is the one under discussion. If the marker never comes back, I stop the session and fix visibility before I ask for a single change. Would you keep driving if the mirror showed a street you do not recognize at all?

The first quarter hour usually fails in a quiet way, not with a dramatic crash you can screenshot for a teammate. You authenticate, pick a model, watch a spinner settle, and then paste a paragraph about a refactor you have been avoiding. The reply sounds confident and names a few files, yet it still misses the function that actually hurts. That miss usually means the tool is staring at a sample repo, a parent directory, or yesterday's checkout instead of this one.

I treat that miss as a visibility failure, not as a prompt that needs one more adjective and a second try. Another attempt only spends the session on a conversation that cannot see the code you actually care about. The one fix I keep is smaller than a new prompt template and ruder than most setup guides admit. Would you hire a contractor to remodel a kitchen they have not been shown how to enter?

The fix is a marker probe that runs before the first real request and refuses to continue when the echo is wrong or missing. I drop a tiny file into the working tree and fill it with a random token that training data could not have memorized. Then I ask the assistant to read that one file and repeat the token, with no advice and no edits attached. If the token comes back intact, I know this session can see this tree, and only then do I allow a change.

Think of the marker as a coat check ticket rather than a unit test for the product you are building. The attendant does not need to understand your coat, and the assistant does not need your architecture either. The only job is to hand the same ticket back, and a wrong ticket means you are standing at the wrong counter. Why would I let a stranger hem the sleeves before they can read the number printed on the stub?

The script below is a local proposal you can run, and I am not reporting a benchmark, a quota, or a lab result. It refuses to start outside a git work tree, writes a short random token, and prints a prompt that forbids edits. I try to keep the probe directory out of history when the ignore file is writable, so a passed check does not become junk. If your policy forbids even a scratch file, skip the script and do not weaken that rule just to watch a demo.

#!/usr/bin/env bash
# visibility-probe.sh — local proposal, not a measured benchmark.
set -euo pipefail

root="$(git rev-parse --show-toplevel 2>/dev/null || true)"
if [[ -z "${root}" ]]; then
  echo "FAIL: not inside a git work tree"
  exit 2
fi

cd "${root}"
probe="${root}/.visibility-probe"
mkdir -p "${probe}"

if command -v openssl >/dev/null 2>&1; then
  token="$(openssl rand -hex 8)"
else
  token="$(od -An -N8 -tx1 /dev/urandom | tr -d ' \n')"
fi

printf '%s\n' "${token}" > "${probe}/MARKER"

if [[ -w "${root}/.gitignore" || ! -e "${root}/.gitignore" ]]; then
  if ! grep -qxF '.visibility-probe/' "${root}/.gitignore" 2>/dev/null; then
    printf '%s\n' '.visibility-probe/' >> "${root}/.gitignore"
  fi
fi

echo "cwd=${root}"
echo "marker_file=${probe}/MARKER"
echo "expected_token=${token}"
echo "Accept no edit until the echo check prints PASS."
cat <<'EOF'
Read only .visibility-probe/MARKER from the repository root.
Reply with the single token in that file and no other words.
Do not edit files. Do not explain the token. Do not propose a refactor.
EOF

After the assistant replies, I pipe that reply into a second command that compares it with the file on disk. A match is not a celebration, and a mismatch is not a mystery I solve by rephrasing the question in a longer voice. The checker strips whitespace so a trailing newline cannot fake a different workspace and push me to ignore later probes. What would you gain by negotiating with a reply that cannot repeat sixteen hex characters sitting in plain sight?

#!/usr/bin/env bash
# check-echo.sh — usage: pbpaste | ./check-echo.sh
set -euo pipefail

root="$(git rev-parse --show-toplevel)"
expected="$(tr -d '[:space:]' < "${root}/.visibility-probe/MARKER")"
got="$(tr -d '[:space:]')"

if [[ -n "${expected}" && "${got}" == "${expected}" ]]; then
  echo "PASS: marker echoed; this session can see this tree"
  exit 0
fi

echo "FAIL: expected [${expected}] but received [${got}]"
echo "Stop. Fix the folder mount before you request an edit."
exit 1

I run those two commands in order, and I read a FAIL line before I touch the original request again. On Linux I replace pbpaste with xclip reading the clipboard, because the probe should fit the machine I already trust. A PASS only means I may ask for one small change in a named file, and I still review the diff before I commit. Have you ever debugged a suggestion for ten minutes and then learned the tool was describing a sibling directory?

chmod +x visibility-probe.sh check-echo.sh
./visibility-probe.sh
# Copy the printed prompt into the assistant, then pipe only its reply.
pbpaste | ./check-echo.sh
# Linux alternative:
# xclip -selection clipboard -o | ./check-echo.sh

When the check fails, I do not open a second chat and hope, because luck is not a mounting strategy. I print the working directory, confirm the marker file still exists, and compare its contents with the string I thought I sent. Then I check whether the assistant was attached to a parent folder, a container path, or a sample that shares my project name. If those three glances still do not explain the miss, I stop rather than teaching myself that a blind session is normal.

When the echo should happen in a hosted room, I use MonkeyCode's free model access and its free server option for that single try. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I am leaning on those two availability facts only, not on names, allotments, hardware, or a promise that the offer stays forever. Run the probe there if that room is simplest, read PASS or FAIL yourself, and do not let the room decide what done means.

The probe has sharp edges, and I would rather name them than let a green PASS travel further than it deserves. An echoed token shows that this session can read that one file, not that every path is visible and not that writes will land. It will not catch a reply that repeats the marker and then invents an edit in a file it never opened. Anyone who needs a reviewed production change, an air-gapped process, or a ban on scratch files should skip this shortcut.

I also refuse to hide secrets in the marker, because a hosted model may log whatever string you ask it to repeat. Use random output from openssl or any other non-secret string, then delete the probe directory when the session ends. If the ignore append fails because the ignore file is read-only, remove the marker yourself before you commit anything. Does a fifteen-minute win still count if you spend the evening scrubbing a token out of the remote history?

If the echo passes, my next message stays boring on purpose: one named file, one failing command, and only the change that command needs. I do not ask for a tour or a redesign while the session is young, because the marker only bought specificity. You can delete the chat once the diff is saved or once the check fails, so those first minutes never turn into a diary. Is there a better use of a fresh session than proving it can see the file before it is allowed to touch one?

Write the Receipt Before the Chat

Quinn Wang — Fri, 09 Oct 2026 14:26:10 +0000

The one fix I trust for those first fifteen minutes is a local session receipt, written before any agent is allowed to speak. I kept treating the green ready badge as permission, and that habit is what burns the opening quarter hour. Would you let a contractor start painting before you wrote down which room they may enter? I would not, yet I keep opening coding agents with less paperwork than I give a house painter.

The friction showed up as a polite chat box, not as an error, which is why I trusted it for so long. The cursor blinked, the model picker looked alive, and I started describing the bug before I named the tree. Ten minutes later I had three suggestions and no record of the directory those suggestions were allowed to touch. Does a blinking cursor feel like progress to you, or does it feel like a waiter who never wrote the order down?

I used to spend that opening stretch negotiating with the tool about scope, as if conversation could replace a boundary. The agent would offer a patch for a file I had not opened, then ask whether I wanted a broader refactor. I would answer, because silence felt rude, and that answer became the only spec the session had. Have you noticed how a helpful coding tool turns your very first reply into an accidental contract?

The analogy that finally stuck was a coat check, not a dashboard, because dashboards flatter you. You do not get your coat back because the lobby looked elegant; you get it back because someone wrote a number. A coding session needs that same numbered stub before the conversation starts, or the lobby will eat the afternoon. I stopped asking which model felt smarter, and I started asking which stub I could still read after a crash.

What I write down first

The receipt is a small JSON file in the repo, created by a script I run before I open the agent at all. It records the working directory, the branch, the commit, the dirty paths, and the write roots I am willing to allow. It also records the execution surface I chose, because a local shell and a remote server are not the same room. If that file is missing or stale, the guard exits, and the chat never gets a chance to become my spec.

Free access is exactly where my first fifteen minutes get sloppy, because the price tag no longer slows my hand. I open the chat the way I open a sample, and I forget that a sample can still write into a real tree. A free server makes that mistake worse, since the files may land somewhere I cannot see from this laptop. Would you skip the coat check because the cloakroom was complimentary, or would you want the stub even more?

The guard I actually run

The script below is a proposal I have not executed against a live MonkeyCode server in this draft, so treat it as a sketch. I want the guard to be boring, local, and fail-closed, because a clever guard becomes another thing I have to debug at midnight. You can drop the file at the repo root, mark it executable, and run it before you touch the agent UI. If your team already has a workspace contract, keep that contract, and use this only as a personal preflight.

#!/usr/bin/env bash
# proposal: unexecuted preflight. Writes .session-receipt.json, then refuses a stale stub.
set -euo pipefail

root="$(git rev-parse --show-toplevel)"
cd "$root"

surface="${SESSION_SURFACE:-local}"          # local | free-server
write_roots="${SESSION_WRITE_ROOTS:-src,tests}"
max_age="${SESSION_RECEIPT_MAX_AGE:-900}"

if [[ "$surface" != "local" && "$surface" != "free-server" ]]; then
  echo "refusing: surface must be local or free-server" >&2
  exit 2
fi

export SESSION_ROOT="$root"
export SESSION_BRANCH="$(git rev-parse --abbrev-ref HEAD)"
export SESSION_HEAD="$(git rev-parse HEAD)"
export SESSION_STATUS="$(git status --porcelain)"
export SESSION_SURFACE="$surface"
export SESSION_WRITE_ROOTS="$write_roots"
export SESSION_NOW="$(date -u +%Y-%m-%dT%H:%M:%SZ)"
export SESSION_MAX_AGE="$max_age"

python3 - <<'PY'
import json, os
from pathlib import Path
root = Path(os.environ["SESSION_ROOT"])
roots = [p.strip() for p in os.environ["SESSION_WRITE_ROOTS"].split(",") if p.strip()]
if not roots:
    raise SystemExit("refusing: write_roots empty")
receipt = {
    "schema": "session-receipt/v1",
    "written_at": os.environ["SESSION_NOW"],
    "cwd": str(root),
    "branch": os.environ["SESSION_BRANCH"],
    "head": os.environ["SESSION_HEAD"],
    "porcelain": [ln for ln in os.environ["SESSION_STATUS"].splitlines() if ln],
    "surface": os.environ["SESSION_SURFACE"],
    "write_roots": roots,
    "max_age_seconds": int(os.environ["SESSION_MAX_AGE"]),
    "note": "records intent only; this file is not a sandbox",
}
path = root / ".session-receipt.json"
path.write_text(json.dumps(receipt, indent=2) + "\n", encoding="utf-8")
print(f"wrote {path}")
PY

python3 - <<'PY'
import json
from datetime import datetime, timezone
from pathlib import Path
path = Path(".session-receipt.json")
data = json.loads(path.read_text(encoding="utf-8"))
written = datetime.strptime(data["written_at"], "%Y-%m-%dT%H:%M:%SZ").replace(tzinfo=timezone.utc)
age = (datetime.now(timezone.utc) - written).total_seconds()
if age > data["max_age_seconds"]:
    raise SystemExit(f"refusing: receipt is {int(age)}s old")
print(
    "receipt ok surface=%s roots=%s head=%s"
    % (data["surface"], ",".join(data["write_roots"]), data["head"][:12])
)
PY

I run that script, read the porcelain list out loud, and only then do I allow myself to open the chat. If the status shows a file I did not expect, I stop, because I would have blamed that mess on the model. The free-server label does not prove the server is empty; it only forces me to admit I chose a room I cannot see. Is that a weak guarantee, and is a weak named guarantee still better than a strong feeling?

chmod +x ./session-receipt.sh
git checkout -b scratch/receipt-drill
SESSION_SURFACE=free-server SESSION_WRITE_ROOTS=src,tests ./session-receipt.sh
# I open the agent only after the guard prints "receipt ok".
grep -qxF '.session-receipt.json' .gitignore || printf '%s\n' '.session-receipt.json' >> .gitignore

How the fifteen minutes move

Here is how the first fifteen minutes used to go, and how the receipt changes the middle of that stretch. Minute one was connection theater, minute four was a vague prompt, and minute nine was a diff I could not narrate. With the guard, minute one is the script, and minute four is a prompt that quotes those write roots. By minute nine I still have a diff, but I can match it to a stub instead of reconstructing the chat from memory.

I do not pick the surface by vibe, and I do not pick it by whichever button is already highlighted in the UI. If the change is a typo I can see, I label the surface local and keep the write root narrow. If I want a disposable room, I label the surface free-server, and I still name the roots I expect back. If I cannot name a root, I do not have a task yet, so why open a free path on a foggy wish?

The prompt I paste is dull on purpose, because a colorful prompt is how I smuggle scope past my own guard. I write the branch, the head, the surface, and the roots in the first lines, then I describe the bug in one sentence. I ask the agent to refuse any path outside those roots, knowing full well a sentence is not a sandbox. Would you trust a promise inside a chat more than a file you can diff, or have you already been burned that way?

branch: scratch/receipt-drill
head: <paste from receipt>
surface: free-server
write_roots: src, tests
task: explain the null check in src/parse.js and propose a patch only inside those roots.
If a path falls outside write_roots, stop and say so. Do not create files I did not name.

After the agent answers, I do not accept anything until I rerun git status and compare it with the porcelain I stored. A new path outside the write roots means I stop, even if the patch looks clever, because clever and bounded are different compliments. I then append a one-line note to the receipt by hand, recording whether I applied, rejected, or abandoned the suggestion. That note is the whole retrospective, and it takes less time than rewriting the prompt because I felt impatient.

python3 - <<'PY'
import json
from pathlib import Path
data = json.loads(Path(".session-receipt.json").read_text(encoding="utf-8"))
Path(".session-receipt.porcelain").write_text(
    "\n".join(data["porcelain"]) + "\n",
    encoding="utf-8",
)
PY
git status --porcelain > .session-now.porcelain
diff -u .session-receipt.porcelain .session-now.porcelain || true

Where the stub lies to you

This approach fails when you treat the receipt as a cage, because the file cannot stop a remote process you do not control. Clock skew, a dirty submodule, or a file matched by gitignore can make the stub look cleaner than the tree you actually have. If you are in a live incident with a named owner, skip the ceremony and use the runbook you already trust. If the directory is empty and disposable, the receipt may cost more than the experiment, and you should not pretend otherwise.

I would also skip this if your platform already mints a signed workspace contract before the agent can start. Duplicating that contract in a side file creates two truths, and two truths are how the first fifteen minutes get confusing again. The receipt covers the gap where the UI says ready and your disk has not agreed yet. Does your current tool even let you see that gap, or does the ready badge cover it with a friendly color?

If a free model path and a free server are already available, run the guard on a throwaway branch first. I am not asking you to stay, and I am not claiming the receipt makes any vendor correct. I am asking whether your next fifteen minutes can start with a stub you could still read after the tab crashes. That question is the whole practice, and the model you pick is just the coat you handed over the counter.

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

Name the File Before You Accept

Quinn Wang — Thu, 08 Oct 2026 10:13:36 +0000

I stop trusting an AI coding session the moment I cannot name the file it would change. A fluent answer can still be a rumor until a patch, a path, and a dry run exist on disk. If those three things are missing, I am watching a polished demo rather than reviewing actual work. Would you merge a teammate's change if you could not point to it in git status?

The first fifteen minutes are where that confusion hides, because everything looks busy and almost nothing is inspectable. You open the tool, you paste a task, and a confident block of code arrives before your coffee cools. The spinner feels like progress, yet the working tree may still be exactly the tree you started with. Have you ever accepted a suggestion and then failed to find it with a simple status command?

That gap is the friction I care about, not the color of the onboarding screen and not the speed of the first reply. You can have a glowing editor, a scrolling chat, and a still-clean branch because the suggestion never left the transcript. A transcript is a conversation, while a patch is a claim you can refuse, replay, or hand to someone else. Which of those two artifacts would you rather defend when a reviewer asks for the change tomorrow morning?

So the one fix that mattered was boring, and that is why it survived contact with a real repository. I write the model's proposed change to a patch file before I let anything touch the working tree. Then I run a dry apply, record the repository fingerprint, and only then decide whether the suggestion deserves a human edit. Does that sound slower than clicking accept, or does it sound like the first moment the session becomes reviewable?

Here is a small Node script I would keep beside the repo while testing that habit. I am labeling it as a proposed local check, not as a benchmark and not as a result from a measured lab. It shells out to git, writes a receipt, and exits non-zero when the patch cannot be applied cleanly. You can drop the file in scripts/session-receipt.mjs and run it with Node eighteen or any newer release.

#!/usr/bin/env node
// Proposed local check. It does not call a model and it does not modify tracked files.
// Add .session-receipts to .gitignore so a path receipt never becomes a commit.
import { execFileSync } from "node:child_process";
import { mkdirSync, writeFileSync, readFileSync, existsSync } from "node:fs";
import { resolve } from "node:path";

const patchPath = resolve(process.argv[2] || "proposal.diff");
const outDir = resolve(".session-receipts");

if (!existsSync(patchPath)) {
  console.error(`missing patch: ${patchPath}`);
  process.exit(2);
}

function git(args) {
  try {
    return execFileSync("git", args, { encoding: "utf8" }).trim();
  } catch (error) {
    const detail = error.stderr ? error.stderr.toString() : error.message;
    console.error(detail);
    process.exit(2);
  }
}

mkdirSync(outDir, { recursive: true });

const head = git(["rev-parse", "HEAD"]);
const branch = git(["branch", "--show-current"]);
const status = git(["status", "--porcelain=v1"]);
const patch = readFileSync(patchPath, "utf8");

let apply = "clean";
try {
  execFileSync("git", ["apply", "--check", "--", patchPath], { stdio: "pipe" });
} catch (error) {
  const detail = error.stderr ? error.stderr.toString() : error.message;
  apply = `failed: ${detail.trim()}`;
}

const receipt = {
  recorded_at: new Date().toISOString(),
  head,
  branch,
  porcelain: status,
  patch_path: patchPath,
  patch_bytes: Buffer.byteLength(patch),
  apply_check: apply,
};

const stamp = receipt.recorded_at.replace(/[:.]/g, "-");
const receiptPath = resolve(outDir, `${stamp}.json`);
writeFileSync(receiptPath, JSON.stringify(receipt, null, 2));
console.log(receiptPath);
console.log(apply);
process.exit(apply === "clean" ? 0 : 1);

I would run it only after saving the suggestion as proposal.diff, because the script will not invent a diff. A typical first pass looks like the three commands below, and none of them require a network call. If the dry run fails, I still have the receipt, and the working tree remains untouched by the suggestion. Is that not a better failure than a half-applied edit you only notice after you come back from lunch?

test -s proposal.diff
node scripts/session-receipt.mjs proposal.diff
git apply --check -- proposal.diff && echo "hunks fit; behavior still unproven"

The commands only prove that a saved diff fits this tree, and they say nothing about whether the behavior is desirable. If the assistant printed a unified diff, I paste that diff into proposal.diff and I do not let the editor apply it for me. If it printed a whole file instead of a diff, I stop and ask for a unified diff against the current file. Why would I accept a rewrite I cannot compare line by line with the file already on disk?

This is where a disposable server becomes useful, and I want the relationship stated before the tool name does any work. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The brief I was given treats free model access and a free server option as available, without a verified quota or hardware spec. I would use MonkeyCode's free server as a scratch workspace, then bring home only a patch that git apply --check already accepted.

I am not treating those availability claims as a performance result, because a free seat does not prove the patch is correct. Read the current docs before you rely on any allowance, since token budgets and server lifetimes move and this article will not chase them. If the docs and the product disagree with a number you saw in a post, believe the docs you can open today. Would you rather cite a changelog you just read, or cite a paragraph that cannot age honestly?

The teardown of those first fifteen minutes usually fails in the same three places, even when the model sounds sharp. First the session cannot prove which commit it saw, so the suggestion argues with a tree you no longer have. Then the accept control sits closer than the diff, so your hand finishes a review your eyes have not started. Have you checked whether your last accepted edit left a path a colleague could open without asking you?

Finally the only surviving record often lives in a chat log that your teammate cannot clone, rerun, or dispute. The receipt script answers the identity failure and the missing-record failure, and it slows the careless click enough to matter. The head and branch fields tell you which snapshot the check ran against, while porcelain shows whether the tree was already dirty. A failed dry run is still a successful diagnosis, because you learned the suggestion does not match this particular tree.

I would not use this approach when the change involves a secret, a migration, or a release commit your policy says must be signed. A local receipt is not an approval system, and it will happily bless a valid patch that deletes the wrong table. Do not paste production credentials into a hosted session just because that server was free to start. If your team needs audit trails, locked runners, or a human gate before model output exists, this scratch workflow is the wrong shape.

There is another limit that shows up quickly, and it is smaller than policy and just as able to waste an afternoon. A clean apply check does not understand intent, tests, or the comment you meant to update three files away. Binary assets, renames, and already-dirty files can make a tidy chat diff fail for purely mechanical reasons. When that happens, can you shrink the task until the patch names one file you could read aloud?

If I were handing this ritual to my future self, I would keep it under five minutes and refuse to add dashboards. Save the diff, run the receipt, read the hunks, and only then decide whether the suggestion earns its own branch. Once the receipt exists, the chat can close, because the claim finally has a filename someone else can open. If you want a disposable desk for that check, read the current free-server docs and ignore any allowance this post refused to freeze.

Accept Nothing You Cannot Replay

Quinn Wang — Thu, 08 Oct 2026 07:43:27 +0000

The first fifteen minutes of an AI coding session fail when you accept a diff you cannot replay the next morning. I keep watching the same quiet collapse, and it is rarely the login wall, the model menu, or the speed of the first token. You paste a goal, three files change, and nobody can name the command that was red before the edit landed. Would you merge a teammate's patch if the only remaining witness was a chat transcript and a hopeful shrug?

That shrug is the friction that actually eats the quarter hour, long before any architecture debate earns the right to speak. A mechanic who swaps parts before reading the fault code sometimes gets lucky, then cannot explain the repair. An assistant that edits before a named check is that mechanic, with your repository as the workshop and the diff as the invoice. If the first fifteen minutes do not end with a frozen failure, what exactly did you purchase with that time?

I do not need those minutes for a settings tour, a green spinner, or praise about how a tool understood the codebase. I want a working directory, one check command, a non-zero exit, and a short tail of the output that made the failure obvious. I do not want a rewritten module or a new dependency until that red exit has a name I can type again. If the check cannot fail on purpose before the patch, what are we asking any model to fix?

The one fix that changed the session for me was a replay card, a small file written before any edit is allowed. It freezes the command, the directory, the git revision, a fingerprint of the dirty tree, and the exit code you just watched. Later, that card is the only context worth pasting, and the same command is the only verdict worth trusting. If the card cannot be rerun in a clean shell, the session was a conversation, not a repair you can defend.

The script below is a local workflow you can copy, not a score I am pretending to have measured on your laptop. It writes .replay/card.env when you pass capture, and it reruns the frozen command when you pass verify. Nothing in the file calls a model, which is deliberate, because the witness should not depend on the assistant that proposed the change. Read it before you trust it, and keep the card out of any commit that might carry secrets from the failing run.

#!/usr/bin/env bash
set -euo pipefail

# Local proposal: bash, optional git, and shasum. Not a measured product benchmark.
card_dir="${REPLAY_DIR:-.replay}"
card="$card_dir/card.env"
mkdir -p "$card_dir"

tree_fingerprint() {
  if git rev-parse --is-inside-work-tree >/dev/null 2>&1; then
    printf '%s %s\n' \
      "$(git rev-parse HEAD)" \
      "$(git status --porcelain=v1 | shasum -a 256 | awk '{print $1}')"
  else
    find . -type f -not -path './.replay/*' -print0 \
      | sort -z | xargs -0 shasum -a 256 | shasum -a 256 | awk '{print $1}'
  fi
}

capture() {
  local cmd="$1" log exit_code
  log="$(mktemp)"
  set +e
  bash -lc "$cmd" >"$log" 2>&1
  exit_code=$?
  set -e
  {
    printf 'captured_at=%q\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)"
    printf 'workdir=%q\n' "$PWD"
    printf 'tree_fp=%q\n' "$(tree_fingerprint)"
    printf 'cmd=%q\n' "$cmd"
    printf 'exit_before=%q\n' "$exit_code"
  } >"$card"
  tail -n 40 "$log" >"$card_dir/stderr-before.txt"
  rm -f "$log"
  printf 'captured exit_before=%s into %s\n' "$exit_code" "$card"
  if [[ "$exit_code" -eq 0 ]]; then
    echo "warning: freeze a failing command before you ask for a patch" >&2
    exit 2
  fi
}

verify() {
  # shellcheck disable=SC1090
  source "$card"
  local log exit_code
  [[ -n "${cmd:-}" && -n "${exit_before:-}" ]] || {
    echo "card is incomplete" >&2
    exit 3
  }
  log="$(mktemp)"
  set +e
  bash -lc "$cmd" >"$log" 2>&1
  exit_code=$?
  set -e
  tail -n 40 "$log" >"$card_dir/stderr-after.txt"
  rm -f "$log"
  printf 'exit_before=%s exit_after=%s\n' "$exit_before" "$exit_code"
  if [[ "$exit_before" -eq 0 ]]; then
    echo "card was not a failing check" >&2
    exit 3
  fi
  if [[ "$exit_code" -ne 0 ]]; then
    echo "still red; do not treat the diff as the fix" >&2
    exit 1
  fi
  echo "same command flipped to zero"
}

case "${1:-}" in
  capture) capture "${2:?command required}" ;;
  verify) verify ;;
  *) echo "usage: replay-card.sh capture '<command>' | verify" >&2; exit 64 ;;
esac

A session that respects the card starts with a command you already believe should pass, then captures the moment it does not. I usually point it at one file-scoped check, because a full suite hides the failure inside a crowd of unrelated green lines. After the card exists, and only after exit_before is non-zero, I allow an edit of any kind. The verify step is intentionally dumb: same words, same shell, and a demand that the recorded red exit become zero.

chmod +x replay-card.sh
./replay-card.sh capture 'npm test -- src/parser.test.js'
# card must exist, and exit_before must be non-zero, before any edit
./replay-card.sh verify
git diff --stat

If verify is still red, the patch is only a hypothesis wearing a confident tone, and the chat does not get a vote. I treat that red line as the session still being inside its opening quarter hour, no matter how many files already changed. A green verify is permission to read the diff carefully, not permission to stop asking whether the check was weak.

Notice what the fingerprint is not allowed to do during the verdict, even though the card bothers to store it. A real fix must change the tree, so locking the porcelain hash would freeze the bug and call that stillness purity. I keep tree_fp as a breadcrumb for the morning after, the way a mechanic keeps the old fault code on a clipboard. The lock is the command string plus the exit flip, not the beauty of the diff and not the confidence of the chat.

This is where a free model session earns a narrow job, and where I should be plain about the relationship before going further. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I would paste the command and the stderr tail there, and I would ask only for a patch aimed at that card. I would run verify on the free server option only as a second shell, not as proof the laptop was wrong.

I am not stating a quota, a model name, a hardware shape, a duration, or a promise that either free option stays fixed. The second shell is a witness rather than a trophy, and it counts only if it can build what the check command needs. If that server lacks the toolchain, green is noise and red is a portability finding, not an insult aimed at the model. Would a passing run on an empty image prove anything except that you skipped the hard dependency on purpose?

There is a temptation, once verify prints its one success line, to treat the quarter hour as finished and the review as optional. That temptation is how a flipped exit gets promoted into a feeling of safety that the card never actually earned. The card proves that one command changed its mind under one shell, which is more than a transcript and less than a careful reader. I still read the diff, and I still ask whether the check was too weak to notice a wrong fix.

Some failures should never enter this workflow, and pretending otherwise is how a tidy script becomes a leak. Do not capture a command that prints tokens, customer rows, or production URLs into .replay, and do not commit that directory by accident. Skip the method when the check is non-deterministic, because a flip to zero might be luck wearing a green coat. Skip it when you need signed provenance, an air-gapped policy, or a human gesture that no shell can honestly replay.

Teams with a gated CI job can keep the card local, then let CI be the stranger who reruns the same words. If your check needs a browser, a paid sandbox, or a secret you must not paste, leave the remote server out of the story. A local red-to-green flip is already a better first fifteen minutes than a chat that rewrote three files and wished you luck. Why hand the only copy of the failure to a window you might close before lunch?

If you already have a free model session and a spare server, refuse the first diff that arrives without a card. The useful question is not whether the assistant sounds sure of itself before you have looked at the exit. The useful question is whether tomorrow morning you can rerun the same words and watch that recorded red become zero. I would rather lose a clever patch than keep a repair I cannot replay on a clean shell the next day.

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.