The Prompt Commit: Score, Rows, Name, Undo Under Every Prompt Change

Lesson 08 of Becoming Forward Deployed Engineer landed this morning with the right principle and, in the part I can read, a field list that is two fields short. This is an Agent Drop: the four lines, and where each one came from.

The short version

Lesson 08 opens at an insurer where the prompt lives in answerer.py as a triple-quoted string; someone shortens it on a Thursday to save tokens, the PR shows four lines removed and reads fine, and two weeks later the adjusters say the answers got worse with nothing to connect the two. Its principle, in the public part: a prompt is code with nothing checking it, so the eval score is a field of the version, written by the same function that ran the eval. The subtitle carries the number: one of four wordings answers seven fewer questions out of forty-two. Score is the right first field. Two more are missing. The rows, because a classifier I shipped scored 89% on held-out data and 61% in production within six weeks with the same prompt. The name, because my own rule library has 51 commits since March 30, at least 21 with an agent co-author line and 30 I cannot attribute. The drop is four lines under every prompt change: Score, Rows, Name, Undo. In the FDE codebase contract the customer layer changes the same day with no review on the condition that it is versioned and diffs; the four lines are what the diff carries.

The Thursday edit

The lesson is paid past its preview, so this is what the preview says and nothing more.

At Meridian Mutual the prompt lives in a Python file as a triple-quoted string. Someone shortens it on a Thursday to save tokens. The pull request shows four lines removed and reads fine. Two weeks later the adjusters say the answers got worse, and there's no way to connect those two facts. The author's line for why: a prompt is code with nothing checking it. No compiler, no type checker, no signature to break. The only thing that catches a bad edit is a measurement you ran on purpose, attached to the exact text you ran it on.

Then the design, stated as the failure it's built to avoid. Version the text without the score, and the history tells you what changed and never whether it helped. So the score is a field of the version, written by the same function that ran the eval.

The subtitle is the number: one of the four wordings answers seven fewer questions out of forty-two, and nothing in the code review would have told you which.

That's the right first field, and I'd put it first. The two fields it's missing I learned about by paying for them.

Field two: the rows

The Threshold Card has the classifier. It scored 89% on held-out data. Six weeks in production, 61%. Same prompt. The same score field would have said 89 the whole time, because the thing that moved wasn't the text, it was the rows. Production traffic drifted away from the set the score was computed on, and a score with no row set attached is a number with no date on it.

So the version carries the rows it was scored on. Not the rows themselves, the pointer: which set, how many, dated. When the adjusters complain two weeks later, the first question is whether the rows that scored the Thursday edit still look like the questions the adjusters are asking. Half the time the prompt is fine and the rows are stale, and that's a different fix.

Field three: the name

The Thursday edit in the lesson had a person behind it. Most prompt edits in a repo an agent maintains don't.

Who Writes Your Agent's Rules? I Counted the Commits. is where I counted mine. Eleven files, 2,322 lines, 51 commits since March 30. At least 21 of those commits carry an agent co-author line. The other 30 I can't attribute to a person or an agent at all. Twenty-three lines in the library carry my name and a date; the rest were written by something and read by nobody in particular.

An unattributed prompt change is the Thursday edit with no Thursday. So the version says who changed it, person or agent, and separately who read the diff. Those are different names more often than you'd think, and the second one is the one you call.

The drop

Four lines under every prompt change. In the commit message if the prompt is in git, in the registry row if you have a registry, in both if your team reads both. Plain text, no tooling required to start.

Score: the eval result on this exact text, written by the run, not typed. Rows: the row set it ran on, count and date. Name: who changed it, person or agent, and who read the diff. Undo: the version this rolls back to, and who can pull it.

The fourth line is the one nobody argues with and nobody writes. The Stop Rule has what a missing undo costs: an autonomous pricing agent with no re-run drifted 14% under benchmark in five weeks and took two quarters to recover. A prompt edit nobody re-scored is the same drift with text instead of a loop, and the undo line is what makes Friday morning a thirty-second decision instead of a meeting.

Why this is an FDE post

Same Model, Twice the Bill: The FDE Codebase Contract draws the line through the codebase. The customer layer, prompts, rules, thresholds, connector settings, and the customer's eval rows, belongs to the forward deployed engineer. Changed the same day, no review. Two conditions: it's versioned, and it diffs against the shipped default in one command.

Lesson 08 is the argument for the first condition, with a better example than mine. The four lines are what the second condition has to carry. A diff that says "four lines removed" is the Thursday edit; a diff that says four lines removed, then the score against a dated row set, the name of whatever changed it and the person who read it, and the version it rolls back to, is a change an FDE can make on a Tuesday at a customer site without anyone in engineering needing to review it. That's the deal, and the deal only holds if the diff is honest.

This is a standalone post alongside The FDE Transition. The closest part is the codebase contract.

Under AI Product Management the claim is that AI collapsed the cost of the parts PMs were trained for and left the parts nobody trained for. Writing the prompt got cheap. Knowing whether the new one is better, on which rows, changed by whom, and how to get back, is the part nobody trained for, and it's four lines.

This week: open the last five prompt changes in your repo or registry. For each one, try to fill in the four lines from what's already recorded. Count how many you can complete. Then add the block to the commit template so the next five are complete by construction.

Related answer: What should a prompt commit record besides the text?

Sources: "Lesson 08: Prompts Belong In Version Control, Not In A String," Becoming Forward Deployed Engineer (Substack, author unnamed), October 26, 2026; paid, and only the public preview (the problem section and the opening of the registry section) is cited, with nothing past the paywall claimed. Falk Gottlob, "Same Model, Twice the Bill: The FDE Codebase Contract," "The Threshold Card: Tune the Judge Before You Trust the Score, and Date the Re-Tune," "Who Writes Your Agent's Rules? I Counted the Commits.," and "The Stop Rule" (September 29, 2026).