Ten years ago, the standard advice to a computer science student was simple: learn a language, build projects, collect a few frameworks, and apply for junior roles. Junior roles were where people got paid to learn the craft.AI coding agents are putting that ladder under pressure. Today's tools don't just autocomplete a line. They read a whole repository, edit several files, run commands, and retry when tests fail. The routine work that used to fill a junior developer's first year is exactly the work these tools handle best.I'm a computer science student, and I feel this shift every time I open an AI coding tool. It can scaffold a feature in minutes that would have taken me an afternoon. But I've also caught myself accepting code I couldn't explain, and then getting stuck when it broke. That gap between "it runs" and "I understand why it runs" is what pushed me to dig into the research, and to change how I study.This article looks at what the evidence says and what a student can do about it.What the Data Says About Early-Career DevelopersResearchers at the Stanford Digital Economy Lab analyzed payroll records from ADP, the largest US payroll provider. They found that workers aged 22 to 25 in the most AI-exposed occupations saw a 16 percent relative decline in employment, even after controlling for firm-level shocks. Employment for more experienced workers in the same occupations stayed stable or kept growing. Software developers were one of the example occupations the paper highlights.Two details matter for students. First, the researchers found that adjustment happens mainly through employment rather than pay, so the problem is fewer openings, not lower salaries. Second, the declines were concentrated in occupations where AI is more likely to automate work than to augment it. A summary from ADP Research walks through the same findings in plain language.Read that carefully: it doesn't say programming is over. It says that tasks that are easy to specify and easy to automate are the ones disappearing from entry-level hiring. Your goal is to be useful at everything around those tasks.The Trap: Shipping Before UnderstandingHere is the uncomfortable part. The tools that make you fast can also stop you from learning.In a randomized controlled trial with 52 software engineers learning an unfamiliar Python async library, the AI-assisted group scored about 50% on a follow-up quiz, versus about 67% for the group that coded by hand. The biggest gap was on debugging questions. The AI group finished only about two minutes sooner, a difference that was not statistically significant.The outcome also depended on how people used the assistant, not just whether they used it. People who asked for explanations and worked through the reasoning retained more than people who handed over the whole task.The sample is small and the task was narrow, so treat it as a warning sign rather than a law. But it matches what many learners feel: you can complete an assignment without being able to redo it tomorrow.The Second Trap: Code That Works but Isn't SafeA working feature and a safe feature are different things. Veracode tested more than 100 language models on 80 coding tasks. The models produced functional code but introduced security vulnerabilities in 45 percent of cases. Java was the worst, with failure rates above 70 percent, and models failed to defend against cross-site scripting in 86 percent of relevant cases. Help Net Security's coverage summarizes the details.The finding worth remembering: Veracode found that larger models did not perform meaningfully better than smaller ones, which points to a systemic issue rather than something scale will fix. The AI will happily write a login system. It won't reliably tell you what's wrong with it. That judgment has to come from you.Where You Can Still Stand OutIf generating routine code gets cheap, these skills gain value:Reading code critically. Reviewing a diff you didn't write is now a daily job. Practice by reading open-source pull requests.Debugging from first principles. Form a hypothesis, find evidence, narrow the cause. This is exactly the skill the trial above found weakest in heavy AI users.Security basics. Know the OWASP Top 10 well enough to spot injection, broken access control, and bad session handling by eye.Turning vague problems into clear specs. "Users leave at checkout" isn't a ticket. Someone has to make it one.Testing. Write tests that try to break the AI's code, not tests that confirm it.Explaining your decisions. In interviews and code reviews, "why does this work?" is the question that separates understanding from copying.A Learning Routine That Keeps You HonestTry a simple loop I call Sketch, Delegate, Break, Rebuild:Sketch. Before opening any AI tool, write your own plan on paper: routes, data model, who can access what, what could go wrong.Delegate. Ask the AI for an implementation, and ask it to explain its choices and list edge cases.Break. Try to make it fail. Send bad input, log in as the wrong user, delete a required field.Rebuild. Close the chat and re-implement one important piece from memory.Steps 3 and 4 feel slower, and that's the point. They are where the learning the trial measured actually happens.What to Build NowPortfolio projects that show only "I generated an app" are getting less convincing. Stronger signals include:a project with a written design note explaining your decisionsa test suite you wrote to challenge generated codea short security review of your own appa commit history that shows you debugging real problemsEmployers and clients can't easily fake-check understanding, so show it openly.The Bottom LineAI won't remove the need for people who understand software, but it is raising the bar for what an entry-level person must bring. Use the tools heavily for speed, exploration, and drafts. Just make sure the understanding stays in your head, not only in the chat history. The students who do both will be the ones who look like low-risk hires when the ladder gets narrower.