# Is AI job risk different for junior and senior engineers?

> AI job risk is hitting junior and senior engineers differently. See what employment data shows and how to reposition around ownership and evidence.

AI will not erase engineering as a profession, but it is already reducing the amount of routine implementation that companies need to buy from people. That difference matters. A growing occupation can still become much harder to enter, and a senior title can still lose value when it only reflects years spent closing predictable tickets.

The honest answer is uncomfortable for both camps. The data does not support "software engineers are finished." It also does not support "AI is just another autocomplete tool." Junior hiring shows the clearest pressure because companies can now cover some starter tasks with experienced engineers using AI. Senior demand holds up better because production systems still need judgment, context, and someone accountable when a plausible answer is wrong.

Your safest move is not to race a model at producing code. Reposition around choosing the right problem, setting constraints, verifying the result, and owning what happens after deployment. Those skills matter at every level, but juniors now have to demonstrate them earlier.

## The data shows growth and displacement at the same time

Software work is growing in aggregate while the mix of people and tasks changes underneath it. The US Bureau of Labor Statistics projects employment for software developers to grow 15.8% from 2024 to 2034, adding about 267,700 jobs. In the same table, it projects computer programmer employment to fall 6%. The agency separates those occupations for a reason: designing and owning software has a stronger outlook than translating specifications into code.

The World Economic Forum's Future of Jobs Report 2025 points in the same direction from a global employer survey. It lists software and applications developers among the jobs expected to produce substantial net growth by 2030. The report also says AI and information processing technologies are expected to create 11 million jobs and displace 9 million across the economy. Those are survey-based projections, not a promise to any individual engineer, but they show why broad claims about "jobs disappearing" miss the actual movement.

Hiring data can deteriorate long before an occupation enters decline. A company that once hired six juniors and four seniors may hire two juniors and three seniors with AI tools. Another company may create a small AI product team. The occupation count can rise across the economy while the entry path narrows inside many firms.

Three measurements often get mixed together:

- Occupational outlook estimates how many people will hold a kind of job years from now.
- Job postings measure current hiring intent, including duplicate and never-filled positions.
- Payroll data measures people actually employed, but it usually explains little about their daily tasks.

Read them together. A long-term growth projection does not cancel a weak hiring quarter. A fall in postings does not prove permanent replacement. Payroll changes by age and AI exposure give the strongest early warning for juniors, while occupational projections show that companies still expect to need people who can build and operate software.

The practical conclusion is precise: AI raises engineering job risk for work packaged as repeatable output, even as demand remains healthy for people who own systems and business outcomes.

Geography and company stage will make the change uneven. A regulated bank, a hardware company, and a seed-stage software startup cannot delegate the same work at the same pace. Local labor supply, financing conditions, and outsourcing also move hiring independently of AI. Compare roles within the market where you can actually work instead of applying a US projection to every country or treating one startup's staffing plan as a global forecast. The direction is broad, but the timing is local.

Compensation may react later than hiring. The Stanford paper found clearer adjustment in employment than in annual pay, which the authors suggest may reflect sticky wages. That means the first visible effect can be fewer openings rather than a dramatic salary cut for people already employed. If you wait for senior salaries to collapse before adapting, you may miss the earlier signal in reduced junior intake, longer searches, and higher expectations at each level.

## Junior demand is taking the first hit

Entry-level engineers face more pressure because AI overlaps with the tasks companies traditionally used to train and evaluate them. Boilerplate endpoints, test scaffolds, simple data transformations, documentation drafts, and small bug fixes were never the whole junior job. They were the low-risk work through which a new engineer learned the codebase and earned trust.

Stanford Digital Economy Lab researchers Erik Brynjolfsson, Bharat Chandar, and Ruyu Chen examined payroll records from ADP in their working paper "Canaries in the Coal Mine?" Their November 2025 version found a 16% relative employment decline for workers aged 22 to 25 in the most AI-exposed occupations after controlling for firm-level shocks. More experienced workers in those occupations remained stable or grew. In the paper's software developer example, employment for ages 22 to 25 had fallen nearly 20% from its late-2022 peak by September 2025.

That finding is serious, but it has limits. Age is not the same as job level, the data covers ADP payroll clients rather than every employer, and the study finds a pattern consistent with AI rather than proving that AI caused every lost position. Interest rates, the post-pandemic hiring correction, outsourcing, and the collapse of speculative hiring all affect junior demand. The researchers tested several alternative explanations, including technology firms and remote-work exposure, and the pattern remained. Treat it as an early warning, not a universal law.

