Dein Architekt versand das Authentifizierungsmodul um 23 Uhr an einem Dienstagabend. Keine Pull Requests, die auf Review warten. Kein Standup am nächsten Morgen, um Merge-Konflikte zu erklären. Nur ein Senior-Engineer und Claude Code, der schneller vorankam als dein letztes vier-köpfiges Team je zuvor. Vor fünf Monaten sagten Investoren, diese Logistik-Plattform würde 18 Monate und eine halbe Million in Gehältern dauern. Letzte Woche bewerteten sie sie mit $2 Millionen. Das ganze Engineering-Team? Eine Person, die die Domain verstand, gepaart mit einer KI, die beim ersten Versuch häufiger Production-Code schrieb, als man erwarten würde. Keine Offshore-Entwickler. Keine Contractor-Rechnungen. Keine Jira-Tickets, die Staub ansammeln. Aber drei Fehlermodi hätten das Projekt fast getötet — und der dritte kostete uns zwei Wochen, die wir nie zurückbekommen werden.

Ich schreibe das nicht, um KI zu loben. Ich bin oft genug vom Hype-Zyklus verbrannt worden. Ich schreibe das, weil das, was auf diesem Projekt passierte, grundlegend verändert hat, wie ich über Teamzusammensetzung, Projektplanung und das denke, was möglich ist, wenn man tiefgehendes Architektur-Wissen mit KI-gestützter Entwicklung paart. Die Zahlen lügen nicht — wir erreichten Meilensteine, die ein traditionelles Team von 6-8 Engineers etwa 18 Monate gebraucht hätte, und wir schafften es in unter 5 Monaten.

Lass mich dir genau zeigen, wie.

Inhaltsverzeichnis

Das Projekt: Was wir tatsächlich bauten

Ich kann den Client nicht nennen — NDA-Gebiet — aber ich kann die Plattform beschreiben. Es ist ein B2B-SaaS-Produkt im Logistik-Bereich. Multi-Tenant-Architektur. Real-Time-Tracking-Dashboards. Komplexe rollenbasierte Zugriffskontrolle über Organisationen, Teams und einzelne Benutzer. Integration mit 14 verschiedenen Third-Party-APIs (Carrier, Payment-Prozessoren, Zolldatenbanken). Ein Kundenportal und ein internes Admin-System.

Die Art von Projekt, wo man in einer typischen Agentur-Umgebung mit einem Tech Lead, 2-3 Senior Devs, ein paar Mid-Levels, einer dedizierten DevOps-Person und vielleicht einem QA-Engineer ausstatten würde. Die ursprüngliche Schätzung des Clients von einer anderen Agentur war $3,2M über 20 Monate mit einem Team von 9 Personen.

Wir schlugen $2M, 5 Monate, ein Architekt vor. Sie dachten, wir wären verrückt. Um ehrlich zu sein? Ich auch, ein bisschen.

Warum ein Architekt statt ein ganzes Team

Hier ist das Kontraintuitive über kleine Teams: Der Kommunikations-Overhead bei einem 9-köpfigen Projekt ist enorm. Fred Brooks schrieb darüber 1975 und es ist immer noch wahr. Mit 9 Engineers hast du 36 mögliche Kommunikationskanäle. Meetings multiplizieren sich. Merge-Konflikte werden zur täglichen Routine. Jemand ist immer blockiert und wartet auf jemand anderem's PR-Review.

Mit einem Architekten lebt der gesamte Systemzustand in einem Kopf. Es gibt keine Context-Switching-Gebühr beim Erklären deines Ansatzes in einem Pull Request. Keine Design-by-Committee. Keine zweistündigen Sprint-Planning-Sessions.

Aber eine Person kann nur so schnell tippen. Eine Person kann nur so viele Dateien im Arbeitsgedächtnis halten. Eine Person wird um 18 Uhr müde und macht Fehler um 20 Uhr.

Hier kommt Claude Code ins Spiel. Nicht als Ersatz für den Architekten, sondern als Kraft-Multiplikator. Der Architekt trifft jede Entscheidung. Claude Code führt die Ausführung mit einer Geschwindigkeit durch, die sonst 4-5 Entwickler erfordern würde.

