Ich schreibe nur noch 20 % Code selbst

An einem normalen Arbeitstag schreibe ich vielleicht 20 Prozent des Codes selbst. Den Rest generiert eine KI, und ich entscheide, ob er richtig ist.

Das klingt nach Zukunft. Ist aber mein Alltag seit Monaten.

Die Arbeit hat sich verschoben: weniger tippen, mehr lesen, mehr entscheiden. Tatsächlich ist es vor allem viel Sprechen – ich diktiere Aufgaben, beschreibe Kontext, formuliere Korrekturen. Die Tastatur ist nicht mehr das primäre Eingabegerät.

Wer mich bei der Arbeit beobachtet, sieht jemanden, der mit seinem Terminal redet (auf dem Walking Pad), gelegentlich durch Diffs scrollt und ab und zu den Kopf schüttelt. Von außen betrachtet könnte man meinen, ich arbeite weniger. In Wirklichkeit treffe ich mehr Entscheidungen pro Stunde als früher.

Ich liefere Kontext und Architektur, stückweise, in verdaubaren Aufgaben. Wenn ich korrigiere, fließt das Feedback ins Memory oder wird zum Skill, sobald es Projektstandard werden soll. Und ehrlich gesagt – es ist anstrengender als vorher. Nicht, weil die Tools schlecht wären. Sondern weil Review fremden Codes mehr Aufmerksamkeit erfordert als den eigenen zu prüfen. Aber genau das macht das Ergebnis besser – eigenen Code reviewt man oft mit weniger Sorgfalt, weil man glaubt, ihn zu kennen.

Der eigentliche Unterschied ist nicht Geschwindigkeit

Welches Tool wann passt — Claude Code, Codex, Mistral und warum ich zwei davon gleichzeitig nutze — habe ich in Teil 2 dieser Serie ausführlich beschrieben. Hier geht es nicht um den Vergleich, sondern um den Alltag.

Wo alle scheitern

An Architektur. An Naming-Entscheidungen. Am Nachdenken über Datenmodelle. Am Verstehen, warum ein Kunde etwas will und nicht nur, was er beschreibt.

Wer glaubt, „KI macht den Code, ich mache den Rest”, unterschätzt den Rest.

Mein Setup: Zed + CLI-Agenten

Ich habe Ende 2025 die Geduld mit JetBrains verloren. Zu langsam, zu aufgebläht, zu viele Features, die ich nicht brauche, und zu wenige, die ich brauche. Der Wechsel zu Zed war einer der besten Entscheidungen des letzten Jahres.

Zed ist schnell. Nicht „schnell für eine IDE”, sondern wirklich schnell — Start in unter einer Sekunde, kein Lag bei großen Dateien, kein Warten auf Indizierung. Aber was Zed für mein Setup besonders macht: Es spielt perfekt mit CLI-Agenten zusammen. Zed ist ein Editor, der sich nicht zwischen mich und mein Terminal drängt. Kein eingebauter KI-Assistent, der mit meinen CLI-Tools konkurriert. Stattdessen eine IDE, die schnell genug ist, um mit dem Tempo der Agenten mitzuhalten — Dateien öffnen, Änderungen reviewen, weiter.

Dazu kommt Refactoring — mal mit KI, mal bewusst ohne. Und oft lasse ich einen Agenten als Kritiker gegen gerade entstandenen Code laufen: nicht um zu generieren, sondern um zu prüfen, zu hinterfragen, Schwächen aufzuzeigen. Dieser Prüfprozess gegen den eigenen Output ist einer der unterschätzten Produktivitätsgewinne.

Die Entwicklungssprünge bei Zed sind ein eigenes Thema. Die aktuelle KI-Integration, die Multiplayer-Features, die Extension-API — dazu gibt es einen separaten Artikel. Hier nur so viel: Für Entwickler, die primär mit CLI-Agenten arbeiten, gibt es gerade keine bessere IDE.

Memory und Skills: Was über den Prompt hinausgeht

Kontext-Dateien, Agenten-Trends und Multi-Agent-Workflows habe ich in Teil 2 behandelt. Hier der Teil, der den Alltag am stärksten verändert hat: Memory und Skills.

