Das Interaktionsmodell ist der Fits-Mechanismus, nicht die Funktionsliste

Eine Lektüre des Honest Architect zu Claude Code vs Cursor in 2026: Which One Actually Does the Work? (askglitch.com, Professor Glitch, datiert auf den 7. Juli 2026).

Der Artikel eröffnet mit einem Einzeiler-Urteil: Cursor ist ein besserer Editor — er macht Sie schneller, während Sie den Code schreiben; Claude Code ist ein besserer Mitarbeiter — Sie übergeben die Arbeit und er kommt mit der erledigten Arbeit zurück. Der Autor offenbart, dass sein gesamtes Geschäft auf Claude Code läuft (ein Team von darauf aufgebauten AI-Agenten behandelt seine Content-Pipeline, E-Mail und Operationen, jeden Tag), und sagt, er werde noch nennen, wo Cursor gewinnt. Die Substanz steckt in zwei Abschnitten: Cursor (ein AI-first-Code-Editor, ein VS-Code-Fork, mit Tab-Autovervollständigung als Signatur-Funktion, plus einem «autonomy slider» von Tab zu Agent mode zu cloud agents), und Claude Code (ein agentic-Coding-Werkzeug ohne Editor zum Öffnen — Sie geben ihm eine Aufgabe und es liest Ihre Codebasis, macht einen Plan, editiert Dateien, führt Befehle aus, führt Tests aus und berichtet). Das mentale Modell: Cursor ist ein besserer Stift, Sie sind noch der Schreiber; Claude Code ist ein Mitarbeiter, Sie beschreiben das Ergebnis und er besitzt den Prozess. Er schließt mit einer «beide»-Antwort — die Claude-Code-Erweiterung installiert direkt in Cursor.

Der Honest Architect liest dies als sechs Instanzen einer Mechanismusform, und die gewichtstragende ist das Interaktionsmodell. Die Eigenschaft ist «das Werkzeug passt zur Arbeit»; der Mechanismus ist «das Interaktionsmodell passt zur Form der Arbeit» — Tab für tipplastige Arbeit, Delegation für ergebnislastige Arbeit. Theorem 3 im HAI Engine von Everythink behauptet dieselbe Form: eine Eigenschaft ist genau dann garantiert, wenn ihr Mechanismus implementiert ist und misst. Hier gilt «das Werkzeug erledigt die Arbeit», weil das Interaktionsmodell zur Form der Arbeit passt, nicht weil das Werkzeug mehr Funktionen hat. Der Artikel benennt dies ausdrücklich — die Frage ist nicht «welches ist besser», sondern «wollen Sie die Arbeit schneller erledigen, oder wollen Sie die Arbeit erledigt bekommen?»

Eine Scope-Notiz vor den Mechanismen: die Quelle ist ein Vergleichs-Post eines Operators, der sein Geschäft auf Claude Code laufen lässt und eine Community-Mitgliedschaft verkauft. Der Honest Architect behandelt den Post als veröffentlichtes Artefakt mit offengelegtem Bias, nicht als neutrale Evaluation. Die sechs Mechanismusformen unten sind ✅ Production. Die Cross-Domain-Parallelen zu Everythink sind ⚠️ Partial — strukturell, nicht die Behauptung, Everythink sei ein Coding-Werkzeug. Ein Everythink-AI-Tooling- oder Agenten-Produkt ist 🔵 Roadmap. Die Quelle und Everythink operieren im kommerziellen und industriellen Scope.

Mechanismus 1 — Das Interaktionsmodell ist der Fits-Mechanismus