Die Rolle des Architekten

Unser Architekt — nennen wir ihn Marcus — hat 15 Jahre Erfahrung. Er hat Systeme in dieser Größenordnung schon mal gebaut. Seine Aufgabe auf diesem Projekt war:

  • System Design und Architektur-Entscheidungen
  • Definition von Modulbereich und Daten-Verträgen
  • Schreiben des kritischen Pfad-Codes (Auth, Payment-Verarbeitung, Data-Pipeline-Orchestrierung)
  • Review und Verfeinerung von allem, was Claude Code produzierte
  • Infrastruktur und Deployment-Architektur
  • Sicherheits-Audits

Was er nicht tat: Boilerplate-CRUD-Endpoints schreiben, UI-Komponenten aus Designs bauen, Unit-Tests für einfache Logik schreiben, Datenbankmigrationen erstellen oder neue Services scaffolden. Claude Code kümmerte sich um das alles.

Wie Claude Code tatsächlich in einen echten Workflow passt

Lass mich konkret sein, was "Claude Code verwenden" tatsächlich aussah, täglich, weil die Marketing-Materialien die Realität nicht erfassen.

Marcus würde jeden Morgen anfangen, die Arbeit des Tages strukturiert zu definieren. Nicht vage Prompts wie "baue mir ein Benutzermanagement-System." Stattdessen würde er erstellen, was wir anfingen "Architektur-Briefe" zu nennen — detaillierte Dokumente, die spezifizierten:

  1. Die Verantwortung und Grenzen des Moduls
  2. Datenmodelle mit exakten Feldtypen und Beziehungen
  3. API-Vertrag (Endpoints, Request/Response-Formen)
  4. Geschätsregeln und Edge-Cases
  5. Error-Handling-Erwartungen
  6. Welche bestehenden Module es mit integrieren musste

Dann würde er diese an Claude Code in Häppchen weitergeben. Eine typische Session sah so aus:

# Marcus würde im Projektverzeichnis mit Claude Code CLI arbeiten
# Zuerst, Kontext etablieren
claude "Lies durch /src/modules/shipment/ und /src/lib/database/schema.ts. 
Ich möchte, dass du die bestehenden Muster verstehst, bevor wir das 
Fakturierungs-Modul bauen."

# Dann, die aktuelle Build-Anweisung mit dem Architektur-Brief
claude "Baue das Fakturierungs-Modul nach dem Architektur-Brief in 
/docs/briefs/invoicing.md. Folge den exakt gleichen Mustern wie das 
Shipment-Modul für Service-Layer, Repository-Layer und Route-Handler. 
Nutze die bestehende Error-Handling-Middleware. Schreibe Tests für alle 
Geschätslogik in der Service-Layer."

Claude Code würde dann das Modul generieren — typischerweise 15-30 Dateien einschließlich Types, Schemas, Services, Repositories, Route-Handler, Middleware und Tests. Marcus würde die Ausgabe überprüfen, Korrektionen vornehmen und iterieren. Der gesamte Zyklus für ein mittleres Komplexitäts-Modul dauerte etwa 2-3 Stunden statt der 2-3 Tage, die ein Senior-Developer brauchen würde.

Die Iterations-Schleife

Hier ist, was niemand dir über KI-gestützte Entwicklung erzählt: Die erste Ausgabe ist selten produktionsbereit. Sie ist vielleicht 70-80% dort. Aber die restlichen 20-30% sind, wo die Expertise des Architekten am meisten zählt.

Marcus entwickelte einen Rhythmus:

  1. Generieren — Claude Code produziert die ursprüngliche Implementierung
  2. Review — Marcus liest jede Datei und markiert Probleme
  3. Verfeinern — Spezifische Korrektionen werden zu Claude Code zurückgegeben
  4. Härten — Marcus kümmert sich manuell um sicherheitskritische Abschnitte
  5. Testen — Führe die generierten Tests aus, füge Edge-Cases hinzu, die Claude verpasste

