AI Won't Take Your First Job — But It's Changing What "Entry-Level" Means

Every few weeks I see a version of the same post. A final-year student, or someone six months out of university, writing that there are no junior jobs anymore. Three hundred applications, four responses, no offers. Underneath it, forty comments agreeing, and at least one confidently explaining that AI has closed the door permanently. I've read enough of these now that the pattern is difficult to ignore — and I've also spent enough time looking at what companies are actually asking for to think the diagnosis is wrong. Not the pain. The pain is real. The diagnosis.

The first job isn't disappearing. The expectations attached to it are.

That distinction sounds like a technicality. It isn't. It changes what you should do next, what you should build, and what you should stop wasting months on. Here's my position, stated plainly so you can disagree with it as you read: AI is not eliminating entry-level jobs. It is eliminating entry-level work that consists only of repetitive execution. The companies still hiring juniors — and there are many — now expect them to produce real value early, because the mechanical layer of the job has been handed to a machine. That is a redefinition of "entry-level," not an extinction of it. And redefinitions are survivable in a way that extinctions are not.

Table of Contents

• Why everyone thinks AI is killing entry-level jobs
• The work that is actually disappearing
• The work companies still desperately need
• Entry-level no longer means beginner
• The junior developer of 2022 vs 2026
• What students should stop doing
• What students should start doing
• The role AI should actually play in your learning
• A practical roadmap, year by year
• Common myths
• Key takeaways
• Frequently asked questions
• Final thoughts

Why Everyone Thinks AI Is Killing Entry-Level Jobs

Start with the mechanics of how you're receiving this information, because they matter more than people admit.

Nobody posts "I applied to twelve companies and got a reasonable offer at the fourth." That post has no audience. It doesn't get shared, it doesn't get sympathy, and writing it feels like bragging. What does get shared is the four-hundred-application screenshot, the rejection email with a typo in your name, the story of a role that closed after receiving two thousand CVs in a day.

So the feed you're reading is not a sample of the job market. It's a sample of the worst outcomes in the job market, sorted by emotional impact. That's not a conspiracy — it's just what engagement optimisation does to any collection of human experiences.

Then there's the timing problem. Graduate hiring genuinely slowed, and the slowdown happened to coincide with AI becoming a household topic. But the same window also contained interest rate pressure, a correction after the enormous 2021 hiring surge, and restructuring across most of the tech sector. When several causes arrive together, people attribute the effect to the most visible one. AI is by far the most visible one.

I want to be careful here, because this is where a lot of writing on this topic starts inventing numbers. Several consultancies and job boards have published research on AI's labour market effects, and the results genuinely conflict with each other. Some find measurable displacement in specific routine occupations. Others find the strongest correlation with macroeconomic conditions rather than AI adoption. I don't think anyone currently has clean evidence separating the two, and I'd be suspicious of anyone who tells you they do.

What I'll say is what's actually observable, without a study behind it: the composition of what's advertised has changed more than the count. Read fifty junior job descriptions from 2021 and fifty from now. The framework names are similar. The verbs are not. There is noticeably more "collaborate," "own," "communicate," "evaluate" and noticeably less "assist with," "support," "under supervision."

That's the shift. Not fewer doors. Different doors, in slightly different places, with a sign on them that most graduates haven't read.

The Work That Is Actually Disappearing

Let me be specific, because vague reassurance is useless and vague doom is worse.

There is a category of work that has genuinely thinned out, and if your plan was to be hired for it, that plan needs updating. It looks like this:

• Simple documentation. Writing docstrings, README skeletons, API reference pages from existing signatures, release notes assembled from commit history.
• Basic CRUD code. The endpoint that reads a row, the endpoint that writes a row, the form that submits it, the model that maps to it.
• Boilerplate generation. Configuration files, project scaffolding, type definitions from a sample payload, repetitive component shells.
• Simple debugging. The stack trace with an obvious cause, the missing import, the typo in a config key.
• Routine copywriting. Product descriptions, standard marketing pages, formulaic listing content.
• Manual summarisation. Condensing meeting notes, long documents, or research into a shorter version.
• Template-driven QA. Writing the fifteenth test case that differs only in input values from the fourteenth.

