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 (21)
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 Stanford numbers are sobering, but I like that this doesn't stop at the fear. One practical takeaway for students: if AI makes "I can write code" cheap, the portfolio signal shifts to "I can own a system." One small project that's actually deployed, monitored, and debugged when it broke says far more than ten tutorial clones. Fundamentals like networking, security and reliability are exactly what let you tell when AI-generated code is wrong, and that's the skill teams are hiring for now.
Owning a system is a perfect way to put it. A deployed project shows something tutorials never can: what happens after the code works. I’d add one thing: keep it running for months, not days, and write down every time it broke and how you fixed it. That record of ownership over time is exactly what separates someone who can build from someone teams can actually trust.
The “learn how things break, not just how they work” section is the part I’d push on hardest, because reverse engineering is probably the most direct, hands-on way to build exactly that instinct — and it’s rarely mentioned alongside CTFs/home labs in these “what to do instead” lists.
Reading a postmortem tells you what broke. Taking a binary apart and figuring out why a specific function behaves the way it does, under adversarial assumptions, teaches you to hold a mental model of a system that has no documentation and actively resists being understood. That’s a different skill than reading someone else’s writeup of a failure — it’s closer to what you need when you’re the first person looking at an incident with no clean narrative yet.
It also ages well against the AI-automation point you’re making. An AI agent can explain what a function does if you ask it nicely and the binary isn’t obfuscated or adversarial. It’s much weaker at the kind of iterative, hypothesis-driven probing RE requires — where each step depends on a judgment call about what the previous step revealed, and there’s no ground truth to check against until you’re done. That’s a good proxy for the “design, analysis, and responsibility” category you’re describing, not just security-specific — it’s a general discipline for building confidence in systems you don’t fully trust.
Great addition, you’re right that it’s missing from most lists. Postmortems teach what broke; reverse engineering teaches how to investigate when nobody has written the story yet. That’s the instinct incidents demand. For students, beginner crackmes and RE challenges in CTFs are a legal, low-cost way to start building it.
Hi, following up from our exchange on your “Not the End, but a Shift” post —
I wanted to mention something I didn’t bring up in the comments: I do 1:1 mentoring on reverse engineering fundamentals (static/dynamic analysis, crackme-style problem-solving, building the investigative instinct you described in your reply). Given your post and the direction you’re pointing students toward, I thought it might be a good fit, either for you directly or for students you’re guiding.
If that’s something you (or your audience) would be interested in, I’m happy to share more — what a typical session looks like, pricing, or just a quick call to see if it’s a good fit. No pressure either way, just wanted to put it out there since the conversation lined up well.
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.
That last line is the part worth underlining: practice becomes evidence when someone else can verify it. A home lab postmortem with a real timeline, cause, and fix does that for free, and it also builds the habit interviews actually test, explaining the decision, not just the fix. The open-source fix is the same idea one step up, because the review itself is the verification. Thanks for writing the honest version of this. Most advice skips straight to learn more, without saying what counts as proof.
The automate vs augment split is the clearest version of this I've read — it explains why the fear isn't about hard work, it's about the patterned part disappearing. The bit I'd push on is the 'learn how things break' advice: postmortems and a home lab sound right, but how does a student turn that into proof a hiring manager believes? That's the gap between the advice and the first job, for me.
Write it down publicly. A home lab failure documented as a proper postmortem, with timeline, root cause, and fix, is real evidence an interviewer can read, question, and actually believe.
One corner of the market already puts a price on the shift you describe: AI labs paying developers to judge AI-written code rather than write it. On the job boards we track at AITraining.jobs, 304 roles in coding and software evaluation were open on 27 platforms this week, advertising a median of $60/hr, 50% above the $40 median for AI training work overall. The work sits on your engineering side: decide whether a change is correct, explain why it fails, name what breaks first.
The catch for the readers you're writing to is who those roles want. Of the 112 that state years of experience, the median ask is 3 years, and about a quarter of the described roles mention a PhD or master's. The judgment gets paid for; the path to acquiring it still runs through the junior building work that's thinning out.
That's the part I'd like your take on: if fewer juniors get hired to build, where do they get the reps that make their judgment worth paying for?
Thanks for the data. That’s the hardest question the article raises, and honestly I don’t think anyone has fully solved it. The best answer I have is open source. Fixing real bugs in projects with real maintainers gives juniors the reps that matter: code reviewed by experienced people, failures in production, and decisions they have to defend. Small projects with actual users help as well. But individuals can only do so much. If companies stop hiring juniors entirely, they’re draining the pipeline that produces tomorrow’s reviewers. Someone has to keep paying for apprenticeship, or the judgment shortage only gets worse.
Deeper engineering skills matter, but beginners also need access to the practice that builds them. Small scoped tasks with review and a clear explanation of tradeoffs can make that learning path more concrete.
Really great take, AI is a tool, a tool for building but not a replacement for understanding. AI is not able to weigh and understand systems and more importantly understand users. That still is in the domain of human engineers.
The drop from 39% to 31% of CS graduates working as software developers is the telling part. That still leaves most graduates elsewhere, so the shift looks less like a new path and more like a hiring freeze with nowhere obvious to go.
Fair point, and it’s a better reading of that number than mine. The data shows fewer graduates becoming developers, not that they’re moving into engineering roles by choice. Some surely are, but many may just be stuck. That’s why the honest section matters: the opportunity exists, but it isn’t automatic, and the path into it is still too narrow.
As a CS student working in DevOps, this gives me hope and worries me at the same time. Some of the best lessons I’ve had at work came from things breaking, so the advice about learning how things fail is spot on. AI is clearly here to stay, so I’m trying to use it in everything I do instead of fighting it. But I’ve also seen that it only really helps when you know your fundamentals. If you don’t understand networking or how a system works underneath, you can’t tell when the AI is wrong. My only worry is that these roles usually want experience, and if companies keep hiring fewer juniors, I’m not sure where new people are meant to get it.