Leave the Dropdown Closed

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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