Drei Wochen, eine App: Was KI für dich bauen kann und was auf keinen Fall

Vor drei Wochen hatte ich ein .NET-Backend, in dem vielleicht 40 % der Dienste verkabelt waren, ein halbfertiges Vue-Frontend und einen vagen Plan. Heute verfügt Rasepi über eine Block-Level-Übersetzungsmaschine mit Glossarverwaltung und Stilregeln, ein Frische-Scoring-System mit Ablaufvorlagen und Überprüfungsworkflows, eine KI-gestützte semantische Suche mit RAG, ein vollständiges Plugin-SDK mit Action Guards und Event-Pipelines, kollaborative Echtzeit-Bearbeitung, eine komplette Marketing-Website mit Preisseiten, ein Dokumentationsportal für Entwickler, einen Blog mit 14 Beiträgen, automatisierte Übersetzungen in 7 Sprachen und ein Wartelistenformular, das tatsächlich E-Mails versendet.

Das habe ich nicht allein gemacht. Ich habe Claude jeden Abend stundenlang, manchmal sogar den ganzen Tag, in VS Code laufen lassen, und es hat sich für die Teile, bei denen es helfen konnte, wirklich gelohnt. Aber es gibt eine Kluft zwischen "eine App bauen" und "etwas haben, das man tatsächlich einem anderen Menschen verkaufen kann", und diese Kluft ist gefüllt mit Tonnen von Einrichtungsseiten, manueller Konfiguration, E-Mail-Zustellbarkeitseinstellungen und DNS-Einträgen. Claude kann einfach noch nicht mit all diesen Diensten sprechen.

Die Leute reden selten über diesen Teil.

Hätte ich das auch ohne KI geschafft?

Ich habe über 30 Jahre Erfahrung in der Entwicklung von Software. Hätte ich das alles auch ohne Claude schaffen können? Wahrscheinlich schon. Aber nicht in drei Wochen. Nicht einmal annähernd. Die KI hat alles beschleunigt, was mit dem Eintippen von Code in Dateien zu tun hat, und das ist ein großer Teil eines jeden Projekts.

Aber das ist es, was die Leute übersehen, wenn sie über "Vibe Coding" und das Erstellen ganzer Apps mit KI sprechen: Du musst immer noch wissen, was du tust. Claude kann dir jeden einzelnen Schritt erklären, der nötig ist, um einen Cloudflare Worker mit einer D1-Datenbank einzusetzen. Er kann dich durch die Konfiguration von OpenIddict führen. Er kann dir DNS-Einträge und die SPF-Einrichtung erklären. Das Problem ist, dass dieses Wissen oft veraltet ist. Die Plattformen aktualisieren ihre Dashboards, verschieben Einstellungen, veraltende Funktionen und benennen Dinge um. Und Claude weiß es nicht.

Ich habe nicht einmal nur eine KI benutzt. ChatGPT wusste manchmal mehr über bestimmte Dienste, besonders wenn Claudes Trainingsdaten ein paar Monate hinter der Dokumentation einer bestimmten Plattform zurücklagen. An manchen Tagen hatte ich beide KIs nebeneinander geöffnet und verglich ihre Vorschläge mit dem, was ich tatsächlich im Dashboard sah.

Aber der springende Punkt ist folgender: Um eine verkaufsfähige App zu haben, musst du unbedingt wissen, wie das Hosting funktioniert. Wie Domains funktionieren. Wie Code Signing-Zertifikate funktionieren. Wie Datenbanken funktionieren. Wie die Zustellbarkeit von E-Mails funktioniert. Wie OAuth2-Abläufe tatsächlich funktionieren, nicht nur der Code, der sie implementiert. Kannst du eine App ohne dieses Wissen entwickeln? Sicher. Bringt dich das weiter? Wahrscheinlich nicht. Du wirst etwas haben, das auf localhost läuft und niemanden außerhalb deines eigenen Rechners beeindruckt.

