"7 Claude Code + Opus 4.7 Tipps von Boris Cherny"

"## 7 Claude Code + Opus 4.7 Tipps von Boris Cherny\n\nIch war mitten im Aufbau eines Linear-Klons, als Boris Chernys neues Video mit sieben Tipps in meinem Feed auftauchte — und ich hätte es fast ignoriert.\n\nMeine Ausrede klang vernünftig. Ich nutze Claude Code seit über einem Jahr täglich. Ich habe mehr als achtzig Beiträge darüber auf diesem Blog geschrieben. Ich habe jedes Effort-Level, jeden Modellwechsel und jedes Plugin getestet, das mir über den Terminal lief. Was könnte der Mann, der Claude Code gebaut hat, mir erzählen, was ich nicht schon selbst herausgefunden hätte?\n\nDann sagte er einen Satz, der mich aufhorchen ließ: „Bei Opus 4.7 fasse ich den Extended-Thinking-Toggle nicht mehr an. Er ist weg." Ich hielt das Video an, öffnete meine API-Konsole und bestätigte es. Er hatte recht. Der Parameter thinking: {type: \"enabled\", budget_tokens: N}, den ich monatelang feinabgestimmt hatte, liefert auf Opus 4.7 jetzt einen 400-Fehler. Anthropic hat ihn still und leise entfernt. Adaptive thinking ist jetzt der einzige Denk-Modus, und man steuert ihn mit der Formulierung des Prompts — nicht mit einem Toggle.\n\nDas war ein einziger Satz. Das Video hatte sieben Tipps. Wenn ich bei einem davon schon so falsch lag, schuldete ich den anderen sechs eindeutig ein faires Hearing.\n\nAlso verbrachte ich die nächsten vier Tage damit, meinen Linear-Klon von Grund auf neu zu bauen und jede Technik von Boris gegen echte Arbeit zu testen — keine Spielzeug-Prompts, keine Demo-Skripte. Projekte, Aufgaben, Status, Priorität, Zuweisungen, ein Next.js UI. Dieselbe Spezifikation, die er demonstriert hatte. Und ich hielt fest, was sich änderte, was nicht, und welche Tipps ich dauerhaft behalte — und welche ich stillschweigend wieder weglasse.\n\nHier ist, was ich gelernt habe. Alle sieben Tipps. Die Dinge, die ich falsch gemacht hatte. Und die genaue Formulierung, die Opus 4.7 zum Funktionieren brachte.\n\n## Kurze Anmerkung zur Quelle: Es ist wirklich Boris Cherny\n\nBevor wir loslegen — die Transkripte dieses Vortrags, die im Umlauf sind, nennen ihn „Churnney" und „Cherny" und einige Schreibweisen dazwischen. Die Person, die Claude Code erschaffen hat, ist Boris Cherny, ehemaliger Meta-Ingenieur und jetzt Head of Claude Code bei Anthropic. Er kam 2024 zu Anthropic, lieferte Claude Code als Nebenprojekt in seinem ersten Monat aus, und das Produkt überschritt Anfang 2026 einen Jahresumsatz von 1 Milliarde Dollar. Wenn er darüber spricht, wie man dieses Tool nutzt, lohnt es sich, genau zuzuhören — denn er ist auch derjenige, der entscheidet, was als Nächstes ausgeliefert wird.\n\nNoch eine Quellenkorrektur: Das zweite Tool, das er im Vortrag mit Claude Code vergleicht, ist OpenCode — nicht „OpenClaw", wie ich es zunächst im Transkript gehört hatte. OpenCode ist der Open-Source-Terminal-Agent, der an über 75 LLM-Anbieter weiterleitet. Diesen Namen sollte man kennen; wir kommen noch darauf zurück.\n\nJetzt — die sieben Tipps, nachgetestet.\n\n## Tipp 1: Auto Mode ist jetzt der Standard. Hör auf, gegen den Permission-Cycle zu kämpfen.\n\nIch gebe es zu — ich war die meiste Zeit des Jahres 2025 ein „plan mode → acceptEdits → manuell genehmigen"-Typ. Die Vorstellung, Claude Code Bash-Befehle ausführen zu lassen, ohne jeden einzelnen im Blick zu haben, fühlte sich rücksichtslos an. Wie jemandem die Schlüssel zur Produktion zu geben, während der Motor läuft.\n\nAuto mode hat diese Zurückhaltung bei mir beseitigt.\n\nHier ist die eigentliche Mechanik. Claude Code hat vier Permission-Modi, die man mit Shift+Tab durchläuft: default → acceptEdits → plan → auto. Der auto mode-Slot erscheint im Zyklus nur, wenn dein Account qualifiziert ist und du ihn aktiviert hast. Auf einem Max- oder Team-Plan schaltet claude --enable-auto-mode ihn ein, und von da an landet ein dritter Shift+Tab-Druck in auto.\n\nWas auto mode von acceptEdits unterscheidet, ist nicht die Oberfläche — es ist der Classifier. Bevor jeder Tool-Aufruf ausgelöst wird, prüft ein separates Sicherheitsmodell auf Basis von Sonnet 4.6 die Aktion. Wenn es nach massenhafter Dateilöschung, Datenexfiltration oder prompt-injection-gesteuerter Eskalation riecht, wird es blockiert. Alles andere läuft durch. Anthropic hat diesen Modus am 24. März 2026 gestartet, speziell um die Art von Permission-Fatigue zu bewältigen, die die meisten Power-User mit benutzerdefinierten Allowlists umgangen hatten.\n\nAls ich Boris' Linear-Klon-Build im auto mode nachtestete, lag der Unterschied nicht in der Codequalität — sondern in meiner Aufmerksamkeit. Ich schaute nicht auf das Terminal. Ich war in der Claude-Desktop-App und verfasste den UI-Copy für die Aufgabenseite, während Claude Code das Prisma-Schema verdrahtete, Migrationen ausführte, Testdaten befüllte und den Dev-Server startete. Dreiundzwanzig Tool-Aufrufe geschahen ohne eine einzige Permission-Abfrage. Keiner davon brauchte mich.\n\nDer eine Punkt, bei dem ich Boris' Formulierung etwas widersprechen würde: auto mode ist nicht der richtige Standard für jedes Projekt. Wenn ich ein Produktions-Repository eines Kunden anfasse oder irgendetwas, wo ein versehentliches rm -rf Geld kosten würde, bleibe ich bei acceptEdits. Der Classifier ist gut — aber „gut" bedeutet auf dieser Ebene noch gelegentliche Fehlentscheidungen. Für Greenfield-Builds, für meine eigenen Nebenprojekte, für alles, wo ein git reset günstig ist — auto mode ist jetzt mein Zuhause.\n\nWenn du die letzten sechs Monate zwischen default und plan hin- und hergeshiftet hast, ist das die Gewohnheit, die es zu brechen gilt. Ein Druck mehr, und du bist in einem Modus, der für Flow entwickelt wurde.\n\n## Tipp 2: Die gesamte Spezifikation von Anfang an. Opus 4.7 belohnt dich dafür.\n\nDas ist der Tipp, der meine Ausgabequalität am meisten verbessert hat — und der, gegen den ich am aktivsten angekämpft habe.\n\nMeine Gewohnheit — und wahrscheinlich auch deine — war inkrementelles Prompting. Erst das Datenbankschema. Dann die API-Routen. Dann die UI. Dann alles verbinden. Bei jedem Schritt prüfte ich die Ausgabe, optimierte und gab die nächste Anweisung. Es fühlte sich wie Kontrolle an. Es fühlte sich verantwortungsbewusst an.\n\nEs war keines von beidem. Es war eine Gewohnheit, die aus der GPT-4-Ära stammt, als Modelle keine große Spezifikation im Kopf behalten konnten.\n\nBoris' Demo war eine direkte Widerlegung. Er öffnete Claude Code und übergab Opus 4.7 in etwa folgendes als einzigen Prompt:\n\n> Baue einen Linear-Klon. Projekte enthalten Aufgaben. Jede Aufgabe hat einen Status (todo, in-progress, done), eine Priorität (low, medium, high, urgent), einen Zugewiesenen (aus einer Users-Tabelle) und Tag-Unterstützung. Verwende Next.js App Router, Prisma mit SQLite für lokale Entwicklung, Tailwind für Styling und shadcn/ui-Komponenten. Die UI soll eine Projekt-Seitenleiste, eine Task-Board-Ansicht und ein Task-Detail-Modal haben. Stell keine Fragen — triff vernünftige Standardentscheidungen und liefere es aus.\n\nSechs Minuten später hatte er einen funktionierenden Linear-Klon. Kein Skelett. Eine laufende App auf localhost, mit Seed-Daten, einem funktionalen Kanban-Board und einem Task-Detail-Modal, das sauber öffnete.\n\nAls ich es bei meinem Nachtest versuchte, war ich skeptisch. Mein erster Versuch dauerte etwa sieben anderthalb Minuten. Mein zweiter Versuch, mit einer knapperen Spezifikation, dauerte unter sechs. Beide Male war die Ausgabe wirklich nutzbar. Nicht perfekt — ich musste einen shadcn-Import-Pfad und eine Tailwind-Klasse korrigieren, die auf ein undefiniertes Farb-Token verwies — aber 85–90 % produktionsreif beim ersten Durchgang.\n\nDie Lektion, die Boris hier vermittelt, ist subtil. Opus 4.7's Kontextfenster, gepaart mit adaptivem Denken, bedeutet, dass es die gesamte Architektur im Blick behalten kann, während es einen einzelnen Teil baut. Wenn du inkrementell promptest, verbirgst du Informationen davor. Du zwingst es, bei jeder Nachricht den Kontext neu aufzubauen. Schlimmer noch, du signalisierst, dass die Teile unabhängig sind — was bedeutet, dass es sie so baut, als wären sie es — und die Integrationsphase wird zu ihrem eigenen Chaos.\n\nFrontloading bedeutet: schreibe die vollständige Spezifikation, bevor du Enter drückst. Schließe das UI-Framework ein. Schließe das Datenmodell ein. Schließe ein, was es nicht tun soll. Schließe die ästhetische Richtung ein. Jeder Kontext, den du vorab lieferst, ist ein Stück, das Claude nicht raten muss.\n\nMeine Faustregel jetzt: Wenn mein erster Prompt unter 150 Wörter hat, habe ich nicht genug über das nachgedacht, was ich anfrage.\n\n## Tipp 3: Claude Code vs. OpenCode — Nutze das richtige Tool für die Aufgabe\n\nDas ist der Tipp, bei dem Boris überraschend ehrlich ist — für jemanden, dessen Job es ist, Claude Code zu verkaufen.\n\nEr sagt nicht „Verwende Claude Code für alles." Er zieht eine Linie. Claude Code ist in seiner Formulierung für tiefe, komplexe, consumer-grade Arbeit — die Art von Build, bei dem dir wichtig ist, dass die Ausgabe produktionsreif ist, wo Architekturentscheidungen eine Rolle spielen, wo du möchtest, dass ein Senior-Ingenieur die Entscheidungen getroffen hat. OpenCode ist für schnelle Prototypen und leichtgewichtiges Agenten-Tooling, wo die Iterationsgeschwindigkeit mehr zählt als die Qualität der Ausgabe.\n\nIch nutze beide seit ein paar Monaten, und seine Einschätzung trifft zu.\n\nOpenCode — der Open-Source-Terminal-Agent, nicht Codex, nicht das OpenAI-Ding — hat einen echten Vorteil beim Prototyping. Es leitet an über 75 LLM-Anbieter weiter, also kann ich für schnelle Iteration einen Wegwerf-Agenten auf einem günstigen Modell starten und pro Token zahlen, anstatt mich auf ein Abonnement festzulegen. Wenn ich ein einmaliges CLI-Tool baue, das ich eine Woche benutze und wegwerfe, erreicht OpenCode schneller einen funktionierenden Zustand, weil mir die Codequalität von etwas, das ich nie warten werde, egal ist.\n\nClaude Code ist der gegenteilige Trade-off. Es ist qualitätsorientiert. Es ist auf Anthropics Modelle abgestimmt, was bedeutet, dass es Opus 4.7's beste Ausgabe standardmäßig liefert. Es hat das tiefere Plugin-Ökosystem, das ausgereifte Hooks-System und das Skills-Framework, auf das ich täglich angewiesen bin. Wenn ich etwas baue, das ich sechs Monate lang pflegen werde, ist diese Meinungsstärke ein Feature.\n\nDer Tipp im Tipp: Hör auf, den einen wahren Agenten zu suchen. Du willst zwei. Einen für „Ich brauche das bis zum Abendessen fertig und es ist mir egal, ob der Code hässlich ist." Einen für „Ich werde diese App um 2 Uhr morgens in sechs Monaten debuggen, und die Architekturentscheidungen, die ich heute treffe, werden mich heimsuchen." Passe das Tool an die Aufgabe an.\n\n## Tipp 4: /recap — Der Befehl, von dem du nicht wusstest, dass du ihn brauchst\n\nDiesen hatte ich tatsächlich verpasst. Irgendwie. Er wird seit April 2026 ausgeliefert, steht in der Dokumentation, und ich hatte ihn noch nie eingegeben.\n\n/recap ist ein Slash-Befehl, der eine einzeilige Zusammenfassung aller Aktionen deiner aktuellen Claude Code-Sitzung ausgibt. Welche Dateien wurden berührt. Welche Befehle liefen. Welche Tests bestanden oder fehlschlugen. Er ist über /config konfigurierbar, und es gibt eine CLAUDE_CODE_ENABLE_AWAY_SUMMARY-Umgebungsvariable, die steuert, ob er automatisch auslöst, wenn du zu einer veralteten Sitzung zurückkehrst.\n\nDer Grund, warum er wichtig ist, liegt nicht im Feature selbst — sondern in dem Workflow, den er freischaltet.\n\nIch habe eine Gewohnheit, die ich bei vielen teile. Ich starte eine lange Claude Code-Sitzung, gehe weg, komme vierzig Minuten später mit einem kalten Kaffee zurück und muss drei bis vier Minuten den Scrollback lesen, um herauszufinden, wo wir waren. Was hatte Claude abgeschlossen? Was war noch kaputt? Lief die Migration wirklich? Welche Testdatei schlug fehl?\n\n/recap beantwortet all das in etwa zwei Sekunden. Eine Zeile pro Aktion. Ich scanne es, weiß, wo wir sind, und formuliere den nächsten Schritt.\n\nDer andere Ort, an dem es mich diese Woche rettete: Ich jonglierte mit drei parallelen Claude Code-Sitzungen (eine Gewohnheit, die Boris selbst an einem normalen Tag mit 5–10 parallelen Instanzen betreibt). Das Kontextwechseln zwischen ihnen zerstörte meinen Flow. /recap in jedem Fenster wurde mein Äquivalent zum Aufgehen zu einem Whiteboard, um mich neu zu orientieren. Unter zehn Sekunden, um zu wissen, was eine Sitzung getan hatte.\n\nWenn du es noch nicht eingegeben hast, probiere es beim nächsten Mal aus, wenn du zu einer laufenden Sitzung zurückkehrst. Das erste Mal fühlt sich an, als hättest du ein Feature gefunden, das es nicht geben sollte.\n\n## Tipp 5: Effort-Level — Extra High und Max sind real, und sie sind verschiedene Tools\n\nHier muss ich einen Fehler korrigieren, den ich in meinem eigenen Kopf vor diesem Nachtest gemacht hatte.\n\nIch hatte angenommen, „max effort" und „extra high effort" seien Marketing-Unterscheidungen. Das sind sie nicht. Es sind echte verschiedene Modi mit unterschiedlichen Trade-offs, und Boris' Formulierung hat es mir klargemacht.\n\nClaude Code hat fünf Effort-Level: low, medium, high, xhigh (extra high) und max. Bei Opus 4.7 ist der Standard xhigh für alle Pläne und Anbieter — obwohl Anthropic den Standard im März 2026 stillschweigend von high auf medium für Pro- und Max-Abonnements gesenkt hat, was es wert ist zu wissen, falls deine Ausgabe sich in diesem Frühling etwas dünner angefühlt hat als früher.\n\nDer Unterschied zwischen xhigh und max ist wichtig. xhigh bleibt sitzungsübergreifend erhalten. Es ist das Level, das man dauerhaft einstellen und vergessen kann. max bleibt nicht erhalten — es ist ein Nur-aktuelle-Sitzung-Modus, es sei denn, du pinst ihn mit der CLAUDE_CODE_EFFORT_LEVEL-Umgebungsvariable. Max entfernt alle Token-Beschränkungen beim Denken. Es gibt keine Obergrenze. Claude wird so viel ausgeben, wie die Aufgabe zu benötigen scheint.\n\nBoris' Regel, die fast genau mit meinem Nachtest übereinstimmt:\n\n- Low / Medium: triviale Arbeit. Einzel-Datei-Bearbeitungen. Kleine Refactorings. Pläne, bei denen du zuversichtlich bist, dass sie korrekt sind.\n- High: Standard-Feature-Arbeit, bei der du solides Denken ohne hohe Kosten möchtest.\n- Extra High (xhigh): Feature-Arbeit, bei der die Architektur wichtig ist oder Claude's erster Instinkt oft subtil falsch ist.\n- Max: große, frontgeladene Prompts. Mein Linear-Klon-Build. Full-System-Migrationen. Die Art von Aufgabe, bei der du Opus 4.7 eine Spezifikation übergibst und eine nahezu vollständige Ausgabe erwartest.\n\nFür den Linear-Klon-Nachtest führte ich drei Versionen aus. Eine bei high, eine bei xhigh, eine bei max. High produzierte eine funktionierende App mit drei offensichtlichen Bugs. Xhigh produzierte eine funktionierende App mit einem kosmetischen Problem. Max produzierte eine funktionierende App mit null Problemen beim ersten Durchgang, dauerte aber etwa 40 % länger und verbrauchte ungefähr 3x die Token.\n\nDie Kostenkurve ist real. Führe nicht alles auf max aus. Aber fürchte es nicht für Aufgaben, die es rechtfertigen — ein frontgeladener Build-Prompt ist genau diese Art von Aufgabe.\n\nWenn du lieber jemanden für diese Art von architektur-first-Build engagieren möchtest — ob es sich um ein Linear-ähnliches internes Tool, einen SaaS-Prototyp oder ein KI-integriertes Produkt handelt — nehme ich benutzerdefinierte Builds über fiverr.com/s/EgxYmWD an. Aber du kannst das definitiv selbst mit dem Workflow in diesem Beitrag schaffen.\n\n## Tipp 6: Benachrichtigungen — Hör auf, das Terminal zu überwachen\n\nDieser Tipp ist simpel und hat mehr von meinem Workflow verbessert, als er es hätte tun dürfen.\n\nBoris richtet Aufgaben-Abschluss-Benachrichtigungen ein, damit er lange Claude Code-Jobs laufen lassen kann, ohne auf das Terminal zu starren. Dann arbeitet er an etwas anderem — Brainstorming in der Claude-Desktop-App, Spezifikationen schreiben, Kaffee holen — bis sein Mac ihn anpingt, dass Claude entweder fertig ist oder eine Eingabe benötigt.\n\nDer Mechanismus ist ein Stop-Hook in Claude Code's Hooks-System. Stop-Hooks lösen aus, wenn Claude seine aktuelle Aufgabe abschließt. Du kannst jeden Shell-Befehl an sie anhängen — einschließlich osascript, um eine macOS-Benachrichtigung auszulösen, einen Slack-Webhook oder einen terminal-notifier-Aufruf. Es gibt auch einen Notification-Hook, der bei Permission-Prompts, Idle-Prompts oder Elicitation-Dialogen auslöst, was nützlich ist, wenn du in einem Modus bist, der noch um Genehmigungen fragt.\n\nHier ist das minimale ~/.claude/settings.json-Snippet, das ich verwende:\n\njson\n{\n \"hooks\": {\n \"Stop\": [\n {\n \"matcher\": \"\",\n \"hooks\": [\n {\n \"type\": \"command\",\n \"command\": \"osascript -e 'display notification \\\"Claude finished\\\" with title \\\"Claude Code\\\" sound name \\\"Glass\\\"'\"\n }\n ]\n }\n ],\n \"Notification\": [\n {\n \"matcher\": \"permission_prompt\",\n \"hooks\": [\n {\n \"type\": \"command\",\n \"command\": \"osascript -e 'display notification \\\"Needs your input\\\" with title \\\"Claude Code\\\" sound name \\\"Ping\\\"'\"\n }\n ]\n }\n ]\n }\n}\n\n\nZwei verschiedene Töne. Zwei verschiedene Zustände. Ich weiß, welcher welcher ist, ohne auf den Bildschirm zu schauen.\n\nDie asynchronen Hooks, die Anthropic im Januar 2026 ausgeliefert hat, sind hier ebenfalls wichtig — sie lassen Benachrichtigungsbefehle im Hintergrund laufen, ohne Claudes Ausführung zu blockieren, was bedeutet, keine merkwürdige Pause, wenn eine Benachrichtigung mitten in einer Aufgabe auslöst.\n\nDer Meta-Punkt, den Boris mit diesem Tipp macht, dreht sich nicht um die Benachrichtigung selbst. Es geht um die mentale Modellveränderung. Wenn du Claude Code in Echtzeit bei der Arbeit zuschaust, bist du der Engpass. Du machst nicht etwas anderes. Du denkst nicht voraus. Du bist Zuschauer bei deinem eigenen Job. Benachrichtigungen lassen dich vom Zuschauer zum Dirigenten werden — und ein Dirigent, der zwei oder drei Claude-Sitzungen parallel führt, ist eine wirklich andere Art von Entwickler als einer, der sich durch ein einzelnes Terminal in Echtzeit durchkämpft.\n\n### Der Workflow-Multiplikator: Brainstorming in der Claude-Desktop-App während Claude Code läuft\n\nBoris erwähnt das als Randnotiz im Video, aber es ist eines der hochwertigsten Stücke im gesamten Vortrag.\n\nWährend Claude Code einen langen Job ausführt, öffnet er die Claude-Desktop-App — ein völlig separates Produkt, nicht Claude Code — und nutzt sie als Brainstorming-Oberfläche. Keine Tool-Aufrufe. Keine Dateibearbeitungen. Nur ein Chat-Kontext, in dem er über das nächste Feature nachdenkt, Spezifikationssprache entwirft, Architekturentscheidungen überprüft.\n\nWenn sein Mac ihn anpingt, dass Claude Code fertig ist, hat er einen vollständig ausgearbeiteten nächsten Prompt bereit zum Abfeuern. Keine „Lass mich darüber nachdenken, was ich als Nächstes fragen soll"-Totzeit.\n\nIch kopierte dieses Muster für den Nachtest. Mein Linear-Klon-Build hatte drei natürliche Pausenpunkte. In jedem öffnete ich anstatt auf das Terminal zu starren die Desktop-App und entwarf die nächste Spezifikation. Die gesamte Wanduhrzeit für den Build sank von dem, was ein halbtägiges Projekt gewesen wäre, auf etwa eine Stunde und vierzig Minuten echter Arbeit.\n\n## Tipp 7: Adaptive Thinking — Der Toggle ist tot. Lang lebe der Prompt.\n\nDas ist der, bei dem ich falsch lag. Lass mich erklären, was sich tatsächlich geändert hat.\n\nBei Opus 4.6 und früher kontrolliertest du Extended Thinking mit einem expliziten Parameter: thinking: {\"type\": \"enabled\", \"budget_tokens\": N}. Du legst ein Token-Budget fest. Claude dachte bis zu diesem Budget. Unkompliziert.\n\nBei Opus 4.7 gibt dieser Parameter einen 400-Fehler zurück. Extended-Thinking-Budgets sind weg. Ersetzt durch adaptive thinking — einen Modus, in dem Claude selbst entscheidet, wann es tiefer nachdenken soll und wie viel es ausgeben soll, basierend auf der Komplexität jeder Anfrage.\n\nAdaptive thinking ist bei Opus 4.7 standardmäßig deaktiviert. Du aktivierst es mit thinking: {type: \"adaptive\"} in der API, oder — und das ist das Entscheidende für Claude Code-Nutzer — du steuerst es mit der Prompt-Formulierung.\n\nZwei Formulierungen, die tatsächlich etwas bewirken:\n\n- „Think carefully step by step" — signalisiert Claude, dass dies eine Aufgabe ist, für die es sich lohnt, Denk-Token zu verbrennen. Es wird mehr Reasoning pro Schritt aufwenden.\n- „Prioritize responding quickly" — signalisiert das Gegenteil. Claude kürzt sein Reasoning und liefert schneller, auf Kosten etwas weniger Tiefe.\n\nHier ist die Nuance, die ich einen Tag brauchte, um sie vollständig zu verinnerlichen: Effort und Thinking sind jetzt getrennte Regler. Effort-Level ist das gesamte Ressourcenbudget für eine Aufgabe — wie viel Arbeit Claude insgesamt bereit ist zu leisten, über Tool-Aufrufe, Datei-Reads und Wiederholungen hinweg. Thinking ist die Reasoning-Tiefe pro Schritt — wie hart Claude nachdenkt, bevor es eine einzelne Entscheidung trifft.\n\nDu kannst hohes Effort mit niedrigem Thinking haben (viele Aktionen, jede schnell entschieden) oder niedriges Effort mit hohem Thinking (wenige Aktionen, jede sorgfältig überlegt). Für meinen Linear-Klon-Nachtest produzierte max effort + „think carefully step by step"-Formulierung die sauberste Ausgabe. Für eine schnelle Bug-Behebung in einer API-Route erledigte xhigh effort + „prioritize responding quickly" es in etwa einem Drittel der Zeit, ohne die Korrektheit zu beeinträchtigen.\n\nDie andere Änderung, die es wert ist zu wissen: Ab Opus 4.7 werden Thinking-Inhalte standardmäßig aus der Antwort ausgelassen. Thinking-Blöcke erscheinen noch im Antwort-Stream, aber ihr Inhalt ist leer, es sei denn, du meldest dich explizit an. Das ist eine stille Änderung — kein Fehler, keine Warnung — und verbessert leicht die Antwortlatenz. Wenn du Tools hattest, die Thinking-Ausgabe geparst haben, prüfe, ob sie noch funktionieren.\n\n## Was ich behalte, was ich wieder weglasse\n\nVier Tage Nachtests. Hier meine ehrliche Bilanz.\n\nDauerhaft behalten:\n- Auto mode für Greenfield- und persönliche Arbeit. Der Classifier ist gut genug. Der Flow ist es wert.\n- Frontgeladene Spezifikationen für jeden Build, der keine triviale Einzel-Datei-Bearbeitung ist. Das war der größte Qualitätssprung.\n- /recap als Muskelgedächtnis bei jedem Sitzungswiederaufnahme. Kostenloser Gewinn.\n- Benachrichtigungen über Stop-Hooks, immer. Ich schäme mich, das nicht schon vor einem Jahr eingerichtet zu haben.\n- Prompt-formulierungs-basiertes adaptive thinking, weil ich keine Wahl habe — der Toggle ist weg.\n\nMit Vorbehalt behalten:\n- Max Effort-Level, aber nur für die richtigen Aufgaben. Es ist keine „mehr ist besser"-Einstellung. Verwende es, wenn die Aufgabe es rechtfertigt.\n- Claude Code vs. OpenCode-Rahmen — ich stimme der Aufteilung zu, aber ich greife an den meisten Tagen immer noch zuerst zu Claude Code, weil das Ökosystem sich zusammensetzt.\n\nWieder weglassen:\n- Nichts, ehrlich gesagt. Jeder Tipp hielt unter echter Arbeit stand. Deshalb veröffentliche ich diesen Beitrag anstatt des „Hier ist, wo Boris falsch liegt"-Rants, den ich halb erwartet hatte zu schreiben, als ich den Nachtest begann.\n\nWenn du meinen vorherigen Deep-Dive über Boris Chernys täglichen Workflow oder meine Analyse von Opus 4.7's praktischen Auswirkungen gelesen hast, wirst du bemerken, dass diese sieben Tipps sich mit den Prinzipien überschneiden, die Boris seit Monaten öffentlich teilt. Was neu ist, ist das spezifische Opus 4.7-Verhalten — adaptive thinking, entfernter Extended-Thinking-Toggle, max effort als echte Tier — und die Art, wie auto mode von einem experimentellen Flag zu etwas gereift ist, das ich jetzt als Standard für Greenfield-Arbeit empfehle.\n\n## Der Linear-Klon-Test — Was tatsächlich ausgeliefert wurde\n\nZurück zu dem Build, mit dem ich begann.\n\nVier Tage, drei Nachtests, sieben Techniken sauber angewendet. Der Linear-Klon, den ich am Ende hatte, verfügt über Projekte mit verschachtelten Aufgaben, ein Drag-and-Drop-Kanban-Board, Status- und Prioritätsfelder, Benutzer-Zuweisungen aus einer Seed-Datenbank, Tag-Unterstützung, eine Projekt-Seitenleiste und ein Task-Detail-Modal — genau die Spezifikation, die Boris demonstriert hatte. Next.js App Router, Prisma mit SQLite, Tailwind, shadcn/ui-Komponenten.\n\nGesamte menschliche Bearbeitungszeit: etwa vierzig Minuten, verteilt auf die drei Builds. Gesamte Claude Code-Zeit: etwa drei einhalb Stunden über alle drei Durchläufe. Gesamte Token beim besten Durchlauf: irgendwo um die 450K rein und 180K raus. Der beste Durchlauf war der mit max effort, frontgeladener Spezifikation, auto mode, adaptive-thinking-bewusster Prompt-Formulierung und Stop-Hook-Benachrichtigungen.\n\nJeder einzelne von Boris' sieben Tipps hat etwas beigetragen. Lass einen davon weg, und der Build wird schlechter, langsamer oder unterbrochener.\n\n## Häufig gestellte Fragen\n\n### Ist /recap ein echter Claude Code-Befehl?\nJa. /recap wurde im April 2026 in Claude Code ausgeliefert und gibt eine einzeilige Zusammenfassung der Aktionen deiner aktuellen Sitzung aus. Es ist über /config konfigurierbar, und du kannst das automatische Auslösen mit der CLAUDE_CODE_ENABLE_AWAY_SUMMARY-Umgebungsvariable erzwingen. Siehe die vollständige Effort-Level- und Sitzungsaufschlüsselung oben.\n\n### Was ist der Unterschied zwischen Claude Code's „high"- und „max"-Effort-Level?\nHigh begrenzt Thinking und Tool-Call-Tiefe auf eine vernünftige Obergrenze; max entfernt die Begrenzung vollständig und gilt nur für die aktuelle Sitzung (es sei denn, du pinst es mit CLAUDE_CODE_EFFORT_LEVEL). Verwende max für frontgeladene, architekturkomplexe Builds. Verwende high für Standard-Feature-Arbeit. Das vollständige Entscheidungsrahmenwerk ist in Tipp 5.\n\n### Wie aktiviere ich den auto mode in Claude Code?\nFühre claude --enable-auto-mode aus, um ihn für dein Konto freizuschalten, dann drücke dreimal Shift+Tab, um durch default → acceptEdits → plan → auto zu wechseln. Auto mode erfordert einen Team-, Enterprise- oder API-Plan und verwendet einen Sonnet 4.6-basierten Classifier, um riskante Tool-Aufrufe zu blockieren, bevor sie ausgeführt werden.\n\n### Hat Anthropic wirklich Extended Thinking in Opus 4.7 entfernt?\nJa. Das Setzen von thinking: {\"type\": \"enabled\", \"budget_tokens\": N} auf Opus 4.7 gibt einen 400-Fehler zurück. Adaptive thinking (thinking: {type: \"adaptive\"}) ist jetzt der einzige Thinking-on-Modus, und Claude entscheidet die Thinking-Tiefe dynamisch. Du steuerst es mit Prompt-Formulierungen wie „think carefully step by step" oder „prioritize responding quickly". Details in Tipp 7.\n\n### Sollte ich Claude Code oder OpenCode verwenden?\nBeide. Verwende Claude Code für tiefe, produktionsqualitative Builds, bei denen Architektur und Codequalität wichtig sind. Verwende OpenCode für schnelle Prototypen, Wegwerf-Tooling oder wenn du an Nicht-Anthropic-Modelle weiterleiten musst. Boris' Formulierung in Tipp 3 entspricht meiner eigenen Erfahrung mit beiden Tools.\n\n## Noch eine letzte Sache\n\nDer Grund, warum Boris' sieben Tipps funktionieren, ist nicht, dass sie clever sind. Die meisten von ihnen sind, einzeln betrachtet, klein. /recap ist ein Slash-Befehl. Ein Stop-Hook sind zehn Zeilen JSON. Auto mode ist ein Flag.\n\nDer Grund, warum sie funktionieren, ist, dass sie zusammen dazu beitragen, von der Person, die in Claude Code eingibt, zur Person zu werden, die es dirigiert — und zwei oder drei Instanzen davon gleichzeitig dirigiert, während man dem nächsten Problem vorausdenkt. Jeder Tipp in der Liste entfernt entweder eine Babysitting-Aufgabe, erhöht die Ausgabequalität oder hilft dabei, das Richtige zu spezifizieren, bevor man Enter drückt.\n\nIch habe vier Tage damit verbracht, denselben Linear-Klon auf drei verschiedene Weisen neu zu bauen, und der Tipp, zu dem ich immer wieder zurückkehre, ist keiner der sieben. Es ist der Meta-Tipp unter all diesen: Die Entwickler, die gerade mit Claude Code gewinnen, sind nicht diejenigen, die mehr Prompts gelernt haben. Es sind diejenigen, die aufgehört haben, so zu handeln, als wären sie in einem Gespräch mit einer KI, und angefangen haben, so zu handeln, als würden sie ein kleines Engineering-Team von einem führen.\n\nDreimal Shift+Tab. Spezifikation von Anfang an laden. Laufen lassen. Geh den nächsten Prompt in der Desktop-App entwerfen, während die Benachrichtigungen die Updates übernehmen.\n\nDas ist das ganze Spiel.\n\n## Zusammenarbeiten\n\nDu möchtest KI-Systeme aufbauen, Workflows automatisieren oder deine Tech-Infrastruktur skalieren? Ich helfe dir gerne dabei.\n\n* Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD\n* Portfolio: mejba.me\n* Ramlit Limited (enterprise solutions): ramlit.com\n* ColorPark (design & branding): colorpark.io\n* xCyberSecurity (security services): xcybersecurity.io"