Prompts für wartbaren Code: Vorgaben für Ordnerstruktur und Benennung

Warum KI-Ausgaben schnell schwer wartbar werden

KI-generierter Code wirkt am ersten Tag oft großartig: er läuft schnell und liefert sofort ein Ergebnis. Das Problem taucht ein paar Tage später auf, wenn Sie ein Feature hinzufügen, einen Bug beheben oder das Projekt an jemand anderen übergeben müssen. Ohne klare Regeln optimiert das Modell für „macht es jetzt funktionsfähig“, nicht für „macht es später leicht änderbar“.

Vage Prompts sind meist die Ursache. Wenn Sie keine Regeln zur Ordnerstruktur, Benennung und Konfiguration vorgeben, füllt das Modell die Lücken jedes Mal anders aus. So landen Dateien in zufälligen Verzeichnissen, es gibt drei Bezeichnungen für dasselbe Konzept, und Einstellungen verstecken sich an Orten, an die niemand denkt. Der Code kann laufen, wird aber fragil.

Typische Anzeichen, dass Sie in ein Wartungschaos steuern: inkonsistente Stile für ähnliche Features, unvorhersehbare Dateipositionen, driftende Namen (userService, users_service, UserSvc) und Konfiguration, die im Code verstreut ist, ohne klare Defaults. Kleine Änderungen lösen überraschende Fehler anderswo aus.

Für einen Solo-Gründer oder ein kleines Team bedeutet „wartbar“ meist: Sie finden Sachen schnell, ändern ein Verhalten, ohne fünf andere Dinge zu brechen, und können eine neue Person ohne lange Einführung ins Projekt holen. Es bedeutet auch weniger nächtliche Überraschungen wie gebrochene Auth, offen gelegte Secrets oder ein verwirrendes Durcheinander an Dateien.

Fügen Sie Einschränkungen immer dann hinzu, wenn das Projekt länger leben soll als ein Demo oder wenn Sie mehr als eine Iteration erwarten. Lassen Sie das Modell nur für wegwerfbare Experimente, schnelle Spike-Tests oder Einmalskripte improvisieren. Wenn Sie es vielleicht ausliefern, warten oder jemanden dafür bezahlen wollen, setzen Sie die Regeln von Anfang an.

Die drei wichtigsten Einschränkungen

Wenn Sie Prompts für wartbaren Code wollen, fragen Sie nicht zuerst nach mehr Features. Beginnen Sie mit drei Einschränkungen, die festlegen, wie der Code organisiert, benannt und konfiguriert wird. Diese Dinge sind später schmerzhaft zu ändern.

1) Ordnerstruktur (wo Dinge hingehen)

Eine Ordnerregel macht die Ausgabe vorhersehbar und verhindert das „alles im Root“-Chaos.

Geben Sie Regeln wie: behalte einen einzigen Einstiegspunkt, gruppiere Code nach Verantwortung, und trenne App-Code von Konfiguration, Skripten und Tests. Sagen Sie auch, was niemals passieren darf (zum Beispiel: keine Business-Logik in UI-Komponenten, kein Datenbankcode in Routes).

2) Benennung (wie Sie Dinge später wiedererkennen)

Benennungsregeln reduzieren doppelte Arbeit und Verwirrung. Ohne sie bekommen Sie zwei Dateien, die dasselbe tun, oder ein utils.ts, das zur Abstellkammer verkommt.

Seien Sie konkret: Dateinamen, Komponenten, Funktionen, Routen und Datenbanktabellen sollten einem Stil folgen und ihren Zweck widerspiegeln. Verwenden Sie konsistente Verben für Aktionen (create, update, delete) und vermeiden Sie vage Namen wie data, helper oder thing.

3) Konfiguration (wie Einstellungen und Secrets gehandhabt werden)

Die meisten KI-Prototypen brechen, wenn Sie von lokalen Läufen in echte Deployments wechseln. Klare Konfigurationsregeln verhindern das.

Definieren Sie diese Regeln von Anfang an:

• Ein einziger Konfigurationsort (Env-Variablen + ein Config-Modul), keine verstreuten Konstanten
• Dev- und Prod-Defaults getrennt, mit sicheren Fallbacks
• Keine Hardcodierung von Secrets, Tokens oder API-Keys im Code oder Beispiel-Dateien
• Eine minimale Beispiel-.env-Datei mit nur Platzhaltern
• Fail fast bei fehlenden Pflichtwerten mit einer klaren Fehlermeldung

