Are cloud vendors the true entities under threat from AI?

Let’s start by being specific. I’m talking about cloud software vendors, not software vendors in general. So this has nothing to do with the recent recoding and release of the entire Adobe suite. That’s a different conversation.

Most cloud software vendors offer a function that is already available within the major cloud services but which is awkward or difficult to configure, non-obvious, or has various pitfalls. Essentially, they provide a framework for your cloud, usually for a specific function.

As we all know, frameworks are designed to offer simplicity and ease of use, but to do that, they often have to roll up or hide a lot of the features you might actually want or display them in a slightly different way.

This is one of the core reasons why frameworks often start out seeming like a brilliant idea but end up a burden. Say a problem seems really hard to solve, and a company comes along and says, “Yes, we’ll do this for you. It’ll make it easier.”

However, as a system matures,   you add features and gain complexity, and the overlayed framework or cloud vendor’s system can actually become harder to update, maintain and pay for, than if you’d simply done it directly using the original cloud services.

And I think this is where generative AI coding tools are starting to change things.

AI can now remove a lot of this particular problem. It can provide the initial ease of implementation that frameworks and cloud vendors offer, without necessarily being any harder to edit after implementation.

So you could start off with Azure or AWS, sit down with Claude or whatever AI tool you prefer, and get it to write you a function or feature. It will go off and do that, producing nicely documented code that does what you want.

However, one of the core things people don’t like about AI written code is that, once it had been produced, very rarely would humans go through and work out exactly how it had been done. This made it potentially harder to maintain.

But that’s not really any different from using a vendor’s product or a big framework. You put it in, it does a very fast job initially, but going back and changing anything can be an absolute devil.

However, AI has not only provided that first fast implementation that a vendor or framework would offer, but it also writes a lot of its own documentation. Anyone who’s read one of those monstrous README files that AI code generation tools produce will know what I mean.

More importantly, AI is actually quite good at going back, reviewing what was done previously and making amendments without screwing everything up. And it’s getting better and better at it.

It’s that speed of updating, but also the fact that doing so costs comparatively little compared to paying for a framework, dealing with the risk of nobody maintaining it, or continuing to pay a vendor’s licence costs, that makes AI a genuine advantage for the customer.

So you end up, three or five years down the line, with a system written directly using basic cloud services, which is well documented and which you can change whenever you need to.

If a vendor goes out of business, changes direction or suddenly changes its pricing, you’re suddenly under threat.

There’s also the question of rewriting.

People who have given AI an existing codebase and asked it to recreate it in something else, notably Rust at the moment, will know just how good AI is becoming at doing that.

Compare this with the sheer monumental difficulty of migrating from one framework or vendor to another.

I say this as someone who’s been doing migrations for 30 years.

This is one of the genuine jobs for AI, and I think it’s why, when you’re talking to almost any cloud software vendor, they themselves go on and on about what their own AI functionality gives you.

Because I suspect they’re the ones, more than almost anybody else, facing a genuine threat from AI taking away their particular market.

The Dynamics of an Acquisition-Led Business

This is an observation post primarily to do with the insurance industry, because large parts of it have grown by acquisition. Many large insurance corporations grow by acquiring companies that have a stake in the line of business they are interested in or are potential competitors.

Obviously, this happens in other industries as well, but it is particularly common in insurance.

One of the key differences is that insurance and finance companies often acquire businesses that are already doing well. So, if you are doing really well and making good money, there is a good chance that a larger corporation will go, “Oh, they have the market sorted. They have an excellent product”, and will purchase you.

This leads to an odd dynamic inside any given corporation.

When something comes down from the group or parent company, there is often a great deal of pushback from former subsidiaries. The key reason for this, which I think is often missed, is that each of these subsidiaries were and are quite capable of standing on their own two feet.

They might not have been big, but they were holding their own, and they were growing.

They didn’t ask to be acquired.

They were taken over, and a lot of the personalities inside those smaller companies were the ones driving that growth. They were taking bold, leading decisions, and now they’re being given orders where they don’t think they need them.

