How Not to Lose Your Engineering Job to AI: Part Two

In November 2024, I published How to Not Lose Your Engineering Job to AI. Coding agents were much less capable, but the speed of progress already made it clear that writing code would become a smaller part of the value an engineer provides.

I wrote:

The days of being valuable purely for your ability to crank out code are numbered.

I still believe that. But I supported it with an unrelated customer-service example and spoke about productivity with more certainty than the available evidence justified. Faster code generation does not translate cleanly into faster delivery, and it says even less about how many engineering jobs will exist.

I also wrote:

AI can generate code, but it’s not good at managing infrastructure—at least not yet.

That aged quickly. Agents can now inspect repositories, run applications, use browsers, investigate logs, configure containers, diagnose deployments, perform migrations, and continue through failed attempts. The important boundary is no longer whether an agent can touch infrastructure. It is who controls its authority, verifies the result, and owns the consequence.

The original article ended with:

Don’t be just a coder. Be an architect. Be a communicator. Be a problem-solver.

The direction still holds, but “be an architect” can become another vague slogan. Two years later, we have better tools and better evidence. We can be more precise about which engineering skills are becoming more valuable—and which ones we still need to protect.

Calling coding agents junior developers now understates their breadth and speed. Calling them senior developers overstates their judgement, organisational context, and accountability.

The serious question is therefore not whether an agent can write code. It can. The question is which parts of engineering become more valuable when implementation capacity becomes abundant—and which skills atrophy if we outsource them without understanding the result.

What the Evidence Actually Shows

We do not yet have one clean number for how much AI improves software development. Different studies measure different developers, tools, repositories, and definitions of success.

In an early-2025 randomized controlled trial, METR studied 16 experienced open-source developers completing 246 real issues in repositories they knew well. When AI tools were allowed, the developers took 19% longer on average, even though they believed the tools had made them faster. The study was narrow: experienced maintainers, mature repositories, tasks lasting roughly 20 minutes to four hours, and early-2025 tools. It did not show that AI slowed every developer or every kind of work.

METR attempted a follow-up with later tools and published an unusually important caveat. Developers increasingly refused to participate when assigned to work without AI, concurrent-agent workflows made time measurement harder, and changes in recruitment created selection effects. The raw results suggested newer tools may have produced a modest speed-up, but METR concluded that the data could not reliably establish its size.

That uncertainty is more useful than another marketing multiplier. AI clearly compresses some work. It can also move effort into prompting, reviewing, waiting, correcting, and integrating. The result depends on whether the task is easy to specify and verify, how much repository context matters, and whether the developer can recognise a solution that is almost right.

The 2025 Stack Overflow Developer Survey captures this tension at broader scale. Among 33,244 respondents to its accuracy question, 46% distrusted AI output while 33% trusted it. The most commonly reported frustration, selected by 66% of respondents to that question, was receiving solutions that were almost right but not quite. Self-reported surveys do not measure causal productivity, but they show why verification remains central even when adoption is widespread.

Do Not Compete With the Agent at Typing

If your value is defined as turning an already precise ticket into conventional code, agents will increasingly compete with that part of your work. They can generate implementations, tests, migrations, documentation, and alternative approaches in parallel. They do not become tired of boilerplate and they can cheaply retry.

That does not make engineering obsolete. It changes the bottleneck.

Somebody still has to determine:

• Whether the ticket describes the real customer problem.
• Which constraints are business rules rather than historical accidents.
• Whether a locally correct change fits the architecture and operating model.
• What evidence is sufficient to release it.
• Which new failure modes and obligations the change introduces.
• Whether the feature should exist at all.

These decisions were always part of good engineering. When code was expensive, implementation occupied more of the visible work. As agents reduce that cost, judgement becomes a larger share of the remaining value.

Domain Expertise Becomes More Important

The person who knows why the system exists can direct an agent better than the person who merely knows the syntax used to build it.

Anthropic's 2026 analysis of roughly 400,000 Claude Code sessions found a recurring division of labour: people made most planning decisions while the agent made most execution decisions. Users with more relevant domain expertise succeeded more often and recovered more effectively from errors and misunderstandings. Because this is observational research on one vendor's own product, it cannot establish that expertise caused success or that the same pattern applies to every agent. It nevertheless matches what I see in practice.

An engineer who understands the customer, data, operational history, regulatory constraints, and economics of a workflow can recognise when a polished implementation solves the wrong problem. They know that an apparently redundant check protects an old integration, that a status has a contractual meaning, or that a five-minute delay is acceptable while a duplicate payment is not.

This context is difficult to reconstruct from code alone. It is also where engineers can become much more valuable: attend customer conversations, investigate support patterns, understand how the company earns money, and learn which failures matter to the business. The better you understand the domain, the more implementation work you can safely delegate.

