Verschwendete KI-Credits sind die Dummheitssteuer jedes Entwicklers. Das mache ich stattdessen.

7 min read

Manche Morgen öffne ich mein Claude-Dashboard noch vor allem anderen und sehe 15-20% meiner Wochenkredits dort liegen, wenige Stunden vor dem Reset. Kredite, die ich bereits bezahlt habe. Kredite, die gleich für nichts verfallen werden.

Die meisten Entwickler schauen zu, wie der Zähler auf null geht. (Du hättest sowieso nichts Sinnvolles damit gemacht, oder?)

Ich nutze diese Stunden anders. Ich setze einen autonomen Refactoring-Agent auf ein echtes Projekt an, gebe ihm eine verifizierbare Abschlussbedingung und mache etwas anderes. Live-Produktionscode, kein Tutorial-Projekt. Letzte Woche: ein WooCommerce-Katalog-Backend mit 118.000 Zeilen TypeScript mit Uptime-Monitoring alle 30 Minuten, und ein zweites Projekt mit 6 Lieferanten-Integrationsdateien, die alle dieselbe Sync-Schleife laufen lassen – etwa 500 Zeilen Code über alle 6 kopiert. Setup: Opus 4.8, /effort ultracode, /goal. Ich konfigurierte beide und ging weg.

TLDR: Ein Agent "verbessert" nicht einfach Dinge. Er optimiert auf die Abschlussbedingung, die du ihm gibst. Eine vage Bedingung bringt vage Ergebnisse. Ein schlechter Prompt findet den kürzesten Weg zu "fertig", was manchmal der falsche Weg ist. 🤓 Diese Sessions haben gezeigt, wo dieser Unterschied zum Tragen kommt.

Büroangestellter gerät in Panik am Computer mit fast aufgebrauchten KI-Credits, während eine Superhelden-Figur selbstbewusst den Fortschritt autonomer Agenten überwacht
Deine KI-Credits verbrennen sich nicht von selbst. Du machst das.

Opus 4.8, /effort ultracode, /goal

Das Trio braucht etwas Erklärung, bevor die Sessions Sinn ergeben.

Opus 4.8 ist das einzige Claude-Modell, das mit xhigh Reasoning kompatibel ist, und es hat ein 1M Token Context-Fenster. Der zweite Teil ist wichtig, wenn du ihm 118.000 Zeilen TypeScript gibst und sagst, er soll seinen eigenen Weg hindurch finden.

/effort ultracode ist eine Session-Einstellung in Claude Code, veröffentlicht am 28. Mai mit v2.1.154. Die Aktivierung schaltet xhigh Reasoning ein und aktiviert Dynamic Workflows automatisch. Claude entscheidet selbst, wann eine Unteraufgabe es wert ist, auf parallele Subagenten aufgeteilt zu werden: bis zu 16 gleichzeitig auf einer Standard-Maschine, bis zu 1.000 pro Durchlauf. Manche Subagenten greifen das Problem aus unabhängigen Blickwinkeln an. Andere versuchen, die Schlussfolgerungen des ersten Durchgangs zu widerlegen und iterieren, bis die Ergebnisse konvergieren. Adversarial Verification, im Grunde (ein Raid-Team, bei dem die Hälfte der Gruppe speziell da ist, um die andere Hälfte zu wipen). Zwischenergebnisse leben in Script-Variablen, nicht im Haupt-Context-Fenster, sodass der primäre Context schlank bleibt, während die Arbeit sich aufteilt. Ich bin darauf eingegangen, warum die CLI-native Architektur verändert, was für autonome Agenten möglich ist in why CLIs outperform MCP for AI agents.

/goal ist verfügbar ab v2.1.139+. Du definierst eine verifizierbare Abschlussbedingung in natürlicher Sprache. Eine separate Haiku-Instanz liest das Session-Transkript nach jedem Turn und antwortet mit ja oder nein plus einem einzeiligen Grund. Falls nein, wird dieser Grund zu Claudes nächster Anweisung. Falls ja, wird das Ziel gelöscht und die Session endet. Ohne /goal: etwa 40 manuelle "mach weiter"-Nachrichten. Mit /goal: Du definierst den Endzustand und gehst weg.

Kombiniere die 3 und du hast eine Session, die stundenlang alleine laufen kann. Was du ihr als Ziel gibst, ist der Teil, der wirklich zählt.

Bevor die erste Zeile sich ändert

Das erste, was der Agent in beiden Sessions tat, war nicht Code schreiben. Es war zählen.

Katalog-Backend: Er fand die projektinterne Testsuite, führte typecheck aus und fixierte die Baseline. 303 Tests bestanden, typecheck grün. Diese Zahlen gingen in die Tracking-Datei, bevor sich sonst etwas bewegte.

Lieferanten-Integration-Session: 404 Tests grün. 701 Lint-Fehler bereits in der Codebase vorhanden, gezählt und aufgezeichnet vor der ersten Änderung.