Dazu kommen Skills — wiederverwendbare Prompt-Templates, die man per Slash-Command aufruft. /new-endpoint scaffoldet einen neuen Axum-Handler mit Extractor, Error-Type und zugehörigem Test. /add-migration erstellt eine SQLx-Migration mit Up- und Down-Script nach den Projektkonventionen. Das sind keine generischen Prompts, sondern projektspezifische Workflows, die ich einmal definiere und danach konsistent nutze. Skills ersetzen die informelle Prompt-Bibliothek, die man sich sonst in Notizen zusammensammelt — nur dass sie direkt im Projekt leben und versioniert werden können. Ich liefere Skills inzwischen auch in meinen Open-Source-Projekten mit aus, damit andere Entwickler sofort produktiv arbeiten können. Mittlerweile gibt es auch Standard-Skills für gängige Anwendungsfälle, die als offizielle Hilfen veröffentlicht werden — Skills werden damit Teil des Ökosystems, nicht nur des eigenen Workflows.

Was den Unterschied macht: die Kontext-Datei

Alle CLI-Agenten arbeiten besser mit einer Projektbeschreibung. Bei Claude Code ist das eine CLAUDE.md im Projekt-Root, bei Cursor eine .cursorrules. Das Prinzip ist dasselbe: dem Agenten erklären, wie das Projekt aufgebaut ist.

# Projekt: E-Commerce Backend

## Stack
- Runtime: Node.js 22
- Framework: Fastify
- DB: PostgreSQL + Prisma
- Validation: Zod
- Tests: Vitest + Testcontainers
- Sprache: TypeScript (strict)

## Konventionen
- Error Handling: Result-Pattern (src/lib/result.ts)
- Kein `any`. Immer explizite Return-Types.
- API-Endpunkte in src/routes/, ein File pro Resource
- Tests neben der Datei: orders.ts → orders.test.ts

## Wichtige Dateien
- prisma/schema.prisma: Datenmodell
- src/lib/result.ts: Result<T, E> Utility
- src/lib/errors.ts: Error-Typen

Diese Datei liest der Agent automatisch. Je besser sie ist, desto konsistenter der generierte Code. Die 30 Minuten, die man dafür investiert, sind die beste Zeitinvestition im gesamten Setup.

Drei Szenarien aus dem Alltag

Die Tool-Beschreibungen oben sind Theorie. In der Praxis wird es unordentlicher. Drei Situationen, die regelmäßig vorkommen – und was dabei wirklich passiert.

Szenario 1: Refactoring über mehrere Dateien

Die Aufgabe: Ein UserService ist über die Monate gewachsen. 400 Zeilen, fünf verschiedene Verantwortlichkeiten, drei Methoden, die eigentlich in einen NotificationService gehören.

# Prompt an Claude Code:
> Lies src/services/UserService.ts. Extrahiere alle
  Notification-Methoden (sendWelcomeEmail, sendPasswordReset,
  sendOrderConfirmation) in einen neuen NotificationService.
  Passe alle Imports an, die den UserService für Notifications
  nutzen. Halte die bestehenden Tests lauffähig.

# Was Claude Code tut:
# 1. Liest UserService.ts und alle Dateien, die ihn importieren
# 2. Erstellt src/services/NotificationService.ts
# 3. Verschiebt die drei Methoden mit allen Abhängigkeiten
# 4. Aktualisiert 8 Import-Statements in anderen Dateien
# 5. Passt die Tests an: UserService-Tests bleiben, neue
#    NotificationService-Tests werden erstellt

Was ich manuell prüfe: Sind die Abhängigkeiten sauber getrennt? Gibt es zirkuläre Imports? Hat der UserService noch Methoden, die den NotificationService kennen sollten, es aber nicht mehr tun?

Die eigentliche Arbeit sind 5 Minuten Review. Das Verschieben, Imports-Fixen und Tests-Anpassen – das ist der Teil, der ohne KI 45 Minuten dauert und null kognitive Leistung erfordert.