Die 80%, die sich wie Magie anfühlen

Lass mich klar sagen, was funktioniert hat, denn es hat wirklich gut funktioniert. Um Service-Schnittstellen zu erstellen, CRUD-Controller zu implementieren, EF Core-Konfigurationen zu schreiben und Vue-Komponenten zu bauen, ist Claude absurd schnell.

Hier ist ein Beispiel. Als ich ein Glossarverwaltungssystem einrichten wollte, beschrieb ich die Anforderungen: Glossare auf Mieterebene, CSV-Import/Export, CRUD für einzelne Begriffe und einen Synchronisationsmechanismus mit der Glossar-API von DeepL. Claude erstellte die Entitätsmodelle, die Serviceschnittstelle und -implementierung, den Controller mit den richtigen Autorisierungsattributen und den Pinia-Speicher. Alles in vielleicht 20 Minuten. Ich hätte fast einen ganzen Tag gebraucht, um das alles von Hand zu schreiben.

Bei der Übersetzungsmaschine war es ähnlich. Die Block-Level-Architektur mit SHA256 Content Hashing, die Staleness Detection, der Orchestrator, der die Dienste koordiniert. Claude verstand das Muster, nachdem ich es ihm einmal erklärt und dann konsequent in Dutzenden von Dateien repliziert hatte. Das Frische-Bewertungssystem, die Überprüfungs-Workflows, die Pipeline für die Ablaufbenachrichtigung. Ein Dienst nach dem anderen, verkabelt und funktionierend.

Für die Marketing-Website erstellte Claude ganze HTML-Seiten aus Beschreibungen. "Eine Preisseite mit einer kostenlosen Stufe, einer Teamstufe und einer Unternehmensstufe. Dunkler Hintergrund. Verwende den grünen Akzent." Und es wurde... einfach eine erstellt. Inklusive responsiver Breakpoints und Hover-Status.

Das ist der magische Teil. Er ist echt.

Die Maschine zähmen

Aber es ist nicht so, dass ich einfach "Bau mir eine App" getippt habe und dann weggegangen bin. Die Arbeit mit Claude ist eine ganz eigene Kunst, und ich habe die ersten Tage damit verbracht, sie schlecht zu machen.

Der erste Output ist immer... gut. Technisch korrekt, vernünftig strukturiert, aber generisch. Claude schreibt Code so, wie man Prosa schreibt: kompetent, vorhersehbar und sehr durchschnittlich. Wenn man ihn sich selbst überlässt, wird er die gleiche Controller-Struktur produzieren, die jedes Framework-Tutorial verwendet. Das gleiche Service-Muster. Das gleiche Komponenten-Layout. Es funktioniert, aber es ist nicht dein Code.

Also fängst du an, es zu trainieren. Nicht formell, nicht mit Feinabstimmung, sondern durch Wiederholung und Korrektur. "Nein, ich will, dass die Serviceschnittstelle von der Implementierung getrennt ist." "Verwende immer dieses Berechtigungsattributmuster." "Der Tenant-Kontext kommt aus der Middleware, nicht aus dem Request Body". Drehung um Drehung um Drehung. An manchen Tagen fühlte ich mich, als würde ich mit einem sehr enthusiastischen Junior programmieren, der ständig vergisst, was wir gestern beschlossen haben.

Und dann macht etwas klick. Nach genügend Korrekturen, nach genügend Beispielen in der Codebasis, die er lesen kann, fängt Claude an, es beim ersten Versuch richtig zu machen. Er lernt deine Namenskonventionen kennen. Er weiß, wo du deine DTOs platzierst. Er folgt unaufgefordert deinem Fehlerbehandlungsmuster. Der Übergang von "lästig" zu "produktiv" dauerte vielleicht vier oder fünf Tage konsequenter Arbeit.