Diese Schleife durchlief typischerweise 2-3 Zyklen pro Modul. Nach dem dritten Monat des Projekts produzierte Claude Code First-Pass-Code, der näher bei 85-90% produktionsbereit war, weil die Codebasis genug etablierte Muster hatte, um ihnen zu folgen.

Der Tech Stack und Architektur-Entscheidungen

Wir wählten den Stack bewusst, um KI-gestützte Produktivität zu maximieren:

  • Next.js 14 (App Router) — für das Kundenportal und Admin-Dashboard
  • Node.js mit Fastify — für die API-Layer (separat von Next.js)
  • PostgreSQL — Hauptdatenbank
  • Redis — Caching, Session-Verwaltung, Real-Time Pub/Sub
  • Drizzle ORM — typsichere Datenbank-Zugriffe
  • Turborepo — Monorepo-Verwaltung
  • Vercel — Frontend-Deployment
  • AWS (ECS Fargate) — API und Background-Worker

Wir wählten Next.js, weil die Muster gut etabliert sind und Claude Code tiefe Trainingsdaten auf App-Router-Konventionen hat. Das ist wichtiger, als Leute denken. Wenn wir etwas Exotisches wie ein Rust-Backend mit HTMX gewählt hätten, würde die KI-Output-Qualität erheblich sinken. Du kannst mehr über unseren Next.js-Entwicklungs-Ansatz in großem Maßstab erfahren.

Drizzle ORM war eine bewusste Wahl über Prisma für dieses Projekt. Claude Code generiert bessere Drizzle-Schemas, weil sie nur TypeScript sind — keine benutzerdefinierte DSL, um falsch zu werden. Plus, die Migrations-Story ist einfacher, wenn du viele Schema-Änderungen schnell generierst.

// Beispiel: Claude Code generierte dieses Invoice-Schema 
// beim ersten Versuch mit minimalen Korrektionen
import { pgTable, uuid, varchar, decimal, timestamp, pgEnum } from 'drizzle-orm/pg-core';
import { relations } from 'drizzle-orm';
import { shipments } from './shipments';
import { organizations } from './organizations';

export const invoiceStatusEnum = pgEnum('invoice_status', [
  'draft', 'pending', 'sent', 'paid', 'overdue', 'cancelled', 'refunded'
]);

export const invoices = pgTable('invoices', {
  id: uuid('id').primaryKey().defaultRandom(),
  organizationId: uuid('organization_id').notNull().references(() => organizations.id),
  shipmentId: uuid('shipment_id').references(() => shipments.id),
  invoiceNumber: varchar('invoice_number', { length: 50 }).notNull().unique(),
  status: invoiceStatusEnum('status').notNull().default('draft'),
  subtotal: decimal('subtotal', { precision: 12, scale: 2 }).notNull(),
  taxAmount: decimal('tax_amount', { precision: 12, scale: 2 }).notNull().default('0'),
  totalAmount: decimal('total_amount', { precision: 12, scale: 2 }).notNull(),
  currency: varchar('currency', { length: 3 }).notNull().default('USD'),
  dueDate: timestamp('due_date', { withTimezone: true }).notNull(),
  paidAt: timestamp('paid_at', { withTimezone: true }),
  createdAt: timestamp('created_at', { withTimezone: true }).notNull().defaultNow(),
  updatedAt: timestamp('updated_at', { withTimezone: true }).notNull().defaultNow(),
});

export const invoiceRelations = relations(invoices, ({ one, many }) => ({
  organization: one(organizations, {
    fields: [invoices.organizationId],
    references: [organizations.id],
  }),
  shipment: one(shipments, {
    fields: [invoices.shipmentId],
    references: [shipments.id],
  }),
  lineItems: many(invoiceLineItems),
}));

Was Claude Code gut konnte

Lass mich konkret sein. Hier ist, wo Claude Code Entwicklung genuinely beschleunigte:

Boilerplate und CRUD-Operationen

