# Code-Performance mit KI optimieren: erst messen

URL: https://agentvera.dev/de/blog/optimize-code-performance-with-ai/ · Veröffentlicht: 2026-10-27

Code-Performance mit KI-Agenten optimieren: erst profilen, dem Agenten echte Profile geben, N+1-Queries und Bundle-Ballast beheben, jeden Gewinn per Benchmark belegen.

**Kurz gesagt:**

- Bitte einen Agenten nie ohne Daten, „es schneller zu machen“. Profile zuerst mit Chrome DevTools, Lighthouse, node --cpu-prof, py-spy oder cProfile und gib dem Agenten das Profil, nicht deine Vermutung.
- Schreib vor der Änderung einen Benchmark oder eine wiederholbare Messung; das ist der Verifikationsschritt. Eine Änderung, die die Zahl nicht bewegt, wird zurückgenommen, egal wie clever sie aussieht.
- Die großen Gewinne sind meist unspektakulär: N+1-Queries, fehlende Indizes, zu große Bundles, wiederholte Arbeit, die sich cachen lässt. Agenten finden und beheben das gut, wenn sie die Belege sehen.
- Sichere Gewinne mit Regressionsschutz ab: Assertions zur Query-Anzahl, Bundle-Größenbudgets und Benchmarks in der CI, damit die nächste Änderung die Arbeit nicht still zunichtemacht.

**Um Code-Performance mit KI zu optimieren, misst du, bevor du promptest: Profile den langsamen Pfad, gib dem Agenten das Profil, bitte um die kleinste Änderung, die den Hotspot beseitigt, und akzeptiere sie nur, wenn ein Benchmark den Unterschied zeigt.** Coding-Agenten wie Claude Code, Codex und Gemini CLI lesen schnell einen Flame Graph, verfolgen eine heiße Funktion zurück zu ihren Aufrufern und schreiben eine Query um. Ohne Daten machen sie, was jeder macht: raten. Und geratene Optimierungen sind die teure Sorte, weil sie Code schwerer lesbar machen, ohne ihn schneller zu machen.

Diese Anleitung beschreibt einen Ablauf, der sich in der Praxis bewährt: Ziel festlegen, profilen, die Belege übergeben, eine Sache ändern, per Benchmark verifizieren und den Gewinn mit einem Regressionsschutz festhalten. Unterwegs geht es um die Probleme, die in echten Apps die meisten Verlangsamungen verursachen: N+1-Queries, Bundle-Größe und fehlende Caches.

## Mit einer Zahl anfangen, nicht mit einem Gefühl

„Das Dashboard ist langsam“ ist keine Aufgabe. Mach daraus etwas, das ein Agent prüfen kann:

- **Was** langsam ist: ein Endpoint, ein Seitenaufruf, ein CLI-Befehl, ein Batch-Job.
- **Wie langsam** es jetzt ist, gemessen: p95-Latenz eines Endpoints, Time to Interactive einer Seite, Laufzeit eines Skripts.
- **Was „schnell genug“ heißt**: ein Ziel wie „unter 300 ms bei p95“ oder „der Import ist bei 100.000 Zeilen in unter einer Minute fertig“.
- **Unter welchen Bedingungen**: Datenmenge, kalter oder warmer Cache, Production-Build oder Dev-Server.

Der letzte Punkt verhindert viel verschwendete Arbeit. Eine React-App auf dem Dev-Server, ein Node-Service ohne `NODE_ENV=production` oder ein Python-Job auf zehn Zeilen Testdaten zeigt Hotspots, die es in Produktion nicht gibt. Miss das, was du auslieferst.

## Schritt 1: den langsamen Pfad profilen

Wähle den Profiler, der dazu passt, wo die Zeit verloren geht.

### Im Browser

Das **Performance**-Panel in den Chrome DevTools zeichnet einen Trace auf: lange Tasks, Scripting, Layout, Netzwerk-Wasserfälle. **Lighthouse** liefert einen Labor-Score mit konkreten Verbesserungsmöglichkeiten. Das Lighthouse-CLI ist praktisch, weil es eine Datei schreibt, die du einem Agenten geben kannst:

```bash
npm install -g lighthouse
lighthouse https://localhost:3000/dashboard \
  --only-categories=performance \
  --output=json --output-path=./lighthouse.json
```

Wenn dein Agent MCP unterstützt, kann er über den Chrome-DevTools-MCP-Server selbst einen Performance-Trace starten und die Auswertung lesen:

```json
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}
```

### In Node.js

Node hat einen eingebauten Sampling-Profiler. `--cpu-prof` schreibt beim Beenden des Prozesses eine `.cpuprofile`-Datei, die du im Performance-Panel der DevTools öffnen oder einem Agenten geben kannst:

```bash
node --cpu-prof --cpu-prof-dir=./profiles server.js
# run the slow request a few times, then stop the server
```

Das ältere Flag `--prof` schreibt ein V8-Log, das `node --prof-process` in einen Textbericht umwandelt, den ein Agent sehr leicht lesen kann:

```bash
NODE_ENV=production node --prof server.js
node --prof-process isolate-0x*-v8.log > processed.txt
```

Bei Speicherproblemen schreibt `--heap-prof` auf dieselbe Weise eine `.heapprofile`-Datei.

### In Python

`py-spy` sampelt einen laufenden Prozess, ohne deinen Code zu ändern, und ist damit die sichere Wahl für einen Live-Service:

```bash
py-spy top --pid 12345                    # live view, like top
py-spy record -o profile.svg --pid 12345  # flame graph
py-spy record -o profile.svg -- python import_job.py
```

Für ein Skript, das du selbst startest, liefert `cProfile` aus der Standardbibliothek exakte Aufrufzahlen:

```bash
python -m cProfile -s cumtime import_job.py | head -40
```

Stand Oktober 2026 bringt Python 3.15 außerdem ein Paket `profiling` mit einem statistischen Profiler (`python -m profiling.sampling`) mit und behält `cProfile` als Alias seines Tracing-Profilers; in älteren Versionen sind `cProfile` und py-spy die Werkzeuge der Wahl.

### In der Datenbank

Bei Query-Zeit kennt die Datenbank die Antwort bereits: das Slow-Query-Log, `pg_stat_statements` bei PostgreSQL und `EXPLAIN ANALYZE` für eine einzelne Query. [SQL mit KI schreiben](/de/blog/write-sql-with-ai/ "SQL mit KI schreiben") erklärt, wie du mit einem Agenten Query-Pläne liest und Indizes wählst, deshalb wiederholt diese Anleitung das nicht.

## Schritt 2: dem Agenten die Belege geben

Jetzt hat der Agent etwas Echtes, mit dem er arbeiten kann. Übergib das Profil und den Kontext und bitte um eine Analyse vor dem Code:

```text
Der Endpoint /api/orders braucht in Produktion etwa 1,8 s bei p95; das Ziel
sind 300 ms. Angehängt: processed.txt aus node --prof-process für 50 Requests
und das Slow-Query-Log für denselben Zeitraum.
Ändere noch keinen Code. Liste die drei größten Hotspots auf, jeweils mit dem
Beleg aus dem Profil (Funktion, Self Time oder Total Time, Anzahl Aufrufe),
der wahrscheinlichen Ursache in unserem Code (Datei und Zeile) und einem
Vorschlag für den Fix. Sortiere sie nach erwartetem Effekt.
```

Ein paar Gewohnheiten lassen diesen Schritt funktionieren:

- **Gib ihm die Rohausgabe, nicht deine Zusammenfassung.** Deine Zusammenfassung enthält schon deine Vermutung.
- **Verlange einen Beleg für jede Behauptung.** „Diese Funktion ist langsam“ sollte mit einer Zahl aus dem Profil kommen.
- **Halte den Agenten im heißen Pfad.** Code, der 2 % der Zeit kostet, ist kein Rewrite wert, egal wie hässlich er ist.

Wenn der Agent etwas sagt wie „das Profil zeigt den Engpass nicht klar“, glaub ihm und zeichne ein besseres Profil auf, mit mehr Last oder dem Production-Build. Das ist ein viel besseres Ergebnis als eine selbstsichere Vermutung.

## Schritt 3: den Benchmark vor dem Fix schreiben

Der Benchmark ist dein Verifikationsschritt. Schreib ihn, führe ihn auf dem aktuellen Code aus und speichere die Baseline, bevor sich irgendetwas ändert.

Für einen Befehl oder ein Skript führt `hyperfine` den Aufruf viele Male aus und meldet Mittelwert und Streuung:

```bash
hyperfine --warmup 3 'node scripts/build-report.js'
```

