Einführung & Setup

Claude Code – Einführung & Setup

0:00 Werkzeuge, die Code schreiben, gibt es seit Jahren. Neu ist etwas anderes: Das Werkzeug sitzt nicht mehr neben Ihnen und schlägt die nächste Zeile vor, sondern es arbeitet im Projekt — liest, plant, ändert, testet. Genau darum geht es in diesem Kapitel. Wir klären zuerst, was ein Coding-Agent überhaupt verändert, bringen Claude Code dann auf Ihrem Rechner zum Laufen und schauen uns an, über welche Oberflächen Sie ihn bedienen können.

0:25 Das Ziel für die nächste Stunde ist bewusst bescheiden und bewusst konkret: eine lauffähige Umgebung — und ein erstes Erfolgserlebnis, das Sie selbst ausgelöst haben.

Einführung & Setup

0:35 Dieser erste Tag ist der Tag der Grundlagen — und zwar der handfesten. Wir beginnen mit der Einordnung: Was ändert sich an Ihrer Arbeit, wenn ein Agent im Terminal mitarbeitet? Danach wird es praktisch mit der Installation auf macOS, Linux und WSL. Zum Schluss die Frage, wo Sie eigentlich arbeiten wollen — Terminal, Desktop-App oder direkt im Editor.

0:57 Am Ende soll niemand hier sitzen und zuschauen: Jede und jeder hat eine laufende Session vor sich.

Beschleunigte Entwicklung

1:03 Fangen wir mit dem Warum an. Bevor wir irgendetwas installieren, lohnt sich die Frage, was sich an der täglichen Arbeit eigentlich verschiebt — und was nicht. Denn die entscheidende Veränderung ist weniger die Geschwindigkeit als die Rolle, die Sie dabei einnehmen. Stellen Sie sich eine neue Kollegin vor, die am ersten Tag schon das gesamte Projekt gelesen hat.

1:24 Sie bekommt eine Aufgabe in normaler Sprache beschrieben, sucht sich die passenden Dateien selbst, macht einen Vorschlag, führt die Tests aus und meldet zurück, was funktioniert hat. Genau das ist mit „agentisch" gemeint: Claude Code arbeitet im Terminal, liest die Codebasis, plant, ändert Dateien und prüft das Ergebnis — gesteuert über Sprache statt über Klicks.

1:45 Der Unterschied zur Autovervollständigung ist also kein gradueller. Sie tippen nicht schneller, Sie delegieren. Und wer delegiert, muss beschreiben können, was er will — das wird gleich noch wichtig. Warum lohnt sich dieser Umstieg? Vor allem, weil der Bruch verschwindet, den wir uns über Jahre angewöhnt haben: hier der Editor, dort der Browser mit der Doku, dazwischen das Terminal für die Tests.

2:08 Der Agent kennt das ganze Projekt, nicht nur die geöffnete Datei — und Schreiben, Testen und Debuggen passieren am selben Ort. Der ehrlichste Gewinn liegt dabei bei der Routine: Refactorings, Boilerplate, das dritte fast identische Formular. Das sind die Aufgaben, die Zeit fressen, ohne dass jemand dabei klüger wird. Wichtig ist die andere Seite der Rechnung: Delegieren heißt prüfen.

2:31 Die Verantwortung wandert nicht mit. Diese Gegenüberstellung sollten Sie nicht als „vorher schlecht, nachher gut" lesen. Das Muster dahinter ist ein anderes: In der linken Spalte tragen Sie jeden einzelnen Schritt selbst — die Zeile, die Recherche, den Testlauf, den Kontext im Kopf. Rechts verschiebt sich Ihre Arbeit an den Anfang und ans Ende der Kette: Sie formulieren die Aufgabe präzise, und Sie bewerten das Ergebnis. Alles dazwischen ist delegierbar.

2:58 Deshalb steht in der letzten Zeile auch das Projektwissen in einer Datei statt in Ihrem Kopf — was der Agent nicht lesen kann, kann er nicht berücksichtigen. Und die Fußzeile ist der Kern des Tages: Der Mensch bleibt Reviewer und trifft die Entscheidungen. Jetzt sind Sie dran — und zwar bewusst mit etwas Kleinem. Suchen Sie sich eine Aufgabe, die Sie in einem Satz beschreiben können: eine Funktion umbenennen, eine README-Sektion ergänzen.