They are effectively big boys and big girls who have moved out and are running their own lives. But, for some reason, their parents have forced them back into the family home and are now telling them what to do.

And they don’t see why they should listen.

In fact, a large proportion of them will look at the larger corporate environment and think, “Well, our way is better. I’m going to fight back and try to make the way I see things going forward the future of this corporation.”

And that is one of the core reasons we get such fierce political conflicts inside corporations that have grown through acquisition rather than organic growth.

So, next time you are working with, or trying to get your point of view across to, a sub-brand or subsidiary within a corporation, realise that for a lot of the time, the people you are talking to are successful in their own right and did not ask to join the same company as you.

They’ve been doing quite well for themselves, and the corporation can come out stronger by taking all the views of the different parts and merging them into a unified whole.

Vendor laptops are better set-up than internal ones.

This, on the surface of it, seems like a really fringe issue. But I’ve seen it four times in the last year.

If a client is extensively using cloud services, and it makes no difference which ones, because this problem applies to them all. Then nearly all cloud services require access to third-party utilities or additional tools to work efficiently.

It can be anything from trying to use Python with Azure, to trying to do anything with Salesforce without a Chrome or Edge extension. Whatever the platform, no cloud service works perfectly straight out of the box with just its built-in tools. If it did, you wouldn’t see so many third-party vendors and tools at conferences.

So, to do the best job, you install a bunch of plugins. That might be loads of extensions to get VS Code working properly, or Chrome and Azure extensions to get Salesforce working, or whatever your particular platform requires.

That’s fine and everything, but increasingly there is a problem.

When you have cloud services set up or development done by a vendor, they use their own company’s laptops. They connect to the cloud, install all the tools they know they need, and develop perfectly happily.

But if they’re using a company laptop, it can be very hard to get those same tools made available because they all expose a certain amount of security risk. Most corporate laptop builds are set up for the average manager or office user using a very minimal set of tools.

You therefore end up with vendors having a significantly better development configuration on their company machines than the internal staff members.

And because the vendors continue to do the work successfully, it is never really exposed to the security teams that there is a wider need for all these exemptions. So few internal people need them that the problem stays small. The majority of the development is being done by vendors, while the few internal people doing the same work end up fighting security for extended periods because there are only one or two of them asking for these rights.

Sounds like a small issue. Everything’s working. You’re delivering everything. There’s only a couple of people being inconvenienced. What’s the problem?

The problem is that you’re saving a bit of a bomb for the future.

You’ve now got a situation where your vendor can do things your internal people can’t. There is no proper exit plan for vendors, or for swapping vendors, because they’re using a whole set of tools and third-party items that your internal people not only don’t know about, but couldn’t use even if they wanted to.

And if you try to enforce on the vendors the same limited tools that are allowed internally, delivery plummets. Things don’t get deployed. Code doesn’t get written. So everyone backs out of that idea very quietly but very quickly, whether formally or not.

It means that if you have to change vendor, there will be a period of time where you are completely hamstrung when it comes to actual delivery and continuation of the work.

So, what’s the fix?

It’s well known and obvious…

You have a developer profile for company laptops.

Unfortunately this tends to involve quite a lot of effort to get set up and working, and, as already said, only a few people will initially be using it. Therefore, in this world of tough budgets, it gets put to the back of the queue and never really gets done.

So I advise either work out a standard set of tools that everyone adheres to and talk with your security teams about enabling them generally, or build a proper developer profile.

If you don’t, it will bite you sooner or later.

Jev and TypeSafe AI: A corporate style of AI not just a chatbot

There is an AI model doing the round called Jev, from a company called TypeSafe AI, and I think it is interesting because it might be much closer to what corporations actually want from AI.

For the last few years, nearly all the public-facing excitement around AI has been about chatbots. You type something in, the AI thinks about it, and a big chunk of stuff comes back; it might be code, it might be power point, it might be plain text.

That is cool and everything, but it is not necessarily how you want to integrate AI into a corporate system.

Most enterprise applications do not need another person to talk to.

