guides/custom-software.html

SOFTWARE MIT CLAUDE BAUEN

Der Brainstorming-zu-Spezifikation-Workflow, die Toolchain und die Entscheidungen, die KI nicht treffen kann. Basierend auf Erfahrungen aus HostList.io, gautamkhorana.com und Seahawk-Kundenprodukten.

SOFTWARE MIT CLAUDE BAUEN

← Blog All posts in this topic

Warum dieser Leitfaden existiert

Software 2026 mit Claude als primärem Engineering-Partner zu bauen verändert die Kostenkurve und die Teamstruktur, nicht das grundlegende Handwerk. Die urteilsintensiven Teile der Softwareentwicklung (was man baut, warum, wie es sich unter Fehler verhalten soll) benötigen weiterhin menschliche Aufmerksamkeit. Die Ausführungsteile (Code schreiben, Refaktorieren, Boilerplate generieren, Migrationen durchführen) komprimieren sich drastisch. Zu wissen, welches was ist, ist die gesamte Fähigkeit 2026.

Dieser Leitfaden ist der Workflow, den ich tatsächlich verwende, um Custom-Produkte bei Seahawk Media und bei persönlichen Projekten wie HostList.io, gautamkhorana.com und Deluxe Astrology auszuliefern. Kein Claude-Tutorial, kein Prompt-Engineering-Handbuch. Die Prozessdisziplin, die lieferbare Software mit Claude als tragendem Engineer produziert.

Der Brainstorming-zu-Spezifikation-Workflow

Phase 1: strukturiertes Brainstorming

Bevor ich Code schreibe, führe ich ein strukturiertes Brainstorming mit Claude durch. Die Anweisung: das Problem in einfacher Sprache beschreiben, Claude bitten, fünf Fragen zu stellen, deren Antworten das Design ändern würden, diese beantworten, dann Claude bitten, die resultierende Produktspezifikation in 200 Worten zusammenzufassen. Diese Phase dauert 30 bis 60 Minuten und erzeugt eine schriftliche Spezifikation, von der der Rest der Arbeit ausgeht.

Phase 2: technische Entscheidungen

Mit der Spezifikation in der Hand bitte ich Claude, die Architekturentscheidungen zu identifizieren, die die höchste Hebelwirkung downstream haben. Datenbankstruktur, API-Oberfläche, Rendering-Strategie, Deployment-Modell. Für jede schlägt Claude zwei oder drei Optionen und die Trade-offs vor. Ich entscheide. Die Entscheidungen werden im selben Dokument festgehalten, damit die Build-Phase eine einzige Quelle der Wahrheit hat.

Phase 3: spezifikationsgesteuerte Implementierung

Code-Generierung ist die letzte Phase und sie ist am schnellsten, weil die Spezifikation bereits vollständig ist. Claude schreibt das Schema, die Abfragen, die Komponenten, die Routen, die Tests, grob in dieser Reihenfolge. Ich überprüfe jeden Commit. Die meisten Überprüfungen decken ein kleines Refactoring oder einen fehlenden Edge Case auf; vollständige Umschreibungen sind selten, wenn die Spezifikation klar war.

Was Claude gut kann und was nicht

Gut

Greenfield-Code in bekannten Mustern: REST APIs, CRUD-Admin-Panels, Auth-Flows, Blog-Engines, Marketing-Sites. Refactoring von bestehendem Code, wenn die Zielstruktur klar angegeben ist. Generieren von Tests für Code mit klaren Eingaben und Ausgaben. Schreiben von Migrationsskripten, wenn der Schema-Diff eindeutig ist. Entwurf von Dokumentation. Debuggen von Code, bei dem das Symptom reproduzierbar ist und der Trace im Kontext liegt.

Weniger gut

Architekturentscheidungen in unbekannten Bereichen. Integrationscode, bei dem die API eines Drittanbieters schlecht dokumentiert oder kürzlich geändert wurde. Performance-Optimierung, bei der der Engpass nicht offensichtlich ist. Code-Generierung in obskuren Sprachen oder Frameworks, bei denen die Trainingsdaten dünn sind. Alles, bei dem die Anforderungen mehrdeutig sind und das LLM plausibel klingende Standards einfügt, die für deinen spezifischen Fall falsch sind.

Die Lücke im Urteilsvermögen

Claude schreibt die nächste Codezeile konsistent besser als ein durchschnittlicher Engineer. Claude entscheidet konsistent schlechter als ein Senior Engineer, ob die nächste Codezeile überhaupt existieren sollte. Die Senior-Urteilskraft bringst du mit. Die Ausführungsgeschwindigkeit bringt Claude mit. Die Kombination schlägt jeden allein.

