Jede Woche ein Blick in die Werkstatt.

KW 35 · 2026

Wer prüft die Prüfung?

24. August 2026 · Lesezeit 5 Minuten

Eine Software mit 2 100 automatischen Prüfungen klingt beruhigend. Diese Woche haben wir die naheliegende Frage gestellt — und die Antwort war unbequem: Fünf von acht neu geschriebenen Prüfungen prüften nichts. Sie waren grün, und sie wären grün geblieben, wenn wir die Regel dahinter abgeschaltet hätten.

Wie man eine Prüfung prüft

Das Verfahren heißt Mutationsprüfung, und es ist so schlicht wie unangenehm: Man baut absichtlich einen Fehler ein und sieht nach, ob eine Prüfung rot wird. Wird sie es nicht, ist die Regel nicht geprüft — sie ist nur vorhanden.

Wir tun das inzwischen mit 155 Regeln. Für jede wird der Quelltext an genau einer Stelle verfälscht, der gesamte Prüfstand läuft durch, und danach wird die Verfälschung zurückgenommen. Ein Durchgang dauert rund anderthalb Stunden.

Der lehrreichste Fund

In unserer Buchungsstrecke steht der Satz: Eine Ablehnung braucht einen Grund. Die Prüfung dazu war grün. Die Mutationsprüfung schaltete die Regel ab — und die Prüfung blieb grün.

Der Grund: Die Pflicht stand zweimal im Code. An zwei Stellen, die dasselbe verlangten. Schaltet man die eine ab, fängt die andere es auf — und niemand merkt, dass die Hälfte der Absicherung weg ist.

Zwei Wächter für dieselbe Frage sind nicht doppelte Sicherheit. Sie sind die Garantie, dass der Ausfall des einen unbemerkt bleibt.

Der teuerste Fund

Beim Anlegen einer neuen Tabelle fiel eine Spalte auf, in der ein Preis stehen soll. Auf dem Server war sie so angelegt, dass sie Werte bis 127 aufnimmt — in Cent gerechnet also 1,27 €.

Ein Preis von 79 € wäre nicht falsch gerundet, sondern abgewiesen worden. Betroffen waren vier Felder, drei davon im Preiskatalog.

Und jetzt der Teil, über den wir länger nachgedacht haben: Warum ist das niemandem aufgefallen? Weil der Preiskatalog leer ist — die Preisentscheidung steht noch aus. Es gab schlicht noch keinen Preis, der hätte scheitern können.

Ein Fehler, den eine offene Entscheidung verdeckt, ist keine Sicherheit. Er ist ein Fehler, dessen Termin jemand anderes bestimmt.

Das Muster dahinter

Sechs Befunde in drei Tagen, und alle gehören zur selben Familie: Etwas meldet Erfolg für Arbeit, die es nicht getan hat.

• Eine Prüfung war grün und prüfte nichts.
• Ein Hilfsskript meldete „erledigt" und hatte nichts geändert.
• Ein abgebrochener Prüflauf hinterließ Schaden und keine Spur.
• Ein Aufräumer meldete „wiederhergestellt" und löschte dabei.
• Eine Bestandsaufnahme verlor Einträge und meldete „alles bestätigt".
• Fehlermeldungen wurden geschrieben, berechnet — und verworfen.

Keiner davon war ein Fehler im Erzeugnis. Alle saßen in den Prüfmitteln. Der Satz, den wir daraus mitnehmen: Unsere Werkzeuge prüfen die Anwendung gründlich und sich selbst zu wenig.

Was jetzt anders ist

Drei neue Kontrollen, und alle folgen derselben Regel: Ein Werkzeug, das nichts angesehen hat, darf nicht „in Ordnung" melden.

• Ein Wächter sieht nach jedem Lauf nach, ob eine absichtliche Verfälschung im Quelltext stehen geblieben ist — und repariert nichts von selbst. Ein Werkzeug, das auf Verdacht zurückschreibt, hat einen der Fehler oben verursacht.
• Die Bestandsaufnahme bricht ab, wenn sie schrumpft, statt eine zu kleine Zahl auszuweisen.
• Die Auslieferung meldet Spalten, die auf dem Server stehen und nicht im Datenmodell. Ein Server, der mehr hat als seine Beschreibung, lässt sich nicht mehr beschreiben.

