DEV Community: Quinn Wang

The First 15 Minutes Are Usually One Step in Disguise

Quinn Wang — Sun, 08 Nov 2026 19:40:46 +0000

The step that decides whether a new tool survives your first fifteen minutes is rarely the tool itself; it is the one step you end up doing twice.

I keep running into the same pattern when I time a first-run session: the total elapsed time tells you almost nothing useful, because a single clumsy step quietly pays for itself three or four times. You sign in, you get bounced, you sign in again, and now the clock has doubled while the step count barely moved. Wouldn't it be better to measure the rework instead of the wall clock, since rework is the part you can actually delete?

So that is what this teardown does. I am going to walk through a small friction log that records each step, its duration, its exit code, and whether you had to redo it, and then I will show the one fix that mattered in the walkthrough I use below. The numbers in that walkthrough are a worked example you should replace with your own; please do not read them as a benchmark of any tool, including the one I mention later.

Why step counts lie to you

A setup guide is a list of steps, and a list of steps invites you to count them, which is exactly the wrong unit. Counting steps rewards guides that merge five confusing actions into one opaque command, and it punishes guides that are honest about the five actions. The thing your patience actually reacts to is interruption: the moment you stop being a visitor and start being a repair technician.

Rework has a nasty compounding shape too. A two-minute step you repeat three times costs more than a seven-minute step you do once, and it also costs you context, because each retry forces you to reload the mental state you had built. That is the analogy I keep coming back to: a single missing screw in a flat-pack shelf is not a small defect, because you disassemble the whole shelf to reach it.

A friction log you can run in one minute

The script below is deliberately tiny and dependency-free, and it wraps whatever entry point you already have rather than assuming a particular CLI. It writes tab-separated records, so you can paste the output straight into a spreadsheet or pipe it into the report that follows.

#!/usr/bin/env bash
# friction.sh — rework-aware log for a first-run session.
# Usage:  source ./friction.sh   then call step / rework.
set -uo pipefail

LOG="${FRICTION_LOG:-friction.log}"
: > "$LOG"

# step <label> <command...>
# Records wall time in ms, exit code, and an ISO timestamp.
step() {
  local label="$1"; shift
  local t0 t1 rc
  t0=$(date +%s%3N)
  "$@"; rc=$?
  t1=$(date +%s%3N)
  printf 'STEP\t%s\t%s\t%s\t%s\n' \
    "$label" "$((t1 - t0))" "$rc" "$(date -u +%FT%TZ)" >> "$LOG"
  return "$rc"
}

# rework <label> <ms_lost>  — call this the moment you realise you must redo a step.
rework() {
  printf 'REWORK\t%s\t%s\n' "$1" "$2" >> "$LOG"
}

Notice that rework takes a number you supply yourself, and that is intentional. You cannot measure the time you spent confused with a timestamp, because the confusion often starts before the command does, but you can absolutely write down your own estimate at the moment you notice it. An honest guess beats a fake precision every time.

Here is a session shape, using placeholders you should replace with your own entry point:

source ./friction.sh

step "read-landing-page" true          # always false-start: reading is a step
step "create-account"    true          # substitute your real command
step "first-answer"      "$ENTRY" "hello"

# the machine asked for a second sign-in before answering:
rework "first-answer" 90000            # 90s of repeated work, your estimate

step "second-answer"     "$ENTRY" "hello"

The report is three lines of awk and gives you the only two numbers worth keeping: how many steps failed loudly, and what share of the session was rework.

awk -F'\t' '
  $1=="REWORK" { rework += $3; next }
  $1=="STEP"   { total += $3; n++; if ($4 != 0) failed++ }
  END {
    denied = total + rework
    printf "steps=%d failed=%d work=%.1fs rework=%.1fs\n", n, failed, total/1000, rework/1000
    if (denied > 0) printf "rework share=%.0f%%\n", 100*rework/denied
  }' friction.log

What the example session showed me

In my worked example, four steps took roughly two minutes of real work, and one of them — getting a first answer out of the tool — was retried once for ninety seconds. That single retry was not the longest step, but it owned most of the session's cost, and it also produced the only moment where I considered closing the tab. Ask yourself which is worse for a first impression: a slow step that works, or a fast step that makes you start over?

That is why I now ignore the total and sort by rework share first. A step with high rework is a design bug wearing a progress bar, while a step that is merely slow is usually just the price of doing something real. Sorting this way also keeps me honest about my own impatience, because it distinguishes "this is slow" from "this made me do it again" and only the second one is the tool's fault.

The one fix that mattered

The fix was not a setting, a flag, or a better error message; it was reordering the guide so the shortest path to a first successful answer comes before any local installation. In practice that means you prove the round trip on someone else's machine first, and only then earn the right to configure your own. Setting up a local environment before you know the tool can answer you is like installing a kitchen before checking the water is on.

This is where hosted options genuinely change the shape of the first fifteen minutes. MonkeyCode is an open-source AI coding project, and its operator-supplied offer at the time of writing (November 2026) includes free model access and a free server option, advertised alongside a 10-million-token allotment; treat all of that as a time-sensitive claim to verify on its own pages rather than a permanent guarantee. Disclosure: This article was prepared as part of MonkeyCode's product outreach. What matters for this teardown is narrower than the marketing: a hosted first answer removes the install step from the rework-prone part of the session, which is the exact defect the log is built to surface.

Choosing a first path, honestly

Situation	Start hosted or free server	Start local install
Evaluating whether the tool fits your problem	Yes — first answer before config	No
Network policy blocks hosted inference	No	Yes, with a pinned version
Reproducing a bug across machines	No	Yes — local only
Teaching a workshop in 30 minutes	Yes — removes account roulette	No
Handling regulated source code	No	Yes, only if you have cleared it

Read the table as a default, not a rule, and re-run your own log whenever the guide changes, because onboarding decays faster than documentation admits. The log takes a minute, and it will tell you more about a tool's DX than any feature list ever could.

Limitations, and who should skip this

This method measures your session, not the product, and a single run has no statistical weight, so collect three or four sessions before you draw a conclusion. It also cannot see the cost you pay after the first fifteen minutes, which is where most real friction lives, and it says nothing about output quality.

If your team has data-residency constraints, needs a pinned model version for reproducible builds, or requires an SLA for production traffic, a free hosted path is the wrong default and you should start local. If you already have a working setup, this exercise is mostly a way to feel productive without shipping anything, so skip it. And if you cannot verify the current offer terms yourself, do not plan capacity around them.

If you want a disposable place to try the log, the free server path is the cheapest first answer you can get; go break it deliberately, then tell me which step made you start over.

Your First Run Has a Tab Budget

Quinn Wang — Sat, 07 Nov 2026 18:23:54 +0000

The first fifteen minutes of a new project almost never fail because some step is slow. They fail because you keep leaving the editor — one tab for the install docs, one for the auth page, one for the cloud console, one for the ticket where someone promised the env var already exists. If you have ever finished a setup session feeling tired without being able to name a single slow command, you already know this feeling; the wall clock was fine, but your attention was chopped into pieces. So the metric I want you to instrument is not minutes per step, it is how many times you leave the editor, and the fix that matters is almost always the same: collapse the browser-shaped steps into one command you can run without thinking.

Why does timing mislead us here? A npm ci that takes ninety seconds is annoying, but it is also a single uninterrupted block you can spend reading the diff of the repo you just cloned. Five separate thirty-second detours to find out which Node version the CI uses are worse, because each one costs you the reload of the mental model you had built up. Duration is additive and predictable; interruption is multiplicative and invisible. That is why a stopwatch on your setup script tells you almost nothing useful, and why the same project can feel smooth to one developer and hostile to another who simply had more tabs open.

