The LLM Generation: Tough Times for Juniors
We are witnessing a silent crisis: young developers are no longer learning to code.
How many of them start their professional careers armed with powerful LLMs for just 20 or 40€ a month? The temptation is too great: they use them for everything and prompt away like crazy. However, lacking any method, understanding of architecture or testing, or—more broadly—any idea of what it means to maintain software over time, they settle for a program that works in broad terms and accumulate technical debt left and right. Letting them do this does no one any favors, least of all them: you can’t delegate the cognitive effort involved in learning.
Should we blame them? Certainly not.
Let’s clear up a possible misunderstanding right off the bat: this editorial is anything but an attack on LLMs. In the right hands, they are formidable accelerators of thought and action—wonderful challengers and facilitators that allow us to work at a higher level of abstraction. Day after day, we discover the possibilities and limitations of these tools and learn to let go, as use cases become clearer and productivity gains become more evident. LLMs are here to stay, provided we view them as just one tool among many (see Law of the Instrument).
Today’s apprentice developers therefore have remarkably powerful tools at their disposal. But to use them effectively, we need to know what to ask of them beyond the basic “develop my feature” and what to check once that feature has been produced. For example, avoid writing code that straddles two contexts—this undermines all efforts at modularization. Or implement a simple hexagonal architecture to isolate and test the domain. These are two considerations that have no visible impact on the user but make all the difference. “It works” simply isn’t enough.
It is therefore the responsibility of the most experienced developers and organizations to mentor them and impart the fundamentals of software development: architectures, methodologies, paradigms, languages, and—beyond that, though this can be learned to a certain extent—rigor and critical thinking. These are, at their core, values: a commitment to excellence and continuous improvement, and thus a tradition of mentorship that must be perpetuated—though perhaps we should say established, and therein lies the problem.
This work is an extension of the mission of schools and other institutions of initial training. That’s another topic, but it’s clear, once again, that they’re falling short of the mark. How many private schools and boot camps have flooded the market with developers—young and old, but all beginners—without teaching them any of the fundamentals of the profession? On closer inspection, the advent of AI-assisted programming merely reveals and amplifies a skills gap specific to our industry.
It is obviously in the best interest of the companies themselves, since today’s junior developers are tomorrow’s senior developers. Any company planning for more than five years ahead will necessarily want to hire and train early-career recruits.
In fact, they ask for nothing else, being well aware of the problem themselves. Even if they don’t know what they don’t know, many of them sense that something is wrong: “If development is as simple as that, anyone should be able to do it, right?” Just last week, an intern described his latest internship in these terms: “Six months at a Parisian startup, alone with my LLM. Whenever I asked questions, they just referred me back to the LLM.” And this other one, even more direct: “Show me how to do it, because I never learned—I started out with LLMs.”
Whether these technological advances will create or destroy jobs remains a difficult question to answer. One thing is, unfortunately, certain: junior developers are, as of today, the first to be sacrificed to AI. Even when, by some miracle, they manage to get hired, they still need the opportunity to learn their trade.
Let’s remain hopeful, however, that things will change. The bubble will burst sooner or later, as technical debt continues to accumulate. Soon, the sorcerer’s apprentices will face the facts: what they produced with Lovable was fine for a POC or demo but should never have gone into production. Add a few more months during which they’ll wrestle with their egos before finally coming to terms with the reality: the developer’s craft is changing, but it’s not dead.