Plattenlager mit KI selbst bauen: Wo der schnelle Erfolg kippt

Mit KI lässt sich heute an einem Nachmittag eine Lagerliste oder eine kleine Plattengalerie bauen. Das funktioniert, solange eine Person sie nutzt und nichts Ungewöhnliches passiert. Im Alltag eines Steinbetriebs passiert ständig etwas Ungewöhnliches, etwa wenn zwei Verkäufer dieselbe Platte anbieten. Dort beginnen die Fehler im Programm, und jede schnelle Reparatur kann weitere Fehler erzeugen.

Der Reiz: in Stunden statt Monaten

„Vibe Coding“ nannte der KI-Forscher Andrej Karpathy im Februar 2025 das, was heute viele ausprobieren: Man beschreibt in Alltagssprache, was das Programm können soll, und die KI schreibt den Code, den man übernimmt, ohne ihn selbst zu lesen. Nach einem Nachmittag steht oft eine Tabelle mit Material, Format und Stärke, mit Foto und Filter.

Für manche Aufgaben ist das genau richtig: eine schnelle Übersicht für den Messeauftritt oder die Auswertung der Kontakte, die auf einer Messe gesammelt wurden. Sobald solche Daten in ein laufendes Projekt einfließen sollen, wird es heikel. Das Fraunhofer IESE nennt schnelles Prototyping eine Stärke und warnt zugleich davor, dass der Prototyp im finalen System landet. „Die Risiken steigen mit der Komplexität und Kritikalität der Anwendung.“ Ein Plattenlager, über das verkauft wird, ist beides.

Die Kurve: Begeisterung, Alltag, Fehler

Dann kommt der Alltag, und mit ihm Fälle, an die beim Beschreiben niemand gedacht hat:

• Eine Platte ist kein Artikel. Jede Rohplatte ist ein Einzelstück mit eigener Kontur und eigenem Veining. Eine Liste, die „Material, 20 m²“ führt, weiß nicht, welche Platte zu welcher passt.
• Blockfolgen. Für einen Bookmatch braucht es die spiegelbildlichen, aufeinanderfolgenden Platten eines Blocks, für ein ruhiges Blending Platten aus demselben Block. Geht eine davon einzeln raus, fehlt in der Fläche genau ihr Nachbar.
• Reste kommen zurück. Nach dem Zuschnitt bleibt ein Reststück mit neuer Kontur. Neuer Eintrag, Änderung oder Abzug? Die Antwort steuert Bestand, Preis und Foto.
• Platten brechen, Plätze wechseln. Eine Platte bricht beim Umlagern, eine andere steht im anderen Gestell. Im System sind beide unverändert da, und ein Angebot läuft weiter.
• Zwei Verkäufer, eine Platte. Sobald mehr als eine Person verkauft, braucht es Reservierungen, die alle sehen.
• Eins greift ins andere. Ein Ablauf, der für Bodenfliesen in Quadratmetern funktioniert, läuft nicht automatisch auch für Sockelleisten in Laufmetern. Was im Angebot stimmt, muss auch im Auftrag, im Lieferschein und auf dem Etikett stimmen.

Wie klein der Auslöser sein kann, zeigt ein Fall aus der Praxis. Ein selbstgeschriebenes Planungsprogramm lief in mehreren Einzelprojekten einwandfrei. Als die Daten mehrerer Projekte zusammengeführt wurden, stand es still. Es nummerierte Teile mit Buchstaben und lief das Alphabet durch; was nach dem Z kommt, hatte niemand festgelegt. Der Fehler war schnell behoben, hatte aber Folgen für Ausführung und Plandarstellung, die alle nachgezogen werden mussten. Das ist der typische Verlauf: Das Ergebnis kommt schnell. Die Fälle, an denen es stehen bleibt, kommen erst, wenn der Betrieb und seine Mitarbeiter das Programm wirklich nutzen.

