Everyone keeps telling juniors they are finished in the age of AI. I think it is exactly the opposite. If I were starting out today, I would be more excited than at almost any point in my career. Let me tell you precisely what I would do, and where the honest catches are.
First, the hard part, because pretending otherwise would not respect you. Entry-level developer hiring has dropped 67% since 2022, and new-graduate hiring at the largest US tech firms has more than halved since 2019. Companies are pausing junior hiring and some are letting juniors go, because one experienced person with agentic tools can now do work that used to take a whole team. If you are at the bottom of the ladder, that is a frightening thing to read. I have written before about why this is genuinely dangerous for the industry: the training ladder is broken, and nobody has a plan to fix it. That is the structural problem, and it is real.
But here is what almost nobody is telling you, and it is the more important half of the story. The same technology that broke the old path can hand you a faster one, if you have the discipline to use it well.
The old apprenticeship is gone, and that is not all bad
For decades, becoming a good engineer meant time served. You joined a team, you were handed the small, unglamorous work, and over five or six years you slowly absorbed how real systems are built, how they fail, and how the people around them think. It worked, but it was slow, and it was gated. You needed someone to let you in before the learning could begin.
That gate is exactly what has narrowed. The tasks juniors used to cut their teeth on are the tasks agentic tools now absorb in seconds. So the apprenticeship that ran on those tasks is disappearing. I will not pretend that is painless. It is the central reason junior hiring has fallen off a cliff.
What gets missed in the panic is that the learning never actually depended on the gate. It depended on doing the work and understanding it. And for the first time in this profession, you can do that work, at volume, without anyone hiring you first. I want to be precise about what speeds up and what does not. The reps speed up enormously: the number of real problems you can face, and the feedback you can get on each one, is far higher than anything I had access to. The judgement does not speed up the same way. That is still built slowly, through failures you have to sit with. So you reach the hard lessons faster. You do not get to skip them.
What to build: a one-person product, not toy projects
Tutorials and courses give you the comfortable feeling of progress without much of the substance. You follow along, everything works, and you have learned almost nothing that survives contact with a real problem. The learning lives in the friction: the bug you cannot explain, the design decision with no obvious right answer, the thing that worked on your laptop and fell over the moment a real person touched it.
So skip the toy projects. Start a one-person product. I mean that literally. It costs almost nothing now, the tools are cheap or free, and you do not need investors. Pick something small and real that you understand, build it, ship it, put it in front of actual people, and try to charge for it.
Most of these will go nowhere, and that is fine. Build the next one. The point is not the exit. The point is what each attempt teaches you that no course ever could. Charging for something, even badly, forces questions a tutorial never asks: who is this actually for, why would they pay, what happens when it breaks at two in the morning, and what did I get wrong about the problem in the first place.
Here is the honest catch, because the cheerful version of this advice skips it. Most solo projects will look, to an employer, exactly like a tutorial repo. What separates a credible build is specific and small: a handful of real users who are not your friends, one architectural decision you can defend out loud, and a written post-mortem of what broke and why. One project with those three things beats ten that have none.
Use AI as a tutor, not a crutch (how to learn instead of copy-paste)
This is the part most people get backwards, and it is where the optimism is either earned or wasted. Used well, AI is the closest thing a junior has ever had to an infinitely patient senior engineer. Used badly, it is a machine that hands you working code and leaves you knowing nothing.
I want to take the strongest objection to this head-on, because it is sitting in the article I just linked. Anthropic ran a study where junior engineers using AI scored 50% on comprehension tests, against 67% for those who coded manually, and the widest gap was in debugging, the exact skill that separates a competent senior from a dangerous one. That is real evidence that learning by AI tends to produce weaker understanding. I am not going to wave it away.
What that data actually measures is passive use: accept the output, move on, never internalise it. The gap is the cost of copy-paste. So the discipline that closes it has to be specific, not a slogan. When the model writes something, do not paste it and move on. Ask why it chose that approach, what the alternatives were, and where it will break when ten thousand people hit it at once. Read the output until you understand it well enough that you could have written it yourself, then change one thing and watch what happens. Used that way, the comprehension gap is not inevitable. It is a habit you refuse.
I will be honest about the catch here too, because it is the real one. That discipline is hard, and it is rare. The instinct to interrogate every answer is exactly the trait that already separates good learners from the rest. Which means AI does not hand the speed-up to everyone equally. It hands it to the people who would have learned well anyway, and now learn faster. If you can build that habit, you have an enormous edge. If you cannot, the tool will quietly teach you nothing while feeling like progress.
Learn the architecture, not just the syntax
Writing code that works is the easy part now, and it is getting easier every month. The durable skill is judgement: knowing why one design is sound and another is a trap, where systems scale and where they quietly fall over.
So push your own product until it breaks, on purpose. Load it. Watch what fails first. Learn why a naive approach that was fine for ten users becomes a disaster at ten thousand. Read about the principles behind the patterns the AI keeps reaching for, so you understand the reasoning rather than just the recipe. This is the part of engineering that does not show up in a demo, and it is exactly the part that decides whether a system survives. It is also, not coincidentally, the part employers are most desperate to find in someone young.
Learn the business, not just the code
Here is the lesson it took me far too long to learn myself, and I have written a whole piece on it: for a natural technologist, the engineering was always the easy part. The engineers who become genuinely indispensable are not the ones who write the cleverest code. They are the ones who understand how their work moves the company forward.
I learned this the expensive way. Across four ventures I built things that were, technically, excellent, and some of them still underperformed, because I was solving the engineering and missing the business reason underneath it. A clean build on a weak foundation is still a failure, just a well-engineered one. Running your own one-person product teaches you that for free, because you have no one else to blame. You are the engineer, but you are also the person deciding what to build, who it is for, and whether it is worth building at all. You will make bad calls. That is the education. By the time you sit in an interview, you will be able to talk about technology in the language of outcomes, which is rarer in a junior than any framework on a CV.
Then walk in with proof
When you interview, do not arrive with a polished CV and a list of courses completed. Arrive with a GitHub full of things you built and taught yourself. Here is the product. I built it. I shipped it. I put it in front of real people, I learned why the first version failed, and here is the principle I worked out on my own that made the second one better.
I have hired juniors exactly like that, off a strong GitHub, over candidates with cleaner transcripts and nothing shipped. Some of the best engineers I have ever worked with came in that way. I will not pretend every hiring manager thinks like me. Plenty still filter on degrees, referrals, and years served, and the funnel for any junior right now is brutal. But the proof of self-directed building is the rarest signal you can send, and it travels further than a grade. One candidate has proven they can be told things. The other has proven they can teach themselves and ship. Over a career, only one of those compounds.
That same instinct, by the way, is what the best engineers chase once they are in. They do not optimise for the biggest offer. They go where the environment lets them do their best work, which is the real reason big tech wins the talent war, and it isn't the money. The thing that wins is a place that takes your growth seriously. Early on, you have to be that place for yourself.
The bottom rung moved. It did not disappear
So no, I do not think this is a terrible time to be starting out. I think it is one of the most interesting times there has ever been, for the people willing to see it clearly and do the harder version of the work.
The ladder did not vanish. The bottom rung shifted, in a direction that rewards initiative more than it ever has, and asks more discipline in return. The juniors who win over the next few years will not be the ones waiting to be trained. They will be the ones who picked up the most powerful learning tool ever made, refused to let it think for them, and quietly outpaced everyone who waited for permission.
If you are starting out and trying to work out where to point all this energy, or if you hire juniors and you are rethinking what a yes actually looks like now, I would genuinely enjoy that conversation. Let's talk.
Related: The training ladder is broken. And nobody has a plan to fix it · After 20 years as a CTO, I learned the engineering was the easy part · How big tech wins the talent war, and it isn't the money · How I work with engineering teams