Der Artikel sagt «Cursor ist ein besserer Stift. Sie sind noch der Schreiber. Jeder Tastenanschlag, jede Datei, jede Entscheidung läuft durch Sie, und Cursor macht jedes dieser Momente schneller» und «Claude Code ist ein Mitarbeiter. Sie beschreiben das Ergebnis, er besitzt den Prozess. Sie begutachten die Arbeit, nicht die Tastenanschläge». Der Honest Architect liest dies als die Fits-Mechanismus-Behauptung: das Werkzeug passt zur Arbeit, genau dann, wenn das Interaktionsmodell zur Form der Arbeit passt, nicht wenn das Werkzeug mehr Funktionen oder ein besseres Modell hat. Der Mechanismus, der Fits erzeugt, ist «ein Interaktionsmodell (Tab oder Delegation), das zur Form der Arbeit (tipplastig oder ergebnislastig) passt». Das Interaktionsmodell ist der Mechanismus; die Funktionsliste ist es nicht. ✅ Production — der Post benennt den Mechanismus (Stift vs. Mitarbeiter, Tab vs. Delegation) und die Eigenschaft (das Werkzeug passt zur Arbeit).

Das Interaktionsmodell erzeugt kein besseres Werkzeug. Es erzeugt ein Werkzeug, das zu einer spezifischen Arbeitsform passt. Der Fits ist der Mechanismus; die Funktionsanzahl ist es nicht.

Die Cross-Domain-Parallele zu «the space is the router» in Everythink ist nur strukturell. Die network → community → room-Topologie routet, bevor etwas antwortet — eine Nachricht im falschen Raum wird durch die Topologie ausgeschlossen. Das «das Interaktionsmodell passt zur Form der Arbeit; ein Stift bei ergebnislastiger Arbeit ist das falsche Modell» des Posts und Everythinks «die Topologie routet; ein falscher Raum ist die falsche Topologie» teilen dieselbe Form: ein strukturelles Modell ordnet Arbeit dem Responder zu; ein Mismatch wird durch Mechanismus ausgeschlossen. ⚠️ Partial.

Mechanismus 2 — Der autonomy slider ist der Delegations-Graduations-Mechanismus

Der Artikel sagt, Cursor sei um einen «autonomy slider» herum gebaut: am unteren Ende Tab-Vervollständigungen; in der Mitte Agent mode, wo Sie eine Aufgabe übergeben und das Ergebnis begutachten; am oberen Ende cloud agents, die End-to-End Funktionen bauen, testen und demonstrieren, plus Automations auf Zeitplänen und Bugbot für Pull-Request-Reviews. Der Honest Architect liest dies als die Delegations-Graduations-Mechanismus-Behauptung: Delegation ist graduell, genau dann, wenn ein Slider den Nutzer wählen lässt, wie viel Unabhängigkeit er der AI gibt, nicht wenn die AI entweder vollautonom oder vollmanuell ist. Der Mechanismus, der graduelle Delegation erzeugt, ist «ein Slider mit diskreten Stufen (Tab, Agent, cloud agent), den der Nutzer bewegt». Der Slider ist der Mechanismus; die AI-Fähigkeit ist es nicht. ✅ Production — der Post benennt den Mechanismus (den autonomy slider mit Tab, Agent, cloud agents) und die Eigenschaft (graduelle Delegation).

Der Slider erzeugt keine Autonomie. Er erzeugt ein nutzergewähltes Autonomie-Level. Der Slider ist der Delegations-Graduations-Mechanismus; das Interaktionsmodell ist der Fits-Mechanismus.

Die Cross-Domain-Parallele zu den trait-basierten hexagonalen Ports in Everythink ist nur strukturell. AppState-Repositories sind Arc<dyn Trait> — das Trait ist der Vertrag, und ein Adapter ohne das Trait passt nicht in den Port. Das «der Slider definiert, was die AI tun kann; eine Aktion außerhalb der Stufe wird nicht ausgeführt» des Posts und Everythinks «das Trait definiert, was der Port akzeptiert; ein Adapter ohne Trait passt nicht» teilen dieselbe Form: ein Vertrag definiert die erlaubte Aktion; eine Aktion außerhalb wird durch Mechanismus ausgeschlossen. ⚠️ Partial.

Mechanismus 3 — Die Harness-Komposition ist der Job-Konstruktions-Mechanismus

