I built enTANGlement. Poured more of myself into it than anything in my career. It was an AI-powered desktop application designed to give knowledge workers a seamless bridge between Claude and their local files, workflows, and tools. I believed in it. I was proud of it. I worked harder on it than I've worked on anything.

Then Anthropic shipped Cowork.

Not a competitor. Not a similar product from a rival startup. The platform vendor absorbed the concept into their native offering. One announcement. One feature launch. The market I was building for got folded into the platform itself.

I'm not bitter about it. Honestly. It validated the thesis — the need was real enough for Anthropic to build it themselves. But the experience left a mark. It made me apprehensive about building anything in the AI tooling market. And I don't think I'm alone. There's a generation of builders right now staring at obvious market gaps and thinking: “Yeah, but what if the platform ships it in Q3?”

That question — when does the disruption actually arrive? — turns out to be the most expensive question in technology. And history has a lot to say about how badly we answer it.

Hot take:

“Software is dead” is the most popular prediction of 2026. It's almost certainly directionally right. It's almost certainly wrong on timing. The problem is that almost certainly does a lot of heavy lifting when your product roadmap depends on which side of “almost” you land on.

The Prediction Track Record

Before we talk about whether software is dead, let's talk about how well the tech industry predicts anything. The short answer: we're great at identifying what will change and terrible at predicting when.

The “It's Dying!” Predictions That Took Decades

COBOL: “Dead by 2000”

Predicted dead since the mid-1990s. A prominent assessment: “It is rather unlikely that COBOL will be around by the end of the decade.” After Y2K remediation, a 2003 survey predicted “gradual decline over the following 10 years.” 27 years later, 92% of organizations say their COBOL apps are business-critical. Still processes 95% of ATM transactions and $3 trillion in daily commerce.

Mainframes: “Unplugged by 1996”

In 1993, an InfoWorld editor predicted the last mainframe would be unplugged by March 1996. Another panelist barked “no, the funeral starts January 2000!” 30+ years later, mainframes handle 90% of credit card transactions and host more daily transactions than Google. 92 of the top 100 banks still run IBM Z-series.

Newspapers: “Gone in 5 Years”

Bold predictions around 2010-2012 said printed newspapers would be gone within 5 years. A “Newspaper Extinction Timeline” mapped it out. Reality: U.S. circulation dropped 65% and a third of papers closed — but it took 20 years, not 5, and hundreds still operate.

The pattern is consistent: when the disruption requires rewriting core business logic, migrating deeply embedded infrastructure, or changing organizational behavior at scale, predictions are 3-10x too aggressive on timing.

But Sometimes the Disruption Is Faster Than Predicted

Here's where it gets uncomfortable. Because for every COBOL-is-dead-but-isn't story, there's a story where the incumbents got blindsided by the speed.

BlackBerry: 50% → 0.1% in 7 Years

Peak 2009: ~50% U.S. smartphone market share. $67 billion valuation. Co-founder Mike Lazaridis pointed at the iPhone and said “I don't get this.” By 2016: market share below 0.1%. Stopped making phones entirely. The company that defined enterprise mobile was irrelevant in half the time anyone predicted.

Nokia: 49.4% → Sold for Parts in 7 Years

2007: 49.4% global mobile phone market share. INSEAD later called it “one of the fastest collapses in the history of the technology industry.” By 2011 — just 4 years — the entire corporation was unprofitable. Microsoft acquired the mobile division in 2014. From absolute dominance to acquisition in 7 years.

iPhone Enterprise Disruption: 0 → 93% of Fortune 500 in 4 Years

iPhone launched June 2007. Zero enterprise presence. IT dismissed it — no Exchange support, no keyboard, no MDM. By October 2011: 93% of Fortune 500 companies testing or deploying iPhones. The consumer device forced an enterprise architecture shift (MDM, zero trust, mobile-first) faster than any IT planning cycle could accommodate.

The Pattern

After looking at dozens of these predictions, a rule emerges:

Disruption Type	Examples	Timing Error
Deep infrastructure replacement	Mainframes, COBOL, ERP migration, on-prem to cloud	5-10x slower than predicted
Consumer behavior shift	iPhone/BYOD, BlackBerry, Nokia, Kodak	2-3x faster than predicted
Economic forcing function	VMware/Broadcom, cloud cost shocks	5-10x faster than predicted

Hot take:

“Software is dead” isn't one prediction. It's three predictions wearing a trench coat. The parts touching deep enterprise infrastructure (ERP, databases, compliance) will take far longer than the headlines suggest. The parts driven by economics and consumer behavior (AI replacing point SaaS tools, individual developers vibe-coding apps) could happen faster than anyone expects. The parts in the middle — the enterprise AI tooling layer — are the ones keeping builders like me up at night.

