Vom Codetipper zum System-Architekt: Was KI an der Entwicklerrolle verändert

Dieser Artikel richtet sich nicht an Entwickler, die den Wandel bereits täglich erleben – sondern an Entscheider, Projektmanager und alle, die verstehen wollen, wie sich die Rolle von Softwareentwicklern durch KI konkret verändert. Die Code-Beispiele illustrieren den Punkt, man muss sie nicht im Detail verstehen.

Code schreiben war gestern der Engpass. Heute ist es Denken.

Ein neuer API-Endpunkt: Request-Validierung, Datenbank-Query, Error Handling, Response-Formatierung, dazu Tests und Dokumentation. Vor einem Jahr: 90 Minuten tippen. Heute:

> "Erstelle einen POST /api/orders Endpunkt. Validierung mit Zod,
   Prisma für die DB, Error Handling nach unserem Pattern in
   src/lib/errors.ts. Dazu Unit-Tests."

30 Minuten später: Endpunkt steht, Tests laufen, Edge Cases abgedeckt. Die restlichen 60 Minuten? Die gehen jetzt in die Frage, ob der Endpunkt überhaupt so aufgebaut sein sollte – oder ob ein Event-basierter Ansatz besser zur Architektur passt.

Der Engpass hat sich verschoben. Von „Wie schreibe ich das?” zu „Was soll das System tun und warum?”

Was KI übernimmt – ein Vorher/Nachher

Vorher: CRUD-Endpunkt manuell

// 90 Minuten tippen, testen, korrigieren
import { z } from 'zod';
import { prisma } from '@/lib/db';
import { ApiError } from '@/lib/errors';

const CreateOrderSchema = z.object({
  customerId: z.string().uuid(),
  items: z.array(z.object({
    productId: z.string().uuid(),
    quantity: z.number().int().positive(),
  })).min(1),
});

export async function POST(request: Request) {
  const body = await request.json();
  const parsed = CreateOrderSchema.safeParse(body);
  if (!parsed.success) {
    throw new ApiError(400, parsed.error.flatten());
  }
  // ... 40 weitere Zeilen DB-Logik, Validierung, Response
}

Dazu Tests, Error-Cases, Dokumentation. Routinearbeit, aber zeitaufwändig.

Nachher: KI generiert, Entwickler reviewt

Der Agent liest die bestehenden Patterns im Projekt (Error Handling, DB-Layer, Validierung), generiert den Endpunkt konsistent dazu und schreibt Tests, die die echten Edge Cases abdecken. Der Entwickler prüft:

• Stimmt die Validierung? Fehlen Felder?
• Ist das Error Handling konsistent zum Rest?
• Was passiert bei Race Conditions (zwei gleichzeitige Bestellungen)?
• Sind die Datenbankabfragen performant?

Das Review dauert 10-15 Minuten. Aber es ist die wertvollere Arbeit.

Die neuen Kernkompetenzen

1. Review statt Tippen

Wenn KI den ersten Entwurf schreibt, wird Review zur Hauptarbeit. Nicht das oberflächliche „Sieht ok aus, merge”, sondern gezieltes Hinterfragen:

// KI hat generiert:
const users = await prisma.user.findMany({
  where: { status: 'active' },
});

// Frage beim Review: Was passiert bei 100.000 aktiven Nutzern?
// Fehlt hier Pagination? Ein Limit? Ein Cursor?

Oder bei einer React-Komponente:

// KI hat generiert:
useEffect(() => {
  fetchData();
}, [query]);

// Frage beim Review: Wird der vorherige Fetch abgebrochen?
// Was passiert bei schnellem Tippen im Suchfeld?
// → Race Condition. AbortController fehlt.

Diese Fragen stellt die KI sich nicht selbst. Das ist die Arbeit, die bleibt – und die wertvoller wird.

2. Contracts definieren statt Code tippen

Die wichtigste Architektur-Arbeit passiert in Interfaces und Typen. Sie sind die Leitplanken, an denen sich KI-generierter Code orientiert:

// Das definierst du. Den Rest generiert die KI.
interface OrderService {
  create(order: NewOrder): Promise<Result<Order, OrderError>>;
  cancel(id: OrderId, reason: CancelReason): Promise<Result<void, CancelError>>;
  getStatus(id: OrderId): Promise<Result<OrderStatus, NotFoundError>>;
}

type OrderError =
  | { kind: 'validation'; fields: string[] }
  | { kind: 'out_of_stock'; productId: string }
  | { kind: 'payment_failed'; reason: string };

Je präziser deine Contracts, desto besser der generierte Code. Ein vages any erzeugt vagen Code. Ein durchdachtes Typsystem erzeugt durchdachte Implementierungen.

3. Kontext steuern

LLMs arbeiten mit Kontext. Welche Dateien sie sehen, welche Architektur-Entscheidungen dokumentiert sind – das bestimmt die Qualität der Ergebnisse.

Konkret: Eine CLAUDE.md im Projekt-Root:

## Architektur
- API: Express + Zod-Validierung
- DB: Prisma mit PostgreSQL
- Error Handling: Result-Pattern (src/lib/result.ts)
- Tests: Vitest, keine Mocks für DB (Testcontainers)

## Konventionen
- Kein `any`. Immer explizite Typen.
- Fehler als Werte, nicht als Exceptions.
- Jeder Endpunkt hat einen Integration-Test.

Ein Entwickler, der diese Datei pflegt, bekommt konsistenten Code. Ohne diese Datei generiert die KI in jedem Feature einen anderen Stil.

4. Aufgaben zerlegen

KI-Agenten arbeiten besser mit kleinen, klar definierten Aufgaben als mit großen, vagen.

# Schlecht:
> "Baue die Bestellfunktion"

# Gut:
> "Erstelle das Zod-Schema für CreateOrder basierend auf
   dem Prisma-Model in schema.prisma"

# Dann:
> "Implementiere den POST /api/orders Endpunkt.
   Nutze das Schema und das Result-Pattern aus src/lib/result.ts"

# Dann:
> "Schreibe Integration-Tests für den Orders-Endpunkt.
   Teste: erfolgreiche Bestellung, fehlende Felder,
   nicht existierender Kunde, Produkt nicht auf Lager"

Drei präzise Aufgaben liefern bessere Ergebnisse als eine vage. Und jedes Zwischenergebnis lässt sich einzeln reviewen.

5. Debugging bleibt menschlich – aber KI hilft bei der Suche

Wenn ein Bug auftritt, ist die Ursachenanalyse weiterhin menschlich. Aber die Suche nach dem betroffenen Code wird schneller:

> "In der Bestellbestätigung fehlt die MwSt. Finde heraus,
   wo die Berechnung passiert und warum der Wert leer sein könnte."

Die KI durchsucht die Codebase, findet die Berechnungslogik, identifiziert den Pfad – und du entscheidest, ob es ein fehlender Default, ein falsches Mapping oder ein Timing-Problem ist.

Praxisbeispiel: Feature von Anfang bis Ende

Ein konkretes Feature: „Kunden sollen Bestellungen stornieren können, wenn sie noch nicht versendet wurden.”

Schritt 1: Architektur-Entscheidung (Mensch)

Wo gehört die Storno-Logik hin? In den Order-Service? Einen eigenen Cancellation-Service? Event-basiert?

Entscheidung: Order-Service erweitern, Status-Machine für Order-States, Event für nachgelagerte Prozesse (Refund, Lagerbestand).

// State Machine definieren (Mensch)
type OrderState = 'pending' | 'confirmed' | 'shipped' | 'cancelled';

const allowedTransitions: Record<OrderState, OrderState[]> = {
  pending: ['confirmed', 'cancelled'],
  confirmed: ['shipped', 'cancelled'],
  shipped: [],     // Kein Storno nach Versand
  cancelled: [],   // Endstatus
};

Schritt 2: Implementierung (KI)

