"Will AI Replace Engineers?" Is the Wrong Question — Ask Which Tasks

The question arrives as a yes-or-no, and both answers are wrong. Jobs are not atomic units that get automated whole. They're bundles of tasks with wildly different exposure, and the bundle gets rewritten around whichever tasks become cheap.

That's not reassurance. A job whose expensive tasks all become cheap changes so much that the old title barely describes it. But you can only see that coming if you look one level down.

Do the decomposition on your own week

List what you actually did last week, in tasks, not responsibilities. A partial list from a typical engineering week:

• Wrote a CRUD endpoint matching an existing pattern
• Traced a bug through three services
• Decided the bug wasn't worth fixing this quarter
• Reviewed two PRs
• Explained a constraint to a product manager who wanted something else
• Chose between two database designs
• Wrote tests for a module
• Updated a runbook
• Sat in a planning meeting and pushed back on a scope estimate

Now sort each by two properties, which matter more than difficulty:

Is the output verifiable? Can you tell mechanically whether it's right — it compiles, it passes, the numbers reconcile?

Is the context complete? Is everything needed to do it present in artifacts an agent could read, or does it live in people's heads, in history, in relationships?

→ Verifiable and self-contained tasks are the exposed ones. Everything else is exposed later, or differently, or not much.

What that sorting reveals

Run it honestly and the pattern is consistent. The CRUD endpoint scores high on both — an agent does it now. Writing tests scores high on verifiable, mixed on context. Tracing a bug through three services is verifiable at the end but requires context that's often scattered and partly undocumented.

And the three items that look least like "engineering" — deciding the bug isn't worth fixing, explaining a constraint, pushing back on scope — score low on both axes. They aren't automated soon, not because they're intellectually harder, but because the inputs aren't written down anywhere and the outputs can't be checked.

⚠️ The uncomfortable finding for many people: the tasks that felt most like the real work, the ones you got hired for, are often the most exposed. Fluent implementation of a known pattern is exactly what's verifiable and self-contained.

Why bundles get rewritten rather than deleted

When part of a job gets cheap, three things happen, and only the third is job loss.

The remaining tasks expand. Less time implementing means more time deciding, reviewing, integrating. The role shifts toward whatever wasn't automated.

More of the work gets demanded. Cheaper software means more software gets attempted, including things nobody would have funded before. Whether this offsets the displacement depends on how much latent demand exists, which nobody knows in advance and which certainly varies by domain.

Fewer people are needed for a fixed amount of output. This is real where demand is genuinely fixed — an internal tools team with a bounded backlog, a company that isn't growing.

Which of the three dominates isn't a fact about AI. It's a fact about your employer's demand curve, and it differs between two teams in the same building.

The question worth asking instead

Not "will I be replaced?" but:

Of the tasks that fill my week, which are verifiable and self-contained — and if those got cheap tomorrow, what would be left, and is that a job I'm good at?

If what's left is deciding what to build, judging whether a change is right, holding context nobody wrote down, and being accountable for outcomes — that's a real job and it's the direction to move deliberately.

If what's left is thin, that's actionable information. It's much better to learn it from an honest exercise now than from a reorganization later.

✅ What the sorting implies you should do

• Move toward tasks with incomplete context. Being the person who knows why the system is shaped this way is durable in a way that fluent implementation isn't.
• Get good at verification. As generation gets cheaper, judging output correctly becomes the constraint — and it's a distinct skill from producing it.
• Stay close to the decision about what to build. That task scores low on both axes and probably will for a while.
• Keep enough hands-on depth to review credibly. Judgment without the ability to check the work is opinion.

The takeaway

The honest answer isn't yes or no. Decompose the job, sort by verifiability and context completeness, and you get a map of what's exposed and when. Some of what's exposed is the part you're proudest of. The rest — deciding, judging, holding undocumented context, being accountable — is where the job is heading, and it's worth moving there on purpose rather than being moved.