For decades we worked under an implicit model we could call the SAP model: there is a "correct" way to do things, someone has encoded it into a tool, and your job is to adapt your processes to that mould. The software dictated the flow and you adjusted. We paid for consultancy by the kilo so our reality would fit someone else's diagram.
That contract is breaking. Today, with AI, I can generate in hours a tool that adapts to my way of thinking instead of forcing me to think in its way. And the interesting thing is not the speed: it is the change of direction. The tool is no longer the destination one conforms to, but mouldable matter orbiting around how one already works.
A colleague recently found an open-source utility he liked. Instead of adopting it, he remade it in minutes so it fit his personal flow. It was not the same tool in another colour: it was something new that only made sense for him. In parallel, I needed a layer of external memory for working with agents, and instead of looking for "the best solution on the market" I built one on top of Obsidian. With each iteration it is "better"... and better here means, without ambiguity, more aligned with my particular workflow. Less universal, more mine.
So far, the good news. Now the trap. My colleague, enthusiastic about what he had built, started sharing it as "the version that will help everyone." Another friend is convinced he can sell the app he vibecoded to solve a very specific problem of his. And I myself, who am writing this critique, every time I upload a version of my memory system to GitHub I accompany it with a README that presents it less as "this is what works for me" and more as "this might work for you." Each commit makes it, paradoxically, less generic and more evangelising.
It is the old reflex. We build something that solves our use case and, in the same gesture, try to universalise it. We return to SAP through the back door, only now the one trying to impose the mould is me. And we do it even when we are convinced we are living in a different paradigm.
The uncomfortable question is why. I think there are three reflexes operating at once. One is economic: if your tool works only for you, there is no business; if it works for everyone, there is a startup. Two, a validation reflex: if others adopt what you made, it confirms that the problem was real and the solution good. Three, an older cognitive reflex: we think of tools as products (stable objects, distributable, with users) instead of as practices (situated, biographical, non-transferable gestures).
The real paradigm shift is not "now I can build my tool." That is only the condition of possibility. The shift is accepting that the perfect tool for someone else is neither bought nor downloaded: it is rewritten. What my colleague should share is not his app; it is the pattern, the reasoning, the way of thinking about the problem. What I should publish is not code ready to clone, but the underlying logic so someone else can build theirs.
The artefact does not travel well. The idea does.
In this new paradigm, tools become biographical: they carry the way their author thinks, the concrete frictions they solve, the idiosyncratic decisions taken on a Tuesday. That is exactly what makes them valuable to the person who built them and useless, as-is, to anyone else.
Sharing code still makes sense as reference, as inspiration, as a learning shortcut. But presenting it as a product to adopt betrays the nature of what we made.
I am still learning to resist the reflex. The next time I upload a version of my memory system, I would like the README to begin: "this is not for you, but it may teach you how to build yours." We will see if I manage it.