If you’re thinking about getting into software engineering right now, the vibes are terrible. Every second post on social media tells you the career is dead: AI writes the code, nobody hires juniors, the golden age is over so pack it up.
I understand why people feel that way, and some of it is genuinely true, but the full picture is messier than the doom scroll suggests and a lot more hopeful. I’ve been building software for over a decade, these days as a principal engineer with AI tools open every working day, so here’s what I think you need to know before you write the whole thing off.
Why the market is rough right now # #
The numbers aren’t great. Stanford ran the analysis across 25 million payroll records and found employment for software engineers aged 22 to 25 has fallen roughly 20% since late 2022. New-grad intake at the big players has thinned right out, and Harvard found firms adopting AI cut junior hiring by 7.7% against those that didn’t.
That’s all real, and it means the entry-level funnel has structurally narrowed.
What gets lost in the noise is everything else happening at the same time. There’s a recession on. The IMF cut its global growth forecasts, Australia’s RBA hiked rates, and tech laid off 142,000 people in the first five months of 2026. Plenty of economists reckon a lot of that is AI washing: companies announcing layoffs and pinning them on AI when they’ve barely deployed it. “We let people go to focus on AI” sounds a lot better on an earnings call than “we over-hired in 2021”. The real drivers look more like that correction, plus the cost cutting that pays for those enormous AI infrastructure bills.
Deloitte’s read is that the real AI labour-market impact in Australia is still a year or two out, while the macro slowdown is biting right now. These are two different forces. They compound each other, but they aren’t the same thing, and conflating them makes the picture look more terminal than it is.
So the career isn’t dead, but I won’t sugarcoat it either. The easy on-ramp is gone, breaking in now takes longer and more deliberate effort than it did five years ago, and some people who would have made it then won’t make it now. That’s a real cost, not just bad vibes. The rest of this is about giving yourself the best shot at being one of the people who does make it.
What AI replaced, and what it didn’t # #
AI coding tools got dramatically better around November 2025. Models like Claude Opus 4.5 and GPT-5.2 crossed some invisible capability line, and a whole class of harder coding problems suddenly opened up. By mid-2026 senior developers were reporting that over half their shipped code is AI-generated. I’m one of them. Most of this blog gets specced and prompted up these days, and I review what comes back rather than typing it all by hand.
What got automated is the typing, the mechanical act of translating a known solution into syntax. Anthropic published numbers showing Claude now authors over 80% of the code merged into their own codebase, and that their engineers merge eight times as much per day as they did in 2024.
What didn’t get automated is the thinking: working out what the business actually needs, choosing an architecture that won’t fall over in a year, knowing why one approach dies at scale while another holds. It’s debugging the thing where the error message tells you nothing useful, and making the call when you’ve only got half the information you’d like.
Put crudely, the split looks like this:
| What the AI handles now | What’s still on you |
|---|---|
| Writing a component or boilerplate | Working out what the business needs |
| Turning a design into markup | Choosing an architecture that lasts |
| Implementing a well-specified feature | Knowing why one approach dies at scale |
| Translating a known solution into syntax | Debugging the error that tells you nothing |
Roychoudhury and Zeller put a number on it: at least half the effort in software engineering goes into maintaining and understanding software that already exists. That’s knowledge you earn through experience, it isn’t sitting in any training set, and every bit of it can still be learned.
The skill floor has risen # #
Five years ago you could land a junior role by knowing JavaScript and React, putting a few todo apps in a portfolio, and interviewing well. That bar has moved up a long way.
The baseline expectation isn’t “can you write code” anymore, it’s “can you think about software.” Here’s what that looks like in practice.
Understand the why. Every feature exists to solve someone’s problem, and if you can’t say who that someone is and what you’re solving for them, you sound like a model emitting output with no sense of purpose. Product thinking used to be a nice extra, and it’s now one of the things that actually separates candidates.
Learn to review and verify what AI produces. This is the core competency now, the one I’d weight highest. Veracode found AI-generated code introduces security holes in 45% of cases, and over 40% of junior developers admit to shipping AI code they don’t fully understand. When review breaks down it shows: Faros AI calls the result Acceleration Whiplash, teams shipping faster and breaking more in the same motion.
The engineers getting hired are the ones who can drive these tools well and catch them when they’re wrong. Treat the AI as a fast colleague who is occasionally confidently wrong, and whose work you always read before it lands.
Go deeper than syntax. Understand how the system actually behaves: how a request travels from a browser to a database and back, and what happens when something fails halfway through. Know why a particular database makes sense for one problem and is the wrong call for another. That systems-level understanding is exactly where the models are weakest, and it’s a lot of what you’re really being hired for.
Build real things that run in production. Things real people use, even if real means ten people, rather than another tutorial or clone. Shipping something properly forces you to handle edge cases, deal with errors, deploy the thing and keep it alive, and you’ll learn more from that than from any amount of AI-assisted prototyping.
How to get in now # #
I get asked some version of this more than I used to, and my honest answer is that the routes that work in 2026 aren’t the ones that worked five years ago. Big Tech grad programs have shrunk hard, but FAANG was never the whole industry, and the rest of it is much bigger.
Smaller companies and consultancies are still hiring juniors, because they need people who’ll wear several hats at once. You don’t get the brand name on your CV, but you get exposure to the full spread of problems: infrastructure, product, talking to actual customers, keeping things running. I’d take that over writing microservices somewhere you never meet a user.
In-office roles have an edge at the moment. When a company is nervous about taking on juniors, being physically there and visible counts for a lot, and you absorb things from senior engineers by sitting near them in a way that just doesn’t happen over Slack.
Specialise early in something close to the AI work, like security, cloud infrastructure, data engineering or ML ops, because that’s where demand is strongest and oversupply is thinnest. In Australia, cybersecurity engineers are still on the national skills shortage list even though general software engineers have dropped off it, so pair solid software fundamentals with one of those specialisations and you’re in a far better spot.
Find a peer group. The junior experience in 2026 is isolating, more than people admit, and the ones who make it through tend to have a cohort around them: meetups, Discord servers, study groups, open source projects. I don’t mean networking in the LinkedIn sense, I mean other people in the same boat to keep you sane and learn alongside.
You still need both fundamentals and AI fluency # #
There’s a trap doing the rounds at the moment that says you don’t need to learn to code anymore because the AI does it for you. That’s wrong, and following it will hurt you.
You need the fundamentals. If you don’t know what a function actually does, how data moves through a system, what happens at the network level, or how state gets managed, you can’t review AI output properly. You can’t debug it when it goes sideways, and you can’t see the architectural mistakes that pile up over months. You end up being a proxy for the model instead of the person directing it.
So get deliberate about building them, and there are three areas worth going after. Algorithms and data structures, so you can reason about why one approach is fast and another crawls, and read a chunk of code and tell what it costs. System design, so you understand how the pieces fit: where caching and queues belong, how services lean on each other, what happens when one part falls over. And the layer underneath all of it, how networks, memory and processes really behave, which is what bites you when something breaks at 2am.
The material has never been more accessible, and most of the best of it is free. For algorithms, Grokking Algorithms is a friendly way in and NeetCode walks you through the common patterns. For system design, the free System Design Primer covers a huge amount of ground, and Designing Data-Intensive Applications is the book worth the effort once you’re ready for it. Julia Evans’s blog explains networking, debugging and how systems actually work better than just about anyone, and Teach Yourself CS lays out a full self-study path if you want one. Pick a couple and go deep, rather than collecting tabs you never open.
None of it sticks by reading alone, so write code every week. A few hours on a hobby project you actually care about will teach you more than a course you half-finish. Keep a steady drip going, a bit of reading and a bit of building each week, instead of cramming it in bursts.
You also need to be fluent with the AI tools from day one, and that means more than chatting with a model in a browser. Get comfortable in the terminal, because that’s where the serious tools live now. Learn a coding CLI like Claude Code, where an agent can read your whole project, make changes across several files, run the tests and keep going on its own. Get a rough feel for how these agents work underneath: what a harness is, how your code and tools get handed to the model as context, and why it sometimes wanders off. Then treat the thing as a pairing partner, using it to explore approaches, draft code and explain stuff you don’t understand yet, and read everything it gives you with a critical eye. Strong fundamentals plus real AI fluency is the most valuable junior profile going in 2026, and the salaries reflect it: roles that list AI skills pay around 43% more.
Why it’s still worth starting # #
I know the discourse is bleak and the job boards are thin, and it really does feel like the ladder got pulled up the moment the last cohort of developers climbed it.
But demand for software hasn’t dropped, and the doom only ever quotes the grim half of the ledger. If anything, Jevons paradox points the other way: make software cheaper to produce and you tend to get more of it. The BLS still projects software developer roles growing 17% through 2033, and Australia is looking at a shortfall of more than 61,000 digital roles by 2030.
There’s also a part the doom misses completely. If nobody hires juniors, there are no seniors in five years, and the industry knows this perfectly well. Anthropic’s own essay on AI improving itself, about as bullish on AI capability as anything you’ll read, still lands on humans being needed for the judgment and verification, and someone has to learn those skills, starting as a junior.
What’s changed is the shape of the job. The people who do well from here are the ones who can think clearly about systems and the people they serve, and who work the gap between what AI does well and what it still can’t. That’s a skill you can learn, and it’s worth the effort.
If you want the deeper version of this argument from the senior end, covering the frontier models, the world model debate, and what the job becomes once you’re established, I wrote a companion piece: The shapeshifting engineer.