The developer who could assemble a component library but could not explain this is about to reappear in AI form. This time, the blast radius is not just the front end.
By @vgutierrez, developer at KWAN · September 2026 · 10 min read
Every hiring loop now has a version of the same question: how does the model actually produce that answer?
The candidate is fluent. They name their assistant, their agent framework, the prompt library they open every morning. The demo works. Then you ask what happens between the prompt and the answer, and the room goes quiet.
I have watched this film before. Ten years ago the question was about React, usually phrased as explain what this refers to in this function. Half the people who could assemble a component library from memory could not answer it.
This is not an argument against abstractions. Abstraction is how anything gets built, and nobody wants to write a web application in assembly. It is an argument for knowing what your abstraction is doing on your behalf, because the bill for not knowing arrives later, in production, in interviews, and every single time the tool of the month changes.
What you will find in this article
- Why every powerful abstraction arrives with the same promise
- The interview question that separated two kinds of developers
- What actually broke when the ecosystem shifted
- Why AI repeats the pattern with a much bigger blast radius
- What "knowing the mechanism" means in practice with AI
- The computer analogy, and what to check on Monday morning
In short: the framework era let a generation ship software without understanding JavaScript, and the people who learned only the framework paid for it every time the ecosystem moved. AI repeats the pattern with a much larger surface area: it produces impressive results without requiring you to understand the mechanism, in code, writing, design and decisions. Knowing the API is enough to ship a demo. Knowing the mechanism is what lets you debug an output, judge it, and still be useful when the tools change. You do not need a PhD. You need to be able to explain what your tool is doing.
1. Every powerful abstraction makes the same promise
The promise is simple, and it is genuinely good: you do not need to understand how this works in order to use it.
That deal is why software is possible at all. You use an HTTP library without implementing TCP. You use a database without writing a B-tree. You use a design system without knowing how the browser computes layout.
The problem is that abstractions leak. Joel Spolsky made the argument in 2002 and it has not aged: an abstraction holds until it does not, and in that moment the details come flooding back up. If you know them, you debug for an hour. If you do not, you are guessing.
In the front-end era, the failures were annoying but contained. A bloated bundle. A component re-rendering for reasons nobody could explain. An edge case that only appeared on a slow phone.
With AI, the same leaks show up as a confident wrong answer, a bill that quadruples overnight, or a feature that works in the demo and fails with the first real user.
The promise is still worth accepting. Accepting it without ever checking what is underneath is what gets expensive.
2. The interview question that separated two kinds of developers
For about a decade, one family of questions did most of the work in front-end interviews, and they all came down to the same request: show me you can work without the framework.
Frameworks were the gold rush. People jumped on React, Vue and Angular, learned the API, memorised the hooks, and became genuinely productive inside the abstraction. Then you asked them to manipulate the DOM directly, or to explain what this refers to, or why a function was re-created on every render, and the fluency disappeared.
That gap is not about trivia. It is about whether someone can predict behaviour in a situation the tutorial did not cover. You can rebuild a component library from memory and still be unable to debug a rendering loop, because the loop lives one layer below the API you memorised.
The AI version of that question is already being asked, just less deliberately. It sounds like this:
- Why does the model hallucinate, and what in your architecture makes it more or less likely?
- What is a token, and what does that imply about how you count cost?
- When is retrieval a better answer than fine-tuning?
- How would you know an AI feature got worse after a model update?
Answer those and you understand your tool. Answer only the first half of each and you have the same problem as the framework tourist, with much more expensive consequences.
3. What actually broke when the ecosystem shifted
The more interesting question is what happened to framework tourists next.
Every two or three years the front end threw the previous playbook away: components, then hooks, then build tooling, then server components. The engineers who understood JavaScript (the event loop, the DOM, why rendering is expensive) moved across each shift in a week. The ones who had learned only the surface re-learned the surface, with interest.
AI is running that cycle faster. The prompt engineering habits of 2023 already look dated. Then came tool calling, then agents, then whatever shipped last month. Each wave makes the previous set of tricks look naive.
That is why the mechanism is the durable asset. Knowing what a context window is, why retrieval exists, what a model can and cannot be trusted with — that is the part which survives the next release, because the next release is built on the same principles the previous one was.
4. Why AI repeats the pattern with a bigger blast radius
Front-end frameworks were domain-specific. If you were a framework tourist, the damage stayed in the browser: a slower page, a harder bug, a painful migration.
AI has no such boundary. Its surface area is everything: code, writing, analysis, design, research, decisions. It sits as a layer under all of the work.
And it feels magical, which is precisely the risk. The results arrive polished enough that the mechanism seems irrelevant. Download the model, write the prompt, ship the demo. Nobody asks what happens when the same input produces a different output, or when an answer is plausible and wrong, or when a feature has to run ten thousand times a day at a cost nobody modelled.
The uncomfortable truth is that AI is powerful enough for people to get impressive results while understanding almost nothing. The distance between "looks right" and "works reliably" is larger than it has ever been, and you cannot see that distance without understanding the mechanism.
5. What "knowing the mechanism" means in practice
Nobody is asking you to become a researcher. You do not need to derive attention from a paper, publish anything, or explain why one architecture won. For most people building with AI, knowing the mechanism looks like this:
Six rows, and not one of them requires a research background. They require a couple of afternoons spent on how the thing actually works.
The row that pays back fastest is the second. Once you understand that a language model generates probable text, hallucination stops being a mystery and becomes a design constraint, something you engineer around, instead of something that surprises you in a call with a client in the room. It is the same shift of responsibility that our data engineering work went through: the tool drafts, the human defines and guarantees.
6. The computer analogy, and what to check on Monday
Here is the argument that sounds obvious until you sit with it: if you write programs for computers, it makes sense to understand how computers work. At least fundamentally.
You do not need to design a CPU. But you should know what memory is, what a process is, and why some operations are fast and others are not. The gap between those two positions is the entire difference between debugging and guessing.
AI sits in exactly the same place. If it is a professional dependency (something you are paid to design, build and support, not a casual tool) then understanding how it works is part of the job description.
For individuals, four questions worth answering honestly this week:
- Can you explain to a colleague why the model produced that particular wrong answer?
- Do you know when a longer prompt stops helping and retrieval starts?
- Could you describe what your evaluation would catch before the users do?
- Can you estimate the monthly cost of a feature before you build it?
For teams and hiring managers, the useful signal is not trivia but narrative. Ask for a story: tell me about a time an AI feature produced something wrong in production. What changed afterwards? The people who understand the mechanism describe the diagnosis. The others describe the tool they swapped. Postmortems have been the cheapest training material in software for decades; AI changes the subject matter, not the method.
And if you are the one hiring, remember that the same distinction decides how much supervision a hire needs. A team that can explain its own system can also review what an AI produces in its name. A team that cannot, only hopes.
Frequently asked questions
Do you need a PhD to work with AI?
No. You need to understand what the tool is doing well enough to judge its output. The bar is closer to "knows how memory works" than to "can derive backpropagation".
How do I tell in an interview whether someone knows the mechanism?
Ask for a failure, not a definition. Someone who has diagnosed a wrong answer, a cost spike or a quality regression can describe the evidence they looked at. Someone who memorised the API describes the tool they replaced.
Does this apply to people who are not engineers?
More, if anything. A writer, designer or analyst using AI is still responsible for the output they ship. The mechanism is what tells them when to stop trusting it.
Conclusion
The pattern repeating now is old, and that is the good news: abstractions arrive with a promise, most people stop at the API, and a smaller group learns what is underneath. The front end gave us a live experiment in what happens to each group when the ecosystem moves.
AI is the same experiment with a much larger surface area, faster cycles, and results polished enough to hide the gap. The people who spend a weekend understanding what their model is doing will keep adapting every time the tools change. Everyone else will keep re-learning surface-level tricks every six months.
Do not be the second group. Know your tools.
Top comments (0)