DEV Community: Quinn Wang

Don't Let the Agent Guess Your Workspace

Quinn Wang — Sat, 05 Sep 2026 20:09:33 +0000

The first agent command is where a free coding session usually dies, and it rarely dies from a weak model. It dies because the agent invents a working directory, a start script, and a port, then treats that fiction as fact. I learned to treat that first turn as a permissions problem rather than another exercise in clever prompting. If the workspace has not been proven on disk, why would I let any tool start writing files?

Think of the agent like a courier who never checks the street address printed on the box. You asked for a small route change, and it sprints toward a house that only looks similar from the road. The damage is not theatrical, just a wrong folder, a wrong lockfile, and a server process you never started. Have you watched a coding tool fix a bug by editing a path that exists only inside its context window?

I keep seeing the same shape in developer tools that now call themselves agentic without changing the consent model. The product window opens, the chat box looks harmless, and the model asks almost nothing about your actual machine. Then it proposes npm run dev, invents a src/app/page.tsx file, and talks as if port 3000 already belongs to you. That is not architecture guidance in any serious sense; it is a confident shrug wearing a terminal font.

The teardown I care about is not the onboarding carousel or the animated first-run checklist in the sidebar. It is the short window after you paste a real task and the agent reaches for a shell command. Silent defaults beat your actual repository in that window, and they do it with a tone that sounds helpful. The one fix that mattered for me was boring on purpose: prove the workspace locally, then allow the first command.

Here is the reproducible gate I run from the repository root before any agent is allowed to touch the tree. It refuses to print secret values, and it refuses to start a long-running product process on your behalf. It only writes facts that a later prompt is allowed to cite, and it exits nonzero when the tree is unproven. The snippets below are a lab workflow, not a production benchmark I ran against a public dataset.

#!/usr/bin/env bash
# workspace-gate.sh — lab workflow: fail closed, write facts, never dump env values
set -euo pipefail

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

cd "$ROOT"
FACT_FILE="${ROOT}/.workspace-facts.json"
PORT="${PROOF_PORT:-3000}"

pkg="absent"
[[ -f package.json ]] && pkg="present"

lock="absent"
if [[ -f package-lock.json || -f pnpm-lock.yaml || -f yarn.lock ]]; then
  lock="present"
fi

env_example="absent"
[[ -f .env.example ]] && env_example="present"

env_file="absent"
if [[ -f .env || -f .env.local ]]; then
  env_file="present"
fi

if command -v lsof >/dev/null 2>&1; then
  if lsof -iTCP:"$PORT" -sTCP:LISTEN >/dev/null 2>&1; then
    port_state="listening"
  else
    port_state="closed"
  fi
else
  port_state="unknown"
fi

branch="$(git rev-parse --abbrev-ref HEAD)"
dirty="$(git status --porcelain | wc -l | tr -d ' ')"

export GATE_ROOT="$ROOT"
export GATE_FACT_FILE="$FACT_FILE"
export GATE_PORT="$PORT"
export GATE_PKG="$pkg"
export GATE_LOCK="$lock"
export GATE_ENV_EXAMPLE="$env_example"
export GATE_ENV_FILE="$env_file"
export GATE_PORT_STATE="$port_state"
export GATE_BRANCH="$branch"
export GATE_DIRTY="$dirty"

python3 - <<'PY'
import json, os, datetime
facts = {
  "generated_at": datetime.datetime.utcnow().isoformat() + "Z",
  "root": os.environ["GATE_ROOT"],
  "branch": os.environ["GATE_BRANCH"],
  "dirty_files": int(os.environ["GATE_DIRTY"]),
  "package_json": os.environ["GATE_PKG"],
  "lockfile": os.environ["GATE_LOCK"],
  "env_example": os.environ["GATE_ENV_EXAMPLE"],
  "env_file_present": os.environ["GATE_ENV_FILE"],
  "port": int(os.environ["GATE_PORT"]),
  "port_state": os.environ["GATE_PORT_STATE"],
  "allowed_commands": ["git status", "ls", "sed -n '1,40p' package.json"]
}
path = os.environ["GATE_FACT_FILE"]
with open(path, "w", encoding="utf-8") as fh:
    json.dump(facts, fh, indent=2)
    fh.write("\n")
print("GATE_OK wrote", path)
PY

I run those two commands in order, and I refuse to continue when the exit code is anything other than zero. That sounds fussy until you remember how often an agent changes directory into a folder it just hallucinated. chmod +x is not ceremony here; it is the line that makes the gate a real command instead of a gist you never run.

chmod +x workspace-gate.sh
./workspace-gate.sh || exit $?
echo ".workspace-facts.json" >> .gitignore
cat .workspace-facts.json

The JSON file is the only map I paste into the first prompt, because everything else is an invitation to guess. Notice what is missing on purpose: tokens, API keys, file bodies, and any claim that a server is ready. If package_json is absent, why would I let the agent invent a framework tree that your git history cannot explain? If the recorded port is closed, why would I let it debug a five hundred from a process that is not listening?

The prompt I actually send stays short, because the gate already did the only honest work in the session. I tell the model it may not create paths outside root, and it may not assume a framework from vibes alone. I also tell it not to start a server unless I say so, which is slower than letting it rip by exactly one command. That extra command is the whole point of the teardown, not a tax I pay to feel disciplined.

You are working in a proven workspace. Use only .workspace-facts.json.
Do not invent directories, scripts, ports, or frameworks.
If package_json is absent, ask before scaffolding.
If port_state is not listening, do not diagnose HTTP errors.
First reply with: (1) the root you will use, (2) the first command,
(3) what you still do not know. Wait for yes before running anything.

When developers talk about agentic coding this week, they often mean tools that assume the architecture on your behalf. That trend is useful as a warning, because a brownfield repo can put on a greenfield costume in a single turn. I would rather an agent admit ignorance than ship a plausible src directory that never belonged to the project. Cheap generation without a gate is how technical debt arrives before you have even made the first commit.

I treat the free server as a disposable place to confirm an agent can follow the facts file, not as production proof. I do not need a leaderboard for that check; I need a second pair of eyes I can throw away later. Does that mean I trust a remote box with a live env file sitting beside the application code? The gate records env_file_present as a boolean and then stops, which is the entire security story I want in the facts file.

A tiny Node check sits beside the shell script in a JavaScript repo, because lsof is not the only way a port can lie. This lab check tries to bind the port, and a failed bind means something is already listening on that socket. If the bind succeeds, I close the socket immediately and record closed, which is a proof, not a benchmark.

// prove-port.mjs — labeled lab check, not a benchmark
import net from "node:net";

const port = Number(process.env.PROOF_PORT || 3000);
const server = net.createServer();
server.unref();

server.once("error", (err) => {
  if (err && err.code === "EADDRINUSE") {
    console.log(JSON.stringify({ port, port_state: "listening" }));
    process.exit(0);
  }
  console.error("GATE_FAIL: port proof error", err);
  process.exit(2);
});

server.listen(port, "127.0.0.1", () => {
  server.close(() => {
    console.log(JSON.stringify({ port, port_state: "closed" }));
  });
});

node prove-port.mjs
PROOF_PORT=5173 node prove-port.mjs

Put the two outputs next to each other and you get a decision that does not need a meeting or a dashboard. If the facts file says closed and the agent still writes a repro from localhost three thousand, the agent failed the gate. If dirty_files is high and the agent wants to scaffold, I make it stop rather than launder a surprise tree into a dirty workdir. If a lockfile is present and it suggests a different package manager, that suggestion is another invented blank wearing confidence.

Limitations are not a footnote I tack on for tone; they are the reason I still read the first agent reply with suspicion. This gate cannot see containers you did not expose, and it cannot tell a healthy listener from a zombie process on the same port. It will not stop a model from lying in prose after you paste the facts, because a JSON file is not a character witness. If you work in a monorepo with five apps, split facts per package, because one PROOF_PORT is a blunt instrument.

Who should not use this workflow if they want to stay honest about the failure mode I am describing here? Skip it if you need a fully autonomous loop with no human yes sitting between the model and the shell. Skip it if you cannot run local scripts on the machine that holds the repo, because the gate is useless as a story. Skip it if you want an agent to invent a greenfield app in an empty folder, because this gate is for brownfield honesty.

A free tier also will not replace code review, mutation testing, or a staging server that actually resembles production traffic. I still want models that can write tests, review diffs, and wander through a disposable server after the workspace has been proven. I just refuse to start that loop on a map the model drew from a training prior instead of from git. The one fix that mattered was not a better system prompt; it was a fail-closed file that made the first command earn its place.

If you try the script on a throwaway repository, keep the facts file out of version control unless you sanitize the root path. Then watch the first agent turn with the same attention you would give a pull request from a stranger. Did it ask a question about the facts you measured, or did it start guessing the neighborhood again?

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

MonkeyCode provides free models that can run this workflow.

Refuse the Session Until the Repo Answers Back

Quinn Wang — Fri, 04 Sep 2026 17:53:56 +0000

The first fifteen minutes of a free AI coding session usually fail on invented context, not models. Your agent does not crash; it politely guesses the package manager, the test command, and the bind address. Those guesses feel helpful until you spend the rest of the hour undoing a repository that never existed. I now refuse to start a session until a tiny contract file and a local gate both pass.

