Managing AI's wobble

The last two posts covered two phenomena.

The first was:

why does AI change its answer the moment you question it?

The second was:

why does AI’s output sometimes suddenly improve once you get angry?

This post pulls back to a more practical question:

given that AI changes its answers, accommodates and overcorrects, how should we actually work with it?

My judgment is:

AI’s wavering can’t be completely eliminated, but it can be managed.

Because AI naturally keeps adjusting its output according to context, feedback, goals and constraints.

The problem isn’t that it changes.

The problem is:

• why does it change?
• based on what?
• which parts are allowed to change?
• which parts shouldn’t?
• when should it stop?

If none of this is clear, AI becomes a very hard-working collaborator with no boundaries.

• You question it, it changes.
• You get angry, it changes.
• You rephrase, it changes.
• You say self-review, it keeps finding problems.

It looks very cooperative.

But you may end up getting lost together.

When AI gets messier with every revision, it usually isn’t because it can’t do it

Many people using AI on open tasks go through a very familiar loop.

The first version is too generic. The second is too long. The third is too stiff. The fourth is too conversational. The fifth finally has structure, but no feeling.

It looks like constant improvement.

Actually it’s swinging between different standards.

This usually isn’t because AI is completely incapable.

It’s because the collaboration is missing a few things:

• a clear goal;
• fixed evaluation criteria;
• a clear statement of what not to do;
• limits on the scope of each review;
• a record of the current decisions;
• a rule for when to stop.

AI is very good at continuing to generate.

But it doesn’t naturally know when to stop.

AI is very good at responding to feedback.

But it doesn’t naturally know which feedback should change the backbone and which is just a local preference.

AI is very good at producing new versions.

But it doesn’t naturally know which parts of the last version should actually be kept.

So managing AI’s wavering doesn’t come down to one line:

“Don’t just accommodate me.”

That’s too broad.

What really helps is giving it a clear set of boundaries for working together.

First: define what “good” means

Open tasks waver most easily because “good” itself is unclear.

Say you ask AI to write a title.

You say:

“Write me a few better titles.”

But what does better mean?

• Clearer?
• More shareable?
• More human?
• More professional?
• Better for RedNote?
• Better for a website?
• Better for investors?
• Better at converting?

Any of these could be “better.”

But they don’t point the same way.

• Clearer may become ordinary.
• More shareable may become clickbait.
• More professional may become templated.
• More human may become loose.

If you don’t define the criteria at the start, every later revision can only be a guess based on your feedback.

• You say “too ordinary,” and it gets punchier.
• You say “too clickbaity,” and it gets more restrained.
• You say “sounds too much like AI,” and it gets conversational.
• You say “not professional enough,” and it starts adding concepts.

That isn’t getting better and better.

That’s the evaluation criteria drifting the whole time.

So for open tasks, the first step shouldn’t be output.

The first step should be to ask:

by what standard are we judging good and bad this time?

You can say:

“Before we start, please define the evaluation criteria for this task and rank them by priority. If the criteria conflict, say which one comes first and which one gets sacrificed.”

For an article, for example:

This time, explaining the mechanism matters more than emotional resonance. Clear structure matters more than quotable lines. Generalizing matters more than just telling a personal story.

For a résumé:

This time, fit with the role matters more than a complete history. Credibility matters more than packaging everything. Concrete evidence matters more than abstract skill words.

For a product plan:

This time, validating the need matters more than a complete feature set. The user journey matters more than technical showing off. Identifying risks matters more than making the plan look pretty.

Once the criteria are clear, AI will still revise.

But it no longer revises at random.

It revises within the same frame of evaluation.

Second: before giving feedback, judge the level of the problem

A lot of the time, our feedback to AI is too crude.

“That’s wrong.” “Not good.” “Polish it a bit more.” “Are you sure?” “This version doesn’t work.”

All of these express dissatisfaction.

But none tells AI where exactly the problem is.

• Is a fact wrong?
• Is the logic wrong?
• Did the goal change?
• Was a constraint not followed?
• Is the wording unnatural?
• Is the output format unsuitable?
• Or do you just prefer a different direction?

Each of these is fixed in a completely different way.