Das ist die offensichtliche. REST-Endpoints generieren, Request-Validierungs-Schemas (wir nutzten Zod), Response-Serializer, grundlegende Service-Methoden — Claude Code schlug diese in Minuten hin. Im ganzen Projekt schätzten wir etwa 180 API-Endpoints. Vielleicht 140 davon waren Standard-CRUD oder Query-Operationen, die Claude Code mit minimaler Überarbeitung generierte.

Test-Generierung

Claude Code schrieb ungefähr 2.400 Tests über das Projekt. Waren sie alle perfekt? Nein. Etwa 15% brauchten signifikante Überarbeitung. Aber 85% deiner Test-Suite zu haben, die generiert und funktionstüchtig ist, spart massive Zeit. Marcus konzentrierte seine Testing-Energie auf Integrations-Tests und die kniffligen Edge-Cases, die Claude Code nicht antizipieren konnte.

UI-Komponenten-Entwicklung

Das Kundenportal hatte etwa 60 einzigartige Page-Views. Für jede würde Marcus die Figma-Design-Referenz und den API-Vertrag geben, und Claude Code würde die React-Komponenten generieren, Hooks für Datenabruf (wir nutzten TanStack Query), Form-Handling mit React Hook Form + Zod und Loading/Error-States. Die Ausgabe war durchgehend gut — vielleicht 75% pixelgenau beim ersten Durchgang.

Datenbank-Migrationen und Schema-Evolution

Als sich Anforderungen entwickelten (und das tun sie immer), handhabte Claude Code Schema-Migrationen reibungslos. Beschreibe die Änderung, die du brauchst, und es generiert die Migration-Datei, aktualisiert das Schema, aktualisiert betroffene Queries und passt die TypeScript-Types an. Was früher eine 45-Minuten-sorgfältig-Refactoring-Session war, wurde zu einem 10-Minuten-Review-und-Genehmigen-Zyklus.

Dokumentation

Claude Code generierte API-Dokumentation, Inline-Code-Kommentare, README-Dateien und sogar Runbook-Dokumente für Operationen. Marcus würde Review und Anpassungen vornehmen, aber die Basis-Ausgabe war genuinely nützlich. Wir endeten mit besserer Dokumentation als 90% von Projekten, die ich je gesehen habe, einfach weil die Kosten, sie zu generieren, so gering waren.

Wo Claude Code scheiterte und was wir dagegen taten

Dieser Abschnitt zählt mehr als die Erfolgsgeschichten. Wenn du planst, KI auf diese Weise zu nutzen, musst du wissen, wo die Grenzen sind.

Komplexe Geschätslogik mit mehreren Abhängigkeiten

Das Shipment-Routing-Engine — das Carrier-Verfügbarkeit, Kostenoptimierung, Zoll-Anforderungen, Lieferfenster und Kapazitäts-Beschränkungen gleichzeitig berücksichtigen musste — war jenseits von dem, was Claude Code gut handhaben konnte. Es würde etwas generieren, das plausibel aussah, aber subtile Logik-Fehler hatte, die echtes Geld kosten konnten.

Marcus schrieb dieses Modul von Hand. Dauerte etwa zwei Wochen. Das ist genau die Art von Arbeit, die einen Senior-Architekten rechtfertigt, statt sich KI-mäßig durchzutricksen.

Sicherheitskritischer Code

Wir vertrauten Claude Code niemals mit Auth-Flows, Payment-Verarbeitung oder Verschlüsselung ohne Zeile-für-Zeile-Review. Und gut so — es generierte gelegentlich JWT-Validierung, die technisch funktional war, aber Edge-Cases verpasste wie Token-Ablauf Clock Skew, oder sanitierte Inputs nicht richtig vor Datenbankabfragen, trotz ORM-Nutzung.

Faustregel: Wenn ein Bug in diesem Code Geld kosten oder Daten offenlegen könnte, schreibt das ein Mensch und ein anderer Mensch überprüft es.

Langreichweitige Architektur-Konsistenz

Bis Monat drei war die Codebasis groß genug, dass Claude Code würde manchmal Muster vergessen, die früher etabliert waren, sogar mit Kontext bereitgestellt. Es könnte einen anderen Error-Handling-Ansatz in einem Modul versus einem anderen verwenden. Marcus musste wachsam sein, diese Inkonsistenzen zu fangen.