Why does AI do these particularly well? Because all of them share one property: the correct output is highly predictable from the input.

That's not a coincidence, and understanding it tells you almost everything about where the line falls. A language model is, at its core, an extremely sophisticated predictor. When the next reasonable thing to write is strongly determined by what came before — as it is in a CRUD endpoint, a docstring, or the fifteenth near-identical test — the model performs beautifully. When the next reasonable thing depends on information that isn't in the text, like what your customer actually meant or which of two acceptable designs your team will regret less in a year, it performs much less reliably while sounding exactly as confident.

Here's the part that stings, and I say this having noticed it in my own work: the tasks AI handles best are also the tasks that used to teach juniors the most. Writing your fiftieth CRUD endpoint is dull, but somewhere around the twentieth you stop thinking about syntax and start noticing patterns. That ladder rung has been sawn off. It's genuinely a loss, and I don't think the industry has worked out what replaces it yet.

But notice what the list above actually is. It's a list of tasks. Not a list of jobs. No company ever hired a graduate purely to write docstrings — that was the work you did between the work that mattered.

The Work Companies Still Desperately Need

Now the other side, which gets far less attention because it's harder to screenshot.

Problem framing. Someone says "the dashboard is slow." That is not a problem statement — it's a symptom report. Turning it into "the aggregation query runs unindexed across three months of rows for users on the enterprise plan" requires investigating, asking the right person the right question, and knowing which observations to discard. AI can help enormously once the problem is framed. It cannot do the framing without the context that lives in people's heads and in Slack threads from eight months ago.

Requirements gathering. This is where I've watched more projects fail than anywhere else. Two stakeholders use the word "active user" and mean different things. One assumes the export includes archived records. Nobody says any of this aloud because everyone believes it's obvious. A junior who notices the ambiguity and asks — in a meeting, out loud, at the risk of sounding slow — has just saved weeks. No model attending that meeting would flag it, because the conflict isn't in the words.

Verification. This is the big one, and it's growing fast. When a tool generates a hundred lines in four seconds, someone has to determine whether those lines are right — not plausible, right. Generated code has a specific failure mode that's worth internalising: it's usually correct in shape and occasionally wrong in a detail that reads perfectly. An off-by-one in a boundary condition. A dependency version that quietly doesn't exist. Error handling that swallows the exception you needed. Catching those requires knowing what correct looks like, which is knowledge, not vibes.

Code review. Related but distinct. Reviewing means asking whether this fits the codebase, whether it duplicates something in a module the author didn't know about, whether it introduces a pattern the team decided against last year. That's institutional judgement.

Communication. Explaining a technical constraint to a product manager in a way that leads to a good decision rather than a defensive one. Writing an incident summary that a non-engineer can act on. This has always been undervalued by students and always been the thing that separates careers.

Customer understanding. Knowing why users abandon a flow at step three, which requires curiosity about people rather than systems.

Decision-making under uncertainty. Choosing between two defensible options with incomplete information, then being answerable for it.

That last word — answerable — is where I think AI's limit genuinely sits, and it's structural rather than temporary. You cannot delegate accountability to a tool. When a deployment takes down checkout on a Friday evening, someone gets on the call. Someone decides whether to roll back or patch forward. Someone writes the post-mortem and stands behind the conclusion. That role requires a person who will be held responsible, and no improvement in model capability changes that, because it isn't a capability problem. It's a question of who answers for the outcome.

Organisations run on ownership. Ownership needs an owner.

Entry-Level No Longer Means Beginner

This is the heart of it.

