97,78 % Konfidenz: Ein Kassenbon-Scanner mit KI-Agenten

Mein Side-Projekt ist eine Web-App, bei der Nutzer Kassenbons fotografieren und für berechtigte Käufe Cashback erhalten. Das Feature, um das es hier geht: doppelter Foto-Upload. Ein Foto des Kassenbons, ein Foto des gekauften Produkts. Beide Pflicht. Beide werden verarbeitet. Cashback wird ausgelöst, wenn beide verifiziert sind.

Drei Phasen, eine Session, fünf kritische Bugs, eine sehr befriedigende Zahl am Ende. (Die Session, die das Backend dieses Side-Projekts finanzierte — der Million-Token-Cashback-Campaign-Build — zeigt, welche Dimensionen dabei möglich werden.)

Der dreiphasige Build

Ich habe gelernt, KI-gebaute Features in Phasen zu strukturieren statt „das Ganze auf einmal”. Jede Phase hat einen klaren Output, und du kannst ihn prüfen, bevor du weitermachst.

Phase 1: Datenbankschema. Neue Tabellen und Spalten, um zwei Bilder pro Einreichung statt einem zu speichern. Beziehungen, Constraints, Migrations-Skripte. Die KI übernahm das Schema-Design; ich reviewte die Migration.

Phase 2: Backend-API. Endpunkte aktualisiert, um zwei Dateien statt einer entgegenzunehmen. Speicher-Logik für beide Bilder. OCR-Pipeline nur an das Kassenbon-Bild geknüpft (nicht an beide — dazu gleich mehr). Konfidenz-Score in der Datenbank gespeichert.

Phase 3: Frontend-UI. Zwei Upload-Bereiche. Vorschau-Zustände für beide Bilder. Fortschritts-Feedback während des Uploads. Fehlerbehandlung, wenn ein Bild die Validierung nicht besteht. Der gesamte User-Flow von „zwei Fotos machen” bis „Cashback eingereicht”.

Jede Phase lief, bevor die nächste begann. Klingt selbstverständlich, ist es aber wert, es zu sagen: Phase 2 zu debuggen ist viel einfacher, wenn du weißt, dass Phase 1 korrekt ist.

Dann kamen die Bugs

Fünf kritische Bugs in einer Session. Jeder davon war nicht offensichtlich. Keiner wäre mit Unit-Tests auf synthetischen Daten aufgefallen.

Bug 1: Bild-Dekomprimierung (trat dreimal auf). Die Vision-API für OCR erwartet rohe Bild-Bytes. Die Upload-Pipeline komprimierte Bilder mit gzip, bevor sie gespeichert wurden. Der OCR-Aufruf bekam komprimierte Bytes — und produzierte Datenmüll.

Klingt einfach zu fixen. War es auch — aber das Problem steckte an drei verschiedenen Stellen: dem initialen Upload-Handler, dem Reprocessing-Endpunkt und dem Background-Retry-Job. Jeder Pfad hatte denselben Bug unabhängig voneinander. Der Fix landete zuerst im Upload-Handler. Dann schlug der Reprocessing-Endpunkt fehl. Dann der Retry-Job. Drei separate Fixes für logisch ein Problem.

Test-Bilder haben das nicht abgefangen, weil kleine Test-Bilder sich kaum komprimieren lassen — die komprimierten Bytes waren noch valide genug, dass die Vision-API einen Parsing-Versuch unternahm. Echte Kamerafotos in voller Auflösung, ordentlich komprimiert, schlugen komplett fehl.

Bug 2: OCR-Aggregations-Scope. Produktfotos wurden zusammen mit Kassenbon-Fotos durch die OCR-Pipeline geschickt. Das Textextraktions-Modell versuchte, Text von einem Foto einer Shampooflasche zu lesen, fand etwas und mischte es in die Kassenbon-Daten. Konfidenzwerte verschlechterten sich, und in manchen Fällen tauchte der Produktname auf der Verpackung als „Position” auf dem Kassenbon auf.

Der Fix war ein einzelner Scope-Filter — OCR läuft nur auf Kassenbon-Bildern — aber ihn zu finden erforderte, die Pipeline durchzuverfolgen, um zu verstehen, wo die Annahme „alle Bilder verarbeiten” gemacht worden war.

