Thrashing is what happens when more energy produces only the illusion of greater forward momentum: the output rises, the sense of progress rises with it, and yet what has mostly increased is noise — for the same signal, or only slightly more.
For a growing list of tasks, AI tooling is now faster than people by orders of magnitude — not a little quicker, but a different order of speed. Drafting, analysis, code, configuration, first-pass design: work that took a skilled person days arrives in seconds. The demonstrations are genuinely impressive, and the impression they leave is that the hard part is over.
It is usually not. There is a gap between speed at the keyboard and value in the business, and a great many AI implementations fall into it.
The term comes from computing, where a system can spend so much of its capacity on overhead — shuffling things in and out, managing itself — that useful throughput collapses. It looks busy. It delivers little. A surprising number of AI initiatives thrash in exactly this way: the first output is astonishing, and the business outcome arrives slowly, expensively, or not at all. Three constraints explain most of it. None of them is about the model. All of them are about what happens after the model has done its impressive part.
Constraint 1 — The cost of closing the gap
AI produces a deliverable that is ninety per cent there in a heartbeat. Then comes the work nobody demonstrated: keeping the ninety per cent that is correct, and closing the ten per cent that is not.
That last tenth is rarely the easy tenth. It is the edge cases, the integration with what you already run, the rules that are specific to your business and written down nowhere. AI is excellent at the plausible draft and unreliable at the precise finish — and the finish is the part that has to be exactly right before anyone can rely on it.
The damage here is as much about expectation as about effort. A leader watched something appear, at a speed that was genuinely remarkable, that looked nearly done. When "nearly there" then takes weeks to become "actually there", the speed that created the excitement becomes the source of the disappointment. The technology over-promised in the first ten seconds, and the team spends the next ten weeks paying that promise down. Disillusionment is the predictable result, and it is unfair to everyone involved.
Constraint 2 — Repeatability
Suppose you get there once. The gap is closed, by one good prompt or by patient iteration or by AI and a person working together, and the result is sound. Now you move to the next project, which is similar to the last.
You have learned from the first. The AI has not — unless it has been deliberately told what your first success was and what about it should be reused. Left to itself, it produces another sound result that is structured and presented differently from the first. The two are functionally equivalent and visibly unrelated: distant cousins, when what the business needed was siblings with an obvious, shared heritage.
This is more than an aesthetic complaint. Outputs that do not share a structure cannot be maintained, audited, or extended as a family. Every one becomes its own special case. The problem is more tractable where standards already exist — but only if each new generation is actually made aware of those standards and is held to them, which does not happen by default. And AI's real gift is taking organisations into work they could not previously afford to do at all, where no standard exists yet. There, the task is two-fold: establish the standard on the first pass, then make every subsequent pass repeat it.
Constraint 3 — Rollout
The first two constraints are about the work. The third is about the organisation.
Once you know what "right" looks like for your particular context, how do you get everyone producing it? A standard that lives in one team's heads, or in one talented individual's prompts, does not scale. Spread AI across enough roles and people without a mechanism to broadcast the right way of working, and you get the opposite of a standard: every person bringing their own, each defensible in isolation, none of them consistent with the others. Bring-your-own-standard is not a standard. It is chaos with good intentions.
What is needed is a way to roll out what is right for your context to every role and every individual operating in the same information pipeline — and to do it again, automatically, every time "right" changes.
How the Predictiv Development Platform answers this
These are not abstract worries. They are the day-to-day problems we set out to solve in building the Predictiv Development Platform — the system we use to produce the platform itself. The answers are deliberately unglamorous, because the constraints are not solved by a cleverer model but by discipline that the tooling enforces rather than hopes for.
Close the gap with tooling, not with chasing. We divide the work by what should be judged once and what should be derived the same way forever. Judgement — what the business actually needs — is for people and AI together. The mechanical parts — the structure, the wiring, the repetitive scaffolding — are produced by deterministic tools, so they are never re-derived by hand or re-guessed by an AI that might guess differently this time. Around the whole thing sit machine-checkable gates: a piece of work is not "done" because someone is impressed by it, but because it has passed the checks that define done for that kind of work. The last ten per cent stops being a thing someone has to remember to notice. It becomes visible, and closeable, by design.
Make the second output a sibling of the first. When we establish a standard, we capture it once and carry it into every future generation rather than trusting it to memory. Catalogued patterns record how a given kind of thing is built here; a standards ledger records each standard and binds it to the work it governs; and the knowledge an AI needs is loaded into it at the moment it generates, so the canonical way is the path of least resistance rather than a document someone might consult. When something needs to change, we fix the generator, not the individual output — so the whole family moves together and stays coherent. The next project inherits the heritage of the last one automatically. Siblings, not cousins.
Roll out the standard structurally, so nobody has to opt in. Our standards are not advisory PDFs that rely on goodwill. They are enforced by hard gates — at the moment work is committed and while it runs — that cannot quietly be bypassed. The framework that carries them is treated as a product: it is pinned and distributed, individuals and teams propose improvements to it, those are reviewed and merged centrally, and the canonical version is simply what everyone runs. Change a rule in one place and every person in the pipeline inherits it on their next piece of work, without a memo, a training session, or a plea for compliance. There is no bring-your-own-standard, because the standard is part of the machinery rather than a matter of individual virtue.
Where this leaves the speed
The speed is real, and it is not the point. The order-of-magnitude advantage at the keyboard is available to everyone now, which means it differentiates no one for long. The advantage that lasts belongs to the organisations that can turn a fast, impressive draft into a capability that is dependable, repeatable across projects, and adopted consistently by everyone who touches it.
That is an engineering and governance problem, not a model problem — and it is precisely the problem the Predictiv Development Platform was built to solve. If your AI initiatives are producing dazzling demonstrations and disappointing rollouts, the gap between the two is worth a conversation.