Für eine Funktion nutzt du die Benchmark-Unterstützung deines Stacks: `go test -bench=. -benchmem` in Go, `pytest-benchmark` in Python, die Bench-Unterstützung deines JavaScript-Test-Runners. Für einen Endpoint einen kurzen Lasttest mit einer festen Anzahl Requests gegen einen Production-Build.

Dann sagst du dem Agenten die Regel:

```text
Hier ist der Benchmark mit seinem Baseline-Ergebnis. Mach eine Änderung nach
der anderen. Führe nach jeder Änderung die Tests und den Benchmark dreimal
aus und melde vorher/nachher. Wenn eine Änderung das Ergebnis nicht über das
Rauschen hinaus verbessert, nimm sie zurück und sag es mir, auch wenn du
glaubst, dass sie helfen sollte.
```

Zwei Details zählen. Vergleiche auf derselben Maschine mit denselben Daten, denn Laptops drosseln und Caches wärmen sich auf. Und lass die Tests neben dem Benchmark mitlaufen: Eine schnellere Funktion, die die falsche Antwort liefert, ist ein Bug. Wenn der Code, den du optimierst, keine Tests hat, schreib sie zuerst; [Unit-Tests mit KI schreiben](/de/blog/write-unit-tests-with-ai/ "Unit-Tests mit KI schreiben") zeigt, wie du von einem Agenten brauchbare bekommst.

## Wo die Zeit meistens hingeht

In echten Apps erklärt eine kleine Gruppe von Problemen die meisten Verlangsamungen. Diese prüfst du zuerst.

### N+1-Queries

Der Klassiker: eine Liste laden und dann pro Eintrag eine zusätzliche Query in einer Schleife oder einem Template ausführen. Mit zehn Zeilen in der Entwicklung sieht das gut aus, mit zweitausend in Produktion bricht es ein. Der Fix ist, die zugehörigen Daten in ein oder zwei Queries zu laden, mit dem Werkzeug, das dein ORM bietet:

| Stack | Eager Loading |
| --- | --- |
| Django | `select_related` (Joins), `prefetch_related` (separate Query) |
| Rails | `includes`, dazu das Bullet-Gem, das N+1 in der Entwicklung erkennt |
| SQLAlchemy | `selectinload`, `joinedload` |
| Prisma | `include` |

Agenten sind gut in diesem Fix, sobald sie wissen, wo das Problem auftritt. Schalte das Query-Logging ein, öffne die langsame Seite einmal und gib dem Agenten das Log: Ein wiederholtes Query-Muster mit unterschiedlichen IDs ist der Fingerabdruck. Dann bittest du um den Fix und um einen Test, der die Anzahl der Queries auf dieser Seite prüft, damit das Problem nicht unbemerkt zurückkommt.

### Bundle-Größe

Bei Frontend-Performance ist das ausgelieferte JavaScript oft der größte Hebel. Miss zuerst, was im Bundle steckt, mit `source-map-explorer` oder `webpack-bundle-analyzer` (oder dem Analyzer für deinen Bundler), und such dann nach den üblichen Ursachen:

- eine große Bibliothek, importiert für eine einzige Funktion,
- ein ganzes Icon-Set oder Locale-Paket, das ein einzelner Import hereinzieht,
- schwere Komponenten, die beim ersten Rendern geladen werden, aber per Lazy Loading kommen könnten,
- dieselbe Abhängigkeit zweimal im Bundle, in unterschiedlichen Versionen.

Gib dem Agenten die Ausgabe des Analyzers und bitte um Änderungen, sortiert nach eingesparten Bytes. Dann vergleichst du die Build-Ausgabe vorher und nachher, genauso wie bei einem Benchmark.

### Wiederholte Arbeit und Caching

Ein Cache ist die richtige Antwort, wenn dasselbe teure Ergebnis immer wieder mit denselben Eingaben berechnet wird. Er ist die falsche Antwort, wenn sich die Berechnung einfach billig machen ließe oder wenn niemand entschieden hat, was passiert, wenn sich die Daten ändern. Bevor du einen Cache von einem Agenten akzeptierst, frag ihn:

```text
Zu diesem Cache: Was ist der Schlüssel, was invalidiert ihn, wie veraltet
dürfen die Daten höchstens sein, wie viel Speicher darf er nutzen, und was
passiert bei einem Kaltstart? Zeig mir die gemessene Trefferquote oder das
Profil, das ihn rechtfertigt.
```

Wenn die Antworten vage sind, wird der Cache später zum Bug-Report. Oft liegt der bessere Fix weiter vorne in der Kette: ein fehlender Index, eine Query, die jede Spalte holt, eine Schleife, die bei jedem Durchlauf denselben Wert neu berechnet.

