What happens if you don't try to speed up an AI workflow one more time, but rebuild it from scratch instead? Over the past few weeks at Oneminded, that's exactly what we did with our own AI setup.
By Anthony Raaijmakers
What happens if you don't try to speed up an AI workflow one more time, but rebuild it from scratch instead? Over the past few weeks at Oneminded, that's exactly what we did with our own AI setup. Not by prompting harder or bolting on another model, but by building smarter: more context per task, clear boundaries on what a model may and may not assume, and a steadier rhythm in how everything gets executed. This article is about what we concretely changed, and why that made more difference than a better model would have.
This matters because many teams treat an AI tool as something you configure once and then let run. In practice, the real gain sits in the layer around it: how a task gets briefed, what happens when something goes wrong, and how consistent that process stays when you repeat it a hundred times.
Concretely, for us that meant: defining per task which assumptions a model may and may not make, instead of leaving that implicit. Where we used to rely on a well-crafted prompt and hope for the best, we now define per task what a model is allowed to decide on its own and what always has to go back to a human. That sounds like a small difference, but it changes the entire way you trace an error: you immediately know whether something went wrong because of an unclear instruction or because a model overstepped its bounds.
We also gave cronjobs and health checks names you understand at a glance, instead of generic labels no one can place after a month. Every loop we rewrote made the whole a little more repeatable and easier to test, and that compounds: a process you can test is also a process you can run with confidence on an ordinary workday, without anyone having to babysit it.
What stuck with me most from this process is that automation only works if the human check is set up well, and that iterating isn't a side task, it's the actual work. A model only becomes useful once it gets enough context to properly understand a task, and you don't build that context all at once — you refine it every time something didn't quite go right.
This is exactly what AI-amplified engineering means to us: not the promise that a model takes over the work, but the discipline of setting up the layer around it so a team can build on it every day. That's why we never just sell access to a model — we help build the work needed to make that model usable within an existing process.
What at first mostly felt like an experiment is now starting to look like a real operation: repeatable, testable, usable on an ordinary workday. We keep building — not toward the perfect prompt, but toward a working layer that actually makes a difference. Do you recognize this challenge in your own organization and want to map out the operational layer around your AI usage together? You can give us a call.