Three engineers on the same team, using the same tool on the same codebase, get into trouble in three completely different ways.
The junior ships something that works and cannot explain why. The mid-level engineer describes the problem accurately, leaves out the row count, and gets an elegant query that dies in production. The lead asks for an architecture recommendation and receives one their team has no chance of building.
None of them used the tool badly. They used it differently, and the differences follow a pattern.
🔍 Five things that change
Across the posts in this series, the same five differences keep appearing. Together they explain more about how an AI interaction turns out than which model you used.
1. What you are using it for. Learning, going faster, or thinking through a decision. A study of AI-assisted work found that novices and intermediates use an assistant mainly as a learning resource when they are unsure, while experts use it as a check on something they already believe. Earlier research found the same split in programming: experienced developers speed up familiar work, while novices explore.
2. How you ask. A short direct question, a question loaded with constraints, or a decision broken across several turns. This one has the strongest evidence attached to it. In a study of 218 developer conversations taken from real pull requests, adding context roughly doubled the odds of getting usable code back, and specificity had a larger effect still.
3. What you do with the answer. Accept it, question it, or check it against your own knowledge of the system. The same study of experts and novices found experts were much more likely to spot and ignore a made-up answer, while non-experts often did not.
4. How much it touches. One line, one component, or the shape of a whole system. A 2026 study found that less experienced developers using AI generate more code and push the checking work onto reviewers, and concluded that a team cannot swap experienced engineers for them without adding review capacity.
5. What goes wrong. This is the useful one, and it is the point of the whole framework, so it gets its own section.
🧠 The failure mode is the thing worth knowing
Each of the first four dimensions produces a different characteristic failure, and once you know which one is yours, you can watch for it.
If you are using it to learn, your failure is collecting fixes without principles. You get an answer, it works, and six weeks later the same problem arrives wearing different clothes and you do not recognise it.
If you are using it to go faster, your failure is under-specifying. You describe the problem correctly and leave out the physical facts, so you get an answer that is right for a problem you do not have.
If you are using it to think through decisions, your failure is organisational. You supply every technical constraint and none of the human ones, so you get architecture that is sound and unbuildable by the people you actually have.
If you accept output as-is, your failure is confident nonsense. Made-up functions, wrong-engine answers, numbers with no source.
If you check output against expertise, your failure is habituation. Your scrutiny quietly decays over months of reviews that were mostly fine, and nothing tells you it is happening.
That last one is why this matters for people who already know what they are doing. Being good at this does not remove the failure mode. It changes which one you have.
✅ How to use this
Take one week of your own AI conversations and mark each one on the five dimensions. Not from memory. Open them and look.
You will usually find you are operating at a different point than you assume, and almost always in a specific direction: more like a beginner than your job title suggests, on the dimensions where the work is unfamiliar. A senior data engineer moving into streaming for the first time behaves like a beginner in that area, with the beginner's failure mode, while continuing to feel like a senior.
That is the practical value. The framework does not tell you how good you are. It tells you which mistake you are set up to make right now, on this piece of work.
There is one finding that sits underneath all of it and is worth stating plainly. A study of 60 developers found that correctness related to how much AI output they accepted in a curved rather than straight line, and it peaked in the middle. Near-total acceptance did badly. Near-total avoidance also did badly. Balanced engagement beat both.
That is the whole argument of this series, measured. The question was never whether to use these tools. It is where on that curve you are sitting, and none of the five dimensions tells you unless you look.
⚖️ The objection worth taking seriously
The weak version is that frameworks are usually common sense with labels attached. Sometimes true, and the test is whether it predicts anything.
The strong version is more uncomfortable, and I found it in the research I have been citing. The level differences come from separate studies of separate populations, not from one study that compared beginners, intermediates and seniors directly. A 2026 review of this literature says plainly that no study compared AI assistant use across groups even within software engineering. Another notes the same problem: the findings are drawn from work targeting distinct populations rather than designs that compare them.
So the neat progression from beginner to senior might be an artifact of putting incomparable studies next to each other. That is a real risk and I cannot rule it out.
What I can offer is a test. The framework claims that failure modes shift by level in a specific order, and that a senior working in an unfamiliar area shows the beginner failure mode rather than the senior one. That is checkable on your own team. If your seniors and juniors fail in the same way, or if the failure tracks the person rather than the situation, the framework is wrong and you should throw it out.
I would rather give you something you can disprove than something that explains everything after the fact.
🎯 The takeaway
The five dimensions:
1. Purpose. Learning, speed, or deciding.
2. How you ask. Bare, constrained, or decomposed.
3. What you do with the answer. Accept, question, or verify.
4. Scope. A line, a component, or a system.
5. Failure mode. Determined by the four above.
Mark one week of your own conversations against these. The point is not to score yourself. It is to find the dimension where you are working outside what you actually know, because that is where the next mistake is coming from.
Every other post in this series is one cell of this table, examined closely.
