Claude Code ermöglicht jetzt Programmieren vom Handy – Was ich dabei schmerzlich lernen musste
Ich saß im Taxi Richtung Strand, als die Vercel-Mail reinkam.
Production down. Deployment failed.
Ich starrte eine Sekunde auf mein Handy. Dann fiel mir ein: Claude Code hat jetzt eine Web-Version. Funktioniert mobil. Wollte ich schon länger ausprobieren.
Also tat ich das Vernünftige. Öffnete Claude Code Web, beschrieb den Fehler und sah zu, wie ein AI-Agent mein Production-System reparierte, während ich buchstäblich auf dem Weg zum Schwimmen war.
Drei Minuten später: Fix fertig, Branch gepusht, PR bereit.
Ich mergte es über GitHub Mobile.
Viva la Vida. 😎
Dann legte ich mein Handy weg und ging an den Strand. Macht man halt so, wenn eine AI die eigene Infrastruktur verwaltet.
Zehn Minuten später schickte Vercel noch eine Mail.
TL;DR: Ja, Claude Code Web lässt dich Production vom Handy aus fixen. Ja, ich hab's aus dem Taxi probiert. Ja, es hat "funktioniert." Der Rest dieses Artikels ist, was danach passierte.
Was ich vor dem Merge nicht gemacht habe: git diff ausführen. Oder npm run build. Oder buchstäblich irgendetwas, das dreißig Sekunden gedauert und mir vierzig Minuten erspart hätte.
Zu meiner Verteidigung: Ich war im Taxi. Und der Fix sah vernünftig aus. Drei Dateien geändert, eine saubere Commit-Message. Was sollte schon schiefgehen.
(Alles. Alles konnte schiefgehen.)
Der Container lebt nicht in deinem Projekt
Lass mich erklären, was Claude Code Web tatsächlich macht, wenn es eine Aufgabe bekommt, denn die Demos lassen es wie Magie aussehen und das ist es nicht (es ist etwas Interessanteres und gleichzeitig Begrenzteres).
Wenn du eine Aufgabe einreichst, startet Claude Code Web einen frischen, isolierten Cloud-Container, klont dein Repository hinein und fängt an zu arbeiten. Was es hat: deinen Code. Was es nicht hat: deine .env-Datei, deine lokalen Packages, deine spezifische Framework-Version, deine Deployment-Konfiguration und jeglichen Kontext von Commits, die vor seinem Auftauchen passiert sind.
Es liest deine Dateien. Es führt Befehle aus. Es beobachtet die Fehler, die diese Befehle produzieren. Dann repariert es, was es sieht.
Der Unterschied ist subtil genug, dass man ihn leicht übersieht. Die AI liegt nicht falsch (sie diagnostiziert aus einer anderen Umgebung als der, in der dein Code tatsächlich läuft). Ihre Fixes sind kohärent. Sie sind nur kohärent mit einem Kontext, der nicht zu deinem passt.
Stell dir vor, du schickst einem Mechaniker per WhatsApp ein Foto von deinem kaputten Fahrrad. Er schaut es an, sagt "es ist die Kette." Du tauschst die Kette aus. Das Rad funktioniert immer noch nicht. Das eigentliche Problem war der Bremszug (auf dem Foto nicht sichtbar). War der Mechaniker inkompetent? Nein. Er arbeitete mit dem, was er sehen konnte. Der Rest war für ihn unsichtbar.
Claude Code Web ist der Mechaniker. Dein Repo ohne Umgebungskontext ist das Foto. Dein tatsächlicher Production-Bug ist der Bremszug.
In meinem Fall spielte sich das mit beeindruckender Präzision ab.
Eine Tour durch meine Phantom-Fixes
Hier ist, was die Sandbox in ihrer eigenen Session dokumentierte, und hier ist, was tatsächlich vor sich ging:
Fix #1: Der Font-Package-Swap.
Die Sandbox notierte: "Das wahrscheinlichste Deployment-Problem ist, dass der Google Fonts-Fetch während des Turbopack-Builds fehlschlägt. Der Wechsel zu einem lokal gebündelten Package vermeidet Netzwerk-Requests während des Builds."
Völlig logisch. In einem isolierten Container mit eingeschränktem Outbound-Netzwerkzugang schlägt das Fetchen von Fonts von einem externen CDN zur Build-Zeit fehl. Also wechselte es zu einer lokal gebündelten Alternative. Clever.
In meiner tatsächlichen Production-Umgebung funktioniert der ursprüngliche Import perfekt und hat monatelang funktioniert. Die Sandbox reparierte ein Problem, das ich nie hatte, mit einer Dependency, die ich nie installiert hatte. Cool. Danke.
Fix #2: Die Placeholder-URL.
Fehlende Umgebungsvariable im Container → Client crashte zur Build-Zeit → Lösung: Fallback zu einer toten Cloud-URL hinzufügen, damit der Build nicht bricht.
In Production existiert die echte Variable. Also würde der Fallback stillschweigend nichts tun, außer die Variable würde jemals fehlen (dann würde die App stillschweigend zu nirgendwo verbinden, anstatt laut zu crashen).
Großartig. Ein Fix, der korrekt in einer Umgebung funktioniert, die nicht existiert, und stillschweigend in einer Umgebung degradiert, die existiert.
Fix #3: Die Lazy Initialization.
Dieser war tatsächlich korrekt. Einen Client zur Modul-Load-Zeit zu instanziieren verursacht echte Probleme mit statischem Prerendering, unabhängig von env vars. Das Refactoring zu Lazy Initialization ist genuiner bessere Praxis.
Einer von drei. Nehme ich.
Keiner der drei berührte den tatsächlichen Grund, warum mein Deployment fehlschlug.
Der echte Bug (Es war ein Icon)
Ein paar Commits vor all dem hatte ich ein Custom-Favicon hinzugefügt. Eine kleine Datei, in ein Verzeichnis geworfen, wo das Framework lief. Was ich nicht wusste: In meiner Framework-Version führt das Platzieren einer Datei mit diesem spezifischen Namensschema in diesem Verzeichnis dazu, dass sie als Route Handler behandelt wird, nicht als statisches Asset. Der Build war seit diesem Commit stillschweigend kaputt.
Die Sandbox erwähnte es nie. Warum auch (die Fehler in ihren Build-Logs waren der Font-Fetch und die fehlende env var). Das Icon-Problem produzierte eine andere Art von Fehlschlag, einen, der nur in einer spezifischen Build-Umgebung auftaucht. Unsichtbar vom Container aus.
Als ich mich endlich an meinen Laptop setzte und einen lokalen Build laufen ließ, zeigte der Output direkt auf die Icon-Datei. Dreißig Sekunden zum Identifizieren. Fünf Minuten zum Fixen.
Dieser Fix ist nicht im Sandbox-Branch. Konnte nicht sein. Die Sandbox hatte keine Ahnung, dass er existierte.
Also zur Zusammenfassung: Ich mergte einen Branch, der eine Dependency hinzufügte, die ich nicht brauchte, einen stillen Fehlermodus einführte und eine Sache korrekt refaktorierte (während die tatsächliche Ursache meines Production-Ausfalls unberührt dasaß und darauf wartete, dass ich meinen Laptop wie ein Erwachsener öffne).
Der Revert (Ja, ich musste den Fix reverten)
Das lokal gebündelte Font-Package war nicht in meinen ursprünglichen Dependencies. Die Sandbox hatte es hinzugefügt. Also produzierte das Ausführen eines lokalen Builds nach dem Merge einen brandneuen Fehlschlag: Package als Dependency gelistet, aber nicht tatsächlich installiert.
Ich holte die ursprüngliche Layout-Datei aus der Git-History. Entfernte das neue Package. Reinstallierte. Revertierte die Placeholder-URL zurück zu einem harten Crash bei fehlender env var (denn wenn diese Variable jemals in Production verschwindet, will ich eine laute Explosion, keine höfliche Verbindung zu nichts).
Behielt die Lazy Initialization. Die hatte sich ihren Platz verdient.
Commit. Push. Sauberes Deployment.
Gesamte verstrichene Zeit zwischen "Laptop bleibt zu" und "Laptop geht wieder zu": vierzig Minuten. Der Strand war schön. Das Debugging war es nicht.
Drei Regeln, die tatsächlich gelten
Behandle jeden Sandbox-Branch wie Code von jemandem, der dein Projekt nie ausgeführt hat.
Nicht weil die AI schlecht in ihrem Job ist. Weil sie dein Projekt buchstäblich nicht ausgeführt hat (sie hat eine Rekonstruktion davon ausgeführt, der die Teile fehlen, die außerhalb deines Repositories leben). Review das Diff. git diff main..origin/branch-name sind fünfzehn Sekunden. Wenn du ein neues Package siehst, eine Fallback-URL, eine Dependency, die du nicht hingelegt hast (die Sandbox kompensierte für etwas, das sie nicht hatte). Finde heraus, ob dieses Etwas real ist, bevor es shipped.
Führe einen Build lokal aus, bevor du irgendetwas in der Nähe von Build-Config mergst.
npm run build. Oder was auch immer dich nah an deine tatsächliche Deploy-Umgebung bringt. Dieser einzelne Schritt hätte mein ganzes Abenteuer beendet, bevor es anfing. Der Phantom-Font-Fix wäre sofort fehlgeschlagen (Package nicht installiert). Dreißig Sekunden Terminal-Output schlagen vierzig Minuten Post-Merge-Archäologie.
Die drei Minuten, die das zu deinem Workflow hinzufügt, sind nicht der Bottleneck. Du weißt das. Gib es zu.
Gib der Sandbox deine Umgebung, bevor du ihr eine Aufgabe gibst.
Claude Code Webs Task-Erstellungsbildschirm hat ein Umgebungsvariablen-Feld. Füge deine tatsächlichen env vars dort ein. Der Container läuft jetzt mit etwas, das deinem echten Kontext ähnelt. Die meisten Phantom-Fixes verschwinden. Der Agent hört auf, Probleme zu lösen, die du nicht hast, und fängt an, das zu lösen, das du tatsächlich hast.
Die ehrliche Version des Traums
Lass uns kurz über die "Code from anywhere"-Fantasie sprechen.
Niemand will wirklich einen Production-Fehlschlag am Strand debuggen. Das ist kein Traum, das ist eine Strafe. Auf einem Handy-Bildschirm in direktem Sonnenlicht blinzeln, Sand in der Tastatur, versuchen, einen Stack Trace zu verstehen. Das ist ein Albtraum mit guter Beleuchtung.
Der echte Traum ist anders. Etwas in die Warteschlange stellen und weggehen können. Ein Refactoring starten, es laufen lassen, zu einem Ergebnis zurückkommen. Der Teil funktioniert. Claude Code Web handhabt eigenständige Aufgaben sauber (alles, wo das Klonen des Repositories dem Agent alles gibt, was er braucht). Tests schreiben. Eine Komponente aufräumen. Dokumentation aktualisieren. Dinge umbenennen. Aufgaben, die vollständig im Code leben, keine env vars erforderlich, keine Build-Umgebungs-Eigenarten.
Der Taxi-zum-Strand-Workflow bricht spezifisch zusammen, wenn das Problem umgebungsbedingt ist. Was, wie sich herausstellt, Production-Deployment-Fehlschläge oft sind.
Stelle die Aufgabe in die Warteschlange. Geh an den Strand. Komm zurück und reviewe das Diff auf deinem Laptop wie ein Profi.
Das ist der tatsächliche Traum. Der Rest ist ein Tweet, der darauf wartet, zu passieren. 😬
Dasselbe zugrundeliegende Prinzip wie Vibe Coding ohne Constraints: Eine AI arbeitet kohärent innerhalb welchen Kontexts auch immer sie hat. Gib ihr einen unvollständigen, und du bekommst kohärente Lösungen für das falsche Problem. Env vars in der Sandbox, lokaler Build vor Merge, git diff vor Approve (jedes Mal derselbe Zug). Du kämpfst nicht gegen die AI. Du gibst ihr deine Realität anstatt einer Fotokopie.
In sechs Monaten wird irgendein Devtool "intelligente Sandbox-Kontext-Synchronisation" als Premium-Feature shippen. Es wird eine Warteliste geben. Die Onboarding-Mail wird sagen "code from anywhere."
Die Entwickler, die bereits einen lokalen Build vor dem Merge ausführen, werden es nicht brauchen.
Sie wissen bereits, was der Container nicht sehen kann.
Sie sind bereits an den Strand gegangen. Ohne ihren Laptop. Mit Absicht.
Das ist die tatsächliche Zukunft der Entwicklung.
Ressourcen: Claude Code Dokumentation — Anthropic Sandboxing Guide
Ich schreibe über das Bauen von Production-Systemen mit AI-Tools (die Teile, die es nicht in die Launch-Threads schaffen). Kein Zeitplan, kein Füllmaterial. Kommt, wenn es etwas Erwähnenswertes gibt.
(*)Das Cover ist AI-generiert. Ich hätte an den Strand gehen können, anstatt es zu prompten. Im Nachhinein wäre das der klügere Schachzug gewesen.
Production-Fixes vom Handy sind cool, aber Vorsicht: Nicht jeder AI-Agent kennt deine spezifische Infrastruktur. Meine wöchentliche Sammlung von Lehren aus der Praxis zeigt dir, wie du solche Fallen umgehst.