Will AI Take Our Jobs? What Still Makes a Software Engineer Valuable

Take the anxiety seriously, then make the question smaller

“Will AI take our jobs?” is a reasonable question from someone whose income depends on building software. Dismissing that concern with a motivational slogan is unhelpful. So is claiming certainty about a labor market that depends on budgets, adoption, product demand, regulation, and technical progress. I would separate the question into tasks that can be automated, responsibilities that still require ownership, and employment decisions that no benchmark can predict by itself.

An assistant can generate a plausible endpoint, explain an unfamiliar function, or suggest tests. That changes the cost of producing a first draft. It does not automatically establish whether the endpoint should exist, which customers may call it, what historical behavior must remain compatible, or how the organization will respond if the feature damages data. Those questions are part of software engineering even when no new code is being typed.

My position is that engineers should learn to use capable tools while becoming more explicit about their own contribution. That is a practical response to uncertainty, not a guarantee of job security. A team may still change its staffing model. An individual can nevertheless improve the quality of their decisions, the evidence behind their work, and their ability to connect an implementation with a real customer or operational need.

Read productivity studies with their boundaries attached

Evidence about AI coding is useful when its setting stays attached to its result. METR's February 2026 update explains that its earlier experiment found a slowdown for experienced open-source developers using early-2025 tools. The follow-up showed signals of speedup, but the researchers described selection effects and measurement problems that made the current effect unreliable. That is evidence about difficult measurement, not proof that every engineer is faster or slower with every assistant.

DORA's 2025 report describes AI as an amplifier of an organization's existing strengths and weaknesses. I read that as a reason to inspect the delivery system around the tool: clear requirements, feedback quality, reliable tests, and the ability to integrate changes. It is an interpretation for engineering practice, rather than a claim that the report can forecast the number of developers a company will employ.

The useful workplace question is narrower: for this kind of task, in this repository, with this review standard, what changes? A new isolated utility, a security-sensitive migration, and a bug in a mature codebase impose different costs. Record the tool version, task category, review time, defects, and rework. Treat an early result as a local observation. Repeating the measurement after a workflow or model changes is more honest than turning one experiment into a permanent rule.

Sources: METR: developer productivity experiment update, February 24, 2026 · DORA: State of AI-assisted Software Development 2025

Generation and acceptance are different jobs

Imagine asking an assistant to build an endpoint that updates an organization's billing contact. The generated code validates an email address, looks up an organization, and writes the new value. It looks complete. But who is allowed to change that organization? Does the audit record preserve the previous contact? What happens if the same request arrives twice? Does a notification disclose the new address to somebody who should no longer have access?

The engineer accepting the change owns those questions. A review that checks only formatting and successful compilation cannot establish the behavior. I would first write the expected authorization rule, audit event, retry behavior, and error contract. Then I would use the assistant to propose an implementation and challenge it against those expectations. This makes the tool an input to a decision rather than the authority for deciding whether the feature is safe.

The same distinction applies to tests. A generated suite may confirm the assumptions of the generated implementation. Independent examples are needed to challenge them. For the billing endpoint, I would include a user from another tenant, an expired membership, an interrupted response after persistence, and an attempted update with unchanged input. The valuable work is identifying why these cases matter and proving the behavior at the correct boundary.

Measure the whole delivery path

Typing time is visible. Integration cost is easier to miss. An engineer may produce a patch quickly and then spend hours untangling an unnecessary dependency, correcting an inconsistent error model, or explaining an oversized change. If a team measures only how fast the first patch appears, it can reward work that shifts effort onto reviewers and operators.

For a small trial, I would compare similar task categories and record time from a clear requirement to an accepted change. Review duration, failing checks, reopened issues, and follow-up fixes belong beside implementation time. The trial should also note whether the author already knew the codebase. A tool that helps discover an unfamiliar module may behave differently when a maintainer already knows exactly where the fix belongs.

Not every benefit is a speed measurement. Better explanations can help a teammate learn. Drafting a test harness can lower the cost of exploring an edge case. Those benefits deserve specific descriptions instead of a universal multiplier. A short weekly review of accepted and rejected suggestions can reveal where the assistant is useful, where it repeatedly misunderstands the repository, and where the team should invest in better context or automation.

Protect the boundaries the model cannot authorize

An assistant does not gain permission to see customer records simply because they would improve an answer. Before using any tool with sensitive material, the team needs an approved handling policy and an understanding of what is transmitted, retained, and accessible. The practical working set should be as small as possible: a synthetic example, a redacted trace, or a narrow interface often communicates the problem without exposing private data.

