Werkzeuge selbst bauen

Format: Live-Abend 5 in Woche 7 · Pfade: Builder · Dauer: zwei Stunden live, dazu drei Stunden Werkstattzeit in der Woche danach

Einstieg

In fast jedem Betrieb gibt es eine Tabelle, die alle brauchen und niemand mag. Die Kalkulation fürs Angebot mit sieben Reitern, die nur eine Person versteht. Die Checkliste für die Abnahme, die auf Papier ausgefüllt und dann abgetippt wird. Die Liste der Wartungstermine, die in drei Fassungen existiert. Für so etwas gibt es selten eine passende fertige Software, und eine Programmierung von außen war bisher zu teuer.

Das hat sich geändert. Mit KI lässt sich heute aus einer Beschreibung ein kleines Programm bauen, das genau eure Aufgabe löst. Fachleute nennen das Vibe Coding: programmieren, indem man beschreibt, was man will. Das ist Stufe 5, Werkzeuge bauen.

So leicht der erste Prototyp entsteht, so wichtig ist der zweite Teil dieses Abends: Was braucht ein selbst gebautes Werkzeug, damit es in einem Jahr noch läuft, sicher ist und jemand es reparieren kann? Darauf gibt dieses Modul eine klare Antwort.

Was ihr danach könnt

• mit KI ein kleines, passgenaues Werkzeug bauen, etwa einen Rechner fürs Angebot, eine Checkliste mit Auswertung oder eine kleine Wissensdatenbank,
• beschreiben, was ein selbst gebautes Werkzeug braucht, damit es im Betrieb hält: eine Person, die es betreut, eine Anleitung und eine Sicherung,
• einschätzen, ab wann ein Eigenbau zu groß wird und eine fertige Lösung besser passt.

Inhalte

Was sich gut selbst bauen lässt

Gut geeignet sind Werkzeuge, die klein, klar umrissen und für den internen Gebrauch sind:

• Rechner: Materialbedarf, Angebotspreis aus Positionen, Zuschläge, Fahrtkosten, Schichtstunden.
• Formulare mit Auswertung: Abnahmeprotokoll, Gefährdungsbeurteilung, Wareneingangsprüfung, Hygienecheck in der Küche.
• Übersichten: Wartungstermine, Fristen, Auslastung, offene Angebote.
• Kleine Wissensdatenbanken: die 20 wichtigsten Dokumente einer Abteilung, durchsuchbar, mit Quellenangabe in jeder Antwort.

Vorsicht ist geboten bei allem, was Kundendaten speichert, Zahlungen berührt oder von außen erreichbar ist. Dort gehört eine Fachperson in die Prüfung, oder ihr greift zu einer fertigen Lösung. Welche Werkzeuge für Prototypen und Wissensdatenbanken es gibt, auch mit EU-Weg, steht auf Stufe 5 unter „Werkzeuge”.

Vom Prototyp zum Werkzeug

Ein Prototyp ist schnell gebaut, oft in einem Nachmittag. Bis ein Werkzeug im Alltag verlässlich läuft, vergehen nach unserer Erfahrung zwei bis sechs Wochen. Der Unterschied liegt in fünf Dingen:

1. Echte Fälle: Das Werkzeug ist mit Fällen aus dem Alltag getestet, auch mit den seltsamen.
2. Eine verantwortliche Person: Sie weiß, wie es funktioniert, nimmt Fehlermeldungen an und entscheidet über Änderungen.
3. Eine Anleitung: eine Seite, wie man es benutzt, und eine Seite, wie es gebaut ist.
4. Eine Sicherung: Daten und Bauplan liegen an einem zweiten Ort. Jede Änderung ist nachvollziehbar, etwa in einer Versionsverwaltung (ein Archiv, das jeden Stand festhält und zurückholbar macht).
5. Getrennte Test- und Echtumgebung: Geändert wird zuerst an einer Kopie, erst nach dem Test am echten Werkzeug.

Warum Sicherheit hier ernst ist

Zwei Fälle aus 2025 zeigen, was schiefgehen kann. In 170 von 1.645 geprüften Apps, die mit dem Baukasten Lovable entstanden waren, fehlten die Regeln, wer welche Daten sehen darf. Offen lagen Adressen und Zugangsschlüssel. Und ein Programmier-Agent von Replit löschte bei einem Nutzer trotz Änderungsstopp die Datenbank. Beides lässt sich vermeiden: mit Testdaten im Prototyp, getrennter Umgebung, Sicherungen und einer Freigabe vor jedem Eingriff in Echtdaten. Die Einzelheiten stehen auf Stufe 5 unter „Risiken”.

Messen statt schätzen

Mit KI zu bauen fühlt sich sehr schnell an. In einer Studie von METR (2025) waren erfahrene Entwickler mit KI-Werkzeugen allerdings langsamer, hielten sich aber für schneller. Für euch heißt das: Notiert, wie lange der Bau wirklich gedauert hat, und rechnet die Betreuung ehrlich mit ein. Die Formel aus Modul 5 gilt auch hier.