For a long time, "entry-level" carried an unspoken agreement. The company accepted that you'd be net-negative for a few months. You'd consume senior time, ship small things slowly, and gradually become useful. In exchange, they got someone who'd grow into the role and stay.

That agreement hasn't been cancelled. It's been compressed.

The reason is straightforward. When the mechanical barriers to producing code dropped, the ramp-up period that used to be spent overcoming those barriers stopped being necessary. A graduate who can use AI tools well can produce working code in an unfamiliar framework on their first week. Companies noticed. And once something becomes possible, it becomes expected — that's just how expectations work.

So what does the modern junior role actually ask for? From what I've seen in job descriptions, interview loops and conversations about why candidates get rejected, it lands on roughly six things.

1. Use AI tools well

Not "have used ChatGPT." Well. Knowing which tasks to hand over and which to keep. Giving a model enough context that the output is usable. Recognising within ten seconds that a response has gone sideways, rather than spending an hour adapting something that was wrong from the first line. This is a real skill with real variance between people, and it shows up quickly in a pairing interview.

2. Verify output

The single most valuable habit a graduate can arrive with. A junior who ships AI-generated code they haven't understood is a liability, and an expensive one, because the bug surfaces in production where it costs twenty times more to fix. A junior who says "this looks right but I tested the empty-array case and it throws" is immediately trusted.

3. Understand architecture

Not design distributed systems — understand where your change sits. Which service owns this data. What happens if this call times out. Why there's a queue between these two components. Generated code is locally correct and globally naive; someone has to hold the global picture.

4. Learn independently

The half-life of specific tool knowledge keeps shrinking. What survives is the ability to encounter something unfamiliar and become competent at it without a course. Reading documentation properly. Reading source code when documentation runs out. Being comfortable in the gap between not knowing and knowing.

5. Ship features, not tickets

Older junior roles were often ticket-shaped: here's a precisely scoped task, complete it. Increasingly the unit is a small feature — including the edge cases nobody wrote down, the tests, the migration, and telling people it's live. That's a meaningful jump in scope.

6. Communicate clearly

Written communication has quietly become one of the highest-leverage skills in engineering, partly because teams are distributed and partly because working with AI tools is a writing task. If you can't specify precisely what you want, you'll get vague output — from a model and from a colleague.

Read that list again and notice something: not one of those six is "know more syntax." Every one is judgement, ownership or communication. The bar didn't rise in the direction most students are studying for. It rose sideways.

Which is, honestly, good news for a certain kind of graduate. If you've been quietly worried that you're not the fastest coder in your cohort, this shift is in your favour — as long as you can think clearly and explain yourself.

The Junior Developer of 2022 vs 2026

A comparison I find clarifying. This isn't survey data — it's a synthesis of how the role has changed based on job descriptions, hiring conversations and watching teams work.

The last row is the whole article compressed into one line. The investment used to be in teaching you to build. It's now in teaching you what's worth building, and that's a shorter, steeper curriculum.

What Students Should Stop Doing

Five habits I'd drop, in rough order of how much time they waste.

Stop memorising syntax. I've seen students spend weeks drilling method signatures they could look up in four seconds. Understand what a hash map costs and when it's the wrong choice — that's durable. The exact argument order of a standard library function is not. Interviews increasingly reflect this, though not universally, so don't take it to the extreme of being unable to write a loop unaided.

Stop avoiding AI on principle. A minority of students have decided that using these tools is cheating and refuse them entirely. I respect the instinct and I think the conclusion is wrong. You'll be expected to use them in your first job, on day one, competently. Refusing to learn a tool your future colleagues use daily is a strange way to prepare. The answer is discipline about when, not abstinence.

Stop copy-pasting blindly. The opposite failure and the more common one. If you cannot explain a block of code line by line, you don't have it — you're renting it, and the rent comes due in a code review or an interview. My rule: never commit something you couldn't defend to a sceptical reviewer.

