Ask for a Real No in the First Fifteen Minutes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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