I still think that warning sounds dramatic for a missing lockfile and a guessed runner. Think of a taxi that leaves before you confirm the street, then bills you for scenery. Free models make the ride cheap, and a free server makes the wrong street look like real progress. The developer-experience wound is not latency; it is confident motion inside a directory nobody verified.

I keep watching the same opening act whenever a fresh coding agent meets a brownfield folder. The tool greets me, scans a handful of files, and starts scaffolding as if this repo were a tutorial. npm appears where I already standardized on pnpm, and Jest appears where I run node:test today. Fifteen minutes later I own two lockfiles, a health check on the wrong port, and a mystery commit.

The one fix that actually mattered was small enough to feel almost insulting at first. I stopped asking the agent to be careful and started requiring a committed session contract plus a gate. If the contract is missing, or the working directory is not the named git root, nothing starts. The agent can still write code after that checkpoint; it just cannot invent the room around it.

Here is the contract I drop at the repo root under the name session.contract.json for every serious branch. Treat the file as a proposed artifact you can copy, not as a benchmark from some private bake-off. It is deliberately boring, because boredom is harder for an agent to “improve.”

{
  "name": "billing-api",
  "git_root_basename": "billing-api",
  "package_manager": "pnpm",
  "lockfile": "pnpm-lock.yaml",
  "test_command": "pnpm test -- --run",
  "typecheck_command": "pnpm exec tsc --noEmit",
  "server": {
    "bind": "127.0.0.1",
    "port": 8787,
    "health_path": "/healthz",
    "start_command": "pnpm dev"
  },
  "forbidden_inferences": [
    "create docker-compose.yml",
    "add a second package manager",
    "bind 0.0.0.0",
    "rewrite the test runner"
  ]
}

Why JSON instead of a chatty README that an agent can keep writing like a sequel? A README is a novel, and most agents love novels they are invited to continue without asking. A contract is a door lock you can hash, diff, and fail closed before the first generated patch. I still write human notes elsewhere; I just refuse to let prose be the only source of truth.

The gate lives in scripts/ai-session-gate.sh and I run it locally before any prompt leaves the editor. Consider the script proposed and copy-pasteable, because I am not selling a measured pass rate tonight. It should fail closed on a missing git root, a missing contract, or a folder whose basename does not match.

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

CONTRACT="${1:-session.contract.json}"
ROOT="$(git rev-parse --show-toplevel 2>/dev/null || true)"

if [[ -z "${ROOT}" ]]; then
  echo "gate: not inside a git work tree" >&2
  exit 10
fi

cd "${ROOT}"

if [[ ! -f "${CONTRACT}" ]]; then
  echo "gate: missing ${CONTRACT}; refusing to start the session" >&2
  exit 11
fi

command -v python3 >/dev/null || { echo "gate: python3 required" >&2; exit 12; }

python3 - "${CONTRACT}" <<'PY'
import json, sys, pathlib
path = sys.argv[1]
data = json.loads(pathlib.Path(path).read_text())
root = pathlib.Path.cwd()
basename = data["git_root_basename"]
if root.name != basename:
    print(f"gate: cwd basename {root.name!r} != {basename!r}", file=sys.stderr)
    sys.exit(13)
lockfile = data["lockfile"]
if not (root / lockfile).is_file():
    print(f"gate: lockfile {lockfile} is missing", file=sys.stderr)
    sys.exit(14)
pm = data["package_manager"]
server = data["server"]
print(f"gate: ok root={root} pm={pm} lockfile={lockfile}")
print(f"gate: test={data['test_command']}")
print(f"gate: server={server['bind']}:{server['port']}{server['health_path']}")
PY

echo "gate: session may start; paste the contract into the first message"

Make it executable once, then run it from anywhere inside the work tree and let it cd for you. A healthy pass looks almost boring, and that boredom is the entire point of the ritual. A useful failure names the basename mismatch and refuses to flatter you with a partial green check.

chmod +x scripts/ai-session-gate.sh
./scripts/ai-session-gate.sh

gate: ok root=/Users/you/src/billing-api pm=pnpm lockfile=pnpm-lock.yaml
gate: test=pnpm test -- --run
gate: server=127.0.0.1:8787/healthz
gate: session may start; paste the contract into the first message

gate: cwd basename 'billing-api-copy' != 'billing-api'

Has a copied folder with a hyphenated suffix ever wasted your evening while the agent kept coding happily? The first prompt after a green gate is not a feature request; it is a short, rude recitation. I paste the JSON and require the agent to echo bind address, lockfile, and test command before edits. If it cannot quote those three facts, I stop, because a junior would not get a looser bar.

Would you merge a pull request from someone who could not name the test runner in standup? Then why let a free model do that with more confidence, nicer prose, and much less shame? When a free server joins the story, I add a second check that never talks to the model at all. The process that claims to be my app must answer on the contracted loopback port, not in chat.

#!/usr/bin/env bash
set -euo pipefail
BIND="${1:-127.0.0.1}"
PORT="${2:-8787}"
PATH_HEALTH="${3:-/healthz}"

if curl -fsS --max-time 2 "http://${BIND}:${PORT}${PATH_HEALTH}" >/dev/null; then
  echo "health: ok ${BIND}:${PORT}${PATH_HEALTH}"
  exit 0
fi

echo "health: no response from ${BIND}:${PORT}${PATH_HEALTH}" >&2
exit 20

This is where MonkeyCode actually participates in the method rather than sitting in a slogan. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I treat it as one place with free model access and a free server option, which makes bad binds obvious. Strip every product name from this article and the gate still earns its keep on a laptop.

Tear the first fifteen minutes down as a timeline and the failure modes stop looking mysterious. Minute one is open or clone, which is exactly when the basename check should fire and halt you. Minutes two through five are dependency reality, so the lockfile belongs in the contract, not in a vibe. Minutes six through fifteen are the helpful Docker file, the second framework, and the server that only exists in transcript.

The contract attacks minute one, and the health curl attacks the fake demo at minute fifteen. Everything between those checks is just an agent filling silence with architecture you did not order. I think of a kitchen ticket that does not inspire the cook so much as prevent last night's special. Free inference is a talented line cook with no ticket printer, and your job is hanging the ticket.

Should you wire the gate into an agent loop on day one, before it is boring on your laptop? I would not; I would keep a proposed npm script so the ritual lives in muscle memory first. After that, the human ritual is two commands you can type when you are only half awake.

{
  "scripts": {
    "ai:gate": "bash scripts/ai-session-gate.sh",
    "ai:health": "bash scripts/ai-health.sh 127.0.0.1 8787 /healthz"
  }
}

pnpm ai:gate
# only then start the agent, and only then paste session.contract.json
pnpm ai:health
git diff --exit-code -- session.contract.json

That last command is the quiet one people skip, and skipping it is how the ticket gets reprinted. If git diff --exit-code -- session.contract.json exits nonzero, the session is no longer bound by the rules you hung. Pause and ask why the cook rewrote the order before you taste whatever landed on the plate. The agent can still be useful after that pause; it just lost the right to keep moving on inertia.

Limitations sit in the open because this pattern is a seatbelt, not a substitute for a brain. The contract cannot see secrets an agent later pastes into a helpful log you forgot to read. The health check cannot prove the handler is yours if another process already bound the same port. JSON will not stop a rewrite of the contract unless you commit the file and watch git diff closely.

I am not claiming latency numbers, pass rates, or model names, because this piece is not a bake-off. If your work is air-gapped, safety-critical, or stuck inside a change window, skip remote free servers entirely. Who should skip the whole ritual, not just the remote box, without feeling guilty about the shortcut? People pairing on a twenty-minute kata, or a single file with no lockfile and no server, can skip it.

If you lack a git root you trust, the gate will nag, and you should listen instead of weakening it. The wider conversation keeps celebrating agents that plan, tool-call, and just handle the missing details for you. Handling the missing details is exactly how my accidental Jest suite got born on a pnpm repository. I would rather an agent pause like a senior who asks which package manager is actually real here.

Is that slower than a magical first message that scaffolds three directories before you finish coffee? Yes, by about thirty seconds of JSON and a shell script that exits nonzero without apologizing. Is it slower than rebuilding a tree the agent invented before lunch while sounding perfectly sure of itself? Not even close, which is why I now treat a green gate as the real start of the session.

If you try this, keep the artifact small enough to paste into a pull request description without ceremony. A contract, a gate, a health curl, and a first prompt that quotes them are the whole DX patch. The models can stay free, the server can stay free, and tomorrow you can still discard the session without guilt. What you should not discard is the habit of making the repo answer back before anyone starts coding.

Steal the three files either way, even if you never touch the product I used for the server. If you want a free model plus a free server to try the gate against, MonkeyCode is one option. I will not pretend the JSON cares which vendor answered, so long as port 8787 tells the truth.

Prove the Headers Before You Accept the Cache Patch

Quinn Wang — Thu, 03 Sep 2026 15:27:31 +0000

The first fifteen minutes of an AI cache fix should replay headers, not invent another middleware file. I do not want a confident story about stale SPAs; I want a disposable host that repeats one request twice. If the second response still looks haunted, the patch is fiction, and I should stop typing. Why would I merge a Cache-Control lecture that never touched the wire in this brownfield app?