Warum wir das aufschreiben

Weil die Alternative wäre, es nicht zu tun. Eine Zahl wie „2 100 Prüfungen" sagt nichts darüber, ob es die richtigen sind — das sagt nur der Versuch, sie zu widerlegen. Und der ist diese Woche fünfmal von acht gelungen.

Stand heute: 2 114 fachliche Prüfungen, 384 über die Weboberfläche, 155 von 155 Regeln nachweislich geprüft und zwanzig Wächter, die bei jedem Lauf mitlaufen. Nächste Woche kann diese Liste wieder anders aussehen — das ist der Sinn der Sache.

KW 34 · 2026

Gesucht: Betriebe, die uns widersprechen

22. August 2026 · Lesezeit 4 Minuten

Wir suchen Sicherheitsdienstleister und Detekteien, die PEWELI AI in ihrem eigenen Betrieb erproben — und uns sagen, was daran nicht taugt. Dafür gibt es bis zu zwölf Monate kostenfreien Zugang.

Das ist kein Geschenk und keine Verkaufsaktion. Es ist ein Tausch: Sie bekommen die Anwendung, wir bekommen das, was uns am meisten fehlt — Widerspruch aus dem laufenden Betrieb. Eine Software für die Sicherheitsbranche, die nur ihre Erbauer kennen, ist eine Vermutung.

Wie die zwölf Monate zustande kommen

Wer nichts meldet, bekommt drei Monate. Wer mitarbeitet, bis zu zwölf. Die Staffel ist absichtlich schlicht, damit sie niemand nachrechnen muss:

• 3 Monate — für alle, die aufgenommen werden. Ohne Bedingung.
• +3 Monate — für regelmäßige Rückmeldung: einmal im Monat ein kurzer Bericht, was gut lief und was nicht.
• +3 Monate — für gemeldete Fehler oder Änderungswünsche, die wir umsetzen. Nicht für die Menge der Meldungen, sondern für das, was daraus wird.
• +3 Monate — für ein ausführliches Gespräch über den Einsatz im Alltag, aus dem wir zitieren dürfen.

Rückwärts geht es nicht. Wer aufhört, sich zu melden, verliert keine bereits erreichten Monate — es kommen nur keine weiteren dazu.

Was Sie bekommen — und was heute noch nicht

Das gehört an diese Stelle und nicht ins Kleingedruckte: Ein Teil der Anwendung läuft noch nicht, und zwar nicht, weil er fehlt, sondern weil er auf eine Rechtsauskunft wartet.

Verfügbar sind Einsatzplanung und Dienstplan, Zeiterfassung (auch ohne Netz), Arbeitszeit mit Urlaub und Abwesenheit, Prüfung und Abrechnung, Leistungsnachweise und Berichte, Verträge, Kunden und Objekte sowie die Sicherheitstechnik mit Wartung und Störungen.

Noch nicht verfügbar sind Fallakte, Anzeigenunterlage, Beweismittel und die Observation mit echten Zielpersonen. Diese Bereiche sind gebaut und geprüft — sie sind gesperrt, bis eine Rechtsberatung geklärt hat, was dabei zulässig ist. Wir schalten sie frei, wenn die Antworten vorliegen, und nicht vorher.

Wir sagen Ihnen das vor Ihrer Bewerbung, weil Sie es sonst nach der ersten Woche selbst merken würden.

Was wir von Ihnen brauchen

• Einen echten Betrieb — keine Testumgebung. Was im Alltag stört, zeigt sich nur im Alltag.
• Eine Person, die ansprechbar ist. Nicht täglich, aber verlässlich.
• Ehrlichkeit statt Höflichkeit. „Ganz nett" hilft uns nicht. „Das dauert drei Klicks zu lang, und deshalb macht es keiner" hilft.

Was wir nicht tun

