Prompt wording changes how well a model responds. Problem framing decides whether it is answering the right question at all, and it has four parts: the observation, the assumptions, the constraints, and what would count as success. Framing used to be checked for you, because implementation was slow enough that a badly stated problem often surfaced while there was still time to restate it. That accidental check has gone, and a wrong answer now arrives with the same finish as a right one.
There is a great deal of advice available on how to write a better prompt, and almost all of it is about phrasing. Phrasing does matter. Better wording improves completeness, format, tone, and how reliably a model holds to the constraints you gave it. What it cannot do is repair a false premise, an unstated requirement, a missing measurement, or an undefined success condition. That work happens before you type anything, and it is not a communication skill presented as an engineering one. It is engineering work, and it now decides the outcome.
It is also the skill most likely to be left out at the moment, because nothing in your working day makes its absence obvious.
A model will answer the question you asked. It has no way to tell you that you asked the wrong one.
We have written before about the first half of this, noticing the real question inside a confusing situation, and about the habits that build that kind of attention. This piece is about what happens next: what a framing is made of, the three ways it fails, and why the failures now cost more than they used to.
The check that used to catch a bad question
Think about what happened when you framed a problem badly five years ago. You started implementing. Somewhere in the second hour you reached a decision the framing did not cover, and you could not proceed without answering a question you had not asked. Perhaps you discovered that the thing you were optimising was not on the path that mattered. The work stopped, you went back, and you restated the problem.
That correction was never dependable. Badly framed projects have survived for months and shipped, and everyone reading this can name one. But it happened often, and it happened for a structural reason: implementation was slow, and slow work made you look closely at details. You could not build the wrong thing without examining enough of the system to notice that it was the wrong thing. Missing information, conflicting requirements and failing integrations repeatedly sent you back to the real system, and some proportion of bad framings did not survive that.
What follows is an observed pattern rather than a measured one. A badly framed problem now produces a complete, confident, well-organised answer in seconds. It compiles. It follows the conventions. It reads like something a careful engineer wrote, because it is shaped by an enormous quantity of writing by careful engineers. Nothing in it records that the question was wrong, and the friction that used to expose the mistake by accident has largely gone.
Slow implementation used to expose a bad question by accident. Nothing exposes it by accident now.
A second change arrives with it, and it is not that polished work should be distrusted — most of it is good, which is exactly what makes this difficult. It is that finish no longer tells you anything. Your own half-finished attempt used to show its own uncertainty: the parts you had not worked out were visibly not worked out, and a colleague reviewing it could see where you were unsure. Now the correct answer and the answer to the wrong question look exactly alike. Human-factors research has a name for what tends to happen next — automation bias, the tendency to over-rely on automated output, particularly when it appears authoritative or saves effort. It has been studied for decades in safety-critical fields such as aviation, and fluent generated text creates a related risk in engineering work.
This is why framing has moved from something most engineers did implicitly to something that has to be done deliberately and in advance. It rarely had to be taught, because the process checked it for you.
The four parts of a problem frame
Framing is not the sentence you type. It is what you have established before you type it. Four parts, and none of them are about wording.
- Observation. What you directly saw or measured, separated from your interpretation of it. “The driver is loading too late” is not an observation. It is a conclusion with a cause already built into it.
- Assumptions. What you have concluded but not verified. Almost every framing contains at least one belief that has never been tested and is being treated as established. Finding it and naming it is most of the work, and it is uncomfortable, which is why it is often skipped.
- Constraints. The limits that decide whether an answer is usable at all. The board has this much RAM. The product must be supported for seven years. Nothing may be added that changes the licence position.
- Success criteria. The outcome that would count as a good answer, stated before you see one.
Leaving any one of the four out has a specific cost, and recognising the symptom is usually how you find out which part you skipped.
| Missing part | What you get instead |
|---|---|
| Observation | Help solving a problem that may not exist |
| Assumptions | A confident answer resting on an untested belief |
| Constraints | An answer that is entirely correct and unusable |
| Success criteria | No way to judge the answer except whether it sounds right |
Written out, a frame takes about five minutes and fits on half a page. Here is the form, filled in for a driver that never binds. The entries are an example, not a report from a real product.
| Observed: | probe returns -EPROBE_DEFER on every boot, and the expected device node never appears. |
| What I know: | The driver’s own probe is being called. The parent bus is present. Other devices on the same bus bind normally. |
| What I am assuming: | That a supplier device is never becoming available. This has not been checked. |
| Constraints: | The peripheral must bind before the application service starts, about four seconds into boot. The device tree bindings are shared with two other boards and cannot change. |
| What must not change: | The boot time budget, currently eight seconds to the application. |
| A good answer must achieve: | The driver binds within 500 ms of its supplier becoming available, on every boot in a hundred. |
| What would show this framing is wrong: | A boot where the device node does appear and the application still fails, which would mean binding was never the problem. |
The last line is the one people leave out, and it is the one that does the most work.
The three ways problem framing fails
Each failure is the absence of one of the four parts, which is what makes them worth naming. The fourth part, constraints, does not fail this way. It is simply left out, and you find out when the answer is correct and you cannot use it.
Mistaking an interpretation for an observation
A panic, a dropped connection, a boot failure: these are observations, and the framing built on top of one is usually already an explanation. “The bootloader is broken” is a framing. “The kernel never prints anything on the console” is what you actually saw, and the difference between the two is a piece of reasoning nobody has checked. This one is well understood in a debugging context, and we have written about it separately in Don’t jump to the solution. What is new is the speed: the gap between accepting a symptom as the problem and holding a plausible fix used to be hours, and those hours were often enough for the mistake to appear on its own.
Treating an assumption as an established fact
“How do I increase the DMA buffer size?” is not a problem statement. It is a solution written as a question. The problem, if it was ever stated, was that a capture pipeline is dropping frames. Somewhere between the two a conclusion was reached about why, and it was reached quickly and never revisited.
A model will help you increase the buffer, and it will do it well. Nothing in the exchange will mention that buffer depth was never shown to be the constraint. This is the costliest of the three, because the work proceeds smoothly right up to the point where it turns out to have been the wrong work.
Five minutes with the form produces a different question from the same situation:
“At 1920×1080 and 60 fps, the capture pipeline drops frames after about twenty minutes of continuous running, and dequeue latency rises shortly before each drop. We are assuming capture buffer depth is too small. We have not measured memory bandwidth, interrupt latency, downstream processing time, contiguous allocation failures or thermal throttling. The device must sustain 60 fps with no dropped frames for two hours with display output enabled. Which measurement would settle whether buffer depth is actually the constraint?”
It is longer, and length is not the point. It separates what was seen from what was concluded, states the buffer-depth belief as an assumption rather than placing it inside the question, gives the workload the answer has to meet, and asks for a measurement rather than a fix. A fix can only be applied. A measurement can be checked.
Ask for a fix and you will get one. Ask which measurement would settle it, and you find out whether you were right.
Stating no condition that could prove you wrong
If there is no observation that would show your framing to be wrong, it is not a framing. It is a preference. “We need to make the system more efficient” cannot fail. “This device must complete the transfer inside twenty milliseconds at the ninety-ninth percentile, and currently does not” can fail, which is what makes it useful. A framing that cannot be wrong will accept any answer you are given, including a bad one.
How to practise problem framing
One warning before the list. None of these are domain-independent techniques you can carry from one field into another. They are a way of getting your knowledge of this board, this stack, this risk and this deadline into the question. If you do not yet have that knowledge, they will produce a well-formatted framing that is still wrong.
Most of this costs no extra time. It is the same time, spent earlier. One item does cost real time, and it is the one worth paying for.
- State the constraint set in three lines. What the hardware allows, what the schedule allows, what the licence and support position allows. Almost every unusable answer traces back to a constraint that was in your head and not in the question. For the accurate version rather than a generic one, open the last three answers you received that were correct but unusable and write down the constraint missing from each. That list will be short and the same items will repeat.
- Say what a good answer would look like before you see any answer. One line is enough. This is the habit that does most to stop a fluent response being accepted because it is fluent.
- Name the assumption you are least sure of, and ask whether you can test it in under an hour. If you can, do that before anything else. This is the expensive item, and the only one that restores a real error signal, because the test either passes or it does not.
- Write two things that would make your problem statement wrong, before you ask the tool for anything. Then put the same question to it — “what would have to be true for this problem statement to be wrong, and what have I not told you that would change your answer?” — and read the difference between its list and yours. The difference is the finding. Asking the tool alone is weaker than it appears, because you will tend to accept the objections of the same system whose answer you are about to accept.
The assumption you did not write down is the one that will still be there when the work is finished.
The third and fourth of those are the difficult ones to do alone, because both depend on someone telling you that the assumption you named was not the assumption that mattered. That is the reason our sessions are live and mentor-led, with attendance enforced rather than optional, and built around working through problem scenarios rather than a walk through an API. A scenario has to be framed before it can be attempted, and getting that wrong in a session costs you an hour instead of a release.
Why problem framing is a career skill, not a technique
We have written before about which engineering skills became cheap and which became scarce, and named specifying precisely as one of the four that gained value. This is that item, examined properly. It belongs with the others for the same reason: it is work whose input is your knowledge of one specific system, one product and one deadline, and there is no written source anywhere that contains those three things. Everyone now has the same tools and the same answers available to them. What differs is who can decide what those tools are being applied to, and that decision is made before anything is typed.
It shows in a career in ways that are easy to miss. The engineer who frames well is the one whose questions in a review save the team a week, whose bug reports are acted on rather than returned, and who can hand a problem to someone else without handing over their own confusion along with it. In a hiring conversation it shows as the ability to state a problem that another person can act on. It is uncommon, and it is obvious within a minute when someone can do it.
Framing is the only step that uses what you know about this particular system. Nothing else in the process has a place for it.
Here is the exercise worth doing this week. Find the last question you asked a model where the answer was good but the work still went wrong afterwards. Read your question again and write down what it assumed. That is a framing you made without knowing you had made it, and it is the cheapest lesson available to you.
— Raghu Bharadwaj
Key takeaways
- Prompt wording still matters, but it cannot repair a false premise, an unstated requirement, a missing measurement or an undefined success condition.
- A problem frame has four parts: observation, assumptions, constraints, and success criteria. Each failure mode is the absence of one of them.
- Slow implementation used to expose bad framings by accident. It was never dependable, but it happened often, and that friction has largely gone.
- A wrong answer now arrives with the same finish as a right one, so fluency can no longer be used as a signal that the question was right.
- Ask which measurement would settle a question rather than asking for a fix. A fix can only be applied; a measurement can be checked.
- None of it transfers between domains. Framing is how your knowledge of a specific system enters the work, not a substitute for having that knowledge.
Frequently asked questions
Is problem framing the same as prompt engineering?
No. Prompt engineering is about how a request is phrased so that a tool responds well to it, and it changes as tools change. Framing is about establishing what the problem is before any tool is involved: what you observed, what you are assuming, which constraints decide the answer, and how you would recognise a good one. Better wording genuinely helps a model follow your constraints and return a usable format. It cannot repair a false premise. A well-framed problem asked clumsily usually produces something useful; a badly framed problem asked expertly produces a confident answer to the wrong question.
What is problem framing in engineering?
Problem framing is establishing what the problem is before any tool is involved. It has four parts: the observation, separated from your interpretation of it; the assumptions you have not yet verified; the constraints that decide whether an answer is usable; and the success criteria that say what a good answer must achieve. It became more important once producing an answer got fast. A badly stated problem used to reveal itself during implementation, while you still had the chance to restate it; now the answer arrives in seconds and looks finished, so the mistake appears later, after other work has been built on it.
How do I get better at framing problems?
Four habits, in order. State your constraints explicitly rather than carrying them in your head. Say what a good answer would look like before you see one. Name the assumption you are least certain of, and test it if that takes under an hour. Write two things that would make your problem statement wrong before you ask a tool anything. Reviewing the questions you asked against the assumptions they rested on, over a week, will show you which of these you habitually skip.
Further reading
- AI Can Fetch the Answer. Only You Can Notice the Question. — TECH VEDA.
- Your Code Got Cheap. Your Judgement Did Not. — TECH VEDA.
- Don’t jump to the solution — TECH VEDA.
- How to Write a Kernel Bug Report Maintainers Act On — TECH VEDA.
- Information Is Free. Skill Is Not. — TECH VEDA.