Szenario 2: Bug-Suche in fremdem Code

Die Aufgabe: Ein Kunde meldet, dass die Bestellbestätigung manchmal keine Versandkosten anzeigt. Der Code ist nicht von mir, das Projekt ist sechs Monate alt.

# Prompt an Claude Code:
> In der Bestellbestätigung fehlen manchmal die Versandkosten.
  Finde heraus, wo die Versandkosten berechnet werden, wo sie
  in die Bestätigungs-Mail eingesetzt werden und unter welchen
  Bedingungen der Wert leer sein könnte.

# Claude Code durchsucht die Codebase:
# - Findet calculateShipping() in src/lib/shipping.ts
# - Findet die E-Mail-Template-Logik in src/emails/orderConfirmation.tsx
# - Findet den Aufruf in src/routes/checkout.ts
# - Identifiziert: Bei Abholung im Laden (pickup) gibt
#   calculateShipping() null zurück, und das Template
#   rendert null als leeren String statt "0,00 €"

# Dann gezielt:
> Fixe das Problem: Wenn shippingCost null ist und die
  Lieferart "pickup" ist, zeige "Abholung – kostenlos" an.
  Wenn shippingCost aus einem anderen Grund null ist,
  logge einen Fehler. Schreibe einen Test für beide Fälle.

Ohne KI hätte ich 20 Minuten mit grep und Datei-Lesen verbracht, um die Kette von der Berechnung bis zum Template zu verstehen. Die KI macht das in 30 Sekunden und erklärt mir den Datenfluss dazu.

Szenario 3: Tests nachrüsten für Legacy-Code

Die Aufgabe: Ein Modul mit 12 Funktionen hat null Tests. Bevor ich etwas ändere, will ich eine Baseline.

# Prompt an Claude Code:
> Lies src/lib/pricing.ts komplett. Schreibe Unit-Tests
  für jede exportierte Funktion. Nutze Vitest. Teste
  Normalfälle und Grenzwerte (0, negative Werte, undefined).
  Orientiere dich am Teststil in src/lib/__tests__/cart.test.ts.

# Claude Code generiert:
# - src/lib/__tests__/pricing.test.ts
# - 34 Testfälle für 12 Funktionen
# - Inkl. Edge Cases: Rabatt > 100%, Preis = 0,
#   fehlende Pflichtfelder

# Tests laufen lassen:
> Führe die neuen Tests aus.

# 31 pass, 3 fail.
# Die 3 Fails zeigen echte Bugs:
# - calculateDiscount() crasht bei negativem Preis
# - applyVoucher() akzeptiert abgelaufene Gutscheine
# - formatPrice() rundet falsch bei 3 Nachkommastellen

Die KI hat nicht nur Tests geschrieben – sie hat durch die Tests drei Bugs gefunden, die seit Monaten im Code schlummerten. Das ist der Punkt, an dem sich Test-Generierung wirklich lohnt: nicht als Abhaken einer Coverage-Metrik, sondern als Diagnose-Tool.

Kosten: Die ehrliche Rechnung

Tool	Fixkosten	Variable Kosten	Typisch gesamt
Copilot Pro	22 Euro	-	22 Euro
Cursor Pro	19 Euro	Pro+ 55 Euro	19-55 Euro
Claude Code (Max)	100-200 Euro	inkl. Token	100-200 Euro
Claude Code (API)	-	20-150 Euro Token	20-150 Euro

Die Zahlen allein sagen wenig. Also die Frage anders stellen:

Wann lohnt es sich? Wenn du mehr als 10 Stunden pro Woche codest, ist Claude Code absurd günstig. 100 Euro im Monat, dafür 2 Stunden am Tag gespart – das ist ein Stundensatz von unter 3 Euro. Kein anderes Werkzeug hat dieses Verhältnis.

Wann lohnt es sich nicht? Wenn du weniger als 10 Stunden pro Woche codest, wirst du nie in den Flow kommen. Die Lernkurve frisst den Gewinn. Copilot reicht dann.

Was die Tabelle nicht zeigt:

Lernzeit: 10-20 Stunden in den ersten 2 Monaten. Die ersten Prompts sind zu vage oder zu spezifisch – man muss das richtige Maß finden.
Context-Pflege: CLAUDE.md, .cursorrules aktuell halten – 30 Minuten pro Woche. Klingt wenig, wird oft vergessen, rächt sich sofort.
Review-Overhead: KI-generierter Code braucht aufmerksames Review. Nicht mehr als menschlicher Code – aber man darf nicht nachlässig werden, nur weil „die KI es geschrieben hat”.
Sackgassen: Wenn die KI Mist liefert, suche ich inzwischen den Fehler bei mir. Meistens war die Aufgabe nicht klein genug oder der Kontext zu dünn. Mit der richtigen Aufteilung passiert das selten.

Die häufigsten Stolperfallen

KI-generierter Code kompiliert, Tests laufen – aber er enthält subtile Probleme:

// KI hat generiert:
const data = await fetch('/api/users').then(r => r.json());

// Problem: Kein Error Handling. Was bei 500? Bei Timeout?
// Was bei ungültigem JSON? Sieht sauber aus, ist fragil.

Regel: KI-Code reviewen wie den Code eines neuen Teammitglieds. Nicht wie den eigenen.

2. Zu viel Kontext auf einmal

# Schlecht:
> Refactore das gesamte Auth-System. Aktuell nutzen wir
  JWT mit Cookies, wechsle auf Session-basierte Auth mit
  Redis. Passe alle Endpunkte, Middleware und Tests an.

# → Agent verliert den Überblick, macht inkonsistente Änderungen

# Besser:
> Erstelle einen neuen SessionService in src/lib/session.ts.
  Interface: create(), validate(), destroy(). Nutze Redis.

# Dann:
> Erstelle eine Middleware, die Sessions validiert.
  Ersetze die JWT-Middleware in src/middleware/auth.ts.

# Dann:
> Passe die Tests an: ersetze JWT-Mocks durch Session-Mocks.

Kleine Aufgaben, einzeln reviewt, schrittweise migriert. Wie bei menschlichen Entwicklern auch.

3. KI als Ersatz für Verständnis

# Gefährlich:
> "Ich verstehe diese Fehlermeldung nicht. Fix es."

# Besser:
> "Der Test schlägt fehl mit 'Connection refused'.
  Prüfe, ob der Testcontainer gestartet wird,
  bevor der Test läuft."

Je besser du das Problem beschreibst, desto besser die Lösung. Wer nicht versteht, was schiefgeht, kann auch nicht bewerten, ob die KI es richtig gefixt hat.

Was in 6 Monaten wahrscheinlich anders ist

Preisstruktur wird wichtiger als Features. Token-basiert, Flatrate, Usage-Caps — die Modelle unterscheiden sich weniger in der Qualität als in der Abrechnung. Wer das falsche Preismodell wählt, zahlt doppelt. Wer das richtige findet, bekommt einen unfairen Vorteil.

Tools verschmelzen. IDE, Agent und Runtime wachsen zusammen. Die Grenze zwischen „Editor mit KI” und „KI mit Editor” löst sich auf. Die Tool-Wahl wird weniger wichtig als die Fähigkeit, mit Agenten zu arbeiten. Die Trends dazu entwickeln sich schnell.

Unterm Strich

KI-Coding-Tools sind kein Hype. Sie verändern den Arbeitsalltag so grundlegend wie die IDE, wie Git, wie Stack Overflow. Der Aufwand für den Einstieg: ein Nachmittag für die Installation, 2-4 Wochen für die effektive Nutzung.

Aber der eigentliche Shift ist nicht technisch. Er ist kognitiv.

Das ist anspruchsvoller, nicht einfacher. Aber es lohnt sich – vor allem, wenn man die KI proaktiv begleitet: Kontext pflegen, Feedback geben, Konventionen schärfen. Je besser der Agent das Projekt kennt, desto mehr quantitative Prozesse kann er autark lösen. Das Ziel ist nicht, weniger zu arbeiten. Sondern an den richtigen Stellen zu arbeiten.