Peakboard Insights

Industrielles Vibe Coding: Was generische KI-App-Baukästen am Shopfloor übersehen

Eine Shopfloor-App lässt sich heute per Prompt bauen – aber hält sie im Schichtbetrieb, am Werksnetz und über Jahre? Warum Peakboards industrielles Vibe Coding genau dort trägt, wo eine generische KI-Web-App aufgibt.

15.06.2026

·

7 Min. Lesezeit

Mitarbeiter analysiert Produktionsdaten auf einer digitalen Shopfloor-Management-Anwendung mit Echtzeit-Kennzahlen, Maschinenstatus und Leistungsanalysen in einer Smart Factory.
Das Wichtigste in Kürze
  • Die Frage ist nicht, ob KI eine App bauen kann, sondern ob sie im Schichtbetrieb, am Werksnetz und über Jahre trägt.
  • Industrieprotokolle (OPC UA, S7, Modbus, SAP RFC, MQTT) und Hardware am Arbeitsplatz sind in Peakboard eingebaut – generische Tools brauchen fragile Zwischenschichten.
  • On-Premises, Dauerbetrieb und ein wartbares Projekt statt Cloud-Zwang, Browser-Lebenszyklus und Black Box.
  • Eine Lizenz statt Rechnung pro App – planbare Kosten und ein Artefakt, das die IT kennt.

Per Prompt entsteht heute in Minuten eine lauffähige App – ganz ohne Programmierung. Für Marketing-Seiten und interne Tools ist das großartig. Für die Produktionslinie stellt sich aber eine andere Frage: nicht „kann KI das bauen?", sondern „hält das Ergebnis im Schichtbetrieb, am Werksnetz und über Jahre?". Genau hier trennt sich ein generischer KI-Web-App-Generator von Peakboards industriellem Vibe Coding – und der Unterschied entscheidet, ob aus dem schnellen Prototyp ein verlässlicher Baustein deiner Fertigung wird oder ein Wartungsfall.

Die Entscheidung ist nicht „KI ja oder nein"

Werkzeuge wie v0, Lovable, Bolt oder Claude Code sind beeindruckend – und ja: Auch in Peakboard beschreibst du per Prompt, was du brauchst, und bekommst ein fertiges Projekt. KI-gestütztes Bauen ist also kein Gegensatz zu Peakboard, sondern längst Teil davon. Die eigentliche Frage ist nicht, ob KI eine App erzeugen kann, sondern ob du dafür einen Allzweck-Generator nimmst, der für Websites gedacht ist – oder ein Werkzeug, das für die Halle gebaut wurde. An acht Stellen macht das im Betrieb den Unterschied.

Daten: Die Fertigung spricht kein HTTP

Der Nutzen: Deine Daten landen ohne fragile Zwischenschicht auf dem Screen – und bleiben verbunden, auch wenn die Anlage neu startet.

Bittet man eine generische KI um ein Dashboard, greift sie zu dem, was sie kennt: einen HTTP-Endpoint, der sauberes JSON liefert. Dieses Muster sitzt so tief, dass fast jeder Daten-Prompt als fetch()-Aufruf gegen ein frei erfundenes Schema endet. Die Produktion funktioniert anders: Eine SPS liefert Binärwerte aus konkreten Datenbausteinen über OPC UA, S7 oder Modbus und erwartet eine dauerhafte Session mit Subscriptions statt Polling. SAP kommt mit RFC und verschachtelten Tabellen, ein MQTT-Broker mit QoS-Stufen, Retained Messages und Last-Will – nichts davon passt in das Request-Response-Schema, das Web-Tooling voraussetzt. Lässt man einen Allzweck-Generator das verdrahten, entsteht Middleware, die in der Demo läuft und beim ersten Steuerungs-Neustart kommentarlos stehenbleibt – ausgerechnet dort, wo niemand an der Linie sie debuggen kann. Peakboard bringt OPC UA, MQTT, SAP RFC, S7, Modbus, SQL und viele weitere Datenanbindungen als Produktbestandteil mit, inklusive Session-Verwaltung, Reconnect und Typ-Mapping. Die KI verknüpft vorhandene Tags, statt SDK-Code zusammenzukleben.

Hardware am Arbeitsplatz statt Browser-Akrobatik

Der Nutzen: Scanner, Drucker und Taster funktionieren sofort – ohne Bastellösung, die beim nächsten Update bricht.