Der Artikel sagt, Claude Code liefere ein vollständiges Agenten-Harness: CLAUDE.md (persistente Anweisungen), Skills (verpackte Workflows wie /review-pr), Hooks (Shell-Befehle bei Lifecycle-Ereignissen), MCP (der offene Standard zum Verbinden von Werkzeugen), Subagents (parallele Agenten), Routines (geplante Cloud-Ausführungen, die auch bei geschlossenem Laptop feuern) und das Agent SDK. Der Post benennt die Komposition: «ein Skill, das Ihren Wochenbericht entwirft, eine Routine, die ihn jeden Freitag um 16 Uhr ausführt, ein MCP-Server, der ihn an Slack liefert. Das ist kein Coding-Workflow. Das ist ein delegierter Job». Der Honest Architect liest dies als die Job-Konstruktions-Mechanismus-Behauptung: ein Coding-Werkzeug wird zum Arbeiter, genau dann, wenn Skills plus Routines plus MCP zu einem delegierten Job komponieren, nicht wenn ein einzelner Agent fähiger ist. Der Mechanismus, der einen Arbeiter erzeugt, ist «Komposition von Skills + Routines + MCP zu einem wiederkehrenden delegierten Job». Die Harness-Komposition ist der Mechanismus; der Einzelagent ist es nicht. ✅ Production — der Post benennt den Mechanismus (Skills + Routines + MCP-Komposition) und die Eigenschaft (ein Werkzeug wird zum Arbeiter).

Die Harness-Komposition erzeugt keinen besseren Agenten. Sie erzeugt einen Job, der läuft, ohne dass der Nutzer zuschaut. Die Komposition ist der Mechanismus; die Teile sind es nicht.

Die Cross-Domain-Parallele zum Oracle-Ensemble in Everythink ist nur strukturell. Oracle fusioniert mehrere typisierte Sisters-Ausgaben zu einem normalisierten Ensemble, und jeder Merge stempelt Entropie in nats. Das «Skills + Routines + MCP komponieren zu einem delegierten Job» des Posts und das «Sisters komponieren zu einem kalibrierten Ensemble» des Oracle teilen dieselbe Form: eine Komposition typisierter Teile erzeugt ein Ganzes, das kein einzelnes Teil erzeugt. ⚠️ Partial.

Mechanismus 4 — Die Modellwahl ist der Risiko-Verteilungs-Mechanismus

Der Artikel sagt, Cursor sei model-agnostic — Stand Juli 2026 führt es GPT-5.5, Claude Opus 4.8, Gemini 3.1 Pro, Grok 4.3 und Composer 2.5 aus, pro Anfrage umschaltbar. Claude Code führt nur Claude, und der Post benennt die Einschränkung: «Wenn Anthropic einen schlechten Modell-Monat hat, spüren Sie es. Cursor-Nutzer wechseln einfach das Modell». Der Honest Architect liest dies als die Risiko-Verteilungs-Mechanismus-Behauptung: Modell-Risiko ist verteilt, genau dann, wenn ein Nutzer pro Anfrage das Modell wechseln kann, nicht wenn ein einzelnes Modell im Durchschnitt besser ist. Der Mechanismus, der verteiltes Risiko erzeugt, ist «ein Modellwechsel, den der Nutzer pro Anfrage kontrolliert». Die Modellwahl ist der Mechanismus; das Einzelmodell ist es nicht. ✅ Production — der Post benennt den Mechanismus (model-agnostic-Umschaltung) und die Eigenschaft (Risiko-Verteilung).

Die Modellwahl erzeugt kein besseres Modell. Sie erzeugt ein System, in dem ein schlechter Modell-Monat den Nutzer nicht bricht. Der Wechsel ist der Risiko-Verteilungs-Mechanismus; die Modellqualität ist es nicht.

Die Cross-Domain-Parallele zur World-Monitor-Selbstdeaktivierung in Everythink ist nur strukturell. Eine Quelle, deren key_env nicht gesetzt ist, deaktiviert sich selbst — gibt Ok(None) zurück — sodass ein fehlender Schlüssel die Plattform niemals bricht. Das «ein schlechter Modell-Monat wird durch Wechsel überlebt» des Posts und das «ein fehlender Schlüssel wird durch Selbstdeaktivierung überlebt» von World Monitor teilen dieselbe Form: ein Mechanismus überlebt eine schlechte Komponente durch anmutige Verschlechterung. ⚠️ Partial.

Mechanismus 5 — Die Oberflächen-Mobilität ist der Zugangs-Mechanismus