Keep Enough Technical Depth to Disagree

“Become a manager of AI” is incomplete career advice. You cannot effectively direct or review technical work that you no longer understand.

You still need a mental model of data flow, state, permissions, concurrency, failure handling, deployment, and the architecture around a change. Without it, you can judge whether the interface looks convincing but not whether the system is safe. Agents are especially persuasive when their output is coherent, and coherent output can still encode a bad assumption.

There is early evidence that careless delegation can also weaken learning. In a randomized study, developers used AI assistance or conventional resources while learning a new Python library. The AI-assisted group showed weaker understanding in the subsequent assessment, with the largest gap appearing in debugging questions. The study covered one learning task and should not be generalised into “AI prevents learning.” It does support a practical concern: getting working code is not the same as building the knowledge required to repair it later.

Use agents to extend your reach, not to remove yourself from the reasoning loop. Ask why a solution works. Trace important paths. Read migrations and security-sensitive changes. Predict failure cases before running the tests. Occasionally implement or debug without assistance so your ability to form an independent model does not disappear.

The aim is not to prove that you can out-code the tool. It is to preserve the expertise required to know when the tool is wrong.

Own Verification, Not Just Review

A traditional code review often begins after somebody believes the implementation is complete. With agents, verification should be part of the implementation loop.

Require the agent to run the application, exercise the real interface, test edge cases, inspect logs, and show the resulting behaviour. Ask it to review the change again from a fresh perspective for regressions, security problems, unnecessary abstractions, and migration risk. Tests are evidence, but the test suite itself may encode incomplete assumptions, so important changes also need human judgement about what was not tested.

The engineer's role is not to read every generated line with equal intensity. It is to design proportionate evidence:

• A visual change needs browser interaction and inspection at relevant sizes.
• A permission change needs positive and negative authorization cases.
• A migration needs compatibility and rollback reasoning.
• A background job needs retry, duplication, and observability checks.
• A performance claim needs a repeatable measurement under representative conditions.

This is a higher-value skill than manually producing boilerplate because it scales across human- and agent-written work. The person who defines convincing evidence becomes the quality boundary for a much larger amount of implementation.

Operations Are About Authority and Consequence

My original article said AI was not good at infrastructure. That is already outdated. Agents can inspect hosts, configure containers, diagnose deployments, query monitoring systems, and repair many operational problems.

What they cannot own is the organisation's risk decision.

Production work has consequences that extend beyond technical correctness: downtime cost, customer communication, regulatory obligations, recovery objectives, credential exposure, and the acceptable radius of an automated action. An agent can explain firewall rules or propose a database failover. A responsible person must decide whether the evidence is sufficient and whether the mutation is authorised.

Engineers who understand operations therefore remain valuable, but not because they memorise more shell commands than a model. They understand the system's failure modes, keep recovery paths available, restrict permissions, sequence risky changes, and know when to stop automating.

The Labour-Market Story Is Not Settled

It is tempting to turn capability progress into a confident prediction that engineering jobs will disappear—or that they will merely become more productive. Current evidence supports neither simple conclusion.

Anthropic's 2026 labour-market research combines theoretical capability with observed AI use to estimate exposure. It found that actual use remained well below theoretical capability and reported no systematic unemployment increase in highly exposed occupations since late 2022. It did find suggestive evidence that hiring of younger workers had slowed in exposed occupations. This is an early observational signal, not proof that AI caused the change.

The likely transition will be uneven. Some teams will use agents to increase output. Some companies will require fewer people for implementation-heavy work. Other teams will attempt more projects because the cost has fallen. Junior roles may change if organisations stop valuing the tasks through which people traditionally learned. New work will appear around evaluation, integration, security, operations, and translating domain constraints into reliable systems.

Nobody can promise that becoming “AI native” guarantees employment. The defensible strategy is to build skills that remain necessary across several plausible futures.

A Practical Career Strategy

I would focus on five things:

1. Learn to operate agents deeply. Give them access to the relevant environment, define the outcome, and make them prove their work instead of accepting generated code as completion.
2. Develop domain knowledge. Understand customers, workflows, data, constraints, and the economics behind the software.
3. Maintain technical judgement. Keep enough depth to evaluate architecture, security, reliability, and failure modes independently.
4. Become excellent at verification. Design tests and evidence that reveal whether a change works in the real system, including what happens when it fails.
5. Own outcomes. Connect engineering decisions to customer value, operational consequence, and the long-term cost of the product.

AI does not reduce the value of a strong engineer to the quality of their prompts. It increases the leverage of somebody who understands the problem, can constrain the solution, and knows how to establish that the result deserves to run in production.

Writing code remains useful. Being the person who knows what should be built, what must remain true, and how to prove it is more durable.