- Cursor und Claude Code parallel genutzt und dabei vielfältige Praxiserfahrungen gesammelt – von echter Entwicklungsarbeit in großen Codebases bis hin zu LLM-Evaluierungs-Consulting
- Cursor war bei Power-Usern wegen der komfortablen UI/UX und des unbegrenzten API-Zugangs beliebt, doch die kürzlich eingeführten strengen Rate-Limits haben die User Experience stark eingeschränkt
- Sonnet 4 in Claude Code zeigt hohe Zuverlässigkeit und Effizienz beim Verstehen und Bearbeiten von Code sowie beim Umgang mit großem Kontext; in Kombination mit Opus 4 lassen sich auch schwierige Bugs lösen
- Für Power-User gibt es viele versteckte Advanced-Features wie eine kommandozeilenbasierte CLI-Umgebung und den Einsatz von Sub-Agents; kontinuierliches Experimentieren und Erkunden der Funktionen ist dabei wichtig
- Nachteile sind unter anderem die fehlende visuelle UI, langsames Kopieren/Einfügen, Einschränkungen bei der Nutzung anderer Modelle sowie der Wunsch nach zusätzlichen Verbesserungen wie Checkpoints
Von Cursor zu Claude Code: Hintergrund des Wechsels
- Bis vor Kurzem war Cursor bei Entwicklern wegen der unbegrenzten API-Nutzung und des intuitiven Diff-Review-Workflows sehr beliebt
- Deshalb wurde es vor allem für Gumroad bounties und Beratungsprojekte rund um AI Engineering und LLM-Evaluierung genutzt – sowohl zur Code-Generierung als auch zum schnellen Verständnis von Codebases
- Seit Mitte Juni wurden jedoch plötzlich starke Rate-Limits eingeführt, wodurch die Arbeitseffizienz stark sank und die Vorteile von Cursor deutlich kleiner wurden
- Unter verschiedenen Modellen wie Sonnet 4, Opus 4, GPT-4.1 und Gemini Pro 2.5 wurden in der Praxis vor allem Sonnet 4 und Opus 4 am häufigsten verwendet
- Wegen Einschränkungen wie API-Kosten und sinkender Geschwindigkeit wurde sogar ein Claude Code Max-Abonnement (200 Dollar pro Monat) in Betracht gezogen und ein ernsthafter Wechsel eingeleitet
Praxiserfahrungen mit Claude Code
- Claude Code wurde in mittelgroßen bis großen Open-Source-Codebases mit Python, Ruby und TypeScript (50M+ Tokens) eingesetzt; dabei wurde ein Feedback-Loop über Spezifikationen und Tests erlebt
- Anfangs wurden nur einfache Eingaben genutzt, später kamen mit dem Erlernen der Grundbefehle und des Plan-Modus deutlich tiefere Nutzungsmöglichkeiten hinzu
- Einfache Eingaben → Befehls-/Plan-Modus lernen → durch klare Command-Kombinationen Automatisierung und höhere Produktivität erreichen
- Es wurde eine gemischte Strategie genutzt, bei der Probleme fast wie in einem Beratungsgespräch frei eingegeben werden: der gesamte Kontext wird Claude übergeben, bei Bedarf wird für die Planung zu Opus gewechselt (Plan mode), während Sonnet 4 die Hauptarbeit übernimmt
- Claude wurde angewiesen, in Dateien im
.claude-Ordner zu protokollieren und zu strukturieren, um Kontextmanagement zu erleichtern und die Unbequemlichkeit beim Kopieren/Einfügen zu reduzieren; empfohlen wird die Kombination aus Plan-Modus und Auto-edit-Modus
- Kontextmanagement: Statt Komprimierung (compaction) lieber regelmäßig neue Chats starten und wichtige Änderungen in separaten Dateien notieren lassen
Kontextmanagement und Einsatz von Sub-Agents
- Claude Code unterstützt zwar Kontextkomprimierung, doch sie ist langsam und wenig effizient; daher wird bevorzugt, selbst Dateien mit den Kernaussagen anzulegen und dann einen neuen Chat zu beginnen
- In Hilfsdateien wie einem Scratchpad können Änderungen, Notizen und Historie festgehalten werden, um sie später für Branch-Arbeit oder Sitzungswiederherstellung (
/resume) zu nutzen
- Sub-Agents: Mehrere Aufgaben innerhalb einer Codebase (Suche, Analyse usw.) lassen sich parallel bearbeiten; so kann Arbeit in einer Multithreading-Struktur verteilt werden
- Intern werden To-do-Listen-basierte Multi-Agenten erzeugt, die beim Kontextmanagement helfen
Suche und Einsatz von Befehlen
- In Cursor stehen verschiedene Werkzeuge wie normale/semantische Suche und agentic search zur Verfügung, zudem ist die Suche schnell
- Die Suche in Claude Code kann dagegen langsam sein. Mit Sub-Agents ist jedoch Parallelverarbeitung in großen Codebases möglich
- Mit Sub-Agents sowie Befehlen wie task tool,
/think und /ultrathink lassen sich große Repositories erkunden und Aufgaben aufteilen
- Wichtig ist, per Shortcut
Shift + ? die Befehlsliste aufzurufen und neue Funktionen schnell zu prüfen
- Terminalbefehle (bash) können mit
! ausgeführt werden, auch im Headless-Modus
- Viele Advanced-Features sind integriert, darunter Datei-Tags (@Datei), die Memorize-Funktion (personalisierter system prompt) und
CLAUDE.md
Vergleich Sonnet 4 vs. Opus 4 und Workflow-Tipps
- Sonnet 4: In den meisten Situationen schneller und besonders stark bei langem Kontext plus Agentenarbeit. Im Vorteil bei Python und Frontend-Arbeit
- Opus 4: Kann verwirrt werden, wenn sich Instructions mehrfach ansammeln; dann empfiehlt es sich, sie in Dateien festzuhalten und einen neuen Chat zu starten. Wird eingesetzt, wenn Sonnet 4 bei schwierigen Bugs nicht weiterkommt
- Für komplexe Probleme wird ein Start mit Opus empfohlen, während allgemeines Coding mit Sonnet erledigt wird – also ein hybrider Betrieb
Individuelle Befehle und weitere Tipps
- Unterstützung für Custom-Commands wie
/pr-comments und /review, benötigt wird die GitHub CLI
- Beim Wechseln von Branches kann die Unterhaltung neu gestartet werden; auch flexible Workflows wie Diff-Reviews gegenüber
main sind möglich
- Mit zweimal
Esc kann die Unterhaltung jederzeit geforkt werden
- Mit
/permissions lassen sich Berechtigungen vor der Sitzung anpassen
- Wer mutig ist, kann claude
--dangerously-skip-permissions ausprobieren
- Empfehlung für das Video Cluade Code Pro TIPS
Was ich künftig ausprobieren möchte
- Ich möchte experimentieren, wie sich Custom-Commands direkt definieren und nutzen lassen
- Mit MCP-Servern wie dem Playwright server möchte ich Frontend-Automatisierung ausprobieren
- Der Fokus liegt auf dem Aufbau eines Feedback-Loops, in dem Claude Screenshots erstellt, die Ergebnisse erkennt und die UI iterativ verbessert
- Ich plane, alle in how-i-bring-the-best-out-of-claude-code-part-2 vorgeschlagenen Advanced-Nutzungsweisen praktisch auszuprobieren
- Ich will mich an Prompt-Optimierung versuchen
- Ich möchte Bewertungskriterien (
rubric.md) klar definieren und zusammen mit kontexttragenden Dateien (pmd usw.) einen Loop zum Bewerten und Verbessern von Prompts entwerfen
- Geplant ist eine Struktur, in der mehrere Claude-Instanzen verwendet werden: Eine Instanz erzeugt mit einem Prompt ein Ergebnis, eine andere bewertet es, gibt Feedback und verbessert es weiter (Single- oder Multi-Agent-System)
- Inspiriert ist dieser Ansatz von einem Post von Nirant
- Ich möchte ein Multi-Agent-System aufbauen, in dem mehrere Claude-Code-Instanzen über Action-Logs miteinander kommunizieren
Fazit und gewünschte Verbesserungen
- Cursor hat klare Stärken bei UI/UX, aber Claude Code regt in einer Power-User- und CLI-freundlichen Umgebung Produktivität und Experimentierfreude an
- Als Tool, das exploratives Lernen und Experimentieren stark belohnt, ist es für Nerds und Power-User sehr zu empfehlen
Funktionen, die verbessert werden sollten
- UI-Integration (Claudia als Referenz)
- Unterstützung für Checkpoints wie bei Cursor. Git gibt es zwar, aber der Ansatz von Cursor ist sehr bequem
- Bessere Qualität beim Kopieren/Einfügen
- Unterstützung für die Nutzung verschiedener Modelle
1 Kommentare
Hacker-News-Kommentare
Jedes Mal, wenn ich Leute Claude Code in den Himmel loben sehe, kann ich das Gefühl nicht abschütteln, dass das entweder alles Influencer sind oder Fans, die auf Terminal und traditionelle Tools wie Emacs oder Vim abfahren. Immer wenn ich Kommentare lese, Claude Code sei viel besser als Cursor, abonniere ich es tatsächlich und probiere es auf einer großen TypeScript-Codebasis aus, aber der Prozess dauert ewig und die Lernkurve ist hoch. Das Ergebnis ist am Ende dasselbe wie mit dem eingebauten Claude in Cursor, nur langsamer und unklarer, sodass auch der Code-Review schwerer wird. Inzwischen fühlt es sich einfach so an, als würden die enthusiastischen Kommentatoren entweder gesponsert oder wollten ihre Entscheidung rechtfertigen, nachdem sie schon 200 Dollar bezahlt haben. Ehrlich gesagt war Cursor für meine Produktivität deutlich besser. Ich programmiere seit 18 Jahren professionell und schreibe täglich viel Code, nutze Gemini 2.5 Pro und Claude 4.0 abwechselnd, aber mit Cursor hole ich mehr heraus. Bisher hat mich noch niemand überzeugt. Ich sehe keinen praktischen Vorteil. Vielleicht denke ich später anders darüber, aber im Moment spüre ich davon gar nichts
Ich glaube, die meisten Leute missverstehen grundlegend, worin der wirklich schwierige Teil der Softwareentwicklung besteht. Der Großteil der echten Arbeit ist nicht die Entwicklung komplexer Algorithmen, sondern das geschickte Zusammensetzen und Anpassen bestehender Ideen. Aber all das kommt erst nach der Vorarbeit wie Spezifikation, Design und Architektur. Mit AI solche Programme schnell aus dem Boden zu stampfen sieht cool aus und in Demos wirkt es, als wäre alles rasch „fertig“, aber das eigentliche Problem ist, ein System so zu bauen, dass es 30 Jahre lang nutzbar bleibt und die Qualitätsstandards erfüllt. Für Prototypen oder einmalige Zwecke ist es großartig, aber für langfristige Haltbarkeit hat es klare Grenzen
Um mit solchen Tools die Produktivität zu maximieren, sind sehr kurze und schnelle Feedback-Loops entscheidend. Das Tab-Autocomplete-Modell von Cursor versteht intuitiv, was der Editor gerade tun will, und fühlt sich an, als würde ein absurd intelligenter Gang runterschalten. Ich muss mir nicht den Kopf über Makro-Programmierung zerbrechen; wenn ich etwas nicht will, drücke ich einfach Esc zum Abbrechen, ansonsten kann ich schrittweise in einen agentischen Modus übergehen. Vollständig agent-basierte Editoren brauchen 15 bis 30 Minuten und reißen den Workflow komplett auseinander. Das Review der Ergebnisse ist selbst Arbeit und erfordert viel mehr Aufmerksamkeit als kurze Schleifen aus Annehmen oder Ablehnen. Dazu kommt noch die Frage, ob man Netzwerkrechte gibt oder das Ganze offline laufen lässt; deshalb lohnt sich so etwas für mich nur, wenn ich schnell irgendeinen Code erzeugen muss, bei dem Wartbarkeit, Sicherheit und Zuverlässigkeit keine große Rolle spielen. Ansonsten sinkt meine Produktivität eher. Das wird sich künftig wohl verbessern, aber aktuell bekomme ich mit Cursor klar bessere Resultate
Ich habe früher auch so gedacht, aber nachdem ich Claude Code kürzlich tatsächlich benutzt habe, finde ich es viel besser als Cursor. Ich weiß nicht genau warum, aber Claude scheint die Gesamtstruktur besser zu erfassen und unnötige Änderungen besser zu vermeiden. Natürlich muss man manchmal selbst die Richtung vorgeben, aber die Effizienz ist deutlich höher. Ein Merkmal ist auch, dass normalerweise immer nur genau eine Datei auf einmal gezeigt wird, wodurch Reviews viel leichter werden. Cursor öffnet oft mehrere Dateien gleichzeitig, und der Umfang der Änderungen ist groß, sodass man sie schwer schnell erfassen kann. Zur Einordnung: Ich nutze die Claude-Code-Erweiterung im VSCode-Terminalfenster. Claude öffnet die Tabs der Dateien, die es ändern will, und schlägt die Änderungen vor
Was viele noch nicht verstehen: Cursor ist kein einzelnes fertiges Produkt, sondern eher ein Bündel an Funktionen, die alle anderen Tools hastig nachrüsten wollen. Die eigentliche Lehre ist, dass es neben Deep Interfaces auch eine Strategie gibt, die besten Agent-Lösungen mit dem jeweils bevorzugten Editor zu kombinieren. Diese Erfahrungen werden sich am Ende zu „Best Practices“ verdichten, die Leute ganz natürlich in ihrem eigenen Editor oder ihrer IDE anwenden, und all diese vscode-Forks werden dann verschwinden
Ich habe es weniger als einen Monat lang im 17-Dollar-Tarif genutzt und bin halb fasziniert, halb frustriert. Ich habe 8.000 Zeilen in Rust und 12.000 Zeilen in Markdown geschrieben und Arbeitsbeschreibung und konkrete Tasks in einer Art Test-Harness voneinander getrennt, um mit der künstlichen Intelligenz zu interagieren. Ob die Magie von VC-Subventionen kommt oder von etwas anderem, weiß ich nicht, aber Rust fühlte sich dadurch fast wie eine Skriptsprache an. (Zur Referenz: Das GitHub-Repository heißt „knowseams“)
Das Beste an AI ist für mich, dass ich einfach sagen kann „mach das hier“, wenn ich keine Lust habe. Ob das Ergebnis gut ist oder nicht, ist erstmal egal. Es gibt mir zumindest einen Startpunkt
Dank LLMs habe ich keine Angst mehr vor dem leeren Blatt. Ich muss komplexen Kontext nicht erst wieder im Kopf rekonstruieren, sondern kann einfach fragen: „Woran haben wir gerade gearbeitet?“ oder „Was war dieser Code noch mal?“, und die AI erklärt es mir sofort, sodass ich direkt wieder eintauchen kann. Sogar Rubber-Duck-Debugging und wiederkehrende Kleinarbeit (yak shaving) erledigt sie extrem schnell, was wirklich nützlich ist. Ich nutze das auch zusammen mit Slack, Notion, Linear usw., also ist es für mich zugleich ein Task-/Projektmanagement-Tool
Selbst wenn ich etwas lieber selbst machen möchte, lasse ich mir von der AI einen Plan erstellen und halte ihn in Markdown fest. Heute habe ich mir zum Beispiel einen Refactor-Plan geben lassen, aber der ging falsch an einen Prototyp-Codeblock mit 40 Dateien heran, indem er die Struktur von unten nach oben umbauen wollte. Wenn ich diesen Fehler übernommen hätte, hätte mich das beim Debugging enorm viel Zeit gekostet. Trotzdem hat es einen Angriffspunkt geliefert, und ich konnte den Plan innerhalb einer Stunde korrigieren und anwenden. Allein hätte ich vermutlich wegen der Komplexität gar nicht angefangen oder irgendwann beim wiederholten Dokumentieren aufgegeben
Am Ende des Tages, wenn ich mich nicht mehr konzentrieren kann und sich Schreiben und Zurückrollen ungefähr die Waage halten, kann ich die AI ans Steuer lassen und erst einmal durchatmen. Bei kleinen Issues reicht ein kurzer Blick auf den Diff, und bei schwierigen Themen kann ich die AI gezielt lenken und überzeugen, sobald ich konkret weiß, was das Problem ist. Wenn etwa 40 bis 60 % der Arbeit erledigt sind, übernehme ich meist wieder selbst und bringe es zu Ende. Normalerweise konzentriere ich mich in meinen scharfen Stunden aufs eigene Denken und Entwickeln; Überstundenreste oder monotone Fleißarbeit gebe ich an die AI ab und nutze die Zeit eher für die Vorbereitung des nächsten Tages oder für höherwertiges Schreiben und Design
Ich gehe einfach spazieren und trinke einen Kaffee. Menschliche Probleme auf menschliche Weise zu lösen fühlt sich irgendwie natürlicher an
Claude Code ist schwer in Worte zu fassen. Seit ich es benutzt habe, fühlt es sich fast so an, als hätte ich den Beruf gewechselt. Ich hatte Claude schon vorher tief in meinen Workflow integriert, aber Claude Code ist wirklich wie „auf Steroiden“. Wenn man es noch nicht ausprobiert hat, kann ich es nur empfehlen. Zum ersten Mal hatte ich wirklich das Gefühl, mit einem Junior Engineer zusammenzuarbeiten
Meine Erfahrung ist das genaue Gegenteil. Ich gebe etwas vor, und nach ein paar Minuten kommt irgendein Ergebnis zurück, aber in Wirklichkeit ist die App dann kaputt, und beim Debuggen stellt sich heraus, dass komplett am Thema vorbeigearbeitet wurde und ich am Ende alles wegwerfe. Trotzdem bleibe ich an Claude dran, weil es, wenn es wie bei anderen gut läuft, eben fantastisch wirkt. In der Realität produziert es meist Boilerplate, ich muss ziemlich viel selbst debuggen, und im schlimmsten Fall verliere ich nur eine Stunde und Tokens
Ich habe es heute zum ersten Mal bei der Arbeit genutzt, und im Vergleich zu Cursor ist es eine überwältigend innovative Veränderung. Obwohl dasselbe Foundation Model darunterliegt, ist es ein völlig anderes Erlebnis. Vor einem Monat hat mich AI eher ausgebremst, aber heute war ich mit Claude Code in 20 Minuten fertig, und die API-Kosten lagen unter 10 Dollar. Ich musste mich kaum um Context-Management kümmern, und Claude Code holt sich den nötigen Kontext selbst, sodass es viel länger produktiv arbeiten kann. Der Agent-Modus von Cursor ist für 3- bis 5-Minuten-Aufgaben brauchbar, aber Claude Code verliert auch bei Aufgaben von über 10 Minuten nicht den Faden und macht stetig Fortschritte. Die Tool-Nutzung ist hervorragend, und es ist erstaunlich, wie selten es in Schleifen hängen bleibt
Du hast gesagt, es sei „wie die Zusammenarbeit mit einem Junior Engineer“, aber für mich fühlt es sich eher so an, als wäre ich der Untergebene und Claude mein Vorgesetzter. Wenn ich stolz sage: „Ich habe dieses coole Ding gebaut!“, ist die Reaktion eher: „Aber das habe ich dir doch gar nicht aufgetragen …“
Kannst du konkreter sagen, bei welchen Aufgaben, Sprachen und Domänen du es eingesetzt hast? Die Fälle unterscheiden sich alle so stark, dass mich das wirklich interessiert
Ich habe dieselbe Erfahrung gemacht. Claude ist mehr als nur ein einfacher Junior. Es ist großartig darin, Optionen vorzuschlagen, Empfehlungen für Entscheidungen zu geben und Trade-offs sichtbar zu machen
Gibt es nicht mehr Walkthrough-Beispiele, in denen tatsächlich Apps oder Libraries mit Claude Code gebaut werden? Mich interessieren echte Entwicklungsabläufe mit diesem Tool mehr als bloße „wow“-Berichte. Eine Sammlung solcher Beispiele wäre wirklich großartig
Irgendwie fühlt sich die ganze Situation insgesamt etwas seltsam an. Claude Code selbst ist eindeutig gut, und man kann es nutzen, um Dokumentation oder Stack Overflow viel schneller zu finden. Aber wenn die übertriebenen Gerüchte stimmen würden, müsste es dann nicht längst zu massiven Software-Innovationen in irrsinnigem Tempo kommen? Der Stripe-CEO sagte, AI-Tools hätten die Produktivität um das Hundertfache gesteigert; wenn das schon seit 3 bis 4 Monaten so wäre, müsste Stripe dann nicht inzwischen Raketen starten? Und wenn Microsoft voll auf AI-Coding setzt, warum wirkt Teams dann immer noch so mittelmäßig? Seit über einem Jahr heißt es, diese Tools seien revolutionär, aber die Realität fühlt sich nicht viel anders an als vor 3 oder 4 Jahren
Zwei auffällige Trends der letzten Zeit sind: (1) Ungeübte nutzen AI für kleine Nebenprojekte, und (2) Entwickler spezifizieren im Voraus dicht und detailliert die gesamte App-Struktur, Dateien, Interfaces, den Tech-Stack und das Test-Framework und versuchen dann, dem LLM per Feinsteuerung ein halbwegs brauchbares Ergebnis abzuringen YouTube-Beispiel. Die 80 bis 99 %, von denen man in PR oder auf YouTube hört, kommen faktisch aus der ersten Gruppe. Das Gefühl von Produktivitätssteigerung entsteht, weil es weniger anstrengend wirkt, mit dem LLM zu reden, zu dokumentieren, zu lenken und zu korrigieren, als direkt selbst zu entwickeln. Selbst wenn Zeitaufwand und Gesamtarbeit gleich bleiben, sinkt die mentale Hürde
Ich suche auf YouTube nach Livestreams oder Fallstudien, die einen echten Produktivitätsschub zeigen, aber ich habe noch keinen Fall gesehen, bei dem ich dachte: „Wow, das ist wirklich schnell!“
Es gibt viele extreme Meinungen pro und contra, aber die meisten committen in Wahrheit einfach still vor sich hin, was an sich schon ironisch ist. In meinem Fall fühle ich je nach Aufgabe tatsächlich eine Beschleunigung um das 1,5- bis 10-Fache. Der größte Vorteil ist, dass die kognitive Last bei rein kreativen, einmaligen, boilerplate-lastigen oder refactoringartigen Arbeiten deutlich sinkt und ich dadurch konsistentere Ergebnisse erreiche. Ich „tippe von Hand“ immer noch viel und reviewe fast jede Zeile bis zum Ende. Es stundenlang allein laufen zu lassen, ist ein Nightmare. Gleichzeitig arbeite ich in einer sehr schlanken Organisation und habe den Kontext des gesamten Systems im Kopf, wodurch ich Probleme schneller erfassen kann. In Umgebungen, in denen persönliche Hebelwirkung entscheidend ist, stärkt das die Grundlagen massiv. In großen Organisationen ist so eine Erfahrung schwerer zu machen
Nach meiner Erfahrung hilft es, in jedem Root eines Code-Ordners eine Markdown-Datei namens Claude.md abzulegen und dort eine minimale Art Regelwerk wie in einer Pipeline zu ergänzen. Damit wird festgelegt, dass Tests genau in den vorgesehenen Ordnern und nach den vorgesehenen Mustern erzeugt und abgelegt werden, dass keine Debug-Dateien erstellt werden und dass neue Klassen oder Strukturen nicht unnötig ausufern, sondern nach Möglichkeit bestehende Dinge wiederverwendet werden. Ich schreibe auch keine langen Prompts; meistens lasse ich nur für unsichere Punkte einen Plan erstellen. Selbst bei ganz neuen Problemen außerhalb des Wissensbereichs des LLM halte ich die zusätzlichen Eingaben minimal. Auf diese Weise bekomme ich konsistent Ergebnisse im Stil von 1 input–1 output, auch in der Tiefe. In letzter Zeit bin ich statt Claude Code auf den CLI-Modus umgestiegen und nutze dort andere große Modelle wie Opus günstiger. Das CLI ist die eigentliche Macht. Ich lasse 60 bis 70 Agent-Streams gleichzeitig laufen und verwalte problemlos eine Codebasis im Umfang von 200 Millionen Tokens (react/typescript/golang). Zusätzliche Anweisungen musste ich nur ein- oder zweimal geben
Kannst du auflisten, was du mit den Agent-Streams konkret betreibst? Das interessiert mich sehr
Mich würde interessieren, welche Modelle du außer Anthropic nutzt. Kimi K2 habe ich ausprobiert, aber für meinen Anwendungsfall war es nicht besonders gut
Mich würde interessieren, was genau mit „Agent-Streams“ gemeint ist. Wie verwaltest du 60 bis 70 davon? Die kognitive Last ist für mich kaum vorstellbar
Manchmal steigt meine Produktivität mit Claude Code bei bestimmten Aufgaben dramatisch. Ich empfehle, Slash-Commands zu nutzen und frühere Unterhaltungen in Slash-Commands umzuwandeln. So baut man sich nach und nach einen immer nützlicheren Satz primitiver Befehle auf. Meine Beispiele habe ich auf GitHub veröffentlicht: make-command.md, improve-command.md
PSA: Mit diesem Repository kann man Claude Code mit praktisch jedem Modell verbinden. Es heißt, das aktuelle Kimi-K2 funktioniere ziemlich gut
Ich habe Kimi-K2 auch ausprobiert; es liegt leistungsmäßig unter Sonnet/Opus 4.0, ist beim Tool Calling aber besser als Gemini 2.5 Pro. Wenn Claude Max (100–200 Dollar pro Monat) zu teuer ist, kann ich es sehr empfehlen. Das Modell selbst ist angenehm schlank und simpel. Anthropic sollte Claude Code eigentlich einfach Open Source machen; dann könnte es das VSCode der CLI-Coding-Agents werden. Und opencode kann ich ebenfalls empfehlen. Es unterstützt alle Modelle nativ und bietet ähnliche Funktionen wie Claude Code
Wenn du sowieso mehrere Modelle einsetzen willst, würde ich einfach sst/opencode empfehlen (ich selbst nutze es auch mit Claude Pro)
Zur Info für alle, die CC noch nicht ausprobiert haben – den CC-Client kann man per npm beziehen und kostenlos nutzen
Ich habe mit Claude Code, einem lokalen LLM, Continue und VSCode ein einfaches Python-App-Projekt als „vibe coding“ ausprobiert und dann vom kostenlosen Claude-Tier erfahren, woraufhin ich den laufenden Code und die LLM-Ausgaben dort hineingegeben habe. Claude hat Fehler und Updates auf Anhieb sauber sortiert und korrigiert, was super war. Als nächsten Schritt habe ich dann mit ChatGPT die Spezifikation und Prompts für ein pygame-basiertes 2D-Spielprojekt im Stil von Manic Miner erstellt und in Claude eingegeben. Aber Claude verweist ständig auf Methoden, die gar nicht existieren, oder erzählt Unsinn über Versionsunterschiede in der Codebasis. Selbst wenn ich mit Zeilennummern und umgebendem Code sehr präzise werde, betreibt es weiter Gaslighting. Wie würdet ihr das lösen? Perfektion erwarte ich nicht, aber ich stoße gefühlt an ähnliche Grenzen wie bei lokalen LLMs. Wegen gesundheitlicher Probleme arbeite ich nur sporadisch daran, deshalb wäre ich für Tipps dankbar
Wahrscheinlich bist du in einer „Code-Hölle voller vager Interfaces und versteckter Annahmen“ gelandet. In so einem Fall ist es oft besser, alle bisherigen ChatGPT-Ergebnisse erst einmal zusammenzufassen, tiefgehend aufzulisten, was das aktuelle Spiel bereits tut und welche Funktionen es insgesamt hat, und dieses Dokument dann Claude zu geben, damit es die Anforderungen von Grund auf neu aufteilt. Claude kann auch zero-shot hervorragende Beispiele liefern, und im schlimmsten Fall kann es sich iterativ selbst verbessern. Wenn Claude trotzdem weiterhin absurde Features erfindet, würde ich empfehlen, den context7-MCP-Server zu installieren und Claude ausdrücklich anzuweisen, context7 zu verwenden
Das ist eine grundlegende Grenze der LLM-Technologie. Sie gibt probabilistisch die „plausibelste“ Token-Sequenz aus, aber wenn „plausibel“ und „korrekt“ nicht zusammenfallen, gibt es keinen Ausweg. Jedes LLM hat dabei je nach Training und Fine-Tuning einen anderen Maßstab dafür, was „plausibel“ ist
Mich würde interessieren, welche zusätzlichen Methoden ihr nach der Basiskonfiguration einsetzt, damit dieses Tool zuverlässig gut funktioniert. Also welche praktischen Vorgehensweisen bei Kontext und Codebasis-Aufbau dem Tool helfen, selbstständig die richtige Richtung zu finden. Ich habe meine bisherigen Gedanken dazu in diesem Beitrag gesammelt. Ich denke, es werden noch bessere Methoden entstehen
Ich bekomme mit Claude Code mehrere Alpha-Vorteile, aber ich frage mich, wie man das auf ein ganzes Team skaliert. Mich würde interessieren, ob es praktische Tipps oder Best Practices gibt, wie man Teammitglieder oder Leute, die man führt, dabei unterstützt, Claude Code effektiv zu nutzen