> "Implementiere cancel() im OrderService.
   Nutze die State Machine aus src/lib/order-states.ts.
   Validiere, dass die Transition erlaubt ist.
   Emitte ein 'order.cancelled' Event über den EventBus.
   Erstelle den API-Endpunkt PATCH /api/orders/:id/cancel"

Die KI generiert Implementierung, Validierung, Endpunkt, Error Handling. In 5-10 Minuten statt 45.

Schritt 3: Review (Mensch)

• Was passiert, wenn gleichzeitig storniert und versendet wird? → Race Condition prüfen
• Wird der Lagerbestand zurückgebucht? → Event-Handler checken
• Ist der Refund-Prozess angestoßen? → Event-Listener vorhanden?
• Was sieht der Kunde im Frontend? → API-Response prüfen

Schritt 4: Tests (KI + Mensch)

> "Schreibe Tests für die Storno-Funktion:
   - Bestellung im Status pending stornieren → OK
   - Bestellung im Status shipped stornieren → Fehler
   - Doppelte Stornierung → Fehler
   - Storno mit ungültiger Order-ID → 404"

KI schreibt die Tests. Mensch ergänzt den Edge Case, den die KI nicht kennt: „Was passiert, wenn der Payment-Provider den Refund ablehnt?”

Zeitaufwand

Schritt	Ohne KI	Mit KI
Architektur + State Machine	30 min	30 min
Implementierung	60 min	15 min
Review	10 min	15 min
Tests	30 min	10 min
Edge Cases + Fixes	20 min	15 min
Gesamt	2,5 Stunden	1,5 Stunden

Die Zeitersparnis liegt bei der Implementierung und den Standard-Tests. Architektur und Review brauchen gleich lang – sind aber jetzt der größere Anteil der Arbeit.

Was sich für Teams verändert

Mehr Kapazität statt weniger Stellen

Die gewonnene Zeit fließt nicht ins Nichtstun. Sie fließt in:

• Den Backlog, der seit Monaten wächst
• Technische Schulden, die niemand anpacken wollte
• Bessere Test-Abdeckung
• Features, die bisher „zu teuer” waren

Junior-Entwickler kommen schneller rein

Ein Junior mit Claude Code oder Cursor löst Aufgaben, für die er vorher Senior-Unterstützung gebraucht hätte. Nicht weil er plötzlich mehr versteht – sondern weil das Tool die Syntax-Hürde senkt und er sich auf das Verstehen konzentrieren kann.

Die Review-Fähigkeit muss trotzdem wachsen. Aber der Einstieg ist niedrigschwelliger.

Senior-Entwickler werden wichtiger

Architektur-Entscheidungen, Code-Reviews, System-Design – das sind die Fähigkeiten, die KI nicht ersetzt. Senior-Entwickler, die bisher einen Großteil ihrer Zeit mit Implementierung verbracht haben, können sich auf das konzentrieren, was wirklich zählt.

Was sich nicht ändert

• Algorithmisches Denken: KI schreibt den Code, aber du musst wissen, warum ein O(n²)-Algorithmus in deinem Fall trotzdem richtig ist
• Debugging: Die KI hilft bei der Suche, aber das Verständnis, was schiefgehen könnte, bleibt bei dir
• Domänenwissen: Die Besonderheiten deiner Branche, deiner Kunden, deines Systems kennt kein Modell
• Entscheidungen unter Unsicherheit: Wenn es keine eindeutig richtige Lösung gibt, braucht es menschliches Urteil

Einordnung

Die Entwicklerrolle wird nicht kleiner. Sie verschiebt sich: weniger tippen, mehr denken. Weniger Boilerplate, mehr Architektur. Weniger allein vor dem Editor, mehr Orchestrierung von Mensch und Maschine.

Das ist das, was viele Entwickler immer wollten: mehr Zeit für die interessanten Probleme.

Der zweite Teil zeigt den konkreten Arbeitsalltag: Tool-Vergleich, Setup-Aufwand, Kosten und wo die Produktivitätsgewinne in Zahlen liegen.