The year is 2025. The advent of ChatGPT, neural-net AI, and large language models is upon us. AI has infiltrated us. The chat-bots are ever present. Innumerable. They’re unavoidable online: from customer service in retail to writing homework assignments for high school students. But what does it all mean for integration developers? Will AI take over? Will we see judgement day arrive? In the words of the great Terminator T800, “Come with me if you want to live.”
February this year saw famed computer scientist, former director of AI at Tesla and co-founder of OpenAI, Andrej Karpathy coin the term “vibe coding” in a viral post on X:
There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It’s possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like “decrease the padding on the sidebar by half” because I’m too lazy to find it. I “Accept All” always, I don’t read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I’d have to really read through it for a while. Sometimes the LLMs can’t fix a bug so I just work around it or ask for random changes until it goes away. It’s not too bad for throwaway weekend projects, but still quite amusing. I’m building a project or webapp, but it’s not really coding – I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.
So, what is he talking about? Vibes? Exponentials? Forget about code? In a nutshell, Karpathy’s saying that a chat-bot can write code for us. We have no reason to intervene, no reason to even check the output. If the program runs, isn’t that all we need? Does it do what it says on the tin? We don’t even need to debug anymore. We can just ask AI to update the code or try again (and again, and again, and again) until it works. But does it work? Let’s break this down.
Can AI integrate?
Integration, at its core, is the replication of fundamentally human business processes into code. As developers, we try to replicate the actions of a person to perform a given task, or set of tasks, even. And of course, we automate it as much as suits the operational architecture we’re writing the integration for. But the foundation of a functional and efficient integration is a functional and efficient business process. The goal is to remove the human element from the equation of information distribution throughout a set of interconnected systems so that the users of those systems can rely on what they’re seeing to perform their own roles in the business. But if asking an AI to write code that gets data from a source system to one or more target systems (thereby satisfying our end users) does AI in fact accomplish the task. Is that our job done?
For a start, let’s have a think about what an LLM is: a Large Language Model is essentially a program that can recognise and generate text. An LLM is built on machine-learning; and trained on enormous datasets comprised of millions and millions of gigabytes of data. A study of LLM datasets by Liu et al. published in early 2024 surveyed over 770 terabytes of data across 700 million sources (that’s a lot!) and that number will have only grown since. LLM’s consume raw text, analyse it, and try to assemble a ruleset on how the characters, words, and sentences function together. This “deep learning” is the probabilistic analysis of unstructured data which eventually enables the model to distinguish the context of pieces of content.[1] The responses to the questions (known as prompts) we ask are then, inherently the best guesses at which word most likely comes next. The finer the context window (in other words, ‘did we ask the right question?’), the more likely the result is usable or correct.
AI can absolutely help us design, write, and even test code that’s fit for use in our integrations. But here’s the human factor: we need to have the necessary skills to understand what it produces. To know whether what AI gives us as output is a fit for the constraints of the architecture we’re working to, to know if it’s going to be efficient, to understand if it’s at least somewhat future-proof, and to know if it’s maintainable. What about the edge cases and complex business scenarios? For instance, a customer requests a refund, but the delivery driver has already been paid… Do we refund the whole amount, or just the product price? What about security or privacy? If two people share a file and one person deletes it, does the other person have their instance deleted? These are minor examples, but the potential for large-scale or catastrophic business consequences is always present.
Prompting a large language model for niche cases, and often very context-sensitive scenarios that occur in the day-to-day duties of everyday people doing specific processes at work takes an innate knowledge of both the process we’re automating, as well as the expected result of the prompt. It also requires the prompter to be able to articulate the requirements in a way that yields a usable result. All of this comes with years of experience—experience that Karpathy in his post even admits he doesn’t always have. His approach of generating code and blindly accepting the output with no further cogitation, as he freely admits in the post, results in “code that grows beyond [his] usual comprehension”—this being the opinion of a renowned and experienced computer scientist. A layman or “citizen integrator” would likely find their limit long before Karpathy in terms of comprehending the AI’s generated output.
What about debugging?
What I find most interesting about Karpathy’s post is the debugging “strategy”, if it can so be called. Working around a bug is fine as a stopgap; however, addressing the root cause of an issue should always be the goal. And for the issues that can’t be fixed by AI? Asking it for arbitrary changes in the code until it writes something that doesn’t contain the bug being addressed is simply asking for trouble when it comes to programming.
This approach is akin to—and excuse the analogy here—dropping into a game of Fortnite or battle royale unprepared. You land on a random spot, hope you get the right gear, and just react to whatever happens next. Sometimes you get lucky and everything works. Other times, you’re out in the first minute.
Random trial-and-error might be fine for casual gaming, but in integration development, it’s a recipe for fragility. Without understanding the architecture or the logic behind your code, you might build something that works once—but breaks the moment conditions change. Or worse, you might not even know why it works, leaving you unable to maintain or scale it.
So, will it steal my job?
Here’s the hot take you’re all tuned in for: integration development (or indeed, any software development) requires some level of expertise, some experience, and some idea of what your end solution looks like. When we’re building to a known and oft-used pattern, AI can hugely decrease our time to delivery by helping us write boilerplate code and even get as far as applying some of the required business logic. It can help us write unit tests. It can help us automate deployments. It can help us document our solutions. But it can’t completely do any of this for us. AI, on its own, can’t replace the years of skill, experience, technique, and most critically, communication that humans naturally have.
Adaptiv’s experienced developers and consultants leverage AI platform tools such as GitHub Copilot, Microsoft Copilot, Boomi Agentstudio, and Einstein for MuleSoft to accelerate delivery in a controlled and secure manner. We are closely monitoring other potential frameworks like Anthropic’s Claude AI for test and code generation capabilities. When it comes to building robust, business-specific integrations, it takes more than automation. It takes an understanding of context, constraints, and complexity. That’s where our people shine. Because when the details matter, there’s no substitute for the human touch.
[1] Cloudflare. (2022). What is a large language model (LLM)? Cloudflare.com. https://www.cloudflare.com/learning/ai/what-is-large-language-model/