Bei den Blogbeiträgen war es ähnlich. Claudes Standard-Schreibstimme ist sofort erkennbar. Dieser geschliffene, leicht distanzierte, perfekt strukturierte Stil, der sich wie jeder KI-generierte Blogbeitrag liest, den du je gesehen hast. Ich habe in mehreren Runden einen Styleguide erstellt, ihn mit Beispielen aus meinem eigenen Schreibstil gefüttert und auf jedes "Es ist erwähnenswert" und jeden em-Bindestrich hingewiesen (im Ernst, die em-Bindestrich-Sucht ist echt). Schließlich habe ich eine ganze Skill-Datei erstellt, eine Anleitung, die Claude lädt, bevor er etwas für den Rasepi-Blog schreibt.

Dieser Beitrag stammt übrigens von Claude. Mit meinem Input, meinen Korrekturen, meiner Richtung. Ich habe beschrieben, was ich sagen wollte, habe es an den Styleguide angelehnt und dann einige Zeit damit verbracht, hin und her zu gehen, bis sich die Stimme richtig anfühlte. Das ist der eigentliche Arbeitsablauf. Nicht "KI schreibt es" und nicht "ich schreibe es". Es ist ein Gespräch, das etwas hervorbringt, das keiner von uns allein geschrieben hätte.

Ich habe auch eigene Anweisungen für die Codebasis selbst erstellt. Eine Copilot-Anweisungsdatei, die die Architektur, das Übersetzungssystem, die Tenant-Isolation-Regeln und die Codierungskonventionen erklärt. Claude liest sie zu Beginn jeder Sitzung, und der Unterschied ist wie Tag und Nacht. Ohne sie rät Claude. Mit ihr weiß Claude Bescheid.

Der Punkt ist: Die Produktivitätsgewinne sind real, aber sie sind nicht umsonst. Du investierst im Vorfeld Zeit, um der KI beizubringen, wie du arbeitest, und diese Investition zahlt sich über Wochen aus. Überspringst du diesen Schritt, verbringst du mehr Zeit damit, Claudes Ergebnisse zu korrigieren, als wenn du den Code selbst geschrieben hättest.

Dann musst du das Ding tatsächlich einsetzen.

An dieser Stelle ändert sich die Geschichte.

Du hast eine funktionierende Anwendung auf localhost. Wunderbar. Jetzt stelle sie ins Internet. Lass sie E-Mails verschicken. Lass die Leute sich anmelden. Akzeptiere eventuell Zahlungen. Schütze es vor Bots. Gib ihr einen Domainnamen, der korrekt aufgelöst wird.

Claude kann dir bei all dem nicht helfen. Nicht wirklich.

Ich meine nicht, dass er schlechte Vorschläge macht. Ich meine, dass er grundsätzlich nicht mit den Systemen interagieren kann, die du konfigurieren musst. Und die Konfiguration ist der Ort, an dem du deine Zeit verbringst, nicht das Schreiben von Code.

Cloudflare: Eine Fallstudie in "Finde es selbst heraus"

Die Marketing-Website von Rasepi läuft auf Cloudflare Pages. Die Wartelisten-API ist ein Cloudflare Worker mit einer D1-Datenbank. Das klingt einfach, bis du es tatsächlich einrichten musst.

Claude hat dein Cloudflare Dashboard noch nie gesehen. Es kann dir zwar sagen, dass du einen CNAME-Eintrag hinzufügen sollst, aber es kann dir nicht sagen, welche der 14 Registerkarten die DNS-Einstellungen für deine spezielle Domain enthält. D1-Datenbankbindungen benötigen eine bestimmte Datenbank-ID in deinem wrangler.toml. Umgebungsgeheimnisse gehen über wrangler secret put. CORS muss mit deinem tatsächlichen Einsatzort übereinstimmen, nicht mit localhost. Turnstile benötigt Schlüssel aus einem anderen Dashboard-Bereich.

