There is a line we keep coming back to at TECH VEDA: AI can fetch the answer. Only you can notice the question. It sounds simple, but it points at the part of engineering work that is changing the least, even as everything around it changes fast.
A language model is very good at one thing: it retrieves and reformats what is already known. Ask it a clear question and it will hand you a clear answer, often a good one. But it is answering the question you typed. It is not standing in your situation, looking at your board, your logs, your half-finished design, and noticing what is actually being asked. That noticing is still yours to do. In a world where answers are nearly free, it is becoming the whole job.
Why the question is harder than the answer
Most real engineering problems do not arrive as well-formed questions. They arrive as symptoms. A device boots most of the time but not every time. A driver works on one board and fails on another. A latency number is fine in testing and bad in the field. None of these is a question yet. Someone has to look at the mess and frame it: what is really going wrong here, what is the smallest thing that would explain it, what should I ask first?
That framing step is where good engineers separate from average ones. It always was. What is new is that the step after framing — finding the answer once the question is clear — has become cheap. You can describe a well-defined problem to an AI tool and get a working response in seconds. So the value has shifted. It has moved away from knowing the answer and toward knowing which question to ask, and noticing when the answer you got is solving the wrong problem.
This is why two engineers can use the same AI tool and get very different results. One types a vague prompt, accepts the first reply, and moves on. The other has already noticed what is off, framed a precise question, and can tell within moments whether the answer fits the real situation. The tool did not make the difference. The noticing did.
How to build the skill of noticing
Noticing is not a personality trait that some people are born with. It is a habit you can train, and it is built mostly by slowing down at the exact moments when you want to speed up. A few concrete practices help:
- Read the problem before you reach for a tool. Before you open an AI assistant, write one or two plain sentences describing what you are actually seeing and what you think is being asked. If you cannot write it clearly, you do not understand it yet, and no answer will fix that.
- Separate the symptom from the question. “The build fails” is a symptom. “Why does this header resolve differently on the target than on the host?” is a question. Practice turning the first into the second yourself, before asking anything.
- Attempt your own answer first. Even a rough guess sharpens your attention. When you then ask the tool, you are checking a hypothesis instead of begging for a rescue, and you will spot a wrong answer far faster.
- Question the question the tool answered. When AI gives you a confident response, pause and ask: did it solve my actual problem, or a nearby one that I described poorly? This single check catches a large share of wasted hours.
- Keep a record of the questions, not just the fixes. When you solve something hard, write down the question that cracked it. Over time you build a library of good framings, and good framings transfer across problems in a way that specific answers do not.
Using AI without losing the skill
None of this is an argument against using AI tools. They are genuinely useful, and an engineer who refuses to use them is choosing to work slower for no good reason. The point is narrower and more practical: use the tool for the part it is good at, and keep the part that builds you. Let it fetch, retrieve, and reformat. Do not let it do your noticing for you, because that is the skill that compounds over a career and the one the tool cannot replace.
The engineers who will do well in the next decade are not the ones who memorise the most or type the fastest. They are the ones who can look at a confusing situation and notice the real question hidden inside it. This is exactly the habit of attention and judgment we try to build in our learners at TECH VEDA — not because it sounds wise, but because it is the part of the work that stays valuable when the answers are free.
So the next time you are stuck, resist the reflex to immediately ask. Sit with the situation for a moment and ask yourself what is really being asked here. Get that right, and the answer is usually the easy part.
— Raghu Bharadwaj