• Keine stille Verlängerung. Nach den freien Monaten endet der Zugang. Wenn Sie weitermachen wollen, entscheiden Sie das ausdrücklich — nichts läuft von selbst in einen Vertrag.
• Keine Nutzung Ihrer Daten für uns. Ihre Einsätze, Kunden und Beschäftigten gehören Ihnen. Wir werten sie nicht aus, und kein Sprachmodell verarbeitet sie.
• Keine Werbung mit Ihrem Namen, solange Sie es nicht ausdrücklich erlauben.

So bewerben Sie sich

Eine E-Mail genügt. Schreiben Sie uns, was Sie tun — Warensicherung, Revierdienst, Ermittlung —, wie viele Personen im Einsatz sind und woran es heute am meisten hakt. Der letzte Punkt ist der wichtigste; daran erkennen wir, ob wir Ihnen überhaupt helfen können.

Wir melden uns zurück — auch dann, wenn wir absagen, und mit Begründung.

Als BETA-Tester bewerben Recht und Datenschutz

Die Aufnahme erfolgt in Stufen und in der Reihenfolge des Eingangs. Ein Anspruch auf Teilnahme besteht nicht. Zugang für fremde Betriebe setzt den Abschluss eines Vertrages zur Auftragsverarbeitung voraus — bis dahin sammeln wir Bewerbungen und melden uns, sobald es losgeht.

KW 34 · 2026

Woher wissen Sie, dass Ihre Daten nicht beim Nachbarn landen?

17. August 2026 · Lesezeit 4 Minuten

Es ist die Frage, die jeder stellt, der eine Software mietet statt sie zu kaufen: Auf demselben Server arbeiten andere Betriebe. Was hindert die Anwendung daran, mir deren Daten zu zeigen — oder meine ihnen?

Die übliche Antwort lautet: „Die Daten sind natürlich getrennt." Das ist keine Antwort, das ist eine Zusage. Diese Woche haben wir aus der Zusage eine Prüfung gemacht — und die hat sofort etwas gefunden.

Warum der Fehler so schwer zu bemerken ist

Jeder Datensatz in unserer Anwendung — jeder Vorfall, jede Person, jedes Lichtbild — trägt die Kennung des Unternehmens, dem er gehört. Bei jeder Abfrage muss danach gefiltert werden. Vergisst ein Entwickler diesen Filter an einer einzigen Stelle, sieht ein Betrieb die Daten eines anderen.

Der Haken: Solange nur ein Betrieb arbeitet, verhält sich die Anwendung mit und ohne Filter völlig gleich. Es gibt keine Fehlermeldung, nichts sieht falsch aus, jeder Test läuft grün. Der Fehler zeigt sich erst, wenn der zweite Kunde dazukommt — und dann ist es zu spät, denn dann hat jemand etwas gesehen, das ihn nichts angeht.

Was wir gebaut haben

Eine Kontrolle, die jede einzelne Abfrage ansieht, bevor sie an die Datenbank geht. Berührt sie eine der 33 unternehmensgebundenen Tabellen, ohne die Unternehmenskennung zu erwähnen, ist das ein Befund — in der Entwicklung ein sofortiger Abbruch, im laufenden Betrieb ein Eintrag im Fehlerprotokoll.

Die Liste dieser Tabellen wird dabei aus dem Datenmodell abgeleitet, nicht von Hand gepflegt. Eine Liste, die man beim nächsten Modul nachtragen muss, ist eine Liste, die man irgendwann vergisst.

Der erste Lauf

Beim Scharfschalten fielen zunächst 60 von 88 Prüfungen. Das sah schlimmer aus, als es war: Der weit überwiegende Teil waren berechtigte Ausnahmen im Anmeldeweg — dort wird ja überhaupt erst ermittelt, zu welchem Unternehmen jemand gehört. Danach zu filtern, bevor man es weiß, ist unmöglich.

Diese Ausnahmen sind jetzt einzeln benannt, jede mit Begründung, und sie werden gezählt: vier je Durchlauf. Eine Zahl, die klein bleiben soll und die auffällt, wenn sie wächst.

