The step you have specified perfectly should probably be code

Refinement has a destination

Prompts for a repeated task tend to get longer over time. Each surprise adds a clause, each edge case adds a sentence, and after a few months the instruction specifies the input format, the output format, the handling of every exception and the exact transformation to apply.

At that point something has changed that is easy to miss. There is no judgement left in the step. Every decision has been made in advance and written down, which is the definition of a procedure, and a procedure executed probabilistically is a strange choice when it could be executed exactly.

The tell is that the prompt reads like a specification rather than a request. If you could hand it to a competent programmer and they would not need to ask you anything, you have already written the requirements document.

What code does better, and it is not subtle

A script that reformats dates does it identically every time, in milliseconds, at no cost per item, with no network involved, and it fails loudly when the input isn’t what it expected. None of those five properties are available from a language tool, and each of them matters more as volume grows.

Reliability is the largest difference. A step that works ninety-nine times in a hundred sounds excellent until it sits in a chain of five such steps running daily, at which point failures are a weekly event and each one has to be found by a person.

The other underrated property is that code can be read. Six months later, the question of what this step does has an exact answer that doesn’t depend on running it and inspecting the output, which is the only way to answer that question about a prompt.

The parts that genuinely need judgement stay

This isn’t an argument against the tool, it is an argument about which steps belong to which. Almost any real workflow contains both kinds of step, and the mistake is doing the whole thing in one register because that is how it was prototyped.

The steps that should remain are the ones where the input is genuinely unpredictable, where language has to be understood rather than matched, or where the output is prose. Classifying free-text complaints, extracting a field from an inconsistent document, drafting a summary — these do not reduce to rules, which is exactly why they were hard before.

The steps that should move are formatting, validation, arithmetic, sorting, filtering, deduplication, file handling, and any transformation with one correct answer. In practice these are a surprising share of what a long prompt is doing, and separating them shortens the prompt as well as improving it.

A mixed pipeline is the normal end state, not a compromise. Code moves the material around and checks it; the language step does the one thing that needed comprehension.

When it is not worth converting

Plenty of steps should stay as they are. A task run monthly by one person, taking two minutes, does not justify writing and maintaining a script, and the maintenance is the part people forget when they estimate this.

Nor is it worth converting anything still changing. A step whose specification has been rewritten twice this month is not settled, and freezing it into code means editing code every time it moves. Wait until it has been stable for a while, which is also when the specification is trustworthy enough to translate.

And the ability to write and maintain the script has to exist. A script nobody in the team can modify is a liability of a different kind, and there are situations where a well-documented prompt that three people understand is genuinely the better engineering decision.

Convert one step, and keep the old one for comparison

The safe way to move a step is to run both for a period and compare the outputs. Where they agree, the conversion is sound; where they differ, one of them is wrong and the disagreement usually exposes a case the original specification handled by accident.

This is also how the undocumented behaviour gets discovered. Long prompts accumulate implicit conventions that nobody wrote down, and those only become visible when something exact refuses to reproduce them.

Do it one step at a time. A pipeline converted wholesale in an afternoon is a pipeline whose failures all appear at once, with no way to tell which conversion caused which.