The mechanism matches what I see when teams redesign work. A senior engineer can ask an agent to draft a migration, inspect the diff, reject a bad assumption, and finish the risky part. That can remove several hours of work that once went to a junior. The company has not automated the senior's job. It has removed one reason to add another person.

This creates a training problem that employers often ignore. If firms remove every safe starter task, they also remove the path by which engineers learn production judgment. A team that hires no juniors for three years does not magically receive experienced candidates in year four. Good engineering leaders will preserve apprenticeships while changing the work inside them. Others will optimize the next budget and leave the talent shortage to someone else.

For a junior, "I can write clean code" is no longer enough differentiation. Show that you can clarify a vague request, use AI without trusting it blindly, test behavior at boundaries, explain tradeoffs, and follow a change in production. That is a higher bar than many companies set five years ago. It is still reachable.

## Seniority protects context, not a title

Senior engineers hold up better when their value comes from accumulated context and accountable decisions. A model can generate three database migration options. It cannot accept the organizational consequences of choosing the one that delays billing, breaks an undocumented integration, or makes a regulatory audit harder.

Experience helps in four specific ways. An experienced engineer recognizes failure shapes before they become incidents. They know which requirements are negotiable and which merely look negotiable. They can coordinate product, security, operations, and finance when a technical decision crosses boundaries. They also know when the fastest code change creates a slower company.

None of that is guaranteed by tenure. A developer who has repeated the same narrow implementation year ten times has less protection than a five-year engineer who has owned migrations, incidents, customer constraints, and cost decisions. AI exposes that distinction because it makes syntax and local pattern matching cheaper.

The METR randomized study of early-2025 tools offers a useful corrective to claims that every experienced developer becomes instantly faster. Sixteen experienced open-source maintainers completed 246 real issues in repositories they knew well. When allowed to use AI, they took 19% longer on average, even though they believed AI had sped them up. The study involved a narrow group, particular tools, and tasks averaging about two hours, so it does not justify "AI slows all senior engineers." It does show that familiarity, review overhead, and subtle repository constraints can erase apparent generation speed.

METR later said its early-2026 experiment design needed to account for newer tools and that participants were probably seeing more speedup than in early 2025. That update reinforces the right lesson: tool capability moves quickly, while the cost of verification depends on the work. Measure completed, accepted outcomes in your own environment instead of quoting a benchmark or asking developers whether they feel faster.

Senior risk rises when leaders use the title as a proxy for judgment but the engineer cannot produce evidence of judgment. If your weekly contribution is mostly converting detailed tickets into conventional code, AI competes directly with a large portion of your job. If you decide what should change, constrain the implementation, and answer for reliability and cost, AI increases your span before it threatens your seat.

## AI removes tasks before it removes roles

Companies automate bundles of tasks, then redraw roles around what remains. Job titles usually lag behind. A "software engineer" may spend time interviewing users, tracing a production fault, editing configuration, implementing a feature, reviewing code, negotiating scope, writing a rollout plan, and supporting an on-call rotation. AI touches each task differently.

Anthropic's Economic Index analysis of 500,000 coding interactions found that coding-agent use leaned more toward automation, while ordinary chat use mixed automation and collaboration. The source is a vendor's own product data, so it cannot describe every engineer or tool. It does reveal how people use capable coding agents: they delegate coherent pieces of implementation, not just ask for a better variable name.

Task exposure depends on four properties:

- The input can be written down without much private context.
- A machine can check the output quickly through tests or static rules.
- Failure has limited cost and can be reversed.
- The task resembles patterns present in code and documentation.

CRUD endpoints and test drafts score high on that list. Choosing a service boundary during an acquisition scores low. Debugging a well-instrumented isolated function may be easy to delegate. Diagnosing an intermittent billing fault across a queue, a vendor API, and an undocumented retry policy requires context that no prompt contains unless someone first discovers and records it.

This is why "What percentage of coding can AI do?" is a poor career question. Code volume does not map cleanly to economic value. A model might generate 90% of the lines in a change while a person contributes the constraint that prevents data loss. Another engineer might hand-write every line of a low-impact internal page. The line count says almost nothing about whose work the company can afford to lose.

Use a task ledger for two weeks. Record each meaningful task, the time spent, whether AI could attempt it, how you verified it, and the cost of a wrong answer. Do not estimate how "AI-exposed" your title feels. Count where your time actually goes. If most hours land on low-context work with cheap verification, your current role has high exposure even if your title says senior. If most hours require cross-system judgment, your role has lower exposure, but you should still use AI to reduce the mechanical parts.