Zwei Funde blieben übrig, und einer war echt — in Code, den wir am selben Tag geschrieben hatten. Eine Abfrage las die Teilnehmer eines Termins ohne den Filter. Falsch war sie nicht: Die Kennungen stammten aus einer Abfrage zehn Zeilen weiter oben, die korrekt gefiltert hatte. Aber damit lag die Sicherheit in einer anderen Abfrage — wer die obere später ändert, hebt hier eine Grenze auf, ohne es zu merken.

Was das nicht leistet

Das gehört dazu, sonst wäre der ganze Text eine Werbebotschaft. Die Kontrolle erkennt einen vergessenen Filter, nicht einen falschen. Und sie ersetzt keine Trennung auf Ebene der Datenbank selbst — wer die Datenbank in der Hand hält, kommt an alles. Ob wir zusätzlich dorthin gehen, ist eine offene Entscheidung.

Was sich geändert hat, ist trotzdem wesentlich: Vorher war die Trennung eine Zusage. Jetzt ist sie eine Prüfung, die bei jedem Testlauf mitläuft — und die beim ersten Scharfschalten sofort einen echten Fund geliefert hat. Das ist die Art von Antwort, die wir auf die Frage oben geben wollen.

KW 33 · 2026

Die Stechuhr, die nicht am Tor hängt

16. August 2026 · Lesezeit 3 Minuten

Diese Woche ist der Kern unserer Anwendung in Betrieb gegangen. Kein Prototyp mehr, kein Klickmodell — eine laufende Software, mit der man arbeiten kann. Ein guter Anlass, über eine Frage zu schreiben, die einfacher klingt, als sie ist: Woher weiß der Auftraggeber, dass jemand da war?

Das Problem mit dem Nachweis

In der Warensicherung arbeitet man nicht im eigenen Haus. Man ist im Markt des Kunden, oft allein, oft an wechselnden Standorten. Am Monatsende steht eine Rechnung, und daneben gehört ein Nachweis: Wer war wann wie lange vor Ort? Bisher entsteht der in vielen Betrieben aus einem handschriftlichen Zettel, der abends abgetippt wird.

Das ist nicht nur mühsam. Es ist auch schwer zu belegen. Wenn drei Wochen später jemand nachfragt, steht Aussage gegen Aussage.

Wie wir es gelöst haben

Der Mitarbeiter meldet sich am Objekt auf dem Handy an und am Ende wieder ab. Dabei hält die Anwendung fest, wann das war und wo — und rechnet aus, wie weit die Position vom Objekt entfernt lag. Am Monatsende entsteht daraus der Leistungsnachweis von selbst. Der Marktverantwortliche unterschreibt direkt auf dem Gerät.

Klingt naheliegend. Die interessanten Entscheidungen stecken in den Einzelheiten.

Die zweite Entscheidung betrifft die Namen. Auf dem Leistungsnachweis, den der Kunde bekommt, steht die Personalnummer — nicht der Klarname. Der Auftraggeber muss wissen, dass jemand da war und wie lange. Wer genau, geht ihn nichts an. Das ist keine Förmlichkeit, sondern schlicht der richtige Umgang mit den Daten der eigenen Leute.

Und die Unterschrift?

Sie wird nicht als Foto gespeichert, sondern als Strichzug — also als der Weg, den der Finger genommen hat. Das hat zwei Vorteile: Sie bleibt im Ausdruck in jeder Größe sauber, und sie lässt sich nicht so einfach aus einem anderen Blatt herüberkopieren.

Was wir bewusst noch nicht gebaut haben

Der eigentliche Kern unseres Fachs — die Fallakte zum einzelnen Vorfall mit Beteiligten, Diebesgut und Beweismitteln — ist noch nicht umgesetzt. Nicht aus Zeitmangel, sondern aus Reihenfolge: Dabei geht es um Daten über Tatvorwürfe, und dafür holen wir zuerst die rechtliche Prüfung ein.

Ein System für solche Daten wird nicht erst gebaut und danach geprüft. Das kostet uns Wochen — und erspart uns vermutlich Jahre.

Nächste Woche: warum ein Betrieb mit drei Niederlassungen andere Software braucht als einer mit einer — und was das mit Sichtbarkeit zu tun hat.