Das ist keine optionale Zeremonie. Der Mechanismus, der autonomes Refactoring funktionieren lässt, ist derselbe, der es sicher macht: Der Agent optimiert auf die Abschlussbedingung, die du definierst, nicht auf eine abstrakte Vorstellung von besserem Code. Ohne eine bekannte Baseline, die vor dem ersten Commit etabliert wird, gibt es keine Bedingung zum Optimieren und keinen Referenzzustand, zu dem man zurückkehren kann, wenn etwas mid-change kaputt geht. Die Baseline definiert, was grün bedeutet. Darauf zeigt jede Verifikation in der Session zurück. Überspringe sie und der Agent macht Änderungen, die er nicht verifizieren kann, macht weiter, weil nichts dagegen spricht, und bis du das Diff checkst, ist er stundentief ohne sauberen Rückweg. Es dauert Minuten, sie vor dem Anfassen zu etablieren. Sie zu überspringen kann die ganze Session kosten.

Du pullst den Boss nicht ohne deinen Spawn-Point zu setzen. Die Baseline ist der Spawn-Point.

Erstes bemerkenswertes Verhalten im Katalog-Backend: Der Agent spawnte parallele Subagenten, um die Codebase zu mappen, bevor er eine einzige Zeile schrieb. Jeder Fund ging zurück durch grep zur Kreuzprüfung. Er browsete nicht den Code. Er baute einen Fall auf.

Zwei Momente über Verifikation

Phantom-Fehler, Katalog-Backend

Mitten in der Extraktion einer Komponente warf die Konsole einen Fehler: CategoryEditor doppelt definiert. Die Art von Ding, die einen sofort zurückrollen lassen will.

Der Agent führte typecheck aus. Sauber. Greppte nach doppelten Klassendefinitionen in der Codebase. Nichts gefunden. Lud die tatsächliche Seite in einem Browser: sie renderte korrekt.

Es war ein Dev-Server-Artefakt, ein Geist aus dem Übergang zwischen alten und neuen Modulpfaden während der Extraktion. Ein Neustart beim nächsten Checkpoint: null Fehler.

Das Verfahren: typecheck, grep, Browser-Render. Jede Prüfung unabhängig. Ein Konsolenfehler ist Rauschen, bis 2 unabhängige Signale ihm zustimmen. "Es kompiliert" ist kein Live-Test. "Das Terminal hat einmal etwas geworfen" auch nicht.

Ein kleiner Exkurs: Während ich die Supplier-Integration-Session-Logs durchlas, bekam ich eine Slack von einem Kunden wegen einer Rechnung von vor 3 Monaten. Verbrachte 20 Minuten damit, durch E-Mail-Threads zu graben, um das Original zu finden. Währenddessen hatte der Agent 40 Dateien verarbeitet und führte 3 parallele Subagenten aus. Anderer Durchsatz.

Deploy-Verweigerung, Supplier-Integration

An einem Punkt traf die Session auf eine Guardrail, die Produktionszugang blockierte. Der Agent versuchte nicht, sie zu umgehen. Er verifizierte, was er durch die Testsuite konnte, bestätigte, dass die Kernänderungen hielten, und arbeitete durch den verbleibenden Scope ohne den Produktionspfad weiter. Das ist der Unterschied zwischen einem Tool und einer Haftung, und es ist keine kleine Unterscheidung.

Was der Agent entschied nicht anzufassen

Das Katalog-Backend hatte 2 slugify-Funktionen, die fast identisch aussahen. Jedes automatisierte Audit flaggt die als offensichtliche Merge-Kandidaten. Den tatsächlichen Code lesend: 1 behandelt Apostrophe anders, die andere kürzt bei 80 Zeichen ab. Der Unterschied zwischen ihnen ist nicht kosmetisch. Es geht darum, welche Produkte welche URLs bekommen, und diese URLs sind bereits über den Katalog indexiert. Sie zu mergen hätte Live-Produktlinks ohne Warnung umgeschrieben.

Dieselbe Logik galt für 5 Varianten eines Metadata-Parsers, die alle Live-Produktdatensätze umschrieben. Das Audit fand die Duplikation. Den Code zu lesen zeigte, warum jede Variante existierte. Die 10%, die zwischen ihnen divergieren, sind genau die 10%, die für Live-Daten wichtig sind. Der Agent flaggte alle 5, mergte nichts und machte weiter.

Das Convex-Backend war eine härtere Entscheidung. Es läuft in einer einzigen Umgebung, was bedeutet Dev ist Prod. Ein Live-Test erfordert Deployment in die Produktion. Der potenzielle Gewinn war kosmetisches Cleanup. Das Risiko war nicht verifizierbar ohne Deploy. Der Agent verschob es, dokumentierte es in der Tracking-Datei und sagte es. Ich bin ehrlich nicht sicher, ob das Refactoring es wert gewesen wäre, selbst mit einer echten Testumgebung, aber das ist ein Urteil, das zu einem Menschen mit vollem Kontext gehört, nicht zu einem Agent, der ohne Aufsicht läuft.