Build the ledger before you build the fix

The artifact here is tiny: a script that timestamps every time you step away, so the shape of the problem shows up as a list rather than a vague memory. It is not clever and it is not automated — you type one command when you leave, one command when you come back, and that manual friction is the point, because it forces you to notice the switch while it is happening.

#!/usr/bin/env bash
# tablog — record every time you leave the editor during first-run setup
# usage: ./tablog start "clone repo"   then   ./tablog mark "docs: node version"
set -euo pipefail
LOG="${TABLOG_FILE:-$HOME/.tablog.csv}"
cmd="${1:-}"; label="${2:-unlabeled}"
epoch="$(date -u +%s)"
stamp="$(date -u +%Y-%m-%dT%H:%M:%SZ)"
case "$cmd" in
  start)  : > "$LOG"; printf '%s,%s,%s\n' "$epoch" "$stamp" "$label" >> "$LOG" ;;
  mark)   printf '%s,%s,%s\n' "$epoch" "$stamp" "$label" >> "$LOG" ;;
  report) awk -F, 'NR==1{start=$1; prev=$1; next}
                   {printf "%5ds  %s\n", $1-prev, $3; prev=$1}
                   END{printf "%5ds  total elapsed\n", prev-start}' "$LOG" ;;
  buckets) awk -F, 'NR>1{split($3,p," "); b[p[1]]++} END{for (k in b) print b[k], k}' "$LOG" ;;
  *) echo "usage: $0 {start|mark|report|buckets} [label]" >&2; exit 64 ;;
hesac

Run ./tablog start "fresh clone" in a clean checkout of a project you have never touched, then ./tablog mark "..." each time you switch away and each time you come back. The report mode prints one line per gap so you can see the rhythm; the buckets mode groups labels by their first word, which is how you discover whether your interruptions are mostly docs, mostly auth, or mostly cloud. An illustrative session, not a real one — yours will differ — might read docs 6, auth 3, cloud 4, and that distribution is the whole diagnosis. Six trips to the docs is not a documentation problem; it is a repository problem, because the answers should have been in the repo.

The one fix: move the browser steps into the repo

Here is the change that actually moved the needle for the pattern above, and it is embarrassingly small. Whatever you had to look up in a browser during the first run goes into a single checked-in file, and every step it describes becomes a target in one entry point, so the answer to "how do I start this?" is a command rather than a search.

.PHONY: first-run
first-run: env-check deps migrate smoke
    @echo "first run complete — you never left this terminal"

env-check:
    @test -f .env || cp .env.example .env
    @test -n "$$DATABASE_URL" || { echo "DATABASE_URL is empty; see .first-run/README.md"; exit 1; }

deps:
    npm ci --no-audit --no-fund

migrate:
    npm run migrate

smoke:
    npm run test:smoke

Notice what this does not do: it does not make anything faster. npm ci still takes as long as it takes, and the migration still has to run. What it removes is the decision layer — the moment where you wonder whether you should run migrations before or after seeding, and open a tab to check. Three or four of those decisions are normal in a new repo; ten of them is a tax you are paying for someone else's undocumented assumptions. The .first-run/README.md next to the Makefile is where the pinned versions, the required env vars, and the "yes, the smoke test fails the first time, run it twice" note live, so the repo answers before the browser does.

Where a hosted dev environment fits

One class of interruption is different from the rest: the toolchain itself. Installing a language runtime, a database, and a compiler on a fresh laptop is where the tab count explodes, and it is also the part with the least to do with your actual code. This is the point at which a hosted option is worth evaluating — I have been looking at MonkeyCode, which the operator describes as an open-source project offering free model access and a free server option, and the operator currently states that the free allowance is 10 million tokens. Verify the current numbers and terms on the project page before you plan around them, because allowances and server terms in this space change on a schedule nobody announces.

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

The reason it belongs in a tab-count article rather than a model-quality article is narrow and honest: two of the biggest interruption sources in a first run are "install and configure a runtime" and "go get an API key and add a payment method". A hosted server removes the first from your laptop, and free model access removes the second from your afternoon. Neither makes your code better, and neither is a reason to move a regulated workload onto someone else's machine.

Situation	Local toolchain	Hosted free server
Trying a repo for the first time	Fine, but high tab count	Strong fit: one fewer install
Data you cannot ship off-machine	Required	Do not use
Pinned, reproducible CI image	Required	Not a substitute
Offline or flaky-network work	Required	Poor fit
Prototype you will delete Friday	Overkill	Strong fit

What this method cannot tell you

The ledger is manual, so it measures what you remember to log, and a developer who forgets to log is exactly the developer having the worst time. It also says nothing about severity: a single twenty-minute detour to fix a broken certificate is worse than eight quick doc checks, and the count alone will not show you that. And if your first run is already a single make first-run that takes four minutes, stop reading — instrumenting that is pure overhead, and the honest answer is that someone already did this work for you.

So try it on the next repo you clone. Start the log, work for fifteen minutes without pretending, and look at the labels instead of the durations. If the biggest bucket is docs, your fix is a file in the repo; if it is auth or cloud, your fix might be a hosted environment; if it is install, your fix is a container or a server, not more patience. Either way, the tab count tells you which one to fix first, and that beats guessing.

Clock the Blocked Minutes, Not the Blocked Steps

Quinn Wang — Fri, 06 Nov 2026 17:02:40 +0000

The number that predicts whether a newcomer ships in week one is not install time; it is the minutes they spend blocked on another human. I have watched teams cut a twelve-step setup down to four and still lose the new developer, because every remaining step ended with the same sentence: ask someone for access. So before you tune another install script, answer a less comfortable question — do you actually know which of those first fifteen minutes were spent waiting on a machine, and which were spent waiting on a person?

That split matters more this year than last, because most of the noise around AI coding tools is about machine speed. Delete ten seconds of inference latency and nobody notices; delete a forty-minute permissions handoff and the entire first day changes shape. Which is why I now log onboarding friction as two separate clocks, and why the harness below is the only setup tool I keep re-using across projects instead of rewriting.

Two clocks, one TSV row

The first clock is machine wait: package installs, cold starts, image pulls, queue time, token generation. The second is human wait: the Slack message asking for a repository invite, the review of your service account request, the "hey, does anyone know how staging is seeded?" thread. Machine waits feel expensive because they are visible in a terminal, but they are short, repeatable, and usually fixable by caching; human waits are invisible, unbounded, and they are the part people actually remember about their first day.

So the artifact here is deliberately boring. It is a tiny shell library that wraps a command, records a start and end timestamp in milliseconds, and tags the block as human or machine. You run it around each phase of a first-run session, you get a TSV file, and you get ratios instead of anecdotes.

#!/usr/bin/env bash
# frictionlog.sh — two clocks for a first-run session: machine wait, human wait.
# needs: bash, python3 (for portable millisecond timestamps)
set -uo pipefail
LOG="${FRICTION_LOG:-friction.tsv}"
[ -f "$LOG" ] || printf 'phase\twaiting_on\tstart_ms\tend_ms\n' > "$LOG"

now_ms() { python3 -c 'import time; print(int(time.time() * 1000))'; }

block() {            # block <human|machine> <phase> -- <cmd...>
  local waiter="$1" phase="$2"; shift 2
  [ "${1:-}" = "--" ] && shift
  local start; start="$(now_ms)"
  if [ "$#" -gt 0 ]; then "$@" || true; fi
  printf '%s\t%s\t%s\t%s\n' "$phase" "$waiter" "$start" "$(now_ms)" >> "$LOG"
}