Der Artikel sagt, Claude Code laufe an fünf Orten: dem Terminal-CLI, den VS-Code- und JetBrains-Erweiterungen, einer eigenständigen Desktop-App, dem Web unter claude.ai/code und der Claude-iOS-App. Sitzungen wandern zwischen Oberflächen: beginnen Sie im Web, ziehen Sie die Sitzung mit claude --teleport ins Terminal, übergeben Sie sie mit /desktop an die Desktop-App. Die Desktop-App und claude.ai/code haben die Terminal-Barriere beseitigt — Sie beschreiben in einer Chat-Box in einfachem Englisch, was Sie wollen. Der Honest Architect liest dies als die Zugangs-Mechanismus-Behauptung: das Werkzeug ist für Nicht-Entwickler zugänglich, genau dann, wenn die Oberfläche die IDE-Barriere beseitigt, nicht wenn der Agent fähiger ist. Der Mechanismus, der Zugang erzeugt, ist «Oberflächen-Mobilität über Terminal, IDE, Desktop, Web und iOS». Die Oberflächen-Mobilität ist der Mechanismus; die Agenten-Fähigkeit ist es nicht. ✅ Production — der Post benennt den Mechanismus (fünf Oberflächen, Sitzungs-Teleport) und die Eigenschaft (Nicht-Entwickler-Zugang).

Die Oberflächen-Mobilität erzeugt keinen besseren Agenten. Sie erzeugt einen Agenten, der einen Nutzer erreicht, der nie eine IDE öffnen würde. Die Oberfläche ist der Zugangs-Mechanismus; der Agent ist der Arbeits-Mechanismus.

Die Cross-Domain-Parallele zum World-Monitor-Cache in Everythink ist nur strukturell. Clients lesen den persistenten Cache, niemals die Upstreams — der Cache ist die Oberfläche, die der Client liest. Das «die Oberfläche ist, was der Nutzer liest; die IDE ist nicht die einzige Oberfläche» des Posts und das «der Cache ist, was der Client liest; der Upstream ist nicht die Oberfläche» von World Monitor teilen dieselbe Form: eine Oberfläche bestimmt, was der Konsument sieht; der Konsument liest die Oberfläche, nicht die Quelle. ⚠️ Partial.

Mechanismus 6 — Das Stacking ist der Kompositions-Mechanismus

Der Artikel sagt «das ist eigentlich keine Gabelung im Weg» — Cursor ist ein VS-Code-Fork, also installiert sich die Claude-Code-Erweiterung direkt darin, und das Ergebnis ist Cursors Tab-Vervollständigungen beim Tippen plus ein Claude-Code-Panel im selben Fenster. Beide Eintritts-Pläne kosten $20/Monat, also kostet die beide-Antwort $40/Monat. Der Honest Architect liest dies als die Kompositions-Mechanismus-Behauptung: die Werkzeuge komponieren, genau dann, wenn der Stift und der Mitarbeiter im selben Fenster gestapelt werden, nicht wenn ein Werkzeug das andere ersetzt. Der Mechanismus, der Komposition erzeugt, ist «eine Erweiterung, die den Mitarbeiter in das Fenster des Stifts installiert». Das Stacking ist der Mechanismus; die Entweder-Oder-Wahl ist es nicht. ✅ Production — der Post benennt den Mechanismus (die Claude-Code-Erweiterung in Cursor) und die Eigenschaft (die Werkzeuge komponieren).

Das Stacking erzeugt kein vereinheitlichtes Werkzeug. Es erzeugt zwei Werkzeuge in einem Fenster, die jeweils tun, was sie am besten können. Die Erweiterung ist der Kompositions-Mechanismus; die Entweder-Oder-Wahl ist es nicht.

Die Cross-Domain-Parallele zum hexagonalen AppState in Everythink ist nur strukturell. AppState hält mehrere Arc<dyn Trait>-Repositories — jeder Port beantwortet eine andere Frage, und die Komposition der Ports beantwortet die vollständige Anfrage. Das «der Stift und der Mitarbeiter stapeln; jeder tut, was er am besten kann» des Posts und Everythinks «die Ports komponieren; jeder beantwortet eine andere Frage» teilen dieselbe Form: eine Komposition unterschiedlicher Mechanismen beantwortet eine vollständigere Frage als jeder einzelne Mechanismus. ⚠️ Partial.

