Looking back at how my work has changed in recent years, two moments stand out: the first time I used OpenCode and suddenly had a coding agent at my disposal that made my work many times faster and more efficient, and a few months later, the first time my token budget ran out.
Within a short time, the agent had become as essential as an internet connection, and the moment it was suddenly gone confronted me with a question I had never asked myself before: what do I actually do when this isn’t available? Not because I had become dependent – I still knew how to solve the problems I now tackled with an LLM on my own – but because going back to the old way of working simply no longer felt logical. I had grown accustomed to the speed and convenience. To borrow a metaphor from a colleague: you can still cycle to Maastricht, but you’d rather take the train. Even if the train is delayed.
Where control currently lies
“AI dependency” is not such an interesting discussion. What we should realise, however, is that the tools that made us the fastest are exactly the tools over which we have the least control. Rate limits, price changes, outages, and in recent months also export restrictions and phased, government-approved releases are all decisions made entirely outside our sphere of influence. This is not a complaint directed at providers, but a simple statement of where control currently lies: at this moment, it is not with us.
As long as everything is available, this does not feel like a problem. Only when things go wrong does it become visible, and by then it is too late to do anything about it.
A distinction that is often overlooked
The good news: that dependency is not equally great everywhere. There is a distinction that is often overlooked.
Two types of AI usage
Interactive usage
Frontier model adds genuine value
Tracing a bug together with an agent, or thinking live about an implementation. Here, the quality you get back outweighs the risk of dependency on an external party.
Autonomous usage
Frontier model not required
Nightly regression analysis, bulk test generation, repeated passes over a migration tool. Needs to run reliably, unattended, and at volume.
For a QA company, this is precisely the next phase: not automating individual tasks, but building complete workflows that run fully autonomously in the background, without anyone waiting or watching, and without each run being billed separately by an external party. That is the work you can bring back under your own control first.
This distinction is also recognised by the providers themselves. Earlier this year, Anthropic announced that it would start billing interactive usage and automated agent usage separately, with a separate budget at standard API rates for the latter. After strong criticism, that announcement was (temporarily) withdrawn, but the underlying observation remained: interactive and autonomously running workloads are simply economically different, even in the eyes of the party sending us the bill.
Local models as a targeted shift
At QA Company, we therefore work with local, open-weight models on our own hardware, deployed precisely for that kind of background work. This is not an attempt to replace the most expensive cloud API everywhere, but a targeted shift of tasks that were already running unattended. The gain is not in an impressive GPU setup, but in the fact that this work simply no longer grinds to a halt as soon as an external party changes something about price, limits, or access.
Why this moment is different
Two developments make this moment different from a year ago. Open-weight models are now good enough for this kind of work. The gap with the absolute top has narrowed considerably in recent years, and for tasks that do not need that absolute top, it hardly matters anyway.
At the same time, the availability of frontier models themselves has become less certain. Companies using GitHub Copilot have recently seen their costs explode — an early signal that the bill, not only for tokens but also for the years of massive investments made, will eventually have to be paid. In addition, we have already seen this year that governments can, in the worst case, impose export restrictions with immediate effect, whereby a model can simply be taken offline.
This is not a plea to stop using frontier models. On the contrary, use them where their lead truly matters. It is a plea to remain aware of where convenience quietly turns into complete dependency, and in any case not to let work that already runs unattended come to a standstill because of something decided entirely outside our own walls.