Die Supplier-Integration-Session endete mit 334 Lint-Fehlern noch an Ort und Stelle. Diese 334 waren bereits da, bevor die Session startete, verteilt über Hunderte von Dateien. Sie in Batch zu bereinigen hätte bedeutet, alles für null architektonischen Gewinn anzufassen. Die alten Migrationsskripte sahen tot aus, stellten sich aber als manuelle Notausgänge heraus, die Art, an die man sich nur erinnert, wenn Prod brennt und das automatisierte Failover down ist (frag mich, woher ich das weiß). Der Agent hinterließ eine Notiz und übersprang sie, anstatt für mich zu entscheiden.

"Zufrieden" bedeutet nicht, dass alles angefasst wurde. Es bedeutet, dass die echten Übeltäter adressiert und verifiziert wurden, und alles andere ist entweder riskant zu ändern oder low-value zu fixen. Zusätzliche Arbeit zu erfinden ist Versagen, nicht Sorgfalt.

Der Prompt mit Narben

Der ursprüngliche Prompt, den ich für die Katalog-Backend-Session schickte, hatte Lücken.

Keine Erwähnung von Produktion irgendwo. "Until satisfied" ohne verifizierbaren Endpunkt. "Live-test" ohne Definition dessen, was zählt. Eine "autoreview"-Anweisung, die keinem echten Claude Code-Befehl entspricht.

Jede Lücke mappt zu einem Moment, der anders hätte laufen können. Die slugify-Funktionen wären gemergt worden. Das Convex-Backend hätte angefasst werden können. Der Phantom-Fehler hätte einen Rollback auf ein einziges unbestätigtes Signal ausgelöst.

Diese 2 Sessions produzierten etwas, das es wert ist, behalten zu werden:

/goal Improve this project's architecture through safe, incremental refactoring.
First: discover the project's own check/test/build/run commands (package.json
scripts, Makefile, justfile, CI config, README) and establish a green baseline
with them — record it. Then audit the codebase for concrete debt (dead code,
duplication, oversized files/modules) with grep-level evidence BEFORE touching
anything. If the project isn't green at the start, stop and report instead of
refactoring blind.
Work in priority order of (value × safety × verifiability). For each step:
  1. one coherent change,
  2. live-test through the REAL path — exercise the change end-to-end for THIS
     project type (browser for a web app, run the CLI/binary, the test suite for
     a library, a real request for an API, a dry-run for a cron). "It compiles"
     is NOT a live-test,
  3. run /code-review on the diff and address its findings,
  4. commit (conventional message, stage by path).
Hard constraints:
  - Production code: prefer surgical, reversible changes over rewrites.
  - Never change a public contract (API paths, published URLs, output formats)
    or any externally observable behavior.
  - Never refactor anything you cannot verify green. If you can't safely
    live-test it, DEFER it and say so explicitly.
  - If reading the real code shows a duplication or variation exists for a
    reason, skip the "cleanup."
Done when the remaining debt is either risky or low-value — don't manufacture work.
Track progress in ~/tmp/refactor-<project>.md (derive <project> from the repo):
log every step, every decision, AND every item you deliberately rejected with why.
Don't push or deploy without asking.

Jede Klausel ist eine Narbe von einer Session, die sie nicht hatte.

Darum geht es beim full prompt contracts framework wirklich: nicht Struktur um ihrer selbst willen, sondern Constraints, die daher kommen, dass etwas schief ging.

Deine Kredite verfallen heute Nacht

Was die 2 Sessions tatsächlich produzierten:

Katalog-Backend: 4 saubere Commits, 2 aufgeblähte Dateien reduziert, Tests von 303 auf 313, netto -57 Zeilen. Null kaputt in Produktion.

Supplier-Integration: +288/-711 Zeilen, Tests von 404 auf 407, eine tote 504-Zeilen-Komponente entfernt, Lint von 701 runter auf 334 Fehler.

Wenn du tiefer in die Methode einsteigen willst, Vibe Coding, For Real deckt den Schritt-für-Schritt-Ansatz ab, echte Projekte mit AI zu shippen. Kostenlos auf Kindle Unlimited.

Dein Reset kommt. Die Kredite in deinem Dashboard sind bereits bezahlt.

Die Architektur deiner Projekte zu verbessern ist die beste Nutzung verfallender Kredite.

Quellen

Dieser Post kann Affiliate-Links enthalten. Wenn du sie anklickst, verdiene ich möglicherweise eine kleine Provision (kostet dich nichts und hilft mir dabei, weiterhin täglich Qualitätsartikel für dein Lesevergnügen zu liefern).