Let’s call him The Engineer.

Two months in, The Engineer brought down a service he did not know existed. The bug was in a module he had generated, deployed, and not read. The fix was one line. The explanation of why it was one line took forty minutes, and I was not sure by the end that it had landed. We hired The Engineer again six months later. Different person. Same GitHub energy. Same velocity. Same outcome`.

A great LLM handed to a great engineer produces something exceptional. Hand the same model to someone who does not deeply understand what they are building, and you get something confidently, efficiently wrong. The LLM has no opinion about the quality of the input. It amplifies whatever is already there. Let’s call our senior engineer also The Engineer, because her title is the same and the comparison is the point.

The second Engineer spent years doing work that does not appear on a resume. Debugging sessions that lasted until the problem was solved, not until she got tired. Rewriting modules not because someone asked her to, but because she could not ship something she did not understand. My old football coach ran the same twenty passing drills every session for three months before we were allowed near a match. By the time we played, those patterns were in our feet. The second Engineer learned to code the same way: by doing the boring part until it became instinct.

She uses AI extraordinarily well now. She knows exactly what to delegate and exactly what to verify when the output comes back. She catches the confident errors. The model is a multiplier on top of a foundation nobody gave her. She built it through years of doing things the slow way. The first Engineer skipped the boring part. The LLM let him.

Here is the uncomfortable part: The first Engineer is not wrong. He is responding rationally to the market he entered.

Universities today are graduating engineers who used AI throughout their education. If you do not, you fall behind peers who do. The bar for junior output has risen because AI tools make the baseline look like the work of someone much further along. To compete at entry level, you use the tools. This is simply true.

We have noticed this consistently: junior engineers who used AI throughout their education produce better initial outputs than those who did not. They also fail our debugging exercises at roughly twice the rate. The demos are polished. The foundations are hollow.

The market created this incentive. The juniors followed it. I would have too.

The counterargument is real: every generation thought the previous abstraction made engineers soft. Assembly to C. C to Java. The abstraction climbed and good engineers adapted. Maybe this generation builds its foundation through reading and critiquing AI output rather than writing from scratch. Maybe that produces something equivalent.

Maybe. I hired The Engineer five times before I stopped being sure what I was selecting for.

The seniors we have today built their foundations in an environment where the boring part was unavoidable. Debugging had no shortcut. Understanding came from breaking things and rebuilding them. That environment no longer exists for engineers entering the field now.

Something has to replace it. Nobody has decided what. Universities have not decided. The companies doing the hiring are certainly not going to decide, because they are incentivized to get output, not to rebuild someone’s foundation on company time.

The boring part was the school. It got cancelled. The question nobody is asking is what grows in its place, and whether we will notice the answer before it matters.