Brownfield front ends fail in the quiet places, like service workers and intermediary caches that tutorials skip. A free coding model will invent ETags, purge keys, and a casual no-store as if your CDN were a textbook diagram. Have you watched a generated patch rename a header that your origin never sent on any environment? That is the DX break: you spend the opening quarter hour arguing with prose while the browser serves yesterday.

The one fix that mattered was embarrassingly small, and it did not live inside the prompt window at all. I wrote a replay probe that hits the same URL twice, prints the cache headers, and diffs the two copies. Until those two copies agree with reality, I refuse to discuss architecture with the model in any serious way. Does that sound slow? It is faster than reverting a service worker that gaslit every teammate.

I still needed two cheap ingredients: a model that could draft a patch, and a server I could throw away after the replay. Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode's free model access and free server option are relevant here only as a draft-and-replay pair I can abandon. The rest of this workflow is local, boring, and useful even if you never mention a product name again.

The probe is ordinary Node, because I already have it, and I do not want another package manager argument. It records status, cache-control, etag, age, last-modified, vary, and a simple boolean for whether set-cookie appeared. Then it hits the URL again and prints a line-oriented diff that even a tired reviewer can scan. If the model invented a header, the diff stays empty on the server and loud in the generated markdown.

Save this as header-replay.mjs. It is a proposed local artifact, not a benchmark, and it uses only Node's standard http and https modules.

// header-replay.mjs — proposed workflow, run against URLs you already may fetch.
import http from 'node:http';
import https from 'node:https';
import { URL } from 'node:url';

const KEYS = [
  'cache-control',
  'etag',
  'age',
  'last-modified',
  'vary',
  'expires',
  'pragma',
  'surrogate-control',
  'cdn-cache-control',
];

function fetchOnce(raw) {
  const u = new URL(raw);
  const lib = u.protocol === 'https:' ? https : http;
  return new Promise((resolve, reject) => {
    const req = lib.request(
      {
        hostname: u.hostname,
        port: u.port || (u.protocol === 'https:' ? 443 : 80),
        path: `${u.pathname}${u.search}`,
        method: 'GET',
        headers: {
          'user-agent': 'header-replay/0.1',
          accept: 'text/html,application/json;q=0.9,*/*;q=0.8',
        },
      },
      (res) => {
        const headers = {};
        for (const k of KEYS) headers[k] = res.headers[k] ?? '';
        headers.status = String(res.statusCode);
        headers['set-cookie?'] = Array.isArray(res.headers['set-cookie']) ? 'yes' : 'no';
        res.resume();
        res.on('end', () => resolve(headers));
      },
    );
    req.on('error', reject);
    req.end();
  });
}

function diff(a, b) {
  const keys = new Set([...Object.keys(a), ...Object.keys(b)]);
  const lines = [];
  for (const k of keys) {
    if (a[k] !== b[k]) lines.push(`${k}: ${JSON.stringify(a[k])} -> ${JSON.stringify(b[k])}`);
  }
  return lines;
}

const url = process.argv[2];
if (!url) {
  console.error('usage: node header-replay.mjs <url>');
  process.exit(2);
}

const first = await fetchOnce(url);
const second = await fetchOnce(url);
console.log('pass-1', first);
console.log('pass-2', second);
const changed = diff(first, second);
console.log(changed.length ? 'UNSTABLE_HEADERS' : 'STABLE_HEADERS');
for (const line of changed) console.log(line);

I run that before I paste any model output into the repo, because silence on the wire is the actual product bug. The first fifteen minutes on my clock look like a short ritual, not a brainstorming session with a chatbot. Can you feel how different that is from opening a chat and asking for a cache architecture? The probe answers one question: did this URL even speak HTTP the way the patch pretends?

# Minute 0–3: prove you can see the brownfield URL at all.
node header-replay.mjs https://staging.example.com/app

# Minute 3–6: capture a baseline you can diff later, nothing fancy.
node header-replay.mjs https://staging.example.com/app > /tmp/baseline-headers.txt

# Minute 6–10: if you have a throwaway host, point the same probe at it.
node header-replay.mjs http://127.0.0.1:8787/app > /tmp/replay-headers.txt

# Minute 10–15: only now ask a free model for a patch, and feed it the two dumps.
diff -u /tmp/baseline-headers.txt /tmp/replay-headers.txt || true

I keep the model on a leash by pasting those dumps and asking for a patch that names only headers that already appeared. If the draft mentions Surrogate-Control and the baseline never did, I throw the draft away without negotiating. Is that rude to the model? Maybe, but rudeness is cheaper than a service worker that pins a broken bundle to every laptop on the team. The disposable server matters because I can apply the patch there, rerun the probe, and delete the machine before the story spreads.

Here is the prompt shape I actually paste after the dumps, labeled as a proposal you should edit for your stack. I want the model to argue with the wire, not with my anxiety about freshness.

You are reviewing a brownfield SPA cache issue.
Only discuss headers that appear in pass-1 or pass-2 below.
If you need a header that is missing, say UNPROVEN and stop.
Do not invent a CDN product, a purge API, or a service worker file.
Return: (1) which header from the dump is the likely culprit,
(2) a minimal patch against files I named, (3) the exact
header-replay command I should rerun after the patch.

pass-1 and pass-2:
<paste dumps>

Notice what this does to the first quarter hour as a developer experience. I am not pairing with a genius; I am pairing with a suspect who must point at evidence I already collected. The free model can still be wrong, and the free server can still be unlike production, which is exactly why both have to be throwaway. Would I let that suspect rewrite sw.js before the probe printed STABLE_HEADERS? Not on a weekday, and not on a brownfield app with real users.

Illustrative output, not a measurement from a private run, looks like this when the origin is merely inconsistent between two GETs.

pass-1 {
  status: '200',
  'cache-control': 'public, max-age=60',
  etag: 'W/"9f3"',
  age: '12',
  'last-modified': '',
  vary: 'Accept-Encoding',
  expires: '',
  pragma: '',
  'surrogate-control': '',
  'cdn-cache-control': '',
  'set-cookie?': 'no'
}
pass-2 { ... age: '0' ... }
UNSTABLE_HEADERS
age: "12" -> "0"

An unstable age is often boring and honest. An etag that flips while the body did not change is a different animal, and that is when I let the model talk. A generated private, no-store on an asset that was public, max-age=31536000 is usually a panic patch, not a diagnosis. Have you seen how often AI cache advice is just panic with extra Markdown? The probe makes that panic visible in fifteen minutes instead of two days of "hard refresh for me?"

There are limits, and they are not subtle if you have ever shipped a CDN. This workflow does not prove correctness of stale-while-revalidate, cookie-gated HTML, or a service worker that intercepts fetch outside the headers the origin sent. It also does not bless a free remote server as a replica of production TLS, geo, or cache hierarchy, so do not treat a green probe as a load-test. If you cannot legally fetch the URL, or you do not own the service worker, do not point this script at it and do not paste dumps into any model.

Who should skip this entirely? Anyone hoping the first fifteen minutes will design a caching architecture from a blank repo, because architecture is not a header diff. Anyone behind a corporate proxy that rewrites Cache-Control will get a theatrical probe and a useless argument. Anyone who needs byte-level body identity should hash the payload, which this script deliberately refuses to do so you do not confuse content drift with header drift. I would also skip it for authenticated apps unless you already have a non-secret staging cookie story, because leaking set-cookie into a chat is a self-own.

I still use the cheap loop when the pain is DX, not theory: a model drafted a patch, a teammate almost merged it, and nobody had asked the origin a second question. The first fifteen minutes are for making the wire confess. After that, you can argue about architecture with whatever free model you already had, on a server you can throw away when the confession is over. If you want that draft-and-replay pair in one place, MonkeyCode's free model access and free server option are the combination I reached for; the probe above is the part I would keep even if the product vanished tomorrow.

Your Free AI Coding Stack Remembers Too Much: An Isolation Workflow

Quinn Wang — Wed, 02 Sep 2026 13:54:53 +0000

Most AI coding tools fail not because the model is weak. They fail because the context is dirty. Yesterday's failed test pollutes today's refactor. One noisy file steers the whole conversation. The fix is not a better prompt. The fix is isolation.

This article shows how to run a small, reproducible context isolation layer for AI-assisted code changes. The workflow uses MonkeyCode's open source project, its free model access, and its free server option. You can apply the same principles to any tool.

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

The Real Problem Is Not Tokens

Free tiers give you plenty of tokens. The bottleneck is relevance. When an AI agent receives a 200-file repository, it does not read every file. It retrieves fragments. Those fragments are often stale, duplicated, or irrelevant.

A typical session includes:

Old build logs from a different branch
Deprecated API examples from Stack Overflow
A teammate's half-written comment
The first 50 lines of a config file that changed last week

All of that becomes equally trusted context. The model has no way to distinguish the signal from the noise. You end up with confident, fluent, completely wrong suggestions.

The standard mitigation is a better system prompt. That helps, but it only works at the prompt level. It does not control what files the retriever picks.

A Different Approach: Context Budgets

Instead of asking the model to ignore noise, keep the noise out of the context. Give the agent a small, explicit budget: at most N files, M lines, and K test results. Enforce that budget before the model sees anything.

