Working in the AI era · Software engineering
Will AI replace software engineers?
Producing code, delivering a reliable change, and getting hired are different problems. A useful career decision needs evidence about all three.
The short answer
AI can change the work and the entry route without eliminating every engineering role.
The evidence below does not establish a date when software engineers disappear. It also does not justify promising that human judgment will preserve today's staffing. Faster development could mean more software, smaller teams, different hiring requirements, or a combination. Which happens depends on the organization and demand for its work.
If you are choosing a course or first job, investigate who will teach you to understand and check generated work. If you already work in software, examine which responsibilities your employer still needs and how it measures your contribution. Neither an impressive demo nor an alarming headline answers those questions.
Five kinds of evidence that should not be mixed together
Here, “software engineering” refers broadly to developing and maintaining software. Official occupational categories do not map perfectly to employers' titles. A figure for programmers, all technology workers, or all AI-exposed occupations is not automatically a figure for software developers.
U.S. projection · 2025–2035
Projected growth is not a promise to a new graduate.
BLS projects software-developer employment to grow 10% over 2025–35. Its broader developer/QA/tester group also has 10% projected growth and about 106,100 annual openings, including replacement needs.
Limit: These are national projections, not observed junior hiring or measured AI-caused job changes. The openings figure covers the combined group; it is not all new developer jobs.
Source: BLS outlook and occupation tableOccupational task inventory · accessed October 2026
The job includes decisions around the code.
O*NET describes software-developer work involving needs analysis, modification of existing software, testing, and consultation with others about requirements and performance.
Limit: A task inventory describes work; it does not prove that a task cannot be automated or that an employer will retain the same number of people.
Source: O*NET software developersProductivity research · February 2026 update
A task-speed result has a population and a date.
METR's early-2025 study found a slowdown among experienced open-source developers using the tools studied. Its follow-up warns that participant and task selection, plus time measurement with concurrent agents, make the newer productivity estimate unreliable.
Limit: Neither result is a universal statement about today's tools, beginners, or jobs lost. Do not reuse an old slowdown headline as proof that AI is ineffective.
Source: METR methods updateLearning experiment · January 2026
Finishing a task and learning from it can diverge.
Anthropic studied 52 mostly junior engineers learning an unfamiliar Python library. The AI-assisted group did worse on an immediate mastery quiz; the task speedup was not statistically significant. How participants used assistance also differed.
Limit: This provider-run experiment concerns a specific learning task and immediate assessment, not long-term skill development or the value of a degree. It does not show that every use of AI reduces learning.
Source: study design and learning resultsU.S. labor-market analysis · March 2026
Exposure is not a probability of losing a job.
Anthropic's analysis found no systematic unemployment increase in highly exposed occupations, with tentative evidence of slower entry by younger workers. Its exposure measure combines task feasibility and observed platform use.
Limit: The provider's usage is not the whole labor market; the occupational groups are broader than software engineering. Survey measurement and alternative explanations matter. This is not proof that AI caused a particular hiring rejection—or proof that entry-level opportunities are unaffected.
Source: labor-market analysis and caveatsOur interpretation: Treat the learning route and the employer's actual work as investigation priorities. Confidence is higher in the need to separate capability, productivity, hiring, and employment than in a forecast of your personal prospects. We do not assign replacement odds or an “AI-proof” score.
Ask what must be true before the work is accepted
These are fictional work situations and editorial questions, not measured market segments or a safety ranking. AI may assist with review and testing too; responsibility alone does not guarantee headcount.
A disposable prototype
The job: Make a small demonstration so a team can decide whether an idea is worth exploring.
What could change: Generating a first version may require fewer implementation hours. The useful contribution may shift toward defining what the demo tests and preventing viewers from mistaking it for a supported product.
Ask: Is success the appearance of a working screen, evidence from a user, or a maintainable service? What happens to prototypes that attract real users?
A change inside an existing service
The job: Add behavior without breaking contracts, data, or existing users.
What could change: More candidate code can increase the amount needing review. Generated tests may repeat the same mistaken assumption as the implementation. A team may automate checks, narrow change scope, or demand more delivery per person.
Ask: Who explains the existing behavior, reviews the change, decides what evidence is sufficient, and helps when it fails? Request an example of a rejected change and why it was rejected.
A service with ongoing consequences
The job: Keep a system useful after release, including handling incidents and changing requirements.
What could change: Tools can help investigate failures and propose repairs. Someone still has to establish the acceptable outcome, permissions, and evidence for action—but that work can be reorganized or concentrated in fewer roles.
Ask: What is the supervision model? Who can deploy or roll back? What are the on-call expectations, and do beginners get protected learning time?
For juniors, investigate the feedback loop—not just the tool list
A course promising fast app creation and an employer promising access to AI agents may both be useful. Neither promise establishes that you will learn to diagnose a wrong result. Use these questions before committing substantial money or time.
- Request an assignment and its review rubric. Does it require explaining the behavior, testing a failure case, and revising an existing project? A polished gallery alone does not show how independently learners can work.
- Ask who reviews your reasoning. Look for a specific feedback arrangement, not merely “mentoring available.” Ask how learners get help with a mistake they cannot yet describe.
- Check the claimed outcome. Ask which cohort, which job titles, which time period, and which learners are included in placement figures. Do not compare unlike percentages.
- Examine constraints. Compare total cost, time, prerequisites, permitted AI use, and your ability to finish. A stronger course is still a poor plan if its schedule is impossible for you.
Our suggested learning loop: predict what a small change should do; attempt or trace it yourself; use permitted assistance to investigate a specific uncertainty; test an unexpected case; explain the result without the assistant. Keep a record of what you misunderstood and corrected. This is a practice recommendation, not a proven hiring formula.
If you already work in software, compare your current role against the three situations above. Ask your manager which outcomes matter as tooling changes. Do not assume producing more lines of code demonstrates greater value, or that becoming a reviewer removes the need to understand implementation.
Separate labor-market concern from personal fit using the software-engineer fit guide. Explore your preferred working conditions with the work-values assessment. Neither forecasts employability.
An original 20-minute review exercise
Would you approve the generated change?
No coding experience, subscription, or live system is needed. Work through the fictional sequence, write your reasoning, then compare the worked answer. This tests a way of investigating, not your aptitude or job readiness.
Fictional case: two people, one remaining seat
A community event has one seat left. A proposed AI-assisted booking change checks whether a seat is available, creates a confirmation, and then reduces the remaining-seat count. A demonstration with one booking succeeds.
- Alex's request reads “1 seat remaining.”
- Before Alex's request finishes, Bea's request also reads “1 seat remaining.”
- Both requests create a confirmation.
- Both write “0 seats remaining.” The display looks correct, but two people have been promised the last seat.
Requirements: At most one confirmation for the last seat. The unsuccessful visitor must receive a clear outcome. No payments or personal records are part of this exercise.
Entries are not submitted or saved by this page. Copy your notes before leaving. Use fictional information only; do not paste employer code, secrets, or personal data. The exercise, fields, reset, and worked answer work without JavaScript.
Compare your reasoning with a worked review
The missing case: Both requests read the same available seat before either completes. Checking availability separately from claiming the seat allows the promise to be made twice. The final count alone cannot reveal that error.
The evidence: Start with one available seat and overlapping requests. Require exactly one confirmation and a clear unsuccessful outcome for the other request; verify the booking records as well as the displayed count. Also investigate retries: if a visitor repeats a request after a slow response, can it create a second booking? A test designed from the requirements is more useful than one that merely reproduces the implementation's assumptions.
The correction to discuss: Ask how the implementation makes checking and claiming the seat one coordinated operation, and how it handles repeated requests. The correct mechanism depends on the storage and system design. This example is not a production implementation or a complete test plan.
The release question: Agree on who reviews and authorizes the change, what evidence reveals duplicate confirmations, and how affected bookings would be reconciled. Rolling code back does not automatically repair promises already made. Do not experiment on a real service without authorization.
The career takeaway: Did you enjoy turning a plausible result into a precise question? Were you willing to investigate beyond the visible screen? One exercise cannot decide your career. It can give you a concrete question to bring to a course provider or practitioner.
Turn the unanswered question into a small career experiment, or compare preparation options with the career-change planner.
Questions that deserve a conditional answer
Will AI replace software engineers by 2030?
No source here establishes that deadline. A benchmark, a projection period, and a company's staffing plan measure different things. Ask what changed in the specific work you intend to pursue, not whether a year appeared in a headline.
Should I still study software engineering?
Investigate it if you want to understand systems and can find a realistic learning route. Try a small project, maintain or debug something unfamiliar, and ask for feedback before making a large commitment. Interest, affordability, access to supervision, and local hiring requirements all matter; this guide cannot make the decision for you.
Will junior jobs disappear first?
The labor-market source above raises an entry-route concern but does not establish that all junior software jobs will vanish. Research actual responsibilities and supervision in the vacancies you could pursue. A title marked “junior” does not tell you how much independent delivery is expected.
Is learning to prompt enough?
A prompt can ask for a change; it does not establish that the result meets the requirement. Use the booking exercise to see the difference. Learn enough of the underlying system to question output and recognize when you need help. This is not a claim that any one skill guarantees employment.
Should I move into cybersecurity, data, or AI engineering instead?
Those are different jobs, not proven shelters. Compare their actual tasks, prerequisites, and entry routes. Switching because a title sounds safer can trade one untested assumption for another.