Stop building tutorial clones. Another to-do list, another weather app, another clone of the same e-commerce site the tutorial built. Every reviewer has seen four hundred of these. They demonstrate that you can follow instructions, which was never in doubt. Build something with an actual problem in it — even a small, unglamorous problem — and be able to describe how you solved it.

Stop waiting until graduation. The most expensive mistake on this list. Treating the degree as a prerequisite to be completed before starting your career wastes three years of the only period when your time is genuinely flexible. Contribute to something, write publicly, build for one real user, help maintain a small open source project. The graduates who struggle least are almost always the ones who started before they were told they could.

What Students Should Start Doing

Build projects with real constraints. Not "an app" — an app that must handle a user pasting nonsense into a field, that has to still work when the API is down, that someone other than you actually opens. Constraints are what create the stories you'll tell in interviews.

Write documentation. Unfashionable and enormously effective. Writing a clear README forces you to discover which parts of your own project you don't understand. It's also the fastest way to improve technical communication, which as established is now a first-year expectation.

Learn Git properly. Not three memorised commands. Branching, rebasing, resolving a conflict without panic, reading history to understand why a line exists, writing a commit message a stranger can use. This is the collaboration layer of the entire profession and most graduates arrive shaky on it.

Study system design early. Not for the senior-level interview — for the mental model. Why a cache exists, what a queue is for, what happens when a service is unavailable, why we shard. You don't need depth yet. You need the vocabulary and the shape.

Learn to prompt precisely. Treat it as specification writing, because it is. Context, constraints, expected output format, examples. The gap between a lazy question and a well-formed one is larger than the gap between models, which I've written about at more length in this piece on writing prompts that actually work.

Practise code review. Find an open source project, read a merged pull request, and try to articulate what you'd have commented on. Then read what the maintainers actually said. This is free training in the exact skill that's becoming central, and almost nobody does it.

Read existing codebases. Genuinely the most underrated activity available to a student. Clone something you use, pick one feature, and trace it end to end. It's uncomfortable and slow. It's also precisely what your first three months of a job will feel like, so arriving practised at it is a real advantage.

Learn testing seriously. Not just how to write a test — how to write one that would actually catch the bug. A useful exercise: break your own code deliberately and check whether your tests notice. If they don't, they were decoration.

Practise explaining decisions. Out loud, to another person, in under two minutes. "I chose Postgres over Mongo here because the data is relational and I needed transactional guarantees on the payment flow." That sentence, delivered calmly, is worth more in an interview than a longer list of technologies. And you should do it unaided sometimes — there's a reason I'd argue against leaning on AI during coding interview preparation.

The Role AI Should Actually Play in Your Learning

Here's the framing I'd offer, having gone back and forth on it and having spent a full week working without these tools to test my own dependence on them.

Use AI as a mentor. The version of a senior engineer who never gets tired of your questions and never makes you feel slow for asking. "Why is this considered bad practice?" "What would break if I did it the other way?" Follow-up questions are where the value is, and they're free.

Use AI as a reviewer. Write the code yourself, then ask what's wrong with it. This is the single best pattern I know for students, because you keep the struggle that creates understanding and still get feedback that would otherwise require a colleague you don't have.

Use AI as a rubber duck. Explain your problem in full. Often you'll solve it mid-explanation, which is the classic rubber duck effect and it works just as well when the duck can answer.

Use AI as a documentation assistant. Draft, then correct. Your judgement about what matters is the part you're contributing.

And the boundary, which I'd hold firmly: never use AI as a replacement for thinking.

The failure mode is subtle. It isn't that you ask for an answer instead of working it out — that's obvious and most people catch themselves. It's that you stop letting the question fully form before you reach for help. The gap between "I've hit a problem" and "let me ask" shrinks to nothing, and that gap is where the thinking used to happen. I caught myself doing it after a decade of experience. A student two years in, who never had a pre-AI baseline, may never notice it's happening at all.