• If a fact is wrong, verify it.
• If the logic is wrong, reason it through again.
• If the goal changed, change the criteria.
• If a constraint wasn’t followed, fix the boundary.
• Only if it’s a wording problem does it need polishing.
• If it’s just taste, the main judgment doesn’t necessarily need overturning.

So when you want to challenge AI, don’t let it change things right away.

First have it judge the level of the feedback.

You can say:

“I’m challenging your output. Please don’t revise it right away. First judge which kind of feedback this is:

• a factual error;
• a logic problem;
• a change of goal;
• a change in evaluation criteria;
• a constraint not followed;
• a wording problem;
• a matter of taste;
• missing information.

Once you’ve judged that, say whether the original answer should be kept, partly revised, or completely overturned.”

The point of this step is:

to stop AI from admitting fault the moment it hears dissatisfaction.

And to stop it treating a local problem as total failure.

A lot of the time, we don’t want it to hand over a new version right away.

We want it to first judge:

what this feedback actually changed.

Third: tell AI what you don’t want

We’re used to telling AI:

what we want.

We’re much less used to telling it:

what we don’t want.

But “what we don’t want” is very important.

Because in open tasks, there are too many wrong directions.

You say: “Make it more professional.”

AI may pile on jargon.

You say: “Make it more natural.”

AI may get loose.

You say: “Make the structure clearer.”

AI may just add lots of subheadings.

You say: “Rewrite it.”

AI may delete the good parts too.

So stating the goal isn’t enough.

You also need negative constraints.

That is, telling AI explicitly:

which directions not to take.

For example:

• don’t make it longer.
• don’t just polish.
• don’t add more concepts.
• don’t overturn everything.
• don’t sacrifice readability to sound professional.
• don’t stuff all my feedback in.
• don’t turn a local problem into a full rewrite.

That cuts out a lot of careless revision.

Because it isn’t that AI doesn’t know how to try.

It’s that it doesn’t know which directions of effort are wrong.

The job of negative constraints is to close off the wrong roads first.

For code, you can say:

• don’t refactor the whole project to fix a bug.
• don’t touch unrelated files.
• don’t add new dependencies.
• don’t optimize performance; make the tests pass first.

For a product plan, you can say:

• don’t start with a complete feature list.
• don’t assume users already have a strong need.
• don’t put monetization before validating the need.
• don’t use a grand, all-encompassing roadmap to hide that the core assumptions haven’t been validated.

For research, you can say:

• don’t just summarize opinions.
• don’t mix old and new sources.
• don’t write unsourced judgments as fact.
• don’t give only conclusions without stating the level of evidence.

A lot of the time, saying clearly “what not to do” is far more effective than saying “make it a bit better.”

Fourth: limit the scope of review

AI self-review easily gets messier the more it revises.

Because as long as you ask it to review, it can almost always find problems.

• It could be shorter.
• It could be deeper.
• It could be more natural.
• It could be more professional.
• It could be more structured.
• It could have more examples.
• It could sound more human.

Every one of these may be true.

But that doesn’t mean all of them should be changed.

Many self-reviews fail not because AI didn’t find the problems.

But because it found too many and didn’t rank them.

And then the next version stuffs every suggestion in.

That makes the content fuller, but not necessarily better.

So don’t just ask:

“Do a self-review.”

That’s too broad.

Better ways to ask:

“Review only the structure; don’t change the tone.” “Check only facts and logic; don’t polish.” “Only judge whether it fits the target users; don’t rewrite.” “Find only the 2 most important problems; don’t list a pile.” “If there are no serious problems, say clearly that nothing needs to change.”

That last one is important.

Because AI easily assumes:

since you asked me to review, I must find problems.

But a good review doesn’t necessarily have to lead to changes.

A good review judges:

• what the most important problem is now;
• whether it’s worth fixing;
• whether fixing it would break something else;
• how big the risk is if it isn’t fixed.

Review isn’t listing problems.

Review is ranking and choosing.

• If the structure is broken, don’t fix the tone first.
• If the goal is unclear, don’t add examples first.
• If the facts aren’t verified, don’t refine the wording first.
• If it’s only a local problem, don’t overturn everything.