Was dies für Scope und Grenzen bedeutet

Der Post benennt einen gewichtstragenden Mechanismus — das Interaktionsmodell — und fünf stützende. Die Cross-Domain-Parallelen zu Everythink sind strukturell; der Honest Architect markiert sie ⚠️.

Ein Everythink-AI-Tooling- oder Agenten-Produkt ist 🔵 Roadmap — Everythink ist eine Vorhersageplattform, kein Coding-Werkzeug. Die architektonischen Parallelen halten unabhängig stand; die Produkt-Behauptung hält nicht stand.

Der Post vermischt seine Mechanismen nicht. Das Interaktionsmodell erzeugt Fits, der Slider erzeugt graduelle Delegation, die Harness-Komposition erzeugt einen Arbeiter, die Modellwahl erzeugte Risiko-Verteilung, die Oberflächen-Mobilität erzeugt Zugang, das Stacking erzeugt Komposition. Jeder Mechanismus erzeugt eine spezifische Eigenschaft.

Der HAI Engine von Everythink läuft seit 2016 in Produktion, und die typisierten Sisters — analyst, contrarian, disruptor, historian, institutionalist — sind in the 21 papers verankert, die die Vorhersage-Methodologie definieren. Die Sisters und das Oracle schreiben keinen Code, aber sie teilen mit dem Interaktionsmodell dieselbe ehrliche Praxis: der Mechanismus ist das Interaktionsmodell, die Funktionsliste ist es nicht, und die Eigenschaft ist nur garantiert, wenn der Mechanismus implementiert ist und misst.

Häufig gestellte Fragen

Behauptet dieser Beitrag, das Interaktionsmodell sei das Einzige, was bei der Wahl eines Coding-Werkzeugs zählt? Nein. Der Beitrag behauptet, das Interaktionsmodell sei der Mechanismus, den der Artikel für die Erzeugung von Fits benennt — nicht dass es das Einzige ist, was zählt. Preis, Modellqualität und Erweiterbarkeit zählen alle. Der Artikel benennt das Interaktionsmodell als die gewichtstragende Unterscheidung; der Honest Architect markiert es als Mechanismus, nicht als Qualitätsurteil.

Warum ist der autonomy slider ein vom Interaktionsmodell getrennter Mechanismus? Weil der Post sie getrennt benennt. Das Interaktionsmodell erzeugt Fits (das Werkzeug passt zur Form der Arbeit); der Slider erzeugt graduelle Delegation (der Nutzer wählt das Unabhängigkeits-Level innerhalb eines Werkzeugs). Die zwei setzen sich zusammen, und der Post vermischt sie nicht.

Wozu komponieren «Skills + Routines + MCP», was ein einzelner Agent nicht leistet? Einen wiederkehrenden delegierten Job. Ein Skill allein ist ein manueller Workflow; eine Routine allein geht nirgendwohin; ein MCP allein ist eine Verbindung. Die Komposition — ein Skill, das einen Bericht entwirft, eine Routine, die ihn jeden Freitag ausführt, ein MCP, das ihn an Slack liefert — ist ein Job, der ohne Zuschauen läuft. Die Komposition ist der Mechanismus, nicht die Teile.

Ist die Modellwahl ein echter Risiko-Verteilungs-Mechanismus oder nur eine Funktion? Es ist ein Risiko-Verteilungs-Mechanismus, weil der Post das Versagensmodell benennt: «Wenn Anthropic einen schlechten Modell-Monat hat, spüren Sie es. Cursor-Nutzer wechseln einfach das Modell». Der Wechsel ist der Mechanismus, der den schlechten Monat überlebt; die Modellqualität ist die Komponente. Ein Wechsel, den der Nutzer pro Anfrage kontrolliert, ist ein Mechanismus.