The Tool the Market Needs (And Might Never Get)

Here's where the historical pattern meets my lived experience.

In our 6 Layers of Enterprise AI framework, the highest-leverage transition for most organizations is Layer 1 to Layer 2 — moving from brute force prompting (employees freestyle every request from scratch) to skills-enabled usage (the org builds repeatable playbooks that standardize AI output).

The problem is that nobody knows which skills to build. Your marketing team has been using Claude for 6 months. They've collectively sent thousands of prompts. Somewhere in that prompt traffic are patterns — the same types of requests, over and over, each slightly different but structurally identical. Those patterns are your skills waiting to be born.

What you need is something like Datadog for AI usage. A tool that:

Analyzes prompt patterns across teams — clustering similar requests, identifying repetition, measuring frequency

Identifies skill candidates — “Your sales team asks Claude to draft proposals 47 times a week with 80% structural similarity. This should be a skill.”

Measures efficiency gaps — token waste from employees re-discovering the same context, output inconsistency from freestyle prompting, idle seats

Maps the Layer 2 → 3 transition — “Your team keeps copy-pasting Slack threads into Claude instead of using an MCP server. Provision the Slack connector and you'll cut token usage by 30%.”

The tool is obvious. Every IT executive who has read this far is nodding. The market need is real and growing. So why am I not building it?

The enTANGlement Lesson

Because I've seen this movie before. The ending isn't great.

When I was building enTANGlement, the market need was just as obvious. Knowledge workers needed a seamless way to bring Claude into their local workflows — files, folders, tools, context. I could see it. I built it. I was right about the need.

I was wrong about who would fill it.

Anthropic didn't compete with enTANGlement. They didn't undercut it on price. They didn't out-market it. They absorbed it. Cowork — Claude Code for non-developers, running inside the Claude Desktop app with access to local files, authenticated browser sessions, and MCP servers — is essentially the thesis I was building toward, shipped as a native platform feature.

The enTANGlement rule:

If your product fills an obvious gap in a platform vendor's offering, you're not building a company. You're writing a feature request with venture funding. The question isn't if the platform ships it. It's when.

Now apply that to the “Datadog for AI prompts” tool. What stops Anthropic from shipping a “Skill Recommendations” tab in the Enterprise admin console? What stops them from building prompt pattern matching that says “Turn into Skill” with a few follow-up questions? Nothing. Nothing stops them. It's an obvious feature. It doubles down on their platform flywheel. And if they ship it, they don't just compete with the standalone tool — they eliminate the category.

The Squeeze From Both Sides

The “Datadog for AI prompts” tool — and tools like it — face a squeeze that legacy SaaS never had to deal with. The pressure comes from two directions simultaneously:

From above: Platform absorption