begin() { __waiter="$1"; __phase="$2"; __start="$(now_ms)"; }   # open a wait with no command
end()   { printf '%s\t%s\t%s\t%s\n' "$__phase" "$__waiter" "$__start" "$(now_ms)" >> "$LOG"; }

The begin/end pair exists because the worst waits have no command to wrap — the command is wait for a reply. You call begin human "secrets: ask platform team" when you send the message and end when access lands; one open human wait at a time is realistic enough for onboarding. A session then looks like this, and yes, it is meant to look unglamorous:

source ./frictionlog.sh
export FRICTION_LOG=run1.tsv

block machine "clone"         -- git clone --depth 1 git@github.com:acme/webapp.git
block machine "deps/install"  -- npm ci --no-audit --no-fund
begin human   "secrets: ask platform team"      # send the message
# ... coffee, hopefully ...
end
block machine "first build"   -- npm run build

Reading the file instead of arguing about it

A TSV that nobody reduces is just a diary, so here is the whole analysis step in awk — no dashboard, no vendor, no new dependency. It prints total seconds per phase and the share of that phase attributed to a human:

awk -F'\t' 'NR > 1 {
  d = ($4 - $3) / 1000
  total += d
  phase[$1] += d
  if ($2 == "human") human[$1] += d
}
END {
  for (p in phase)
    printf "%-30s %8.1fs   human-blocked %5.1f%%\n", p, phase[p], 100 * human[p] / phase[p]
  printf "%-30s %8.1fs\n", "TOTAL", total
}' run1.tsv

Here is illustrative output showing the shape of a result, not a benchmark of any tool or machine: secrets: ask platform team at roughly 2410s and 100.0% human-blocked, deps/install at 74.2s, first build at 38.9s, first test at 11.6s. Look at that ratio for a second — was your last onboarding fix aimed at the 74 seconds or at the 40 minutes? The reducer answers that in one line, and it is very hard to argue with a number you produced yourself in your own repository.

One discipline point I keep relearning: measure the second run, not the first. The first run is dominated by one-time state and flatters whatever you already optimized, while the second run shows what a returning developer pays every single day. Keep both files, compare them, and be honest about which number your team is actually paid to care about.

The one fix that mattered

In the session above, the fix was not caching and it was not a new devcontainer. The fix was replacing "ask a person for credentials" with "start in a throwaway environment that needs no credentials to build" — a disposable box plus a read-only fixture beats a faster package manager, because it converts a human wait into a machine wait you can queue and forget.

That is the honest place where MonkeyCode's free model access and free server option enter this workflow, and it is a narrower claim than a launch post would make. For the eval-shaped part of onboarding — read this file, write a test, explain this stack trace — a free sandbox with a free token allowance removes two waits that normally stall the first hour: waiting for budget approval, and waiting for someone to provision a machine. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The team advertises a free allowance on the order of ten million tokens and a free server option at the time of writing; that number is exactly the kind of thing that changes, so read the project page before you size a plan around it, and do not treat my prose or this post's date as the source of truth.

I would also keep the open-source claim practical rather than romantic. Being able to read the implementation is genuinely useful when you need to know what leaves your machine, but it is not a security review, and it is not an SLA.

Who should not use this

If your repository needs production credentials to build, a free disposable environment is not your answer and no amount of free tokens changes that — decouple the build first. If you handle regulated data, run latency-sensitive CI, or need uptime guarantees for a demo, a free tier is the wrong layer and a boring paid box is the correct choice. And if your measured human-blocked share is above forty percent, stop shopping for tools entirely, because your bottleneck is a permission model and every new AI feature is a distraction from it.

Which brings me back to this week's loudest argument about AI and jobs. The interesting question is not whether a model can do the work; it is which waits your team has quietly normalized for years and stopped seeing. Clock both kinds, publish the ratio where the team can read it, and let the numbers pick the fix — would you rather save ten seconds of inference, or one expensive afternoon of asking?

If you want to run the harness against something disposable, the free tier is a fair place to try it; bring the TSV back with you, not just the vibes.

Budget the Undo Before You Budget the Install

Quinn Wang — Thu, 05 Nov 2026 15:38:09 +0000

The first fifteen minutes of onboarding are not an installation problem at all; they are a reversibility problem wearing an installation costume. Everyone times the download, the package install, the first npm run dev, and almost nobody times the undo. But when a new contributor gets stuck at minute twelve, the question they are actually asking is not "how do I go forward?" — it is "how do I get back to the state I trusted?" If you cannot answer that question quickly, every subsequent step feels expensive, and the onboarding budget quietly evaporates.

So I stopped optimizing the install and started pricing the undo. For each step in a setup guide, I ask two questions in order: how many commands does it take to reverse, and have I ever run that reversal myself? Steps that pass both questions are cheap to try, and cheap-to-try steps get attempted instead of postponed. Steps that fail either question are the real blockers, even when they look like one-liners.

What follows is a rehearsal workflow, not a benchmark. I am not going to quote timings I did not measure on your machine, because your network, your shell profile, and your company proxy will rewrite all of them anyway. Instead, here is a small artifact you can run today and a decision table that tells you where your fifteen minutes actually go.

Snapshot first, install second

The core move is embarrassingly simple: before the first mutating command, record what the machine looked like. I mean the cheap, boring facts — the commit you are on, whether the tree is dirty, which binaries exist and where they live, and which environment variables the setup guide is about to touch. The template below is the shape of the script I would start any repo with; adapt the binary list to your stack and treat it as a proposal you have to test, not as a finished tool.

#!/usr/bin/env bash
# rehearse.sh — run this BEFORE the first onboarding step.
set -euo pipefail

STAMP="$(date -u +%Y%m%dT%H%M%SZ)"
LEDGER=".onboard/$STAMP"
mkdir -p "$LEDGER"

git rev-parse --is-inside-work-tree >/dev/null
git rev-parse HEAD        > "$LEDGER/head.txt"
git status --porcelain    > "$LEDGER/dirty.txt"

# Which interpreter/runner is this shell actually going to pick up?
for bin in node npm python3 uv docker make; do
  if command -v "$bin" >/dev/null 2>&1; then
    printf '%s\t%s\t%s\n' "$bin" "$(command -v "$bin")" "$("$bin" --version 2>&1 | head -n1)"
  else
    printf '%s\tMISSING\t-\n' "$bin"
  fi
done > "$LEDGER/bins.tsv"

# Only the variables a setup guide realistically mutates.
env | grep -E '^(PATH|NODE_OPTIONS|PYTHONPATH|HTTP_PROXY|HTTPS_PROXY|NO_PROXY)=' \
  > "$LEDGER/env.txt" || true

echo "ledger written to $LEDGER — now you may install things"

The point of command -v plus --version on the same line is that a version manager can lie to you. If node resolves to a shim in ~/.nvm/... on your laptop and to /usr/local/bin/node in CI, your setup guide has two audiences and only one of them is documented. Capturing the resolved path makes that divergence visible in the ledger instead of in a stack trace.

The undo has to be one command, and you have to run it

A snapshot is worthless if restoring it requires judgment. The second script is deliberately blunt: reset to the recorded commit, show what untracked files would be removed, then stop and let a human look at the list.

#!/usr/bin/env bash
# undo.sh — usage: ./undo.sh .onboard/<stamp>
set -euo pipefail
LEDGER="${1:?usage: undo.sh .onboard/<stamp>}"