Wir milderten das, indem wir ein lebendes "Conventions"-Dokument unterhielten, das in jeder Claude Code-Session eingebunden war. Denke daran als Style-Guide, aber für Architektur-Muster.

Performance-Optimierung

Claude Code generiert Code, der funktioniert, aber generiert nicht immer Code, der schnell ist. Datenbankabfragen, die N+1-Abruf tun. React-Komponenten, die unnötig re-rendern. API-Endpoints, die mehr Daten laden als nötig.

Marcus verbrachte ungefähr 20% seiner Review-Zeit auf Performance-Optimierung. Kein Deal-Breaker, aber etwas zum Budget.

Die Wirtschaftlichkeit: Kostenaufschlüsselung und ROI

Hier ist der Teil, den jeder sehen möchte. Echte Zahlen.

Kostenbereich Traditionelles Team (Est.) KI-beschleunigt (Tatsächlich)
Engineering-Gehälter (18 Mo / 5 Mo) $1.890.000 $175.000
Claude Code API / Abonnement $0 $12.400
Infrastruktur (Dev/Staging) $48.000 $8.200
Projektmanagement $216.000 $0*
QA / Testing $180.000 $22.000**
Design (Contractor) $120.000 $95.000
DevOps / Infrastruktur-Setup $96.000 $35.000
Gesamt $2.550.000 $347.600

Marcus verwaltete selbst mit Linear für Task-Tracking. Kein PM-Overhead.

*Beauftragte einen QA-Spezialisten für die letzten 6 Wochen.

Die Claude Code-Kosten teilen sich wie folgt: ungefähr $2.500/Monat. Das ist der Max-Plan ($100/Monat für das Abonnement) plus API-Kosten für erweiterte Sessions. An manchen Tagen würde Marcus $150-200 in API-Aufrufen während schwerer Generierungs-Sessions durchbrennen. An den meisten Tagen waren es $40-80.

Das Projekt rechnete mit $2M ab. Unsere totalen Bereitstellungskosten waren unter $350K. Ich überlasse dir die Margin-Mathematik.

Geschwindigkeit-Vergleich

Meilenstein Traditionelle Timeline KI-beschleunigt Timeline
Architektur & Design 6 Wochen 3 Wochen
Kern-Plattform (Auth, Multi-Tenancy, Basis-API) 10 Wochen 3 Wochen
Feature-Entwicklung (alle Module) 32 Wochen 10 Wochen
Integrationen (14 Third-Party-APIs) 12 Wochen 4 Wochen
Testing & QA 8 Wochen 3 Wochen
Deployment & Hardening 4 Wochen 2 Wochen
Gesamt 72 Wochen 25 Wochen

Lektionen für Teams, die KI-beschleunigte Entwicklung erwägen

Nach diesem Projekt denke ich viel darüber nach, was das bedeutet für wie wir Software gehen bauen. Hier ist, was ich jedem Team oder Agentur erzählen würde, die diesen Ansatz erwägt.

Du brauchst noch immer einen Senior Architekten. Vielleicht mehr als je zuvor.

KI eliminiert nicht die Notwendigkeit für Expertise — sie verstärkt was auch immer Expertise (oder Mangel daran) du mitbringst. Ein Junior-Developer mit Claude Code wird Junior-Qualitäts-Code schneller versenden. Ein Senior-Architekt mit Claude Code wird Senior-Qualitäts-Code bei einer Geschwindigkeit versenden, die früher unmöglich war.

Das schlimmste mögliche Szenario ist ein Mid-Level-Developer, der denkt, dass sie Senior sind, der KI nutzten, um Code zu generieren, den sie nicht richtig evaluieren können. So erhältst du eine Codebasis, die an der Oberfläche gut aussieht, aber unter Last zusammenbricht.

Konvention über Konfiguration, überall