Wenn Sie einen KI-generierten App übernommen haben, die diese Regeln ignoriert, kommt diese Aufräumarbeit meist zuerst, weil sie spätere Fixes einfacher macht.

Eine wiederverwendbare Prompt-Vorlage, die Sie kopieren können

Der schnellste Gewinn ist ein kleiner, wiederverwendbarer Einschränkungsblock. Fügen Sie ihn in jede Anfrage ein und passen Sie nur das an, was für das Projekt relevant ist.

Hier ist eine Vorlage, die Sie eins zu eins kopieren können:

CONSTRAINTS
1) Before coding, output a brief file tree (max 15 lines). Ask 2-4 questions only if needed.
2) Folder structure:
   - Keep source in /src
   - Keep shared utilities in /src/lib
   - Keep UI components in /src/components
   - Keep config in /config
3) Naming:
   - Files: kebab-case (user-profile.ts)
   - React components: PascalCase
   - Functions/vars: camelCase
   - No single-letter names (except i/j in loops)
4) Configuration and secrets:
   - Read all secrets from environment variables
   - Provide a sample .env.example (no real secrets)
   - Safe defaults for dev, strict checks for prod
5) If a rule conflicts with the framework:
   - Follow the framework default
   - Explain the conflict in 2-3 sentences
   - Suggest the closest alternative that keeps the spirit of the rule
6) Output:
   - Generate code file-by-file with clear filenames
   - Add short comments only where the intent is not obvious

Halten Sie Regeln spezifisch, aber nicht zu detailliert. Gute Einschränkungen beschreiben überprüfbare Ergebnisse (wo Dateien liegen, wie Namen aussehen, wo Secrets herkommen). Überspringen Sie winzige Stilregeln, die nur Mehraufwand erzeugen.

Eine hilfreiche Gewohnheit: verlangen Sie zuerst den Dateibaum. Das zwingt das Modell zu planen und gibt Ihnen eine schnelle Chance, zu sagen „verschiebe Auth in /src/lib“, bevor es 10 Dateien schreibt.

Wenn Sie später KI-generierten Code reparieren, machen Einschränkungen die Fehlerbehebung schneller. Wenn alles einen vorhersehbaren Platz hat, fällt es leichter zu sehen, was fehlt, und es zu patchen, ohne Unabhängiges zu brechen.

Schritt-für-Schritt: Wie Sie Ihre Einschränkungen schreiben

Gute Prompts für wartbaren Code beginnen mit Klarheit und fügen nur die Regeln hinzu, die Sie tatsächlich durchsetzen werden. Wenn Sie zu viele Regeln angeben, ignoriert das Modell sie oder produziert Fülltext.

Ein einfacher Workflow, der funktioniert

Schreiben Sie Ihren Prompt in fünf Teilen, in dieser Reihenfolge:

• Beginnen Sie mit einem Satz, der die Aufgabe beschreibt (für wen und was getan werden soll).
• Legen Sie die wesentlichen Teile des Stacks fest (Framework, Sprache und Versionen, die Syntax/Config beeinflussen). Den Rest weglassen.
• Setzen Sie Projektregeln: wie Ordner organisiert sind und wie Dateien, Komponenten und Funktionen benannt werden.
• Definieren Sie, wie Konfiguration funktioniert: was in Env-Variablen kommt, welche Defaults sicher sind und was niemals committet werden darf.
• Fordern Sie eine Ausgabereihenfolge: zuerst ein Dateiplan, dann der Code, dann eine kurze Selbstprüfung, was verifiziert wurde.

Diese Reihenfolge ist wichtig. Wenn Sie mit Ordnern und Benennung beginnen, bevor das Ziel klar ist, bekommen Sie oft eine saubere Struktur, die das falsche Problem löst.

Kleines Beispiel (einfachere Sprache)

Stellen Sie sich vor, Sie wollen einen einfachen Rechnungstracker für einen Freelancer. Wenn Sie React + TypeScript fixieren und sagen „Server-Code in /api, UI in /web, geteilte Typen in /shared“, verhindern Sie viel Chaos. Fügen Sie Benennung hinzu wie „Komponenten in PascalCase, Hooks beginnen mit use“, und Sie vermeiden später das Rätsel, wo Logik liegt.