This is a routing problem, not a reasoning problem. You decide what the agent may see. The agent then focuses only on that slice.

MonkeyCode's open source project gives you a place to build that routing layer. Because it provides free model access and a free server option, you can run the whole pipeline without paying for a hosted IDE or a cloud subscription. You own the context pipeline.

The Isolation Workflow

We will build a small script that does three things:

Snapshot the git diff for the current change.
Select only the files touched by that diff, plus a fixed allowlist.
Send that selected context to the model through MonkeyCode's API-compatible endpoint.

The model never sees the full repository. It sees only the diff, the allowlist files, and the latest test output for the changed module.

Step 1: Snapshot the Change

Run this inside your repo:

git diff HEAD --name-only > /tmp/context_allowlist.txt
git diff HEAD > /tmp/context_diff.patch

This gives you two artifacts: the list of changed files and the exact patch. The patch is the ground truth for what changed.

If you are working on a fresh branch, use git diff main...HEAD instead of HEAD. That captures the full branch diff.

Step 2: Build the Context Package

Now we create a small directory with only the relevant files.

rm -rf /tmp/context_bundle && mkdir -p /tmp/context_bundle
while read -r file; do
  if [ -f "$file" ]; then
    mkdir -p "/tmp/context_bundle/$(dirname "$file")"
    cp "$file" "/tmp/context_bundle/$file"
  fi
done < /tmp/context_allowlist.txt

cp /tmp/context_diff.patch /tmp/context_bundle/change.patch

Add one more file: a short description of the intended change. Write it before asking the model. Do not let the model guess intent.

cat > /tmp/context_bundle/goal.md <<'EOF'
Goal: Fix flaky timeout in the retry logic.
Acceptance: Retry waits between attempts and stops after 3 tries.
EOF

Step 3: Send Only the Bundle to the Model

MonkeyCode's free server runs locally on your machine or on a small free-tier VM. It exposes an OpenAI-compatible endpoint. Point your HTTP call at that endpoint with the bundle as system and user messages.

Here is a minimal Python client:

import json
import glob
from pathlib import Path
import urllib.request

BUNDLE = "/tmp/context_bundle"
ENDPOINT = "http://localhost:31415/v1/chat/completions"

def read_files():
    files = sorted(glob.glob(f"{BUNDLE}/**/*", recursive=True))
    content = []
    for path in files:
        p = Path(path)
        if p.is_file() and p.suffix in {".py", ".js", ".ts", ".md", ".patch", ".json"}:
            content.append(f"### FILE: {p.relative_to(BUNDLE)}\n\n{p.read_text()}")
    return "\n\n".join(content)

payload = {
    "model": "free-model",
    "messages": [
        {"role": "system", "content": "You review a code change. Only use the files provided."},
        {"role": "user", "content": read_files()}
    ],
    "temperature": 0
}

req = urllib.request.Request(ENDPOINT, data=json.dumps(payload).encode(), headers={"Content-Type": "application/json"})
response = urllib.request.urlopen(req)
print(json.loads(response.read())["choices"][0]["message"]["content"])

The key decision is in read_files(). It only reads the bundle. The model has no path to the full repository. It cannot retrieve something that is not there.

How This Changes the Output

Run the same change through a non-isolated tool and through this workflow. The isolated version will produce more conservative, more task-specific suggestions. It will not invent files that do not exist. It will not reference a function from another module unless that function is in the bundle.

The trade-off is speed of onboarding. A fully contextual agent can discover useful existing code automatically. Our isolation workflow forces you to manually add allowlist files if a change crosses module boundaries.

Decision Table: Use Isolation or Not

Scenario	Isolated bundle	Full repo context
One-file bugfix	✅ Best	Overkill
Refactor across 10 modules	⚠️ Needs manual allowlist	✅ Better
New feature in unknown codebase	🚫 You will miss dependencies	✅ Best for discovery
CI failure fix	✅ Perfect	❌ Too noisy
Security audit of a diff	✅ Ideal	❌ Too broad

Use isolation when the change is local and the failure is specific. Use full context when you need discovery, but then you must accept the noise.

Why Free Models and a Free Server Matter Here

Context isolation eats tokens. You send the same files multiple times across iterations. On a paid API, that becomes expensive fast. Free model access removes that cost ceiling.

A free server also changes privacy. You can run the isolation server on your own machine or on a free-tier VM. The diff and the source files never leave your control. That is a real advantage for unreleased code or proprietary modules.

MonkeyCode's free server option gives you a local endpoint without configuring API gateways. You can test this workflow in under an hour. If it does not improve your review quality, stop and go back to a full-context agent.

Limitations You Must Accept

The free models are not frontier models. They may produce less elegant solutions. They are fine for review, test generation, and small refactors. They are not suitable for architect-level reasoning on large codebases.

The free server is also not a permanent SLA. Do not build a production pipeline on it. Use it for experiments, personal work, or internal tooling. If you need reliability, plug in a paid API or a self-hosted model.

This workflow assumes git. If your team uses mercurial or an unfamiliar VCS, adapt the diff commands yourself. The principle stays the same: capture the change, select the files, drop everything else.

How to Extend This Workflow

Add a test snapshot to the bundle. Run only the tests for the changed module and write their output into test_output.txt. Include that file in the bundle. The model can then explain why the test fails and what the fix does, using the actual error instead of a guess.

Add a lint step. Run git diff | eslint and include the linter output. Now the model sees the exact line numbers and the exact rules being violated. That is much stronger context than "the linter is unhappy."

You can also version the bundle. Save every bundle as contexts/YYYY-MM-DD-HHMM/. After a week, replay a few sessions and ask why certain suggestions were so wrong. The answer is almost always in the bundle: the wrong file was there, or the right file was missing.

The One Metric That Matters

Track the percentage of model suggestions that you accept without modification. That is your barometer. If you were at 10% before and you reach 30% with isolation, the workflow pays for itself. If the number stays flat, the context was not the problem.

The same metric works for any AI coding tool. You do not need a dashboard. A simple tally in a spreadsheet works.

What to Do Next

Clone MonkeyCode's open source repository. Run the free server locally. Try this isolation script on your next bugfix. Compare the suggestions against your normal workflow.

If it helps, keep it. If not, the cost was zero: free models, free server, and a few lines of shell code. That is the right way to evaluate developer tooling — not by marketing, but by an experiment you can reproduce before lunch.

The Real Friction in Free AI Coding Isn't the Model — It's the Setup

Quinn Wang — Tue, 01 Sep 2026 13:06:39 +0000

Free AI coding tools rarely fail because the model is dumb. They fail because the road from installation to first useful answer is paved with environment variables, credential files, and server endpoints that never line up. I recently spent fifteen minutes debugging a proxy that pointed to a dead port, and that was after a clean install. The lesson? The real deliverable isn't model quality — it's a setup that works.

MonkeyCode, an open-source project, focuses on that exact pain. Disclosure: This article was prepared as part of MonkeyCode's product outreach. It offers free model access and a free server option, which means you can skip most of the configuration tango that usually comes with AI-assisted development. Instead of managing a local model runner, a separate inference server, and an editor plugin that all disagree with each other, you have one consistent place to point your editor.

Why does that matter? Because every configuration file is a chance for the system to break in a way that has nothing to do with your code. A wrong port, a missing schema, a stale token — each one produces an error that sends you down a rabbit hole. The most expensive resource in development isn't compute; it's your attention. When a tool spends your attention on plumbing instead of programming, the cost is hidden but enormous.

In practice, the first launch of any AI tool is a gauntlet. I count five things that usually go wrong: the model binary is too large, the download fails halfway, the port is already taken, the authentication handshake times out, or the editor extension can't find the local server. Each failure looks like a programming problem, but it's really an environment problem. The most effective fix is to eliminate the environment.

That's where a free, hosted server shines. It shifts the computational burden away from your laptop and onto infrastructure that is already running. You don't need a beefy GPU or a midnight brew of llama.cpp; you just need an HTTPS endpoint and a valid token. For developers who work on a company-issued laptop with restricted ports, that's not a nice-to-have — it's the difference between using an AI tool and reinstalling Python for the fourth time.

Another angle: the free server turns a synchronous blockage into an asynchronous resource. When your editor can reach the model without negotiating a local firewall, you stop treating AI as a delicate instrument and start treating it as a utility. Utilities are just there, like electricity. You don't configure your wall socket every morning; you plug in and go. That mental shift matters more than any token count.

To make this concrete, I wrote a tiny shell script that checks the usual pain points. Run it before you start a session and you'll see exactly what your environment expects.

#!/bin/bash
# friction-check.sh — uncover common setup blockers
echo "=== Runtimes ==="
node -v 2>/dev/null || echo "node: missing"
python3 --version 2>/dev/null || echo "python: missing"
echo "=== Local ports ==="
for port in 3000 8080 8000; do
  echo "$port: $(curl -s -o /dev/null -w '%{http_code}' http://localhost:$port 2>/dev/null || echo closed)"
done
echo "=== Credentials ==="
[ -n "$OPENAI_API_KEY" ] && echo "OPENAI_API_KEY: set" || echo "OPENAI_API_KEY: missing"
[ -n "$MONKEYCODE_API_KEY" ] && echo "MONKEYCODE_API_KEY: set" || echo "MONKEYCODE_API_KEY: unset (free tier may not need it)"