Jeder dieser Fälle lässt sich der KI beschreiben, und sie liefert eine Lösung. Hier liegt die Falle: Die Reparatur behebt in einem oder mehreren Anläufen das sichtbare Problem und verändert dabei oft im Hintergrund Dinge, die vorher funktioniert haben. Beim Vibe Coding werden, so beschreibt es das Fraunhofer IESE, „Fehlermeldungen einfach direkt als neuer Prompt an die KI weitergegeben“. Als Risiko nennt das Institut das sinkende Systemverständnis: Der erzeugte Code ist schwer nachvollziehbar.

Ein Grund liegt in der Arbeitsweise der KI. Ein Mensch, der ein Programm über Monate aufbaut, behält, warum etwas so gelöst wurde. Die KI arbeitet mit dem, was im aktuellen Gespräch steht. Über viele Sitzungen wird der Chat gewechselt und nicht alles übergeben, oder das Gespräch wird so lang, dass frühere Teile nicht mehr zuverlässig berücksichtigt werden. Das Forschungsteam von Chroma hat 18 Sprachmodelle getestet: In allen Versuchen sank die Leistung, je länger die Eingabe wurde. Genau dort entstehen die Reparaturen, die an anderer Stelle etwas kaputt machen.

Mit jeder Reparatur wächst der Code, und weil das Verständnis für die Logik fehlt, wird er komplizierter als nötig: doppelte Abschnitte, Umwege, Schleifen in Schleifen. Einen Hinweis aus der professionellen Entwicklung gibt die Codeanalyse-Firma GitClear, die 211 Millionen geänderte Codezeilen aus den Jahren 2020 bis 2024 ausgewertet hat: Der Anteil kopierter Zeilen stieg von 8,3 auf 12,3 %, der Anteil aufgeräumter Zeilen sank von 25 % (2021) auf unter 10 % (2024). Dieses Aufräumen ist zeitintensiv, braucht Fachkenntnis und übersteigt in der Regel das, was jemand leisten will, der „das mal eben selbst baut“.

Bleibt die Sicherheit. Veracode hat Code von über 100 KI-Modellen geprüft: In 45 % der Tests enthielt er riskante Sicherheitslücken. Wie das aussieht, zeigte 2025 der KI-Baukasten Lovable: Bei 170 von 1.645 untersuchten Anwendungen, die damit gebaut waren, waren die Zugriffsrechte so lückenhaft, dass Daten wie Namen, Telefonnummern und Zahlungsdaten offenlagen. Für ein Plattenlager, das Kundenpreise und Kundendaten im Netz zeigt, wiegt das schwer.

Die Falle: Je mehr drinsteckt, desto schwerer der Ausstieg

Teuer wird ein selbstgebautes System meist erst nach dem Start, in den Wochen, in denen abends noch ein Fehler behoben wird und morgens ein neuer da ist. Diese Stunden fehlen im Verkauf und beim Aufmaß. Je mehr Zeit drinsteckt, desto schwerer fällt der Satz: „Wir hören auf und nehmen etwas Fertiges.“ In der Psychologie heißt das Sunk-Cost-Effekt: Die bereits investierte Zeit hält einen fest, auch wenn sich der nächste Schritt nicht mehr lohnt.

Dabei merkt man kaum, wie viel Zeit hineinfließt. In einer Studie der Forschungsgruppe METR bearbeiteten 16 erfahrene Entwickler echte Aufgaben in ihren eigenen großen, über Jahre gewachsenen Open-Source-Projekten, mal mit, mal ohne KI-Werkzeuge von Anfang 2025. Gemessen brauchten sie mit KI 19 % länger und glaubten danach trotzdem, 20 % schneller gewesen zu sein. Für neuere Werkzeuge halten die Autoren den Rückstand inzwischen für kleiner, nennen ihre Datenlage dafür aber selbst schwach. Bemerkenswert bleibt die Lücke zwischen Gefühl und Messung. Wenn schon Profis ihr eigenes Tempo so falsch einschätzen, wie verlässlich ist dann die Selbsteinschätzung bei jemandem, der nebenher zum ersten Mal programmiert?

