The honest answer is yes: AI could put some of us out of a job.

The more useful answer is that it will not happen because a model suddenly becomes “a software engineer.” It will happen when a company redesigns work around the model, decides it needs fewer people for the same output and accepts the operational risk that comes with that decision.

That distinction matters. Technology creates the capability; organisations decide how to use it.

I work in mobile engineering, where a convincing demo and a production system are separated by lifecycle, state, accessibility, privacy, observability, offline behaviour, API contracts, release processes and years of accumulated product decisions. AI can already generate a respectable Compose screen or SwiftUI view. That is useful. It is not the same as owning the application.

But it would be complacent to turn that gap into reassurance. Models are improving, agents are taking on longer tasks and the economic pressure to convert productivity into lower headcount is real. The job is not safe simply because the tool still makes mistakes.

The people building AI do not agree on what happens next

The current debate among AI leaders is unusually direct.

In a June 2026 essay, Anthropic CEO Dario Amodei argued that AI may be a broader substitute for human cognitive work than earlier technologies. He sees a “decent possibility” of significant, enduring job loss and is already calling for wage insurance, retention incentives and potentially universal basic income.

OpenAI CEO Sam Altman has recently sounded less alarmed. At a Commonwealth Bank conference in May 2026, he said he was “delighted to be wrong” about how quickly entry-level white-collar roles would disappear. He pointed to a part of work that people still want from other people: communication, trust and human presence.

Google DeepMind CEO Demis Hassabis made the growth case more explicitly around Google I/O in May 2026. If engineers become three or four times more productive, he told WIRED, Google wants to “do three or four times more stuff”. Cutting engineers in response, in his view, shows a lack of imagination.

At a Milken Institute conference in May 2026, Nvidia CEO Jensen Huang drew a distinction between a job and its component tasks. “AI creates jobs,” he said, arguing that automating an activity does not automatically remove the purpose of the role around it.

None of these positions is a neutral forecast. Every AI CEO has commercial incentives, and every prediction should be read with that in mind. Yet the disagreement reveals the real variable: what happens to employment depends not only on model capability, but on demand, company strategy, regulation and how work is redesigned.

A job is a system of tasks, responsibility and trust

The replacement question is usually framed badly: can AI do a developer’s job?

A better set of questions is:

OpenAI’s April 2026 jobs-transition framework uses a similar model. It estimates that 18% of US jobs face relatively high automation risk, while 24% are more likely to be reorganised and 12% could grow as lower costs increase demand. The largest group—46%—shows less immediate change. Those are scenarios, not promises—and they come from a company with an obvious interest in adoption.

The independent evidence is still early. A June 2026 review from the International Labour Organization found real but uneven productivity gains, limited large-scale displacement so far and a particular risk to opportunities for younger workers. That is a less dramatic story than either mass unemployment or universal abundance—and closer to what I see in engineering: tasks are moving faster than organisational structures.

What AI changes in a mobile team

AI is already strong at bounded, legible work: drafting tests, mapping data models between layers, explaining an unfamiliar module, proposing migrations, generating fixtures, summarising logs and producing the first implementation of a well-described component.

That removes meaningful effort, and it changes the value of some engineering habits. Memorising framework syntax matters less. Producing boilerplate on demand is no longer much of a differentiator. A role built mainly around turning detailed tickets into predictable code is exposed.

The work that remains is not mysterious or uniquely human. It is simply harder to specify and verify:

This is where staff-level engineering sits. My value is not the number of lines I can personally type. It is reducing uncertainty, creating a path through constraints and leaving a system and team easier to operate.

AI helps with that work, but it does not remove the need for it. In fact, cheaper code can increase the amount of judgement required. When the cost of producing five plausible implementations falls close to zero, choosing the right one—and proving it is right—becomes the expensive part.

The junior-engineer problem is the part we should not dodge

Senior engineers can say, with some justification, that coding was never the whole job. That answer is much less comforting to someone trying to enter the profession.

The routine work AI absorbs is also how engineers have traditionally learned: small bug fixes, test coverage, contained features and time spent reading code in order to change it. If companies remove that work without designing another path to competence, they do not merely reduce junior hiring. They damage the pipeline that produces future senior engineers.

Anthropic’s latest Economic Index survey reflects that anxiety: early-career respondents reported the highest task exposure and the most concern about job loss. More than a third of respondents assigned a greater than 60% chance that a junior colleague would lose a job in the next year. The sample is made up of Claude users and is not representative of the wider workforce, but the signal is too important to ignore. The same survey carries a counter-signal: the respondents who delegated the most work to Claude were also the most optimistic about their own prospects.

Engineering leaders need to treat apprenticeship as infrastructure. Junior engineers still need bounded ownership, review that explains reasoning and time to build mental models. “Let the agent do it” may optimise this sprint while creating a capability problem two years later.

AI fluency is necessary, but it is not the moat

“Learn to use AI” is correct advice, but incomplete. Tool familiarity diffuses quickly. Knowing a particular prompt pattern will not protect a career for long.

The durable advantage is being able to direct and verify increasingly capable systems. For a mobile engineer, I would focus on five things:

  1. Use AI on real work. Learn where it saves time, where it loses context and which tasks become slower once review and repair are included.
  2. Strengthen verification. Tests, observability, security review, performance measurement and release safety become more valuable as code becomes cheaper to generate.
  3. Keep platform depth. Lifecycle, concurrency, rendering, storage, networking and operating-system constraints are what let you recognise a plausible but wrong answer.
  4. Move closer to the outcome. Understand the user problem, the business constraint and the operational consequences. Do not allow your role to collapse into implementation alone.
  5. Build team leverage. Good architecture, clear contracts, useful documentation and mentoring allow both people and agents to work safely at greater speed.

There is a warning in the 2025 Stack Overflow Developer Survey: 84% of respondents used or planned to use AI tools, yet 46% distrusted their accuracy. Adoption is not the same as confidence. The engineers who can close that gap—turning fast output into trustworthy delivery—remain valuable.

So, will AI take your job?

It may take parts of it. It may change the size and shape of your team. In some companies, it will be used to justify cuts before the technology is capable of replacing the people who leave. In others, the same productivity will fund products that were previously too expensive to build.

I do not believe software engineering disappears when models write most of the code. I do believe an implementation-only version of the role becomes difficult to defend.

The safest response is not denial, panic or a race to produce more code. It is to become accountable for a larger outcome: frame the right problem, use AI aggressively where it works, verify it where it fails and own the consequences in production.

AI is making implementation abundant. Judgement, trust and responsibility are not abundant yet. That is where I would build my career.