If you're studying computer science right now, or you just graduated, you've probably heard some version of this: AI writes code now, so what's the point?
It's not an irrational fear. The numbers behind it are real.
The fear is real
Researchers at Stanford's Digital Economy Lab studied payroll data covering millions of US workers and found something uncomfortable. In jobs most exposed to AI, workers aged 22 to 25 saw employment fall by about 13% relative to other groups since generative AI took off. For young software developers specifically, employment dropped close to 20% from its late-2022 peak.
And it's not mostly layoffs. Young people aren't being pushed out so much as never being let in. Companies are simply hiring fewer juniors.
So if you feel anxious, you're not imagining things. The ground has moved.
But the same research contains a detail that I think matters more than the headline, and it's where this article is going.
What AI is actually automating
Look at what kind of work AI is replacing.
The Stanford team found that entry-level jobs fell mostly in roles where AI automates tasks: generating complete code, handling routine requests, producing standard documents. In roles where AI augments people, helping them solve complex problems or make better decisions, employment for young workers held steady or even grew.
In software, the automated part is easy to recognize. Boilerplate. CRUD endpoints. Wiring forms to APIs. Converting one format to another. Writing the hundredth version of a login page. This is work that follows patterns, and patterns are exactly what AI is good at.
What AI is much weaker at is the part that doesn't follow a pattern: deciding how a system should be built, understanding why it fails, knowing what can go wrong before it does, and taking responsibility for the answer.
That difference is the whole point of this article.
Why routine development never felt like engineering to me
I want to be clear that this part is personal.
Plenty of developers genuinely love building features, and many developers do deep, serious engineering work every day. This isn't a judgment on them.
But for me, routine development work always felt repetitive. After four years of studying algorithms, operating systems, networks, computer architecture, and theory, I kept wondering why so much of the work waiting for graduates was writing code that looked almost the same as the last project. It never felt like what all that study was for.
And I don't think I'm the only one who has felt this.
How other engineering fields work
Look at other engineering disciplines.
A civil engineer designs a bridge. They calculate loads, choose materials, plan for earthquakes and floods, and sign off on safety. But they don't pour the concrete or weld the steel. Construction crews do that, following the engineer's design.
An electronics engineer designs a circuit and decides how it should behave. But the boards are assembled and manufactured by technicians and production lines.
In both cases, the engineer's value is in design, analysis, and responsibility. The building is done by others.
Computer science has been an exception. For decades, CS graduates were expected to be both the engineer and the builder, and most entry-level jobs leaned heavily toward the building.
AI is starting to change that balance. If AI can increasingly do the building, the human value shifts toward the part other engineers have always focused on.
The engineering side of computer science
This is where it gets hopeful.
There's a whole side of computer science that's about understanding and designing systems, not just producing code:
- System design and architecture: deciding how services fit together, how data flows, how a system scales, and what happens when parts of it fail.
- Network engineering: understanding how data actually moves between machines, and keeping that movement fast, reliable, and secure.
- Cybersecurity: thinking like an attacker, finding weaknesses, and designing defenses. As AI makes attacks faster and cheaper, this field needs more people, not fewer.
- Infrastructure and reliability engineering: keeping systems running, diagnosing outages, and designing them to recover.
These roles depend on exactly what a CS degree teaches: how operating systems manage resources, how networks route packets, how databases keep data consistent, how distributed systems behave when clocks disagree and messages get lost.
And people are already moving this way. One analysis of US data found that only about 31% of the 2023–24 computer science graduating cohort were working as software developers, compared with about 39% of the 2019–20 cohort. CS graduates are spreading into a wider range of roles.
The honest part: this shift won't be easy
I'd be doing you a disservice if I made this sound simple.
These engineering roles are not easy to walk into straight out of university. System design usually requires experience seeing real systems grow and break. Security roles often expect hands-on skills and practice. Network and infrastructure jobs come with their own certifications and steep learning curves. And they're competitive too.
Even the Stanford researchers are careful to say AI probably isn't the only cause of the drop in junior hiring, and nobody knows exactly how this will play out.
So this isn't a promise that AI will hand you a better job. It's a suggestion about where to aim. Hope works best when it's honest.
Where to start building real engineering skills
If you're still studying, you have something valuable: time. Here's where I'd put it.
Take your fundamentals seriously. Operating systems, computer networks, databases, and computer architecture are the courses many students rush through. They're also the foundation for every role mentioned above, and the part AI can't learn on your behalf.
Learn how things break, not just how they work. Read public postmortems from companies about their outages. Set up a small server and try to take it down. Learn what happens when a disk fills up, a certificate expires, or a network partition splits your system in two. Engineers are valued for knowing failure.
Get your hands on real systems. Build a small home lab, even on an old laptop or a cheap cloud account. Configure a network, set up a firewall, run a database, break it and fix it. For security, try beginner-friendly capture-the-flag challenges.
Use AI as a tutor, not a replacement. Ask it to explain concepts, quiz you, or review your design. But always make sure you understand the answer. If AI writes code you can't explain, you've learned nothing that makes you more valuable than the AI.
Practice explaining decisions. Engineering is about trade-offs. When you build a project, write down why you chose one approach over another. That habit is exactly what interviews for these roles test.
A shift, not an ending
AI is changing computer science, and for many people starting out, that change is painful. I don't want to pretend otherwise.
But I also don't think it's the end. If anything, it might be pushing the field toward what it was supposed to be all along: not just writing code, but understanding systems deeply enough to design them, secure them, and take responsibility for them.
Civil engineers don't lay every brick. Maybe, soon, computer scientists won't write every line. And maybe that's not a loss, but a chance to become the engineers our degrees were meant to make us.
I'd love to hear from both sides here. If you're a student, does this shift worry you or excite you? And if you're an experienced engineer, do you think routine coding was ever the real heart of the job?
Top comments (4)
IMO. A CS graduate is still expected to do both the building and Engineering stuff. It's just that building part for the most part is solved by AI. One needs to review it and review can only be done by a person who has solid grip on fundamentals. Also True that now core fundamentals has become like Data Structure, algorithms, networking, OS has become more valuable than ever.
Era of bootcamp developers is officially over now for the best or the worse.
Agreed that review needs strong fundamentals, but that’s also where the crisis comes from. One reviewer can check the work AI used to need several developers to produce. So companies still need people who understand the code, just far fewer of them. The demand didn’t disappear, it got concentrated, and that’s why fewer juniors are getting through the door.
The automate versus augment distinction is the clearest version of this argument I have read. It also explains why the anxiety feels so specific. It is not that students are afraid of hard work, it is that the work they were preparing for is the part that follows a pattern, and patterns are exactly what AI does well.
Your honest section is the part I would underline for anyone still studying. You say these roles are not easy to walk into straight out of university because system design needs experience seeing real systems grow and break, and security roles expect hands-on practice. That is the real gap, and it is also the gap most advice skips over. Telling someone to learn how things break is right, but a home lab alone does not give them anything they can show a hiring manager when the interviewer asks what they have actually handled.
I see the same thing on the IT and security side. No IT certification is needed to start; what moves someone forward is proof they can handle real work, graded the way a real team would grade it, with a verifiable work record behind it. That is exactly what the simulated shifts at getonthejob.com are built around: real tickets and incidents, graded like a real team, so the next time someone asks what you have handled, you have a broken system you diagnosed and fixed to walk through, not just a lab you built for yourself.
Tanay's point about fundamentals fits here too. The fundamentals are what let you review work instead of just accepting it, and graded work is where those fundamentals get tested under pressure. The free shifts are a good way to feel what that kind of graded work looks like, before you need it in an interview.
Thank you, and you’re right that the honest section points at a gap most advice skips: knowing how things break isn’t the same as being able to prove it. I can’t speak to specific platforms, but the principle holds. Proof matters. Students can build it for free: contribute fixes to open-source projects, publish CTF writeups, or document a home lab failure as a proper postmortem with timeline, cause, and fix. A hiring manager can read those. What turns practice into evidence is that someone else can verify it, and writing it down is the cheapest way to make that happen.