The Art of Unattachment
Disposable Tooling in an Age of Software Abundance
You are on an adventure through wilderness, searching for answers. You reach a river. You need to cross it. You build a raft. It takes skill and care. You cross. What do you do with the raft? With the tool you made and used to move forward?
There is a Buddhist teaching that uses this parable to talk about not clinging to the very thing that freed you. It applies with unexpected precision to something happening right now in software engineering. You build a tool during production. It solves your problem brilliantly. And then you carry it with you, maintaining it, extending it, defending its existence, long after the river is behind you. The raft becomes baggage.
In the age of AI-assisted development, we can build rafts in an afternoon. That changes the value proposition. Not just whether we should keep them, but how many we should be building in the first place.
The tools between the tools
I am not talking about your stack, your framework, your CMS, the main deliverables you share with the world. Those are the map and the boots. I am talking about the custom tools you build during production to solve problems that only exist within that production.
Every serious project generates them. The parameter-based test harness you build to isolate a motion system and hone its feel. The visual explorer you spin up to audition generative audio patterns or design systems. The CLI that batch-processes a hundred SVGs through a specific transformation pipeline.
These are not the product. They are the tools you build to build the product. And they are some of the most valuable work on any project, not because of what they are, but because of what they reveal.
Think of a good production tool as a torch in the half-light. It takes you into the problem space and shows you things you would never have discovered without it. The test harness does not just let you tweak timing values faster; it lets you see relationships between weight, rhythm, and context that are invisible in the production codebase. The audio explorer does not just save time; it trains your ear in ways that change what you reach for next.
You explore by its light, make discoveries you could not have planned for, and arrive somewhere you did not expect. That is where the real work happens.
Build more of them
When building a custom tool used to take days or weeks, I had to ration and justify them. I only built a harness when the problem absolutely demanded it. Everything else I worked out by squinting at the production codebase, tweaking values by hand, making do.
That rationing made sense then. Tools were expensive to make, rarely accounted for in estimates, and not part of deliverables. It does not make sense now.
AI-assisted development has collapsed the cost of bespoke tooling so dramatically that there is no longer any excuse not to be building these things for more and more aspects of production. Not just for the hard problems. For the medium problems. For the “I could probably figure this out by eye but a tool would show me something I cannot see yet” problems.
Tuning by touch
Aside from working as torches to discover new territory, these tools are also tuning instruments.
Much of what we build now involves non-deterministic systems, generative processes, and behaviours that cannot be specified in advance. You cannot write a rule that says “this animation should feel right.” You cannot define in a config file where the guardrails of a design system should sit across every possible context. These are things you have to feel your way toward, and the only way to develop that feel is to build something that lets you dial parameters, run things in loops or batch variants, and watch what happens.
The test harness becomes a calibration instrument. You set parameters, move sliders, watch the system respond. You start to sense where the sweet spot lives, where the boundaries should sit, where things break down and where they sing. You are developing a physical intuition for the problem space.
This need intensifies dramatically in spatial computing. When you are building for Apple Vision Pro or any immersive platform, you are designing for presence, depth, gaze, gesture, and intent. You are working at world scale, where a misplaced element is not a layout bug but a break in the felt reality of the experience. A creature that reacts to your hand movements needs to feel alive, and “alive” is not a value you can look up. A story that unfolds as you move through a space needs to feel woven, not triggered. These are systems where non-deterministic behaviour is not a side effect but the entire point, and they demand orders of magnitude more experimentation than flat-screen work.
You need a harness to tune how a procedural animation responds to gaze at different distances. You need a tool to feel the difference between two approaches to spatial audio falloff. You need something that lets you stress-test how a reactive system handles the unpredictable overlap of hand tracking, head position, and speech input at 90Hz. Each of these is a river. Each one demands its own raft. And none of them will be the same river twice.
The calibration you develop through this process crosses mediums. The feel for weight and rhythm in a motion system informs how you approach typography. The sense of boundary you build from stress-testing one layout system travels with you to the next, even if the tech stack is completely different. The spatial intuition you develop tuning a creature’s response to gesture changes how you think about interaction everywhere. The tool is disposable. The calibration is not.
This is how style guides get written that actually hold - not by theorising about rules in the abstract, but by building instruments that let you find the edges, then encoding what you discovered. The tool is how you externalise taste long enough to examine it.
Why we keep the raft
If the tool served its purpose, why hold on? The reasons are mostly emotional, dressed up as practical. We imagine future utility. “We might need this again.” But the next river will be a different width and current. Rebuilding with fresh eyes will usually be faster than adapting the old one, and the rebuilding itself will teach you something.
We confuse the tool with the knowledge. The harness taught you something essential about how your system behaves. So you keep it, as if the knowledge lives in the code and not in you. It does not. You are the vessel. The tool was the process.
The adventurer who carries the raft overland does not just move slower. They see the landscape differently. Every route is evaluated against “can I carry the raft through here?” rather than “where do I actually need to go?” The raft constrains the journey. The tool constrains the thinking.
Building for disposal
There is a craft to building things you intend to throw away.
When you build to keep, you optimise for maintainability - clean abstractions, comprehensive tests, separation of concerns. When you build to dispose, you optimise for immediacy. How fast can this give me real feedback? How directly does it connect my input to the thing I need to understand?
Hard-coded values instead of configuration files. A single file instead of a careful directory structure. Parameters exposed as sliders rather than buried in documentation. These are not shortcuts born of laziness. They are design decisions born of clarity about what this tool is for, and what it is not for.
If every tool you build carries the weight of permanence, you will build fewer of them. You will ration your torches, explore less territory, and miss what the half-light would have shown you. But if you know the tool is temporary, the cost of building it drops to almost nothing. You build, you learn, you move on. The pace of exploration accelerates. Your velocity increases. And in a commercial context, where time and cost give you competitive advantage, you cross the finishing line first - should you be in a race.
The goal is a practice where building a bespoke tool for a specific production question is as natural and unremarkable as opening a browser tab. You do it reflexively, because you know it will show you something, and you close it without ceremony when it has.
This is an attitude, not a doctrine. If you really cannot bring yourself to delete something, set it aside, archive it, stick it in a folder you never open. The point is not that the file must cease to exist. The point is that it must cease to exert gravity on your next decision. And if you want scaffolding for the process itself - a lightweight template for parameter UI, a component library you like for quick harnesses - that is fine too. You can just as easily instruct AI what component libraries to use and have it style to your design system on the fly. The meta-tooling can be as disposable as the tools themselves.
The practitioner, not the toolkit
The deeper shift is about where you locate your value.
If your value is in the tools you have accumulated, then throwing them away is threatening. If your value is in your ability to look at a problem and know what tool it demands, the throwing away is irrelevant. The skill is in the building, not the built.
AI has dropped the barrier to creating custom production tooling so dramatically that the differentiator is no longer “can you build it” but “do you know what to build.” Taste, problem-reading, the instinct to reach for a torch when others would squint or rush to answers that stay in the expected and mundane. The feel for where guardrails should sit in a system you have never worked with before, because you have calibrated that sense across a dozen disposable instruments in a dozen other contexts. These matter now. The tools are just how they are expressed, temporarily, in service of the work.
There is something else happening here that I do not want to leave unsaid. AI is not just changing what experienced practitioners can build. It is changing who gets to build at all.
I have watched account managers and strategists - the people closest to the client problem, closest to the intent behind the brief - spend years unable to prototype the ideas they understood better than anyone else in the room. They had to hand the work over to a tech team and hope something of the original instinct survived the translation. That dependency is breaking. The barrier to building tooling is no longer who writes code best. It is who understands the problem well, knows how to work with AI, and is curious enough to move out of their historic comfort zone.
I am genuinely excited about these people. Not because they will replace developers - they will not ( though they may become one ) - but because they will produce work that could not exist otherwise. Work that carries client intent intact, because the person who understood that intent was the same person who built the thing. Or better still, work produced by cross-functional teams finally able to gather around the hearth fire of code and tell new stories together, unattached to the old divisions of who gets to make things and who only gets to describe them.
That is the real unattachment this moment invites. Not just from the tools we build, but from the assumption that tool-building belongs to a specific type of person or department.
Paddy Keane is the founder of Sinjin Studio, an independent creative technology practice specialising in AI-native web development, spatial computing, and MCP architectures.