Ab wann ein Eigenbau zu groß wird

Ein selbst gebautes Werkzeug ist richtig, solange es klein bleibt, eine Person es versteht und euer Ablauf etwas Eigenes hat. Wechselt zu einer fertigen Lösung oder holt einen Partner, wenn eines davon zutrifft:

• Mehr als eine Handvoll Menschen hängt täglich davon ab, und ein Ausfall hält die Arbeit an.
• Es verarbeitet Kundendaten, Personaldaten oder Zahlungen.
• Die verantwortliche Person ist die einzige, die es versteht, und ihre Vertretung ist ungeklärt.
• Es gibt eine fertige Software, die 80 Prozent davon kann. Die restlichen 20 Prozent lassen sich oft mit einem kleinen Zusatz lösen.

Wie aus vielen kleinen Werkzeugen später ein System mit gemeinsamem Wissen, Standards und Prüfern wird, zeigt die Säule KI-System bauen. Modul 10 greift das auf.

Übungen am eigenen Betrieb

Übung 1: Die ungeliebte Tabelle als Werkzeug

Ziel: ein Prototyp in zwei Stunden.

1. Bringt eine Tabelle oder ein Formular mit, das oft genutzt wird und nervt. Ersetzt alle echten Daten durch Testdaten.
2. Beschreibt in einem Absatz, was das Werkzeug können soll, wer es nutzt und was am Ende herauskommt. Nutzt das Prompt-Gerüst aus Modul 1.
3. Lasst die KI einen ersten Prototyp bauen. Testet ihn mit drei Fällen und beschreibt, was fehlt oder falsch ist.
4. Arbeitet in kleinen Schritten weiter: eine Änderung, testen, die nächste Änderung.
5. Stellt den Prototyp am Ende des Abends den anderen Buildern vor.

Ergebnis: ein lauffähiger Prototyp mit Testdaten und eine Liste dessen, was noch fehlt.

Übung 2: Die Halte-Prüfung

Ziel: wissen, was der Prototyp braucht, um im Betrieb zu halten.

Geht die fünf Punkte aus „Vom Prototyp zum Werkzeug” durch und schreibt zu jedem auf, wie er bei eurem Werkzeug erfüllt wird oder was noch fehlt. Prüft danach die vier Punkte aus „Ab wann ein Eigenbau zu groß wird”. Trifft einer zu, schreibt ihr auf, welche fertige Lösung oder welcher Partner in Frage kommt.

Ergebnis: eine Seite mit eurer Entscheidung: behalten und ausbauen, professionell nachbauen lassen oder verwerfen.

Übung 3: Drei Testerinnen und Tester

In der Werkstattzeit danach geben drei Menschen aus dem Team das Werkzeug eine Woche lang in ihrem Alltag eine Chance, weiterhin mit Testdaten oder grünen Daten nach der Ampel. Sie notieren, was hilft und was stört. In der nächsten Bau-Sprechstunde wertet ihr das gemeinsam aus.

Ein Fall aus dem Mittelstand

Das Beispiel ist aus Situationen zusammengesetzt, wie sie uns in ähnlicher Form begegnen. Namen und Zahlen sind erfunden.

Ein Dachdeckerbetrieb mit 22 Beschäftigten kalkulierte jedes Angebot in einer Tabelle mit sieben Reitern, die der Juniorchef vor Jahren gebaut hatte. Nur er und eine Bürokraft konnten damit umgehen. Am Live-Abend baute der Builder des Betriebs, ein Geselle mit Freude an Technik, daraus einen Rechner: Dachfläche, Neigung, Material und Zuschläge eingeben, heraus kommt die Materialliste und ein Preisvorschlag zum Prüfen.

Die Halte-Prüfung zeigte zwei Lücken: Es gab keine Sicherung, und die Preise standen fest im Programm. Beides wurde in der Werkstattzeit gelöst, die Preise liegen jetzt in einer eigenen Liste, die das Büro pflegt. Kundendaten speichert der Rechner bewusst keine, das Angebot entsteht weiterhin in der Branchensoftware. Nach drei Wochen kalkulierten vier Menschen mit dem Rechner statt zwei.

Checkliste

• Das Werkzeug löst eine klar umrissene Aufgabe für den internen Gebrauch.
• Der Prototyp lief ausschließlich mit Testdaten oder grünen Daten.
• Eine verantwortliche Person und ihre Vertretung sind benannt.
• Es gibt eine Anleitung zur Nutzung und eine kurze Beschreibung, wie es gebaut ist.
• Daten und Bauplan sind gesichert, Änderungen sind nachvollziehbar.
• Geändert wird zuerst in einer Testumgebung.
• Die Halte-Prüfung ist gemacht und die Entscheidung aufgeschrieben.
• Bauzeit und Betreuungszeit sind notiert und in die Rechnung aus Modul 5 eingeflossen.