Das Toolchain, das ich wirklich nutze

Claude Code als primäre Oberfläche

Claude Code ist die IDE für AI-gestützte Entwicklung. Projektkontext einmal geladen, Terminalzugriff, Dateisystemzugriff, MCP-Tool-Integration. Das einzelne wirkungsreichste Tool, das ich 2025 in meinen Stack integriert habe. Die meiste Engineering-Arbeit läuft jetzt in Claude Code statt direkt in VS Code oder Cursor.

Cursor für direkte In-Editor-Änderungen

Cursor bietet immer noch das beste Editor-Erlebnis für die Zusammenarbeit mit AI an einer einzelnen Datei. Tab-Vervollständigung, Inline-Edits, Side-by-Side-Diff. Ich nutze Cursor, wenn die Arbeit auf ein oder zwei Dateien konzentriert ist; ich wechsle zu Claude Code, wenn die Arbeit das gesamte Projekt umfasst.

Claude Sonnet via API für Batch-Arbeit

Wenn ich hunderte von Seiten programmatisch generieren oder umschreiben muss (die Auto-Blog-Pipeline, Content-Humanisierung, Schema-Generierung), rufe ich die Claude API direkt via Sonnet auf. Niedrigere Latenz als die Chat-Oberfläche, vorhersehbare Kosten, skriptbar. Das richtige Tool für Content-Pipelines im Besonderen.

OpenAI GPT-4o für Prompt Engineering

Meine Entdeckung im späten 2025 war, dass Prompts für Kimi, Minimax oder andere Agenten am besten von Claude oder GPT geschrieben werden, nicht von Hand. Ich beschreibe das Ziel, bitte GPT-4o, den Prompt zu schreiben, und führe diesen Prompt dann gegen den Executor aus. Die Output-Qualität ist materiell besser als bei handgeschriebenen Äquivalenten.

Kimi Researcher und Minimax Agent

Tiefgehende Recherche und vollständige App-Design-Mockups entsprechend. Der Post /blog/kimi-minimax-deep-research-design-mockups/ deckt den kompletten Workflow ab. Beide sind tragende Werkzeuge bei Seahawk für Client-Recherche und schnelle Prototypisierung.

Repository-Disziplin, die KI-gestützte Entwicklung übersteht

Kleine Commits, aussagekräftige Nachrichten

KI-gestützte Entwicklung neigt dazu, große Diffs zu produzieren, weil es einfach ist, 800 Zeilen generierten Code in einem Commit zu verschiffen. Diszipliniere dich selbst, um kleinere Commits zu machen. Eine Commit-Nachricht, die sagt, was sich geändert hat und warum, ist das einzige Artefakt, das der zukünftige du hast, um eine Regression zu debuggen. Mach es lesbar.

Tests als Vertrag

Claude kann Code schreiben, der kompiliert und läuft, aber leise eine Einschränkung verletzt, die im Spec implizit war. Tests, die diese Einschränkungen als ausführbare Verträge kodieren, fangen die Verletzungen ab. Die Test-First-Disziplin ist im KI-gestützten Zeitalter wichtiger als damals, als Menschen jede Zeile schrieben.

Code-Review ist für jetzt nur menschlich

Ich lasse Claude seine eigenen Pull Requests nicht genehmigen. Das Review-Gate ist die wichtigste Qualitätskontrolle, die dem Menschen bleibt, und das Outsourcing an das gleiche Modell, das den Code geschrieben hat, verfehlt den Zweck. Das Anthropic SDK und die Claude Code Workflows machen KI-gestützte Review einfach, aber die endgültige Genehmigung ist meine.

Versionierte Abhängigkeiten und Lockfiles

Fixiere jede Abhängigkeit. Nutze Lockfiles. Führe npm audit bei jedem Build aus. Die Supply-Chain-Angriffsfläche ist real, und KI-gestützte Entwicklung neigt dazu, mehr Abhängigkeiten hinzuzufügen als von Menschen geschriebener Code, weil das Hinzufügen eines Pakets schnell geht. Lockfile-Disziplin hält die Fläche überprüfbar.

Die Produktentscheidungen, die KI nicht treffen kann

Fünf Kategorien von Entscheidungen, bei denen Claude das falsche Werkzeug ist:

Was man überhaupt bauen soll. Die Produktentscheidung ist urteilslastig, hängt vom Nutzerkontext ab, den Claude nicht hat, und ist die folgenreichste Entscheidung in jedem Produkt. Gründer und PMs tragen hier die Verantwortung; KI assistiert höchstens.

