“Right now it’s 40-60. Forty percent of the time it’s tweaking the tools, and sixty percent of the time it’s working. My aim when I use AI is to amplify what I’m doing and to offload the work, rather than to generate more work — so that I work on the tool that’s actually allowing me to do the work.” — Jay Drobez

Session context: 2026-07-23_Mastermind — Jay spent several minutes searching for the right word for what he was feeling about his stack. He landed on it mid-sentence: “I was a bit frustrated — there we go, that’s the right word.”

Core Idea

Jay is a neuroscientist and clinician who came to AI to amplify his work. He now spends 40% of his working time maintaining the thing that lets him do the work. He described his stack honestly: he started with a model and a few markdown files, and it grew into an MCP server, an annotation loop, integrations, and a topology diagram he had to draw to keep track of how it all connected. He got there one reasonable decision at a time.

That number deserves to be said out loud in a room full of people who build systems, because the enthusiasm in this community makes it easy to miss. The tool tax is invisible when you enjoy paying it. Every hour of tinkering feels like investment; most of it is, some of it isn’t, and nothing in the experience distinguishes the two. Jay caught it because his actual work — clinical and scientific — competes for the same hours and pushes back.

Two things make it worse than ordinary tooling overhead.

The ground moves. A conventional tool you sharpen stays sharp. Here, models get replaced, quantized, or retired, guardrails shift, and behaviour you tuned for last month has to be re-tuned. Maintenance isn’t a one-time setup cost you amortize; it’s a recurring subscription paid in your attention.

Some of the work is pre-obsolete. Jay named the diminishing return directly: “all of the stuff that we’re probably working on right now will, in one way, shape, or form, be probably integrated in the next set of models, which will make this whole ordeal redundant.” Some of what you build today is scaffolding for a gap that closes on its own.

The discipline Jay proposed against it is the useful part, and it is not “build less.” It is a question: what’s the one thing that moves the needle for this process? Isolate that, double down on it, and stop adding tools, skills, and agents around the edges. Most of the 40% goes to the edges — the integration that saves four minutes, the agent that adds a check you’d have caught anyway.

The room’s honest close was that this is where we are. “We’re in this pre- era, where you had to sharpen your axes.” Enthusiasts absorb the tax without noticing. Clients paying you for outcomes will not.

Practical Application

Track the split for one week. Two columns, rough tallies: doing the work versus working on the tools. Don’t optimize while you measure, just look at the ratio at the end. If tinkering is over 25%, take your most-loaded workflow and answer Jay’s question in one sentence — what is the single thing that moves the needle here? Everything in that workflow that isn’t that, or directly serving that, gets frozen for a month. Not deleted. Frozen. If you don’t miss it, it was tax.

Evolution Across Sessions

Establishes the baseline for tooling overhead as a named, measurable cost rather than a mood. Prior insights in this vault treat system-building as unambiguously good — Insight - Skill Scoping — Not Every Prompt Wants to Be a Skill, and Not Every Skill Wants to Grow gets closest to the counterweight, but frames it as design discipline rather than time economics. The new development is a number from a working practitioner (40/60), the two reasons this tax behaves worse than normal tooling overhead (a moving substrate and pre-obsolete work), and a triage question to spend against it. Future sessions should test whether the ratio moves as stacks mature, and whether the same members report the same number six months on.