Vibe-Coding on the Shopfloor: Building MES Applications In-House Without System Integrators

Vibe coding in the factory — how generative artificial intelligence can replace entire MES systems. Our guest is the company United Manufacturing Hub, UMH for short. This is a company that makes its solution available for free as so-called open source, giving it a rapidly growing community of enthusiastic users. How they still manage to make money despite that, and everything else that's possible with AI in the factory — that's what you'll find out today. Enjoy.

Hello, dear friends of IoT. Welcome to the IoT Use Case Podcast. Today we're talking about a topic that is becoming more and more relevant in many plants right now. What happens when generative AI suddenly not only writes text but also builds production applications? My guest for this is Alexander Krüger from United Manufacturing Hub, UMH for short. UMH positions itself as an open-source platform for industrial data management. Alexander is its CEO and Managing Director. Alexander, let's dive right in.

So what problem do you solve for your customers?

Alexander

Thanks, Peter. I think that, not just for AI but in general, our customers have the problem that they can't get at their data. That is, they have production data somewhere in the MES, in the ERP, possibly in various systems like warehouse management, on the PLCs, in the SCADA, in the historian. But it isn't really easily and consistently accessible anywhere. And that's exactly what we want to solve — making all the data you have nicely structured and available, so you can then, for example, vibe-code really great frontends on top of it. That's what today is all about.

I'm really glad to be talking about vibe coding in particular, because it has developed incredibly dynamically and keeps evolving. My own background right now is also very much in generative AI. In the manufacturing environment it does come with challenges — hallucination and the like. The first use cases you heard and saw for generative AI on the shopfloor were topics like documentation — making the relevant manual available and being able to ask questions about it. You're now going a clear step further. At the same time, your focus isn't actually vibe coding itself, but the foundation for it. Could you elaborate on that a bit?

Alexander

Eighteen months ago, AI in manufacturing was obviously a topic, but no one knew exactly how to approach it. GPT was essentially integrated with the data in some form, and then you'd say, "Ask your AI" or "Ask your Factory." And then it would tell you why your OEE is poor or why machine 5 has higher downtime than machine 2. And I think that's not actually the problem. Those are usually things that are either very obvious or not very helpful tips: "You evidently have technical availability problems, try increasing your maintenance" or "Try to react more often or faster when your machine goes down." That isn't really helpful.

And that's why people actually focused more on other things — not really doing anything new, just doing things they already wanted to do, much more easily and quickly. And that, I think, solves a really cool problem in manufacturing — this whole issue around skills. That is, our customers actually had loads of use cases that were already technically feasible before. They wanted transparency over machine utilization, over tool usage, over resource consumption — broken down into various analyses and segments and machines. And now they simply have a tool in hand that can build frontends incredibly easily.

That's basically the cool thing about AI. There's no world model yet where you feed in your factory data and it tells you, "Turn the process parameter from 5 mm/s up to 6 mm/s and you'll get a higher yield." Sadly not yet. But you can now say, "Please build me a frontend that shows plant manager Peter, very simply, where my top 6 availability problems are based on real-time data in the factory." It's just really cool that far more people can build applications than two years ago. So a factor of 10, 100 more applications. And that's exactly what we're seeing right now with many of our customers.

I'd be a bit curious about that — which customers this is working for right now. Many still have classic HMIs, that is, human-machine interfaces, that are permanently built into the machine, dictated by the vendor, which you can't change at all. Then there are the offices, where something can already be built. Could you make that concrete with a customer example? Did they hang up extra screens for such frontends in the plant, or what kinds of applications are there?

Alexander

Our example that we can now also talk about publicly is HiPP. It's a baby food manufacturer — they make the little jars and also the breast milk and so on, you might know them. And they have actually built loads of vibe-coded frontends, now I believe already at a high four-figure amount of extra Claude usage per user per month, just to build these frontends. We've already hung up screens everywhere in the factories. That is, in the various halls there are dashboards for different top KPIs that always show "goal versus actual."

