A long essay arguing that AI coding tools can interfere with professional development rather than strengthen it has become a flashpoint in the developer community this week. The author, engineer Lars Faye, is not arguing that people should stop using AI. He uses these tools himself every day. His point is narrower and sharper: when AI finishes the code for you, it can also remove the friction that helps engineers build judgment.
According to BlockTempo, the essay reached 558 points and 542 comments on Hacker News. Faye frames the issue around one basic question: how expertise is formed over time, and what happens when the difficult parts of that process are outsourced too early.
Expert tools still require expert judgment
Faye introduces what he calls the “skilled orchestrator paradox.” In his telling, using an AI agent well requires abilities that usually come from years of engineering practice: writing clear specifications, understanding architecture, and spotting what is off in generated output at a glance. Those are not beginner skills. Yet if AI keeps taking over the work that would have built them, their development slows or stalls.
He says the people benefiting most from these models right now are often those who had already spent 10 to 20 years building experience before AI tools arrived. In that sense, AI amplifies judgment that already exists. It does not automatically create it.
That leaves newer developers in an awkward middle ground. Faye describes them as something close to “expert-level novices”: people with little tenure, but under pressure to use AI tools to raise output. Company messaging, in his view, is contradictory. One side says workers who do not use AI will fall behind colleagues, echoing the line from 2023 that “AI won’t replace you, but someone using AI will.” The other side warns that vibe coding is a dead end and that anyone aiming to become a senior software engineer still has to write good specifications, understand every line of output, and verify code before shipping it.
That is the contradiction at the center of his essay. Today’s AI tools assume you are already an expert, but they do not necessarily help you become one.
The missing friction in learning
Faye uses cooking to make the point concrete. If someone wants to learn to cook, they could stand beside a great chef and keep asking questions. After a month, that person might be able to talk fluently about how to prepare a perfect medium-rare ribeye. But if they have never actually cooked the steak themselves, the odds of overcooking it when the moment arrives are still high.
He says software works the same way. The bugs with no obvious logs, the performance differences that only appear at scale, the architecture that has to be rewritten halfway through because it will not hold up — all of that is training. Faye uses the German word Fingerspitzengefühl to describe the instinct that develops from repeated contact with those situations: the fingertip feel that lets someone look at code and sense that something is likely to go wrong. Skip the early struggle, and that instinct may never form.
A compass that always points north
Faye argues that learning with large language models flips the usual teacher-student relationship. Traditionally, a teacher leads and a student follows. With an LLM, the student acts first, the model responds, and the student then tries to adjust course. He calls this inverted learning.
The weakness, he says, is that LLMs are highly sensitive to prompt shape. When people enter a domain they do not understand, they often do not know what they do not know. That means they cannot reliably ask the question that matters most. Faye compares this to a compass that always points north. It can tell you where north is, wherever you stand. It cannot tell you where you are.
For that reason, he argues that the real gap in these systems is not knowledge volume. It is judgment, empathy, and teaching intent. The model’s solution does not grow out of understanding, in his view; it is interpolated from patterns in training data. Once a user settles into generated solutions, the work tends to stay there, and the friction that might have helped build a mental model disappears. Faye adds that even senior engineers can be “contaminated” by this pattern.
What the studies cited in the essay found
One of Faye’s main references is The Widening Gap, a 2024 paper presented at the ACM Conference on International Computing Education Research, written by James Prather and eight other researchers. The paper examined how novices behaved while actually writing code. JetBrains has also recently cited the same research.
Faye says the results ran against how the learners felt about the tools. Many thought they had gained a private tutor. The data suggested otherwise.
In the group that relied heavily on AI, learners often skipped the planning stage because the reasoning had effectively been offloaded to Copilot. When they finished, they came away with what the researchers described as an illusion of competence rather than real understanding. The most confident beginners, and the ones most comfortable handing work to AI, were also the ones more likely to skip critical steps in solving the problem and lose their way.
The restrained-use group looked different. They developed what the researchers called “negative expertise,” meaning the ability to ignore incorrect or unhelpful AI suggestions. They used AI to accelerate things they had already intended to write. In the study overall, the best-performing novices were those who either used AI sparingly or did not use it at all.
Math students and developer trust tell a similar story
Faye also points to a University of Pennsylvania study that tracked 1,000 students using LLMs to learn math. In that study, the group using AI as a crutch ended up scoring 17% below students who had only textbooks.
On the industry side, he cites Stack Overflow’s 2025 developer survey. The survey covered 48,945 people, including 26,004 professional developers. It found that 84% were using or planning to use AI tools, up from 76% in 2024. But only 3.1% said they had high trust in output accuracy, while 19.6% said they had high distrust.
The split becomes more striking by experience level. People still learning to code posted the highest rate of high trust, at 6.1%. Developers with more than 10 years of experience had the lowest, at 2.5%. Their high-distrust rate reached 20.7%, also an extreme in the data. Faye’s reading is blunt: the people least able to verify output are often the most willing to trust it.
Use AI as a tutor, not a laborer
The second half of the essay is where Faye offers a practical alternative. He does not tell readers to quit AI. He tells them to change how they use it.
Anyone trying to get better at programming, he argues, should largely ignore the model’s code-generation side and lean on its other strengths. That means treating an LLM as interactive documentation, a resource that can be questioned repeatedly, or a Socratic sparring partner rather than an answer machine.
He says the University of Pennsylvania research offers support here too. The researchers also tested a “tutor version” of GPT that did not give answers directly when students got stuck. It guided them through the process instead. That group performed much better during practice. The key difference was that the cognitive work stayed with the student. The friction remained, so the learning left a mark.
Abstraction saves labor, not study time
Faye explains the importance of sequence through abstraction layers. Someone learning Java should not start with Spring Boot, he says. Someone trying to build strong JavaScript fundamentals should not start with React. Someone aiming to get very good at CSS should not start with Tailwind. In his framing, LLMs may be the ultimate abstraction layer.
He borrows a line to make the point: abstraction layers save work time, but they do not save learning time.
Faye’s five-question checklist
Before pressing generate, Faye suggests asking five questions:
- Am I using this model to deepen understanding, or to bypass understanding?
- If I had to audit and verify this output right now, could I clearly explain what it is doing?
- Have I done enough homework to know what I should be asking?
- Have I cross-checked this approach elsewhere, such as official documentation, general search, or Stack Overflow?
- Is this repetitive routine work, or a task that requires my own decisions and judgment?
He also warns that even the “AI as tutor” approach carries risk. Models can still hallucinate. They cannot serve as the only source of learning. If a user lacks the ability to audit generated code for correctness, Faye argues, that user also lacks the ability to audit generated concepts for correctness.
Productive struggle versus unproductive struggle
Another part of his framework is learning to identify the kind of difficulty a person is facing. “Painfully stuck” is not always bad, he says. The challenge is to separate productive struggle from unproductive struggle, then resist sliding back into asking for the answer too quickly.
He quotes Kent Beck, the creator of test-driven development, to support the point that programming itself is one of the best ways to consolidate understanding. The more someone writes, the deeper their grasp of the field becomes.
Faye is explicit that this path is hard. Choosing the slower, clumsier route can mean producing less than coworkers in the short term, while the broader software ecosystem pushes in the opposite direction. Companies are mandating AI use. AI is being built into more IDEs. Some tools even collapse code review views by default unless users click to open them. He adds that if a company truly believes every task should be handed fully to AI, it will eventually learn its own lesson.
The larger wager behind the debate
For Faye, the stakes go beyond individual productivity. He asks whether software expertise itself could become discontinuous across generations.
He frames the question plainly. If models can generate code, design systems from patterns in training data, and debug problems they created themselves, what is the point of learning those skills at all? He says that is exactly what a multitrillion-dollar wager is betting on now: that a gap in professional formation may not matter because LLMs will be there to fill the role.
He writes that if the industry keeps focusing on lines of code and tokens spent, while fewer people continue down the path of genuine skill development, Sam Altman’s vision of selling intelligence like metered electricity or water could become reality. In that world, a person sitting down to write software without AI at hand could simply stall out.
The labor impact is no longer theoretical
Faye closes by pointing to changes already unfolding outside the classroom and the editor. Fortune reported last week on a 40-year-old programmer in Beijing, Fei Zhaojun. After his boss asked whether AI might soon replace people who write code, Fei and about 160 colleagues were laid off two weeks later. The same report said the share of Chinese industrial companies using AI models rose from 9.6% to 47.5% in one year.
Fei’s own judgment was that mid-level engineering work can, in many cases, be replaced. He also offered what Faye presents as one of the bluntest lines in the discussion: even if this eventually turns into a disaster that replaces all humans, right now you still have little choice but to use it along with everyone else.
Questions at the center of the discussion
Why do some people say AI coding can obstruct growth?
Faye’s argument is that using AI agents well already requires the ability to write specifications and judge output quality, and those abilities come from the friction of solving problems by hand. The ICER 2024 research adds that novices who rely heavily on AI often skip planning and finish with an illusion of competence.
How should people use AI without weakening themselves?
Faye’s answer is to treat the model more like interactive documentation or a Socratic coach than an answer generator. The University of Pennsylvania study supports that direction: the tutor-style GPT led students through the process instead of giving direct answers, and that group performed far better during practice.
How much do developers actually trust AI-generated code?
Stack Overflow’s 2025 developer survey found that 84% of respondents use or plan to use AI tools, but only 3.1% report high trust in output accuracy. Among developers with more than 10 years of experience, that figure drops to 2.5%.