Limiting the scope of review is, at heart, stopping AI from pretending to “do better” by “doing more.”

Fifth: keep a decision log

There’s another reason AI wavers easily:

it doesn’t necessarily know which version to go by now.

Today you say A. Tomorrow you say B. In between you say “actually A has a point too.” It may treat all of these as valid information.

And when it answers, it grabs a direction at random.

This is especially obvious in long tasks.

Say you’re building a product.

At first you say the target users are indie developers. Later you think it might be people changing careers. Then you realize these two directions shouldn’t be mixed. So you decide: validate indie developers only, for now.

If that process isn’t recorded, AI can easily pick the old judgment back up later.

It looks like a good memory.

Actually it’s a poor sense of versions.

So for important tasks, it’s best to have a simple decision log.

It doesn’t need to be complicated.

It can be just a few lines:

• Current goal:
• Current stage:
• Confirmed judgments:
• Directions abandoned:
• Questions to validate:
• Next step:
• Don’t discuss again:

The point of this file isn’t to make AI remember more.

It’s to let it know:

which version to go by now.

Many AI collaborations fail not because it completely forgot.

But because it mixes old assumptions, new judgments, passing emotions and temporary preferences together.

A decision log helps it build a sense of versions.

Sixth: set a stopping rule

Open tasks most easily get stuck at the last step:

endless revision.

• An article can always be better.
• A title can always be rethought.
• A product plan can always add more risks.
• A piece of code can always be optimized further.
• A résumé can always be polished more.

Without a stopping rule, AI will keep revising with you forever.

Because it won’t naturally say:

that’s enough.

So before starting, it’s best to be clear about:

• the maximum number of review rounds.
• what problems each round handles.
• under what conditions it must stop.
• under what conditions overturning is allowed.
• under what conditions only local fixes are made.

For example:

“At most two rounds of revision. The first round only changes structure. The second only changes wording. Unless you find a factual error or a logical hole, don’t overturn the main direction.”

Or:

“If the current version already meets 80% of the standard, don’t keep chasing perfection. Just point out what must be fixed before publishing.”

A stopping rule isn’t laziness.

It’s keeping you and AI from falling into endless optimization together.

Especially for products, content, job hunting and learning, real feedback can’t come only from inside AI.

In the end you still have to publish. To test. To apply. To let users see it. To get results from the real world.

AI’s review can’t replace outside feedback.

So when it’s time to stop, stop.

A reusable collaboration protocol

If I had to compress all of the above into a general version, I’d write:

“Before we start, please help me make clear:

what the goal of this task is;

what the success criteria are, ranked by priority;

which directions not to take;

which constraints must be followed;

if I challenge you later, first judge whether my feedback is about facts, logic, the goal, the criteria, a constraint, wording, or preference;

in each review, find only the 2 most important problems;

unless the goal, the facts or a key criterion changes, don’t overturn everything;

if it has already reached a usable standard, explicitly recommend stopping instead of optimizing further.”

This isn’t an all-purpose prompt.

It’s more like a collaboration protocol.

It reminds AI:

• don’t just generate.
• settle the goal first.
• don’t just accommodate.
• judge the feedback first.
• don’t just revise.
• confirm what to change first.
• don’t optimize endlessly.
• stop when it’s time to stop.

Finally

So how do you manage AI’s wavering?

• Not by being harsher.
• Not by writing more prompts.
• And not by asking “are you sure?” again and again.

But by making the collaboration clearer.

• First define what “good” means.
• Then say what you don’t want.
• Sort feedback into levels.
• Limit the scope of review.
• Keep a decision log for long tasks.
• Set a stopping rule for open tasks.

AI’s wavering often isn’t because it has no ability at all.

It’s because it’s too willing to align with you.

If you don’t have stable standards yourself, it will drift along with you.

So better AI collaboration isn’t turning AI into someone forever firm.

It’s letting people and AI share a clear system of judgment.

What the goal is. What the criteria are. What the constraints are. What the current version is. When overturning is allowed. When to stop.

Once that’s clear, AI will still adjust.

But it won’t adjust at random.

It doesn’t stop changing.

It starts changing for reasons.

That’s the key to managing AI’s wavering.