And they have now actually built frontends for various problems they had. It starts with building up asset management for the various products they have in use — things like accessories that are supposed to run in production and that you then also track in the Unified Namespace. Various analyses of, for example, compressed-air consumption — which then enables much more granular and also much more user-friendly inputs into the Unified Namespace. And so, piece by piece, they first built things for themselves and then share them on a platform with other users as well, so that they're available on monitors in production, on a phone, or wherever. And these are always lots of small problems that you basically just throw a few tokens at.

For context: tokens — that's the unit for generative AI. Input tokens are fragments of words, parts of words — that's how these large language models compute. Because that's also something I've noticed: many people in industry are a bit confused; AI gets talked about all the time, and there are the classic AI models that make predictions based on machine data — those are very specific models trained for that purpose. And then we have generative AI — those are the large models that are already available.

You touched on another topic that we may need to clarify: the Unified Namespace — much better known in industry, but perhaps not to everyone. Could you briefly elaborate on what role it plays here?

Alexander

The idea behind it is to say: you fundamentally have a structuring problem to begin with. That is, I'd like to have data, but I don't have it readily available. And the Unified Namespace takes that on as the solution. Two things: it's an event-based architecture. That is, all the information from my factory now comes into a central data platform as events and as updates in real time.

Second — in a semantics, that is, in a structure in which I can actually understand the data. That is, along my ontology or my hierarchical structure — my site, my production areas, my lines, my machines — I've structured it all the way down. Then, within this model, I've defined what the attributes are that I'd like to have. And that's how I build myself a data structure, functionally and systemically. And then there are also compatible, supposedly even competing standards — in the chemical and pharmaceutical industry, like the Asset Administration Shell or the Module Type Package, or industry-specific standards. But it's totally compatible. It's more of a high-level concept that data should be centralized, structured, and processed in an event-based way. You can also combine that brilliantly with the various asset models that already exist.

I think it's totally relevant for anyone heading in this direction to understand how important the semantics of the data is. Some have started collecting data and storing it in some blob storages. But if you don't know what a data point stands for, if it has no semantics, no description — when, why, to which asset it belongs — then you simply can't do anything with the data. Then it's ultimately garbage. And that's why it's all the more important to give yourself a clean structure.

Alexander

That applies fundamentally to humans as well as to AI. The idea that AI can completely anticipate what the data means is wrong. The AI needs exactly the same context that a production manager or a maintenance technician would need in order to understand what data is being published — whether it's a maintenance order, a work order, or a machine state. Just as for humans, the data has to be just as understandable for the AI too — because it works via natural language. Accordingly, it's the same foundation for both.

I've just come out of an AI training where I always bring up the example of the working student whom you then have to explain what to do. Because many still use generative AI like a calculator or a Google search — very sporadically — and then expect magic to happen. And indeed, once you understand how thoroughly you'd have to explain something to someone for a good result to be possible, it becomes clear that it's about good communication, clean communication, ultimately semantics.

If you describe it once more — semantics understood, you have a clean data structure and can vibe-code an app on top of it —: what exactly do you do at UMH now?

Alexander

Just because you have the data doesn't mean it's already a great backend for a vibe-coding application. To break it down: the vibe-coding platform is basically just frontend. That is, you have an application that lives in your browser or wherever you install it, and it then accesses our data backend. That is, we try to offer the AI all data and functions via APIs — that is, functional interfaces — through which you can either retrieve or write back data. So that the AI can focus purely on the visualization and the user interface.

Functionally speaking, we've built a platform that deals with reading out data from various machines and processes. I can pull my data from a Siemens controller, from a Rockwell controller, from a Beckhoff controller, or others — that is, a wide range of protocols that we've built over the past years. I can then normalize it in our platform and offer it via various APIs.

We have an API that provides historical data — which is super relevant for frontends, so you can look at the data over the last week, shift, month, day. And at the same time also a real-time API for the events — so you can access the real-time stream of the data directly, reading or writing. And that's how I can build data visualizations or also functions — for example: "Please create a work order" or "I'm now reporting back a fault reason." Classic employee inputs that you sometimes still require at the HMI we can also offer functionally, so that the AI can focus purely on the buttons, colors, and charts that are then fed by our backend.

