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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
Love that addition. A running "what broke and how I fixed it" log is basically a postmortem history, and it's the best interview material you can have. Thanks for a great post!
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 “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.
Former university lecturer here, and the 39% to 31% line reads differently to me than "AI took the jobs". A good share of students never chose the specialty out of interest, they chose it as a safe degree, and the safe part is what went away. The ones who cared were always a small group. They built things nobody assigned, broke them, and came to class with questions the course had not reached yet. Those people will keep building systems with or without a company paying them, and the fundamentals you list are exactly what they pick up on the way.
What has changed is the cheap first step. I left university with two years of part-time PHP sites behind me, small money, real clients, real bugs. That kind of paid small work is harder to find now. So I would add one thing to your list: a small project that someone pays for directly, an automation of a process in someone's shop or a tiny app for a daily problem. Getting money from a user teaches more about the market and about where things are going than a course or a junior seat ever did. Hackathons, small apps, automations that help people in everyday life: that is the training ground, and it still exists.
This is the productive framing: AI raises the value of people who can define constraints, inspect outputs, and reason about systems beyond the happy path. The skills worth practicing are still fundamentals, but demonstrated through concrete artifacts — tests, traces, incident reports, and design decisions.
Routine coding is pattern matching, yes. But I also believe it forces the young engineers to understand the project as a whole. This is what makes them stronger. Repetition is mastery. However, with AI taking all those parts now, it is harder for young ones to replicate what made the seniors of today "seniors". Your suggested methods is actually helpful, I've been applying most of those myself too even in my own personal projects. I act as if I am in a team even though I'm a solo dev on a project. But still, nothing beats the real world experience. I hope that the future would find a balance because I believe repetition is still important in building mastery.
The Stanford data point is the sharpest part of this — the split isn't code vs no-code, it's pattern vs judgment. AI can generate a CRUD endpoint, but it can't decide the invariants, own a pager rotation, or explain from telemetry alone why a system degraded at 3am. For juniors that suggests a concrete move: bias your practice toward failure analysis, system design, and end-to-end ownership — those are the tasks that keep getting harder for AI, not easier.