Execution is another boundary. A plausible shell command can delete state, publish a package, or apply an irreversible migration. I would distinguish reading from mutation and require a reviewable result before crossing a production boundary. Tool access should follow the engineer's actual authorization. The presence of a credential in an environment is not evidence that an automated workflow should use it for every suggested action.

When an assistant proposes a dependency or an API, verify it in the project's approved sources and run the relevant checks. When it suggests a data repair, inspect the affected set before applying the mutation. These are ordinary engineering controls made more important by the ease of generating confident instructions. The objective is to make a mistaken suggestion recoverable and to keep a real person accountable for the decision that affects users.

Build skills that make uncertainty easier to handle

The strongest response to changing tools is a learning plan connected to actual work. Reading unfamiliar code, tracing a request through several services, explaining a query plan, identifying an authorization boundary, and writing a reversible migration all remain useful when the implementation language changes. An assistant can help practice these skills, but it should not be the only judge of whether the explanation is correct.

I would choose one modest system and follow it beyond the happy path. Add an operational dashboard, reproduce a concurrency bug, measure a slow query, and document a recovery procedure. Ask a colleague to challenge the assumptions. The resulting evidence says more than a list of tools used for an afternoon. It demonstrates the ability to notice a problem, develop an explanation, test an intervention, and communicate the limitations.

Communication belongs in that plan. A senior engineer often creates value by making a difficult choice understandable to product, security, support, and other engineers. Write a short decision record that states the rejected alternative and the cost of the chosen approach. Explain what evidence would change the decision. That skill helps a team move safely when neither the engineer nor the assistant has complete information at the start.

Give early-career engineers real ownership with support

There is a risk in treating every small implementation task as something that should disappear from a junior engineer's workload. Small tasks are also where people learn how a system behaves, how reviews work, and why seemingly harmless changes can fail. A team that removes the learning path may later struggle to develop the judgment it expects from senior staff.

A better exercise is bounded ownership. Give a developing engineer a real user problem, a clear reviewer, and a limited release scope. Let them use an assistant, but ask them to explain the contract, reproduce the relevant failure, and demonstrate a recovery path. The reviewer should discuss the reasoning instead of merely supplying the final patch. The result can teach both tool use and independent engineering judgment.

Senior engineers need the same discipline. Refusing assistance can become an identity habit; accepting every suggestion can become another. Neither is a reliable professional standard. The standard should be whether the engineer understands the change well enough to defend its behavior, maintain it, and intervene when the assumptions stop holding. Tool fluency and technical accountability can develop together.

Try a controlled comparison on one real task

For a team evaluating assistance, choose a bounded task with a clear acceptance contract. A suitable exercise might add a filter to an existing internal search endpoint. Record which behavior must remain compatible, which permissions apply, and how the result will be checked. Do this before seeing a generated implementation so the acceptance criteria do not drift toward whatever the tool happens to produce.

Let the engineer keep a brief record of useful suggestions, rejected suggestions, review effort, and follow-up changes. Compare the result with similar work cautiously. Different people and tasks are not interchangeable experimental units, and a small workplace trial cannot support a sweeping causal claim. It can still reveal practical friction: missing repository context, oversized patches, unreliable generated fixtures, or an explanation that helped the engineer locate the right module.

Finish by asking the engineer to explain the accepted change without consulting the generated conversation. Can they describe the failure boundary, the test evidence, and the safest way to modify it next week? If they cannot, the workflow has produced an ownership gap even if the feature works today. Improve the process before expanding it. The objective of this exercise is an understandable accepted change, with useful observations about the tool, rather than a headline claiming a universal productivity gain.

Show the work that deserves trust

On a portfolio or in an interview, I would explain where AI helped and where independent decisions were necessary. For a fictional contact-management feature, that might mean using an assistant to draft validation code while personally defining tenant authorization, writing a concurrent update test, and verifying audit behavior. Clear attribution makes the discussion more credible than pretending every line was typed unaided or that generation solved the entire problem.

The same approach helps a hiring manager evaluate seniority. Ask the candidate what the first draft got wrong, what evidence changed their approach, and which failure they chose to test. These questions make room for useful tool use while still exposing understanding. A polished repository is easier to generate than a coherent explanation of why its boundaries and recovery behavior are correct.

AI will continue to change the work. The responsible response is to remain curious about its capabilities, honest about the evidence, and demanding about the behavior shipped to users. I cannot promise what a particular employer will do. I can describe an engineering standard worth practicing: define the problem carefully, use assistance deliberately, verify the result independently, and stay accountable after the merge. That is the professional value I would keep building.

Further reading

• METR: February 2026 productivity experiment update ↗
• DORA: 2025 AI-assisted development report ↗