The Career Risk of Being Excellent at the Thing Being Automated

The engineers with the most exposure are frequently the ones who are best at what they do. Not despite their skill — because of what the skill is.

This is worth naming plainly, because the usual framing suggests that being good is protective, and for one specific category of good it isn't.

The mechanism

Expertise is depth in a particular activity. If that activity is fluent implementation of well-specified work — the most exposed category — then years of investment produced excellence in exactly the thing that got cheap.

Meanwhile the excellence is self-reinforcing in a way that makes the position harder to leave:

The feedback is good, right up until it isn't. Being the fastest, most reliable implementer generates praise, interesting assignments, and a reputation. Nothing signals a problem until the market for the skill changes.

Identity is entangled with it. Someone who is the person who writes the clean code has a professional identity built on the exposed skill, and identity is harder to change than a task list.

It's rational to lean in. Comparative advantage says do what you're best at. That reasoning is correct in a stable market and misleading in a shifting one, and it feels the same from inside.

The alternatives look like a demotion. Moving from producing to specifying, reviewing, and deciding can feel like leaving the real work — particularly for someone who chose the field for the craft.

⚠️ Which is why this lands hardest on the people who care most about the work.

What actually transfers

The situation is better than it sounds, and it isn't the excellence itself that carries over — it's what produced it.

The taste. Knowing what good looks like, recognizing a solution shape that goes wrong, sensing where the difficulty is. That's what's needed to evaluate generated output, and it's the scarce input now. It transfers directly.

The systems knowledge. Years of implementation produced a model of how things fit together. That model is what makes review credible and debugging possible.

The precision. The habit of caring whether something is exactly right rather than approximately right. That's what makes a good specification, and specification is the constraint.

→ The excellence doesn't transfer. The judgment that produced it does — and that's the part worth consciously repositioning around.

✅ What to do about it

Notice which list you're on. If your value is production speed and quality, that's the exposed list, however good you are. This is a five-minute honest assessment and most people avoid it.

Move the demonstration, not the skill. You don't have to stop being excellent at implementation. You have to stop having that be the thing you're valued for — which means making the judgment visible: decision records, prevented problems, reviews that caught what nobody else would have.

Take the review work seriously. It's where the taste is applied, it's the current bottleneck, and doing it well is a strong position. Not a consolation prize.

Keep enough hands-on practice to review credibly, and let it be a means rather than the product.

Get proximate to decisions. The judgment developed over years is most valuable applied to what to build rather than to how to build it.

💡 The honest part

Some of this is a loss, and pretending otherwise doesn't help. If what you loved was the craft of writing excellent code and that's now less scarce, that's a real thing to have lost, and reframing it as an opportunity is a move that lands poorly when someone else makes it for you.

The consolation that's actually true: the judgment is the durable half, it was earned by the craft, and it applies to a wider set of problems than the craft did. Whether that trade feels acceptable is individual, and it's worth being honest with yourself about rather than performing enthusiasm.

The takeaway

Excellence at fluent implementation is exposure, not protection, and the feedback loop hides it until the market shifts. What transfers isn't the excellence — it's the taste, the systems model, and the precision underneath it. Move what you're valued for toward judgment while keeping the practice that maintains it, and take review and decision work seriously rather than as a step down from the real thing.