Je vorhersagbarer die Muster deiner Codebasis sind, desto besser funktioniert KI. Wir nutzten die gleiche Datei-Struktur, Naming-Konventionen und Code-Organisation in jedem Modul. Diese Konsistenz zahlte sich massiv aus, als Claude Code lernte, bestehende Muster zu treffen.

Wenn du mit einer Headless-CMS-Architektur arbeitest, machen strenge Konventionen für Content-Typen, API-Routes und Component-Strukturen KI-generierten Code dramatisch zuverlässiger.

Investiere in Architektur-Briefe

Die Qualität von Claude Code's Output korrelierte direkt mit der Qualität von Marcus's Architektur-Briefen. Vage Anweisungen produzierten vagen Code. Detaillierte Briefe mit expliziten Datenmodellen, Geschätsregeln und Integrations-Anforderungen produzierten Code, der nahe an produktionsbereit war.

Wir schätzen, dass Marcus etwa 30% seiner Zeit mit dem Schreiben von Architektur-Briefen und Überprüfen von Output verbrachte, und 70% der Zeit, die ein traditionelles Team bei der tatsächlichen Implementierung verbracht hätte, wurde von Claude Code gehandhabt.

KI-gestützte Entwicklung ändert Pricing-Modelle

Wenn du eine Agentur bist, ist das das unbequeme Gespräch. Wenn ein Architekt das versenden kann, was früher ein Team von 8 brauchte, wie gibst du Preis? Wir glauben an wert-basiertes Pricing — der Client zahlt für das Ergebnis, nicht für die Stunden. Die Plattform ist $2M wert, unabhängig davon, ob 1 Person oder 10 es brauchten, um sie zu bauen.

Wenn du interessiert bist, wie diese Art von Ansatz für dein Projekt funktionieren könnte, bricht unsere Pricing-Seite auf, wie wir über Project-Scoping in dieser neuen Realität denken.

Nicht jedes Projekt passt zu diesem Modell

Das funktionierte, weil:

  • Die Anforderungen gut definiert waren (Logistik ist ein reifer Domain)
  • Wir einen genuinely Senior-Architekten verfügbar hatten
  • Der Tech Stack war Mainstream (großartige KI-Trainingsdaten)
  • Der Client vertraute uns, das zu versenden ohne das Team-Größe zu micromanagen

Projekte mit mehrdeutigen Anforderungen, schwere R&D-Komponenten oder spezialisierte Domains (medizinische Geräte, Finanz-Instrumente mit regulatorischen Anforderungen) brauchen mehr menschliches Urteilsvermögen und sollten entsprechend besetzt werden.

Für Projekte, die mit Frameworks wie Astro gebaut werden, wo das Ökosystem neuere und KI-Trainingsdaten dünner ist, wirst du weniger Beschleunigung von KI-Tools im Vergleich zu React/Next.js-Projekten sehen.

FAQ

Wie viel kostet Claude Code tatsächlich pro Monat für schwere Entwicklung?

Auf diesem Projekt schätzten wir durchschnittlich $2.500/Monat alles-in. Das Claude Max-Abonnement ist $100/Monat (oder $200/Monat für den höheren Tier ab früh 2026) und API-Nutzung für Claude Code's agentic Sessions addiert auf je nachdem, wie viel Code du generierst. Schwere Tage schlugen $150-200 in API-Kosten an. Leichte Review-und-Verfeinern-Tage waren $40-80. Anthropic hat auch den Max-Plan bei $200/Monat eingeführt, der signifikante Nutzung enthält, die variable Kosten reduzieren könnte.

Kann ein Junior-Developer Claude Code auf die gleiche Weise nutzen?

Nein, und das ist wichtig. Claude Code verstärkt dein bestehendes Skill-Level — es ersetzt Architektur-Wissen nicht. Ein Junior-Developer mit Claude Code wird schneller Code generieren, aber sie werden nicht die subtilen Bugs, Sicherheits-Probleme, Performance-Probleme oder Architektur-Inkonsistenzen fangen, die ein Senior-Engineer sofort erkennt. Du brauchst jemanden, der die Ausgabe evaluieren kann, nicht einfach akzeptieren.

