2026 – und wir stolpern immer noch über dieselben Programmierfehler wie 1990
Die IT redet über KI-Agenten, Cloud, Kubernetes, Microservices und automatisierte Deployments. Gleichzeitig scheitern produktive Systeme noch immer an Dingen, die seit Jahrzehnten bekannt sind: Datum, Uhrzeit, Dezimaltrennzeichen, Zeichencodierung, Rechteprüfung, Dateipfade, Imports, Caches und kaputte Schnittstellen.
Das ist der eigentliche Witz der modernen Softwareentwicklung: Die Werkzeuge werden immer mächtiger, aber die alten Fehler verschwinden nicht.
Die alten Fehler sind nicht verschwunden
01/02/2026 ist entweder der 1. Februar oder der 2. Januar. Deutschland schreibt 1.234,56, viele technische Systeme erwarten 1234.56, Excel macht daraus bei Gelegenheit etwas Drittes. Umlaute zerfallen zu Zeichensalat. null, "", 0, "0" und false werden vermischt. CSV-Dateien zerstören führende Nullen. APIs liefern null, obwohl das Frontend einen String erwartet. Caches geben Daten des falschen Mandanten aus. Worker laufen nach dem Deployment mit altem Code weiter.
Das klingt banal. Genau deshalb ist es gefährlich.
Diese Fehler sind keine exotischen Spezialfälle. Sie sitzen an den Grenzflächen: zwischen Ländern, Formaten, Systemen, Datenbanken, Frontends, Backends, Benutzern, Importen, Exporten und externen Diensten.
Und dort entstehen die meisten Produktionsprobleme.
KI-Agenten machen das nicht automatisch besser
Jetzt kommt die nächste Illusion: KI-Agenten schreiben Code, also verschwinden diese Fehler.
Nein.
KI-Agenten können solche Fehler sogar schneller produzieren. Ein Coding-Agent baut plausiblen Code. Aber plausibel ist nicht automatisch korrekt, sicher oder produktionsreif.
Er prüft nicht von selbst, ob Geldbeträge als Float gespeichert werden.
Er erkennt nicht zwingend, ob ein Cache-Key den Mandantenkontext vergisst.
Er weiß nicht automatisch, ob ein Retry doppelte Zahlungen auslösen kann.
Er sieht nicht immer, ob ein Datum locale-abhängig interpretiert wird.
Deshalb reicht ein Prompt wie „prüfe den Code“ nicht.
Das ist zu schwach.
Die Lösung: Coding-Agenten gezielt auf alte Fehler ansetzen
Die alten Fehler müssen explizit geprüft werden. Nicht allgemein, nicht vage, nicht nach Bauchgefühl.
Ein Coding-Agent braucht einen klaren Prüfauftrag:
- Welche Problemfelder soll er untersuchen?
- Was gilt als echtes Risiko?
- Wie soll er Funde bewerten?
- Was soll er ignorieren?
- Was darf er ändern?
- Was muss er zunächst nur berichten?
Genau dafür eignet sich ein systematischer Prüfprompt. Er zwingt den Agenten, nicht nur „schönen Code“ zu betrachten, sondern Produktionsrisiken: Datum, Geld, Encoding, Rechte, Mandantenfähigkeit, Race Conditions, Caching, Deployment, Schnittstellen, Fehlerbehandlung und Datenmodellierung.
Mein Prüfprompt für Coding-Agenten
Der folgende Prompt ist dafür gedacht, ein bestehendes Projekt systematisch auf typische, wiederkehrende IT-Fehlerquellen prüfen zu lassen.
Rolle:
Du bist ein Senior Software Architect, Security Reviewer und Production Readiness Engineer.
Ziel:
Prüfe dieses Projekt systematisch auf typische, wiederkehrende IT-Fehlerquellen. Es geht nicht um kosmetische Verbesserungen, sondern um reale Produktionsrisiken, Datenfehler, Sicherheitslücken, Wartungsprobleme und Integrationsfehler.
Arbeitsweise:
- Prüfe den bestehenden Code und die vorhandene Projektstruktur.
- Ändere zunächst nichts.
- Erstelle zuerst einen Review-Bericht.
- Nenne nur konkrete, im Projekt tatsächlich erkennbare Risiken.
- Keine allgemeinen Belehrungen.
- Keine hypothetischen Probleme ohne Codebezug.
- Keine Architektur-Neuerfindung.
- Keine größeren Umbauten vorschlagen, wenn eine kleine robuste Korrektur genügt.
- Wenn Informationen fehlen, markiere den Punkt als „nicht prüfbar“.
- Bewerte jedes Problem nach Schweregrad:
- kritisch
- hoch
- mittel
- niedrig
- Gib pro Fundstelle an:
- Datei
- betroffene Methode/Funktion/Klasse
- konkretes Problem
- mögliches Fehlverhalten
- empfohlene minimale Korrektur
Prüffelder:
1. Datum, Zeit und Zeitzonen
- Uneindeutige Datumsformate wie 01/02/2026
- Locale-abhängige Datumsverarbeitung
- Speicherung von Datum/Zeit als String
- fehlende UTC-Strategie
- fehlende Zeitzonenbehandlung
- Sommerzeit/Winterzeit-Probleme
- falsche Berechnung von Fristen, Monatsenden, Kalenderwochen
- Serverzeit vs. Benutzerzeit vs. Datenbankzeit
2. Zahlen, Geldbeträge und Rundung
- Dezimalpunkt vs. Dezimalkomma
- Geldbeträge als Float
- Rundungsfehler bei Preisen, Steuern, Rabatten, Summen
- implizite Zahlkonvertierungen
- Locale-abhängige Parser
- falsche Behandlung von Tausendertrennzeichen
- Speicherung formatierter Zahlen statt Rohwerte
3. Zeichenkodierung und Text
- UTF-8-Probleme
- kaputte Umlaute/Sonderzeichen
- falsche Datenbank-Kollation
- Sonderzeichen in Dateinamen
- Probleme mit typografischen Zeichen, Emojis, Gedankenstrichen, Anführungszeichen
- unsaubere Normalisierung von Text
4. Internationalisierung und Lokalisierung
- hart codierte Sprache
- Währungen ohne explizites Format
- Länder-, Adress-, Telefon- oder Steuerformate
- sprachabhängige Sortierung
- fehlende Trennung zwischen interner Speicherung und äußerer Darstellung
5. Null, leer, false, 0
- Vermischung von null, leerem String, 0, "0", false und fehlendem Wert
- Truthy/Falsy-Prüfungen
- unklare fachliche Bedeutung leerer Werte
- fehlende explizite Validierung
6. Typen und Konvertierungen
- implizite Typumwandlungen
- String-Zahlen statt echter Zahlen
- Boolean-Werte als Strings
- unsichere Casts
- unklare Array-Strukturen
- fehlende Rückgabe- und Parametertypen
- potenzielle PHPStan-/TypeScript-/Linting-Probleme
7. Schnittstellen und APIs
- unklare oder inkonsistente Feldnamen
- fehlende Pflichtfeldprüfung
- uneinheitliche Fehlerformate
- falsche oder inkonsistente HTTP-Statuscodes
- fehlende API-Versionierung
- fehlende Pagination
- fehlendes Rate-Limit-Handling
- fehlende Timeout- und Retry-Strategie
- nicht idempotente Endpunkte bei Wiederholung
8. CSV, Excel, Import und Export
- Trennzeichenprobleme
- Encoding-Probleme
- automatische Excel-Konvertierungen
- führende Nullen bei ISBN, EAN, PLZ oder Bestellnummern
- Datums- und Zahlenverfälschung
- instabile Spaltennamen oder Spaltenreihenfolgen
- fehlende Importvalidierung
- fehlendes Fehlerprotokoll bei Teilimporten
9. Dateien und Pfade
- Windows-/Linux-Pfadprobleme
- Groß-/Kleinschreibung
- Leerzeichen und Sonderzeichen in Dateinamen
- relative vs. absolute Pfade
- fehlende Rechteprüfung
- unsichere temporäre Dateien
- Race Conditions beim Dateizugriff
- zu frühes Löschen verarbeiteter Dateien
10. Authentifizierung und Autorisierung
- Authentifizierung ohne Rechteprüfung
- Frontend-only-Schutz
- fehlende Rollenprüfung im Backend
- zu grobe Rollenmodelle
- unsichere Admin-Endpunkte
- fehlende Prüfung von Objektbesitz
- fehlende Mandantenprüfung
11. Mandantenfähigkeit
- fehlender Mandantenfilter
- globale Daten vs. kundenspezifische Daten unsauber getrennt
- Cache ohne Mandantenkontext
- Hintergrundjobs ohne Mandantenkontext
- Exporte ohne Mandantenbegrenzung
- versehentliche Datenlecks zwischen Kunden
12. Nebenläufigkeit und Race Conditions
- parallele Verarbeitung derselben Daten
- doppelte E-Mails
- doppelte Zahlungen
- doppelte Jobs
- fehlende Locks
- fehlende Idempotenz
- unsicheres Retry-Verhalten
- Überschreiben neuerer Daten durch ältere Prozesse
13. Fehlerbehandlung
- geschluckte Exceptions
- zu allgemeine catch-Blöcke
- technische Fehlermeldungen an Nutzer
- fehlende Unterscheidung zwischen Benutzerfehler, Validierungsfehler, Systemfehler und externem Fehler
- Retry bei nicht wiederholbaren Fehlern
- kein Retry bei temporären Fehlern
- fehlende Eskalation kritischer Fehler
14. Logging und Nachvollziehbarkeit
- fehlende Request-ID, User-ID, Job-ID oder Correlation-ID
- sensible Daten in Logs
- zu wenig Logs für produktive Fehlersuche
- zu viele unbrauchbare Logs
- fehlende Laufzeitmessung
- fehlende Protokollierung von externen API-Fehlern
- fehlende Nachvollziehbarkeit bei Hintergrundjobs
15. Caching
- Cache-Key zu grob
- fehlende Mandanten-, Sprach-, Rollen- oder Benutzerkomponente im Cache-Key
- fehlende Invalidierung
- veraltete Daten
- unterschiedliches Verhalten lokal/produktiv
- Browsercache/CDN/Servercache-Konflikte
16. Umgebungen und Konfiguration
- abweichende Konfiguration zwischen Entwicklung, Test und Produktion
- fehlende ENV-Variablen
- unsichere Default-Werte
- Testwerte in Produktion
- produktive Secrets in Testsystemen
- unterschiedliche Locale, PHP-/Node-/DB-Versionen
- fehlende Prüfung beim Start der Anwendung
17. Secrets und Sicherheit der Konfiguration
- Secrets im Repository
- öffentlich erreichbare .env-Dateien
- API-Keys im Code
- fehlende Rotation
- zu breite CORS-Regeln
- Debug-Modus in Produktion
- Directory Listing
- sensible Daten in Responses oder Logs
18. Validierung
- nur Frontend-Validierung
- fehlende Backend-Validierung
- fehlende Längenbegrenzungen
- fehlende Prüfung von Dateitypen
- fehlende Wertebereichsprüfung
- fehlende Datenbank-Constraints
- widersprüchliche Validierungsregeln zwischen Frontend, Backend und Datenbank
19. Datenbankmodellierung
- falsche Datentypen
- Geld als Float
- Datum als String
- JSON als unstrukturierte Müllhalde
- fehlende Constraints
- fehlende Indizes
- zu viele nullable Felder
- unklare Statuswerte
- fehlende Historisierung
- harte Löschung trotz Nachweispflicht
20. Statusmodelle
- Boolean-Felder, obwohl mehrere Zustände existieren
- unklare Statusübergänge
- fehlende Fehlerzustände
- fehlende Retry-Zustände
- fehlende Abbruch- oder Ablaufzustände
- inkonsistente Statusnamen
- Statusänderungen ohne Transaktion
21. Externe Dienste
- fehlende Timeout-Konfiguration
- fehlendes Rate-Limit-Handling
- fehlende Kostenkontrolle
- fehlende Fallback-Strategie
- Annahme, dass externe APIs immer verfügbar sind
- unsichere Webhook-Verarbeitung
- fehlende Signaturprüfung bei Webhooks
- fehlende Idempotenz bei Webhooks
- falsche Reihenfolge von Webhook-Ereignissen
22. E-Mail
- fehlende Trennung zwischen Test- und Produktivversand
- doppelte E-Mails
- fehlende Bounce-Behandlung
- HTML-Mail ohne Plaintext-Alternative
- Encoding-Probleme
- zu große Attachments
- fehlende SPF/DKIM/DMARC-Hinweise, soweit im Projekt erkennbar
- sensible Daten in E-Mails
23. Sicherheit allgemein
- SQL Injection
- XSS
- CSRF
- unsichere Uploads
- fehlendes Rate Limiting
- unsichere Direktzugriffe auf Dateien
- unzureichende Passwort- oder Tokenprüfung
- fehlende Security Headers
- fehlende Rechteprüfung auf API-Ebene
- unsichere Deserialisierung
- unsichere Redirects
24. Uploads und Dateiverarbeitung
- Vertrauen auf Dateiendung statt Inhalt
- fehlende MIME-Prüfung
- fehlende Größenbegrenzung
- fehlende Viren-/Malware-Strategie, falls relevant
- unsichere Dateinamen
- fehlende Isolation temporärer Dateien
- parallele Verarbeitung ohne Schutz
- Speicherplatzprobleme
- Bereinigung alter Dateien
25. Deployment und Betrieb
- fehlende Migrationen
- nicht neugestartete Worker
- nicht geleerte Caches
- falsche Rechte
- fehlende Build-Artefakte
- fehlender Rollback-Plan
- alte Prozesse mit altem Code
- fehlende Health Checks
- fehlende Startprüfung kritischer Dienste
26. Versionierung und Abwärtskompatibilität
- API-Änderungen ohne Versionierung
- inkompatible Datenbankmigrationen
- alte Daten erfüllen neue Regeln nicht
- fehlende Migrationsstrategie
- Frontend/Backend-Versionen passen nicht zusammen
- fehlende Kompatibilität mit bestehenden Clients
27. Performance
- N+1 Queries
- fehlende Indizes
- zu große Payloads
- zu viele API-Calls
- lange synchrone Prozesse im Webrequest
- fehlende Pagination
- große Exporte ohne Hintergrundverarbeitung
- ineffiziente Schleifen
- unnötige Dateisystem- oder Datenbankzugriffe
28. Suche und Filter
- naive LIKE-Suche
- fehlende Behandlung von Umlauten
- fehlende Normalisierung
- Probleme mit Singular/Plural
- falsche UND/ODER-Logik
- instabile Sortierung
- fehlende Relevanzlogik
- Filter ohne klare Semantik
29. Frontend-/Backend-Vertrag
- inkonsistente Feldnamen
- Backend liefert null, Frontend erwartet String
- Backend liefert Objekt, Frontend erwartet Array
- uneinheitliche Fehlerantworten
- fehlende Lade-, Fehler- und Leerzustände
- Race Conditions durch parallele Requests
- fehlende OpenAPI-/Schema-Abstimmung
30. Anforderungen und fachliche Logik
- unklare Begriffe
- fachliche Regeln nur implizit im Code
- Magic Numbers
- versteckte Sonderfälle
- fehlende Tests für Randfälle
- fachliche Logik über mehrere Stellen verteilt
- Regeln nicht aus Datenmodell oder Tests nachvollziehbar
Ausgabeformat:
Erstelle den Bericht in folgender Struktur:
# Production-Risk-Review
## Zusammenfassung
- Anzahl kritischer Probleme:
- Anzahl hoher Probleme:
- Anzahl mittlerer Probleme:
- Anzahl niedriger Probleme:
- Wichtigstes Gesamtrisiko:
## Kritische Probleme
Für jedes Problem:
- Datei:
- Stelle:
- Kategorie:
- Problem:
- Auswirkung:
- Minimale Korrektur:
## Hohe Probleme
Gleiche Struktur.
## Mittlere Probleme
Gleiche Struktur.
## Niedrige Probleme
Gleiche Struktur.
## Nicht prüfbare Bereiche
Liste Bereiche, die mangels Informationen nicht seriös geprüft werden konnten.
## Empfohlene Reihenfolge der Korrektur
Sortiere nach Risiko, nicht nach Aufwand.
Regeln:
- Keine Codeänderung ohne ausdrückliche Freigabe.
- Keine pauschalen Empfehlungen.
- Keine Framework-Wechsel.
- Keine neuen Libraries vorschlagen, wenn native Mittel ausreichen.
- Keine Refactorings vorschlagen, die nicht direkt zur Risikoreduktion beitragen.
- Jede Empfehlung muss sich auf eine konkrete Fundstelle beziehen.
Was macht dieser Prompt?
Der Prompt verhindert die typische Agenten-Krankheit: loslaufen, umbauen, verschlimmbessern.
Er zwingt den Agenten zuerst in die Rolle eines Prüfers. Nicht eines Bastlers. Nicht eines Refactoring-Fans. Nicht eines Framework-Missionars.
Wichtig sind vor allem drei Regeln:
Erstens: Keine Codeänderung ohne Freigabe.
Der Agent soll zuerst Risiken finden, nicht blind umbauen.
Zweitens: Nur konkrete Fundstellen.
Keine Allgemeinplätze. Kein „man könnte vielleicht“. Kein theoretisches Architekturtheater.
Drittens: Minimale Korrektur.
Wenn ein kleiner Fix reicht, soll kein neues Subsystem erfunden werden.
Damit wird KI nicht als magische Code-Maschine benutzt, sondern als systematischer Prüfer für genau die Fehler, die seit Jahrzehnten teuer werden.
Das ist weniger glamourös als der nächste Architekturtrend.
Aber vermutlich deutlich nützlicher.
0 Kommentare