The phrase “I tried AI and it never comes out right” usually describes not the quality of artificial intelligence in general, but one unsuccessful run of a specific system. At that moment the word “AI” can hide different providers, models, tools, reasoning modes and data sets. Change any one of these layers and the very same request starts to behave differently.
It’s more useful to think not of a single button but of a chain of conditions. The answer takes shape where the technical platform, the available context and the precision of the task definition meet. Below are seven variables that are most often mistaken for one.
1. The provider
OpenAI, Anthropic, Google, DeepSeek and other companies don’t offer “the same AI under different logos”. Each provider has its own research, training data, ways of fine-tuning models and product restrictions.
In practice this shows up as different strengths. One service is handier for code, another keeps track of a long document better, a third works more confidently with images, a fourth bets on speed and low cost. On top of that, the provider determines the available tools, limits, API format and some of the system rules that the user may not even see.
So the verdict “this AI is bad” is too broad. It’s like judging the whole of world cuisine after one dish at an airport: the result may be real, but the conclusion stretches far beyond that one experience.
2. The specific model
Choosing a provider doesn’t yet determine the result. Within one service there are usually several models: fast and economical ones, more powerful ones for complex tasks, specialised ones for code, images or work with large contexts.
At Anthropic it’s the Opus — Sonnet — Haiku line-up, at OpenAI the flagship and mini versions of GPT and Codex, at Google Pro and Flash. The names matter not for their own sake: different models differ in how many conditions they hold on to, how they follow instructions, how thoroughly they check their conclusions and how often they go wrong over a long chain of actions.
The same wording can suit a fast model but be too vague for a complex engineering task. The reverse happens too: a powerful model spends time and its usage allowance on a task that could have been solved more simply. Comparing answers only makes sense with the model, version and settings fixed; otherwise several conditions of the experiment change at once.
3. The harness around the model
A model almost never works in a complete vacuum. On top of it sits a harness: the working shell that connects the model to the interface, files, tools and rules. Examples of this layer are Claude Code, Codex, OpenCode, Cursor and other environments.
The harness decides what exactly the model will see and what it will be able to do:
- which files and messages end up in the context;
- which commands, APIs and external services it’s allowed to use;
- whether it can change files or only suggest text;
- whether it needs to run checks on its own;
- how memory, history and repeated steps are organised;
- which system instructions are added to the request.
That’s why running the same model in a plain chat and in an agentic environment gives you two different working configurations. In a chat it more often gives an answer based on a single message. In a harness it can study the repository, call a tool, see an error, fix the solution and check it again. Quality here depends not only on the model’s “brains” but also on the quality of the process around it.
4. Effort and thinking
Some models let you choose an effort level: low, medium, high, max. In
other products a similar setting is called reasoning or thinking. It affects
how much computation the system is prepared to spend before forming an answer.
At a low level the model goes down the obvious path faster, but may miss a contradiction, an edge case or a hidden constraint. At a high level it gets more time to work through the conditions, compare hypotheses and check itself. This is especially noticeable in programming, document analysis and tasks that require several dependent actions.
High effort doesn’t turn a wrong brief into a right one. If the model was given the wrong data or wasn’t told the acceptance criteria, the extra computation will only help it solve the wrong task more thoroughly. The effort setting is one of the system’s parameters, not a universal “make it better” button.
5. Context
Context isn’t just the amount of text in the window. It includes files, earlier decisions, constraints, examples, definitions of terms and criteria for the result. What matters is not only that this data is present but also that it’s current: an old document or a contradictory rule can send the answer in the wrong direction.
In a project, internal working documents become context too: AGENTS.md, CLAUDE.md,
GEMINI.md, the links in them, the available skills and connectors. If an
important rule was left outside the request, the model doesn’t know it has to
take it into account. It will fill the gap with the most likely assumption.
Good context engineering means finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome.
The simple conclusion: the best context isn’t necessarily the longest. Unnecessary files create noise, while a short set of precise sources helps keep hold of the main thing: the goal, the boundaries and the signs of a finished result.
6. Setting the task
The model can’t work out on its own what “properly” means. For one person it’s a short text, for another a detailed analysis with sources, for a third a finished file that passes a specific check.
A workable brief should separate several things: the goal, the input data, the constraints, the answer format, the quality criteria and the prohibitions. If the order of actions matters, it’s worth spelling that out too: first study the materials, then draw up a plan, after that make the changes and check the observable result.
The difference between a vague and a precise request looks like this:
Do it properly.and:
Rewrite the introduction as 2–3 paragraphs, keep the article's meaning, remove the
direct addresses to the reader, don't add unconfirmed facts and check that the final text builds.The second version leaves less room for random interpretation. The model gets not only the topic but also a working definition of a good result.
7. Load and available compute
The answer also depends on the infrastructure the service runs on. It has queues, limits, context restrictions, the cost of computation and its own internal routing of requests. During a product update or under heavy load the service may change the available mode, choose a different processing route or return a result with shallower reasoning.
Not every such change is visible to the user. Sometimes the interface or the default model changes, sometimes only the behaviour near the limit. So the same request at different times may not give an identical answer, even with settings that look unchanged.
This doesn’t explain every mistake and isn’t an excuse to blame everything on “the servers”. Load is just an extra variable to take into account when reproducibility matters: save the request, the model, the mode, the context, the date and the result you got.
How to find the cause of a bad result
One unsuccessful answer doesn’t show which layer failed. To diagnose it, change one variable at a time and keep the rest fixed:
- the provider;
- the specific model and its version;
- the harness, the available tools and the system instructions;
effortand thethinkingmode;- the make-up and freshness of the context;
- the wording of the task and the quality criteria;
- the time, the limits and possible load on the service.
After a check like this, “the AI did a bad job” turns from a general impression into a testable hypothesis. It becomes clear what to change: the model itself, the shell, the context or the way the task is set.
Two of the layers on this list have their own write-ups: prompt engineering following OpenAI’s and Anthropic’s guidelines and context engineering.
