Score the File, Not the Prompt: A Week-One Triage Table for AI-Assisted PRs

Give the model a ticket only after you score the file.

Most juniors do it backwards. They paste the ticket, accept a patch, then try to understand it. On day one that order costs you your rollback.

This post gives you a small triage script, a decision table, and a baseline test loop. You run all three inside your first hour. The artifact is the point, not the opinion.

The risky window is week one

The tooling changed fast this year. Juniors now open real tickets with an agent in the loop from day two. That is fine, if you gate the loop with evidence.

My rule is simple. Score the file before you score the prompt. A patch is only as safe as the code it touches.

Step 1: Measure the blast radius

Run this on the file you plan to edit. It uses only git, grep, and find.

#!/usr/bin/env bash
# triage.sh - rate a file's blast radius before you take the ticket
set -euo pipefail

file="${1:?usage: triage.sh path/to/file [since]}"
since="${2:-90.days.ago}"
stem="$(basename "${file%.*}")"

churn=$(git log --since="$since" --format=%H -- "$file" | wc -l | tr -d ' ')
owners=$(git log --since="$since" --format=%ae -- "$file" | sort -u | wc -l | tr -d ' ')
refs=$(grep -RIl --exclude-dir=.git --include='*.ts' --include='*.js' --include='*.py' "$stem" . 2>/dev/null | wc -l | tr -d ' ')
tests=$(find . -path ./.git -prune -o -name "*${stem}*test*" -print 2>/dev/null | wc -l | tr -d ' ')

printf 'file=%s\nchurn=%s\nowners=%s\nreferences=%s\ntest_files=%s\n' \
  "$file" "$churn" "$owners" "$refs" "$tests"

Make it executable and run it on your candidate.

chmod +x triage.sh
./triage.sh src/billing/invoice.ts

Sample output from a small service I worked in:

file=src/billing/invoice.ts
churn=14
owners=5
references=9
test_files=2

Read it like this. High churn means the file moves under you. Many owners means no single reviewer knows the whole file. Many references means your typo becomes someone else's outage.

Treat the script as a rough instrument. It measures motion, not correctness. Zero test files is the loudest signal in the output.

Step 2: Turn the numbers into a decision

Do not negotiate with yourself. Map the score to one of three lanes.

Signals	Lane	Who edits	Evidence before PR
tests >= 1, owners <= 2, references <= 3	Green	You, with a model draft	Baseline test log, diff under 60 lines
tests >= 1, but owners >= 3 or references >= 6	Amber	Model drafts, you rewrite	Named reviewer, per-hunk explanation
tests = 0, or references >= 10, or churn is spiking	Red	Senior pairs with you	Written rollback plan first

Red does not mean forbidden. It means you do not learn on the expensive file. Take a green ticket first, then ask for the red one.

Step 3: Write the ticket contract in one paragraph

Before any prompt, write five lines in the ticket. File, function, expected behaviour, test command, and what must not change.

File: src/billing/invoice.ts
Function: applyDiscount()
Expected: rounding stays half-up, no new exports
Test: npm test -- invoice
Must not change: public signature, error messages

Now the model gets a boundary, not a wish. If it returns code that violates line five, you reject it in seconds.

Step 4: Prove the loop before the edit

Run the test command and save the output. This is your baseline, and it is the only honest reference you have.

npm test -- invoice 2>&1 | tee /tmp/base.log
grep -E 'passing|failing' /tmp/base.log

If the suite is already red, stop. A red baseline hides your regression inside someone else's failure.

After the patch, run the same command against the same log target. Compare counts, not vibes.

npm test -- invoice 2>&1 | tee /tmp/after.log
diff <(grep -E 'passing|failing' /tmp/base.log) \
     <(grep -E 'passing|failing' /tmp/after.log)

Identical counts plus your new test passing is a shippable result. Anything else is a conversation.

Step 5: Set the hunk budget and the rollback line

Cap the diff before you open the editor. Forty lines for a first ticket is plenty. Sixty is the ceiling on green files.

Write the revert command in the PR description. It takes ten seconds and saves an hour.

git revert --no-commit <sha>
git diff --cached --stat

If you cannot name the sha you would revert, you do not understand the patch yet. Read the diff again before you request review.

Where free model access and a free server actually help

A junior needs volume, and volume is where budgets bite. Explaining unfamiliar files, drafting a failing test, and re-reading your own diff are high-frequency, low-risk uses. This is exactly the workload free model access fits.

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

Two operator-supplied details matter here. The project offers free model access, and it offers a free server option. The operator also describes a free allowance of 10 million tokens; confirm the current terms yourself, because allowances change and I am not quoting a benchmark. I have not measured speed, model quality, or uptime, and I am not claiming any.

The free server option helps in one concrete way. Your laptop keeps its toolchain, and the build-and-test loop runs elsewhere. That is a real convenience when npm install fights your local Node version.

One rule, no exceptions. Do not paste secrets, customer data, or internal credentials into any hosted model. Read your employer's policy before your first prompt.

Limitations and who should skip this

This workflow is honest about what it cannot do.

1. Churn is not risk. A quiet file can still hold the payment path.
2. The script misses dynamic references: reflection, string lookups, config-driven wiring.
3. Test file counts lie in monorepos with shared fixtures.
4. Free tiers change. Re-verify terms on the day you rely on them.
5. A model draft is not a review. You still own every line you commit.

Skip this approach if your repo has no test command at all. Fix that first; a model will only make the chaos faster.

Skip it too if you cannot read the language fluently yet. Learn the file by hand for a week, then add the agent.

Your first-hour checklist

Run the script on two candidate files. Pick the green one. Write the five-line contract. Capture the baseline log. Draft with the model, then rewrite at least one hunk yourself.

That last step is the whole method. You are not shipping model output. You are shipping a change you can explain, test, and revert.

If you run the triage table on your own repo, keep your real thresholds in the PR description. The next junior will thank you for the numbers.