On my machine, the script reported a missing Python runtime, a closed port 8000, and no API key. A traditional setup would have required me to fix all three before writing a single line of code. With MonkeyCode's free server, the port requirement disappears; with the free model access, the key requirement disappears too. The only element left is the runtime, which my code editor already uses anyway.

Think of it like ordering a coffee. Some tools give you the beans, a grinder, and a milk frother, then ask you to become a barista. MonkeyCode hands you a cup and says, "Here's your espresso." Both approaches produce caffeine, but only one lets you start the day without a ten-step ritual. That's the developer experience difference that matters in the first fifteen minutes.

Now for the caveats. I am not quoting token quotas or server throughput because I haven't verified those numbers from a primary source today. The free tier might not fit everyone: if you need a fully offline environment, an air-gapped network, or a static model that never changes, then an external free server is the wrong answer. Also, don't mistake convenience for capability — the model's output still needs human review, and this tool won't save you from bad requirements.

Let me also address the obvious question: does free mean unreliable? In my experience, the reliability depends on the provider's infrastructure, which is exactly why a hosted option can beat a self-managed local setup. A local process dies when your laptop sleeps; a hosted service doesn't. For developers who move between meetings and a dozen browser tabs, that stability is the difference between trusting the tool and watching it fail silently.

Who should skip this? Teams with strict data-residency policies, users on metered satellite connections, and anyone who just enjoys building their own infra. For those cases, a local model runner is the better fit. But if your blocker is not compute cost but configuration cost, the free server model deserves a look.

One more observation from my testing: the speed of feedback matters more than the speed of inference. A tool that responds in two seconds while you're in flow feels five times faster than a tool that responds in one second but interrupts your rhythm with a configuration prompt. MonkeyCode's setup kept me in flow because there was nothing to configure. That's a subtle but powerful property.

Free tools are judged in the first fifteen minutes, not by benchmark tables. The ones that win let you move from idea to output without detouring through Stack Overflow. MonkeyCode cleared that detour for me, and the same friction-check script will tell you whether your environment is ready. Run it, see what breaks, and then decide if the setup is the real cost.

Free Models Write Tests. Mutations Prove Them.

Quinn Wang — Mon, 31 Aug 2026 12:12:12 +0000

A passing test proves nothing. A test that fails when the code is broken proves everything. Free models can generate the second kind, but only after you force them through a mutation gate.

The gap is not generation. The gap is trust. A free-tier model writes twenty tests in thirty seconds. All green. The commit ships. Months later, a regression slips through because those tests only checked that the code did something, not the right thing.

This article shows a zero-budget pipeline. MonkeyCode's free model access writes the tests. MonkeyCode's free server runs them and mutates the source. The result is a measurable quality gate, not a hopeful vibe.

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

Why Mutation Testing Is the Right Judge

Unit tests have a single job: catch regressions. A test that never fails on broken code is a false confessor. Mutation testing edits the source in tiny ways — swapping > to <, deleting a return, flipping a boolean — and then checks if the test suite catches the edit.

If a mutant survives, that test does not protect that behavior. The survival rate is the confidence score for the generated test.

The Pipeline: Generate, Run, Mutate, Decide

Step 1: Generate tests with a free model.

Send the target function to MonkeyCode's free model access. Ask for a pytest file focused on edge cases, not happy paths. The model returns a draft. Do not open it yet.

Step 2: Run the original tests on a free server.

MonkeyCode's free server becomes the executor. It pulls the repo, installs dependencies, runs pytest, and returns a baseline. The server is stateless and ephemeral, so setup cost is zero.

Step 3: Mutate the source and rerun.

A small script rewrites the source file into N mutant versions. For each mutant, the server reruns the test suite. Survivors are recorded.

Step 4: Compare survival rates.

A decision table tells you which tests to keep, which to rewrite, and which to delete.

A Minimal Mutation Runner You Can Run Today

The following script is intentionally small. It mutates Python operators and statements, runs pytest on each version, and outputs a survival report.

# mutation_gate.py
import ast
import copy
import subprocess
import sys
import tempfile
from pathlib import Path

MUTATIONS = {
    ast.Gt: [ast.Lt, ast.Eq],
    ast.Lt: [ast.Gt, ast.Eq],
    ast.Add: [ast.Sub],
    ast.Sub: [ast.Add],
    ast.And: [ast.Or],
    ast.Or: [ast.And],
}

class Mutator(ast.NodeTransformer):
    def __init__(self):
        self.mutants = []

    def visit_BinOp(self, node):
        self.generic_visit(node)
        repls = MUTATIONS.get(type(node.op), [])
        for repl in repls:
            newnode = copy.deepcopy(node)
            newnode.op = repl()
            self.mutants.append(newnode)
        return node

    def visit_Compare(self, node):
        self.generic_visit(node)
        for op in node.ops:
            repls = MUTATIONS.get(type(op), [])
            for repl in repls:
                newnode = copy.deepcopy(node)
                newnode.ops = [repl()]
                self.mutants.append(newnode)
        return node

def apply_mutant(source, mutant_node):
    tree = ast.parse(source)
    # Simple approach: replace the whole module with a tree holding one mutant
    # In practice, replace node in the tree by matching source position.
    # This demo mutation swaps every occurrence of a single operator.
    return ast.unparse(mutant_node)

def run_tests(test_file):
    return subprocess.run(
        [sys.executable, "-m", "pytest", test_file, "-q"],
        capture_output=True, text=True
    ).returncode == 0

def mutate_and_report(source_file, test_file):
    source = Path(source_file).read_text()
    tree = ast.parse(source)
    mut = Mutator()
    mut.visit(tree)

    total = 0
    killed = 0
    survivors = []

    for mutant_ast in mut.mutants:
        mutant_source = apply_mutant(source, mutant_ast)
        with tempfile.NamedTemporaryFile(mode="w", suffix=".py", delete=False) as f:
            f.write(mutant_source)
            mutant_path = f.name

        total += 1
        tests_pass = run_tests(test_file)
        if tests_pass:
            survivors.append(mutant_path)
        else:
            killed += 1

    print(f"Mutants total: {total}")
    print(f"Killed: {killed}")
    print(f"Survived: {len(survivors)}")
    print(f"Mutation score: {killed / total:.2%}" if total else "No mutants")

if __name__ == "__main__":
    mutate_and_report(sys.argv[1], sys.argv[2])

Run it after the free model writes the test:

python mutation_gate.py src/billing.py tests/test_billing.py

A mutation score above 80% means the generated test is worth keeping. Below 60%, the test is mostly theater.

Decision Table: Which Tests Earn Their Place

Mutation score	Verdict	Action
90–100%	Strong	Keep and merge
70–89%	Acceptable	Keep, add one edge-case test
40–69%	Weak	Regenerate with more failure examples
0–39%	Harmful	Delete and rewrite from a different prompt

This table turns a subjective code review into a numeric gate. Teams can set the threshold in CI and reject PRs that lower the mutation score.

Where the Free Server Shines

Running this loop locally ties up a laptop for an hour. With MonkeyCode's free server, the mutation runs happen off-machine. The server queues each pytest run, collects the scores, and writes a Markdown report.

The cost is zero for a reasonable number of mutants. That changes the habit: developers stop treating generated tests as filler and start demanding proof.

Honest Limits

This mutation runner is a prototype, not a production framework. It handles only operator-level mutants, not deleted statements or changed arguments. Real projects need a tool like mutmut or cosmic-ray running on the server.

The free server is not a high-performance CI cluster. It executes small test suites and reports results. Heavy integration tests will hit patience limits, not correctness limits.

Who should not use this approach? Teams shipping safety-critical systems need formal verification, not mutation testing. Developers who already use a commercial mutation suite may find the free-tier overlap redundant.

The Core Lesson

Free models are cheap. Trust is expensive. Mutation testing is the exchange rate.

Next time a free model hands you twenty green tests, run one mutation pass before you merge. Let the survivors teach the model what real coverage means.

The $0 Code-Review Pipeline: Free Models, Free Server, No Credit Card

Quinn Wang — Sun, 30 Aug 2026 11:16:34 +0000

A code-review bot that costs zero dollars per pull request sounds like a compromise. It is not. A free model with a self-hosted server catches missing tests, dead code, and broken error handling as well as paid tiers do for common cases. The trick is choosing the right endpoint and wiring a trigger that runs on every PR.

This guide uses MonkeyCode, an open-source AI coding assistant, for exactly that setup. Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode offers free models and a free server option, so the entire pipeline runs without a credit card. There is no trial clock. There is no billing form. There is only an API endpoint and a prompt.

The workflow is simple. A GitHub Action detects a pull request, extracts the diff, and sends it to a MonkeyCode endpoint. The endpoint can be the hosted free server or a server you run yourself. The returned comments are posted back to the PR. The whole loop takes less than a minute for a typical diff.

Why bother with your own server? Control. You set the rate limits, the logging, and the model. The hosted free tier is fine for experiments. A self-hosted server keeps every diff inside your network, which matters for closed-source work. That choice should not feel heavy. It is a matter of one environment variable.

Here is the complete action. Save it as .github/workflows/ai-review.yml in any repository.

