No.

Not yet, at least.

Well, not in the way people think.

It’s easier to say no.

Let’s unpack this more and discuss why these waves are less clear-cut than people might think.

The Wave of LLMs, AI, No Code, and Low Code

AI and low-code tools are seemingly taking over the world. They are both taking off like DogeCoin in April of 2021 (what a time that was). It’s led to many thought pieces of how these tools will change the world and our lives forever. We are undoubtedly at the precipice of a technological shift, but people are overestimating ChatGPT and AI in many things (and underestimating others).

The AI wave creates a new expectation of what is possible with English language commands. AI generates pictures, removes backgrounds, duplicates voices, and more with simple sentences. However, the more complex the task, the more complex and precise the query must be. These LLMs also have limitations only found once you run into them. They can and do learn and improve even, but it’s important to remember these limitations.

The No-Code/Low Code wave has been building for years. When I first learned development, tools like Scratch and IDE workflow/interface builders evolved into tools that can build entire applications with minimal or no development code. Unfortunately, these tools are extremely limited in their current capabilities. They either require some development code to glue the puzzle pieces together or have to fit a particular use case and model perfectly. However, more and more solutions are looking to make building software as easy as building a Powerpoint by dragging all components into it.

Ultimately, these tools are compelling, but it is necessary to compare them to some of the significant characteristics of technology partnership integrations.

Integrations Are Messy

Some folks may have differing views on the terminology here that integrations are messy. But we can agree that they are complicated, unique, often hard to understand, and most importantly, valuable. Integrations are a key business driver for many SaaS companies today, and most folks in the two companies working together need to help to understand what’s happening underneath.

An Underinvestment in Tools

Many companies realize they need integrations and either expose their existing private endpoints to the world and call it an API, or they write massive bulk data extractions and call it an API.

While this process is a proper first step to get moving and validate the market, over time, the iterations into more proper APIs result in code spread across the code base and documentation that must be more accurate. Short of allowing an AI to scan the entire code base or sniff through possible connections, it would depend on much information that isn’t valuable.

I have many horror stories from integrations, and many people could help fill blog after blog with their own stories. Ultimately, investment into APIs and integrations are more strategic than directly tied to revenue, resulting in many problems. This underinvestment is why folks start on other projects after the code is complete, and the documentation and testing can be incorrect, inadequate, or even non-existent.

Components of Tech Partnership Integrations

I’ve spent a decade working on various integrations into many systems. While every integration has its pieces, the template is very similar. Even in the two main types of integrations, unidirectional and bidirectional, the components look the same because, at their core, the underlying mechanics are the same.

• Source System - the system that data is being retrieved from or requesting action
• Source API - enables data retrieval or action
• Destination System - the system that receives data or actions are occurring
• Destination API - the way the data/action is pushed to the system
• The Middleware - this can be in one of the systems or completely separate, but this is what maps the data from source to destination

The data in two disparate systems always look different. So it’s important to map those. The difference can be as simple as other naming conventions (“email” vs. “e-mail”) or utterly different tiering of the objects. But these five pieces make up most integrations at the highest level. Of course, some integrations have subspecies or complex APIs with callbacks, but let’s keep it non-technical.

In the AI/Low Code world, this glue can become difficult. You either end up with a game of AI Telephone, which ends up with some creative shifts as AI feeds itself prompt as seen in this TikTok or some version of a low-code solution that has a drag block that requires you to write much code in it. These multiple pieces create much complexity that requires some consistent understanding. When compounded with potentially inaccurate documentation, there’s some trial and error that people are more equipped to deal with than AI.

Integration Outputs are User Driven

Most technical partnership integrations are looking to drive a user experience. The partnerships can automate an existing workflow but eventually end in a user experience. For example, I spent time integrating medical devices with electronic health records early in my career. We were automating a lot of the workflow of nurses for clinical rounding. Gone were the days of walking into each room, reading the monitor, writing it on a clipboard, and returning to the nurse’s station to enter that data. This integration gave nurses more time to treat, more data availability, and quicker data availability to the care team.

The user experience here is that nurses could spend less time charting. It needs to be more user-driven. But, eventually, that data ends up in the hands of a doctor or care team concerned about timeliness and accuracy. So we created a new user-driven output in addition to the user story of improving the clinical time spent with patients.

The user-driven outputs are often hard to measure automatically and input; AI can iterate and improve with outcomes. The user, for now, is still an integral part; because of this, testing often requires some user interaction as iteration occurs.

Eventually, these waves will crash and ultimately disrupt the integration marketplace in SaaS. However, today, they complement the tools we already have and the skills everyone needs.