Use a deterministic script when the task has a fixed shape, a verifiable output, and nobody plans to reread the result; reach for an LLM agent only when the inputs are unstructured and a human stays in the review loop. Kyle Kingsbury's new Jepsen writeup on ParticleDB is the clearest practitioner argument I have seen for keeping that line sharp.
In a quote collected by Simon Willison, Kingsbury warns that LLM-generated prose makes it trivial to counterfeit the signals engineers once used to judge software maturity: polished docs, confident commit messages, plausible test descriptions. The result is erosion of trust in documentation, in software, and in the organizations producing them.
What this means for small-business automation
Apply the rule node by node in a pipeline. Pulling an invoice number from a PDF, posting a payload to an API, moving rows between a CRM and a spreadsheet - that is a script, and the output should be checkable byte for byte. Reading a 300-page tender for hidden penalties, classifying a customer email, summarizing a court ruling - that is where an LLM earns its place, and only when the pipeline logs its reasoning and shows a human the diff. In a tender analysis pipeline I built, OCR, chunking and routing are deterministic code; the model only answers narrow questions, and every risk flag links back to the source paragraph for review.
Why it matters: Treat the LLM as the fuzzy part of your stack, not the whole stack. The more an automation leans on a model's confident tone instead of verifiable code, the harder it gets for anyone, including you, to notice when it has quietly broken.
Source: Simon Willison