## Routine implementation is the dangerous middle

The most exposed engineers are neither complete beginners nor deep system owners; they are competent implementers waiting for fully specified work. They can turn a ticket into a solid pull request, but they rarely shape the ticket, define the acceptance evidence, or operate the result.

That profile became popular for understandable reasons. Growing companies split product discovery from delivery, architecture from feature work, and operations from development. Ticket queues made staffing predictable. Interviews rewarded algorithm practice and framework recall because those skills were easier to score than judgment. The system trained engineers to stay inside a narrow box, then AI became good at the contents of that box.

Consider a common failure. Product asks for a bulk user-import feature. An engineer gives an agent the ticket and schema, gets a clean implementation, adds unit tests, and opens a pull request. The code passes. In production, large files hold a web worker for minutes, retries create duplicate invitations, and malformed rows leak partial writes. Nothing in the original ticket mentioned queueing, idempotency, transaction boundaries, rate limits, or operator visibility. The agent did not miss a hidden sentence. The team failed to turn business risk into engineering constraints.

The engineer who survives that redesign asks different questions before generating code. How large can an import be? Can users retry safely? Which side effects must occur once? What should support see when row 8,412 fails? Can we stop and resume? Which metric tells us the queue is falling behind? Those questions convert an implementation task into owned behavior.

I argue against the advice to "become an AI engineer" as a default response. It is popular because it sounds like a clean escape into a growing specialty. For some people, learning model evaluation, retrieval, inference systems, or agent design is an excellent move. For everyone else, relabeling ordinary API calls as AI expertise produces shallow candidates in a crowded market. Every industry still needs engineers who understand its data, failure modes, economics, and customers.

Do not abandon backend, mobile, security, data, or infrastructure experience to chase a label. Add AI fluency to a domain where you can recognize a wrong result. The combination is harder to replace than generic prompt skill and more useful than code generation alone.

## Reposition around ownership and evidence

Repositioning means expanding the unit of work you can own, then proving that ownership with artifacts. "I use AI every day" is weak evidence. Hiring managers have heard it from hundreds of candidates, and it says nothing about quality, speed, or judgment.

Use this ownership record for a project or substantial change:

```text
Outcome:
Constraint I discovered:
Decision I made and alternatives rejected:
Work delegated to AI:
Checks I ran myself:
Failure found before release:
Production signal after release:
Business result or cost avoided:
```

Fill every line with specifics that you can discuss without exposing confidential information. "Checks I ran" should name a load test, migration rehearsal, permission matrix, rollback exercise, or comparison against known cases. "Production signal" should name the metric, log event, trace, or support pattern that confirmed behavior. If you cannot fill those lines, the project may show activity rather than ownership.

Juniors can build this evidence without pretending to have run a global platform. Take a small open-source issue or a personal service and operate it seriously. Write the acceptance cases before prompting. Ask AI for alternatives and inspect the assumptions. Add tests for permissions, retries, and malformed input. Deploy it. Trigger a failure. Record what you changed after observing the system. A small system with honest operational evidence beats a large generated repository that nobody uses.

Mid-level engineers should move one boundary outward. If you normally own implementation, take responsibility for requirement clarification and rollout. If you already own rollout, add cost and support impact. Volunteer for incident follow-up, dependency removal, or a migration that crosses teams. These jobs are uncomfortable because the answer is not inside one file. That discomfort is where defensible experience grows.

Senior engineers should quantify the team system, not just personal output. Measure lead time from accepted request to production, escaped defects, review delay, incident load, cloud cost, and work abandoned after implementation. Then test AI on a defined class of work. A faster pull request that increases review and rework is not a productivity win.

The career shift is visible in the verbs you use. "Implemented" and "assisted" describe participation. "Defined," "constrained," "verified," "operated," and "reduced" describe responsibility. Do not rewrite your résumé with stronger verbs unless the evidence supports them. Change the work first.

## A portfolio must show supervised AI work

A credible portfolio now shows how you control AI, not how much AI-generated code you can accumulate. Recruiters and engineering leaders know that a polished demo can be produced quickly. They need a reason to believe you can work safely in a codebase that has customers, history, and consequences.

One strong case study should include the original ambiguity, the constraints you discovered, the prompts or task briefs you gave the tool, selected rejected outputs, the final diff, and the checks that established confidence. Include a short note on where AI cost time. That last detail signals judgment because real tool use includes false starts, excessive changes, and convincing mistakes.