Eine Peakboard-Anwendung läuft direkt am Arbeitsplatz – auf der Box an der Linie oder dem Tablet in der Hand. Weil sie lokal ausgeführt wird, erreicht sie die Geräte, die ohnehin dort stehen: Scanner, RFID- und NFC-Leser, Fußschalter, Taster, Andon-Leuchten, Etikettendrucker, die Tablet-Kamera. Gerät als Datenquelle hinzufügen, auf den Screen ziehen, fertig. Eine generierte Web-App käme an einen Teil davon höchstens über WebUSB, WebHID oder WebSerial heran – mit Browser-Versions-Macken, Berechtigungsdialogen pro Profil, Geräten ganz ohne Web-API und Treibern, die das nächste Kiosk-Update zerlegt. Der übliche Ausweg ist ein nativer Hilfsdienst, mit dem die Web-App über einen lokalen Socket spricht – also genau das zusätzliche bewegliche Teil, das Vibe Coding eigentlich abschaffen sollte.

Dauerbetrieb statt Tab-Lebenszyklus

Der Nutzen: Der Screen an der Linie läuft monatelang durch und zeigt auch nach einem Netz-Hänger sofort wieder Daten.

Ein Peakboard-Projekt läuft auf einer Runtime, die niemand schließt: Die Peakboard Box startet direkt in die Anwendung, rendert im Vollbild ohne Browser-Rahmen, fängt Fehler selbst ab und läuft über Monate. Fällt das Netz kurz aus – und in der Halle passiert das –, bleibt der letzte Stand auf dem Schirm und die Verbindung kommt von allein zurück. Eine vibe-gecodete Web-App erbt dagegen den ganzen Browser-Lebenszyklus: Updates, Erweiterungen, Speicherlecks, der versehentliche Reload mitten in der Schicht, der Lade-Spinner, wenn das Cloud-Backend kurz nicht erreichbar ist. Für die Kollegin, die zweimal am Tag am Laptop reinschaut, reicht das völlig. Für den Bildschirm an der Laderampe, der um 6 Uhr nach einem Stromausfall sofort wieder lesbar sein muss, ist es das falsche Modell.

Die Produktion bleibt on-prem

Der Nutzen: Deine Maschinendaten verlassen das Werk nicht – und die Lösung kommt durch jedes Security-Review.

Der bequeme Pfad generischer Tools endet in der Public Cloud: öffentliche Datenbank, öffentliche URL, im Zweifel sogar die Entwicklungsumgebung im Netz. In vielen Werken ist das von vornherein raus – Cloud-Kontakt aus der Produktion ist entweder unerwünscht oder nur über streng auditierte Gateways erlaubt, durch die eine komplett cloud-gehostete Vibe-Umgebung nicht durchkommt. Peakboard läuft on-prem auf der Box, spricht die lokale SPS über OPC UA im lokalen Netz an und greift nur nach außen, wenn das Projekt es ausdrücklich vorsieht. Auch das Prompten selbst passiert im lokalen Designer, gegen das lokale Projekt. Nichts verlässt das Werk, außer ihr entscheidet euch bewusst dafür.

Kein Stack, den die IT pflegen muss

Der Nutzen: Ein bekanntes Artefakt pro Box statt eines zweiten Vollzeitjobs für die IT – pro Bildschirm.

Wenn die Vibe-Coding-Session vorbei ist, steht beim generischen Werkzeug nicht nur eine App, sondern ein ganzer Stack: eine Node- oder Next.js-Runtime, eine von der KI erfundene Datenbank, Hosting, ein SSL-Zertifikat, eine Auth-Schicht, Secrets zum Rotieren, eine CI-Pipeline und ein npm-Abhängigkeitsbaum, der alle paar Wochen Patches verlangt – und das pro Screen. Für eine einzelne Marketing-Seite mit kleinem Ops-Team ist das vertretbar. Für eine Flotte von Industrie-Anwendungen, mit der die Werks-IT leben muss, ist es ein zweiter Vollzeitjob. Peakboard ist eine einzige Anwendung auf der Box: Updates übernimmt Peakboard, die Konnektoren sind Teil des Produkts, es gibt keine eigene Datenbank zum Sichern, kein Zertifikat pro App, keine Node-Version zum Nachziehen. Die IT bekommt ein bekanntes Artefakt zu verwalten – egal, wie viele Linien, Terminals oder Dashboards die Teams in die Welt prompten.

Kein Black Box – wartbar über Jahre

Der Nutzen: Dein Team entwickelt die Anwendung weiter – auch lange nach dem ersten Prompt und nach einem Personalwechsel.

