Why giving away your expertise makes you more valuable
The fear of being replaced by AI pushes experts to hoard their judgment, which is exactly what makes them replaceable.
You’ve met the non-technical person who spent an afternoon with Claude Code and concluded software engineers are done. Or the one who tried an AI design tool and is ready to replace the design team. To anyone who does the work, it’s laughable and insulting. It’s also scary, because the labor market is unstable enough that the question sticks anyway: am I that easy to replace?
No. The people saying yes are making a specific mistake: they have equated expertise with the most common tasks in the job. An engineer’s value was never typing code. A designer’s value was never placing elements on a canvas. A product manager’s value was never writing tickets. Those were the most visible parts of the role, and the most tedious, which is exactly why they were the first to automate. The expertise was always the judgment underneath: what to build, what not to, what the user will actually do with it.
So the claim is wrong. The problem is that it is harmful. Fear of being replaced pushes people toward something that can actually make them replaceable: locking their judgment up where only they can apply it. From the outside, hoarded judgment looks exactly like a bottleneck. The way out of that fear is the opposite of what it suggests: give that judgment away. Publish it into the systems your team already works in, and you end up in more decisions, not fewer. The rest of this post is about why that’s hard, why people don’t, and what it actually looks like when they do.
Everyone’s coping, nobody’s collaborating
The fear is understandable. The reactions to it are what cause problems. They seem to run along a spectrum, and both ends assert the same thing, relevance, in the face of an implication that we no longer matter.
At one end: the “10x” engineer, heads-down with an agent, outproducing everyone, treating collaboration as drag. Save yourself. At the other: rejecting the tooling, or clinging to authority over a process so that nothing ships without passing through you. The reviewer who re-reads every generated line is here too, not because the code needs it, but because being the person who reads every line is the last place their expertise is visibly required.
None of these addresses quality at scale. The first abandons collaboration; the rest refuse scale. All of them assume quality lives in a person rather than in something people share. The irony is that knowledge was never what made any of us expert. Judgment was, and judgment is the thing most easily overlooked in the excitement about what the latest model can do.
These reactions don’t stay personal. Throughput becomes uneven across a team, so handoffs land on people who can’t absorb them. Communication quality drops: verbose, generated messages at handoff, effort redirected to output over clarity. And gates get bypassed, because annoying a coworker costs less than falling behind the coworker who isn’t waiting. The PR description nobody read because it was two thousand generated words. The UI rebuilt from scratch because asking design felt slower than guessing. The migration that broke another team’s build because the heads-up felt optional. These aren’t individual failures. They’re what the incentives produce.
It’s not them, it’s the incentives
Blaming individuals for these reactions doesn’t help, and it wouldn’t even be fair. They’re the outputs of a system: incentives that reward being needed, a rate of change nobody chose, and tooling that rewards solo speed.
Systems thinking does two things here. It makes the reactions legible, so you can change the incentive instead of lecturing the person. And it points at the fix: create shared systems with AI, and put knowledge into those systems, so the gains compound across the team instead of inside one person’s session.
“So you want me to write down the thing that makes me valuable?”
If judgment is what makes you valuable, wouldn’t writing it down and publishing it just be a slower way of being replaced?
No, and the reason is the line between what can be written down and what can’t. What you can publish is the settled part of your judgment: the rules you’ve already decided, the patterns you’ve already learned, the “always check X on Y surfaces” you’ve said a hundred times. That’s judgment that has finished becoming knowledge. Holding onto it does nothing except make you a queue.
What you can’t publish is the part that produced those rules in the first place. Recognizing that this case is the one the rule doesn’t fit. Noticing the question no one in the room has asked. Reading which stakeholder needs to hear it first, and how. None of that can be written down ahead of time, because none of it is a rule yet. It’s the capacity to make the next rule, and it stays valuable no matter what the tooling does, how the org changes, or what the problems turn into. What you publish is a snapshot of your judgment. You’re the thing that updates it.
Publishing the snapshot doesn’t shrink that. It gives it reach. Put the settled part of your judgment in a form an agent reads on every task. A wiki page humans read sometimes is documentation. Judgment in a form an agent reads every time is you, present in work you never saw. Handoffs smooth out because the people on either side already understand each other, and the conversations that remain are the ones that needed the unwritten part of you anyway.
That is what I want from this transformation: better collaboration, not everyone isolated and talking to each other through agents. Concretely:
- Engineers publish what a surface is like to build: its states, who reaches it, what the backend can’t do. A designer starts from those constraints instead of hearing them in review.
- Designers publish the design system’s judgment: form states, which component fits which case, what “on brand” means where nobody designed. An engineer considers what a designer would have, before the designer sees it.
- Product publishes the why: the metric a surface serves, the audiences it reaches, what it must never break. An engineer scoping a change knows the stakes before the first line of code.
- QA publishes what “tested” means for each surface: the regression risks, the edge cases that have bitten before. A risky change arrives with the right coverage instead of waiting for QA to ask.
None of this eliminates collaboration. It answers the questions that used to consume the first half of the meeting, so the meeting can be about the thing only the people in it can decide.
To be clear about what “shared systems” means, because it isn’t one artifact: it’s tools, commands, deterministic steps, and agent-readable guidance, connected to the systems where the real data lives, built on single sources of truth for everything that matters, packaged so teams can install and share it, with a hierarchy so a team’s rules sit inside the org’s. It’s closer to an operating model for how the organization works than to a document. Nobody has it fully figured out, me included. Later posts get into the parts.
“Be in rooms you’re not in”
Publishing your expertise puts your judgment in more rooms and more conversations than you could attend. We don’t need to design away from humans and toward a world of agents. We need to keep judgment at the front and accept that it won’t always be applied in person. The tooling can be an extension of it. AI didn’t remove the constraint on good work; it moved it from the labor of producing things to access to the judgment that makes them right. Publishing is how you put yours where the constraint now lives.