Seien Sie strikt bei der Konfiguration: „Secrets nur aus Env-Variablen lesen, .env.example bereitstellen und bei fehlenden Variablen sofort mit klarer Fehlermeldung abbrechen.“ Diese einzige Zeile verhindert klassische Probleme mit gebrochener Auth und offen gelegten Geheimnissen.

Beenden Sie mit einer erforderlichen Selbstprüfung. Das regt das Modell an, fehlende Dateien, nicht übereinstimmende Namen und unsichere Defaults zu erkennen, bevor Sie es tun.

Ordnerstruktur-Einschränkungen, die Projekte ordentlich halten

Ein sauberer Ordnerbaum ist eine der einfachsten Einschränkungen. Das Ziel ist nicht Perfektion, sondern Vorhersehbarkeit, damit Sie (oder jemand anderes) Dinge schnell finden und ändern können, ohne Unabhängiges zu brechen.

Eine einfache Struktur, die für kleine Web-Apps passt, sieht so aus:

• src/ui/ für Screens und wiederverwendbare Komponenten
• src/domain/ für Geschäftsregeln (was die App tut)
• src/data/ für Datenbank und externe APIs (wie Daten gespeichert/abgefragt werden)
• src/shared/ für wirklich geteilte Helfer (klein, langweilig, wiederverwendet)
• src/config/ für App-Setting-Defaults (keine Secrets)

Fügen Sie eine weitere Regel hinzu: trennen Sie UI von Business-Logik und Data-Access. Einfach gesagt: UI sollte nicht direkt mit der Datenbank sprechen, und Datenbankcode sollte nicht entscheiden, was ein Benutzer darf.

Damit Dateien nicht zu 800-Zeilen-Monstern werden, definieren Sie „eine Verantwortung pro Datei“ praktisch. Eine Datei sollte einen Hauptzweck haben (eine Komponente, einen Service, ein Repository). Wenn sie zwei verschiedene Überschriften braucht, splitten Sie sie. Wenn sie an drei Stellen wiederverwendet wird, verschieben Sie sie nach shared/. Wenn sie nur innerhalb eines Features wiederverwendet wird, behalten Sie sie im Feature-Ordner. Vermeiden Sie ein generisches utils/ als Ablage: verlangen Sie spezifische Ordnernamen wie shared/date/ oder shared/format/.

Eine hilfreiche Regel, wann ein neues Modul zu erstellen ist vs. etwas zum bestehenden hinzuzufügen: Erstellen Sie nur dann einen neuen Ordner, wenn es ein neues Konzept in der App gibt. Eine Billing-App könnte domain/invoices/ und ui/invoices/ hinzufügen, sobald Rechnungen ein echtes Feature werden, nicht nur ein einzelner Bildschirm.

Wenn Sie chaotische KI-Ausgaben übernehmen, machen diese Einschränkungen die Remediation schneller. Viel Arbeit besteht darin, Code in klare Grenzen zu verschieben, bevor Sie Logik, Auth oder Sicherheitsprobleme sicher reparieren können.

Benennungsregeln, die später Verwirrung verhindern

Benennung ist ein Bereich, in dem KI-Code oft schiefgeht. Wenn Ihr Prompt hier strikt ist, verbringen Sie weniger Zeit mit Import-Suchen, Rätseln, was eine Funktion macht, oder dem Entwirren von „fast gleichen“ Modellen.

Wählen Sie einen Stil pro Kategorie und mischen Sie nicht. Eine einfache Zuordnung, die Sie in Prompts einfügen können, ist:

• Dateien und Ordner: kebab-case (z. B. user-profile.ts)
• React-Komponenten/Klassen: PascalCase (z. B. UserProfile)
• Funktionen und Variablen: camelCase (z. B. fetchUserProfile)
• Konstanten: SCREAMING_SNAKE_CASE (z. B. MAX_RETRIES)
• API-Routen: kebab-case (z. B. /user-profile)

Dateinamen sollten zu dem passen, was sie exportieren. Wenn eine Datei UserService exportiert, nennen Sie sie user-service.ts (oder UserService.ts, wenn das Ihre Regel ist). Exportieren Sie nicht fünf unzusammenhängende Dinge aus einer Datei. Ein Hauptexport pro Datei hält Importe vorhersehbar und macht Refactors sicherer.