Ich habe fast einen ganzen Tag damit verbracht, den Worker dazu zu bringen, Turnstile-Tokens korrekt zu verifizieren, Formular-Eingaben zu akzeptieren, sie in D1 zu speichern und Bestätigungs-E-Mails zu versenden. Claude hat mir geholfen, den Code für den Worker selbst zu schreiben. Aber das Deployment, die Wrangler-Konfiguration, die Verwaltung der Geheimnisse und das Debugging der DNS-Verbreitung? Das war alles ich.

OAuth2: Das Konfigurationslabyrinth

Die Authentifizierung ist das beste Beispiel für die Kluft zwischen "Code" und "Produkt".

Claude kann dir durchaus eine OAuth2-Integration schreiben. Er kennt die OIDC-Spezifikation, kann Middleware erstellen und versteht JWT-Claims. Für unsere Entwicklungsumgebung habe ich einen DevAuthHandler, der Token mit tenant_id und sub Claims aus einem einfachen Bearer String Pattern prägt. Claude hat das in wenigen Minuten geschrieben.

Aber Produktionsauthentifizierung bedeutet OpenIddict, und OpenIddict bedeutet, dass man sub-Ansprüche, tenant_id-Ansprüche, Callback-URLs, JavaScript-Ursprünge, Logout-URIs und all den anderen Blödsinn herausfinden muss, der zu einer echten Identitätseinrichtung gehört. Und das, bevor du zu den externen Anbietern kommst.

Denn deine Nutzer wollen sich bei Google, Microsoft oder GitHub anmelden. Und Claude kann sich bei keiner dieser Entwickler-Konsolen für dich anmelden. Das kann es nicht:

eine OAuth-Anwendung in der Google Cloud Console erstellen und eine Client-ID und ein Geheimnis generieren
eine App im Microsoft Entra Portal registrieren und die Redirect URIs konfigurieren
eine GitHub OAuth App einrichten und die Anmeldedaten abrufen
Konfiguriere die Callback-URLs der einzelnen Anbieter für jede Umgebung, die du betreibst
Verkabelung der richtigen Bereiche, Zustimmungsbildschirme und Token-Endpunkte

Jeder Anbieter hat sein eigenes Entwicklerportal, seine eigene Terminologie und seinen eigenen Ablauf für die Generierung von Anmeldeinformationen. Google nennt es einen "Zustimmungsbildschirm". Microsoft nennt es "App-Registrierungen". GitHub nennt es "OAuth Apps" (nicht zu verwechseln mit "GitHub Apps", die etwas ganz anderes sind). Und bei jeder einzelnen musst du eine Client-ID und ein Geheimnis manuell in deine Konfiguration kopieren.

Claude kann die Konfiguration des OpenIddict-Servers, die Middleware des externen Anbieters und die Logik zur Umwandlung der Ansprüche schreiben. Aber die eigentliche Generierung der Anmeldeinformationen, die Portalnavigation, die Einrichtung der umgebungsspezifischen URL? Das machst du selbst, indem du dich in einem Browser durch die Dashboards klickst.

E-Mail: Es ist nie nur "eine E-Mail senden"

Der Code zum Versenden einer E-Mail über die Resend API besteht aus etwa 15 Zeilen. Claude hat ihn ohne Probleme geschrieben. Aber damit die E-Mails auch wirklich im Posteingang ankommen? Das erfordert eine verifizierte Absenderdomäne, DNS-Einträge für SPF, DKIM und DMARC, das Warten auf die Weiterleitung und das Testen der Zustellbarkeit, denn Gmail und Outlook haben ihre eigene Meinung darüber, ob deine Domäne vertrauenswürdig ist.

Und du musst eine E-Mail-Vorlage entwerfen, die nicht in jedem E-Mail-Client schrecklich aussieht. Outlook unter Windows verwendet auch 2026 noch die Word-Rendering-Engine. Lass das auf dich wirken.

Die komplette Liste der Dinge, die ich ohne KI gemacht habe