I think that's an important part too — understanding that AI, when the data is clean, can then also work reliably. It just must not be confronted with unclear data, otherwise it starts to hallucinate. But when the data is provided cleanly, it's so flexible to build on — I keep building vibe-coding apps myself, and it's totally impressive how fast and easy it is once you throw a few tokens at it.

There are all sorts of standards out there. You talked about APIs, MCP, and the like. Have you already thought in that direction too?

Alexander

Exactly, there are various currents in the AI bubble right now. We're actually leaning more toward a CLI at the moment. That is, you can offer the various functions of our product and the platform via a CLI, because that's something you can interact with really nicely — you know it from programming. And the APIs we offer for consuming the data are very classic REST APIs. MCP does solve a few things like security and access. But since we mostly deal with relatively complicated authorization mechanisms within the company, it doesn't help us nearly as much as you might think. That is, we're currently consciously deciding a bit against MCP, betting on CLIs and APIs that provide functions or make data consumable.

I've heard that too — that MCP isn't quite the cure-all. It's also a standard that's still evolving, so you have to watch where and in what way it takes hold and becomes relevant.

Alexander

That will surely get even better. But what we've actually always thought in our product development: what is, in fact, already "old and boring"? And to just bet on that. It's just not the case that every new technology always requires new technology. For a Unified Namespace there may already be something like Kafka or Postgres, where you can store things in a totally boring but highly available way. And likewise, for interacting with data there are technologies that have been working for 10, 15, 20 years already. A fun fact: GitHub — there, too, the AI interacts with a CLI, simply because it's totally great, well-known, and documented. And that's exactly our idea behind it too.

We've now dived a bit deeper into the interface topic. Let's step back up a level and think: how can you put all of this to use? We'd talked about dashboards. But it gets even more ambitious from there. I'm thinking right now of MES systems, where many struggle with the complexity. Where do you see the limits of such an approach — and also the possibilities?

Alexander

Many technologies or products you already use are actually always a bit of frontend, database, and business logic. Whether I have a tool for detailed scheduling, a tool for dispatching my work orders, a tool for reporting machine hours or from employees — that's usually always some frontend application that logically runs on a database, but is then extremely heavily adapted to the customer's business processes. There is no MES system that would work across industries and even within a single industry for every customer. And that's why you throw a system integrator at it or pay the maker of the MES system a lot of money all over again.

And what I find so cool here: the business processes are very clear to the company. You can describe extremely well how a reporting process happens, or an interlocking, or a process lock, or a fault-reason report. And now the AI can basically build frontends against a standardized backend to represent exactly these things. My standard MES applications — something like: an employee says a work order is done, clicks "OK" three times and "NOK" once — that's somehow three buttons and maybe a signature field. And there the AI can build these small business processes extremely well. I see that as a huge opportunity to also massively bring down the cost and the time for implementing new software.

So MES in particular — if you can solve it in this form, it does a lot to many players in the market: some it sends into a sweat, others into storms of enthusiasm. Because it's not a simple topic, one that no one has cracked at scale yet, and these are always very complicated projects.

Alexander

Almost everything shifts fundamentally there. You still have the build-versus-buy situation — that was already the case two or three years ago. But what's happening right now: you fundamentally shift the cost lever massively downward for these build decisions. I no longer have a 500,000-euro project; instead I can do it in-house with two or three really talented developers, and they get it done for me in a few weeks for 20,000, 30,000 euros in tokens.

We already have this now, too. I know construction companies that have vibe-coded their entire MES system. And it's actually already in productive use in dozens of plants worldwide. Yes, it really is just a question of wanting to. But it's actually the same dynamic — only the cost point of the build decision has shifted.

It's exciting too — back in the day with IoT platforms we always had this build versus buy as well. I think that, when it now moves toward building, a lot is of course attached to that. Because building was always the difficulty — once I've built it, I also have to maintain it. And the maintenance is then quite a huge thing, except — and that's also how I understand you now — when you work with clean interfaces and the frontend is so flexible and quickly adaptable that the maintenance effort goes down. Where do you see the biggest challenges in this approach?