Bug 3: FormData-Feldreihenfolge. Das Backend erwartete zuerst das Kassenbon-Foto, dann das Produktfoto. Das Frontend konstruierte das FormData-Objekt so, dass die Reihenfolge nicht garantiert war. In den meisten Browsern mit den meisten Bildern stimmte die Reihenfolge zufällig. In mobilen Browsern mit bestimmten Bildquellen drehte sie sich um. Die Cashback-Einreichung gelang dann zwar, aber das Produktfoto wurde als Kassenbon verarbeitet und umgekehrt — hoher OCR-Konfidenzwert, null übereinstimmende Positionen.

Das ist genau die Art Bug, der QA überlebt: Er funktioniert beim Testen, weil du vom Desktop mit konsistentem Verhalten testest, und bricht bei den mobilen Nutzern, auf die es am meisten ankommt.

Bugs 4 und 5 waren Validierungs-Edge-Cases — bestimmte Kombinationen aus Bildabmessungen und Dateigröße, die einen Fehlerpfad auslösten, den das Frontend nicht behandelte, was zu stillen Fehlern ohne Nutzer-Feedback führte.

97,78 %

Nachdem alle fünf Fixes eingespielt waren, testete ich mit einem echten Kassenbon-Foto — dem knittrigen, leicht überbelichteten, schräg fotografierten Foto, das echte Nutzer einreichen.

OCR-Konfidenz: 97,78 %.

Kein Test-Bild. Kein PDF. Ein echter Kassenbon, mit dem Handy fotografiert, unter Küchenbeleuchtung. Die Textextraktion war korrekt. Die Positionen stimmten. Der Gesamtbetrag war richtig.

Diese Zahl hatte ich mir verdient.

Was in derselben Session noch passierte

Zwei weitere Dinge liefen in derselben Session — sie zeigen, wie viel eine einzelne Agentic-Session abdecken kann.

Strategische Feedback-Fragen. Die App brauchte eine Post-Cashback-Umfrage, um Einzelhandelsdaten zu erfassen. Ich wollte fünf Fragen, die statistisch verwertbare Ergebnisse liefern. Wir entwarfen sie gemeinsam: einheitliches Radio-Button-Format für alle fünf (einfacher zu aggregieren), klare Sprache, keine suggestiven Fragen. Die KI half beim Fragen-Design genauso wie beim Code — Entwurf, Review, Überarbeitung.

DSGVO-Rechtsseiten. Die App brauchte eine Datenschutzerklärung und AGB. Zwei Dinge kamen dabei auf, auf die ich ohne Nachfragen nicht gekommen wäre:

Erstens der Unterschied zwischen „Datenverarbeiter” und „Verantwortlichem” nach DSGVO. Die App ist Verantwortliche — sie entscheidet, was erfasst wird und warum. Ein Zahlungsdienstleister wäre eher ein Auftragsverarbeiter. Den falschen Begriff zu verwenden ist nicht nur ungenau — er hat rechtliche Konsequenzen für Haftung und Einwilligungsanforderungen. Wir haben den richtigen Begriff verwendet.

Zweitens die Formulierung des Datenschutz-Checkboxes. Der Text muss konkret genug sein, um die DSGVO-Einwilligungsanforderungen zu erfüllen, ohne so juristisch zu klingen, dass Nutzer drüber hinweglesen. Wir haben die Formulierung so lange überarbeitet, bis sie klar, korrekt und wirklich informativ war.

Die Erkenntnis

Echte Daten brechen Dinge, die Testdaten nicht brechen.

Kleine synthetische Bilder testen kein Komprimierungsverhalten. Desktop-Browser legen keine FormData-Reihenfolge-Bugs offen. Saubere, glatte Kassenbons zeigen keine OCR-Pipeline-Scoping-Probleme.

Die Lücke zwischen „es funktioniert” und „es funktioniert für echte Nutzer” ist der Ort, wo die interessantesten Bugs wohnen. KI baut schnell — aber schnell bedeutet auch, dass du diese Lücke schneller erreichst. Die Bugs verschwinden nicht; sie tauchen nur früher auf.

Teste so früh wie möglich mit echten Daten. Echte Kamerafotos, echtes Geräteverhalten, echte Nutzereingaben. Jede Abkürzung, die du dir dort nimmst, taucht irgendwann als Produktionsvorfall wieder auf. (Was danach kam — Rate Limiting, CORS-Härtung, Graceful Shutdown und alles andere, was die Agenten nicht von sich aus eingebaut haben — beschreibe ich in Production Hardening. Und das Backend dieser Cashback-App ist dasselbe, das in meiner ersten Million-Token-Session gebaut wurde.)