Als ich auf drei Wochen Arbeit zurückblickte, fing ich an, eine grobe Auflistung dessen zu machen, was Claude gebaut und was ich von Hand konfiguriert hatte. Die Liste "von Hand" ist länger, als ich erwartet hatte:

Cloud-Infrastruktur:

Einrichtung des Cloudflare Pages-Projekts und Konfiguration der benutzerdefinierten Domain
Einrichtung von Cloudflare Worker und Bereitstellung der D1-Datenbank
DNS-Einträge für Marketingseite, API und E-Mail-Versand
Konfiguration von SSL/TLS-Zertifikaten (meist automatisch, aber die Fehlersuche ist mühsam, wenn sie nicht funktioniert)
Konfiguration der Build-Pipeline für den Blog (Eleventy + Übersetzung + OG-Bilderstellung)

Authentifizierung & Sicherheit:

Google, Microsoft und GitHub OAuth App-Registrierung und Generierung von Anmeldeinformationen
OpenIddict-Konfiguration mit korrekten Claims, Callback-URLs, JS-Originals und Logout-URIs
Einrichtung des Turnstile-Botschutzes (Site Keys, geheime Schlüssel, Dashboard-Konfiguration)
Konfiguration der CORS-Richtlinie zwischen Frontend, API und Worker-Originals

E-Mail:

Einrichtung von Resend-Konto und API-Schlüssel
SPF, DKIM, DMARC DNS-Einträge
Testen der Zustellbarkeit von E-Mails und Fehlerbehebung
Testen von Vorlagen für verschiedene E-Mail-Clients

Drittanbieter-Integrationen:

DeepL API-Konto und Schlüsselverwaltung
Google Analytics-Einrichtung mit Cookie-Einwilligung

Azure Hosting:

Einrichtung und Konfiguration des Azure App Service für das .NET-Backend
Azure SQL-Datenbankbereitstellung, Firewall-Regeln und Verbindungsstrings
Einrichtung von Azure Cache für Redis und Konfiguration der Verbindung
Azure OpenAI Ressourcenbereitstellung für Einbettungen und RAG

Bereitstellung:

Docker-Konfiguration für das .NET-Backend
Verwaltung von Umgebungsvariablen für drei verschiedene Bereitstellungsziele
Datenbankverbindungsstrings für verschiedene Umgebungen

Und ehrlich gesagt habe ich wahrscheinlich ein paar Dinge vergessen. Jeder Drittanbieterdienst hat sein eigenes Dashboard, sein eigenes Anmeldemodell, seine eigene Dokumentationsqualität (die sehr unterschiedlich ist) und seine eigenen Macken.

Warum das wichtiger ist, als man denkt

Das ist die Dimension, die in jeder Diskussion über KI-gestützte Entwicklung untergeht: KI-Tools haben keinerlei Informationen über deine Infrastruktur.

Deine Codebasis besteht aus Dateien, die eine KI lesen kann. Deine Cloudflare-Konfiguration ist es nicht. Deine Google OAuth App-Einstellungen sind es nicht. Deine DNS-Einträge sind es nicht. Dein Resend-Domain-Verifizierungsstatus ist es nicht. Die gesamte operative Oberfläche eines echten Produkts ist für KI-Tools unsichtbar, und diese Oberfläche ist riesig.

Das Schreiben von Code ist der einfache Teil der Softwareentwicklung, und es wird von Tag zu Tag einfacher. Der schwierige Teil ist, was du mit dem Code machst. Ihn zu betreiben, ihn zu verstehen, wenn um 2 Uhr morgens etwas nicht funktioniert, ihn zu erweitern, wenn sich die Anforderungen ändern, und ihn über seinen gesamten Lebenszyklus hinweg zu verwalten. KI macht den einfachen Teil schneller. Für den schwierigen Teil tut sie nichts.

Die Marketing-Site verdient einen eigenen Bereich

