Post: Why Most Companies Will Get Make Skills Wrong (And How to Be One That Doesn’t)
Every major technology shift produces the same pattern. Early adopters race in. Most treat the new tool as the destination. A small group treats it as a faster path to the work that actually matters. The first group declares victory too soon. The second group compounds the advantage.
Make Skills for Claude is following that exact pattern right now. I’ve written a detailed field report on what we found after running Make Skills in production — the seeding process, how it handles HTTP modules, the self-diagnosing error handler we built. The tool is genuinely impressive. But impressive tools get misused all the time, and I’m already seeing the misuse pattern form.
Here’s my thesis: most companies will treat Make Skills as a build accelerator and stop there. That’s not wrong — it is a build accelerator. But build acceleration is the least important thing it does. The companies that win with this technology will use it to compress the build step so completely that they can redirect almost all of their automation investment into the two phases where value actually lives: discovery and production support.
The Workshop Metaphor
Think about a master carpenter who just got a shop full of CNC machines. The machines cut faster. They cut more precisely. They eliminate a category of skilled manual work.
But the master carpenter still has to design the furniture. Still has to know what the client actually needs. Still has to maintain the machines, troubleshoot when a cut goes wrong, and adapt when the wood doesn’t behave as expected.
The CNC machines didn’t replace the craft. They compressed one stage of it. The carpenter who understands that redirects the saved time into better design and better client work. The carpenter who doesn’t understand that just runs the machines faster and charges less.
Make Skills is a CNC machine. Most companies are going to run it faster and charge less.
Why Is the Mistake So Easy to Make?
Because the build step is the most visible part of automation work. It’s where the scenario editor opens, where modules get connected, where the logic takes shape on screen. It looks like the work because it looks like work.
Discovery — figuring out what to automate, in what order, against what business outcome — is invisible. It happens in conversations, in process audits, in judgment calls about what’s worth automating at all. There’s no screenshot for it.
Production support is reactive and intermittent. Errors fire at inconvenient times. Fixes are often small. It doesn’t feel like high-value work even when it absolutely is.
So when Make Skills compresses the build step by 60 to 80 percent, most leaders look at that and think: great, we can build more automations faster. They’re not wrong. But they’re answering the wrong question. The right question is: now that build is cheap, where should we invest the time we saved?
Three Claims I’ll Stand Behind
Claim 1: Build was never the bottleneck. In almost every automation project I’ve run, the delay wasn’t in the scenario editor. It was upstream — unclear requirements, undocumented processes, stakeholders who hadn’t aligned on what success looked like. Make Skills doesn’t touch any of that. If you skip discovery and go straight to build, you now just build the wrong thing faster.
Claim 2: Production support is where automations succeed or fail long-term. An automation that runs flawlessly in testing will hit something unexpected in production within weeks. A data format changes. An API endpoint moves. A business rule gets updated and nobody told the automation. If you don’t have structured support — what we call the post-commoditization model where OpsCare carries more weight than ever — your automations degrade silently. Most companies have no answer for this.
Claim 3: The companies treating Make Skills as a cost-reduction tool will underinvest in the wrong phase. I’ve already had this conversation with a prospective client: “If AI can build the scenario, why do I need a consultant?” The answer is that the scenario is the easy part. Knowing which process to automate, in what sequence, connected to which systems, with what error handling, monitored by whom — that’s the work. Skipping discovery doesn’t save money. It moves the cost to rework.
What About the Counterargument?
Fair pushback: some companies genuinely do have the discovery work done. They know their processes. They have documented requirements. They just needed someone to build the scenarios. For those companies, Make Skills is a clean efficiency gain with no hidden cost.
I’ll grant that. For mature automation programs with strong process documentation and dedicated production support, Make Skills is pure upside.
But in my experience, that describes a small minority of the companies looking at this technology right now. Most are earlier in the journey. They have some automations running, a backlog of ideas, and no real system for deciding what to build next or for maintaining what’s already live. Dropping Make Skills into that environment without addressing those gaps doesn’t fix the gaps. It accelerates into them.
The counterargument is real — it just doesn’t apply to most of the audience reaching for this tool right now.
What Does Good Adoption Actually Look Like?
Here’s what I’d tell any company evaluating Make Skills seriously:
- Audit your discovery process first. If you don’t have a structured way to evaluate what to automate and in what order, Make Skills will make your backlog chaos faster. Fix the intake process before you accelerate build. Our OpsMap™ process exists specifically to answer this question before a single scenario gets built.
- Seed it properly before you trust it. We had to seed our MCP with existing Make scenarios so it understood the JSON structure we use. Once seeded, it pulls in credentials and module patterns correctly. Skip that step and you’ll get structurally valid scenarios that don’t match your environment.
- Use it for HTTP modules first. This is where Make Skills earns its keep immediately — formulating API calls for tools without native Make modules. The JSON script and module internals come out correctly the first time. That’s hours of work compressed to minutes.
- Be specific. Seriously specific. It builds exactly what you describe. Vague prompts produce vague scenarios. If you haven’t done the discovery work to know precisely what you want, the output will reflect that.
- Build your production support layer before you scale build. The self-diagnosing error handler we built — where the MCP reads a broken scenario, identifies the failure point, and emails a technician with the analysis — took research time from 20 to 30 minutes per error down to a glance at an email. That’s the high-value use. Not just building faster, but maintaining better.
- Recognize what Make Skills doesn’t do. It doesn’t tell you what to build. It doesn’t prioritize your backlog. It doesn’t monitor production health. It doesn’t know your business. Those are still human jobs — or at minimum, they require human judgment informed by real operational context. A partner with real AI production experience will know the difference between what the tool can do and what it can’t.
What Does This Mean for Your Automation Program?
- If you’re early in your automation journey, invest in discovery before you invest in build speed.
- If you’re mid-program, use Make Skills to accelerate build and reinvest the savings into production support.
- If you’re mature, Make Skills is a genuine efficiency gain — use it to expand scope, not just to cut cost.
- In every case, don’t let the excitement of fast builds distract from the question that matters: are you building the right things?
The Honest Bottom Line
Make Skills is the most significant productivity shift I’ve seen in Make-based automation work in years. It’s real, it works, and the production results we’ve documented aren’t marginal — they’re significant.
But I’ve also seen enough technology cycles to know that the tool isn’t the strategy. The companies that get this right will use Make Skills to free up time for the higher-order work: better discovery, stronger production support, smarter sequencing of what gets built. The companies that get it wrong will build more automations faster and wonder why the ROI didn’t follow.
Be one of the ones that gets it right. The gap between those two groups is about to get a lot wider.
Keep Automating,
Jeff Arnold
Founder & CEO, 4Spot Consulting — Make Gold Partner
Information in this article is deemed to be accurate at time of publishing. 4Spot Consulting reviews and updates content periodically as best practices evolve.