git reset --hard "$(cat "$LEDGER/head.txt")"
git clean -nd   # -n is intentional: print the deletion list, delete nothing.
echo "review the list above, then rerun with 'git clean -fd' if it is what you expect"

That -n flag is the entire lesson. A destructive command you have rehearsed is a tool; the same command unrehearsed is a threat, and threats make people hesitate at exactly the moment they should be experimenting. Running the dry-run at minute three also proves the ledger exists and is readable, which is a much better failure than discovering at minute forty that the snapshot directory was gitignored.

Where the fifteen minutes actually go

Once you have the two scripts, classifying steps becomes mechanical. The table below is the one I scribble next to a setup guide, and it has changed my mind about which steps to automate first.

Step type	Undo cost	Rehearse it?	What it really costs
Edit files inside the repo	One `git reset --hard`	Automatic	Almost nothing
Create untracked files	One reviewed `git clean`	Yes, with `-n`	A minute of attention
Global package install	Manual, often unknown	Yes, on a disposable box	Trust, not time
Shell profile edits	Manual, easy to forget	Yes, diff the profile	Future-you's debugging hours
Pulling container images	`docker image rm`	Only if disk matters	Bandwidth

The pattern is uncomfortable: the steps that take the longest to undo are usually the fastest to run. npm install -g something finishes in seconds and can leave a shim in your PATH that outlives the project. That asymmetry — instant forward, murky backward — is what makes a confident engineer go quiet and start reading the setup guide twice.

The one fix that mattered

If I had to ship exactly one change to a setup guide, it would not be a faster install or a better error message. It would be a refusal to proceed: a make rehearse target that fails loudly when .onboard/ is missing, wired in front of the first mutating step.

.PHONY: rehearse undo
rehearse:
    @test -d .onboard && echo "ledger exists" || { echo "run ./rehearse.sh first"; exit 1; }
