The first fifteen minutes of an AI coding session are not a warm-up; they are the product test. A recent post on DEV.to argues that if you cannot name the friction in that opening window, you should not trust the diff that follows. The author proposes treating this period as a drill, using a clock and a pre-set budget to avoid losing an afternoon to chatter without a reviewable change in the tree.

The Four-Beat Drill

The proposed method splits the opening quarter-hour into four distinct beats: reach, place, read, and touch. 'Reach' confirms you can talk to a model without guessing which door opened underneath you. 'Place' verifies the process cwd is the intended repository, not a parent folder. 'Read' ensures git status is clean enough that a later diff belongs to the current session, and 'Touch' proves a throwaway branch can be created and deleted, restoring git state.

Implementing the Friction Ledger

The core tool is a Node.js script named dx-drill.mjs that writes a ledger outside the work tree. It refuses the first real edit until four cheap checks each have a timestamp. The script uses environment variables like BUDGET_PLACE_MS and BUDGET_READ_MS to set strict time limits, defaulting to 30 seconds for place and read operations. If any beat exceeds its budget or fails, the script stops execution and logs the failure to a JSONL file specified by the FRICTION_LEDGER environment variable.

Context and Caveats

The author ran this drill against MonkeyCode's free model access and free server option, though the article is disclosed as part of MonkeyCode's product outreach. The script is explicitly described as an unexecuted proposal, not a vendor benchmark. It does not prove quality, safety, or cost, but rather catches infrastructure issues like a hung git process or a silent authentication hop. The author warns that a green HTTP status can still mean you reached a model you did not choose, making the manual 'reach note' a critical confession in the ledger.

Key Takeaways

  • Treat the first 15 minutes as a hard budgeted drill, not a casual setup.
  • Use a script to log timestamps for 'reach', 'place', 'read', and 'touch' before editing code.
  • A smooth landing page often hides a slow first edit; the ledger makes this visible.
  • Do not average scores across different model or server paths; keep them separate.

The Bottom Line

The clock will not make the model wiser, but it will stop you from paying an afternoon for a setup you never named. Smoothness is not a diff, and a messy ledger is always better than a demo that felt easy.