Ich habe die gesamte Marketing-Seite von Rasepi in etwa vier Tagen erstellt. Homepage, Preisseite, Anmelde- und Kontaktformulare mit Bot-Schutz, Datenschutzbestimmungen, vier Vertiefungsseiten zu den Funktionen. Claude hat wahrscheinlich 70 % des HTML/CSS gemacht.

Aber dann musste ich die Seite auch noch im Internet veröffentlichen. Der Blog läuft auf Eleventy mit einer 8-stufigen Build-Pipeline: Übersetzen von Beiträgen über DeepL, Erstellen der Website, Übersetzen statischer HTML-Seiten, Kopieren gemeinsam genutzter Assets, Generieren von OG-Bildern aus SVGs, Generieren von Audio-Versionen, Verwalten von Audio-Manifesten, Erstellen einer mehrsprachigen Sitemap. Claude half dabei, Teile dieser Pipeline zu schreiben, aber bis alles mit den richtigen Dateipfaden und den richtigen Einstellungen für die Bereitstellung von Cloudflare Pages funktionierte, brauchte es einen ganzen Tag voller Versuch und Irrtum.

Und die Entwicklerdokumentationsseite? Das ist ein separates Cloudflare Pages-Projekt mit einer eigenen Domain, einer eigenen Build-Konfiguration und eigenen Deployment-Triggern. Ein weiteres Dashboard, eine weitere Reihe von Umgebungsvariablen, eine weitere Runde DNS.

Das Muster, das ich immer wieder erkenne

Bei einem bestimmten Feature erledigt Claude etwa 80% der Arbeit nach Umfang. Codezeilen, erstellte Dateien, gelöste Probleme. Die restlichen 20 % sind manuelle Konfigurationsarbeit: sich durch Web-Dashboards klicken, Schlüssel zwischen Diensten kopieren, Integrationsprobleme beheben, die sich erst in der installierten Umgebung zeigen.

Und diese 20% dauern mindestens genauso lange wie die anderen 80%. Manchmal sogar noch länger.

Aber hier ist die Sache, die sich im Vergleich zu früher geändert hat: In der Vergangenheit hast du entweder Code geschrieben oder die Konfiguration vorgenommen. Niemals beides. Wenn du einen Tag damit verbracht hast, Stripe-Webhooks einzurichten und die Zahlungsströme im Dashboard zu testen, hast du an diesem Tag keinen Anwendungscode geschrieben. Dein Projekt kam an einer Stelle zum Stillstand, während du an der anderen gearbeitet hast.

Mit Claude ist das nicht mehr der Fall. Während ich mich im Stripe-Dashboard mit Webhook-Endpunkten und Ereignistypen beschäftigte, entwickelte Claude die nächste Service-Schnittstelle. Während ich mich zum dritten Mal durch die OAuth-Zustimmungsmaske von Google klickte, weil ich die Scopes falsch eingegeben hatte, schrieb Claude Vue-Komponenten. Mein Kopf war im Konfigurationsland, aber die Codebasis wuchs weiter. Das ist wirklich neu. Ein einzelner Entwickler kann jetzt an zwei Fronten gleichzeitig arbeiten, und das ist vielleicht der größte praktische Unterschied, den KI für kleine Teams macht.

Wenn du mit Hilfe von KI Code schreibst, befindest du dich in einer engen Feedbackschleife. Schreiben, testen, korrigieren, iterieren. Wenn du herausfindest, warum dein Cloudflare Worker nur in der Produktion CORS-Fehler zurückgibt, starrst du auf Dashboard-Screenshots, liest Beiträge in Community-Foren und probierst wahllos Konfigurationsänderungen aus, in der Hoffnung, dass eine von ihnen funktioniert.

Was muss sich ändern?

Ich glaube nicht, dass dies eine dauerhafte Einschränkung ist. Der fehlende Teil liegt auf der Hand: KI-Tools müssen in der Lage sein, mit Service-APIs und Dashboards von Drittanbietern zu interagieren. Sie müssen nicht nur Code schreiben, der sie aufruft, sondern sie auch konfigurieren können.