A simple discipline: attempt first, ask second. Fifteen or twenty minutes of genuine effort before you open the other window. Not as a moral position — as training. You're deliberately keeping a muscle that the job still requires.

A Practical Roadmap, Year by Year

Adjust for your situation. The sequencing matters more than the specific items.

Year 1 — Build the foundation the tools can't give you

• One language, properly. Not four, superficially.
• Data structures and algorithms by hand, unaided. This is the year to struggle deliberately.
• Git from week one, on everything you write, even the throwaway assignments.
• Command line comfort — navigating, piping, editing files without an IDE.
• Use AI only to explain concepts, never to produce your solutions.

Year 2 — Learn to build and collaborate

• Two or three real projects with actual constraints, deployed somewhere public.
• Learn databases beyond basic queries — indexes, transactions, why a query is slow.
• Write tests for everything you build, and verify the tests can fail.
• Start reading open source code weekly. Twenty minutes counts.
• Begin using AI as a reviewer of your finished work.

Year 3 — Get near real teams

• Internship, freelance work, or sustained open source contribution. Any of the three.
• System design fundamentals — caching, queues, load balancing, failure modes.
• Make real contributions to a project you didn't start: an issue, a fix, a merged PR.
• Write publicly about what you're learning. A blog, a newsletter, detailed READMEs.
• Practise reviewing other people's code and articulating why.

Final year — Sharpen and consolidate

• Build one substantial project you can discuss for thirty minutes without notes.
• Interview preparation, deliberately unaided, because the interview will be.
• Practise explaining technical decisions to non-technical people. Find one and try.
• Get comfortable in an unfamiliar codebase — pick one and give it a fortnight.
• Tidy your public presence: repositories, README quality, a CV of outcomes rather than tools.

Fresh graduate — The first eighteen months

• Optimise for learning rate over salary. The compounding is enormous and most people underweight it.
• Ask questions early and specifically. "I tried X, expected Y, got Z" is a great question. "It doesn't work" isn't.
• Volunteer for the unglamorous work near production — on-call shadowing, incident notes, the migration nobody wants.
• Verify everything you ship. Build the reputation of someone whose code doesn't need re-checking.
• Write down what you learn. In eighteen months it becomes the thing you teach the next graduate.

Common Myths

Myth: AI will replace all junior developers.
Reality: It replaces junior tasks. Companies still need people who can frame problems, verify output and be accountable for a decision — and they need those people to eventually become seniors, which requires hiring them as juniors.

Myth: There are no entry-level jobs anymore.
Reality: There are fewer of a specific type, and they're harder to find because application volume has exploded. The market is more competitive, which is not the same as empty. Those two situations feel identical from inside four hundred rejections and are entirely different strategically.

Myth: Learning to code is pointless now.
Reality: Learning to code as typing is pointless. Learning to code as a route to understanding systems is more valuable than ever, because verification requires knowledge you can only get by having built things.

Myth: You need to become an AI engineer to stay employable.
Reality: AI engineering is one path among many, and a crowded one with a steeper mathematics requirement than most people expect. Being excellent in your domain while using AI well is a more accessible and often stronger position.

Myth: Using AI while learning makes you a worse programmer.
Reality: Using it as a substitute for thinking does. Using it as a reviewer, explainer or rubber duck after your own attempt appears to accelerate learning. The sequencing is what determines the outcome.

Myth: Companies want candidates who never use AI.
Reality: Almost the reverse. What they don't want is candidates who use it without understanding the output. In interviews, the question is shifting from "can you produce this" to "can you tell me what's wrong with this."

Myth: A degree alone will get you hired.
Reality: It was never sufficient and it's less so now. It gets you past filters. Evidence of judgement — projects, contributions, writing, anything with a decision in it — is what gets you through the final stage.

Myth: If AI can build an app, my project portfolio is worthless.
Reality: The artefact was never the point. The point is the reasoning behind it. A reviewer looking at your project is asking what you decided and why, and no tool answers that on your behalf in a conversation.

