Erick Wendell: becoming an AI code reviewer exposes a crisis in developer training

In an interview with Gabs Ferreira, instructor and content creator Erick Wendell described something that most people who code today recognize in their own routine: the feeling of having effectively become a reviewer of prompts and model-generated diffs, rather than someone who writes code from scratch. Wendell calls this a "crisis" and places the moment in November, when he started asking himself what exactly was left of engineering work, faced with the question that sums up the conversation's unease: if Claude does the work a junior would do, what's left for the person coding?

The full interview is available in the source sent for this piece, but the core of the conversation is worth more than the viral clip: it isn't about "AI will take your job," it's about what changes in practice for those who already work with it and along the path of those who are just starting out now.

The layer of abstraction isn't new, it's just gotten higher

Wendell's central argument is that generative AI didn't invent a new problem, it stacked one more layer of abstraction on top of discussions engineering had already been having for decades. He cites as an example the classic question of whether a junior should learn to use a framework or do everything from scratch first. "The questions have always been the same," he says in the interview, including a reference to a recent post attributed to Robert C. Martin (Uncle Bob) saying that he no longer even reads code, just the mechanics that pass through it.

This matters because it shifts the discourse from moral panic to technical responsibility: if the problem has always been "how far do I need to understand what's underneath before trusting the abstraction," then the work of those who build systems hasn't disappeared, it has just moved up a level. A developer who uses Rails without understanding the SQL underneath already lived with this dilemma before any LLM existed. The difference is the speed with which today's abstraction delivers functional code, and that's where the real risk lies: AI-driven abstraction gets things wrong in a much more convincing way than a framework used to.

The college experience Wendell describes has already changed order

One of the most concrete points in the conversation is the comparison Wendell draws between his own education and that of his brothers, who are now studying Systems Analysis and Development (a common Brazilian college program for IT careers). In his class, three hundred students started and only thirty made it to the end of the program, because the first semester was pure filtering: data structures and SQL with no context whatsoever for what any of it was for, and whoever couldn't handle abstraction without purpose dropped out. His brothers learn in the reverse order: first they build an application with low-code tools, model a database with a few clicks, see the app working end to end, and only afterward go back to refine the piece that doesn't work well.

Gabs Ferreira reinforces the same point from his own experience: it took him two years to understand what a real system was, because he was stuck building command-line applications in the terminal without ever seeing the whole picture. It's a pedagogical argument worth taking seriously beyond the clip: teaching backwards, starting from the working system and going back to the reason for the data structure, is more similar to how people who already work solve problems day to day (first understanding the symptom, then digging into the cause) than the traditional linear curriculum model.

If AI does the junior's job, why hire a junior?

That's the question Ferreira poses directly, and it sums up the market anxiety around the topic. Wendell's answer isn't "it won't make a difference," it's that the definition of junior changes shape. Instead of someone hired for knowing a language's syntax, the junior of the future described by Wendell is someone who gets a concrete task ("there's a bug, when you double-click the button the screen freezes, fix it"), writes the prompt, solves the problem, and above all asks questions about why that bug existed and how the solution works. This pushes the learning curve up faster: instead of spending months just understanding syntax, the junior is thrown straight into system design questions, with one more layer of abstraction between them and the raw code.

It's an honest argument, but incomplete if it stops there: the risk the interview doesn't resolve is what happens to those who never developed the habit of asking these questions, because the AI has already delivered something that "seems" to work. The pressure on junior training isn't just "learn faster," it's ensuring the junior keeps training the muscle of doubting their own code, even when they didn't write a single line of it.

Code has stopped being the most important thing, but not in the way it seems

Wendell uses an example from a financial system to illustrate where human judgment remains irreplaceable: if an app takes five seconds to load, that might be irrelevant to most users; if a payment via Pix, Brazil's instant payment system, takes twenty seconds, that's a serious problem. The difference between the two cases isn't in any specific line of code, it's in understanding the domain, user expectations, and the cost of getting it wrong, something no model today infers on its own without someone deciding what matters.

The comparison he makes to aviation ("would you 100% trust someone who doesn't understand mechanics to command that?") is useful, and it's worth extending the reasoning: automation systems, in general, reduce the cognitive load of routine work, but create a specific risk when the human needs to take back control without having kept their mental model updated on what the automation was doing. It's the same trap awaiting anyone who reviews AI-generated code without ever having written the equivalent logic themselves: the moment something breaks in production, the mental model that only gets built by writing is missing.

The experiment: 30 hours of AI working alone at night

The most concrete part of the interview is the experiment Wendell describes: an open source project in which he imposed on himself the rule of not touching the code or reviewing anything, only observing how the AI performed without intervention. In total, the project accumulated more than 60 hours of AI work, of which 30 hours happened at night, while he was out (in his own words, "I'd go to the bar and it would keep working alone"). The initial conclusion he draws is that, to start a project from scratch, AI today does very well on its own.

The point where the interview gets most interesting is exactly where the available transcript cuts off: Wendell begins to explain that maintaining the project over time is where "things become" a different kind of problem, and the account stops there. But the excerpt is enough to expose the asymmetry that any team already using coding agents in production recognizes: starting a project is the easiest scenario for generative AI, because there's no accumulated history of decisions, no technical debt, no three sprints' worth of context the model needs to rebuild with every prompt. Maintaining is a different game: it requires remembering why an architecture decision was made six months ago, understanding the side effect of a change in a module nobody has touched in a while, and noticing when a model's suggestion is syntactically correct but semantically wrong for that specific system.

Why reviewing is harder than writing

Here the interview stops short of closing the argument, but this piece's angle calls for exactly this question. Writing code from scratch forces the person coding to make each decision sequentially, and that naturally builds the mental model of why the system works that way. Reviewing an AI-generated diff reverses that order: the decision has already been made, and whoever reviews it has to reconstruct the reasoning behind it just by looking at the result, without the benefit of having lived through the trial-and-error process that led there. It's easier to trust that something is right because it compiles and passes tests than to actually verify whether the logic reflects the original intent, especially under the pressure of reviewing dozens of suggestions a day.

This is the real bottleneck left open in the conversation between Wendell and Ferreira: junior training that prioritizes prompting and asking "why" solves part of the problem, but it only works if the team's culture actually sets aside time for that question, instead of treating review as a bureaucratic step between generating code and merging. Without that space, the team doesn't just become an AI reviewer in the good sense (critical and demanding), it becomes a reviewer in the bad sense: someone who rubber-stamps approval because the code looks right.