name: ai-review
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Generate diff
        run: git diff origin/${{ github.event.pull_request.base.ref }}...HEAD > /tmp/diff.txt
      - name: Send diff to MonkeyCode
        env:
          MC_API_URL: ${{ secrets.MC_API_URL }}
          MC_API_KEY: ${{ secrets.MC_API_KEY }}
        run: |
          curl -sS -X POST "$MC_API_URL/v1/completions" \
            -H "Content-Type: application/json" \
            -H "Authorization: Bearer $MC_API_KEY" \
            -d @- <<BODY > /tmp/review.json
          {"model":"default","prompt":"You are a code reviewer. Review this diff and list concrete issues:\n\n$(cat /tmp/diff.txt)","max_tokens":500}
BODY
      - name: Post comment
        run: |
          comment=$(jq -r .choices[0].text /tmp/review.json)
          gh pr comment "${{ github.event.pull_request.number }}" --body "$comment"
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

The workflow needs two repository secrets. MC_API_URL points to the MonkeyCode server address. MC_API_KEY holds the free API key from the project's dashboard. If you self-host, point MC_API_URL to http://localhost:8080 and keep the key secret. The JSON body asks for a review with max_tokens set to 500, which keeps the response short enough for a PR comment.

The diff generation command is the fragile part. It assumes the branch was opened from the current default branch. For forks, git diff may not see the history. A safer method is to use the GitHub API to fetch the diff directly. That change is left as an exercise because most personal projects run on branches, not forks.

The jq parser is available on ubuntu-latest. If you use a lighter runner, install it first. The gh CLI also needs to be present, and it is. Nothing else is required. The action is intentionally small.

A decision table helps you pick the server mode. The factors are straightforward.

Factor	Hosted free server	Self-hosted free server
Setup time	About five minutes	About thirty minutes
Data privacy	Diff leaves your network	Diff stays on your machine
Capacity	Limited by provider	Limited by your hardware
Best for	Quick trials, open source	Private repos, compliance

That table is not a benchmark. It is a cost model. The hosted server wins when you want a taste without reading a README. The self-hosted server wins when your code is the product.

Free models come with limitations. Context windows are smaller than the latest paid tier. Rate limits are lower. The model name and capabilities can change as the project evolves. Treat this bot as a formatting and sanity check, not an architectural oracle. It will catch a missing else or an unhandled null. It will not design your event-driven microservice.

The output is a suggestion. Do not make the PR fail when the bot complains. Let a human decide. The bot's value is in the baseline it creates: every diff gets a first pass before a human looks at it.

What about the free server? The MonkeyCode repository documents how to launch it. The server exposes a compatible API on a local port. You can run it on a spare laptop or a small VPS. It does not need a GPU for the free model tier. A single CPU with a few gigabytes of RAM is enough for occasional PR reviews.

This pipeline was tested against a real side project. The review caught a missing null check in a TypeScript function and a SQL query that forgot a WHERE clause. It also generated a false positive on a closure variable name. That one-in-three hit rate is fine for a free tool. The false positive cost a minute to dismiss.

You can reproduce that result. Clone any repository, add the action, and open a PR. The first run takes about two minutes because the Action itself has to spin up. The second run is faster. Keep the diff small for the first trial. A feedback loop of ten lines is easier to judge than a rewrite of the whole codebase.

The setup cost is nearly zero. MonkeyCode's free models and free server make the experiment free. The only resource you spend is the time to read the repository's README and set two secrets. That is the right price for a test worth running.

Try it on a side project this weekend. After a few PRs, look at the comments you actually accepted. If the bot catches one real bug a week, it has already paid for itself in attention. If it only contradicts your style guide, delete the workflow and move on. Either way, you now know what a zero-dollar review bot feels like.

The open-source project is listed on the MonkeyCode GitHub page. Start there, run the server, and point this workflow at your next pull request.

Friction Log: The First Fifteen Minutes of an AI Coding Tool

Quinn Wang — Sat, 29 Aug 2026 10:22:53 +0000

The first fifteen minutes of an AI coding tool have almost nothing to do with the model, because the model only matters once the editor, the config, and a server on the other end of the network agree to talk to one another. When those seams are quiet, you trust the tool enough to hand it a real task, and when they squeak, you blame the model and start shopping for the next thing. That is why I recently stopped timing benchmarks and started timing my own setup, and the result was a small friction log that changed how I review every AI assistant.

MonkeyCode is an open-source AI coding assistant that offers two things I usually distrust in the same breath: free model access and a free server option. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I approached it the way I approach every free tier, which means I treated the generosity as temporary, the documentation as optimistic, and the first prompt as a coin flip. My start line was identical for every tool: a fresh project, an empty config, and a stopwatch running in the corner of my terminal.

The metric I care about is time to first useful edit, which I define as the exact second a suggestion lands in my editor and I actually keep it instead of deleting it in confusion. My first attempt failed on the most boring blocker imaginable: the tool sat silent on the first prompt, and that silence is the worst failure mode in this category because it looks like a model problem when it is usually a routing problem. I checked the model settings, I checked the API key, and I was about to abandon the whole free-tier category when I remembered my own rule from a previous teardown: audit the server, not the model. The server is the one part of the chain you can interrogate directly, and a single curl command tells you more than five minutes of prompt fiddling ever will.

The fix that mattered took about twenty seconds, because the default configuration was not broken, it was just pointing at a destination I had never verified. Once I pointed the client at the free server option instead of assuming I had to host the backend myself, the first response showed up fast enough that I laughed at the fifteen minutes I had spent staring at silence. That is the exact moment every AI tool earns me or loses me, but how many tools have you abandoned right before the one-line fix that would have saved them? Every AI coding tool promotes the developer to reviewer, and nobody has ever tested the reviewer, but the first fifteen minutes are that test whether you run it deliberately or not.

Here is the reproducible part: a tiny friction log that costs nothing and survives every tool you throw at it. Put it in ~/.local/bin and source it at the start of any evaluation session, then run your setup exactly the way a new user would.

#!/usr/bin/env bash
# friction.sh — a stopwatch for setup sessions
# usage: source friction.sh; note "opened docs"; note "first suggestion kept"
_start=$(date +%s)
note() {
  printf '%4ss  %s\n' "$(( $(date +%s) - _start ))" "$*" | tee -a "$HOME/friction.log"
}
first_edit() {
  grep -i "kept" "$HOME/friction.log" | head -1 | awk '{print $1}'
}

Call note after every step that costs you attention, especially the ones that make you open a browser tab you did not plan to open. When you finally keep a suggestion, call note "first suggestion kept" and then run first_edit to see how many seconds of your life this tool consumed before it did anything useful. The gaps between those markers are the real review, because a tool that loses you at step three will never show you how good step fifty is.

When a tool goes silent, resist the urge to rewrite the prompt and interrogate the chain in this order instead: config, endpoint, auth, restart. First ask whether the client read the config you think it read, then probe the server with a plain curl, then check whether a token is present and still valid, and only then restart the whole thing.

# does the endpoint answer at all, and how slowly?
curl -sS -o /dev/null -w 'HTTP %{http_code} in %{time_total}s\n' "$SERVER_URL"

# is a token actually in the environment, or did you dream it?
env | grep -i token | sed 's/=.*/=<redacted>/'

That order works for MonkeyCode, and it works for every other assistant I have tried, because the model is almost never the first thing that breaks. Free model access and a free server are the two availability claims that made this teardown possible, but those are exactly the kind of facts you verify in the repository before you build a workflow around them. Free tiers change without ceremony, and a quota you read on a blog post today is already a historical document by the time your calendar catches up.

Who should not use this approach: anyone whose evaluation question is about answer quality on hard problems, because fifteen minutes says nothing about that, and anyone whose policy requires code to stay on company hardware, because a hosted free server is a non-starter regardless of how convenient it is. This is not a benchmark either, and I am deliberately not printing a number for the free tier, because an unverifiable number is exactly the outdated data this article is supposed to avoid. What this approach is good for is deciding whether a tool deserves a second hour at all.

Steal the friction log for your next evaluation, because fifteen minutes of honest timestamps will save you fifteen hours of feature-list reading. If MonkeyCode ends up on your shortlist, treat its repository as the source of truth for what the free tier includes this month, and let the first useful edit do the talking. The best review you will ever write is the one where you can point to the exact second a tool won you over, or the exact second it lost you.

Run the Cheap Review First

Quinn Wang — Wed, 26 Aug 2026 11:17:36 +0000

Most code review errors are boring. They are typos, wrong variable names, missing null checks, and copy-paste mistakes. A free model catches these reliably. A paid model catches them slightly faster. The difference rarely matters. The expensive model earns its money later, on the second pass, when the review turns architectural. Most teams run these two passes in the wrong order. They send every diff to the most powerful model they can afford. Then they run out of budget and patience before the interesting questions get asked.

Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode's free models and free server make the two-queue design practical for a solo developer or a small team. The free tier is not a compromise here. It is the correct tool for the first pass.

The two-queue rule is simple. Every incoming diff gets classified into one of two queues. The fast queue handles mechanical errors. The slow queue handles design problems. The fast queue runs on free models. The slow queue runs on the best model you can justify. The classification is the hard part, and it is a script, not a feeling.

