Becoming Your Own Provider

A few months ago, I started building tools that do things I used to do myself. Not to replace myself. To go further than my hands alone could take me. And at some point, I realized the real shift wasn’t in the tool — it was in me.

Building the tool that performs on your behalf means becoming your own provider. That semantic move matters.

The Tool That Extends — and Amputates

McLuhan put it with uncomfortable precision: every medium is an extension of the human body, and every extension is also an amputation. The wheel extends the foot and atrophies walking. Writing extends memory and excuses us from remembering. An AI agent that drafts my reports extends my analytical capacity — and risks atrophying my writing practice.

The double movement is real. But McLuhan doesn’t render it as a verdict. He renders it as a description. What matters is what you do with the displacement.

Stiegler goes further, and darker. In Technics and Time, he names the phenomenon: proletarianization. Externalizing your know-how into a machine means losing mastery of the gesture. The worker who can no longer do anything without his lathe. The accountant who can no longer calculate without a spreadsheet. The machine captures the knowledge, and the individual becomes the executor of their own outsourced competence.

But Stiegler also signals the exit: reclaim authorship over the design of the tool. Whoever builds the machine doesn’t suffer proletarianization — they reverse it. They become the one who knows again, because they know how it works.

That is exactly what self-tooling displaces.

The Center of Competence Shifts — It Doesn’t Disappear

When I build an agent that processes data in my place, I’m not externalizing my competence. I’m transposing it. It leaves the act of execution and takes up residence in system design. I may no longer be able to do the task by hand — but I know how the task needs to be done, what edge cases it runs into, when the tool is lying and why.

That’s a different kind of knowledge. More abstract, more architectural. Less legible on an org chart, more powerful in the actual work.

The real question, then, isn’t: does the tool replace me? It’s: does my function evolve with this displacement, or can I fulfill that function through means the organization never planned for?

Both answers are true. And they don’t cancel each other out.

Building for Yourself — Then for Everyone

There’s a third movement, less often named.

If I build a tool that performs on my behalf, and that tool is good, nothing stops me from opening it to others. I potentially become the person who builds tools for the rest of the organization. The internal craftsperson. The provider.

Mary Parker Follett, at the turn of the twentieth century, had an intuition that management theory took decades to absorb: the most durable power inside an organization isn’t power over — it’s power with. Whoever masters the fabrication of shared tools exercises no hierarchical authority. They exercise influence through design. They redraw the constraints within which everyone else works.

That’s a fundamentally different career shift from what the “AI will replace you” narrative implies. This isn’t about being supplanted by a tool. It’s about reinventing functions and the tools that fulfill them — from scratch, for tomorrow.

What “Reinventing” Actually Means

Reinventing isn’t erasing. It’s returning to the original question: what does this function actually do? What problem does it solve inside the organization? And if we designed it today, with the capabilities now available, what shape would it take?

Self-tooling forces that question. Because building a tool requires modeling the problem. And modeling the problem usually reveals that the inherited function is solving something that no longer quite exists in that form — or that it’s generating a new problem it never anticipated.

The shift in the center of competence isn’t a loss. It’s a forced move toward abstraction. Brutal sometimes. But it’s the only way to remain the author of what you do — rather than simply the executor of what you once learned to do.

Becoming your own provider means refusing to let the machine be the one who knows.