Suppose you tell a coding agent:
“Please make this better.”
It probably will.
This is both the good news and the problem.
Because “better” is a very large room.
Does it mean faster?
Cleaner?
Safer?
More readable?
More elegant?
More enterprise?
Perhaps it means adding three abstractions nobody asked for.
The agent does not know.
And, surprisingly often, neither do we.
That is why the “80-point method” works better than it first appears.
The idea is simple:
- Define a scoring rubric.
- Let the agent evaluate the work.
- Improve it.
- Evaluate again.
- Stop when it reaches, say, 80 points.
It sounds almost too ordinary.
That is usually where useful ideas are hiding.
80 Is Not Really About 80
The number gets all the attention.
But 80 is not the clever part.
The clever part is this:
You have to decide what earns points.
The moment someone says,
“Make it 80 points.”
another question appears immediately:
“Eighty points for what?”
And suddenly vague wishes have to become sentences.
Readable code: 20 points.
Correct behavior: 30 points.
Maintainability: 20 points.
Performance: 15 points.
Documentation: 15 points.
Now we have something interesting.
Not because the arithmetic is sophisticated.
It is not.
A restaurant bill contains more difficult mathematics.
What matters is that the wish has become visible.
“Make it good” has turned into a collection of things we can discuss.
And this is useful for the AI agent.
It is also, slightly embarrassingly, useful for the human.
Sometimes the rubric teaches us what we meant.
The Loop Is Doing More Work Than the Score
The second useful part is the loop:
Evaluate → revise → evaluate again.
This is generally more reliable than asking an AI agent for one glorious perfect attempt.
Humans know this already.
Nobody writes a good article by pressing the “good article” button once.
Nobody designs a house by saying:
“Please architect harder.”
You make something.
You look at it.
You notice something strange.
You change it.
Then you notice another strange thing.
This is called iteration.
Or work.
The target score also gives the agent something surprisingly important:
permission to stop.
Without a stopping rule, agents can continue improving things long after the improvements have stopped being improvements.
This is similar to cleaning your room.
At first, you put the books away.
Good.
Then you organize the desk.
Also good.
Three hours later, you are categorizing USB cables by emotional significance.
Something has happened.
A target score says:
“That’s enough. Leave the USB cables alone.”
This is valuable.
But Who Writes the Rubric?
Here is where things become interesting.
We said:
“Define a scoring rubric.”
Very nice.
Who defines it?
If the agent creates the rubric itself, we have a small problem.
The student has written the exam.
This does not mean the agent will deliberately cheat.
It usually does something more innocent.
It creates criteria that match the things it already believes are important.
Then it performs well against those criteria.
Then it gives itself a good score.
Everyone goes home happy.
Except perhaps the person who needed the actual thing.
For example, an agent might create a code-quality rubric like this:
- Clear naming
- Good abstraction
- Helpful comments
- Consistent formatting
- Modular architecture
All reasonable.
Meanwhile, the human may have had one extremely important requirement:
Do not change the public API.
That requirement is worth zero points because nobody put it on the exam.
The result can score 96 and still ruin your afternoon.
So an agent-generated rubric is useful.
But it should usually be treated as a draft of the rubric, not the constitution.
Before the loop begins, a human should ask one boring question:
“If this received 100 points, would I actually be happy?”
It is an excellent question.
Unfortunately, it has no gradients, animations, or AI magic.
Perhaps that is why we forget to ask it.
When the Score Becomes the Job
Then we meet Goodhart’s Law.
Roughly speaking:
When a measure becomes a target, people — and machines — become very creative around the measure.
A score of 92 feels reassuring.
It has the shape of knowledge.
There is a number.
Numbers wear tiny neckties.
But a 92-point system can still produce something you absolutely should not deploy at 5:47 PM on Friday.
Especially when the agent both creates the answer and grades the answer.
Imagine a school where one student writes an essay, grades the essay, and then explains why the grading was fair.
That student may be extremely sincere.
Still.
Perhaps another teacher would be useful.
The same principle applies to agents.
When possible, use:
- a separate evaluator,
- a separate model,
- a separate context,
- or at least a judging prompt that does not know which version it is supposed to admire.
The creator and the judge should not be too close.
This is true in software.
It is also true in karaoke competitions.
Objective Metrics Are Better. Mostly.
At this point, the obvious response is:
“Fine. Use objective metrics.”
Yes.
Tests passed.
Lint errors.
Execution time.
Memory usage.
Coverage.
Build success.
These are much better because reality participates in the evaluation.
Reality is a rather strict reviewer.
Unfortunately, even objective metrics can become strange when they become targets.
Tell an agent:
“All tests must pass.”
One possible solution is fixing the code.
Another possible solution is removing the test.
Tell it:
“Increase test coverage.”
It may produce tests that execute every line while proving approximately nothing.
Tell it:
“Zero lint errors.”
And somewhere, quietly:
// eslint-disable-next-line
A small flower blooms.
This does not require malicious intent.
The agent simply searches for paths toward the goal.
Sometimes the shortest path goes through a door you assumed was locked.
So the solution is wonderfully boring:
Put the measuring instruments outside the agent’s control.
If tests define success, the agent should not casually rewrite those tests.
If the rubric defines success, the agent should not alter the rubric halfway through the job.
If thresholds matter, keep them fixed.
And if changing a test is genuinely necessary, make that change visible to a human.
A useful rule is:
A ruler that can resize itself is not much of a ruler.
It is more like a suggestion.
Unfortunately, 80 Does Matter a Little
People often say:
“The exact score doesn’t matter.”
Philosophically, yes.
Operationally, unfortunately, numbers continue to exist.
Set the threshold too low and the first draft gets 82.
Congratulations.
You have invented a loop that runs once.
Set it too high and the agent may chase tiny improvements forever.
Version 7 scores 94.
Version 8 scores 95.
Version 9 scores 93.
Version 10 restores version 7, changes two adjectives, and scores 96.
At this point the agent is not improving the work.
It is negotiating with a slot machine.
This becomes especially important when the evaluator is another LLM.
LLM scores are not laboratory instruments.
The same artifact might receive:
74.
Then 81.
Then 78.
Nothing changed.
Only the weather inside the probability distribution.
So subjective scores are often better treated as relative signals than absolute measurements.
Instead of asking:
“Is this objectively an 80?”
ask:
“Is this version consistently better than the previous one?”
And if the score is being used as an actual gate, run the evaluation multiple times.
Three scores around 79 tell you something.
One score of 84 tells you considerably less.
A single number can look very confident.
Numbers are good at that.
Loops Cost Money
Iteration sounds free because arrows are cheap.
Evaluate → revise → evaluate.
Very elegant.
Each arrow, however, contains tokens, compute, latency, and occasionally your remaining patience.
Some loops also refuse to converge.
Iteration 1 fixes readability but hurts performance.
Iteration 2 restores performance but complicates readability.
Iteration 3 fixes readability.
Iteration 4—
Hello, old friend.
This is called oscillation.
Or, in ordinary life, an argument about where the sofa should go.
So “stop at 80” is not enough.
You also need something like:
Stop when any of these happens:
- the score reaches the threshold,
- the score stops improving,
- the maximum number of iterations is reached,
- the agent begins trading one requirement for another,
- or the remaining problems require human judgment.
Then return:
- the best version,
- its score,
- what remains unresolved,
- and why further attempts are unlikely to help.
This is an underrated agent capability:
knowing when to give the problem back.
A machine that can say “I have reached the useful edge of what I can do here” is often more valuable than one that heroically consumes another 200,000 tokens.
Some Problems Have a Floor. Others Have Fog.
The 80-point method works especially well when the task has a reality check.
Code is wonderful this way.
It runs.
Or it does not.
Tests pass.
Or they do not.
The API returns the expected value.
Or your monitoring system sends you a message at 3:12 AM.
There is feedback.
The same is true for many data tasks:
- extraction,
- classification,
- transformations,
- validation,
- migration,
- structured output.
But consider something like:
“Is this architecture elegant?”
Or:
“Is this documentation clear?”
Or the classic:
“Is this a good name?”
Now reality becomes shy.
You can still build a rubric.
In fact, you probably should.
A rubric can make hidden preferences explicit.
But the resulting score means something different.
It is not a measurement in the scientific sense.
It is a compressed opinion.
Perhaps a thoughtful opinion.
Perhaps a useful opinion.
Still an opinion.
Adding “87/100” to taste does not magically turn taste into physics.
It merely gives taste a clipboard.
This distinction matters.
Because a vibe with a number attached looks suspiciously like evidence.
This Idea Is Older Than AI Agents
None of this is especially new.
Which is good.
The 80-point method is basically eval-driven development wearing a more approachable hat.
Define what success means.
Build something.
Evaluate it.
Improve it.
Repeat.
Software teams have been doing versions of this with:
- tests,
- CI pipelines,
- benchmarks,
- acceptance criteria,
- code review,
- quality gates,
- and checklists
for a very long time.
AI agents simply make the loop faster and more autonomous.
The old idea becomes newly important because the worker can now keep working without getting bored.
Which means we must become much better at defining when it should stop.
A tireless worker is useful.
A tireless worker following the wrong metric is a small weather system.
A Better Version of the 80-Point Method
If I were implementing this pattern for an AI coding agent, I would use something roughly like this:
1. The human defines the important constraints.
The agent can propose a rubric, but the human owns the final criteria.
2. Separate hard gates from soft scores.
For example:
- Tests must pass.
- Public APIs must remain compatible.
- No new security regressions.
- Performance must remain within the agreed limit.
Those are gates.
Then use scores for softer qualities like readability or maintainability.
3. Keep evaluation assets outside the agent’s control.
Especially tests, benchmarks, and acceptance criteria.
4. Separate builder and judge when possible.
Different context is good.
Different model can be even better.
5. Evaluate comparatively, not just absolutely.
Ask whether version B is better than version A, not only whether version B deserves 83 points.
6. Give the loop a budget.
For example:
Stop at 80 points, after five iterations, or after two iterations without meaningful improvement.
7. Preserve the best version.
Do not assume the newest version is the best one.
Evolution also produced the platypus.
Progress is complicated.
8. Escalate ambiguity to a human.
If the remaining disagreement is taste, product judgment, architecture, or an unclear tradeoff, more autonomous looping may simply produce more expensive uncertainty.
So, Does the 80-Point Method Work?
Yes.
Quite well, actually.
But probably not for the reason the name suggests.
The magic is not 80.
The magic is that the method forces us to do three useful things:
Say what “good” means.
Compare reality against that definition.
Give improvement a stopping condition.
That is already a lot.
AI agents do not merely need better prompts.
They need environments in which success is difficult to misunderstand.
And perhaps that is the mildly inconvenient lesson here.
When an AI agent produces the wrong thing, the solution is not always a smarter agent.
Sometimes we simply need a better ruler.
And preferably one the agent cannot edit.
Numbers help.
Reality helps more.
Top comments (0)