AI Isn't a Decision Engine— How You Use AI now could cost you in the long term

Everyone is going for an AI jackpot

I can't stop thinking about AI since Sapphire — where we are, where we're going, and how to get there in the context of integration. The nerd way of saying it: AI is best for problems that are probabilistic, not deterministic. Using it for the wrong purpose could cost you consistent outputs, additional time, and money (through unneeded tokens)

Let me explain what I mean through some recent examples I have run into.

The use case AI was made for: understanding what nobody documented

Every team has it. The conditional that clearly exists for a reason — but the reason left with the person who wrote it. No documentation. No ticket. Just code, and sometimes code fragments in a coding language no ones uses.

This is where AI earns its place. Feed it multiple samples of the legacy logic — variations, edge cases, historical outputs — and it can surface patterns that would take a human analyst days to reconstruct. Not to make decisions. To help you understand what decisions the logic was already making.

Here's where I tend to pump the brakes though. As a consultant, I don't want the solution — I want the requirement. I can then help find the right solution. If you ask AI to recreate what you had before, it's not going to stop and ask whether the process was worth keeping, or if it makes sense for CI. It's going to give you what you asked for.

Using AI to explain existing code, then validating with the business to develop a deterministic approach — that's the smart move. And when you take that approach on old codebases, you often find things like: "Oh, that was for a business unit that went away in 2012" or "We haven't used that movement type in years, what's that doing there?" You end up fixing, simplifying, and documenting processes instead of just replicating outcomes.

A real example: the UTC problem that wasn't UTC

I have an interface partner who gives bad requirements. Recently they told me they couldn't support timezones, and had data in UTC internally — so we should just send that. When we went to test, we kept hitting date conversion issues.

Turns out the vendor didn't really know what UTC was. I think they meant GMT. Every date field had an internal format, which also had a variable length. A lot of date fields. What a pain.

After feeding some examples of what worked and what didn't into AI, we identified the issues pretty fast. Not ideal, but we got a fix in. I had manually mapped the dates initially — in the samples I reviewed manually, they looked consistent and close enough to UTC to my eyes that I missed it by a character or two. AI caught it.

That's AI doing what it's good at: Pattern recognition across messy, inconsistent samples, faster than a human would.

The problems with misusing AI for deterministic problems

A lot of mappings aren't judgment calls. They're binary outcomes with defined inputs, outputs, and rules — and they need to stay that way. When you route deterministic decisions through a probabilistic model, you're not adding intelligence. You're adding variance to a place that can't afford it. And paying extra to do so.

A lot of people are burning tokens

While doomscrolling Reddit last night, I saw someone suggest that in the future every web service will just be a JSON blob routed and processed by AI. I genuinely hope that was a joke. No matter how cheap AI gets, I can't imagine paying per-inference forever is going to beat paying once for a consistent approach. And in a high-volume message environment, the math gets ugly fast. To me this is the difference between being a workman with quality tools vs. cheap tools. Long term quality pays off, and cheap has to be replaced.

More importantly: properly written deterministic rules are always right. Probabilistic rules are rolling the dice — and you can't afford that on your critical interfaces. When something breaks at 2am, "the model thought it was okay" is not a postmortem anyone wants to write.

The test I use: can the outcome be fully specified in advance?

If yes — build a rule. Defined schemas, transformations, version checks, policy gates, environment parity — these belong in code, not prompts. If no — that's time to consider AI. Analyzing large or non human readable datasets. Interpreting ambiguous failure modes. Summarizing novel errors in plain language. Reviewing change risk. Generating runbook drafts from observed behavior. These are judgment-heavy, context-dependent, hard to fully specify — and that's where AI adds real value as a collaborator for the humans making the call.

AI has improved remarkably fast. But for integration it's still better at riding shotgun with a map than sitting in the driver's seat.

A good servant but a bad master

Governance is key to make this work

Does your organization know what is happening on CI. For most people they have a high level scope, but the documentation is blank.

I say it a lot, but none of this lands cleanly without governance. If your CI environment is a tangle of implicit assumptions, inconsistent approaches, and tribal knowledge, introducing AI doesn't fix that. It potentially can be used to help identify, document, and resolve issues with the help of a good service provider.

A few practices that actually matter:

Consistency first. Nobody knows what the future holds, but consistency means you can adjust quickly. In my opinion, consistently wrong long-term will save more money than inconsistently right. Think about packing for a trip. If you pack as fast as you humanly can, you will almost definitely forget something crucial that you have to pay for later. The same thing happens with integration projects. Create standards; make your team follow them or justify deviation. Create a review process to be more DevOps-y

Document the why, not just the what. I wish CI had an annotation button on iFlows, but in the meantime, use clear language on activities to explain what you're doing and why. In Groovy and XSLT, write — or have AI write — a summary of what the logic does and the reasoning behind it. Build a document repository so the next person isn't starting from zero.

Write meaningful exceptions. Just like humans, AI can take a guess at a vague error message — but it may not be able to fix a problem without all the information. If you're doing something special in your error handling, leave a note for the support person explaining what was tried and why it failed. A little extra effort here pays off significantly at run time especially on complex interfaces.

Identify what's deterministic and what isn't before you reach for AI. Are you using AI to generate test messages because you have specific rules to validate — or are you burning tokens generating random strings you could produce for free? Maybe you could use AI to generate a deterministic program that creates your test messages, so you aren’t burning tokens every time. Are you using AI for a permanent solution, or for an understanding of the problem? Right now, the understanding is the real winner. Watch out for AI giving you a short-term win at a long-term cost.

Take time to review and retire legacy logic regularly — especially after AI-assisted analysis or as part of a migration. Rules that made sense three years ago or on a different platform may be encoding constraints that no longer exist.

The payoff

Jackpot

A well-governed CI environment doesn't just run more reliably today. It creates a documented, auditable foundation. No matter what the future brings, it will be better, and it makes AI integration deliberate and straightforward — because the line between rule and judgment call is already drawn.

More to come on what this looks like in practice. Onward. 🚀

If you're working through any of this — recovering understanding from undocumented legacy logic, building governance practices, or figuring out where AI actually fits in your pipeline — reach out. This is exactly the kind of work we do at Happy Integrations. info@happyintegrations.work