The cat's in the cradle and the silicon spoon

Luckily I'm not so old that I know the original version, but I did grow up with Ugly Kid Joe's cover. I know that still dates me, and it points to a problem: I'm getting middle-aged, and so are a lot of Drupal developers.

The song is about a kid who is starving for his father's time. The father is always busy, so he gives him a silver spoon instead and hopes that will be enough. When the father gets old and finally has time, the son has none left for him. I think we are doing the same with AI. We are busy, so we hand our juniors a silicon spoon (AI) instead of our time and hope that will be enough. And when we get old and want someone to take over, there might be nobody left who learned the trade.

This article will go through some of the Drupal-specific problems, the AI-specific problems, and where the silicon spoon might just make Drupal a better learning ground for the next generation.

I went to a DrupalCamp recently, and while I love the meetups, one thing is obvious: the community is getting older. And I am part of the problem.

The numbers we have say the same thing. In the 2024 Drupal Developer Survey, run by Ironstar, 9.1% of the 648 people who answered were under 30, and none were under 21. Only 9.6% had worked with Drupal for less than four years. Mike Anello wrote about it at the time in Drupal needs new, young developers.

The people who teach Drupal see it too. In April DrupalEasy ended Drupal Career Online, its 12-week beginner course, after more than 15 years. In The slow decline of beginner Drupal training Mike Anello collects the same story from other trainers: DrupalTutor has about a quarter of the students it had three or four years ago, Drupalize.me has fewer customers, Debug Academy cut its beginner programme to one semester a year, and beginner training days at events are much emptier.

Most of this started before AI. Modern Drupal is more powerful and harder for a hobbyist to pick up than it was before Drupal 8. The project knows it: in his State of Drupal presentation in October 2023 Dries listed "attracting fresh talent" as a marketing goal, and Drupal CMS got its name after testing with newcomers. AI arrived on top of a community that was already getting older.

When I think about core memories of learning, I think about the great seniors I have worked with. Some of them were crucial for my development. There are also three kinds of panic I have had during my career that had a lasting effect on my will to learn more.

At university I built a web portal where our fraternity could upload photos. Nudity was part of our hazing rituals back then (mostly good fun, and rightfully not allowed today). The pages checked that you were logged in, but the images were served straight from the web server, and one day the traffic exploded: a gay porn forum was hotlinking them. At my first job I took down the production database and spent the whole night restoring it. I learned proper CI/CD and manual testing, and the administrators learned not to give the keys to the kingdom to a junior. Then I started at Nokia, which back then was what the FAANG companies are today. The developers there were all on top of their game, my impostor syndrome was at its maximum, and I spent my nights learning concepts.

None of these lessons came from a course. Each one came from getting something wrong or feeling out of my depth, being scared enough to find out why, and having someone better than me around to explain it. The panic made sure I remembered, and the seniors made sure I learned the right thing from it.

To prove a point, I wrote a small game. You play the junior I was back then: one round the way I learned, and one round with a lifeline I never had.

Ok, I do realize that this is a fairly simplified way of showcasing the point. But the problem is that a lot of the learning that happens, happens through problem solving and information gathering. And with AI, both those steps might never happen.

Development has mostly been learned on the job. You get the small tickets: a broken template, a field that should be required, a migration that misses one value. You get them wrong, a senior reviews your code and tells you why, and you fix it. You read other people's code because you have to. After a year or two the tickets get bigger, and one day you are the one doing the review.

Those small tickets are exactly what coding agents are good at now. They are well described, low risk and quick to check. If an agent closes them, the junior never gets them, and a company has one reason less to hire the junior at all.

Daniel, a senior engineer at Amazon, wrote about this in AI is making junior devs useless. It got a lot of traction on Hacker News and is a good read. I agree with the problem: juniors used to fix the boilerplate and code what a senior had already designed, and that is what an agent does now. At the same time, if the junior doesn't use AI, the difference in speed of delivery compounds.

The hiring data points the same way. Stanford's Digital Economy Lab finds that employment of 22 to 25 year olds in the jobs most exposed to AI is 19% below where it would be if it had kept pace with less exposed jobs. The fall comes from fewer hires, not from more people being let go, and the authors say the results describe what happens without proving the cause. A Harvard study of 65 million résumés finds that junior employment at companies that adopted generative AI fell about 9% after six quarters compared with companies that didn't, while senior employment hardly moved. And SignalFire's 2026 talent report counts new-grad and entry-level hiring at twelve of the biggest tech companies about 65% below 2019, across all kinds of jobs.

Then there is the learning itself. Anthropic ran a randomized trial with 52 mostly junior engineers who learned a Python library they didn't know, Trio. The group with an AI assistant scored 50% on a quiz afterwards and the group that coded by hand scored 67%. The biggest gap was on debugging, and the AI group wasn't significantly faster. But the people who asked the AI conceptual questions, or asked for code with an explanation, kept what they learned and scored 65% or more. Those who handed the work over scored under 40%.