Bei Funktionen: Verwenden Sie verbenbasierte Namen, die sagen, was passiert: getUserById, validateSignupForm, saveInvoice, sendPasswordResetEmail. Vermeiden Sie vage Namen wie process, handleThing oder doWork. Wenn etwas async ist, seien Sie konsistent: fügen Sie überall ein Async-Suffix hinzu oder verlassen Sie sich auf den Kontext, aber mischen Sie nicht die Stile.

Datenmodelle sollten Singularnamen verwenden (User, Invoice). Datenbankfelder sollten einer Konvention folgen (snake_case ist in SQL üblich; camelCase in Anwendungscode). Wählen Sie eine und bleiben Sie dabei. Stimmen Sie verwandte Namen ab, sodass createdAt sauber zu created_at passt, und nicht an einer Stelle create_date und an anderer created heißt.

Eine kleine „nicht verwenden“-Liste spart später Zeit: temp, misc, helper2, final_v3, newNew. Wenn Sie einen Codebestand mit solchen Namen erben, zahlt sich Umbenennen und Umorganisieren oft sofort aus, weil unklare Namen Bugs verstecken.

Konfigurationsregeln: Umgebungen, Secrets und Defaults

Seien Sie streng darin, was Konfiguration ist und was Code ist. Konfiguration ist alles, was sich zwischen Dev, Staging und Prod ändert: Datenbank-URL, API-Keys, erlaubte Origins, Cookie-Einstellungen, Feature-Flags. Code ist die Logik, die gleich bleibt: Routen, Validierung, Geschäftsregeln.