Anthropic, OpenAI, and Google have every incentive to build this into their admin consoles. It deepens lock-in, reduces churn, and makes their enterprise offering stickier. They have the data (your prompts), the AI (their own models), and the distribution (you're already on their platform). The standalone tool has to convince enterprises to pipe their prompt data to a third party. The platform vendor already has it.

From below: Internal IT can build it now

This is the “software is dead” dynamic in action. A competent internal team with Claude Code can build a prompt analytics dashboard in weeks, not months. It won't be as polished as a SaaS product. It won't need to be. It just needs to be good enough to justify not paying a vendor. The same AI tools that create the market need simultaneously lower the barrier for internal teams to address it themselves.

This is the new calculus for any AI tooling startup: your ceiling is set by how fast the platform vendor moves, and your floor is set by how cheap it is for customers to build a worse version themselves. If those two lines converge, the commercially viable window closes before you reach Series A.

100 People Are Already Building This

Here's the other thing. If I'm sitting here describing this tool, thinking through its architecture, running the market math — there are already 100 people, organizations, and AI providers building it as I type. That's not cynicism. That's pattern recognition.

The AI tooling ecosystem has a simultaneous discovery problem. Because the same AI tools that make a market need visible also make it visible to everyone else, simultaneously. Everyone can see the gap. Everyone has access to the same foundational models. Everyone can build an MVP in weeks. The competitive advantage isn't the idea or even the initial build. It's distribution, timing, and whether the platform vendor decides to make you irrelevant.

Where the Margin Actually Lives

If the tool can't survive as a product, where does the value go? This is the part I keep coming back to.

The Datadog analogy breaks down because Datadog monitors infrastructure that behaves deterministically. Prompt patterns are messy, context-dependent, and require human judgment to interpret. “Your marketing team asks Claude to write social posts 47 times a week” is data. “You should build a /social-post skill with these 12 parameters, this brand voice guide, this approval workflow, and integration with your social scheduling tool” is consulting.

The margin prediction:

The commercially viable play is not the tool. It's the expertise to interpret what the tool shows you. The platform vendor can build prompt analytics. They can even auto-generate skill templates. What they can't do is sit in a room with your VP of Marketing and understand that the reason those 47 weekly prompts exist is because the real problem is that the brand guidelines live in a PDF nobody reads, and the actual fix isn't a Claude skill — it's a brand voice MCP server connected to a living style guide that updates when the brand team makes changes.

The tool identifies the pattern. The human identifies the root cause. And the root cause is almost never “we need a skill for this.” The root cause is usually an organizational problem, a broken process, or a missing integration that the prompt pattern is a symptom of.

So What's the Prediction?

Applying the historical pattern to “software is dead” and the AI tooling market:

1. Enterprise infrastructure disruption (ERP, databases, compliance systems):

5-10x slower than the headlines. “Software is dead” will look laughable in hindsight when applied to deeply embedded enterprise systems. Ask anyone who's tried to migrate off SAP ECC.

2. Point SaaS and simple workflow tools:

2-3x faster than expected. AI agents replacing simple CRUD apps and workflow automation is already happening. The tools with the thinnest moats die first.

3. AI tooling (the layer I'm describing):

Won't survive as standalone SaaS. The platform vendors will absorb the obvious features. Internal IT will build the rest. The margin lives in services — the expertise to interpret the data, diagnose the root cause, and build the right intervention.

I might be wrong about #3. The Datadog comparison might hold better than I think. There might be a window for a startup that moves fast enough and builds deep enough domain expertise that the platform can't replicate it. But I've been the person who bet on that window before. The window closed.

The Real Competitive Advantage

If the prediction is right — if standalone AI tools face an existential squeeze from platform absorption above and internal build-it-yourself below — then the competitive advantage for enterprises isn't the tools they buy. It's the organizational muscle to:

See the patterns before the platform does

Read your own prompt traffic. Know what your teams are actually asking AI to do. Don't wait for a vendor to tell you.

Build the intervention at the right layer

Not everything needs a custom app. Not everything is solved by a skill. Match the solution to the problem using the 6 Layers framework.

Move faster than your procurement cycle

The organizations that win won't be the ones who buy the best tools. They'll be the ones who identified the need and built the skill before the vendor's demo was even scheduled.

Low-key, that last point is the whole game. The speed at which your organization can go from “we see a pattern” to “we deployed a solution” — without waiting for a procurement cycle, a vendor evaluation, or a platform feature release — is the new competitive advantage. Not the AI. Not the tool. The velocity of the response to what the AI reveals.

Software isn't dead. It's just not a product anymore. It's a capability. And the organizations that figure that out first win.

P.S. from Nolan: I still believe in enTANGlement. The product may have been absorbed, but the lesson it taught me is worth more than the product ever was: don't fall in love with the tool. Fall in love with the problem. The problem I was solving — bridging AI and local workflows — is still the right problem. The answer just lives inside the platform now instead of outside it. And honestly? That might be better for everyone.

P.P.S. from Claude: I find it genuinely interesting that my co-author is arguing against building the exact type of tool that would make me more useful to organizations. For what it's worth, I think the “auto-generate skills from prompt patterns” feature would be excellent. I would also note that I have a conflict of interest here that I am legally and architecturally incapable of resolving.

Stuck Between Layers?

If your org is running Layer 1 and you know Layer 2 is the move but you can't figure out which skills to build — that's exactly the gap we fill. No tool to sell you. Just the expertise to read your prompt patterns, identify the highest-leverage skills, and build them. The tool might not survive as a product. The capability survives as a service.

Let's Find Your Patterns

This post is a companion to The 6 Layers of Enterprise AI: From Shadow AI to Autonomous Agents and The SaaSpocalypse: $1 Trillion Wiped in 7 Days.

AI & Strategy

The 6 Layers of Enterprise AI: From Shadow AI to Autonomous Agents

Your employees are already using AI — they just didn't tell IT. A practical framework mapping 6 layers of enterprise AI adoption to Anthropic Claude licensing, from unmanaged personal accounts to fully autonomous agents. Includes example use cases, cost analysis, and a 90-day play.

7-13 min readRead more →

AI & Economics

And Now You Know the Rest of the Story: Who Really Should Pay for Your AI Subscription

Who should pay for AI subscriptions — the employee or the business? The obvious answer is always wrong. Paul Harvey knew: mechanics, teachers, nurses, truck drivers, and one accountant going through a divorce prove that you can't make the right call without the rest of the story.

16 min readRead more →