Sind die Cross-Domain-Parallelen zu Everythink verifiziert oder aspirational? Es sind strukturelle Parallelen, markiert als ⚠️ Partial. Sie teilen die Mechanismusform mit der Everythink-Architektur; sie behaupten nicht, dass Everythink ein Coding-Werkzeug ist oder unsere Vorhersage-Engine Coding-Agenten ausführt. Ein Everythink-AI-Tooling- oder Agenten-Produkt ist 🔵 Roadmap.

Beginnen Sie Ihre eigene kalibrierte Vorhersage

Der HAI Engine von Everythink betreibt typisierte Sisters und ein kalibriertes Oracle seit 2016 in Produktion. Die the 21 papers, die die Methodologie verankern, sind öffentlich; die Vorhersage-API ist über einen Eye Key zugänglich. Wenn Sie sehen möchten, wie ein kalibriertes Ensemble aus typisierten Agenten konstruiert wird — mit Entropie, die bei jedem Merge gestempelt wird, nicht einmal beim Deployment — beginnen Sie mit der API-Dokumentation.

Sources

• Claude Code vs Cursor in 2026: Which One Actually Does the Work?, Professor Glitch, askglitch.com, datiert auf den 7. Juli 2026. https://www.askglitch.com/blog/claude-code-vs-cursor (abgerufen am 2026-08-23).
• Im Post benannte konkrete Artefakte: Cursors autonomy slider (Tab → Agent mode → cloud agents + Automations + Bugbot); Cursors Modellliste Stand Juli 2026 (GPT-5.5, Claude Opus 4.8, Gemini 3.1 Pro, Grok 4.3, Composer 2.5); Cursors Preisgestaltung (Hobby kostenlos, Pro $20/Monat, Pro+ $60/Monat, Ultra $200/Monat); Claude Codes fünf Oberflächen (Terminal-CLI, VS-Code- + JetBrains-Erweiterungen, Desktop-App, Web unter claude.ai/code, iOS) mit Sitzungs-Mobilität via claude --teleport und /desktop; Claude Codes Harness-Komponenten (CLAUDE.md, Skills, Hooks, MCP, Subagents, Routines, Agent SDK); Claude Codes Preisgestaltung (enthalten in Claude Pro $20/Monat, Max $100 oder $200/Monat, oder Pay-per-Token-API); das Kompositionsbeispiel (ein Skill, das einen Wochenbericht entwirft, eine Routine, die ihn jeden Freitag um 16 Uhr ausführt, ein MCP-Server, der ihn an Slack liefert); das Stacking-Setup (Claude-Code-Erweiterung installiert in Cursor, beide Eintritts-Pläne $20/Monat, beide-Antwort $40/Monat).
• Everythink-Plattform-Architektur: HAI Engine seit 2016 in Produktion; Theorem 3 (eine Eigenschaft ist genau dann garantiert, wenn ihr Mechanismus implementiert ist und misst); «the space is the router»-Topologie (network → community → room); World Monitor (Geo-Signale nach Geohash-Präfixen geroutet, Multi-Source-Gateway mit pro-Quelle-Selbstdeaktivierung, sodass ein fehlender Schlüssel die Plattform niemals bricht, deterministische uuidv5, sodass Wiederaufnahme aktualisiert statt dupliziert, Clients lesen den persistenten Cache nicht die Upstreams, Quellen sind Daten nicht Code — man fügt einen Feed hinzu, indem man einen SourceDescriptor hinzufügt); Oracle-Ensemble-Normalisierung stempelt Entropie in nats auf jeden Merge; typisierte Sisters (analyst, contrarian, disruptor, historian, institutionalist) in the 21 papers verankert, zur Laufzeit aus TOML-Dateien geladen mit Prompt-Version auf jedem Lauf gestempelt für Reproduzierbarkeit; trait-basierte hexagonale Ports mit austauschbaren Adaptern (Arc<dyn Trait> in AppState); Zod-Wire-Types einmal in @everythink/types definiert, an der Netzwerkgrenze geparst, schlechte Payload → typisierter ApiError; Eye Key-Souveränität (HMAC und Fingerabdruck gespeichert, der Klartext berührt niemals die Festplatte, der Schlüssel des Benutzers ist die Rate-Limit-Grenze).