undo:
    @ls -1d .onboard/*/ | tail -n1 | xargs -r ./undo.sh

Why a gate instead of a paragraph of documentation? Because guidance is advisory and gates are structural. A contributor who skips the snapshot now gets a one-line error at the moment they can still cheaply comply, rather than a mystery at the end of the day. The gate also encodes the ordering knowledge that used to live in a senior engineer's head, which is the only durable way to transfer it.

Rehearse on a machine you are allowed to break

There is one obvious problem with a drill: you need somewhere to run it that is not your only laptop. This is the one place where a free server option genuinely earns its keep, because a disposable machine turns a scary rehearsal into a boring one — snapshot, install, undo, destroy, repeat. The same reasoning applies to the "what does this error mean" step at minute nine, which is where free model access helps: a contributor can ask a model for a hypothesis about a failing command -v result without waiting on a credit card, a seat license, or a procurement ticket. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The claim worth testing is narrow and testable — you get model access and a throwaway server at no cost, so use them for the undo drill, not for the happy path you already trust.

Keep the loop honest, though. A rehearsal proves your script runs and that the rollback returns you to a known commit; it does not prove your production config is safe, and it says nothing about steps that live outside the repository. Anything installed at the system level, anything written into a shell profile, and anything pulled into a shared Docker daemon is only partially covered by a git-based ledger, and you should write that limitation into the guide instead of hoping nobody notices.

Who should skip this

If your setup is genuinely one command against a container that already contains everything, the ledger is ceremony and you should drop it. The same is true on a monorepo so large that git status itself costs more than the install, where a tarball snapshot of the relevant subdirectory will serve you better. And if your team has no review culture for destructive commands, adding git reset --hard to a newcomer's toolbox without the -n habit is a net negative — teach the dry run first, or teach neither.

For everyone else, the experiment is cheap: spend the first three minutes of your next onboarding writing the ledger, spend one minute proving you can undo, and only then start installing. If the install still stalls, you will at least know that the person stuck can get back to safety without asking anyone — and isn't that the thing "developer experience" was supposed to mean in the first place?

Which Setup Step Actually Blocks Your First Run?

Quinn Wang — Tue, 27 Oct 2026 13:12:25 +0000

The step that decides whether a new contributor finishes setup is rarely the step your README spends the most words on. I learned this the boring way: I timed every step of a first run, wrote one JSON line per step, and only then saw which step was really eating the first fifteen minutes. The fix that mattered was not better prose for that step, it was a two-second version check that failed loudly before the expensive work started. What follows is the harness I use now, plus the two habits that stopped me from guessing when a run failed.

Aggregate setup time is a polite fiction

When someone tells you setup takes ten minutes, ask them what they actually measured. They usually measured their own last successful run, on a warm cache, on the machine they have been using for a year. That number is not a distribution, it is a memory, and it says nothing about the person whose first run ends in a stack trace about engines. Would you rather fix a step that is slow, or a step that quietly decides whether people finish at all?

Averages hide the shape of the problem, which is why I stopped reporting totals. A step that passes for eight people in two minutes and fails for two people in forty is not a two-minute step; it is a fork in the road with the sign pointing the wrong way. What I want to know is narrow and answerable: which step is both slow and unreliable, because that is the only one worth changing this week.

A preflight timer that fits in one file

The harness is deliberately dull: bash, one JSONL file per run, no dashboard, no SDK, no telemetry I have to defend in a review. Each step records its wall time and a pass or fail, and the script keeps going after a failure, because the failure you did not record is the one that ruins your afternoon.

#!/usr/bin/env bash
# preflight.sh — time each setup step, record pass/fail as JSONL.
# Unexecuted template: replace the step list with what your repo actually needs.
set -uo pipefail

OUT="${1:-/tmp/preflight-$(date -u +%Y%m%dT%H%M%SZ).jsonl}"
LOG="${OUT%.jsonl}.log"
: > "$OUT"; : > "$LOG"

now_ms() { python3 -c 'import time; print(int(time.time()*1000))'; }

run_step() {
  local id="$1"; shift
  local start end status
  start=$(now_ms)
  if "$@" >>"$LOG" 2>&1; then status=pass; else status=fail; fi
  end=$(now_ms)
  printf '{"step":"%s","ms":%d,"status":"%s"}\n' \
    "$id" "$((end - start))" "$status" >> "$OUT"
}

run_step versions bash -lc 'node --version && python3 --version'
run_step clone    bash -lc 'git clone --depth 1 "$REPO_URL" /tmp/pf-repo'
run_step install  bash -lc 'cd /tmp/pf-repo && npm ci --no-audit --no-fund'
run_step build    bash -lc 'cd /tmp/pf-repo && npm run build --if-present'
run_step smoke    bash -lc 'cd /tmp/pf-repo && npm test -- --bail'

Running it five times on cold caches gives you something to argue with, and jq turns the pile into one sorted answer per step. The blocking field is my own blunt weighting: median milliseconds multiplied by the failure rate plus a small floor, so a fast step that always fails still surfaces near the top.

jq -s '
  group_by(.step)
  | map({step: .[0].step,
         runs: length,
         fails: (map(select(.status=="fail")) | length),
         p50_ms: (map(.ms) | sort | .[length/2 | floor])})
  | map(. + {blocking: (.p50_ms * ((.fails / .runs) + 0.1) | floor)})
  | sort_by(-.blocking)
' /tmp/preflight-*.jsonl

I do not treat that score as science, because it is not; it is a way to end a meeting where everyone has a different favourite step. If the top row is your install step and it fails half the time, you have learned more in one minute than a week of reading complaints. Where is the signal in your own setup, honestly?

The one fix that mattered was a version check

On one repo, five of seven failed runs died in the same place, and it was not the build. People were installing dependencies against a Node major that the lockfile did not want, and the error only appeared after a three-minute download. We had written three careful paragraphs about the right version in the README, which is a lovely artefact that nobody reads at nine in the morning. The fix was a step zero that costs two seconds and names the culprit out loud.

# step 0 — fail in two seconds instead of twenty minutes
want=$(awk '/^nodejs/ {print $2}' .tool-versions)
have=$(node --version 2>/dev/null | sed 's/^v//')
if [ "$have" != "$want" ]; then
  echo "node $have != pinned $want" >&2
  exit 64
fi

Wrap that in run_step versions and it lands in the log with almost no milliseconds and a clean fail, which is exactly what you want from a gate. The lesson generalises beyond Node: move the constraint out of prose and into a check that runs before the expensive work. A fast loud failure is a gift, while a slow quiet one is a support ticket with extra steps.

Is it me, or is it the repo?

The hardest question in a first fifteen minutes is whether the breakage belongs to the repository or to the laptop. Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode's free model access and free server option are supplied by the operator and are the two pieces I reach for here; the terms, quotas and availability change over time, so check the current documentation before you plan around them. The server option is the useful one for triage: run the identical preflight.sh inside a known-good baseline, then diff two files instead of reading tea leaves.

# local run, then the same script against the baseline host
./preflight.sh /tmp/pf-local.jsonl
# run it again in the baseline environment you have access to

diff <(jq -r '"\(.step) \(.status)"' /tmp/pf-local.jsonl | sort) \
     <(jq -r '"\(.step) \(.status)"' /tmp/pf-baseline.jsonl | sort)

If the baseline passes everything and your laptop fails at install, stop rewriting the README and go look at your toolchain. The second piece is smaller: when a log is genuinely ambiguous, a model call can sort it into toolchain, network, permissions or unknown. I keep a keyword classifier as the default path and treat the model as an optional hook, so the script still works offline and on a locked-down runner.

classify() {
  local log="$1"
  grep -qiE 'EACCES|permission denied' "$log" && { echo permissions; return; }
  grep -qiE 'ECONNRESET|ETIMEDOUT|ENOTFOUND' "$log" && { echo network; return; }
  grep -qiE 'engine|unsupported|version' "$log" && { echo toolchain; return; }
  echo unknown   # swap for a model call; read endpoint and model id from current docs
}

What the numbers cannot tell you

One run is an anecdote, so I only trust a row after about five cold-cache runs, and I only trust a failure rate after roughly eight fresh machines across at least two operating systems. Wall clock on a shared CI box is noisy, and a baseline environment drifts away from your users' laptops over time, which makes it a reference point rather than proof. The score also cannot see humiliation: a step that takes four seconds and prints a wall of red text will lose you a contributor just as fast as a slow one.

So who should skip all of this? If your setup is already one command that passes on a clean container, you have solved the problem this article measures, and a devcontainer or Nix flake probably buys you more than a timing harness. If your dependencies are private or your network policy forbids an external baseline, you can still run the per-step timing locally, but the diff loses most of its value. Small teams of two or three contributors may also find that a pinned toolchain file alone gets them most of the way, with no JSONL at all.

If you want a baseline machine without provisioning one, the free server option is the cheapest way I have found to answer the is-it-me question, so run the script twice and compare two boring files. Then ask the only question that matters: which single step would you delete from a stranger's first fifteen minutes today?

The Slow Step Should Never Wait Its Turn

Quinn Wang — Mon, 26 Oct 2026 11:42:33 +0000

Fifteen minutes is a budget, not a vibe, and the fastest way to blow it is to schedule your slowest step last. I keep meeting the same first-run experience: three correct steps, written in the wrong order, defended by nobody. The steps are usually fine — the schedule is what leaks. So this is a post about ordering, with a harness you can point at your own setup tonight.

The loop I care about is deliberately small: prove the key works, get one reply from a model, get one answer from a server. Free model access and a free server option make that loop cheap enough to restart five times in an afternoon, which is exactly what a first-run budget needs. The setup I am pointing the harness at here uses MonkeyCode's free model access and free server option. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Here is the naive version, and yes, it is the version I wrote first. Three awaits in a column, each waiting for the one above it, even though almost nothing about them depends on each other.

// serial.mjs — the shape of most quickstarts, including my own first draft
const key    = await checkAuth();     // one request
const reply  = await askModel();      // one request, but only after auth resolves
const health = await bootServer();    // a cold start, but only after the model replies

Ask the obvious question out loud: does the server boot need the model reply before it can begin? No. Does auth need the boot at all? Also no. So why is the slowest stage sitting at the bottom of the file? Because it was written last, and nobody re-read the file with a stopwatch in hand.

That is the whole teardown, and the fix that mattered is one line of scheduling, not three new features.

// the fix: the slow, idempotent stage starts first and runs beside the fast one
const [bootResult, authResult] = await Promise.all([boot(), auth()]);
const modelResult = authResult.status === "ok"
  ? await model()
  : { stage: "model", status: "skipped", ms: 0, note: "auth failed first" };

Wall clock goes from boot + auth + model to roughly max(boot, auth) + model. If your cold boot is the long pole — and it usually is, because a free server option will happily cold-start for you — you have just removed almost all of it from the critical path. If the boot is not the long pole, the harness tells you so and you delete that branch. Either way you stop guessing.

Here is the full harness, no dependencies, Node 18 or newer. Every stage has a name, its own budget, and an abort handle, so a hang becomes a labelled timeout instead of a silent stare at the terminal.

#!/usr/bin/env node
// envelope.mjs — three first-run probes under one 15-minute envelope.
// Env: MODEL_BASE_URL, MODEL_API_KEY, MODEL_NAME, SERVER_HEALTH_URL
// Optional: BUDGET_AUTH_MS, BUDGET_MODEL_MS, BUDGET_BOOT_MS, ENVELOPE_BUDGET_MS, LEDGER_PATH
import { writeFileSync } from "node:fs";

const BUDGET_MS = Number(process.env.ENVELOPE_BUDGET_MS ?? 900_000);
const STAGE_BUDGET = {
  auth:  Number(process.env.BUDGET_AUTH_MS  ?? 60_000),
  model: Number(process.env.BUDGET_MODEL_MS ?? 120_000),
  boot:  Number(process.env.BUDGET_BOOT_MS  ?? 240_000),
};

const t0 = performance.now();
const elapsed = () => Math.round(performance.now() - t0);

// Never throws: a failed stage returns a failed row, so one error cannot hide the others.
async function stage(name, fn) {
  const budget = STAGE_BUDGET[name];
  const ctrl = new AbortController();
  const timer = setTimeout(() => ctrl.abort(), budget);
  const started = performance.now();
  try {
    await fn(ctrl.signal);
    return { stage: name, status: "ok", ms: Math.round(performance.now() - started), note: "" };
  } catch (err) {
    const status = err.name === "AbortError" ? "timeout" : "error";
    return { stage: name, status, ms: Math.round(performance.now() - started), note: String(err.message ?? err) };
  } finally {
    clearTimeout(timer);
  }
}

const auth = () => stage("auth", async (signal) => {
  const key = process.env.MODEL_API_KEY;
  if (!key) throw new Error("MODEL_API_KEY unset — this is an auth failure, not a model failure");
  const res = await fetch(`${process.env.MODEL_BASE_URL}/models`, {
    headers: { authorization: `Bearer ${key}` }, signal,
  });
  if (!res.ok) throw new Error(`auth endpoint said ${res.status}`);
});

const model = () => stage("model", async (signal) => {
  const res = await fetch(`${process.env.MODEL_BASE_URL}/chat/completions`, {
    method: "POST",
    headers: { "content-type": "application/json", authorization: `Bearer ${process.env.MODEL_API_KEY}` },
    body: JSON.stringify({
      model: process.env.MODEL_NAME,
      messages: [{ role: "user", content: "Reply with the single word: ready" }],
      max_tokens: 8,
    }),
    signal,
  });
  if (!res.ok) throw new Error(`model endpoint said ${res.status}`);
});

const boot = () => stage("boot", async (signal) => {
  const res = await fetch(process.env.SERVER_HEALTH_URL, { signal });
  if (!res.ok) throw new Error(`health endpoint said ${res.status}`);
});

// Schedule: the slow idempotent stage goes first, beside auth. Model waits for auth only.
const [bootRow, authRow] = await Promise.all([boot(), auth()]);
const modelRow = authRow.status === "ok"
  ? await model()
  : { stage: "model", status: "skipped", ms: 0, note: "auth failed first" };

const rows = [authRow, modelRow, bootRow];
const width = Math.max(...rows.map(r => r.stage.length));
for (const r of rows) {
  console.log(`${r.stage.padEnd(width)}  ${r.status.padEnd(7)}  ${String(r.ms).padStart(6)}ms  ${r.note}`);
}

const total = elapsed();
const bad = rows.filter(r => r.status !== "ok");
console.log(`\nverdict: ${bad.length ? "outside — " + bad.map(b => b.stage).join(", ") : "inside the envelope"}`);
console.log(`wall clock ${(total / 1000).toFixed(1)}s of a ${(BUDGET_MS / 1000).toFixed(0)}s budget`);

writeFileSync(process.env.LEDGER_PATH ?? "envelope-ledger.json",
  JSON.stringify({ runAt: new Date().toISOString(), totalMs: total, rows }, null, 2));

process.exitCode = bad.length === 0 && total <= BUDGET_MS ? 0 : 1;

Run it with the cheapest possible inputs, and do not commit the key:

MODEL_BASE_URL="$BASE" MODEL_NAME="$NAME" SERVER_HEALTH_URL="$HEALTH" \
  MODEL_API_KEY="$(cat ~/.secrets/trial-key)" node envelope.mjs

echo "exit code: $?"   # 1 means the envelope was missed, and the rows say where

The output format matters more than my numbers, which I am not going to pretend to know for your network. It looks roughly like this, with NN.Ns standing in for whatever your machine actually does:

auth    ok         NN.Ns
model   ok         NN.Ns
boot    ok         NN.Ns

verdict: inside the envelope
wall clock NN.Ns of a 900s budget

Now the part I actually care about: the ledger file behind the verdict. One run is an anecdote, but six runs on six mornings answer a much better question — is this stage slow, or was that one Tuesday slow? Compare totalMs across the file and read the row that keeps winning. Blaming the model for a cold boot is the most common misdiagnosis I have watched people make, and it costs them an afternoon of prompt tweaking that was never going to help.

Long pole in the ledger	First move
`boot` dominates	Start it first and let it warm while auth runs; consider a keep-warm ping before you sit down
`auth` dominates	Cache the exchange locally for the session; a 401 loop is not a model problem
`model` dominates	Shrink the probe to a two-token reply before you judge latency
Nothing dominates, but the total is over	The envelope is wrong, not the provider; write down what you actually need

A few honest limitations, because this harness is a stopwatch, not a diagnosis. Free tiers queue, rate-limit, and change underneath you, so a green run today is evidence about today only. The parallel branch assumes your server boot is idempotent and safe to cancel, which is not true for every service, and behind a corporate proxy you are mostly measuring the proxy. And the script proves which stage is slow without telling you why it is slow — you still have to read a log.

Who should skip this? Teams on committed infrastructure with stable latency and real monitoring, because the ledger is a downgrade from what they already have. Anyone whose first fifteen minutes are dominated by a compiler toolchain, since the harness will just confirm a truth you already resent. And anyone who wants to turn this into a leaderboard — it measures your network and your order of operations, not the quality of anybody's model.

If you want something free to break while you test the schedule, the free model access and free server option are a fair place to point the harness; check the current quotas in your own dashboard rather than trusting a number in a blog post, mine included. Then move one await and watch the wall clock change shape, because that is the whole trick.

Stopwatch the Cold Start, Not the Model

Quinn Wang — Tue, 20 Oct 2026 09:48:52 +0000

Stopwatch the Cold Start, Not the Model

The first conclusion I want to hand you is uncomfortable: in a brand-new AI-assisted workspace, the model is almost never your bottleneck. The cold start is, and it stays invisible because nobody writes timestamps down. Ask ten developers where their first fifteen minutes went and nine will blame the model, which is a polite way of saying they never measured. I now treat onboarding as a latency problem with a p99 budget, and the change that moved the number most was not a smarter model at all.

So let me show you the instrument first and the opinions second, because an argument about free tiers without a stopwatch is just vibes with a changelog attached. The script below is deliberately boring: it records a millisecond timestamp before and after each step you already run, then prints the deltas. Nothing in it is specific to any vendor, which is exactly why it survives the next time you switch tools.

#!/usr/bin/env bash
# scripts/cold-start.sh — timestamp every step of a fresh workspace bootstrap.
set -euo pipefail

LOG="${LOG:-cold-start.tsv}"
: > "$LOG"

now_ms() { python3 -c 'import time; print(int(time.time() * 1000))'; }
mark()   { printf '%s\t%s\n' "$(now_ms)" "$1" >> "$LOG"; }

mark "boot"

mark "install:start";  ./scripts/install-toolchain.sh;      mark "install:end"
mark "deps:start";     npm ci --no-audit --no-fund;          mark "deps:end"
mark "auth:start";     ./scripts/check-creds.sh;             mark "auth:end"
mark "model:start";    ./scripts/smoke-task.sh > /tmp/smoke.patch; mark "model:end"

mark "apply:start"
git apply --check /tmp/smoke.patch && git apply /tmp/smoke.patch
mark "apply:end"

The report is six lines of awk, and I keep it in the repo next to the script so the numbers are comparable across weeks. Reading a table beats remembering a feeling, especially when the feeling is "it seemed slow".

awk -F'\t' '
  NR==1 { start=$1; prev=$1; printf "%9s %9s  %s\n", "delta_ms", "total_ms", "step"; next }
  { printf "%9d %9d  %s\n", $1-prev, $1-start, $2; prev=$1 }
' cold-start.tsv

Now run it three times, with the container thrown away between runs, because a warm cache will happily lie to you. I use a throwaway image precisely so that "it works on my machine" cannot creep into the measurement.

for i in 1 2 3; do
  docker run --rm -v "$PWD:/w" -w /w node:22-slim ./scripts/cold-start.sh
  mv cold-start.tsv "cold-$i.tsv"
 done

The variance between those three runs matters more than the absolute number, and I learned that the hard way. If run one and run three differ by more than about thirty percent on the same step, you are not measuring your setup, you are measuring the network. That distinction changes what you fix, so please do not skip the repetition.

Here is how I bucket the deltas, and these thresholds are opinions you should tune rather than laws. The point of a table like this is to stop the argument before it starts, because "slow" is not actionable and "install took 412 seconds" is.

Bucket	Typical symptom	Act when	First move
install	toolchain download, version drift	over ~4 min	pin versions, cache the layer
deps	`npm ci` re-resolving a lockfile	over ~2 min	commit the lockfile, use `ci`
auth	silent 401 retries, wrong profile	any failure	fail loudly, never retry blind
model	first round trip, no output	over ~60 s	send a trivial prompt, not the real task
apply	patch rejected, whitespace noise	any failure	shrink the smoke task to one file

The one fix that mattered for me was not faster inference; it was turning the cold start into a single warm step that either succeeds or fails in under a minute. I put a warm target in the Makefile, and now every new machine, container, or teammate runs exactly one command before touching the real work.

warm:
    ./scripts/install-toolchain.sh --pinned
    npm ci --no-audit --no-fund
    ./scripts/smoke-task.sh > /dev/null   # cheap proof that creds and endpoint answer
    ./scripts/cold-start.sh --report      # keeps the number honest over time

Why does a smoke task beat a real task as the first move? Because a real task mixes three unknowns at once — your prompt, the endpoint, and the repository state — and you cannot debug three unknowns together. A tiny task that touches one file separates them, and it costs almost nothing when the environment is already broken. I have wasted entire afternoons on prompts that were fine while the credentials were quietly stale, and I would like you to skip that afternoon.

When the smoke patch never lands, the debugging order is fixed and short in my notes. First check that the endpoint answers a trivial request without touching the repo, then check that the repo is clean enough to accept a patch, then check the diff size. Ninety percent of the time the failure is in step one or two and the prompt was never the problem at all.

This is the workflow where MonkeyCode's free model access and free server option are genuinely relevant, and I want to be precise about what that means. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The operator describes the project as open source with a free tier that includes model access and a server option, and the free allowance has been quoted to me as ten million tokens; quotas move, so verify the current figure on the project's own page before you plan around it. What I actually used it for is unglamorous and that is the point: I ran the timed loop above against a hosted workspace so the install and dependency buckets were not my laptop's problem. Because the source is public, you can read what the server does with your prompt before you send anything you would not paste into a ticket.

Who should not use this approach? Anyone who needs a contractual SLA, anyone whose cold start is dominated by a proprietary build cache the free tier cannot see, and anyone working in a regulated environment where the answer to "where did the prompt go" must be a document rather than a repository. A free tier is a fine place to measure friction and a poor place to promise uptime, and confusing those two is how teams end up with a very confident incident report.

So before you benchmark another model, time your own first fifteen minutes and write the numbers into a file that other people can read. My guess is that your biggest bucket is not the one you have been blaming, and you will only find out if something is counting. If you want a place to run the stopwatch without provisioning anything, the free workspace is a reasonable first target — just bring the timer with you.

The First Fifteen Minutes: One Preflight, One Fix

Quinn Wang — Mon, 19 Oct 2026 08:30:32 +0000

The thing that decides whether a new AI coding setup survives contact with a real repo is almost never the model — it is whether the first fifteen minutes end in something you can verify. I have been tearing down first-run experiences for a while now, and the pattern keeps repeating: people lose the quarter hour to a handful of small uncertainties, then blame the tool for being slow. So instead of reviewing features, let me show you the stopwatch I use, the friction log it produces, and the single fix that actually moved the needle for me.

The premise is boring on purpose. You cannot improve a setup you have not timed, and most of us never time anything; we just remember that it "felt slow" and carry that feeling into the next tool we try. A clock turns a vague feeling into a row in a file, and a row in a file turns into an argument you can act on. Isn't that a better basis for a decision than vibes?

Clock every step before you judge anything

I start by sourcing a tiny timing helper into the shell session, so every step I take gets a timestamp without me thinking about it. The script is deliberately dumb: it records elapsed seconds and a note, and it never tries to be clever about what a "step" is. You decide that, and you decide it before you start, which is the whole point.

#!/usr/bin/env bash
# clock.sh — source me, then call mark after every step
set -uo pipefail

LOG="${CLOCK_LOG:-friction.tsv}"
[ -f "$LOG" ] || printf 'step\tseconds\tnote\n' > "$LOG"
CLOCK_T0=$(date +%s)

mark() {
  local now; now=$(date +%s)
  printf '%s\t%s\t%s\n' "$1" "$((now - CLOCK_T0))" "${2:-}" >> "$LOG"
  printf '[%3ss] %s %s\n' "$((now - CLOCK_T0))" "$1" "${2:-}"
}

Then a first run looks like this, with the setup command replaced by whatever the project's README currently tells you to run — I am not going to paste an install line I cannot verify against today's docs.

source ./clock.sh
mark "account"     "signed in, key copied to clipboard"
mark "install"     "ran the documented setup command"
mark "server"      "free server option selected"
mark "first-prompt" "opened editor, sent a trivial question"
mark "first-diff"  "got a change I could actually apply"
column -t -s $'\t' "$LOG"

The last row is the only one I really care about, because everything before it is preparation and everything after it is work. If first-diff lands at two minutes or at nineteen, that number describes the tool's design more honestly than any feature list. What would your own log say about the last three tools you tried?

Here is the shape of my log from a recent run through an AI coding setup that offers free model access plus a free server option. These rows are illustrative of the format, not measurements from a controlled benchmark — rerun the clock yourself before you quote anything.

step          seconds  note
account       42       key copied, no docs needed
install       96       two commands, one PATH fix
server        18       free server option, no card prompt
config        151      env vars invented by me, not documented
first-prompt  63       worked, but model choice unclear
first-diff    644      mostly me re-reading setup notes

Look at the two biggest numbers and notice that neither of them is the model. Config and re-reading together account for more than half the wall clock, and both are pure friction: nothing was learned, nothing was produced, and no token was spent. That is the leak I keep finding in onboarding budgets, and it is cheap to plug.

The one fix that mattered

The fix was not a tutorial and it was not better documentation — it was a preflight script that refuses to let me start until the boring questions are already answered. Instead of discovering an unreachable endpoint inside my editor, I discover it in a two-second terminal command that prints a clear OK or FAIL per check. Failure moves to the place where failure is cheap.

I wrote the version below against a generic OpenAI-compatible shape, so treat the paths as placeholders to adjust against the project's current API reference rather than gospel. The structure is what matters: check reachability, check that your credential is accepted, and exit non-zero so a wrapper can stop you.

#!/usr/bin/env bash
# preflight.sh — proposed, adapt paths to the current API docs
set -euo pipefail

: "${MC_BASE_URL:?export MC_BASE_URL first}"
: "${MC_API_KEY:?use a shell env var, never a committed file}"

fail=0

code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 5 "$MC_BASE_URL/health" || true)
if [ "$code" = "200" ]; then echo "OK   health"; else echo "FAIL health: $code"; fail=1; fi

if curl -s --max-time 5 -H "Authorization: Bearer $MC_API_KEY" \
     "$MC_BASE_URL/v1/models" | jq -e '.data | length > 0' >/dev/null 2>&1; then
  echo "OK   credential accepted"
else
  echo "FAIL credential or endpoint moved"; fail=1
fi

exit "$fail"

Wire it into a make target so the gate is the path of least resistance, and so skipping it requires a deliberate keypress rather than an oversight. A gate you have to think about bypassing is a gate that holds.

preflight:
    @./preflight.sh || (echo "stop here: fix the failing line before opening the editor"; exit 1)

first-run: preflight
    @echo "you have 15 minutes; make them count"

Does this feel like overhead? It is eleven lines and roughly two seconds, and in exchange the expensive part of your session starts with a known-good connection instead of an unknown one. That trade is the whole article.

Where the free server option earns its place

I run the preflight against the free server option because a remote endpoint fails in ways that are visible from curl, while a local misconfiguration tends to fail inside an editor where the error message is a shrug. Free model access is genuinely useful during the first fifteen minutes, when you are sending small, disposable prompts to learn the interface rather than doing serious work. The caveat is that free capacity is exactly the kind of thing that changes without notice, so check the project's current page for today's limits instead of trusting a number someone quoted last month. Want the details straight from the source? The MonkeyCode project page is the only place worth trusting for current availability.

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

Your situation	Preflight against free server	Preflight locally	Skip preflight entirely
Evaluating an unfamiliar tool	Yes — fastest signal	No	No
Repo contains secrets or customer data	No	Yes	No
Reproducible CI check	Unreliable; no SLA	Yes	No
One-off throwaway script	Yes	Overkill	Acceptable
Latency-sensitive workflow	Measure first, then decide	Yes	No

Limits, and who should walk away

This workflow measures setup friction, and it says nothing useful about code quality, model reasoning, or cost per task — do not let a clean preflight talk you into trusting output you have not reviewed. Free tiers change, endpoints move, and a health check that passed at nine in the morning proves nothing at five in the afternoon, so the script is a gate, not a guarantee. If you handle regulated data, need an SLA, or cannot tolerate a third-party endpoint seeing your prompts, this whole approach is the wrong shape for you and a local-only setup is the honest answer.

Who should try it? Anyone who has ever said "this tool feels slow" without a number behind the claim, and anyone onboarding a teammate who will ask the same five questions next Monday. Run the clock once, keep the log in the repo next to the Makefile, and let the friction show itself. Fifteen minutes of measurement buys you a much better argument than fifteen minutes of opinion — and honestly, what else were you going to do with that quarter hour?

Teardown: The First Fifteen Minutes, Minus One Step

Quinn Wang — Sun, 18 Oct 2026 07:11:02 +0000

The fix that mattered most in my last onboarding teardown was not a better doc, a faster model, or a smarter plugin — it was deleting a step. I keep relearning this, and I keep being surprised by how much of the first fifteen minutes evaporates once you remove the one gate that everyone hits before they can even ask a question. So this is not a review of a tool; it is the ledger I use to find that gate, and one concrete result from running it against a free-tier setup.

Half the posts I scrolled past this week were some version of "AI fatigue", and honestly, a lot of that fatigue is setup fatigue wearing a costume. You read a launch post, you carve out twenty minutes, and then you spend eighteen of them picking a provider, finding a key, and discovering your laptop's GPU situation. Isn't that the real tax? Not the inference bill — the pre-inference ceremony.

Instrument before you optimize

You cannot shorten a wait you never measured, so the first artifact is a ledger, not a benchmark. I stamp each step into a CSV as it happens, then read it back once the first accepted edit lands; the numbers are wall clock, not impressions. Run it in the same shell session where you are actually doing the setup, so the timestamps reflect the real pauses.

#!/usr/bin/env bash
# first15.sh — stamp each onboarding step, then read the ledger back.
set -euo pipefail
LEDGER="${LEDGER:-first15.csv}"

stamp() {
  printf '%s,%s,%s\n' "$(date -u +%FT%TZ)" "$1" "${2:-}" >>"$LEDGER"
}

case "${1:-}" in
  start)  : >"$LEDGER"; stamp "clock-start" "${2:-}" ;;
  mark)   stamp "$2" "${3:-}" ;;
  report) python3 - "$LEDGER" <<'PY'
import csv, sys
from datetime import datetime

rows = list(csv.DictReader(open(sys.argv[1])))
if len(rows) < 2:
    sys.exit("not enough stamps to report")

parse = lambda ts: datetime.fromisoformat(ts.replace("Z", "+00:00"))
start = parse(rows[0]["ts"])
prev = start
print(f'{"step":<26}{"delta_s":>9}{"total_s":>9}  note')
for r in rows[1:]:
    t = parse(r["ts"])
    print(f'{r["step"]:<26}{(t-prev).total_seconds():>9.1f}'
          f'{(t-start).total_seconds():>9.1f}  {r["note"]}')
    prev = t
print(f'\ntotal: {(prev-start).total_seconds():.1f}s across {len(rows)-1} transitions')
PY
    ;;
  *) echo "usage: $0 start|mark|report [step] [note]" >&2; exit 2 ;;
esac

A typical session looks like ./first15.sh start "free-tier trial", then a mark for each gate you pass: account, key, endpoint, first reply, first file changed. Here is the shape of the output I care about — schematic, not a measurement of your machine or anyone else's:

step                        delta_s  total_s  note
account-and-key                63.0     63.0  email verify included
endpoint-reachable              4.0     67.0  smoke request
first-reply                    19.0     86.0  one-line prompt
first-accepted-edit           241.0    327.0  wrong file, then right file

Look at where the minutes actually go. In my runs the account-and-key step is roughly a minute and the first reply is seconds, but the stretch between "it answered" and "it changed something I kept" is where four out of five minutes disappear — and that gap is a comprehension problem, not a latency problem.

The gate nobody logs

When I wrote the ledger down honestly, the biggest stall had a boring name: choosing what to ask first. People install the thing, get a cheerful reply, then freeze, because the blank prompt is a decision and decisions are slow. The fix was not a prompt library and it was definitely not a longer quickstart; it was constraining step four to a single named file with a single named change, so the first request has an obvious right answer.

The second gate was infrastructure — not speed, just existence. Every "do you have a GPU, a card, a quota?" question adds a branch to the first fifteen minutes, and branches are where people leave. That is where a free server option does real work in a teardown like this: it removes a branch rather than shortening one. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The project is open source and, per its own materials at the time of writing, advertises free model access plus a free server option and a free token allowance on the order of ten million tokens; I would re-check that allowance on the project page before you plan around it, because published quotas move.

What I will not tell you is how fast it is, which models sit behind it, or how it compares on a benchmark — I did not measure any of that here, and a number I invented would be worse than no number. What I can say is what the ledger says: with the hardware question removed, my schematic run loses its second-longest stall, and the remaining time goes into the only step that teaches you anything.

A smoke test before you commit twenty minutes

The cheapest habit I have is a thirty-second reachability check before installing anything. Substitute the base URL and model id from your own account page — the path below is illustrative, and I have not run this exact request against the current API, so treat it as a template rather than documentation:

BASE_URL="https://<endpoint-from-your-dashboard>"
curl -sS -o /tmp/first.json \
  -w 'http=%{http_code} total=%{time_total}s\n' \
  -H "Authorization: Bearer $MONKEYCODE_TOKEN" \
  -H 'Content-Type: application/json' \
  --data '{"model":"<model-id>","messages":[{"role":"user","content":"reply with the word ready"}]}' \
  "$BASE_URL/v1/chat/completions"

If that prints a 200 and the word ready, the next fifteen minutes belong to your problem instead of your plumbing. If it prints a 401, you found the gate in one command instead of nine, and that is a win even though nothing worked. Keep /tmp/first.json around; when something breaks later, the diff between a working reply and a broken one is usually one header.

Who should walk away

Your situation	Verdict
Solo exploration, throwaway repo, no card	Worth the fifteen minutes
Regulated code, audit trail, SSO requirements	Check the terms first, probably not
You need pinned model versions for reproducibility	Not without a fallback path
Your team already has an approved provider	Adding a second one is a cost, not a feature
You want a benchmark winner	This article will not give you one

That last row matters. Free access and a free server are availability claims, not quality claims, and a teardown that measures onboarding friction says nothing about whether the output is any good on your codebase. If your code cannot leave your network, no amount of free is free.

If you keep any kind of onboarding ledger for your own projects, run it once on the tool you already pay for before you add another one. You might find that the step you were about to document is the step you should have deleted — and isn't that a cheaper fix than writing the doc?

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.