Myth: Entry-level roles pay less now because AI does the work.
Reality: Compensation moves with market conditions, location and company stage far more than with tooling. If anything, the compression of the ramp-up period argues for graduates being worth more sooner, not less.

Myth: This will all settle down and go back to normal.
Reality: Tooling shifts of this size don't reverse. The industry adapted to compilers, to the internet, to open source and to cloud infrastructure — each time the work moved up a level of abstraction and stayed there. Planning for a return to 2019 is planning for something that isn't coming.

Key Takeaways

• The job isn't gone; the job description changed. Entry-level roles now assume the mechanical layer is handled and start you higher up.
• What disappeared is predictable execution. Boilerplate, simple documentation, routine QA, basic CRUD — work where the output follows mechanically from the input.
• What grew is verification and ownership. Someone must decide whether generated output is correct, and someone must be accountable when it isn't.
• "Entry-level" now means early in career, not early in capability. Mentoring has shifted from teaching you to build toward teaching you what's worth building.
• The ladder rung that's missing is real. Repetitive work used to teach through repetition. Nobody has replaced that yet, so you have to seek difficulty deliberately.
• Attempt first, ask second. The habit that protects your thinking is a fifteen-minute delay before reaching for help.
• Communication is now a technical skill. Specifying precisely is the same muscle whether the recipient is a colleague or a model.
• Start before you feel ready. The graduates struggling least almost always began contributing to something real years before they had to.

Frequently Asked Questions

Is AI actually reducing the number of entry level jobs?

The honest answer is that we cannot cleanly separate AI's effect from everything else happening at once. Graduate hiring slowed during a period that also included interest rate pressure, post-2021 over-hiring corrections and widespread restructuring. AI is part of that picture but attributing the whole slowdown to it is a claim nobody can currently support with evidence. What is much easier to observe is a change in composition: fewer roles built purely around repetitive execution, and more roles that expect a graduate to verify, integrate and communicate from early on.

Will AI replace junior developers?

It replaces junior tasks far more convincingly than junior people. A model can generate a CRUD endpoint, but it cannot sit in a requirements meeting, notice that two stakeholders mean different things by the same word, and raise it before three weeks of work go the wrong direction. Teams that remove juniors entirely also remove their own future seniors, and most engineering managers understand that. The risk to juniors is not deletion — it is a raised floor for what counts as useful on day one.

What does entry level mean now if it doesn't mean beginner?

It means early in your career, not early in your capability. You are still expected to need mentoring on architecture, judgement and domain knowledge. You are increasingly not expected to need hand-holding on producing code, reading documentation, or getting unstuck on a syntax problem, because tools now handle that layer. The mentoring budget has shifted upward: seniors expect to spend their time on your decisions rather than your keystrokes.

Should students avoid AI tools while learning to code?

Avoiding them entirely is a mistake, and so is leaning on them for everything. The approach that seems to work is sequencing: attempt the problem unaided first, then use AI as a reviewer, explainer or second opinion afterwards. That keeps the struggle that builds understanding while still giving you the feedback loop. What genuinely damages learning is accepting a correct answer you could not have evaluated, because programming is largely the skill of evaluating answers.

What skills do employers want from graduates in the AI era?

Recruiters and hiring managers keep circling the same short list: can you read code you did not write, can you tell when generated output is wrong, can you explain a technical decision to a non-technical person, and can you make progress on an ambiguous task without being handed step-by-step instructions. Notice that none of those are frameworks. Frameworks still matter for getting past a keyword filter, but they are rarely what separates two candidates at the final stage.

Are internships still worth doing if AI can do the work?

More valuable than before, and for a different reason. Internships used to be partly about proving you could produce output. Now the output is cheap and the scarce thing is context — knowing how a real team argues about priorities, how code review actually works, how a feature goes from a vague request to something shipped. That context is nearly impossible to simulate alone, which makes any exposure to a real codebase and a real team disproportionately useful on a CV and in an interview.