Eine gute Vorgabe trennt Runtime-Konfiguration von Build-Time-Konfiguration. Runtime-Konfiguration sollte aus Umgebungsvariablen kommen, weil sie sich ohne Rebuild ändern kann. Build-Time-Konfiguration kann in Dateien im Repo liegen, etwa ein typisiertes Config-Modul mit sicheren Defaults oder config/*.json für nicht-geheime Werte.

Secrets brauchen explizite Regeln, weil KI-Apps sie oft versehentlich leaken:

• Secrets niemals im Code oder in Konfigurationsdateien hardcoden
• Secrets niemals loggen (auch nicht in Debug-Logs)
• Secrets niemals committen (nur eine Beispiel-Datei committen)
• Bei fehlenden Pflichtsecrets sofort abbrechen
• Klare Namen wie DATABASE_URL und JWT_SECRET verwenden

Defaults sind wichtig. Fordern Sie sichere, langweilige Defaults, damit die App vorhersehbar läuft, bevor Sie alles feinjustieren. Beispiel: CORS sollte eingeschränkt sein (nur bekannte Origins zulassen), Auth-Cookies sollten in Produktion HttpOnly und Secure sein, und Sessions sollten eine kurze Idle-Timeout sowie eine klare Max-Age haben.

Verlangen Sie außerdem einen Ort, an dem Konfiguration dokumentiert ist. Das einfachste Muster ist eine einzelne .env.example mit Kommentaren plus ein kurzes „Configuration“-Abschnitt in der README, der jede Variable, ihre Funktion und ein Beispielwert beschreibt. Diese Einschränkung spart später Stunden, besonders wenn ein Prototyp auf einem Laptop lief, aber beim Deployment kaputtgeht.

Qualitätsregeln: Fehler, Validierung und kleine Tests

Die meisten KI-Apps scheitern in Produktion aus banalen Gründen: undurchsichtige Fehler, fehlende Validierung und keine Tests für riskante Bereiche. Ein paar Qualitätsregeln machen die Ausgabe jetzt leichter zu debuggen und später einfacher zu reparieren.

Beginnen Sie mit einer einheitlichen Fehlerbehandlung. Fordern Sie ein Muster im ganzen Projekt, nicht eine Mischung aus geworfenen Strings, ad-hoc-Antworten und stummen Fehlern. Fehler sollten explizit sein, dieselbe Form haben und sicher gegenüber Nutzern angezeigt werden können.

Fordern Sie dann Validierung an den Grenzstellen, an denen schlechte Daten hereinkommen: API-Routen, Formulare, Webhooks, Background-Jobs. Fehlt die Validierung, entstehen merkwürdige Bugs wie „funktioniert auf meinem Rechner“ oder „fehlt nur bei manchen Nutzern“.

Kopierbare Einschränkungen:

• Verwenden Sie ein einheitliches Fehlerformat (z. B. { code, message, details? }) und werfen Sie niemals reine Strings.
• Validieren Sie alle externen Eingaben an der Grenze, geben Sie klare Validierungsfehler zurück und vertrauen Sie niemals Client-Daten.
• Halten Sie Funktionen klein (etwa 20–40 Zeilen) und Rückgabewerte vorhersehbar (keine gemischten Typen).
• Loggen Sie unerwartete Fehler mit genug Kontext, um sie zu reproduzieren (Request-ID, User-ID falls vorhanden, Aktion).

Tests müssen nicht umfangreich sein, um zu helfen. Fordern Sie ein minimales Set passend zum Risiko an. Wenn Sie Login, einen Zahlungsfluss oder Create/Update-Aktionen haben, sind das die ersten Bereiche, die Sie abdecken sollten. Ein leichtgewichtiges Minimum könnte Auth-Ablehnung bei ungültigen Zugangsdaten, ein erfolgreicher Pfad des Kernflusses plus ein häufiger Fehlerfall und ein Validierungstest für schlechte Eingaben umfassen.

Fordern Sie schließlich eine kurze „Wie lokal starten“-Anleitung in der Ausgabe an, inklusive benötigter Env-Variablen und sicherer Defaults. Das verhindert viele „es startet nicht“-Projekte.

Beispielprompt: Eine kleine App bauen, die wartbar bleibt

Stellen Sie sich vor, Sie wollen eine kleine Web-App mit Login, einer Profilseite und einem Einstellungsformular. Ohne Einschränkungen verteilt eine KI Auth-Logik über Seiten, mischt DB-Aufrufe in UI-Code und erfindet Dateinamen spontan. Mit klaren Regeln bekommen Sie saubere Grenzen und einen Dateiplan, den Sie später debuggen können.

Hier ein kopierbares Beispielprompt, das Sie anpassen können:

Build a small app with:
- Login page
- Profile page (shows name + email)
- Settings page (update display name, toggle a feature flag)

Hard constraints (do not violate):
1) Folder structure:
- /src/routes = route definitions only
- /src/handlers = request/response logic only (no database queries)
- /src/services = business rules (auth, profile, settings)
- /src/data = database access only (queries, repositories)
- /src/config = configuration loader and typed config

2) Naming:
- Files: kebab-case (profile-handler.ts)
- Exports: camelCase functions, PascalCase types
- One main export per file

3) Code boundaries:
- Routes call handlers
- Handlers call services
- Services call data layer
- Data layer is the only place allowed to import the DB client

4) Config constraints:
- Read DATABASE_URL and AUTH_SECRET from environment variables
- Never hardcode secrets or sample keys
- Add FEATURE_SETTINGS_ENABLED default=false when missing
- Provide a single config object from /src/config

Deliverables:
- Start with a file tree
- Then output code file-by-file
- Finish with a summary table: file created/changed + 1 sentence why

Wenn Sie noch strengere Ausgabe wollen, fügen Sie hinzu: „Wenn Sie eine neue Datei hinzufügen müssen, erklären Sie, warum sie in diesen Ordner gehört.“ Das drängt das Modell, Grenzen zu respektieren, statt alles an einen Ort zu kippen.

Häufige Fehler beim Hinzufügen von Einschränkungen

Einschränkungen sollen die Ausgabe lesbarer, änderbarer und reparierbarer machen. Die meisten Probleme entstehen, wenn Regeln entweder zu vage sind, um das Modell zu leiten, oder so streng, dass sie mit dem genutzten Framework kollidieren.

Fehler 1: Zu starke Einschränkungen

Es ist leicht, Regeln zu schreiben, die sauber klingen, aber unnatürliche Entscheidungen erzwingen. Zum Beispiel ein Layout verlangen, das gegen Next.js-Konventionen arbeitet, oder die Standard-Konfigurationsdatei eines Frameworks verbieten, weil sie „chaotisch“ wirkt. Das Modell verbringt dann Aufwand damit, Ihre Regeln zu umgehen, anstatt korrekten Code zu schreiben.

Ein sichererer Ansatz: Folgen Sie den Framework-Standards, wenn es einen Konflikt gibt, und fügen Sie Einschränkungen nur dort hinzu, wo Sie wirklich wiederkehrende Verwirrung sehen (z. B. wo API-Routen leben oder wo gemeinsame Typen liegen).

Fehler 2: Zu vage Regeln

„Clean code“, „best practices“ oder „enterprise-ready“ sagen dem Modell nichts Konkretes. Ersetzen Sie solche Begriffe durch überprüfbare Vorgaben.

Beispiele für funktionierende Einschränkungen:

• „Gebe zuerst einen Dateibaum aus, dann die Code-Dateien in dieser Reihenfolge.“
• „Verwende einen Benennungsstil: camelCase für Variablen, PascalCase für Komponenten.“
• „Lese Env-Variablen aus .env.example nur über ein Config-Modul.“
• „Keine neuen Libraries ohne Rückfrage und Erklärung.“
• „Wenn Sie Dateien verschieben, fügen Sie Migrationsschritte hinzu.“

Ein weiteres Problem ist, dass das Modell Bibliotheken oder Config-Dateien erfindet, die Sie nicht wollten. Sie verlangen Auth, und es fügt drei Pakete, zwei Konfigurationen und ein neues Build-Tool hinzu.

Unterschätzen Sie nicht die Migrationsschritte beim Ändern der Ordnerstruktur. Eine kleine Umbenennung kann Importe, Tests und Deployments brechen. Fordern Sie einen kurzen „Was hat sich geändert“-Abschnitt und die notwendigen Befehle zur Aktualisierung von Pfaden. Und verlangen Sie immer einen Dateibaum; ohne ihn wird die Ausgabe verstreut und schwer zusammensetzbar.

Schnelle Checkliste und nächste Schritte

Bevor Sie KI-generierten Code akzeptieren oder mergen, machen Sie einen 5-minütigen Durchgang. Diese Checks fangen die meisten „sieht jetzt gut aus, später schmerzhaft“-Probleme ab:

• Der Dateibaum entspricht Ihren Regeln (Ordner, Schichten, geteilte Teile) und es gibt keine zufälligen One-Off-Verzeichnisse.
• Namen sind konsistent: dasselbe Konzept wird nicht an verschiedenen Stellen unterschiedlich genannt.
• Keine Secrets im Code: keine API-Keys, Tokens, private URLs oder echte Zugangsdaten in Dateien, Kommentaren oder Beispiel-Konfigurationen.
• Die Konfiguration ist klar: es gibt einen dokumentierten Ort für Env-Variablen, Defaults sind sicher und das Verhalten ändert sich nicht still zwischen Dev und Prod.
• Es ist mit Copy-Paste lauffähig: jemand Neues kann installieren, konfigurieren und starten, ohne zu raten.

Wenn Sie nicht bei den meisten Punkten klar „ja“ sagen können, stoppen Sie. Eine kleine Aufräumarbeit jetzt ist billiger, als einen Monat später Bugs zu debuggen — besonders wenn Probleme in Namensverwirrung, verteilter Konfiguration oder einer Ordnerstruktur liegen, die Spaghetti fördert.

Wenn Sie bereits ein chaotisches KI-Projekt haben, machen Sie es verständlich, bevor Sie Features hinzufügen. Eine praktische Reihenfolge: Scope 24 Stunden einfrieren, aktuelle Struktur kartieren (Ordner, Einstiegspunkte, wo Konfig/Secrets liegen), eine Benennungsregel für den Hot-Path auswählen und zuerst anwenden, Konfiguration an einen Ort ziehen mit einer sicheren Beispiel-Datei und klaren Startschritten, dann ein paar kleine Prüfungen (Validierung, grundlegende Fehlerbehandlung, 1–2 Smoke-Tests) hinzufügen, um Regressionen zu verhindern.

Wenn Sie mit einem Prototyp von Tools wie Lovable, Bolt, v0, Cursor oder Replit stecken, die sich in Produktion nicht verhalten, kann FixMyMess (fixmymess.ai) eine kostenlose Code-Prüfung durchführen, um Struktur-, Benennungs-, Konfigurations- und Sicherheitsprobleme zu identifizieren, bevor Sie mit Fixes beginnen. So erhalten Sie einen klaren Plan, nicht noch eine Runde Raten.