Changing the method halfway leaves you with two batches rather than one

The improvement always turns up at item forty

It is a reliable pattern. You are a third of the way through a run of two hundred and something occurs to you: a better instruction, a cleaner structure, a field you should have been capturing, a format that would save the next person an hour. It is a genuine improvement and it is arriving at the worst possible moment.

The temptation is to switch immediately, because the improvement is obvious and the remaining work is the majority. What that produces is a set in which the first third was made one way and the rest another, and the difference is often invisible in any single item.

The cost is not in the switching. It is in the seam, and seams in a body of output are expensive in ways that are hard to see while you are producing it.

A mixed set is worse than a consistently mediocre one

A collection produced by two methods is difficult to review, because the reviewer has to hold two standards. It is difficult to describe, because any statement about how it was made needs a qualification. And it is difficult to use downstream, since anything consuming the output has to tolerate both shapes.

The mixed set also defeats comparison. If you later want to know whether the change helped, you cannot tell, because the two halves differ in method and in everything else that drifted along the way.

A uniform set produced by the inferior method has none of these problems. It is worse in one dimension and coherent, which for most purposes is the better position to be in.

Three honest options, and the middle one is usually right

The first option is to finish as you started and apply the improvement to the next run. This is right when the improvement is marginal, the set is nearly done, or the output is a body of work that will be seen together.

The second is to switch and go back, applying the new method to what has already been produced. This costs the rework and it preserves consistency, and it is usually the right answer when the improvement is substantial and the completed portion is small enough to redo.

The third is to stop, decide properly, and restart the whole thing. That sounds extravagant and it is occasionally correct, particularly when the realisation is not really about method but about the specification — you have discovered that the wrong thing is being produced, and no amount of consistency rescues that.

What is almost never right is switching and leaving the earlier material as it is, which is what happens by default when nobody frames the decision at all.

Make the switching point a decision with a record

If you do switch mid-run, mark it. Record which items were produced under which method and when the change occurred, in the output itself if the format allows and in a note beside the process if it does not.

This costs a line and it saves the conversation six months later when somebody notices that items one to fifty behave differently and cannot find out why. It also makes a partial rework possible, since you can identify exactly which items would need redoing.

The same record turns an accident into evidence. Two methods applied to comparable material, with the boundary known, is the closest thing to a comparison you will get from a live run, provided the boundary was recorded.

Pilots reduce this and do not remove it

Running a small sample first exists precisely to surface these realisations while nothing has been produced, and it works often enough to be worth doing every time. It does not catch everything, because some problems only appear at volume, at the awkward items, or after the tenth time you have looked at the output.

So build a decision point into long runs rather than relying on the pilot alone. A deliberate pause after the first fifty, with a question about whether the method is still the right one, is cheaper than an improvement that arrives unbidden at item one hundred and forty.

And accept that some improvements will simply be logged rather than applied. A note saying what you would do differently next time is a real output of a run, and it is more useful than a set of results nobody can describe.