They need a decision that can then be ratified by a human or process.

Jev is what TypeSafe calls a System One Model. Rather than being designed primarily to generate text, it is designed to take some state, answer defined questions about that state, and return structured results that software can use directly.

TypeSafe describes this as “decisions, not strings”.

The model currently works around three basic types of answer:

  • Noul: effectively a yes/no question returned as a probability.
  • Choice: where the AI selects from a defined set of options.
  • Score: where it returns a position on a defined scale.

The result is also accompanied by probability and confidence information.

This is much more interesting to me from an integration point of view.

Ive talked multiple times about how we actually implement AI into existing systems, with my favourite example being insurance fraud.

Imagine you already have a claims system.

Today it has a load of rules that say things such as:

If this condition is true, add five fraud points.

If that condition is true, add ten fraud points.

If the total goes above a certain level, send the claim for investigation.

AI can potentially make a much better judgement because it can look at far more context and far more subtle relationships.

But the person using the claims system does not need a chatbot appearing in the corner saying:

“Having carefully considered this claim, I believe there are several factors that may indicate…”

Nobody asked for an essay.

They need a dial or percentage.

Or simply “please investigate this claim”

That is a useful result.

The existing application and team can then do what it has always done but faster.

This is the bit I think we sometimes lose when talking about corporate AI.

AI should not necessarily be the application.

AI can simply be a component in an existing process, with the users just thinking its an improvement to the normal way they do things.

This is a very different architecture from throwing an autonomous chatbot at a business process and hoping it behaves itself.

TypeSafe’s own published workflow examples follow exactly this pattern. Their security incident example uses AI questions to assess an alert, then ordinary code determines whether to close it, queue it or take action. Their invoice example similarly combines AI judgements with deterministic business rules to decide whether something should be paid, held, disputed or sent for fraud review.

This is much closer to traditional enterprise integration.

And therefore, rather conveniently, it is much easier for corporate IT departments to understand.

Type-safe models do not mean magically correct; the Jev model can still make poor decisions.

Type-safe means, in this context, that you define the shape of the answer in advance.

If you ask it to choose between: Approve/Reject/Refer

You are not going to suddenly get three paragraphs discussing the philosophical nature of approval.

The software receives something it knows how to process.

That removes an entire class of integration rubbish.

  • No trying to extract the answer from a paragraph.
  • No checking whether it invented a fourth status.
  • No defensive parsing because somebody changed the prompt.

The judgement might still be wrong, and you absolutely still need testing, monitoring and sensible confidence thresholds.

But the interface between the AI and the rest of your software becomes much more like an ordinary software interface.

Then there is the cost.

At the time of writing, TypeSafe lists Jev at $0.042 per million input tokens, with output tokens effectively free because it is not generating long strings of text. It also reports end-to-end response times of roughly 70 to 500 milliseconds.

Think how that applies to your big systems.

If a decision requires roughly 1,000 input tokens, the model cost at the published price is around $0.000042 per decision.

A million decisions of that size would therefore be around $42 in model input cost.

Obviously real systems have other costs: integration, infrastructure, monitoring, support, networking, data preparation, etc.

But the model cost suddenly becomes tiny for the right workload.

And there is another saving that is perhaps more important.

You are not paying a large general-purpose model to write an answer that your software then has to turn back into a usable decision.

TypeSafe reports very large speed and cost advantages over general-purpose LLMs on its own workflow evaluations 1.

Even ignoring the headline benchmark numbers, the savings make it worth looking at.

That, to me, is proper integration.

AI should become boring and just do the boring jobs for us.

Jev itself may or may not become the model everybody uses. It is extremely new, having been released by TypeSafe AI in September 2026, and real corporate implementations will tell us far more than launch demonstrations ever can.

But I think the architectural idea behind it is much more important.

Perhaps the future of corporate AI is not talking to it at all.

Perhaps it is just the thing quietly helping us make our decisions more accurate.

  1. although these are currently TypeSafe’s own benchmarks and so take with a pinch of salt[↩]