### Algorithmische Probleme

Manchmal zeigt das Profil eine einzige Funktion mit riesiger Aufrufzahl: eine verschachtelte Schleife über zwei Listen, ein `.find()` in einem `.map()`, eine Sortierung in einer Schleife. Eine lineare Suche durch eine `Map` oder ein `Set` zu ersetzen, ist ein klassischer Agenten-Fix, und der Benchmark sagt dir sofort, ob es etwas gebracht hat.

## Vorzeitige und spekulative Optimierung vermeiden

Agenten optimieren leidenschaftlich gern. Bitte einen, die Performance einer Datei „zu verbessern“, und er memoisiert Komponenten, schreibt Schleifen um und baut überall Caches ein. Die meisten dieser Änderungen bewegen nichts Messbares und machen den Code schwerer änderbar. Regeln, die du klar in deine Projektanweisungen schreiben solltest:

```markdown
## Performance-Arbeit
- Keine Optimierung ohne ein Profil oder einen Benchmark, der das Problem zeigt.
- Eine Änderung pro Commit, mit Vorher/Nachher-Zahlen in der Nachricht.
- Lesbarkeit geht vor Mikrooptimierungen außerhalb gemessener heißer Pfade.
- Füge keine Caches, Worker oder neuen Abhängigkeiten hinzu, ohne zu fragen.
```

Dasselbe gilt für Vorschläge des Agenten während anderer Arbeit. Wenn er mit „bei der Gelegenheit habe ich auch … optimiert“ kommt, frag nach den Zahlen oder lass ihn die Änderung zurücknehmen. Wenn nach einer Optimierung doch etwas kaputtgeht, zeigt [Code mit KI debuggen](/de/blog/debug-code-with-ai/ "Code mit KI debuggen"), wie du den Fehler eingrenzt, ohne zu raten.

## Schritt 4: den Gewinn absichern

Performance verschlechtert sich leise, eine vernünftige Änderung nach der anderen. Mach aus jedem Fix einen Check, der laut fehlschlägt:

- **Tests zur Query-Anzahl.** Prüfe, dass die Bestellseite höchstens eine feste Anzahl Queries ausführt. Die meisten Frameworks haben dafür einen Helfer, etwa `assertNumQueries` in Django.
- **Bundle-Budgets.** Tools wie `size-limit` lassen den Build fehlschlagen, wenn ein Bundle über eine festgelegte Größe wächst.
- **Lighthouse in der CI.** Führe das Lighthouse-CLI gegen einen Preview-Build aus und lass den Lauf auf den wichtigen Seiten unter einem Score-Schwellenwert fehlschlagen.
- **Benchmarks gegen eine Baseline.** Speichere die Baseline und vergleiche; in Go vergleicht `benchstat` zwei Benchmark-Läufe und sagt dir, ob der Unterschied signifikant ist.

Agenten schreiben solche Schutzmaßnahmen gut, und es lohnt sich, in derselben Aufgabe wie den Fix darum zu bitten: „Behebe das N+1 und schreib einen Test, der es erkannt hätte.“

## So geht es in AgentVera

AgentVera ist eine Desktop-App, die Coding-Agent-CLIs wie Claude Code, Codex und Gemini CLI nebeneinander ausführt. Mehrere Funktionen passen zu dieser Schleife:

- **Ein Browser, den der Agent steuern kann.** Der [Agenten-Browser](/de/features/agent-browser/ "Agenten-Browser") ist ein separates Chrome-Profil, das Agenten über Playwright MCP nutzen, mit eingebauten DevTools und Konsole, so dass der Agent die langsame Seite selbst öffnen kann und du zusehen kannst.
- **Belege mit einem Shortcut senden.** [An Agent senden](/de/features/send-to-agent/ "An Agent senden") (⌘⇧L) schickt Terminalausgabe, eine Auswahl im Editor, einen Diff oder die Browserkonsole an einen Agenten. Profiler-Ausgabe im Terminal landet so ohne Kopieren und Einfügen beim Agenten; sehr lange Ausgaben werden bei 12.000 Zeichen abgeschnitten, also schick den Anfang des Berichts oder speichere ihn in einer Datei.
- **Query-Pläne neben dem Code.** Der [Datenbank-Manager](/de/features/database-manager/ "Datenbank-Manager") (Pro) öffnet PostgreSQL, MySQL und SQLite mit einem SQL-Editor, der EXPLAIN-Pläne zeigt, und Agenten können die Datenbank über sein eingebautes Werkzeug abfragen.
- **Benchmarks als Abnahmekriterien.** Schreib „die Tests bestehen und der Benchmark ist mindestens 30 % schneller als die Baseline“ in deine Nachricht, und [Verify](/de/features/verify/ "Verify") prüft das am Ende des Turns mit einem Verifier, der Befehle ausführt, aber keine Dateien bearbeiten kann.
- **Eine Optimierung zurücknehmen, die sich nicht gelohnt hat.** [Checkpoints](/de/features/checkpoints-and-replay/ "Checkpoints und Replay") sichern jeden Turn, so dass du ein Experiment mit einem Klick zurücknimmst.
- **Zwei Ansätze gleichzeitig ausprobieren.** Im Raster des [Workspace](/de/features/workspace/ "Workspace") laufen zwei Agenten in getrennten Worktrees, etwa einer am Caching und einer an der Query, und du behältst den mit den besseren Zahlen.

## Fazit

Code-Performance mit KI zu optimieren ist dieselbe Disziplin wie ohne KI, nur schneller: ein klares Ziel, ein Profil, die übergebenen Belege, eine Änderung nach der anderen, ein Benchmark als Beweis und ein Schutz, der den Gewinn hält. Der Agent übernimmt das Lesen und Umschreiben; die Zahlen entscheiden. Wenn deine Verlangsamung mit einem Dependency-Upgrade kam, hilft dir der Ablauf in [Abhängigkeiten mit KI aktualisieren](/de/blog/upgrade-dependencies-with-ai/ "Abhängigkeiten mit KI aktualisieren"), das verantwortliche Paket zu isolieren.

Um diesen Ablauf an deinem eigenen Projekt auszuprobieren, [lade AgentVera herunter](/de/download/ "AgentVera herunterladen").

## Häufige Fragen

**Kann ein KI-Agent Performance-Probleme durch Lesen des Codes finden?** Er kann wahrscheinliche Verdächtige nennen, etwa eine Query in einer Schleife, aber er kann nicht wissen, welcher davon bei deinen Daten und deinem Traffic zählt. Gib ihm ein Profil, ein Slow-Query-Log oder einen Trace, dann kann er sich auf den Code konzentrieren, der wirklich Zeit kostet.

**Welchen Profiler sollte ich nutzen?** Im Browser das Performance-Panel der Chrome DevTools und Lighthouse. Für Node.js node --cpu-prof, das eine .cpuprofile-Datei schreibt, die du in den DevTools öffnen kannst. Für Python py-spy für laufende Prozesse und cProfile für ein Skript, das du selbst startest.

**Woran erkenne ich, dass die Optimierung gewirkt hat?** Miss dasselbe vorher und nachher, jeweils mehrere Läufe, auf derselben Maschine. Ein Benchmark-Tool wie hyperfine für Befehle oder die Benchmark-Unterstützung deines Test-Frameworks übernimmt die wiederholten Läufe. Liegt der Unterschied im Rauschen, hat es nicht gewirkt.

**Warum schlagen Agenten Optimierungen vor, die nichts bringen?** Ohne Messungen greift ein Modell auf allgemeine Ratschläge zurück: dies memoisieren, eine schnellere Schleife nehmen, einen Cache einbauen. Solche Änderungen machen den Code komplexer und bewegen oft nichts. Frag nach dem Beleg für jeden Vorschlag und lehne alles ab, was nicht an einem gemessenen Hotspot hängt.

**Wie verhindere ich, dass die Performance wieder schlechter wird?** Mach aus jedem Fix einen Check: einen Test, der die Anzahl der Queries auf einer Seite prüft, ein Bundle-Größenbudget in der CI oder einen Benchmark, der mit einer Baseline verglichen wird. Der Check schlägt fehl, bevor die Regression die Nutzer erreicht.

---

**Über AgentVera.** AgentVera ist eine Desktop-App für macOS, Windows und Linux, entwickelt von Solviera Teknoloji. Sie führt 18 KI-Coding-Agenten (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) nebeneinander aus, pro Projekt, in echten Terminals mit den eigenen CLI-Installationen und Logins des Nutzers. Der kostenlose Plan hat unbegrenzt viele Agenten. Download: https://agentvera.dev/de/download/ · Preise: https://agentvera.dev/de/pricing/