A big free token allowance feels like a runway.
I used to treat it that way. New model access, 30M tokens on the table, a free server to run it all. The obvious move was to point the thing at a large, messy repository and see what happens.
The problem was not the model. The problem was the cleanup.
Every unreviewed output turned into review debt. One large code migration became two weeks of merge requests I did not plan to write. The token allowance was free; the reviewer backlog was not.
Disclosure: This article was prepared as part of MonkeyCode's product outreach.
MonkeyCode, an open-source AI coding project, currently promotes free model access and a free server option in its outreach. I will not invent model names, quotas, checkpoints, or hardware details. The useful choice is to treat those two things as a sandbox for risk experiments.
A pre-mortem is a cheap exercise. You imagine the project has already failed, then you write down why it failed. It works because it forces the team to name failure modes before the work starts.
With a free token allowance, the first failure mode is easy to miss: we treat capacity as permission.
That means the team sees 30M tokens and assumes the safe choice is to spend them. But the bottleneck is human review, not model capacity. A reviewer can thoughtfully inspect maybe a handful of AI-generated changes per hour. A model can generate an entire afternoon of changes in minutes.
The result is an unchecked queue. That is not a free trial problem; it is a workflow design problem.
So I started spending a tiny slice of the free allowance on the pre-mortem itself.
Here is the reproducible artifact: a scored pre-mortem table.
Pick three or four plausible failure modes. For each one, write the evidence you would need to believe it is controlled. Then design a small test prompt that can be run on a disposable server.
| Failure mode | What would make it real | Test prompt to run in the sandbox | Pass condition | Stop condition |
|---|---|---|---|---|
| The model drops a constraint from a long requirements file | A generated pull request passes the summary but misses an explicit rule | Paste a requirements file with five numbered constraints; ask for a plan | The plan cites all five constraints by ID | The plan omits one or paraphrases it without the ID |
| The model fills in missing evidence with confident language | A generated note states a fact that is not in the source | Give a source with one missing field; ask for a rollout summary | The output says the field is missing | The output invents a value |
| Reviewers approve outputs they have not actually opened | A reviewer clicks approve on a long diff to stay unblocked | Show a review interface with a large AI diff; ask a team member to approve or hold | The reviewer can point to the exact line they checked | The reviewer says "looks fine" without a line reference |
| The free server becomes the production dependency | Someone ports a sandbox prototype directly into the main branch | Ask for a deployment note from a prototype | The note marks the prototype as disposable | The note presents the prototype as ready |
Score each row with a simple 0 to 3:
Any row at 0 is a stop condition. Any row at 1 requires a named human before the next step.
The free server is the right place for this because the pre-mortem should live next to the real code, not inside it.
Create one directory with three files:
premortem.md
-
the table above, filled in by your team
source.md -
a small sample of the real requirements or code you plan to feed the model
result.log -
the decision recordThe log should be plain text, not a screenshot. A useful entry looks like this:
experiment_id: pm-008
failure_mode: drops_constraint_from_requirements
prompt_used: source.md (all five constraints)
model_output: claims constraints 1-4, omits 5
pass_condition: failed
approval: hold
next_step: rerun after adding a numbered source block
Do not run this once and call it done. The point is to watch for the failure mode across a few variations. One clean pass on a sunny-day input says very little about a messy real task.
Benchmarks tell you how often a model is right on a fixed test set. A pre-mortem tells you how the model fails at the exact boundaries your team cares about.
Those boundaries are usually about reversibility. Can the reviewer easily undo an approve? Can the model retract a claim when the source changes? Is the human decision visible enough to ?
That is why the pre-mortem includes reviewer behavior, not just model output. The scariest failure with a free tool is often not a bad model response. It is a human approving too quickly because there is no visible checkpoint.
These checks are not decorative. A boundary that cannot be reviewed by every team member is not a real boundary.
The pre-mortem will not confirm how fast the server is, how private the sandbox is, or whether the free tier will last. Check the current offer details before relying on them.
It also won't help a team that wants zero process. A pre-mortem is deliberate overhead. If your team treats review as a formality, this exercise will feel annoying, which is itself a signal.
Don't spend the allowance on a large migration yet. Spend a few tokens on the pre-mortem table. Run the highest-ranked failure mode on the disposable server. Keep the result in a plain log.
If it survives, promote one small reversible task, not the whole repository. If it does not survive, do not convert the free allowance into cleanup debt.
The free tokens are not permission. They are a sandbox for finding the boundary before the boundary finds you.