How We Use AI

AI is here to stay, whatever any of us think about it.

Epicor appears to feel the same way, and many of the recent big announcements revolve around making their ERPs work with AI, embed AI into them, and in general assume AI is the future. There are many people who are less sure that it's going to be for the better, but this is the way things are going. And there are undoubted advantages, because LLMs etc are an extraordinary technology.

If you're thinking that this doesn't appear to be a very enthusiastic endorsement ... well, that's just because I want to focus on how we're managing the downsides of AI. Firstly because hype isn't helpful so we need to acknowledge that there are some, and secondly because I am well aware that there are many who are suspicious or downright hostile to AI and I have some sympathy. Transparency can only be a good thing.

This particular transparency is expanded on here if you're interested.

META eight and AI

We are a consultancy and developer focusing on Epicor Kinetic ERP. So when we do work for you, typically we access your ERP system and your data. It may be a development system, usually, but still with your data.

So we do not feed that data into a commercial AI. Not even one that promises not to store the prompts or use the session for training. The data is not ours to do that with.

I can see a future in which AI analysis of ERP data may be useful, but our research in that direction is around LLMs that we control ourselves. Either with dedicated hardware, or via services that run only transient compute. As we do that, privacy and control will be the first priority.

What we DO actually do

We do, though, use AI tools in our work. And here's the practical run-down on what I have found personally. Bear in mind that, from the conversation I see, opinions differ and there are some strong opinions out there.

As a developer and consultant, I have paid accounts for both ChatGPT and Claude (writing as of June 2026) and have a sufficiently specced computer that I can supplement them with local models for certain uses. All are now arguably better at pure code than I am, including the C# used in Kinetic server work (and classic screens) and the Javascript needed for the browser client. Also SQL, which is a mixed blessing because of the way Epicor's developer tools work.

Although there's a preview tool that suggests otherwise, you can't create a BAQ by writing SQL. Epicor's fondness for visual developer tools, with drag-and-drop widgets, limits what AI tools can help with directly. So, ironically, in our work they're most useful for the "advanced" work such as BPMs and functions, where they can work on pure code.

In addition, Epicor systems are relatively niche compared to the vast mass of data out there for, say, website design. So in my experience general development advice from AI tools is a bit hit-and-miss. It can be very accurate, but you can't rely on good answers, and if you're used to viewing the best Epicor-related online forums you'll probably recognise the better solutions. Epicor's own AI systems will presumably be better, but it's early days for those.

What works:

When I want to implement an algorithm or code function I can specify precisely, AI will do that for me, saving me time and (generally) mistakes. I need to know enough to know exactly what it should do and where it will be implemented, and none of the AIs can ever accept that helper functions aren't compatible with Epicor's systems so I often need to change what it gives me, but the code is good.

When there's a bug in a BAQ or RDL, I can upload that directly (see note later about privacy) and AI tools are better at combing through and pinpointing where to look.

If my own code isn't behaving as I want, AI tools are likewise good at pointing me towards where the problem might be. They are tireless and eagle-eyed, where the best of us humans get blind spots, often the harder we look.

When something is conceptually tricky, AI is a luxury "rubber duck" that I can explain the problem to and it will actually answer. (For those unfamiliar, programmers have long sworn by explaining their stubborn problems to a rubber duck as a sample inanimate object, because the very act of explaining it often leads us to a solution). The fact that often I don't agree with what it suggests doesn't matter, because it's having the conversation that does the work, not its answers.

AI tools are also good at manipulating and summarising tedious documents like formal specifications and documentation. So it can save a lot of time pulling out and matching up data fields, for example, or turning examples into the right sort of code to work with, rather than doing it all manually.

And here's the privacy part. We make a distinction between putting client data into an AI tool, and using it for code. As an example, a customer record is data, and that should not be made public without specific permissions of various kinds, so public AI tools are off-limits. But a BPM that adjusts how that customer record is handled by the ERP doesn't expose that data so the workings can be touched by a public AI without compromise, as long as it doesn't include any hard-coded values it shouldn't.

And the medium-term future

In spite of what may look like caution and pessimism, we are, if anything, expanding our use of AI in our Epicor-related work.

With more efficient coding tools, we have been able to build things like test harnesses for Kinetic systems that would otherwise need too much resource to be worth the risk. In those cases, the AI doesn't work on the ERP directly, but broadens what we can do with the ERP.

Similarly, we are in the promising early stages of tools that allow us to automate the creation of customised functions within an Epicor system based on the specification we provide. Again, the AI doesn't touch the ERP, but makes the tools possible. As we get further with this approach, we hope that it may be possible to do much the same with BPMs and BAQs at least.

As we do that, an important development has been a gateway that does interact with any specific Kinetic system, and exposes secondary tools to our own tools. This (without the involvement of any AI) maintains a directory of Kinetic API calls it can use, and which are allowed to what extent. So specific calls we allow can be requested by our tooling and limited information passed according to rules. That means we can work on the system without working in the system. This firewall, or insulating layer, is what is allowing us to experiment under control, and means we can, for instance, create a customised function library automatically without giving our intelligent local tools access to the Kinetic system at all.

And the final piece of that particular puzzle is the library of snippets and techniques we've built up over time, proven ways of doing things in Kinetic systems. AI makes that easier to work with, both for human retrieval and as the basis for new solutions. A small local AI is enough to turn it into an intelligent source of its own.

Doing AI for you

For thoughts on how AI tech mixes with ERPs, we've already covered that in another article: Careful with that AI in your ERP.

Where it makes sense, we can integrate AI systems into your Kinetic system, whether commercial ones or local. We are happy to talk about how to decide and approach such efforts. Increasingly, in fact, a lot of this is fairly routine as the line blurs between specialist add-on software and AI tools anyway, but we are also constantly evaluating the use of raw LLMs and custom frameworks around them in areas where unique things can be done so are able to advise more generally.

The takeaway

At META eight we feel we are realistic about AI at this point.

We use it ourselves, we increasingly feel it's important, but we are also aware of its limitations and the care needed to use it well.

And most of all, we treat commercial AI as an unknown third party, so we don't pass it your data.

This article, incidentally, is written without AI in any way, and so is our newsletter every time.