Was man launcht und was man streicht. Scope-Entscheidungen während eines Builds laufen immer auf Constraints hinaus, die das Modell nicht sieht. Zeitdruck, Teamstimmung, Partnerbeziehungen, Marketing-Positionierung. Entscheide als Mensch, dokumentiere die Begründung, dann bitte Claude, den beschlossenen Scope umzusetzen.

Ausfallmodus-Design. Wie sich das System bei Fehlern verhalten sollte, wird selten im Voraus spezifiziert und ist der Ursprung der meisten Production-Incidents. Investiere überproportional Zeit in Ausfallmodi; sie entstehen nicht natürlich aus Happy-Path-Code-Generierung.

Die Ethik-Ebene. Das, was du baust, hat Konsequenzen. Datenschutz, Datenspeicherort, Barrierefreiheit, Umweltkosten. Das sind menschliche Entscheidungen, keine Optimierungsergebnisse. Stelle die Frage explizit zur Entwurfszeit.

Langfristige Wartbarkeit. Zukünftiges Selbst liest zukünftiges Claude liest gegenwärtiges Claude's Code — das ist die tiefste Version von technischer Schuld. Optimiere den gegenwärtigen Code darauf, zuerst von Menschen lesbar zu sein, zweitens von KI.

Spezifische Projekte, die ich auf diese Weise umgesetzt habe

Konkrete Beispiele aus den letzten zwölf Monaten bei Seahawk und persönlich:

HostList.io (28.000 programmgesteuerte Seiten auf Next.js + Supabase): mit Claude Code in fünf Tagen scaffoldet, Content-Pipeline von Claude mit Tavily-Recherche-Integration geschrieben, Hero-Generierung über FAL, Schema-Markup automatisch erzeugt. Die gesamte Engineering-Zeit war ungefähr ein Drittel dessen, was ich vor drei Jahren geschätzt hätte.

gautamkhorana.com (diese Website, auf Astro + Supabase): über ein 24-Stunden-Wochenende mit Claude Code als primärem Collaborator neu aufgebaut. Site-Editor-Oberfläche, Blog-System, Schema-Layer, i18n, alles generiert, überprüft, refaktorisiert. Die Kosten für den Bau einer persönlichen Website in dieser Qualität fielen auf ein Wochenende konzentrierter Arbeit.

Deluxe Astrology Auto-Blog und Übersetzungs-Pipeline: Die Tavily-Recherche-zu-Claude-Draft-zu-Winston-Check-zu-FAL-Hero-zu-Supabase-Publish-Schleife läuft täglich über 30 Sprachen auf 91.000+ Seiten. Die Pipeline selbst ist ungefähr 800 Zeilen Code, die Claude in etwa 12 Stunden konzentrierter Arbeit geschrieben hat, vieles davon hätte mit einem reinen menschlichen Team eine Woche gedauert.

Interne Admin-Dashboards bei Seahawk: Der Minimax Agent erzeugt den ersten Prototyp aus einer sechszeiligen Beschreibung, Claude verfeinert ihn, das Ergebnis ist in einer Stunde lieferbar. Die Zeit von „wir brauchen ein internes Tool" zu „wir nutzen das interne Tool" ist von Tagen auf unter einen Arbeitstag gefallen.

Das Fazit

Eigene Software zu bauen ist 2026 ein Handwerk, das in der Ausführungsgeschwindigkeit um eine Größenordnung komprimiert wurde und in der Komplexität der Urteilsfindung ungefähr gleich geblieben ist. Die Teams, die sich anpassen, sind die, die mehr Urteilsvermögen mitbringen (bessere Spezifikationen, bessere architektonische Entscheidungen, besseres Design für Fehlerfälle) und mehr Ausführung an KI auslagern. Die Teams, die sich nicht anpassen, produzieren Software mit konkurrenzfähiger Geschwindigkeit, verlieren aber in der Qualität, oder umgekehrt.

Du musst nicht jedes Tool in diesem Guide verwenden. Du musst wissen, welche Entscheidungen deine sind und welche du delegieren kannst. Die Fähigkeit ist die Grenze, nicht der Toolstack.

Wenn du Hilfe bei der Auslieferung eines benutzerdefinierten Software-Projekts zu dieser Kostenkurve brauchst, führen wir Product Builds bei Seahawk Media durch. Das Gespräch ist kostenlos; die Projekt-Preisgestaltung spiegelt die KI-gestützte Kostenrealität wider, nicht die Stundenhonorar-Realität von 2018.

WHEN YOU ARE READY TO TALK