Einiges davon ist bereits in Arbeit. MCP (Model Context Protocol)-Server für verschiedene Dienste tauchen immer häufiger auf. Anthropic denkt eindeutig über die Nutzung von Werkzeugen als ein erstklassiges Konzept nach. Aber wir sind noch lange nicht an dem Punkt, an dem ich sagen könnte: "Richte meinen Cloudflare Worker mit einer D1-Datenbank ein, konfiguriere die benutzerdefinierte Domain und füge den Turnstile-Schutz hinzu", und es würde tatsächlich passieren.

Bis dahin ist die ehrliche Geschichte, ein Produkt mit KI zu entwickeln, die folgende: KI ist ein unglaublicher Beschleuniger für das Schreiben von Anwendungscode. Aber ein verkaufsfähiges Produkt besteht nur zur Hälfte aus Anwendungscode. Die andere Hälfte ist die Infrastruktur, die Integration von Drittanbietern, die Bereitstellung von Pipelines, die Zustellbarkeit von E-Mails, die Konfiguration von Domains und die Einrichtung der Sicherheit. Und für all das bist du auf dich allein gestellt.

(Das ist übrigens einer der Gründe, warum wir Rasepi als gehostete Plattform aufbauen und nicht nur Open-Source-Code bereitstellen. Die Dokumentationssoftware zum Laufen zu bringen, ist nicht so schwer. Sie zuverlässig zum Laufen zu bringen, mit der richtigen Autorisierung, E-Mail und Hosting? Das ist das Produkt.)

Wenn du das ausprobieren willst

Ein paar praktische Dinge, die ich gelernt habe und die dir Zeit sparen könnten:

Fange mit der Infrastruktur an, nicht mit dem Code. Richte zuerst dein Hosting, deinen Autorisierungsanbieter, deinen E-Mail-Dienst und deine benutzerdefinierten Domains ein. Setze ein "Hallo Welt" in der Produktion ein, bevor du eine einzige Zeile echten Anwendungscodes schreibst. Die Zahl der Probleme, die erst in einer produktiven Umgebung auftauchen, ist deprimierend.
**Bewahre eine Anmeldedokumentation auf ** Du wirst API-Schlüssel, Client-IDs, Callback-URLs, Datenbank-IDs und geheime Schlüssel haben, die über 8 verschiedene Dashboards verstreut sind. Ich verwende eine lokale verschlüsselte Datei. Du kannst auch 1Password oder etwas anderes verwenden. Hauptsache, du hast einen einzigen Ort.
Wenn Claude dir hilft, die Funktion in 2 Stunden zu erstellen, solltest du mindestens weitere 2 Stunden für die Bereitstellung, die Konfiguration der Integrationen und die Tests in der Produktion einplanen.
Akzeptiere, dass es Tage gibt, an denen du nur am Dashboard arbeitest.** Es gab Tage, an denen ich praktisch keinen Code geschrieben, aber entscheidende Fortschritte gemacht habe: OAuth-Apps bei drei Anbietern registrieren, E-Mail einrichten, DNS debuggen. Diese Tage fühlen sich weniger produktiv an, aber das sind sie nicht.

Drei Wochen sind für das, was ich gebaut habe, immer noch verdammt schnell. Ich beschwere mich nicht über Claude. Mit ihm konnte ein einzelner Entwickler etwas bauen, wofür ein kleines Team normalerweise ein ganzes Jahr gebraucht hätte. Aber bei der Geschichte, die im KI-Hype-Zyklus erzählt wird (Eingabeaufforderung, Code, Auslieferung, fertig), fehlt der gesamte Mittelteil, in dem du die Sache realisierst.

Die App ist der einfache Teil. Sie in die Realität umzusetzen ist die Aufgabe.