What Happens When AI Can Spin Up a Tool for Anything?

The landscape of external services is about to dramatically change.

Tools that are most accessible via API are likely to stick around, but as a dev with Claude, I can now build increasingly more personalised, more effective and more internally integrated tools than external ones can give me.

For my company, Daeda Tech, one of our most utilised but limited tools was the company site - I like to work from the cli and using their MCP was only slowing down my changes, not speeding them up. In the beginning of 2025 we used Webflow to accommodate growing our site as we made more apps and gained more users. Its CMS was simpler than keeping everything self-hosted, but as the months went on webflow’s designer MCP couldn’t implement branded components, and building with Astro was just faster, so I migrated us over this month.

Webflow’s edge - a large user base, a more tried and tested platform - is less of a selling point once Claude can access the code directly. Having our site self hosted means full control over AEO, site-wide edits, automated processes, and design elements like neo-brutalist box shadows, branded animated SVGs, React image assets via Remotion - things their tools cannot replicate.

And platform limits aren’t the only reason I’m seeing this major shift.

full context

With AI tech giant companies like Meta, OpenAI, Google etc there’s a lot of talk over an individual’s data and who controls it. With most people’s data scattered across platforms like gmail, socials etc, a new niche of entrepreneurs is forming - some with the idea of centralisation and others where the focus of consolidating data is driven by privacy. E.g. keeping data away from Meta, third parties or unknown actors.

But there’s a more immediately practical reason: the more your data lives in one place, the more context your AI has to work with. A locally integrated tool isn’t just more private - it’s faster, more aware, and more useful.

What happens when AI can spin up a tool for anything?

k-shaped path ahead

As Geoffrey Huntley talks about in his recent article Software development now costs less than the wage of a minimum wage worker, there is a fast approaching K-shaped economy.

On LinkedIn, in the HubSpot ecosystem, I’m already seeing a wave of new builders emerge: the revops power user - these people are building and scaling custom solutions for their clients that were previously out of reach, and it’s such a small group that other agencies are being left in the dust cause they can’t compete.

The K-shape predicts the automation of most professional jobs. When workflows shrink from hours of manual clicking to niche custom prompts, fewer people are needed to watch the progress and orchestrate the systems.

But competitors won’t be eliminated immediately. If someone doesn’t know a product is possible to build in one-shot, there’ll still be a market to sell to.

For high-level teams who do know, the only way to stay competitive is to niche down in domain expertise.

what are magic words

As tech advances, we see more abstractions. Programmers in the 1950s were all writing in assembly, then we abstracted up to languages like C and FORTRAN, and then all the way up to today and natural language.

Magic words are the new abstraction layer. There’s a massive difference between:

My app says RATE LIMIT error can you fix?

vs

Getting a rate limit error on prod when users click scan btn on home pg. This is sending a req to search api on X platform but hitting platform pagination limits of 100 per second. Let’s queue the reqs as they come in and throttle each call by wrapping fn in async limiter. Then lets switch to a polling scan progress bar, every 500ms, in ui so user doesn’t think app is broken

The first prompt might get you a generic fix. The second gets you a solution because you already know the domain well enough to scope the problem.

That domain knowledge is what I mean by magic words.

not a magic box

On its own, AI is not a magic box; as Dax from OpenCode said:

It cannot one shot everything.

As I see it, the only way a complex product like Final Cut Pro can be one-shotted is if someone with deep domain knowledge has already built and tested the guardrails. The magic words have to come first.

Buyers will still approach software products when building the thing themselves requires magic words they don’t have.

For example, remotion lets me generate videos, loop in ElevenLabs for voiceover, and produce marketing assets more professional than anything I’d manually make - without touching a video editor. And OpenCode’s Docker integration gives me local model inference with no external API calls and no data leaving my infra. I wouldn’t build either from scratch; the magic words for video tooling and sandboxed model runners are too far outside my daily stack right now, but because someone built those abstractions, I can use them.

Jack, my husband and co-founder, raised a useful counter-point here: he recently met someone automating AEO/SEO, but without proper tracking software you can’t get a clear view of how the agent is processing content - and you can’t optimise what you can’t see.

Because there doesn’t seem to be much agent tracking software in the wild yet, this area of work is unlikely to be one-click-done just yet.

So as of March 2026, AI cannot spin up a tool for anything via one-shot - but crafting the domain-specific guardrails will mean power users can build most things.

This systems building is where the interesting problems live and what I’m exploring next.

---

This is part of an ongoing Systems Philosophy series exploring how complex systems behave, fail, and evolve.