Bauen mit Claude Code: Wie KI-Zusammenarbeit wirklich aussieht
“Kannst du das irgendwie mit KI loesen?”
Meine Partnerin malt. Aber sie hat kein Atelier. Keine sauberen Waende, kein gutes Licht. Wenn sie ein Bild fertigstellt, koennen Kaeufer sich nicht vorstellen, wie es in ihrem Zuhause aussehen wuerde.
Ich wusste, was ich wollte: einen Telegram-Bot, bei dem man ein Kunstwerk hochlaedt, einen Raum auswaehlt und eine Visualisierung bekommt. Einfaches Konzept. Aber ich habe keine einzige Zeile Code selbst geschrieben.
47 Commits spaeter hatte ich ein funktionierendes Produkt. Und ein viel klareres Bild davon, was es bedeutet, Software mit einem KI-Mitarbeiter zu bauen.
Was ist Claude Code?
Fuer alle, die es noch nicht benutzt haben: Claude Code ist Anthropics Kommandozeilentool, mit dem man direkt im Terminal mit Claude arbeitet. Es kann deine Codebase lesen, Dateien schreiben, Befehle ausfuehren, Fehler debuggen. Weniger Autocomplete, mehr ein Entwickler, mit dem man Pair Programming macht.
Der Unterschied zu Chat-basierter KI: Claude Code hat Kontext. Es sieht dein gesamtes Projekt. Wenn ich sage “der Telegram-Handler ist kaputt”, weiss es, welche Datei ich meine.
Die ersten 4 Stunden
28. Dezember, gegen 20 Uhr. Ich sagte Claude, was ich wollte: einen Telegram-Bot mit Googles Image-Generation-API. Das Konzept war simpel: Ein Foto vom Kunstwerk hochladen, visualisieren wie es in einem Raum haengt. Das war mein erster Input. Claude schlug eine Struktur vor, ich stimmte zu, Claude schrieb den Code.
Um Mitternacht war der Bot live auf Cloudflare und antwortete auf Telegram-Nachrichten. Aber das Ergebnis war nicht wie erwartet. Ich hatte Googles Image-Generation-Modell vorher in AI Studio getestet, und die Resultate sahen anders aus. Irgendetwas stimmte nicht. Trotzdem hatte ich in wenigen Stunden einen funktionierenden Bot, den Leute tatsaechlich aufrufen konnten.
So sah das in der Praxis aus. Ich beschrieb den User Flow so praezise wie moeglich: “Nutzer sollten zwischen verschiedenen Raum-Presets waehlen koennen.” Dann wechselte ich in den Plan Mode in Claude Code und diskutierte den Ansatz, bis ich mit dem Plan zufrieden war. Erst dann setzte Claude es um. Ich testete das Feature sofort danach.
Die Entscheidungen waren immer noch meine. Welche Raeume einbezogen werden. Wie sich der User Flow anfuehlen soll. Wie Fehlermeldungen formuliert sein sollen. Aber die Implementierung war Claudes.
Dann kam ich nicht weiter
Am naechsten Tag wollte ich bessere Bildqualitaet. Die Visualisierungen sahen komisch aus. Das Kunstwerk fuegte sich nicht natuerlich in die Raeume ein.
Hier wurde die Zusammenarbeit interessant.
Ich verbrachte 3-4 Stunden mit Debugging. Ich war ueberzeugt, dass etwas mit meiner Implementierung nicht stimmte. Die Prompt-Struktur, die Aufloesung, das Bildformat. Ich bat Claude immer wieder, Dinge anzupassen. Claude passte an. Nichts half.
Irgendwann dachte ich ehrlich: Das wird nichts.
Dann trat ich einen Schritt zurueck und stellte eine andere Frage. Nicht “fix diesen Code”, sondern “ist Imagen 3 ueberhaupt das richtige Modell fuer diesen Use Case?”
Claude erklaerte die Unterschiede zwischen Imagen 3 und Gemini 3 Pro Image. Gemini handhabt Image-to-Image-Aufgaben anders. Besser im Compositing. Ich traf die Entscheidung: Wechsel zu Gemini. Claude schrieb die Integration neu.
Funktionierte immer noch nicht. Berechtigungsproblem in der Google Cloud Console. Das konnte Claude nicht fixen, da musste ich selbst durch die Console graben. Eine Config-Aenderung spaeter funktionierte alles.
Und hier ist das Interessante: Der Wechsel zu Gemini hat aus Versehen ein Feature freigeschaltet, das ich nicht geplant hatte. Custom-Hintergrund-Upload. Nutzer koennen jetzt ihr eigenes Raumfoto schicken statt Presets zu verwenden. Das waere mit Imagen nicht moeglich gewesen. Claude bemerkte das und schlug vor, es einzubauen. Ich stimmte zu.
Der echte Test
Der Bot funktionierte. Aber manchmal antwortete er nicht. Nutzer schickten ein Kunstwerk, warteten, und nichts passierte. Timeout-Fehler. Ueberall 524er.
Ich beschrieb das Problem Claude. Claude identifizierte es sofort: Grammy, das Bot-Framework, hat ein 30-Sekunden-CPU-Limit. Gemini braucht bis zu 60 Sekunden fuer die Bildgenerierung. Die Rechnung geht nicht auf.
Ich fragte: “Was sind meine Optionen?”
Claude schlug drei Ansaetze vor. Die Requests an einen externen Service queuen. Zu einer anderen Hosting-Plattform wechseln. Oder Cloudflare Durable Objects nutzen, die ein 5-Minuten-CPU-Limit haben statt 30 Sekunden.
Ich kannte Durable Objects vorher nicht. Claude erklaerte sie mir. Ich traf die Entscheidung: Wir machen Durable Objects.
Was folgte, war der sauberste Teil der Zusammenarbeit. Claude schlug vor, die Migration in 5 Phasen aufzuteilen. Ich stimmte zu. Jede Phase: Claude schreibt den Code, ich deploye, ich teste, wir gehen zur naechsten Phase. 1055 Zeilen hinzugefuegt, 710 entfernt. Grammy weg. Fuenf Handler-Dateien geloescht. Das Ganze dauerte etwa 2 Stunden.
Ich hatte erwartet, dass das ein Albtraum wird. War es nicht.
Was ich gemacht habe vs. was Claude gemacht hat
Ich will ehrlich sein ueber die Arbeitsteilung.
Claude hat allen Code geschrieben. Jede Funktion, jeden Handler, jeden API-Call. Claude hat die Durable-Objects-Architektur vorgeschlagen. Claude hat Gemini statt Imagen empfohlen. Claude hat die phasenweise Migration strukturiert.
Ich habe das Problem erkannt. Als die Bilder komisch aussahen, habe ich es bemerkt. Als der Bot Timeouts hatte, habe ich es bemerkt. Als der SQLite-Speicher explodierte (Cloudflares 128KB-Limit pro Wert, ich hatte Bilder als Base64 gespeichert), habe ich es bemerkt.
Ich habe die Fragen gestellt. Nicht “schreib diese Funktion”, sondern “was sind meine Optionen hier?” Nicht “fix diesen Bug”, sondern “ist das ueberhaupt der richtige Ansatz?”
Ich habe die Entscheidungen getroffen. Gemini statt Imagen. Durable Objects statt externe Queues. Phasenweise Migration statt Big-Bang-Rewrite. Wann shippen, wann weiter iterieren.
Ich habe getestet. Jede Aenderung, ich startete den Bot. Schickte Testbilder. Pruefte die Ergebnisse. Fand Probleme bevor sie Nutzer erreichten.
Ich wusste, wann es gut genug war. Claude haette ewig weitere Verbesserungen vorschlagen koennen. Ich habe entschieden, wann Schluss ist.
Was das wirklich bedeutet
Ich bin kein Backend-Entwickler. Ich habe noch nie einen Telegram-Bot gebaut. Ich wusste nicht, was Durable Objects sind. Vor drei Jahren haette mich dieses Projekt Wochen gekostet, wenn ich es ueberhaupt fertig bekommen haette.
Mit Claude hat es ein Wochenende gedauert. Und die Qualitaet ist hoeher als das, was ich alleine produziert haette.
Aber hier ist, was ich ueber KI-Zusammenarbeit gelernt habe: Die menschliche Arbeit verschwindet nicht. Sie verschiebt sich. Weniger tippen, mehr denken. Weniger Syntax, mehr Strategie. Weniger Implementierung, mehr Urteilsvermoegen.
Die Fragen, die du stellst, sind wichtiger als der Code, den du schreibst. “Fix das” produziert schlechtere Ergebnisse als “was sind meine Optionen hier?” Claude Kontext zu geben, warum du etwas willst, produziert bessere Ergebnisse als nur zu beschreiben, was du willst.
Und es gibt Dinge, die Claude nicht kann. Ein Berechtigungsproblem in der Google Cloud Console debuggen. Entscheiden, ob die Bildqualitaet “gut genug” ist. Wissen, wann man shippen soll. Das blieb bei mir.
Was kommt als naechstes
Der Bot funktioniert. Meine Partnerin benutzt ihn. Aktuell nur auf Whitelist. Werde ich ihn oeffentlich machen? Vielleicht. Zuerst will ich testen, ob die Qualitaet fuer verschiedene Kunststile ausreicht.
Was mich mehr interessiert: Wie skaliert diese Art, Software zu bauen? Das war ein Wochenendprojekt. Was passiert, wenn mehr auf dem Spiel steht? Wenn die Codebase groesser ist? Wenn man gleichzeitig mit Claude und anderen Menschen zusammenarbeitet?
Ich habe noch keine Antworten. Aber ich werde weiter experimentieren.
Code ist nicht oeffentlich, aber bei Fragen: Twitter/X