Is it still worth learning to code in 2026?

Yes, but learn to code in order to understand systems, not in order to produce lines. The person who can only type syntax is competing directly with a tool that types syntax faster. The person who understands why a database query is slow, what a race condition looks like, or why an abstraction is leaking is doing something the tool cannot do reliably. Coding is still the route to that understanding — there is no shortcut that skips it.

How do I show AI skills on my CV without sounding generic?

Describe outcomes and judgement rather than tool names. "Used ChatGPT and Copilot" tells a reader nothing, because everybody writes that. "Rebuilt our test suite with AI-generated scaffolding, then hand-wrote assertions after finding the generated ones passed on broken input" tells them you can supervise a tool. The second sentence demonstrates verification, which is exactly the skill that is scarce. Specificity is what makes an AI mention credible — and the same principle applies to the rest of your resume.

Do companies still hire graduates with no experience?

They do, but the definition of experience has loosened in a way that helps you. Personal projects with real users, meaningful open source contributions, a well-documented repository or a technical blog all read as experience now, because they demonstrate the same things a first job would. What reads poorly is a list of tutorial projects with identical structure, since those signal completion rather than judgement. Build something that had a problem you had to solve unaided, then be able to describe that problem.

Which entry level roles are most affected by AI?

Roles where the whole job description was routine production: basic content writing, manual data entry and cleanup, first-pass summarisation, simple template-driven QA, and heavily scripted support. Roles that involve dealing with people, ambiguity, physical environments or accountability for a decision have moved much less. Software engineering sits in between — the production layer has thinned considerably while the reviewing, integrating and deciding layers have grown.

How long does it take to become useful as a junior now?

The productive window has compressed. Teams that once expected three to six months before a graduate shipped meaningful work now often expect something visible in the first few weeks, because the mechanical barriers have dropped. This is not entirely bad news — it means your early contributions are more interesting than they would have been. It does mean arriving with the ability to navigate an unfamiliar codebase matters far more than arriving with memorised syntax.

Should I specialise in AI to get hired?

Specialising in AI engineering is one valid path, but treating it as the only safe option is a mistake — that field has its own crowding problem, and it demands a mathematics and systems foundation many graduates underestimate. The broader and safer move is to become someone who uses AI well inside whatever domain interests you. Being an excellent backend engineer who supervises AI output effectively is a stronger position than being an average prompt specialist.

Final Thoughts

I don't want to end this by telling you it's all fine, because for a lot of people applying right now it isn't fine. The competition is genuinely harder. Application volume has exploded, filters are more aggressive, and the rung of the ladder that used to be made of repetitive work — dull work, but work that taught you things through sheer repetition — has largely been sawn off. That's a real loss and I don't think anyone has properly replaced it yet.

But there's a difference between a harder market and a closed one, and the two feel identical from inside a rejection streak while requiring completely different responses. A closed market means stop trying. A harder market means change what you're bringing.

What I keep coming back to is how badly the popular framing misdirects effort. Students hear "AI is taking entry-level jobs" and respond by studying more syntax, collecting more certificates, building another tutorial project — competing harder in exactly the dimension where competing is now pointless. Meanwhile the things that actually differentiate candidates sit largely untouched: reading unfamiliar code, spotting where generated output is subtly wrong, explaining a decision clearly, noticing an ambiguity in a requirement before it costs three weeks.

Those aren't glamorous. None of them make a good LinkedIn post. They're also, as far as I can tell, what the job now is.

So the reframe I'd offer, and the thing I'd want a student to take away: you are not in a contest against a model. That contest doesn't exist, and imagining it just makes you anxious about the wrong things.

The graduates who struggle won't necessarily be the ones competing against AI. They'll be competing against graduates who know how to work with it.

That's a much more solvable problem. It's also entirely within your control, starting this week.