Keep the evidence compact enough to review in fifteen minutes. A useful case study has a one-page narrative, a runnable repository, a small architecture sketch if the boundaries need explanation, and a test or command that demonstrates the risky behavior. The purpose is not to display every thought. It is to make your decision process inspectable.

For example, if you built a webhook consumer, do not stop at the happy-path handler. Demonstrate duplicate delivery, reordered events, a forged signature, timeout behavior, and replay. Explain which parts AI drafted and which assumptions you corrected. Show the command and expected result for one failure:

```text
$ ./replay-fixture duplicate-payment.json
event payment_104: accepted
event payment_104: ignored_duplicate
charges_created=1
```

That output shape tells an interviewer more than a badge claiming proficiency with a model. It shows that you understand idempotency, observability, and a business consequence. The repository does not need to contact a real payment provider; a deterministic fixture is easier to inspect.

Avoid dumping chat transcripts into the portfolio. They are noisy, may expose private data, and rarely prove that you recognized the best answer. Curate the moments where the model proposed a dangerous assumption, where a test disproved an answer, or where you changed the plan because the generated solution raised operating cost.

If your employer forbids sharing code, write a sanitized decision record. State the scale in broad terms without inventing precision, describe the constraint, and show the verification method. Hiring managers can probe the reasoning in an interview. They cannot probe a résumé bullet that only says you "used AI to improve productivity."

## Choose employers by their operating model

The best career move may be choosing a company that uses AI to expand engineering scope instead of treating it only as a headcount subtraction. You can often detect the difference during interviews by asking how work enters the team, who verifies generated changes, and what happened to junior responsibilities after AI adoption.

Ask for a recent example of an AI-assisted change that reached production. Who wrote the acceptance criteria? What review did it receive? Which production signal mattered? Did the tool reduce implementation time, review time, or total lead time? A mature answer includes friction. A vague claim that "everyone is ten times faster" usually means the company has not measured the full system.

For junior roles, ask how you will gain production context. Will you join incident reviews? Can you own a small service through deployment? Who reviews your reasoning rather than just your code? Does the company preserve work that teaches system behavior, or does it give every bounded task to an agent and leave new hires with support chores?

For senior roles, find out whether authority matches accountability. A company may expect one engineer with agents to replace a team while denying that engineer access to product decisions, observability, budgets, or deployment controls. That is not an AI strategy. It is concentrated blame. Higher span only works when the engineer can set constraints and stop unsafe work.

Founders should answer the same questions before cutting positions. I have reduced a 25-person operation to two AI-augmented engineers while keeping output and uptime, but the result depended on redesigning ownership, tools, and operating practices. Copying the headcount ratio without the surrounding system would be reckless.

This is also where team economics become personal. A smaller team can pay strong engineers more, ship with fewer handoffs, and give juniors broader responsibility. It can also burn out a few people who inherit every exception. Look at on-call load, work in progress, review queues, and vacation coverage. AI does not remove the need for slack when production misbehaves.

## Make the transition before your role is redesigned for you

You do not need to predict when a model will match every engineering skill. You need to notice when your employer can buy your current bundle of tasks more cheaply, then change that bundle while you still have room to learn.

Use the next 30 days to produce one piece of evidence:

1. Audit two weeks of your tasks by context required, verification cost, reversibility, and business consequence.
2. Pick one recurring low-risk task and test AI on total completion time, including briefing, review, correction, and release.
3. Take one adjacent responsibility that AI cannot infer, such as acceptance criteria, rollout design, cost analysis, or production monitoring.
4. Write an ownership record for the work and ask a respected engineer to attack its assumptions.
5. Turn the corrected record into a portfolio case or an internal proposal for a larger area you can own.

Do not spend the month collecting tool certificates. Tool interfaces will change. The durable skill is turning an unclear business need into constrained work, using machines where they help, and producing evidence that the result behaves correctly.

If you lead a company, evaluate roles at the task level before announcing a hiring freeze or an arbitrary AI quota. The Team & AI Audit I run maps work, costs, and operating bottlenecks over five business days, then identifies at least $50,000 a year in savings or the audit is free. The point is to redesign the system with evidence, because blunt cuts often delete context that the remaining team cannot regenerate.

Will AI take your engineering job? It may take a role built around predictable implementation, especially at the entry level, and it will change nearly every role that remains. It is less likely to replace an engineer who can discover constraints, direct tools, verify behavior, and own production consequences. Start collecting proof that this describes you before your next interview, reorganization, or budget review demands it.