Wie wir KI nutzen, um schneller zu liefern — ohne Entwickler zu ersetzen

Jeder zweite LinkedIn-Post erzählt dir, dass KI Software-Entwickler ersetzen wird. Wir nutzen LLMs seit über einem Jahr im täglichen Workflow. Hier die ehrliche Version: KI macht uns schneller. Sie macht uns nicht überflüssig.

Was wir tatsächlich nutzen

Lassen wir die Theorie. Das sind die Tools und Workflows, die wir bei echten Kundenprojekten nutzen — jeden Tag.

Code-Generierung: Die 80/20-Aufteilung

LLMs sind hervorragend bei Boilerplate. Prisma-Models, API-Route-Handler, React-Komponenten mit Standardmustern — hier glänzt KI. Wir schätzen, dass sie etwa 80% des repetitiven Codes übernimmt, den wir früher manuell geschrieben haben.

// Prompt: "Erstelle eine Next.js API-Route für paginierte Bestellungen mit Status-Filter"
// Was KI in Sekunden generiert — und es ist meistens korrekt:

export async function GET(request: NextRequest) {
  const { searchParams } = new URL(request.url);
  const page = parseInt(searchParams.get("page") ?? "1");
  const status = searchParams.get("status") as OrderStatus | null;

  const orders = await prisma.order.findMany({
    where: status ? { status } : undefined,
    skip: (page - 1) * 20,
    take: 20,
    orderBy: { createdAt: "desc" },
    include: { items: true },
  });

  const total = await prisma.order.count({
    where: status ? { status } : undefined,
  });

  return NextResponse.json({ orders, total, page });
}

Die anderen 20%? Business-Logik, Randfälle, Architekturentscheidungen. Da braucht der Code ein menschliches Gehirn, kein statistisches Modell.

Code Review: Ein zweites Paar Augen

Wir lassen KI-gestützte Reviews bei jedem PR laufen. Nicht als Ersatz für menschliches Review — als Vorfilter. Sie erkennt:

• Ungenutzte Imports und toten Code
• Inkonsistente Namenskonventionen
• Fehlende Fehlerbehandlung an API-Grenzen
• Offensichtliche Sicherheitsprobleme (unsanitisierte Eingaben, exponierte Secrets)

Was sie nicht erkennt: ob der Ansatz richtig ist, ob das Feature das Nutzerproblem wirklich löst, ob die Abstraktion in sechs Monaten noch trägt.

Dokumentation: Das, was niemand schreiben will

Hier liefert KI wohl den größten Mehrwert. Wir nutzen sie für:

• JSDoc-Kommentare aus Funktionssignaturen generieren
• API-Dokumentation aus Route-Handlern erstellen
• Erste README-Abschnitte für neue Packages schreiben
• PR-Änderungen für nicht-technische Stakeholder zusammenfassen

Das Ergebnis braucht immer Überarbeitung. Aber von einem Entwurf zur finalen Version zu kommen ist dramatisch schneller als von einer leeren Seite.

Was nicht funktioniert

"Lass einfach die KI das ganze Feature schreiben"

Haben wir versucht. Mehrfach. Das Ergebnis ist immer dasselbe: Code, der korrekt aussieht, ein oberflächliches Review besteht und in der Produktion bricht, weil er Annahmen über Business-Logik macht, die kein Modell kennen kann.

// KI-generiert: sieht vernünftig aus
async function processRefund(orderId: string) {
  const order = await prisma.order.findUnique({ where: { id: orderId } });
  if (!order) throw new Error("Order not found");

  await prisma.order.update({
    where: { id: orderId },
    data: { status: "REFUNDED" },
  });

  await sendRefundEmail(order.customerEmail);
}

// Was sie übersehen hat:
// - Teilerstattungen (nicht jede Erstattung gilt dem vollen Betrag)
// - Payment-Provider-Webhook-Bestätigung vor Status-Update
// - Bestandswiederherstellung bei physischen Waren
// - Audit-Trail für Compliance
// - Rate-Limiting zur Verhinderung von Erstattungsbetrug

KI generiert den Happy Path. Produktion lebt in den Randfällen.

Architekturentscheidungen

"Sollen wir eine Message Queue oder direkte API-Calls nutzen?" — kein LLM kann das für euer spezifisches System beantworten. Es kennt eure Traffic-Muster nicht, die operationale Erfahrung eures Teams nicht, das Budget eures Kunden nicht und eure Deployment-Einschränkungen nicht.

Wir haben Teams gesehen, die unnötig komplexe Architekturen eingeführt haben, weil eine KI Kafka für ein System vorgeschlagen hat, das 50 Events pro Tag verarbeitet. Kontext zählt. KI hat euren nicht.

Debugging von Produktionsproblemen

LLMs können Stack Traces erklären. Sie können mögliche Ursachen vorschlagen. Aber ein echtes Produktionsproblem zu debuggen erfordert das Lesen von Logs, das Verstehen der Deployment-Historie, das Wissen, welche Features letzte Woche live gingen, und manchmal einfach die Person fragen, die den Code vor sechs Monaten geschrieben hat. Da kommt man mit Prompts nicht weiter.

Unsere Regeln für KI in Produktions-Codebases

Nach einem Jahr Iteration haben wir uns auf ein paar Prinzipien geeinigt:

1. KI schreibt, Menschen reviewen. Jede KI-generierte Zeile durchläuft denselben PR-Prozess wie menschlich geschriebener Code. Keine Ausnahmen.

2. Vertraue KI niemals Business-Logik an. Nutze sie für Infrastruktur (Routes, Models, CRUD). Schreib die Geschäftsregeln selbst.

3. KI ist eine Entwurfsmaschine. Behandle ihre Ausgabe als ersten Entwurf, nicht als fertiges Produkt. Erwarte, 30–50% zu überarbeiten.

4. Nutze KI nicht, um Verständnis zu umgehen. Wenn du nicht erklären kannst, was der generierte Code macht, liefere ihn nicht aus. KI-generierter Code, den du nicht verstehst, ist technische Schuld mit Zeitzünder.

5. Miss den echten Gewinn. Wir tracken Time-to-Merge, nicht Lines-of-Code-Generated. Geschwindigkeit ohne Qualität ist nur schnelleres Debugging.

Das Fazit

KI ist der beste Junior-Entwickler, mit dem wir je gearbeitet haben. Sie ist schnell, beschwert sich nie und schreibt ordentlichen Boilerplate. Aber sie braucht Aufsicht, macht selbstbewusste Fehler und hat keine Ahnung, was eure Nutzer wirklich brauchen.

Wir nutzen sie jeden Tag. Wir würden nie ohne einen Menschen in der Schleife ausliefern.