Wie ist die Code-Qualität — ist KI-generierter Code wartbar?

Es hängt völlig von den Constraints ab, die du ihm gibst. Unser generierter Code bestand die gleichen Linting-Regeln, Type-Checking und Code-Review-Standards wie von Menschen geschriebener Code. Der Trick ist, starke Muster früh im Projekt zu etablieren, damit die KI gute Beispiele zum Folgen hat. Wir unterhielten ein Conventions-Dokument, das in jeder Claude Code-Session eingebunden war. Sechs Monate nach dem Launch, hat das Team, das die Plattform wartete, keinen ungewöhnlichen Wartungs-Burden gemeldet.

Funktioniert dieser Ansatz für Frontend-intensive Projekte?

Ja, mit Vorbehalten. Claude Code ist hervorragend im Generieren von React-Komponenten, Form-Handling, Datenabruf-Hooks und State-Management-Code. Es ist weniger zuverlässig bei der Erstellung von pixel-perfekten CSS-Layouts aus Designs — du brauchst mehr Iterations-Zyklen für visuelle Politur. Wir fanden, es war ungefähr 75% akkurat beim ersten Durchgang der UI-Generierung im Vergleich zu 85-90% für Backend-Code.

Wie handhabst du Code-Review, wenn es nur einen Developer gibt?

Marcus überprüfte jede Zeile des KI-generierten Codes selbst. Wir brachten auch einen Contractor-Sicherheits-Spezialisten für zwei fokussierte Audit-Sessions während des Projekts herein (Woche 12 und Woche 22). Für die finale Phase schloss sich ein QA-Spezialisten für sechs Wochen an. Der Mangel an Peer-Code-Review ist ein echtes Risiko — wir milderten es mit automatisiertem Tooling (TypeScript strict mode, ESLint mit aggressiven Regeln, Vitest mit Coverage-Schwellwerts) und externen Audits.

Was passiert, wenn Claude Code fehlerhaften Code generiert?

Es passiert regelmäßig. Der erste Durchgang ist selten perfekt. Wir bauten diese Erwartung in den Workflow ein — generieren, überprüfen, verfeinern, härten. Die meisten Bugs wurden während Marcus's Review-Zyklus gefangen. Die automatisierte Test-Suite (auch großteils KI-generiert aber von Menschen überprüft) fing Regressions-Probleme. Der Schlüssel-Einsicht ist, dass das Debuggen von KI-generiertem Code schneller ist als das Schreiben von korrektem Code von Grund auf, weil du von etwas anfängst, das größtenteils richtig ist.

Ist das nur für Greenfield-Projekte möglich, oder funktioniert es mit bestehenden Codebases?

Claude Code funktioniert tatsächlich gut mit bestehenden Codebases, weil es bestehende Muster lesen und verstehen kann. Auf diesem Projekt profitierten später Module davon, frühere Module als Referenz zu haben. Wir haben Claude Code seitdem für Feature-Addierungen auf bestehende Client-Projekte mit guten Ergebnissen genutzt. Der Schlüssel ist, genug Kontext über bestehende Konventionen und Muster zu geben. Wenn deine Codebasis inkonsistent oder schlecht dokumentiert ist, werden KI-generierte Addierungen diese Inkonsistenz erben.

Würdest du das noch einmal tun?

Absolut. Wir tun es bereits. Zwei weitere Projekte laufen mit diesem Modell direkt jetzt — eines mit einem einzelnen Architekten, ein anderes mit zwei Engineers für ein komplexeres System. Die Wirtschaftlichkeit ist zu überzeugend, um ignoriert zu werden. Aber ich möchte klar sein: das geht nicht darum, Developer zu ersetzen. Es geht darum, das Verhältnis von Senior-Architekten zu Output zu ändern. Du brauchst noch immer menschliche Expertise. Du brauchst nur weniger von menschlicher Tipperei. Wenn du ein Projekt erwägst und erforschen möchtest, wie dieses Modell für dich aussehen könnte, kontaktiere uns — wir sind glücklich, durchzusprechen, ob es eine Passung ist.