Was bei generischen Tools am Ende herauskommt, sieht man erst, wenn man nicht mehr auf die hübsche Vorschau schaut: ein Haufen generierter React-Komponenten, zusammengewürfeltes State-Management, von Hand gestrickte API-Routen und ein spontan erfundenes Datenbankschema. Für eine Wegwerf-Demo ist das in Ordnung. Für eine Anwendung, die vier Jahre eine Linie steuert, ist es ein Pflegefall – ändern kann das oft nur, wer den ursprünglichen Prompt geschrieben hat, weil der Kontext in der Prompt-Historie steckt und nicht im Code. Industrie-Anwendungen können sich das nicht leisten: Sie werden von wechselnden Leuten angefasst, überstehen Personalwechsel und ändern sich mit der Linie. Bei Peakboard ist das Ergebnis ein ganz normales Peakboard-Projekt – jede Variable, jeder Screen, jede Datenquelle, jedes Skript identisch zu dem, was jemand von Hand gebaut hätte. Zwischen KI-generiert und manuell zu wechseln ist ein Nicht-Ereignis: Feature prompten, Screen öffnen, im Peakboard Designer nachjustieren, bei Bedarf ein Skript selbst schreiben, dann die nächste Änderung ansagen.

Eine Lizenz statt Rechnung pro App

Der Nutzen: Planbare Kosten – ein zusätzlicher Screen löst keine neue monatliche Rechnung aus.

Die Kosten generischer Tools zeigen sich meist ein paar Monate nach der Demo. Jede App braucht Hosting, die Datenbank muss irgendwo liegen, der KI-Dienst rechnet API-Aufrufe ab, der Auth-Anbieter kassiert pro aktivem Nutzer, Monitoring ist ein eigener Posten – und die Summe wächst mit jeder Linie, jedem Screen, jedem Werk. Peakboard läuft unter einer Lizenz, die du ohnehin hast; Konnektoren, Designer, Runtime und KI-Unterstützung sind eingeschlossen. Der zweite OEE-Screen an derselben Linie, das dritte Terminal nebenan, das vierte Board fürs Morgenmeeting lösen keine neue monatliche Rechnung aus. Bei fünfzig Bildschirmen über drei Werke ist der Unterschied zwischen fester Lizenz und Cloud-Abo pro App schnell kein Rundungsfehler mehr.

Fazit

Generische Generatoren sind brillant für das, wofür sie gedacht sind: kurzlebige Apps im Browser-Tab. Die Fertigung stellt andere Fragen – an Daten, Geräte, Dauerbetrieb, Datenhoheit, Wartbarkeit und Kosten. Peakboards Vibe Coding ist genau auf diese Fragen gebaut: Du behältst das Tempo der KI, bekommst aber ein Ergebnis, das im Schichtbetrieb trägt, im Werksnetz bleibt und sich auch in vier Jahren noch anfassen lässt. KI ersetzt Peakboard also nicht – sie macht Peakboard schneller.

KI in der Fertigung

Industrielles Vibe Coding live erleben

Sieh dir an, wie aus einem Prompt ein lauffähiges Peakboard-Projekt wird – lokal an der Linie.

Kann ich Shopfloor-Apps einfach per KI prompten?

Technisch ja, aber eine generische Web-App läuft im Browser-Tab und passt schlecht zur Fertigung. Peakboard läuft lokal an der Linie, bindet Produktionsprotokolle direkt an und bleibt wartbar.

Spricht eine generische KI-App OPC UA oder SAP?

Meist nur über selbstgebaute Middleware, die beim ersten SPS-Neustart verstummt. Peakboard bringt OPC UA, S7, Modbus, MQTT, SAP und SQL als Teil des Produkts mit.

Nutzt Peakboard selbst KI?

Ja. Du beschreibst per Prompt, was du brauchst, und bekommst ein normales Peakboard-Projekt, das dein Team im Designer weiterbearbeiten kann.

Teile diesen Artikel:
Peakboard Favicon
Author: Peakboard Redaktion

Die Peakboard Redaktion schreibt über Digitalisierung, Datenvisualisierung und Prozessoptimierung in Industrie und Logistik. Der Fokus liegt auf praxisnahen Lösungen, aktuellen Entwicklungen und verständlich aufbereitetem Fachwissen.

Schneebedeckter Berg mit orangefarbener Markierung entlang des Gipfels.
Schwarz-weiß-Bild von schneebedeckten Bergen in einem Tal.
Weiße Wolken vor schwarzem Hintergrund, die in horizontalen Linien verlaufen.
Weiße Wolken vor schwarzem Hintergrund, die in horizontalen Linien verlaufen.