Alexander

Exactly right. The question of what has to be maintained and what is maintained by whom is basically always the slider you want to move. What we say very concretely: vibe coding is, A, not for everyone. If I place a great deal of value on deep integration into my ERP system, then you might also buy SAP DM and save yourself the work. Or I have a great business process that already sits there exactly one-to-one — then I don't need to give it any further thought.

But the only place where I generate maintenance effort is really the frontends. I have this data infrastructure in the background — I have to maintain the interfaces, but I have to maintain those anyway, no matter which system I have. And it gives me data in a standardized, versioned, auditable format. Now I basically only have to think about: does the graph come out green or blue, button in red, top or bottom. And maintaining such frontend applications is then significantly easier.

Sure, you have to think about how you handle the concept for dependencies, updates, and security. But you no longer have this business logic that's hidden somewhere and that only Martin — who left the company three years ago — still knows how it was built. You explicitly no longer have that. You only have the visualization question left, which could also easily be done again from scratch. And I think that's the important point: not to vibe-code everything, but only the things that could basically be reproduced as single-use code within a few minutes.

That's also shifting increasingly. Half a year ago, you'd still have had to have everything that was vibe-coded rebuilt by developers. By now they're really production-ready applications. What I liked in the preparation is this term "infrastructure as code." Could you explain that a bit again in this context?

Alexander

There are two ways to put AI to better use in production. One direction goes toward the user — that is, toward the application — where you can approach it with vibe coding. And the other massive driver of effort is actually setting up this data infrastructure. You can see: the world is a completely different one once I finally have my data straightened out — that's basically the claim. Then everything becomes much easier.

And on the con side there's supposedly this huge project over months, years, in which I now sort all my data points and connect all my machines. That's still the counterargument against doing such a project at all. And that's exactly where, with infrastructure as code, you can cut out a whole lot again, by saying: I'm not going to have my infrastructure clicked together over nine months per plant, clicking configurations together in dropdown menus every time, but rather: our entire infrastructure is basically one giant configuration file. It's available to the AI as a configuration file.

And what makes it much easier? Now I have my Janitza Modbus gateway that reads out my power values everywhere — it then has something like 800 register entries that no one understands, across 800 pages of PDF. And I can now simply throw those into the AI and, with our UMH skill, have it produce a valid configuration file for the UMH that reads out these Janitza meters. And right there I now take out five hours of reading, three hours of clicking things together in the tool — and within 15 minutes I've implemented something that would otherwise have taken a day. That's the big lever of infrastructure as code: the AI can work really well with code, and every tool that functions as code becomes much faster and easier to use as a result.

That keeps evolving too — all the new sensors and machines are being described better and better. What's your experience from practice there? Where are the limits where you say: this still doesn't work?

Alexander

That's actually always a function of how good the documentation is. As any developer would say: the interface is only as good as it's documented. That naturally applies to the AI too. That is, if the AI has no context at all — say it's somehow a completely self-developed project from a machine manufacturer who hasn't documented anything — then it may get difficult. You can even just upload the TIA Portal project file and still have the data points pulled out anyway. That already works.

But that's exactly where the limits are: the less context I can make available to the AI, the less effective it gets, the more I have to write emails and make phone calls afterward. There are very, very many standardizations taking place. For example, with new machines in the food-and-beverage sector — at least under the Weihenstephan Standard. And in the injection-molding sector there's EUROMAP — which you can lean on brilliantly. And a great, great deal is already happening there.

In the IoT user group we had the exciting discussion of how to get at the data. One participant said he'd recently bought a new machine and hadn't taken data availability into account at all. Which left me totally amazed that this is still the case. It's so simple and obvious: when you buy a new machine, you also write into the tender: "By the way, we also want to have all the data."