So AI doesn't stop people from learning. Using it to skip the work does. A junior who never has to understand the code never learns to see when the agent is wrong. I wrote about the same worry for mathematicians in The quiet math revolution: the people who can check the work don't appear from nowhere. This is the point the game above is meant to visualize.

This is where I think Drupal could have an advantage. When I vibe-configed this website, the rule was configure first, code last. The agents configured modules that already existed, and only 0.14% of the PHP is custom code. Most of what the agents made is configuration: content types, fields, views, permissions.

Configuration is easier to learn from than code:

• You can see it - every field and view the agent made is in the admin UI, in the same forms a site builder uses.
• You can review it - drush config:export writes it as YAML to config/sync, and a diff shows what the agent changed.
• It is built from reviewed parts - the code behind it is core and contrib, much of it covered by the security advisory policy, not new code that nobody has read.

That makes the agent a possible teacher for a junior site builder. The agent builds, and the junior opens what it built, clicks through it, reads the diff and explains it back. You don't need to know Symfony to understand a view, so the bar to start is lower than for code.

Compare that with how many people start today: ask an agent for an app, and it glues a Node.js or Python framework and a handful of libraries together. It works, but all of it is new code. The junior owns every line, has read none of it, and can't tell which part is the framework, which part is a library and which part the agent made up.

Starting from Drupal, with the admin UI, MCP, configuration management and an agent harness like Claude Code, is a better place to learn:

• The product is 99% there - the agent configures login, permissions, content types, forms and search from modules that already work. What is left is the 1% that makes the site yours: a small custom module, a template, a migration. The junior can spend their time on that 1% and study it properly.
• The agent works in steps you can follow - over MCP it calls one tool per step, create this field, place that component, and every call is logged. That log is a list of what was built, in the terms a site builder uses.
• Someone else maintains the 99% - core and contrib have maintainers who update them for the next version of Drupal. In glued-together code, keeping every library up to date and patched is your job.
• The 1% teaches skills that carry over - custom code in Drupal uses the same hooks, plugins and services as thousands of contrib modules, so the junior can read how others solved the same problem. Code an agent invented for one app has nothing like that around it.
• The harness keeps the rules - you can write down "configure first, code last" and "explain what you did" in a file the agent reads at the start of every session.

When the junior gets to the 1% that is code, they meet it with a working site around it instead of an empty folder. The bridge from being a site builder with some code understanding to being a vibe-configer with some code understanding is a lot shorter.

If you are a junior, or want to become one, this is what I would do. Daniel has his own list at the end of his post, and it overlaps with mine.

1. Learn the underlying technology - use AI as a rubber duck, or to ask it fundamental questions about how things work. Don't ask it how to solve something. Don't be a meat proxy.
2. Be interested in technology - both the number of people working in tech and the salaries will most likely shift. I would have worked with this anyway: I work for a lower salary so I can do open source. This probably needs to be a hobby for you too, otherwise you will have a hard time.
3. Fail - build personal projects or contribute to open source, where you can fail, have the utter feeling of fucking up, and fix it. Many of my learning moments came because I failed at things, and promised myself to never do them again.
4. Struggle - don't ask AI to solve anything for you while you are learning. Allow yourself to struggle. Ask the AI for clues or for the why, never for the how. That is also the difference in the Anthropic trial above: asking why kept the learning, handing the work over lost it.
5. Do Novice issues yourself - don't use the Novice tag for credit farming. Contribute to those issues without AI. We can already solve them with AI; they are there for people to learn how to contribute and code.
6. Contribute a project - even if it is small, it is yours and you understand it.
7. Always understand what you are committing - this goes for any developer. But be ok with telling your senior that you have problems solving something. And seniors: make time for your juniors.

I don't think this is lost, but it won't fix itself. Most of what we need already exists:

1. Hire juniors anyway - with the IXP programme, an organization that hires a newcomer for at least 160 paid hours, with at least one hour of mentoring per ten hours worked, gets 250 contribution credits.
2. Give juniors breathing room to learn - don't judge them only on how fast they close tickets. Let them take the slow way through a problem now and then, because that is where the learning happens.
3. Make "I don't know how to solve that" ok - let juniors know that it is fine to say, and that you want them to become seniors, not meat proxies.
4. Give juniors the agent, and have them explain its work - review the config diff together, ask why the view was built that way, let them fix what the agent got wrong.
5. Keep some small issues for people - the Novice tag marks tasks that take an experienced contributor up to 30 minutes. Leave some of them for a first-time contributor instead of an agent.
6. Send juniors to DrupalCons and DrupalCamps - that is where they meet the people behind the modules they use, and where a contribution day can give them a mentor and a first issue.
7. Be there when newcomers show up - the first-time contributor workshop at every DrupalCon, mentors on contribution days, and Drupal CMS as the first Drupal a newcomer installs.

Drupal might have a better starting point than most, because so much of a site can be built, and learned, without writing code. But someone still has to write the code. If we want seniors in ten years, we need to hire juniors now.

If you want to go deeper, watch Kristiaan Van den Eynde's great talk A future without juniors from Drupal Dev Days Athens 2026. He asks the same question: if AI means fewer juniors get hired, who builds our future?