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.

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[↩]

An Easier Way to Get Rid of AI Fluff

We all use AI nowadays, some of us better than others. Often, we use it to generate a bit of text, whether that is a definition, some proofreading, or something similar.

One of the main problems is that AI, particularly chatbots, represents the internet as it stands at any given moment. And that the majority of the people that generate such content are not professional writers. This is one of the reasons AI companies are currently chopping up books to improve the standard of English their models produce. Published material tends to be far better than the language used on forums and social media.

However, there is a way to improve AI-generated text without chopping up priceless books.

You can ask any text generated or modified by AI to adhere to ASD-STE100, a standard for Simplified Technical English. It is a constantly evolving standard that is updated regularly. It is proprietary and wholly owned, but it is available to download free of charge.

If you tell an AI to format text according to ASD-STE100 and obey its rules, you get a much cleaner result that requires far less reworking before it becomes usable.

It removes the thesaurus-mangling habit of replacing simple words with fancier ones. It reduces meandering sentences and keeps the writing crisp and clear.

Yes, it is designed for technical documentation, but believe me, it is also far better for everyday communication, particularly when you are asking AI to produce clear instructions or useful results.

It is a good top tip and well worth knowing.

Move 37: learning from a little AI history

This might sound like a strange phrase, because AI, at least in the form most people now recognise it, has only really been around for a few years. But there is already AI history, and some moments that have been dismissed in one region or country have been fundamental in another.

One example that I think is well worth reading about, especially if you are interested in how China came to view AI, is the AlphaGo tournament, where an AI beat one of the world’s best Go players.

To many of us who had already seen similar things happen with chess, this felt like another incremental step. Computers had been getting better and better, and sooner or later they were going to beat humans at more complex board games. Chess had already had its Deep Blue moment, so AlphaGo could easily be seen as the next stage in the same thing.

But Go is different.

If you watch some of the videos about the match, particularly those that cover Chinese reactions to it, one move stands out: Move 37. In that move, the AI did something that was classed by many observers as almost alien. Mathematically, it was simply finding a logical gap in a progression. It was a move that worked, and there was no real reason why it should not have been played. But up to that point, it looked completely weird and different.

Because this happened within a subject that was culturally important and widely understood, it helped redefine, to a certain extent, how China saw AI. From that point on, AI was taken far more seriously, contributing to the enormous effort and investment that followed.

I will put a link to a video below, but it is well worth watching.