Yes, when you have the upper hand — because once you've already bought the machine and then want to get at the data, it gets difficult. Back in my Siemens days I always used to say: everyone, please by all means write into the tender that you can access the data. Do you see further limitations there? Do you see it as industry-specific, or are you more active in certain industries than in others?

Alexander

There are always industries that are fundamentally easier — that also react more innovatively or dynamically to change. And there are industries that, due to a heavily regulatory or project-driven approach, would rather not be the first movers. As an example: the pharmaceutical industry has high quality requirements. There you tend to go by "never change a running system." I mean, they change too, and there are innovative companies and pioneers as well. But per se I'd say: harder at first, because now every vibe-coded frontend still has to be signed off. Which of course isn't so nice then either.

And then there are industries like food and beverage, which I find relatively strong. There you clearly also have requirements around the topic of critical infrastructure. But they actually have a relatively good connectivity profile and also, mostly — because they have large installations — are actually faster to connect than, say, a manufacturer with very, very many machine tools, where you have to communicate with 15 different makers. I'd say: the less regulated, the better. And the larger the installations, the easier.

You were able to give an example already with HiPP, who now have many vibe-coding applications on their dashboards. Do you also have benchmark figures, KPIs, any key metrics there that you can use to justify: "Hey, let's go in this direction"?

Alexander

We recently did a study with some of our customers together with Forrester, an analyst agency. They looked at it very top-down: what benefit customers actually get — not in the sense of higher, faster, further, but really: how many euros come out at the end? Across our customers there was on average 5% energy savings — through greater transparency over consumption and processes. And, I believe, 14% fewer unplanned stoppages.

In the end, for a composite organization made up of various customers of ours, that actually led to an ROI of over 400% and a few million euros in benefits. And that's extremely cool, because with vibe coding it now gets even faster. That is, customers who built this the traditional way — that is, with classic frontends or in Grafana — will reach these benefits significantly, significantly faster thanks to vibe coding. So we've already generated really solid figures across our customers there.

That's exciting too — whether it will even still be called "vibe coding" going forward, or whether it simply evolves further. You're not really in the vibe anymore then — you can define and set very clear requirements there, and that then gets implemented accordingly. By now it's super reliable.

To sum it up: if someone now wants to get started with you — how do you begin? What did customer projects look like in terms of the process? First step, second step — and maybe you can also work in right away what mistakes there are that one could avoid.

Alexander

We have a somewhat special starting position because we're open source. That is, our core product — basically anyone can now go to our website, download it, and use it to connect their first machines and vibe-code the application they'd like to build. That is, many of our customers initially start out in a solution space where we don't even exist. There's no salesperson pestering you, just a product — and the person can first validate for themselves whether it's even interesting at all. And that, I think, is one of the first important steps: first really engaging intensively with the product, with the problem you want to solve, and seeing: can the product solve the problem?

And then they mostly start with one plant or with one to three plants, to build templates piece by piece. Because this Unified Namespace instance also consists of a lot of homework. I first have to define: what does a CNC machine look like at my site? What does an injection-molding machine look like at a Böllhoff? Or what does a furnace look like at another company? From that I derive standards that I establish and test in the first one, two, three plants — do they also work for Japan, will they work for Brazil, and vice versa. And then I create this first batch of standards along semantics and hierarchy and roll it out piece by piece.

Along the way, you then build up so-called competence centers — usually divided by region — where power users sit who help build up the other regions and sites. A very organic approach, but it always has a great deal to do with engaging intensively with product and problem and then progressing iteratively.

With open source, the exciting thing now is, of course — there's always this problem for the provider: what is my business model if I give it away for free? I'd be interested in that. You do then also provide support when things get more difficult — or how exactly do you make your money?

Alexander

Yes, it's counterintuitive at first. Building a company — for that you do also have to make money. And you don't initially make money with free software, that's true. Let me call it open source 1.0, where these Red Hat models basically existed, where for an enterprise product — which is the same product as the open-source product — you paid a fee, in case something breaks, so that you're allowed to call someone.