3:23 Es geht in dieser Übung nicht darum, den Agenten an seine Grenzen zu bringen, sondern darum, den Kreislauf einmal zu durchlaufen: beschreiben, arbeiten lassen, Ergebnis anschauen, bewusst annehmen oder ablehnen. Dieses Ablehnen ist ausdrücklich Teil des Erfolgs — wer nur abnickt, hat den Schritt übersprungen, auf den es ankommt.

3:42 Achten Sie beim Lesen darauf, ob Sie nachvollziehen können, warum der Agent so entschieden hat.

Installation

3:48 So weit die Theorie — jetzt bringen wir das Werkzeug auf Ihren Rechner. Die gute Nachricht vorweg: Das ist erfreulich unspektakulär und in wenigen Minuten erledigt. Die kleinen Fallstricke, die es trotzdem gibt, nehmen wir gleich gemeinsam mit. Claude Code ist ein Kommandozeilen-Werkzeug — ein CLI. Das klingt technischer, als es ist: Sie installieren einmal ein Programm, wechseln danach in Ihren Projektordner und tippen `claude`. Mehr Startvorgang gibt es nicht.

4:17 Wichtig ist dabei der Ordner, in dem Sie starten, denn er bestimmt, welches Projekt der Agent vor sich hat. Für die Installation gibt es zwei Wege: den nativen Installer per Skript — das ist der empfohlene, weil er keine weiteren Voraussetzungen mitbringt — und alternativ den Weg über npm, wenn Node ohnehin zu Ihrem Alltag gehört.

4:36 Beide führen zum selben Ergebnis. Der rote Faden dieser fünf Schritte ist schnell erzählt. Sie öffnen das Terminal im Projektordner, weil dort später der Kontext herkommt. Dann läuft das Installationsskript durch. Der dritte Schritt sieht überflüssig aus, ist es aber nicht: Ein frisches Terminal muss her, damit der `PATH` die neue Installation überhaupt kennt — das ist mit Abstand die häufigste Stolperfalle.

5:00 Danach starten Sie `claude`, melden sich im Browser an, und der letzte Schritt ist der eigentliche Test: ein erster Prompt in einer echten Session. Wer Node bereits nutzt, findet in der Fußzeile den npm-Weg als gleichwertige Alternative. Diese vier Zeilen sind das ganze Setup. Die erste holt das Installationsskript und führt es aus — der klassische Einzeiler, den Sie von vielen Entwickler-Werkzeugen kennen.

5:24 Ein kurzer Hinweis in eigener Sache: Ein Skript aus dem Netz direkt in die Shell zu leiten, ist bequem, verlangt aber Vertrauen in die Quelle. Bei der offiziellen Domain ist das vertretbar, als Gewohnheit sollte man es nicht übernehmen. Die zweite Zeile ist Ihre Kontrolle: Kommt eine Versionsnummer zurück, hat alles geklappt. Und die dritte startet die Session.

5:44 Beim allerersten Mal führt Claude Code Sie durch den Login im Browser — danach sind Sie angemeldet und können loslegen. Diese vier Punkte kosten erfahrungsgemäß die meiste Zeit — und keiner davon ist ein echter Fehler. Der Klassiker ist das alte Terminal: Der Befehl `claude` existiert, aber Ihre Shell weiß noch nichts davon, weil sie den `PATH` beim Start eingelesen hat.

6:07 Neues Fenster, Problem weg. Unter Windows gibt es einen eigenen Installer — Sie brauchen WSL nicht, es geht auch ohne. Der dritte Punkt ist keine technische, sondern eine organisatorische Hürde: Ohne Konto keine Session, entweder über ein Claude-Abo oder über die Anthropic-Konsole. Und wenn im Firmennetz der Download hängt, ist meistens der Proxy schuld, nicht das Skript. Dann hilft der npm-Weg.

6:31 Jetzt geht es ans eigene Gerät. Ziel ist, dass Sie die Umgebung selbstständig zum Laufen bringen und den Start auch verifizieren — beides gehört zusammen. Zwei Belege reichen: `claude --version` gibt eine Version aus, und `claude` öffnet eine angemeldete Session in Ihrem Projektordner. Wenn das Installationsskript klemmt, greifen Sie ohne schlechtes Gewissen zum npm-Fallback; wir wollen hier keine Netzwerkkonfiguration debuggen.

6:55 Nehmen Sie sich die Zeit, kurz zu schauen, was beim ersten Start passiert — der Login-Ablauf und der Projektordner in der Statuszeile sagen Ihnen mehr, als es zunächst scheint.

Oberflächen & Editor-Integration

