Over the past few weeks, Anthropic has claimed employees are relying on Claude for most of their day-to-day work, as AI becomes their “internal operating system”.

This has raised a potent question for engineering leaders: Should teams construct their own AI-enabled operating layer around internal tools, workflows and knowledge? Or should they rely on emerging vendor platforms to provide that structure for them?

A Question of Confidence

A shift from traditional platforms to LLMs could reshape the way that software is built today, but engineering teams should approach any decisions they make with caution.

When we talk about operating systems in an enterprise context, we’re talking about something stable, standardized, and predictable – like the SaaS platforms most enterprises have relied on for the past decade or so. That’s what gives people confidence to run critical workloads on top of it.

Right now, AI is a powerful execution layer, but it must be housed in a system surrounded by guardrails that make its execution trustworthy and deterministic.

While Anthropic might be able to use AI to build a stable operating system of sorts, it’s running the best possible conditions for that to succeed: a clean environment, tight toolchain, skilled engineers, and not a lot of legacy technology.

This isn’t the reality for most enterprises, especially in regulated industries like financial services. They have fragmented data, rigid processes, and years of accumulated complexity. Drop AI in as an “execution layer” and you hit friction fast.

Probabilistic systems can take action and pull in data with reasonable confidence, but there are hard stops like evidence collection, separation of duties, and audit trails. Those are not optional, and they cannot be discounted simply because the model is able to run faster than those it’s built to serve.

Stability Versus Speed

Many enterprises are seeing that AI is incredibly powerful, but it’s still dynamic. It doesn’t yet meet the bar for consistency, auditability, and control that engineering teams at large enterprises require.

Speed doesn’t override control, so engineering leaders shouldn’t be weakening governance processes when embedding AI into their workflows and execution layers. However, they also can’t stop moving or be a blocker to progress.

They have to find a way to automate their processes from end-to-end to keep pace with their peers and competitors. If you’re still opening tickets or relying on human engineers to enforce manual checkpoints, you’re giving back all the velocity AI just created.

Building Consistency

Engineering leaders shouldn’t cancel their licences for all SaaS platforms and solutions just yet. But they should be shifting to ensure they can make the most of AI tools in their current environments.

That means creating shared templates, defined paths to production, and guardrails that guide how work gets done. You have to make it easy to do the right thing and hard to do the wrong thing, especially when it comes to change.

AI as an internal operating system is only sustainable if it runs within guarded execution paths and controlled production workflows. That’s how engineering leaders can get real velocity without compromising the requirements that actually matter.

What do you think? Has your organisation started using AI to build or enhance its internal operating systems? And where do you stand on the build versus buy debate?