Woran man merkt, dass man drinsteckt:

1. Jede Woche kommt eine Reparatur dazu, die Liste der offenen Fehler wird nicht kürzer.
2. Fragen zum Programm landen immer beim selben Kollegen, und wenn er im Urlaub ist, wartet der Betrieb.
3. Nach einer Änderung prüft niemand das System in alle Richtungen durch, also Angebot, Lieferschein und Etikett. Ob etwas kaputtgegangen ist, zeigt erst der Alltag.
4. Niemand hat bisher die Stunden zusammengezählt, die in das eigene Programm geflossen sind und weiter fließen.

Trifft mehr als ein Punkt zu, lohnt sich eine ehrliche Rechnung mit drei Zahlen: die Stunden, die das Selbstbauen jeden Monat kostet (zwei Wochen mitschreiben genügt), der Monatspreis einer professionellen Lösung und die Zeit, die das Team mit ihr im Verkauf und im Lager spart, am besten im Test am eigenen Bestand gemessen.

Was noch kommt: der digitale Produktpass

Die neue europäische Bauproduktenverordnung (EU) 2024/3110 gilt seit dem 8. Januar 2026 und bringt den digitalen Produktpass für Bauprodukte. Pflicht wird er laut Deutschem Institut für Bautechnik, sobald die EU-Kommission den jeweiligen Rechtsakt erlassen hat, nach 18 Monaten Übergangsfrist. Welche Produkte und welche Daten er umfasst, legt dieser Rechtsakt fest. Absehbar ist, dass Produktdaten digital und in festgelegter Form bereitstehen müssen. Eine selbstgebaute Lösung steht dann vor einem Umbau, den jeder Betrieb für sich allein stemmt. Ein Anbieter, der viele Betriebe bedient, muss ihn einmal für alle lösen.

Was für das eigene Bauen spricht

Fair ist auch die Gegenseite. Eine fertige Lösung kostet jeden Monat Geld, solange sie läuft. Man hängt an einem Anbieter und dessen Planung, eigene Wünsche stehen dort neben denen anderer Kunden. Und vor dem Einstieg gehört die Frage geklärt, wie die eigenen Daten wieder herauskommen, falls man wechselt. Wer diese Punkte höher gewichtet und die Zeit zum Pflegen hat, kann mit gutem Grund selbst bauen, am ehesten dort, wo keine Kundendaten im Spiel sind.

Was in einer gewachsenen Lösung steckt

Fehlerfrei ist auch eine gekaufte Lösung nicht. Der Unterschied liegt darin, wer die Fehler findet und behebt. Auf einer Plattform arbeiten jeden Tag Mitarbeiter aus vielen Betrieben. So werden die Abläufe im echten Betrieb getestet, Fehlermeldungen laufen beim Anbieter auf und werden behoben, und zwar für alle Kunden gleichzeitig. Davon lebt der Anbieter, also hat er allen Grund, schnell zu sein. Viele Kinderkrankheiten, die ein eigenes Programm noch vor sich hat, sind dort schon auskuriert.

In eine Plattform fließt das Wissen vieler Betriebe ein. Wer für viele Steinbetriebe baut, schaut sich die Abläufe genau an und fragt, wie sie sich grundsätzlich beschleunigen lassen. Für einen einzelnen Betrieb ergibt es wenig Sinn, diese Arbeit allein zu wiederholen. Wichtig ist, dass sich die Lösung flexibel einstellen lässt, damit auch ein kleiner Betrieb seine Abläufe darin wiederfindet. Bei DDL, seit 2020 bei Steinbetrieben im Einsatz, ist jede Platte als Einzelstück mit Foto, Maß und Block geführt, Reste gehen als neue Platten zurück ins Lager, und wer eine reservierte Platte anbietet, bekommt eine Warnung.