7:06 Die Umgebung läuft. Bleibt die Frage, wo Sie eigentlich arbeiten wollen. Denn das Terminal ist nur eine von mehreren Türen zu demselben Agenten — und welche Sie nehmen, ist weniger eine technische als eine Gewohnheitsfrage. Denken Sie an einen Streaming-Dienst: Sie schauen dieselbe Serie am Fernseher, am Laptop oder am Handy — der Dienst dahinter bleibt derselbe, nur die Bedienung passt sich an.

7:29 So funktioniert das hier auch. Ob Sie Claude Code als Terminal-CLI starten, die eigenständige Desktop-App öffnen oder die offizielle Erweiterung in VS Code nutzen — für JetBrains gibt es das Gegenstück —, dahinter steckt immer derselbe Agent mit denselben Fähigkeiten. Was sich unterscheidet, ist die Sicht auf die Arbeit: wo Diffs auftauchen, wie viel Kontext Sie nebenbei sehen. Sie müssen sich also nicht festlegen.

7:53 Statt die Zeilen abzulesen, halten wir das Prinzip fest: Die drei Oberflächen unterscheiden sich vor allem darin, wie nah sie am Code und wie nah sie an der Automatisierung sind. Das Terminal ist am direktesten und als Einziges skriptbar — deshalb ist es der Standard und die einzige Option, wenn Claude Code irgendwann in einer Pipeline mitlaufen soll.

8:13 Die Desktop-App senkt die Einstiegshürde und eignet sich, wenn mehrere Sessions parallel laufen. Und die Editor-Integration punktet dort, wo Sie Änderungen sehen wollen, während sie entstehen. Entscheidend ist die Fußzeile: Es ist keine Entweder-oder-Frage. Die meisten kombinieren nach Aufgabe. Die Einrichtung im Editor ist in vier Handgriffen erledigt und folgt dem, was Sie von jeder anderen Erweiterung kennen: Marktplatz öffnen, „Claude Code" suchen, installieren.

8:40 Der einzige Schritt, der wirklich zu dieser Extension gehört, ist die Verbindung mit Ihrem Claude-Konto — dieselbe Anmeldung wie im Terminal, es entsteht kein zweites Konto. Danach starten Sie die Session über die Seitenleiste, wieder im Projektkontext. Der eigentliche Unterschied zeigt sich erst im Betrieb, und darauf sollten Sie achten: Änderungen erscheinen als Diff direkt im Editor, dort, wo Sie ohnehin hinschauen.

9:04 Für diese Übung brauchen Sie nichts Neues zu erfinden — nehmen Sie dieselbe kleine Aufgabe von vorhin und führen Sie sie ein zweites Mal aus, diesmal in der Desktop-App oder in VS Code. Das Lernziel klingt banal, ist es aber nicht: Sie sollen den Unterschied einordnen können, nicht nur bemerken. Achten Sie darauf, wo Diffs auftauchen, wie viel Projektkontext Sie nebenbei sehen und wo Ihnen das Bestätigen leichter fällt.

9:27 Am Ende sollten Sie sagen können, welche Oberfläche für welche Art von Aufgabe Ihre erste Wahl ist — diese Antwort fällt für jeden etwas anders aus. Halten wir fest, was jetzt steht. Sie haben verstanden, dass Claude Code kein Vorschlagswerkzeug ist, sondern ein Agent im Terminal, der das ganze Projekt kennt — und dass sich damit Ihre Rolle vom Tippen zum Beschreiben und Prüfen verschiebt.

9:50 Sie haben das Werkzeug installiert, per Skript oder über npm, und mit `claude` eine Session gestartet. Und Sie wissen, dass dieselbe Fähigkeit über drei Türen erreichbar ist: Terminal, Desktop-App, Editor. Damit ist die Voraussetzung geschaffen für die eigentlich spannende Frage, die im nächsten Kapitel wartet: Wie beschreibt man eine Aufgabe so, dass ein gutes Ergebnis dabei herauskommt?

Startklar — es kann losgehen

10:12 Damit ist die Startlinie erreicht: Die Umgebung läuft, der erste Auftrag ist erledigt, und Sie haben den Kreislauf aus Beschreiben, Arbeiten lassen und Prüfen einmal selbst durchlaufen. Das ist die Grundlage für alles Weitere — denn ab hier geht es nicht mehr um Werkzeuge, sondern um Arbeitsweise: um Prompting, Planung und Architektur.

10:32 Nehmen Sie einen Gedanken mit in die Pause: Der Agent wird nur so gut, wie Ihre Beschreibung der Aufgabe es zulässt. Wenn Sie im Anschluss noch Fragen haben oder das Material suchen — alles finden Sie unter www.HCO.de.