Lass deine KI nicht ihre eigenen Hausaufgaben benoten
Bevor etwas Wichtiges deine Hände verlässt, gib es dem Modell, das es nicht geschrieben hat. Was diese Vier-Minuten-Gewohnheit wirklich findet, die Forschung dahinter, und wo es nur Theater ist.
Fabian Mösli Leseeinstellungen
Das Wichtigste in Kürze
- • Bevor etwas Wichtiges deine Hände verlässt, füg das fertige Ergebnis und ein zweizeiliges Briefing in ein Modell ein, das es nicht geschrieben hat. Füg nie das Gespräch ein, denn der frische Context ist genau das, wofür du bezahlst.
- • Nimm die Kritik dann zurück zum ersten Modell und lass es sich Punkt für Punkt verteidigen. Überspringst du das, knickt es vor jeder Kritik ein, auch vor den falschen, und du landest bei einem schlechteren Entwurf.
- • Frag aktiv nach der zweiten Lektüre, automatisiere sie nicht. In vorregistrierten Experimenten liess eine ständig eingeblendete Zweitmeinung Leute guten Rat etwa so oft misstrauen wie schlechten. Wer selbst entschied, wann sie fragten, bekam den Vorteil ohne diesen Preis.
In diesem Guide
Ich zahle für Claude und ich zahle für ChatGPT, und die Leute fragen mich ständig, welches ich behalten würde, wenn ich eines aufgeben müsste. Etwa ein Jahr lang gab ich darauf eine schlechte Antwort: Ich redete über Stärken, das eine besser bei langen Dokumenten, das andere bei aktuellen Informationen, nimm halt, was zu deiner Arbeit passt.
Das ist nicht der Grund, warum ich beide habe.
Der eigentliche Grund kam aus einem etwas peinlichen Abend. Ich hatte Stunden mit Claude an einem Business Case gearbeitet, der Sorte mit einem Dutzend verknüpfter Annahmen, wo eine falsche Zahl still und leise alles Nachgelagerte vergiftet. Gute Session, die Art, wo du zurückstösst und es zurückstösst und du am Ende wirklich etwas durchdacht hast. Dann bat ich es, das Ergebnis zu prüfen, bevor ich damit zum Team ging. Es sagte mir, die Logik halte.
Aus Neugier fügte ich dasselbe in ChatGPT ein, unvoreingenommen, ohne jede Vorgeschichte, wie es entstanden war. Im zweiten Absatz fragte es, warum ich einen meiner Kosteneingaben als fix behandelte, obwohl im Briefing nirgends stand, dass er fix sei. Es hatte recht. Ich hatte diese Annahme drei Stunden zuvor getroffen, Claude hatte mir geholfen, darauf aufzubauen, und als ich um eine Prüfung bat, war die Annahme längst nichts mehr, das man noch überprüfte. Sie gehörte zum Inventar. Der Case überlebte, aber der Boden darunter hatte sich verschoben, und ich finde das lieber an einem Dienstagabend heraus als am Donnerstag vor dem Team.
Das zweite Modell ist also ein Leser, der nicht im Raum war, als das Ding entstand.
Die ganze Gewohnheit besteht aus vier Schritten, und du kannst nach diesem Absatz aufhören zu lesen und trotzdem den grössten Teil des Nutzens mitnehmen. Beende die Arbeit in einem Modell. Öffne das andere in einem neuen Chat und gib ihm zwei Dinge: das fertige Ergebnis und eine zweizeilige Aussage darüber, was es erreichen sollte. Nie das Gespräch. Frag es, wo der Entwurf am Briefing scheitert. Nimm dann, was zurückkommt, zum ersten Modell zurück und lass es zu jedem Punkt Stellung beziehen, statt einfach zuzustimmen.
Der Rest hier erklärt, warum das funktioniert, was es tatsächlich findet, wann es Zeitverschwendung ist, und wie du es in den Chat-Apps oder auf der Kommandozeile umsetzt.
Warum ein Modell die eigene Arbeit nicht benoten kann
Dahinter steckt echte Forschung, und das ist der stärkste Teil des Arguments.
Auf der NeurIPS 2024 veröffentlichten Arjun Panickssery, Samuel Bowman und Shi Feng LLM Evaluators Recognize and Favor Their Own Generations. Modelle, die Text bewerten sollen, geben ihrem eigenen Output höhere Noten als dem anderer Modelle, bei Arbeiten, die menschliche Gutachter als gleichwertig einstufen. Das nennt man Self-Preference-Bias. Was das Paper hinzufügt, ist eine Ursache: Modelle erkennen ihre eigene Schrift, weit über dem Zufallsniveau, und als die Forschenden diese Selbsterkennung per Fine-Tuning hoch- und runterdrehten, bewegte sich die Grösse des Bias mit. Je besser ein Modell seine eigene Arbeit erkennt, desto mehr schmeichelt es ihr.
Meine eigene Laienübersetzung: Vertrautheit macht die Arbeit, und dasselbe passiert dir mit deinem eigenen Entwurf. Du liest ihn nochmals durch und er klingt gut, weil du längst weisst, was jeder Satz sagen will. Du bewertest den Text nicht, du erkennst ihn nur wieder.
Hast du das einmal gesehen, wirkt «Claude soll Claudes Arbeit prüfen» nicht mehr wie Qualitätskontrolle. Das Modell, das die Sache geschrieben hat, oder das drei Stunden mit dir dran sass, während du sie geschrieben hast, ist der denkbar schlechteste Leser, den du wählen kannst. Und ein besserer Prompt rettet das nicht. Ich habe schon geschrieben, wie schwer es ist, ein Modell per Prompt davon abzubringen, dir zuzustimmen. «Sei kritisch» wird von der zugrundeliegenden Neigung einfach überrollt. Das ist dasselbe Problem, nur eine Ebene höher, und die Lösung ist strukturell, nicht sprachlich: Wechsle, wer liest.
Genau das unterscheidet es auch von der Recherche-Pipeline, die ich mit Perplexity und Claude fahre. Die teilt einen Job in Stufen auf und gibt jede Stufe dem Tool, das dafür gebaut ist. Hier machen beide Modelle dieselbe Arbeit am selben Material, und der ganze Punkt ist, dass eines der beiden sie nicht geschrieben hat.
Was ein unvoreingenommener Blick wirklich findet
Prompts sind leicht zu kopieren und schwer zu beurteilen, also hier, wie eine solche Runde konkret aussieht.
Das Briefing, das ich dem unvoreingenommenen Modell gab, war zwei Zeilen: «Das ist ein Business Case mit einer Fünfjahresprojektion. Er muss vor einem Führungsteam bestehen, das nachfragt, woher jede Zahl kommt.»
Drei der vier Punkte, die zurückkamen, waren Rauschen. Ein Vorschlag, eine Sensitivitätsanalyse zu ergänzen, gegen die ich mich schon entschieden hatte, eine Bemerkung zur Formatierung, eine generische Warnung vor Konkurrenzreaktionen. Diese Quote ist normal, und es lohnt sich, das laut zu sagen, damit du nicht denkst, du machst etwas falsch. Der vierte Punkt war dieser:
«Du behandelst die Stückkosten als fixe Grösse, aber im Briefing steht nirgends, dass sie fix ist, und die Marge reagiert am empfindlichsten genau auf diese Zahl. Bewegt sie sich um 10%, funktioniert der Case nicht mehr. Entweder begründest du, warum sie fix ist, oder die Schlussfolgerung hält nicht.»
Das war der Treffer. Kein Rechenfehler. Eine Entscheidung, die ich längst nicht mehr als Entscheidung wahrnahm.
Wichtiger als der Treffer selbst ist, was danach kam. Ich brachte alle vier Punkte zurück zu Claude und liess es sie diskutieren, statt sie einfach zu übernehmen. Bei der Kostenannahme stimmte es zu und schrieb den Abschnitt um. Bei der Sensitivitätsanalyse widersprach es und erklärte, warum die zusätzliche Komplexität die Entscheidung, die das Führungsteam eigentlich treffen musste, nicht verändern würde. Ich stimmte zu, und wir änderten dort nichts.
So funktioniert die Schleife: ein echter Treffer, eine verteidigte Ablehnung, zwei verworfene Punkte. Übernimmst du jede Kritik des zweiten Modells ungeprüft, landest du bei einem schlechteren Dokument als am Anfang, denn ein Modell, das um eine Prüfung gebeten wird, findet immer etwas.
Der Teil, der wehtut
Die Gegenevidenz hier ist stärker, als die meisten, die Multi-Modell-Workflows propagieren, zugeben, also gleich vorneweg.
Die bequeme Geschichte lautet: Zwei Modelle aus zwei Labs machen unabhängige Fehler, also fangen sie zusammen fast alles ab. Diese Geschichte stimmt grösstenteils nicht. Auf der ICML 2025 veröffentlichte eine Cornell-Gruppe Correlated Errors in Large Language Models, die grösste empirische Untersuchung dazu, die ich gefunden habe. Über mehr als 350 Modelle hinweg, auf einem der beiden getesteten Leaderboards, wählten zwei Modelle, die beide eine Frage falsch beantworteten, in rund 60% der Fälle dieselbe falsche Antwort. Weit über dem Zufallsniveau.
Die Richtung des Trends ist der unangenehme Teil. Grössere, genauere Modelle hatten mehr korrelierte Fehler, und das galt über verschiedene Architekturen und Anbieter hinweg. Alle trainieren auf überlappenden Ausschnitten desselben Webs, und die Post-Training-Rezepte sind sich immer ähnlicher geworden. Zwei Frontier-Modelle sind weniger wie zwei unabhängige Experten und eher wie zwei Absolventen desselben Studiengangs, die zufällig verschiedene Professoren hatten.
Also kalibriere den Anspruch. Eine zweite Lektüre findet einen echten Teil dessen, was das erste Modell übersehen hat. Sie ist kein Audit, sie macht dich nicht sicher, und wo beide Modelle selbstbewusst falsch liegen, liegen sie meist selbstbewusst in dieselbe Richtung falsch.
Frag danach, automatisiere es nicht
Der nächste Befund hat verändert, wie ich arbeite, und ich hätte dagegen gewettet.
Drei vorregistrierte Experimente, veröffentlicht in den Proceedings of the ACM on Human-Computer Interaction, untersuchten, was eine Zweitmeinung mit menschlichen Entscheidungen macht. Wurde den Leuten immer eine Zweitmeinung neben der KI-Empfehlung gezeigt, sank ihr übermässiges Vertrauen in die KI, was man sich erhoffen würde. Aber gleichzeitig stieg ihr zu geringes Vertrauen. Sie begannen, die KI zu überstimmen, auch wenn sie recht hatte. Nettoeffekt: nicht eindeutig besser. Und es machte keinen Unterschied, ob die Zweitmeinung von einer anderen KI kam oder von einem menschlichen Kollegen.
Die dritte Bedingung wirkte anders. Konnten die Leute selbst entscheiden, wann sie eine Zweitmeinung einholten, sank das übermässige Vertrauen, ohne den gleichen Preis auf der anderen Seite.
Ein ständiger Chor des Widerspruchs scheint dich zu lehren, allem zu misstrauen. Wenn du selbst entscheidest zu fragen, heisst das, du hast schon etwas bemerkt, das eine Prüfung wert ist, also liest du die Antwort mit eingeschaltetem Urteilsvermögen.
Das ist eine Laborstudie zu menschlicher Entscheidungsfindung, nicht zu Review-Pipelines, ich extrapoliere also. Aber sie macht mich skeptisch gegenüber dem Setup, das die meisten zuerst bauen: eine feste Zwei-Modell-Anordnung, bei der alles automatisch gegengeprüft wird, bevor du es zu sehen bekommst. Das erzeugt Rauschen, kostet doppelt, und macht dein Vertrauen schlechter kalibriert statt besser. Halt das zweite Modell einen bewussten Schritt entfernt und greif dazu, wenn der Einsatz es rechtfertigt. Ein leicht ärgerlicher Befund, denn die automatisierte Version ist die, die sich ausgefeilt anfühlt.
Das meiste davon geht auch mit einem einzigen Tool
Wenn deine Firma die Consumer-KI-Tools gesperrt und dir stattdessen Copilot oder einen internen Chatbot in die Hand gedrückt hat, lesen sich die letzten vier Abschnitte wahrscheinlich wie Ratschläge für jemand anderen. Sind sie nicht, und das hier ist der Teil, den ich mir ausbuchstabiert gewünscht hätte.
Was du mit einem zweiten Modell kaufst, ist ein frischer Context. Ein anderer Anbieter ist die stärkste Version davon, aber nicht die einzige. Öffne einen komplett neuen Chat in welchem Tool auch immer du nutzen darfst, mit Memory und Projektanweisungen ausgeschaltet, und füg nur das fertige Ergebnis und das zweizeilige Briefing ein. Keine Vorgeschichte, kein Reasoning, nichts darüber, wie du dorthin gekommen bist. Du hast das Gespräch entfernt, das das Modell blind gemacht hat, und das ist der grösste Teil des Effekts. Was du nicht entfernt hast, ist das geteilte Training und die geteilten Gewohnheiten, also wird es Dinge übersehen, die ein wirklich anderes Modell finden würde.
Nenn es 60 bis 70% der Technik ohne einen Rappen zusätzlich, und es funktioniert innerhalb eines von der Firma freigegebenen Stacks. Lern die Schleife dort. Bekommst du später Zugang zu einem zweiten Tool, weisst du bereits, wie man es nutzt. Die Zwei-Spuren-Regel gilt weiterhin: Arbeitsmaterial bleibt im Arbeits-Tool, privates Lernen passiert auf privaten Tools mit privatem Material, und die beiden vermischen sich nie. Der Guide dazu, wie du arbeitest, wenn deine Firma ChatGPT gesperrt hat, erklärt diese Trennung genauer.
Wann es sich lohnt, und wann es Theater ist
Ich entscheide das mit einer Frage: Was kostet es mich, wenn das falsch ist und ich es erst später merke?
Lautet die Antwort «nichts, ich merke es und korrigiere es», nimm ein Modell und mach weiter. E-Mails, erste Entwürfe, Brainstorming, das Zusammenfassen eines Dokuments, das du ohnehin gleich liest, alles, wo du der unmittelbare Konsument bist und ein Fehler schnell auffällt. Fast meine gesamte KI-Nutzung ist das, und die bleibt bei einem Modell.
Die zweite Lektüre lohnt sich bei einer bestimmten Art von Arbeit: Der Output verlässt deine Hände, und bis jemand den Fehler findet, hast du schon danach gehandelt. Eine Zahl, die in einen Business Case einfliesst. Ein Strategiememo, aus dem das Führungsteam eine Entscheidung ableitet. Eine kundenseitige Analyse, ein Migrationsplan, eine Vertragszusammenfassung, auf die du dich verlässt, statt sie selbst zu lesen. In diesen Fällen prüfst du, weil du die Arbeit rund eine Stunde vor Fertigstellung nicht mehr klar sehen konntest.
Drei Situationen, in denen es Theater ist, und ich war in allen dreien:
Beide Modelle bekommen denselben Context. Gibst du dem zweiten Modell das ganze Gespräch, samt deiner Überlegungen und deiner Rahmung, hast du genau die Bedingungen wiederhergestellt, die das erste Modell blind gemacht haben. Es wird dir zustimmen. Ergebnis und Briefing, nie die Vorgeschichte.
Du kannst nicht sagen, welche Antwort besser ist. Sind die beiden sich uneinig und du hast keine Möglichkeit zu entscheiden, hast du dir nur ein Unentschieden gekauft. Passiert das, sortiere die Uneinigkeit in eine von zwei Schubladen. Ist es eine Tatsachenfrage, schau selbst nach; die Modelle haben dir gerade gezeigt, auf welche Tatsache es ankommt. Ist es eine Ermessensfrage, ist sie deine, und die Uneinigkeit hat ihren eigentlichen Job schon erledigt, indem sie eine Entscheidung sichtbar gemacht hat, die du sonst getroffen hättest, ohne zu merken, dass du sie triffst. Was du nicht tun darfst: die Antwort nehmen, die dir gefällt, und sie für geprüft erklären.
Du weisst schon, welche Antwort du willst. Dann behältst du das Modell, das zustimmte, und wertest das andere still ab. Das ist das Fehlverhalten, auf das ich bei mir selbst achten muss, und es sieht genau aus wie Sorgfalt.
Es gibt auch eine Kostenseite. Anthropic berichtete, ihr Multi-Agent-Recherche-Setup verbrenne rund das Fünfzehnfache der Tokens eines normalen Chat-Austauschs, und ordnete das so ein, dass es sich nur lohnt, wenn die Aufgabe wertvoll genug ist, um das zu rechtfertigen. Die Engineers von Cognition gingen weiter und veröffentlichten Don’t Build Multi-Agents, mit dem Argument, dass das Aufteilen von Arbeit auf mehrere Agenten unstimmigen Output erzeugt, weil jeder Agent implizite Entscheidungen trifft, die die anderen nicht sehen. Sie haben ihre Position inzwischen abgeschwächt: das Denken parallelisieren, das Schreiben einsträngig halten. Ungefähr dort bin auch ich gelandet. Parallele Prüfung, ein Schreiber.
So geht’s in den Chat-Apps
Kein technisches Setup, rund vier Minuten Zusatzaufwand bei einem kurzen Ergebnis.
Klär zuerst, wohin das Material überhaupt darf. Geht es um Firmenarbeit, nutz den Account, den deine Firma freigegeben hat, und prüf, ob das ein Consumer- oder ein Business-Tarif ist. Consumer-Tarife haben Gespräche historisch standardmässig fürs Training genutzt, Business-Tarife nicht, und dieser Standard ist es wert, geprüft statt angenommen zu werden. Füg nie Arbeitsmaterial in ein privates Abo ein, nur um ein paar Franken zu sparen. Ist das Ergebnis wirklich vertraulich und du hast nur Consumer-Accounts, steht dir diese Technik für dieses Dokument nicht zur Verfügung, und kein Workflow-Vorteil rechtfertigt das Gegenteil.
Zu den Kosten, weil ich hier eine Gewohnheit empfehle und keinen Kauf: Sowohl Claude als auch ChatGPT haben kostenlose Tarife, und dieser Job ist so ziemlich das Kleinste, was man von einer KI verlangen kann. Ein Ergebnis, eine Lektüre, vielleicht eine Rückfrage. Du kannst die ganze Technik diese Woche testen, ohne irgendwem etwas zu bezahlen. Was du im kostenlosen Tarif triffst, sind ein schwächeres Modell und ein Nachrichtenlimit, und das ist der falsche Ort zum Sparen, sobald es um Arbeit geht, die wirklich zählt.
Die mechanische Regel, die das Ganze funktionieren lässt: gib das Ergebnis und das Briefing weiter, nie das Gespräch.
Claude in der Führungsrolle ist mein Standard für alles Schriftliche oder Analytische. Ich arbeite das Problem dort durch und nehme den Output dann in einem neuen Chat mit zu ChatGPT:
Ich gebe dir ein Briefing und einen Entwurf, der daraus entstanden ist. Du hast den Entwurf nicht geschrieben und hast kein Eigeninteresse daran. Schreib ihn nicht um und gib mir keine verbesserte Version. Sag mir drei Dinge: wo der Entwurf am Briefing scheitert, welche einzelne Aussage am schwächsten ist und warum, und was ein gut informierter, feindselig eingestellter Leser zuerst angreifen würde. Ist der Entwurf tatsächlich in Ordnung, sag das, statt etwas zu erfinden.
Der letzte Satz wiegt mehr, als er aussieht. Ohne ihn bekommst du erfundene Kritik, was derselbe Gefallenreflex in anderer Verkleidung ist, und schlimmer als Lob, weil es wie Sorgfalt aussieht.
ChatGPT in der Führungsrolle für alles, was von aktuellen, überprüfbaren Fakten abhängt. Seine Suche und Deep Research waren bei mir gründlicher, und es ist besser darin, die Sache tatsächlich zu finden, also passieren die Recherche und die erste Synthese dort, und Claude übernimmt den Kritikerstuhl. Gleiche Prompt-Form, eine Ergänzung: prüf jede Tatsachenbehauptung gegen die angegebenen Quellen und liste jede Behauptung auf, die diese Quellen nicht stützen. Das findet den spezifischen Fehler bei Recherche-Output: einen selbstbewussten Satz mit angehängter Quellenangabe, die nicht sagt, was der Satz behauptet.
Die meisten hören dort auf, und genau der übersprungene Schritt ist der, wo der Nutzen entsteht:
Hier ist eine Review deines Entwurfs von einem anderen Modell. Geh Punkt für Punkt durch. Sag bei jedem, ob du zustimmst, teilweise zustimmst oder widersprichst, und warum. Wo du widersprichst, verteidige das Original und ändere nichts. Überarbeite nur, was du wirklich für falsch hältst.
Ohne diese Vorgabe knickt das erste Modell vor jeder Kritik ein, auch vor den falschen, und du bekommst einen schlechteren Entwurf, der doppelt so lange gedauert hat. Modelle sind zueinander genauso gefällig wie zu dir.
Praktische Notizen, weil ich das oft mache. Markdown übersteht den Weg zwischen den Apps, formatierter Text nicht, also kopier als Klartext. Dateien werden nicht mitgenommen, du lädst sie auf beiden Seiten neu hoch. Memory und Projektanweisungen werden ebenfalls nicht mitgenommen, und genau das willst du hier. Und wenn du ein festes Kritiker-Setup pflegst, ein Claude Project oder ein Custom GPT mit den Review-Anweisungen, lass es kein Gedächtnis für deine Projekte aufbauen, sonst hast du dir langsam wieder genau den investierten Leser aufgebaut, dem du entkommen wolltest.
Wenn du Code schreibst, ist die Kommandozeilen-Version besser
Überspring diesen Abschnitt, wenn nicht. Nichts hier unten ändert den Rat von oben.
Das geprüfte Ergebnis ist ein Diff, und beide Agenten können das Repository selbst lesen. Claude Code in der Führungsrolle hat einen offiziell unterstützten Weg: OpenAI liefert und pflegt ein Plugin, das Codex in Claude Code einbindet. Installier es direkt in Claude Code:
/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/codex:setup
Das gibt dir /codex:review für eine Standard-Review nicht committeter Änderungen, und /codex:adversarial-review, den eigentlich lohnenswerten Befehl. Er stellt den Ansatz infrage, statt nur zu prüfen, ob der Code läuft. Dazu kommt /codex:rescue, um ein festgefahrenes Problem als delegierte Aufgabe zu übergeben, und --background, damit Codex weiterarbeitet, während du weitermachst. /codex:setup --enable-review-gate macht die Review bei jeder Änderung automatisch, und gemäss der Forschung oben lasse ich das aus. Das README des Plugins selbst warnt: “can create a long-running Claude/Codex loop and may drain usage limits quickly” (sinngemäss: kann eine lang laufende Claude/Codex-Schleife erzeugen und dein Nutzungslimit schnell aufbrauchen).
Ein Lab baut und pflegt das Tooling dafür, dass der Agent des Konkurrenten es konsultieren kann. Das ist längst kein Community-Hack mehr.
Codex in der Führungsrolle hat kein entsprechendes Plugin in die andere Richtung, also braucht es ein zweites Terminal und ein gemeinsames Briefing. Dieses gemeinsame Briefing richtig hinzubekommen ist das, was verhindert, dass die Review zu einer Stildiskussion wird. Codex und die meisten anderen Agenten lesen AGENTS.md. Claude Code nicht. Die Dokumentation macht klar, dass Claude Code CLAUDE.md liest, nicht AGENTS.md, also pflege nicht zwei Dateien, die auseinanderdriften. Pack den eigentlichen Inhalt in AGENTS.md und mach CLAUDE.md zu einer einzigen Zeile:
@AGENTS.md
Alles Claude-Spezifische kommt darunter. Jetzt arbeiten beide Agenten nach denselben Standards, und ein Review-Kommentar bedeutet, dass der Code falsch ist, nicht bloss anders gemeint. Zeig dem Reviewer git diff plus das Ticket, nicht das Transkript, und gib jedem Agenten sein eigenes Git-Worktree, wenn sie gleichzeitig laufen, sonst streiten sie sich um dieselben Dateien.
Lohnt sich das zweite Abo?
Dieser Teil ist Meinung. Wenn deine Arbeit regelmässig deine Hände verlässt und danach gehandelt wird: ja. Zwanzig im Monat gegen ein Memo, das ein Team drei Wochen lang in die falsche Richtung schickt, ist keine knappe Sache, und der teure Teil war nie der Fehler selbst. Es ist alles, was darauf aufbaut, bevor es jemand merkt. Aber ich will ehrlich sein: Das ist bei einem normalen Gehalt eine echte wiederkehrende Ausgabe, kein Rundungsfehler, und meine beste Geschichte dazu ist ein Beinahe-Fehler, den ich abgefangen habe, keine Katastrophe, die ich durchlebt habe. Test es zuerst kostenlos. Wenn zwei Monate davon keinen Treffer bringen, für den du bezahlt hättest, kauf das zweite Abo nicht. (Ich habe kein Affiliate-Verhältnis mit einer der beiden Firmen, und in diesem Guide gibt es keine Referral-Links.)
Ein ehrliches Wort zur Zeit, da ich jetzt schon zweimal vier Minuten gesagt habe. Vier Minuten ist der Testlauf: ein Ergebnis, eine Lektüre. Eine echte Runde bei einem Dokument, das zählt, mit dem Verteidigungsschritt und einer Entscheidung, über die du nachdenken musst, dauert eher zwanzig. Immer noch billig für etwas, das vor ein Führungsteam kommt, und trotzdem nicht nichts.
Es ist auch wirklich nicht für alle etwas. Ethan Mollick, der an der Wharton School lehrt und wohl die meistgelesene Stimme in diesem Feld ist, rät Leuten, Claude oder ChatGPT zu wählen, die zwanzig Dollar zu bezahlen und einem Agenten eine echte Aufgabe aus ihrem Leben zu geben. Für die meisten Leute, sagt er, reicht es, einfach das zu nehmen, das ihnen am besten gefällt. Ich glaube, bei den meisten Leuten hat er recht. Zwei Modelle reparieren kein schwaches Briefing; du bekommst zwei Antworten auf eine schlechte Frage. Baust du noch die Grundfertigkeit auf, ein ordentliches Briefing zu schreiben, werd zuerst mit einem Tool richtig gut. Und wenn du dich dabei ertappst, aus Angst statt aus Urteilsvermögen alles durch beide Modelle zu jagen, ist das ein Zwang im Gewand einer Prüfung.
Probier es diese Woche an einem einzigen Stück Arbeit, mit welchem Account auch immer du dafür nutzen darfst. Schreib in zwei Zeilen auf, was die Arbeit erreichen sollte. Öffne einen neuen Chat im Modell, das sie nicht geschrieben hat, füg diese zwei Zeilen und das fertige Ergebnis ein, und nutz den Prompt für den unvoreingenommenen Blick von oben.
Achte darauf, was du mit der Antwort machst. Ertappst du dich dabei, dem zweiten Modell zu erklären, warum es den Context nicht versteht, ist das meist ein Zeichen, dass der Entwurf etwas voraussetzt, das er nie laut ausspricht. Und das ist gut zu wissen, bevor es jemand anderes liest.
Veröffentlicht: 2026-08-05
Zuletzt aktualisiert: 2026-08-05