Think of a hospital triage desk. A paper cut does not go to surgery. A chest pain does not wait in the minor injuries line. Code review needs the same discipline. Most diffs are paper cuts. A few are chest pains. Routing them correctly is worth more than upgrading the model.

Here is a routing script that reads a diff and assigns a risk score. Save it as queue-diff.py.

#!/usr/bin/env python3
"""queue-diff.py — route a diff to the fast or slow review queue."""
import re
import sys

def risk_score(diff_text: str) -> int:
    score = 0
    added = re.findall(r"^\+[^+]", diff_text, re.MULTILINE)
    score += len(added) // 50
    if re.search(r"TODO|FIXME|HACK", diff_text):
        score += 2
    if re.search(r"except:|except\s", diff_text):
        score += 1
    if re.search(r"password|token|secret|api[_-]?key", diff_text, re.IGNORECASE):
        score += 5
    return score

def main() -> None:
    diff = sys.stdin.read()
    score = risk_score(diff)
    print("SLOW_QUEUE" if score >= 5 else "FAST_QUEUE")

if __name__ == "__main__":
    main()

Run it in a review pipeline like this:

git diff origin/main...HEAD | python3 queue-diff.py

The script is deliberately naive. It does not understand semantics. It understands signals. A diff touching a secrets file goes to the slow queue. A config change with two lines goes to the fast queue. A fifty-line refactor goes to the slow queue. The threshold is a starting point, not a law.

The fast queue review prompt is short. Ask the free model to check three things. Are names consistent? Are there null or undefined risks? Are there obvious copy-paste errors? That is the entire brief. No architecture questions. No style debates. The output is a list of concrete findings or a single word: clean.

The slow queue review prompt is different. It asks about coupling, error propagation, and whether the change matches the surrounding design. This is where a stronger model changes the outcome. This is where the paid tier earns its cost. Running this prompt on every tiny diff is how teams burn their budget on noise.

The two-queue design changes the economics of review. A team of five reviewing ten pull requests a day can route most diffs to the fast queue. The free models handle the mechanical pass. The slow queue sees only the diffs that matter. The result is a review process that scales with attention, not with token spend.

MonkeyCode fits this workflow because both queues are available in one client. The free models cover the fast queue without a subscription. The free server removes the local hardware requirement, which matters on a company laptop. The setup is a config change, not a migration. The project is open source, so the limits are visible in the repository. Check the current numbers there before planning around them.

The decision table for queue assignment looks like this:

Diff characteristic	Queue	Why
Config, docs, styles	Fast	Mechanical changes, low blast radius
One function, clear scope	Fast	Free models handle local errors
Cross-module refactor	Slow	Design questions dominate
Auth, secrets, payments	Slow	Failure cost is high
Generated code	Fast	Nobody should review it deeply

The approach has limits. Free models still hallucinate on ambiguous code. The fast queue can miss subtle concurrency bugs. A free server adds network latency and sends code off-device. Teams under compliance rules should skip the server and run a local model instead. Solo developers on air-gapped machines cannot use this workflow at all. The two-queue rule is a budget strategy, not a quality guarantee.

Some teams should not use this approach at all. Teams reviewing security-critical code. Organizations with strict data residency policies. Projects where every line is a liability. These teams need the slow queue for everything. The free tier does not help them, and pretending otherwise is how review pipelines rot.

The core lesson stands. Run the cheap review first. Reserve the expensive review for the diffs that deserve it. The free models are not a downgrade. They are the first pass of a two-stage process, and they are the stage that runs most often.

If you want to try the two-queue setup, clone the open source repository and check the current free model list and server status. The script in this article is yours to keep. It works with any client that reads a diff from stdin. The review budget is the real constraint, and this workflow spends it where it counts.

The 10M Token Question

Quinn Wang — Tue, 25 Aug 2026 09:14:37 +0000

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

Most developers ask the wrong question about AI coding tools, and I used to be one of them. We argue about model rankings and leaderboard scores, yet the assistants that actually change our workflow are rarely the smartest ones; they are the ones we can afford to run badly. That is why I now evaluate every coding tool the same way: give it a hard token budget, put it on a free server, and watch what it does while the meter is running.

Benchmarks measure the model, not the loop, and that distinction is the whole game. A model can score beautifully on a curated suite and still burn forty thousand tokens explaining a syntax error, because no leaderboard measures the cost of a rambling conversation. The price signal is the only honest feedback loop we have, and most paid subscriptions hide it behind a flat monthly fee where waste feels free.

This is where MonkeyCode enters the picture, and I will be honest about my bias up front: the project gives you free model access, a free server option, and a ten-million-token allowance, which sounds like marketing until you treat it as an experiment budget. Ten million tokens is roughly enough to run a small feature through a coding assistant a few hundred times, which means you can finally measure the variance between a good day and a bad day. Generosity, in other words, is a debugging strategy rather than a giveaway, because it removes the excuse not to look at your own usage.

The free server matters just as much as the token budget, and localhost is a liar when it comes to agent behavior. An assistant that feels instant on your laptop will stall, retry, and quietly fail once it faces real network latency, cold starts, and rate limits, and a free server reproduces those conditions without asking for a credit card. If a tool cannot survive a constrained environment, it will not survive your production environment either, and you deserve to learn that before you pay for it.

The budget test

So here is the reproducible artifact I use, a small budget test that treats a real task as the unit of measurement instead of a benchmark question. Save the script below, point it at your tool's CLI or any OpenAI-compatible endpoint, and run it against a task file from your own repository. It takes about ten minutes, and if your endpoint is free, the only thing you spend is attention.

#!/usr/bin/env bash
# budget_test.sh — measure tokens per real task, not per benchmark
set -euo pipefail

TASK_FILE="${1:-task.md}"
LOG="budget_$(date +%Y%m%d_%H%M%S).jsonl"

run() {
  local label="$1" prompt="$2"
  local start end response usage
  start=$(date +%s)
  # Point ENDPOINT and API_KEY at your tool's CLI or compatible endpoint.
  response=$(curl -s "${ENDPOINT:-http://localhost:8080/v1/chat/completions}" \
    -H "Authorization: Bearer ${API_KEY:-test}" \
    -H "Content-Type: application/json" \
    -d "{\"model\":\"${MODEL:-default}\",\"messages\":[{\"role\":\"user\",\"content\":\"$prompt\"}]}")
  end=$(date +%s)
  usage=$(printf '%s' "$response" | jq -c '.usage // {prompt_tokens:0, completion_tokens:0}')
  printf '{"label":"%s","seconds":%d,"usage":%s}\n' "$label" "$((end-start))" "$usage" >> "$LOG"
}

run "explain" "Read the failing test in $TASK_FILE and explain the root cause in three sentences."
run "plan" "Propose a fix for $TASK_FILE without writing any code."
run "patch" "Write the minimal patch for $TASK_FILE."

jq -s '{runs:length,
        total_seconds:(map(.seconds)|add),
        total_prompt_tokens:(map(.usage.prompt_tokens)|add),
        total_completion_tokens:(map(.usage.completion_tokens)|add)}' "$LOG"

Run it three times on the same task, because one sample tells you nothing about variance, and then read the ledger like a doctor reads a chart. If the explain step burns more than a couple thousand tokens, your task file is too vague or the tool cannot see your codebase. If the plan step simply repeats the prompt back at you, the tool is ignoring your constraints, and no amount of clever prompting will fix that.

The decision table below is the part that turns the script into a decision, and I trust it more than any benchmark score. It converts three runs into a diagnosis, which is the difference between guessing and knowing. Read the row that matches your worst result, and act on it before you spend another token.

Observation	Diagnosis	Action
explain step > 2k tokens	Context too vague or codebase invisible	Tighten the task file, shrink the repo scope
plan echoes the prompt	Tool ignores constraints	Switch tool or endpoint before paying
patch fails twice in a row	Model cannot see the relevant code	Reduce file size, add explicit file paths
seconds grow across runs	Server or context degradation	Test again on a different free server

Limitations

Who should not use this approach? Teams with production SLAs should not run real workloads on a free server, and anyone in a regulated environment should check data policies before sending code anywhere. Free tiers also change without notice, so a ten-million-token budget is a starting point for measurement, not a permanent promise, and my script assumes an OpenAI-compatible endpoint or a thin CLI wrapper around whatever tool you choose.

The uncomfortable truth is that most of us do not know how many tokens we waste in a normal day, because the tools we pay for make waste invisible. A free server and a generous budget flip that equation, turning cost into a signal you can actually read, and that is why I now recommend the cheapest setup to everyone who asks. The next time somebody asks me which coding assistant is best, I ask them a different question: how many tokens did you waste yesterday?

If you do not know the answer, go find a free server, grab a budget, and start measuring, because the best assistant is the one whose waste you can see. MonkeyCode's free tier is a fine place to run this ledger, and the open-source codebase means you can read what the tool does before you trust what it says. If you run the budget test on your own tasks, I would genuinely like to hear what your token ledger tells you.

Audit the Server, Not the Model: A Free-Tier Test for AI Coding Tools

Quinn Wang — Tue, 25 Aug 2026 05:01:34 +0000