That of course has a wonderful conflict of objectives: if you make your product so good that you no longer need anyone — which is supposed to be the target state — then you don't need this enterprise license. Then there was the second wave of open-source products — the whole as-a-service topic. I was able to get databases like MongoDB or PostgreSQL as a service. And because we, in particular, are actually installed in the customer's factory and accordingly can't offer ourselves as a service at all, we created a different licensing model.

We introduced additional components — we call it the Management Console — that make scaling in particular easier. It has a great management and permissions concept, multi-user collaboration, audit trails, and also versioning, and much more. So everything you don't necessarily need to be successful at a single site — but everything you need if you want to work scalably and with good governance in a large organization, that's then proprietary with us. We try to build that as a fair compromise: we don't want to hold anyone back, nor punish the community we've built up. But at the same time, in the situation where large enterprises start scaling us, to offer significant added value on top, which is then commercial. And that's how we make our money.

Exciting approach. I think it's really great that you can start out for free there. You just mentioned the community — that would be quite exciting too. Because to simply get started, you need a lot — support, documentation, exchange, too. How did you build it up and what's going on there?

Alexander

That was another topic that actually really bothered us. Because normally software in manufacturing was bought — that was usually a very manual process. Then you got some file or some license key, validated it locally, downloaded the software, unpacked it, installed it. And then, as a user — or also as a provider — you never got feedback from the products again. As a smaller provider you then have something like 20, 30, 40 customers. That is, you mostly only get feedback when things go really badly — when it then gets escalated via the salesperson to the dev team.

It was clear to us from the start: we can't do it this way, because, A, that's far too few users to really build a good product, and, B, we want to stay very, very close to the user. And that's where the community is a great thing. We now have around 1,000 community members who are actively building things with the UMH all over the world right now. And through them we get significantly more feedback than we could get if we were just a closed product.

And they may then even build in new features. They build in their own protocols for machine manufacturers that are especially important to them. They build up templates for use cases or for integrations that others can use as well. And above all they give feedback on things that don't work — so that everyone else can also benefit from that edge case. We can then fix it anyway, because we have so many people out there using our product daily.

Yes, that was a strong design decision: if we want to build a manufacturing product, then we also want to build it with a large number of users. That really only works with open source. And especially if we really want to change something — what fundamentally bothered us is how we currently handle data in industry. And we can only change that in a structured way if we have as many users as possible. That's easiest with open source. That's why it was a very, very obvious choice for us.

I think that's strong, a very courageous path in any case. And now a somewhat mean question — because you're right at the forefront with vibe coding and, with open source, also with a very innovative business model: where does it go from here? What are the development steps you're now taking to keep being innovative?

Alexander

We're lucky not to be that old yet. We weren't founded yesterday, but five years ago. But we now have the great opportunity to build our product, without 10, 15 years of technical debt, very close to the current challenges of the time. That's a CLI, for example. A product that had been built 15 years ago would make that very difficult now. We can actually offer various APIs and interfaces that further simplify interacting with AI applications. You could also offer a graph interface with which you can explore data much more easily with the AI.

That's of course also the medium-term vision: to build the best product for consuming and using data in the factory. And I think that's a big enough problem to solve for now — because no one has solved it yet. And out of that, lots of great business models will emerge that one could also tackle. That's always the challenge for the next few years — to do it really well.

Alexander, thank you very much. For me this was super exciting. I hope we explained all the buzzwords sufficiently too — otherwise you can surely look it up again afterward. No further questions. What would you still like to give the listeners to take away?

Alexander

If I've used so many technical terms now, I'm sorry — but you're welcome to ask me on LinkedIn what they mean. Feel free to start an outreach there. And I think getting started would of course be great now. That is, we have a large learning platform — independent of the product — that everyone is welcome to take a look at, especially what Jeremy has written there. Getting started is the next important step.

Great — with generative AI in general, that's the order of the day right now, I'd say too. So thank you very much for the exciting exchange. A very significant use case has definitely joined my list of topics that you can now do with generative AI on the shopfloor. Many thanks to the listeners for listening this far, and until next time.

Alexander

Thanks, Peter.