Three AI Trends We Are Telling Clients to Ignore
Three AI Trends We Are Telling Clients to Ignore
Almost all AI advice is additive: here is another thing to adopt. Rather less of it tells you what to stop paying attention to, which is a shame, because engineering attention is the actual constraint in most organisations.
Here are three widely-discussed things we are currently advising clients to deprioritise, and what we suggest instead.
1. Benchmark chasing
Every few weeks a model tops a leaderboard and someone forwards the announcement with a question about whether the roadmap should change.
It should not, almost always. The difference between the leading few models on public benchmarks is consistently smaller than the difference your own prompt design, retrieval quality and evaluation discipline make to the same task. We have repeatedly watched a mid-tier model with good context beat a frontier model with poor context on the client's actual work — which is the only benchmark that matters.
There is also a structural reason to distrust the comparison: public benchmarks measure general capability on tasks that are not yours. Your workload has a specific distribution, specific edge cases and a specific definition of correct. Two models a few points apart on a leaderboard can be far apart, in either direction, on your traffic.
What to do instead: build so you can swap models in an afternoon. Keep model choice behind an interface, run your evaluation set against candidates when you feel curious, and let the numbers on your cases decide. Then stop reading leaderboards. The switching capability is the durable asset; the current ranking is not.
2. Premature fine-tuning
Fine-tuning has an unusual pull. It feels like real machine learning rather than prompt-writing, it sounds impressive internally, and it promises to make the model yours.
In practice, most teams that want to fine-tune have a retrieval problem or a prompt problem. The model is not failing because it lacks knowledge of your domain; it is failing because the right context was not in front of it, or the instruction was ambiguous. Fine-tuning does not fix either, and it adds a maintenance obligation that lasts as long as the system does — retrain when your categories change, revalidate when the base model updates, carry the operational weight of a model artefact and its versioning.
What to do instead: exhaust context engineering first. Fix retrieval. Sharpen the instruction. Measure against your evaluation set at each step. If, after all that, you have a narrow repetitive task, a stable target and a few thousand labelled examples, fine-tuning a small model is genuinely excellent — that is the case where it wins on cost, latency and control. It is just much rarer than the enthusiasm suggests, and it is the end of the process rather than the start.
3. Full-autonomy ambitions in high-consequence domains
There is real appetite for removing the human from decisions involving money, health or eligibility. The technology permits it in narrow cases. The regulatory and reputational environment does not yet reward it.
The asymmetry is the point. The upside of removing a human review step is a modest efficiency gain. The downside is a regulatory finding, a class of customer harm, and a news story — and in 2026 the disclosure and traceability obligations mean the incident will be well documented by your own logs.
What to do instead: human-in-the-loop at the irreversible step remains the correct default. Not a human reviewing everything — a human at the specific point where an action becomes hard to undo. Automate the ninety per cent that is reversible and put the checkpoint where the consequence is.
This is also better engineering. It gives you a natural place to sample quality, an escalation path when confidence is low, and a source of labelled outcomes that feeds back into your evaluation set. The checkpoint is not just a safety measure; it is where your training data comes from.
What we tell clients to do instead
Since a list of things not to do is unsatisfying on its own, the short version of the positive list:
- Build the evaluation set before the feature — 200 real cases with known correct answers
- Automate one bounded workflow end to end, including the failure path
- Instrument cost per resolved task from day one
- Fix permissions at retrieval time before opening any internal assistant beyond a pilot
- Start capturing labelled outcomes from existing human processes now
None of those will appear in a keynote. All of them determine whether the next twelve months of AI investment produce anything.
Frequently Asked Questions
Should we never switch models?
Switch when your own evaluation set says a different model does better on your cases. The point is that the leaderboard is not that evidence, and building for cheap switching matters more than picking correctly today.
When is fine-tuning actually the right choice?
When you have a narrow repetitive task, a stable definition of correct, and a few thousand labelled examples — and when context engineering has already been exhausted. Then a tuned small model wins clearly on cost, latency and control.
Is human-in-the-loop just slower automation?
No, if placed correctly. Automate everything reversible and put the human only at the irreversible step. That preserves most of the efficiency while removing most of the exposure, and it generates labelled data as a byproduct.
What about industries with no regulator?
Reputational exposure is the binding constraint even without a regulator. The question is what a wrong answer costs, not who is watching — and the answer determines how much review the design needs.
Are these trends wrong, or just badly timed?
Mostly badly timed and badly sequenced. Each has a legitimate place after the foundations exist. The failure is reaching for them before evaluation, retrieval and cost instrumentation are in place, at which point they consume attention without producing anything measurable.
What is the single highest-return thing to do instead?
Build the evaluation set. It is cheap, it takes days rather than quarters, and it determines whether every subsequent decision can be made on evidence rather than opinion.
The full 2026 analysis — eight developments that actually changed, plus what to build next quarter — is here: Top AI Developments for Business in 2026: What Actually Changed.
TechCirkle builds AI development services and LLM integrations for production use. Get in touch.

Lo de armar la arquitectura para poder cambiar de modelo en una tarde me parece un consejo súper práctico. Muchos se marean persiguiendo las leaderboards semanales, pero la diferencia se nota cuando enfocás la atención en mejorar el contexto de tus propios datos. Esto es genial.