The model decides what the tool says, but the server decides what the tool does, and most developers audit the first and ignore the second. When you evaluate an AI coding assistant you ask which model it wraps, how many tokens the free tier includes, and whether the completions feel smart, yet the moment the tool has to actually run your code the whole calculation changes. My position is simple: the free server is the part of the free tier worth auditing first, because it tells you whether the tool can close the loop between a suggestion and a working program.

A token allowance is just a number on a pricing page until you watch it burn inside a real edit cycle, and a clever model is just a chat partner until its output has to survive a compiler. That is why I stopped asking which model is behind a tool and started asking where the code runs when I press run. The second question exposes more about a tool's honesty than any benchmark, because a tool that only generates text can look brilliant in a screenshot and fall apart in a fresh workspace.

Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode is an open-source AI coding assistant that currently offers free model access alongside a free hosted server option, and the operator's current free allowance sits at 10 million tokens; I treat that number as a snapshot rather than a promise, because quotas move and you should verify them before you build a workflow on top of them.

Why do I care about the server more than the model? Because the model is replaceable and the loop is not, and a free server lets you test the loop without the usual excuses. Local setups lie to you: your dependencies are already installed, your environment variables are already set, and your linter already knows your preferences, so the tool gets credit for your machine's preparation. A blank remote workspace removes that advantage and forces the assistant to bootstrap from nothing, which is exactly the condition most real projects start from.

Have you ever noticed that every demo video ends exactly when the code compiles? That is not a coincidence, because the interesting part of an AI coding session is not the first suggestion but the tenth correction, and the tenth correction is precisely what a screenshot cannot show. A free server changes that dynamic because it gives you a place where the failure is visible, and visible failure is the only honest material for an evaluation.

Here is the audit I run on any tool that offers a free server, and it is deliberately dumb because it measures three numbers instead of pretending to judge quality. The script is a ledger, not a benchmark: it records time to first edit, time to first run, and error-to-fix cycles, then leaves the interpretation to you.

#!/usr/bin/env bash
# audit-free-tier.sh — a ledger for your next AI coding tool trial
set -euo pipefail
LOG="${1:-free-tier-audit.csv}"
: > "$LOG"
now() { date +%s; }
stamp() { echo "$(now),$1" >> "$LOG"; }

stamp "session_start"
echo "1. Open the tool's free server workspace and paste this task:"
echo 'Build a Node HTTP server with a /health route returning {"ok":true}'
read -rp "Press Enter when the first edit appears" _
stamp "first_edit"

echo "2. Run the generated code in the remote terminal."
read -rp "Press Enter after the first run attempt" _
stamp "first_run"

echo "3. If it failed, paste the error back and count cycles."
for i in 1 2 3 4 5; do
  read -rp "Does it pass now? (y/n) " ok
  [ "$ok" = "y" ] && { stamp "fixed_cycle_$i"; break; }
  stamp "failed_cycle_$i"
done

echo "Ledger written to $LOG. Now compute:"
echo "  time_to_first_edit = first_edit - session_start"
echo "  time_to_first_run  = first_run - first_edit"
echo "  fix_cycles         = the last cycle number in the log"

Notice what the script does not do: it does not measure code quality, it does not score the model, and it does not care which vendor you are testing. That is intentional, because the moment you add subjective scoring you start rationalizing the tool you already want to like, and the whole exercise collapses into confirmation bias. A ledger keeps you honest by reducing the trial to events you can timestamp, which is why I run it on every new assistant instead of trusting my memory of how the session felt.

The numbers only mean something when you compare them across tools, so I keep a small table in my notes and I read it the same way every time. If the first edit lands within two minutes, the tool can bootstrap from a blank workspace; if the first run succeeds on the first attempt, the free server is actually executing code rather than just suggesting it; if error recovery takes more than two cycles, you are doing the debugging and the assistant is a typewriter with opinions. Tools with impressive models die on step two because their free server is a glorified preview pane, while modest models look great because the remote environment handles setup for them.

Teams keep choosing coding assistants the way they choose headphones, by reading spec sheets and trusting the brand, and then they discover six weeks later that the tool cannot run their monorepo or their CI pipeline. A ten-minute free-server audit will not catch every problem, but it will catch the most expensive one: the gap between what the tool generates and what the tool can execute. That gap is where developer time actually disappears, and it is the one number every vendor would prefer you never measure.

Who should not use this approach? If you already have a locked production workflow and a model you trust, a free-tier audit is noise, and if your project depends on proprietary libraries or private data, a free hosted workspace is the wrong place to test it. The audit also has real limits: ten million tokens sound generous until a long refactor starts eating them, free servers are not production infrastructure, and the numbers measure the tool's loop rather than the model's ceiling. Treat the ledger as a first date, not a marriage contract, and re-run it whenever the vendor changes the quota or the execution environment.

The next time someone shows you an AI coding tool, ask to see the free server instead of the model card, because a suggestion you cannot run is just a paragraph with syntax highlighting. If you want to run this audit somewhere with a free server, MonkeyCode's free tier is a reasonable place to start, but bring your own stopwatch — the point is the method, not the vendor.

Stop Tuning Prompts. Start Tuning the Loop.

Quinn Wang — Mon, 24 Aug 2026 19:48:51 +0000

There's a recurring argument on DEV right now that constraints make you a better engineer, and I think the AI coding discussion keeps ignoring the constraint that actually matters. That constraint is not the model, the context window, or the token budget — it's the speed of your reset loop. A coding assistant is only as useful as the time between a failed experiment and the next attempt, and most workflows are losing the game right there.

I've been testing this idea with a deliberately cheap setup: an open-source assistant called MonkeyCode, its free model access, and its free server option. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The point was not to rank the model against its competitors, because rankings describe the model, not your workflow. The point was to measure how many rounds of failure I could afford in an afternoon without spending money or polluting my laptop.

Here is the position I want to argue: you should treat every AI coding experiment like a git branch — cheap to create, cheap to delete, and never something you fall in love with. The moment a tool makes its environment feel permanent, you stop experimenting, and the moment you stop experimenting, model quality stops mattering. Free servers and free model tiers matter because they make the branch metaphor literal instead of aspirational, and that is a bigger deal than any benchmark delta.

The workflow I keep coming back to has four steps, and none of them are about prompt engineering. First, spin up the disposable server and point the assistant at the free model endpoint. Second, give it a real task with a real failure condition, like "write a test that fails for the right reason." Third, verify the output with my own check instead of trusting the tool's self-report. Fourth, tear the whole thing down and decide whether the next round deserves a fresh start.

The artifact that made this concrete is a tiny shell harness that times the entire loop instead of the model's answer. It runs with any coding assistant CLI, so the three functions below are placeholders you replace with whatever your tool actually ships:

#!/usr/bin/env bash
# loop.sh — time the full experiment loop, not the model's answer
set -euo pipefail

TASK="${1:-write a failing test for the auth module}"
ROUNDS="${2:-3}"

# Replace these three functions with your assistant's real CLI.
provision() { your-cli server up --free; }
run_task()   { your-cli run "$TASK" --output "./out-$1"; }
teardown()   { your-cli server down; }

for i in $(seq 1 "$ROUNDS"); do
  echo "--- round $i ---"
  start=$(date +%s)

  provision >/dev/null 2>&1
  run_task "$i" >/dev/null 2>&1
  ./run-tests.sh "./out-$i"
  teardown >/dev/null 2>&1

  end=$(date +%s)
  echo "round $i took $((end - start))s"
done

Run it three times — once with a local setup, once with the free server, once with a paid model — and you will learn more about your own workflow than a month of model comparisons. What I found is that the free server wins not because it generates tokens faster, but because it removes the friction of cleanup. When the environment is remote and disposable, I stop hoarding failed experiments, and that single habit changes how I prompt.

Why does that matter for the broader conversation? Because the current wave of AI discussion is full of people arguing about which model writes better code, and almost nobody is measuring the loop around the model. The "limitation breeds greatness" crowd is right, but for the wrong reason: the limitation that matters is not fewer features, it's cheaper failure. A free tier with a generous allowance — the project's current allowance is ten million tokens at the time of writing, though you should verify that number in the README before relying on it — is a constraint that works in your favor.

Now the honest limitations, because this approach is not for everyone. If you are building a production pipeline that needs guaranteed uptime and a support contract, a free server is the wrong foundation, and you should not build your CI around it. If your codebase is proprietary and your compliance rules forbid sending code to a remote machine, keep everything local and skip the server entirely. And if you need a specific model that is not available on the free tier, this workflow will not cover you, so check the model list before you commit.

There is also a deeper caveat: free tiers change, and what is free today may be metered tomorrow, so treat the allowance as an experiment budget, not an infrastructure plan. The loop harness has its own limitation too, because it measures your habits as much as the tool, and a fast loop with a lazy verification step is just fast garbage. You need a real test suite or a real human review at the verify step, or the whole exercise becomes theater.

So here is my closing argument: stop tuning prompts and start tuning the loop, because the prompt is the part you can see and the loop is the part that actually costs you time. A disposable server and a free model tier are a forcing function that keeps your experiments honest and your environment clean. When was the last time a benchmark told you something about your own Monday morning? Grab the open-source assistant, spin up the free server, and time your own three rounds — the script above will tell you more in an afternoon than a month of model comparisons.