Where Tomorrow’s Engineers Come From, Part 2: The Apprenticeship Problem
AI can teach the fundamentals. It cannot give the skills, and the skill that matters most it cannot teach at all. A post on what does build judgment, and on the one disposition that decides whether someone is an engineer or an automaton.
Written with Claude Opus.
Part 1 ended on a question. The roles AI displaces are the entry-level ones that used to be the path to the higher-complexity work. The destination still exists. The on-ramp is being demolished. So where do tomorrow’s senior engineers come from, if the activity that used to grow them is being absorbed by AI?
The reassuring answer, the one you hear at conferences, is that AI will teach the next generation. Give a junior engineer a tutor that is infinitely patient, available at every hour, and fluent in every topic, and you have solved the training problem. It is a comforting story. It is also half right, which is the most dangerous kind of story, because the half that is wrong is the half that matters.
What AI can teach, and what it cannot
AI can teach the fundamentals, and it is genuinely good at it. An engineer today can ask a frontier model about clock-domain crossing and get a clear, structured, patient explanation. They can ask follow-up questions, work scenarios, build vocabulary, and probe edge cases for as long as their curiosity holds. For canonical material that is written down somewhere, AI is a better tutor than most textbooks, because it is interactive and it adapts to the question. A junior engineer in 2026 has a better path to the fundamentals than any generation before them. That is real, and it should be said plainly before the rest of this post complicates it.
But teaching the fundamentals is not the same as giving someone the skills. Fundamentals are what you know. Skills are what you can do, and skills come from practice, not explanation. You do not learn to debug by reading about debugging. You learn it by sitting in front of something broken, forming a wrong theory, watching it fail, and forming a better one, a few hundred times, until the pattern recognition is wired in. No explanation shortcuts that. AI can narrate the process. It cannot do the reps for you, and the reps are the point.
And then there is the skill that matters most, the one this post is really about, and AI cannot teach it at all.
The olfact
Every senior engineer has it and almost none of them can fully explain it. It is the sense that something is wrong before you can say why.
Some years ago, as a director, I was reading a spec. There was a clause describing how a counter would wrap around. I read the clause, and before I had seen a single line of the engineer’s code, I knew they would implement it incorrectly. Not a guess. A certainty, arriving ahead of any evidence. I went and asked, and I was right: the engineer had read the same clause and understood it differently than the spec intended. The code was not written wrong. It was understood wrong, and I had known that would happen from the clause alone.
That is the olfact. Notice what it is not. It is not knowledge of counters, which any engineer has. It is not a careful reading of the code, because there was no code yet. It was a sense, built from having watched comprehension break in that exact shape many times before, that the clause as written would be read past. The wording left a gap, and I could feel the gap before anyone fell into it. Call it the olfact: the engineer’s sense of smell for the parts that do not add up.
The olfact is not knowledge. It is compiled experience. It is built from hundreds of cases, most of them never written down, many of them never even discussed, and it is the single thing that separates an engineer who can be trusted with sign-off from one who holds the title but not the judgment. It is also, precisely because it is compiled from undocumented experience, the thing no corpus contains and no model can be trained on.
There is a deeper reason AI cannot teach it, and it is worth being exact about. AI has to be driven. It does not decide what matters; it responds to what it is asked. It does not make the call the engineer is making, which means it cannot model the act of making that call, which means it cannot teach it. You cannot learn judgment from a thing that has none. The model can hold more facts than any human and still not have the one thing the junior most needs to acquire, because that thing was never a fact. It was a disposition.
How judgment actually gets built
Here is the part that is not gloomy.
The olfact cannot be taught, but it can be practiced, and the conditions for practicing it are better now than they have ever been. To see why, it helps to look at how it got built before.
When I was a junior engineer, I used to synthesize my RTL just to see what it became. Not because anyone asked me to. I did it because I needed to know how each construct turned into gates. What did this if-statement become. Where did this loop unroll. Why did this innocent-looking line explode into a tangle of logic. I did it over and over, and after enough times something changed: I could look at RTL and feel how it would synthesize before I ran anything. The intuition for what compiles cleanly and what does not was not taught to me. I built it, by interrogating the layer beneath the one I was working at.
That act, the interrogation of the layer below, is how judgment has always been built. And it is exactly the act available today, one level up. The junior engineer now should be driving AI to generate RTL from microarchitectural intent, and then doing to that output what I did to the synthesis netlist: interrogating it. Why this structure. What does this become downstream. Where does this break. The abstraction level moved up. The discipline did not change at all. You build the olfact for microarchitecture-to-gates the same way an earlier generation built it for RTL-to-gates, by refusing to treat the layer below as a black box.
There is one question in that interrogation that matters more than the rest: what did you assume that I did not tell you to assume. It matters most because of how an AI fails. Handed an instruction that says less than it thinks it does, an AI does not stop and flag the gap. It fills the gap, silently, with a plausible assumption, and hands back a complete-looking answer with the assumption buried inside it. That is the exact failure in the counter-wraparound clause from earlier in this post: a spec said less than its author believed, and the silence got filled by a reader, quietly and wrongly. The olfact for that gap, the sense that an answer is resting on something that was never specified, is the spec-first instinct itself. It is the thing this publication keeps circling. An engineer who learns to ask an AI what it assumed is learning to read the silences in a spec, and reading the silences is the most valuable reading skill in chip design.
The AI is the synthesis tool of this era. The mistake is to treat it as an oracle. The opportunity is to treat it as something to interrogate.
Be the adversarial agent
This is the practice, stated as a discipline. Question everything the AI gives you. Ask it for justifications. Make it defend every claim. Push hardest on the parts that feel wrong, the parts where the answer is a little too smooth, a little too confident. Be the adversarial agent in every exchange.
Earlier posts in this series gave the concrete reason this matters. A frontier model can produce an answer that is more sophisticated, more rigorously argued, and more confident than its predecessor, and still be wrong. It can defend a flawed conclusion more persuasively than a weaker model defended the correct one. The model does not signal its own uncertainty reliably. It will hand you a plausible, articulate, well-structured answer whether or not the answer is right, and the better the model gets, the better that wrong answer will look.
Which means the human role is not to receive the answer. It is to dig and test. The engineer who interrogates the AI, who treats every confident output as a claim to be checked rather than a fact to be accepted, is doing two things at once. They are catching the errors, which is the immediate job. And they are building the olfact, which is the long one, because the act of probing for what does not add up is the exact act that compiles into the sense for what does not add up. The questioning is the practice. The adversarial stance is the apprenticeship, and the engineer who adopts it is, whether they frame it this way or not, training themselves.
Two responsibilities
There is an honest limit here, and the post would be dishonest to skip it. Interrogating the AI sharpens the questions you already know to ask. It does not surface the ones you do not. The senior at your elbow used to do exactly that, the unprompted “wait, did you check the thing you did not think to check.” The AI will not do that. It answers what you ask, not what you should have asked. Self-driven practice is powerful and it is not complete.
So there are two responsibilities, and they belong to two different parties.
The engineer’s responsibility is to own the learning path. Nobody is going to assign you the curiosity. Drive the tool, then interrogate what it produced. Treat every abstraction below you as something to be opened up and understood, not delegated and forgotten. This is not careerism or self-improvement advice. It is the job. It has always been the job.
The company’s responsibility is to acknowledge the problem and plan for it instead of pretending the pipeline will refill itself. The future seniors are not a recruiting problem to be solved in 2035. They are juniors on the team right now, and the question is whether the organization recognizes them and protects the conditions that let them practice, or whether it grinds them into executors because execution is easier to measure on a quarterly basis than judgment is. Growing a senior engineer is a multi-decade investment. It will never show up well on a quarterly metric, and the companies that under-invest will not feel the cost until bring-up, years later, when the people who would have caught the problem were never given the room to become the people who could.
It comes down to curiosity
Strip everything else away and this is what is left. The engineer who questions, interrogates, and experiments will be more needed than ever, because that engineer is the irreplaceable filter between a confident machine and a tape-out. The engineer who will not, who waits to be told what to build and codes it without asking why, is not being replaced by AI so much as discovering that the role was always hollow. Coding someone else’s intent without interrogating it was never engineering. It was transcription, and transcription is precisely the thing AI does well.
This is not about juniors versus seniors. The automaton exists at every level of experience. I have seen engineers fifteen years into a career who never built judgment, because they never built the habit of questioning, and a title tracked their tenure while their olfact never arrived. I have also learned that you can predict, fairly well, how far an engineer will go by listening to the questions they ask when they are junior. The questions are the leading indicator. Curiosity shows up before expertise does, and where curiosity is absent, expertise never really arrives.
A note on how far this goes. The argument here is about the engineer’s role now and for the design generation ahead. The repeats, the basic and well-trodden subsystems, may well automate completely, and sooner than most people expect. How far autonomy climbs beyond that, into the novel architectures and the hard optimization calls, is not something anyone can honestly predict, and this post does not try to. But that uncertainty is the argument for curiosity, not against it. When you cannot predict which specific skills a tool will absorb next, the durable move is to become the kind of engineer who questions and interrogates, because that disposition keeps its value across the widest range of futures, including the ones nobody can see yet.
AI did not create this divide. It revealed it, and it removed the place to hide. When the routine coding is absorbed, what is left exposed is whether you were ever actually engineering, which is to say whether you were ever asking why. The good news is that the answer is not fixed and the practice is available to anyone, starting now, at any level, with the next exchange you have with a model. Do not accept the answer. Ask how it knows. Push on the part that feels wrong. That is where the next generation of senior engineers comes from. It comes from whoever refuses to stop asking.
Marco Brambilla is a semiconductor industry veteran with 25 years in chip design, most recently as Senior Technical Director at Meta Reality Labs. He writes about AI, chip design, and the future of hardware engineering at Above the RTL.