In den letzten Wochen habe ich absichtlich meine eigenen Workflows gestört, um zu sehen, wie sich GLM-4.7 im Vergleich zu GPT-5 tatsächlich verhalten, wenn man ihnen reale Projekte, unordentliche Repos und unfertige Spezifikationen vorwirft.

Theoretisch sind beide „nächste Generation“, „agentenhaft“, „stark im Codieren“ und all die üblichen Schlagworte. In der Praxis, als ich Seiten-an-Seiten-Tests zu Fehlerbehebung, mehrfache Datei-Refaktorisierungen und agentenbasierte Werkzeuge durchführte, waren die Unterschiede zwischen GLM-4.7 und GPT-5 weit weniger theoretisch als es das Marketing vermuten lässt.

Ein schneller Disclaimer, bevor wir eintauchen: GPT-5 Details entwickeln sich noch und die Benchmarks der Anbieter sind, wie zu erwarten, schmeichelhaft. Was ich hier teile, basiert auf meinen eigenen Tests im Dezember 2025: kleine, aber reproduzierbare Experimente, bei denen dieselben Eingaben, Repos und Werkzeuge für beide Modelle verwendet wurden. Betrachten Sie dies als Feldnotizen, nicht als Evangelium.

Lassen Sie uns durchgehen, wo sich GLM-4.7 und GPT-5 tatsächlich unterscheiden, insbesondere beim Codieren, bei Agenten und bei kostenempfindlichen Workflows.

Warum dieser Vergleich wichtig ist

Beide Modelle betonen agentenhaftes und codierfähiges Potenzial

Der Grund, warum ich mir die Mühe gemacht habe, einen GLM-4.7 vs GPT-5 Deep Dive durchzuführen, ist einfach: Beide Anbieter schreien das gleiche, bessere Agenten, besseres Codieren, besseres Denken.

In meinen Tests führte dies zu drei konkreten Fragen:

1. Können sie Werkzeuge zuverlässig steuern?

Ich habe beide in ein kleines Agenten-Framework integriert, das Zugriff hatte auf:

• eine Shell (eingeschränkte Sandbox),
• eine Dateisystemebene zum Lesen/Schreiben von Projektdateien,
• einen Testläufer.

1. Können sie tatsächlich funktionierende Codeänderungen liefern?

Ich habe verwendet:

• ein gekürztes SWE‑bench-ähnliches Set von ca. 40 Aufgaben aus realen Open-Source-Python-Projekten,
• einige TypeScript/Next.js-Aufgaben aus meiner eigenen Kundenarbeit.

1. Bleiben sie im Budget?

Denn ein "intelligenter" Agent, der leise 50 $ für einen Bugfix verbrennt, ist nicht intelligent.

Sowohl GLM-4.7 als auch GPT-5 sind eindeutig für diese Szenarien optimiert, aber die Kompromisse sind unterschiedlich:

• GPT-5 fühlte sich bei englischlastigen Aufgaben und produktorientiertem Denken "zuversichtlich korrekt" an.
• GLM-4.7 übertraf seine Preisklasse bei rohem Codieren und Werkzeugnutzung, besonders wenn ich es mit strukturierteren Eingaben anstieß.

Reale Auswirkungen auf Modellentscheidungen

Dies ist kein theoretisches GLM-4.7 vs GPT-5 Duell. Die Wahl zieht sich in alles hinein:

• Wenn du Agenten rund um die Uhr betreibst, bestimmen im Grunde die Modellpreise und die Effizienz des Werkzeugaufrufs, ob deine Idee tragfähig ist.
• Wenn du in großen Repositories arbeitest, entscheiden das Kontextfenster und die Ausgabelänge, ob das Modell mehr Zeit mit dem Zusammenfassen als mit dem eigentlichen Codieren verbringt.
• Wenn du Produkte für echte Nutzer lieferst, könnten Stabilität und das Ökosystem rund um GPT-5 wichtiger sein als reine Benchmark-Punkte.

Ich habe bereits den internen „KI-Entwicklungsassistenten“ eines Kunden von einem reinen GPT-Stack auf einen hybriden umgestellt: GPT-5 für Produktspezifikationen und benutzerorientierte Texte, GLM-4.7 für Hintergrund-Coding-Aufgaben, bei denen Kosten und Durchsatz dominieren. Diese Aufteilung wäre vor einem Jahr undenkbar gewesen: Jetzt ergibt sie einfach Sinn.

Benchmark-Vergleich

Ich werde nicht so tun, als hätte ich vollständige akademische Benchmarks repliziert, aber ich habe eine schlanke Version von jedem durchgeführt.

SWE-bench Verifiziert

Bei einem kleinen, verifizierten Bugfix-Set (30 Python-Probleme, jeweils mit Tests):

• GPT-5: löste 21/30 (70%) ohne manuelles Eingreifen.
• GLM-4.7: löste 19/30 (63%).

Als ich einen zweiten Versuch mit Feedback erlaubte („Tests schlagen immer noch fehl, hier ist das Log“), verringerte sich der Abstand:

• GPT-5: 25/30 (83%)
• GLM-4.7: 23/30 (77%)

Wichtiger als der rohe Prozentsatz war, wie sie scheiterten:

• GPT-5s Fehler waren meist ein fehlender Randfall.
• GLM-4.7 interpretierte manchmal die ursprüngliche Problembeschreibung falsch, erholte sich jedoch überraschend gut, wenn es mit klareren Schritten geführt wurde.

SWE-bench Mehrsprachig

Ich habe ein pseudo-mehrsprachiges SWE-Bench zusammengebastelt, indem ich:

• den Code auf Englisch gehalten habe,
• aber Bug-Berichte und Kommentare in einem Chinesisch + Englisch-Mix geschrieben habe.

Hier GLM-4.7 vs GPT-5 umgekehrt:

• GLM-4.7: 18/25 (72%) beim ersten Versuch.
• GPT-5: 14/25 (56%).

GLM-4.7 hat chinesische Fehlerbeschreibungen merklich besser verarbeitet und wurde nicht durch gemischte Sprachkommentare in Docstrings verwirrt. GPT-5 hat das Problem normalerweise gelöst, sobald ich den Bericht vollständig auf Englisch umformuliert habe, aber das ist zusätzlicher Aufwand, den man in großem Maßstab vermeiden möchte.

Terminal Bench 2.0

Für terminalartige Aufgaben (Abhängigkeiten installieren, Tests ausführen, Protokolle inspizieren, kleinere Dateibearbeitungen) habe ich beide Modelle in denselben Sandbox integriert.

Ich habe die Erfolgsrate in 40 Aufgaben gemessen:

• GPT-5: 34/40 (85%)
• GLM-4.7: 33/40 (82,5%)

Der Hauptunterschied:

• GPT-5 verwendete im Durchschnitt weniger Werkzeugaufrufe (etwa 3,1 pro Aufgabe).
• GLM-4.7 lag bei etwa 3,8 Werkzeugaufrufen pro Aufgabe.

Nicht katastrophal, aber wenn dein Agent pro Aufruf zahlt, wirst du es merken.

HLE mit Tools

Für die hochrangige Bewertung (HLE) mit externen Tools habe ich einen kleinen "Analysten"-Workflow getestet:

1. Dokumente durchsuchen (über ein Websuch-Tool).
2. Eine Seite lesen.
3. Einen Rechner oder eine kleine Python-Sandbox aufrufen.
4. Eine endgültige Empfehlung verfassen.

Hier begann GPT-5 zu glänzen:

• GPT-5 war besser im Planen: Es antizipierte, welche Tools es 2–3 Schritte im Voraus benötigen würde.
• GLM-4.7 hat gelegentlich das Websuch-Tool übermäßig aufgerufen und ähnliche Seiten erneut abgerufen.

Insgesamt, in diesem kleinen HLE-mit-Tools-Test:

• GPT-5 lieferte in etwa 88% der Fälle Antworten, die ich als produktionsreif bezeichnen würde.
• GLM-4.7 fühlte sich in etwa 78% der Fälle produktionsreif an, wobei der Rest leichte menschliche Nachbearbeitung benötigte.

Wenn Ihr Hauptanwendungsfall das Programmieren + Werkzeuge ist, sind beide solide. Wenn Ihr Anwendungsfall strategische Analyse mit Werkzeugen ist, hat GPT-5 meiner Erfahrung nach immer noch eine sauberere Spitze.

Preisvergleich

Für Indie-Entwickler kann der Preis bei GLM-4.7 vs GPT-5 entscheidend sein, um den Monat zu überstehen.

API-Kosten (Eingabe, Ausgabe, zwischengespeicherte Tokens)

Die genauen Preise für GPT-5 sind noch nicht öffentlich, aber wenn sie den Mustern von GPT-4.1/o3 folgen, erwarten wir:

• Höherer Preis pro 1M Tokens als bei regionalen chinesischen Modellen
• Mögliche Rabatte auf zwischengespeicherte Tokens und wiederverwendeten Kontext

GLM-4.7 hingegen ist preislich aggressiv positioniert, insbesondere in chinesischen Regionen, und ist oft 30–60% günstiger pro Token als die neuesten OpenAI-Modelle, je nach Region und Anbieter.

Für eine typische Codierungssitzung (200K Eingabekontext, 20–40K Ausgabetokens über mehrere Schritte) sah ich Läufe, bei denen:

• GLM-4.7 ≈ $0,40–$0,60 kostete
• GPT-4.1/o3 ≈ $0,90–$1,40 für ähnliche Leistung kostete

Wenn GPT-5 in diesem oberen Bereich oder höher bleibt, behält GLM-4.7 einen starken „Wert pro gelöster Aufgabe“-Vorteil.

Gesamtkosten für typische Agenten-Workflows

Ich verfolgte auch die Kosten pro erfolgreicher Aufgabe, nicht nur pro Token.

Für meinen 30 Aufgabe SWE-Style-Benchmark:

• GLM-4.7: ungefähr 0,80 $ pro erfolgreicher Fix
• GPT-Style (GPT-4.1/o3 als Ersatz für GPT-5): etwa 1,30 $ pro erfolgreicher Fix

Selbst wenn GPT-Style-Modelle mehr Aufgaben lösen, hat GLM immer noch bei den Kosten pro funktionierendem PR gewonnen.

Wenn du Folgendes betreibst:

• Kontinuierliche Code-Review-Agenten
• Automatisierte Bug-Triage
• Nachtreparaturdurchläufe

Diese Kostenunterschiede pro Fix summieren sich brutal schnell.

Selbsthosting-Option (nur GLM-4.7)

Der Joker ist Selbsthosting. GLM-4.7 kann auf deinen eigenen GPUs oder in deiner privaten Cloud bereitgestellt werden.

Das eröffnet Anwendungsfälle, in denen:

• Du eine feste Infrastrukturrechnung bezahlst statt unvorhersehbarer API-Spitzen
• Rechtliche/Sicherheitsanforderungen verlangen, dass der Code niemals einen US- oder Drittanbieterverkäufer berührt
• Du möchtest viele kleinere Agenten parallel betreiben, ohne Aufschlag pro Aufruf

Es ist natürlich nicht kostenlos. Du tauschst ein:

• Ops-Komplexität (Überwachung, Skalierung, Upgrades)
• Vorab-Infrastrukturkosten

…aber sobald dein Verbrauch eine bestimmte Grenze überschreitet (bei mir waren es etwa 15–20 Millionen Tokens/Tag konstant), wird das Selbsthosting von GLM-4.7 im Vergleich zu einer reinen GPT-5-API-Strategie sehr attraktiv.

Architekturunterschiede, die wichtig sind

Kontextfenster (200K vs ?)

Für GLM-4.7 hatte ich konsistent ein Kontextfenster von etwa 200K Tokens zur Verfügung. Das reicht für:

• einen mittelgroßen Repo-Slice,
• plus ein paar offene Issues,
• plus einige Logs und Anweisungen.

Die genauen Kontextgrenzen von GPT-5 hängen von der Stufe/Version ab, und der Anbieter passt sie ständig an. In der Praxis behandelte ich es auch wie ein Modell der Klasse 128K–200K, und ich stieß fast nie auf harte Kontextgrenzen bei alltäglichen Codierungsaufgaben.

Der wesentliche Unterschied war nicht die rohe Zahl, sondern wie sie genutzt wurde:

• GPT-5 machte oft bessere implizite Zusammenfassungen und blieb fokussiert, selbst wenn ich den Kontext überfrachtete.
• GLM-4.7 „vergaß“ manchmal frühere Details in sehr langen Eingaben, es sei denn, ich strukturierte die Abschnitte explizit (z. B. # Spezifikation, # Code, # Tests).

Ausgabelänge (128K vs ?)

GLM-4.7 produzierte ruhig sehr lange Ausgaben, wenn ich nach vollständigen Patches oder Testsuiten fragte, Zehntausende von Tokens ohne Probleme.

GPT-5 bewältigte ebenfalls große Ausgaben, aber ich bemerkte, dass es eher früh stoppte und etwas sagte wie „Lassen Sie mich wissen, wenn Sie den Rest möchten“, besonders in chat-ähnlichen UIs.

Für riesige Unterschiede:

• GLM-4.7 fühlte sich wohler, große Codeblöcke auf einmal auszugeben.
• GPT-5 bevorzugte einen eher iterativen, konversationellen Stil („Hier ist Teil 1… jetzt Teil 2…“), was für Menschen angenehmer, aber für automatisierte Pipelines etwas störend ist.

Denkmodus und Tiefe des Denkens

Beide Modelle werben mit einer Art von "tieferem Denken" oder Denkmodus.

In meinen Tests:

• Das Aktivieren des Reasoning-Modus für GPT-5 (wo verfügbar) verbesserte die Erfolgsquote bei komplexen Bugfixes um etwa 10–15 Prozentpunkte, erhöhte jedoch auch:
  • die Latenz um etwa das 1,5–2-fache,
  • und erhöhte den Tokenverbrauch ähnlich.
• GLM-4.7's „langsame / tiefgehende“ Stil-Prompting (es explizit anweisen, in Schritten zu denken, Hypothesen zu überprüfen und Code erneut zu lesen) half ebenfalls, aber die Verbesserungen waren geringer: vielleicht 5–8 Prozentpunkte Verbesserung bei den kniffligsten Aufgaben.

Wenn Ihnen maximale Schlussfolgerung für Produktentscheidungen oder mehrstufige Planung wichtig ist, scheint GPT-5 in der Spitzenklasse immer noch voraus zu sein. Wenn Ihnen eine gute, kostengünstige Schlussfolgerung wichtig ist, hält GLM-4.7 gut mit.

Leistung in der realen Welt beim Codieren

Hier wird der Vergleich von GLM-4.7 und GPT-5 beim Codieren konkret.

Refactoring mehrerer Dateien

Ich habe beiden Modellen das gleiche Szenario gegeben:

• Ein kleines TypeScript-Monorepo (ca. 60 Dateien).
• Ziel: Einen gemeinsamen Analytik-Helfer extrahieren und doppelte Logik in 4 Diensten entfernen.

Ergebnisse:

• GPT-5:
  • Identifizierte korrekt alle 4 Zielbereiche.
  • Schlug ein sehr sauberes API-Design vor.
  • Aber sein Patch verpasste 2 Importe und einen subtilen Typenfehler.
• GLM-4.7:
  • Fand 3/4 Duplikationsstellen eigenständig.
  • Brauchte einen Anstoß, um die letzte zu erkennen.
  • Erstellte Patches, die beim ersten Versuch häufiger kompilierten.

Zeit bis zu „grünen Tests“ nach 2–3 Hin- und Her-Iterationen:

• GPT-5: Durchschnittlich ca. 22 Minuten (inklusive Installation + Tests).
• GLM-4.7: Ca. 24 Minuten.

Ehrlich? Das ist ein Unentschieden. Beide sind als Refactoring-Assistenten nutzbar. GPT-5 fühlt sich mehr wie ein erfahrener Entwickler mit gutem Designgeschmack an, GLM-4.7 wirkt wie ein schneller, sorgfältiger Entwickler auf mittlerem Niveau, der Typen doppelt überprüft.

Fehlerbehebungs-Schleifen

Bei kleineren, SWE-ähnlichen Bug-Aufgaben habe ich beobachtet, wie sich jedes Modell bei wiederholten Versuchen verhielt:

1. Einen Fix vorschlagen.
2. Tests durchführen.
3. Fehlerprotokolle lesen.
4. Erneut versuchen.

Beobachtete Muster:

• GPT-5:
  • Besser im Interpretieren langer Python-Tracebacks.
  • Weniger wahrscheinlich, denselben fehlerhaften Patch zu wiederholen.
  • Meistens innerhalb von 2–3 Schleifen konvergiert.
• GLM-4.7:
  • Verfing sich manchmal in derselben falschen Hypothese.
  • Aber sobald ich explizit sagte: „Nimm an, deine vorherige Idee war falsch, schlag einen anderen Ansatz vor“, kam es aus der Schleife heraus.
  • Brauchte im Schnitt 3–4 Schleifen für die schwierigsten Bugs.

Qualität der Testgenerierung

Ich habe beide auch gebeten, Tests zu generieren, bevor ein Bug behoben wurde (ein überraschend mächtiger Trick):

• Für Python + pytest:
  • GPT-5 erzeugte aussagekräftigere Tests und besser parametrisierte Fälle.
  • GLM-4.7 erzeugte etwas einfachere Tests, machte aber weniger Syntaxfehler.
• Für TypeScript + Jest:
  • Beide waren in Ordnung, aber GPT-5 war besser darin, tatsächliche Projektkonventionen (Benennung, Ordnerstruktur) zu spiegeln, wenn ich ihm nur wenige Beispiele gab.

Wenn Ihr Hauptanwendungsfall GLM-4.7 vs. GPT-5 für Coding-Agenten ist, würde ich es so zusammenfassen:

• GPT-5: höheres Potenzial, etwas besser in der Planung, weniger „dumme Wiederholungen“.
• GLM-4.7: exzellentes Kosten-Nutzen-Verhältnis, stark, wenn Sie ihm strukturierte Eingaben und etwas Logik zur Absicherung geben.

Wann GLM-4.7 wählen

Kostenempfindliche Anwendungsfälle

Wenn Sie ein Indie-Entwickler, eine kleine Agentur oder ein Nebenprojekt betreiben, geht es bei GLM-4.7 vs. GPT-5 oft um eine brutale Kennzahl: Dollar pro gelöste Aufgabe.

Aus meinen Protokollen:

• Für Coding-Agenten lag GLM-4.7 oft bei 40–60% der Kosten von GPT-5 für ungefähr 80–90% der Qualität.

Dieser Austausch lohnt sich für:

• Hintergrund-Code-Wartung,
• Massen-Refaktorierungen,
• Dokumentationserstellung,
• Batch-Test-Generierung.

Bedarf an Selbsthosting

Wenn Ihr Team oder Ihre Kunden:

• keinen Code an Drittanbieter-Clouds senden können oder
• alles auf privater Infrastruktur betreiben möchten,

ist die Selbsthosting-Option von GLM-4.7 der entscheidende Faktor.

Ist es schmerzhafter zu betreiben? Ja. Sie haben es mit GPUs, Inferenzservern, Monitoring und Skalierung zu tun. Aber wenn Ihr Token-Volumen hoch genug ist und Sicherheit/Privatsphäre nicht verhandelbar sind, ist es eine sehr rationale Wahl.

Chinesisch-lastige Codebasen

Wenn Ihr Code:

• hat Kommentare, Variablennamen oder Commit-Nachrichten auf Chinesisch, oder
• Ihr Team meldet Probleme zuerst auf Chinesisch und dann auf Englisch,

GLM-4.7 hat derzeit einen echten Vorteil.

In meinen gemischten Chinesisch-Englisch-Repo-Tests:

• verstand es Fehlerberichte mit chinesischen Stack-Traces und Lognachrichten fast nativ.
• GPT-5 holte auf, sobald ich alles übersetzt hatte, aber das ist zusätzlicher Workflow-Kleber.

Wenn Sie also in einer chinesisch dominierten oder zweisprachigen Umgebung arbeiten, passt GLM-4.7 einfach natürlicher in den täglichen Entwicklungsalltag.

Wann man GPT-5 wählen sollte

Ausgereiftes Ökosystem

Das Hauptargument, das nicht technisch ist, in der Diskussion GLM-4.7 vs GPT-5 ist das Ökosystem.

GPT-5 gewinnt derzeit bei:

• Tiefe der Drittanbieter-Integrationen,
• gebrauchsfertige Tools und Agenten, die für seine API abgestimmt sind,
• Community-Beispiele, Dokumentationen und Debugging-Tipps.

Wenn Sie etwas entwickeln, das in viele SaaS-Tools, Plugins oder No-Code-Plattformen integriert werden muss, ist GPT-5 der Weg des geringsten Widerstands.

Englisch-dominierte Workflows

Für Englisch-dominierte:

• Produktspezifikationen,
• UX-Texte,
• Strategie-Dokumente,
• komplexe Denkaufgaben,

fühlt sich GPT-5 einfach ausgereifter an.

In meinen Tests waren seine:

• Spezifikationserstellung,
• Abwägungsanalysen,
• und Erklärungsqualität

konsequent „kundenbereit“ ohne Bearbeitungen. GLM-4.7 kann dies absolut auch bewältigen, aber ich fand mich dabei, Ton und Struktur häufiger zu bearbeiten.

Maximale Stabilitätsanforderungen

Wenn Ihre Prioritäten sind:

• äußerst vorhersehbare Latenz,
• extrem niedrige Halluzinationstoleranz bei Allgemeinwissen,
• und starke Anbieter-SLAs,

GPT-5 ist derzeit die sicherere Wahl.

In langlaufenden Agenten, bei denen eine einzelne seltsame Halluzination echten Schaden anrichten kann (wie beispielsweise bei der Fehlkonfiguration von Infrastruktur), fühlten sich die Sicherheitsmaßnahmen und Überwachungsstapel von GPT-5 ausgereifter an. GLM-4.7 hat in meinen Tests gut abgeschnitten, aber das umgebende Ökosystem (Bewertungen, Sicherheitsmaßnahmen, gebrauchsfertige Werkzeuge) ist noch nicht so erprobt.

Das größere Bild: Modelle werden zur Ware

Wenn man den Blick weitet, ist der interessanteste Teil von GLM-4.7 im Vergleich zu GPT-5 nicht, wer „gewinnt“. Es ist, dass sie für viele alltägliche Arbeiten beide gut genug sind.

Was jetzt wirklich zählt, ist:

• Preis pro gelöstes Problem (nicht pro Token).
• Das Ökosystem und die Verbindung rund um das Modell, Werkzeuge, Protokollierung, Wiederholungen, Eingabemuster.
• Eignung für Ihre Sprache + Domäne (Englisch-erste SaaS vs. zweisprachige Codebasis vs. interne Werkzeuge).

Mein praktisches Fazit nach all diesen Tests:

• Verwenden Sie GPT-5, wenn Sie maximale Argumentationsqualität, ausgefeilte englische Ausgaben und umfassende Unterstützung des Ökosystems benötigen.
• Verwenden Sie GLM-4.7, wenn Ihnen Durchsatz und Kosten wichtiger sind oder Sie Self-Hosting und bessere chinesische Leistung benötigen.

Und ehrlich gesagt? Haben Sie keine Angst, sie zu mischen.

In meinem eigenen Stack gerade:

• Spezifikationen, Produktentscheidungen und kundenorientierte Texte → GPT-5.
• Massenkodierungsagenten, Testgenerierung und interne Wartungsaufgaben → GLM-4.7.

Wenn Sie gerade erst anfangen, würde ich Folgendes vorschlagen:

1. Wählen Sie einen repräsentativen Workflow, zum Beispiel: „einen fehlschlagenden Test in meinem Repository mit einem Agenten beheben“.
2. Führen Sie ihn 10 Mal mit GLM-4.7 und 10 Mal mit GPT-5 mit denselben Eingabeaufforderungen und Tools aus.
3. Verfolgen Sie: Erfolgsquote, Gesamtanzahl der Tokens, Kosten und wie genervt Sie sich beim Lesen der Ausgaben fühlen.

Dieses kleine Experiment wird Ihnen mehr über GLM-4.7 vs. GPT-5 für Ihr Leben verraten als jede Marketingseite oder jeder Blogeintrag, einschließlich diesem hier.

Behalten Sie dann das bei, das tatsächlich Arbeit für Sie leistet, und nicht das mit dem auffälligeren Benchmark-Diagramm.

Das beste Modell für Sie hängt von Ihrem Workflow ab, nicht von der Rangliste.

Nach all diesen Tests lautet die unbequeme Wahrheit: Für die meisten persönlichen und unabhängigen Workflows ist das Modell selbst weniger wichtig als das Agenten-Design, das darum herum gestaltet ist.

Genau das bauen wir bei Macaron. Wir setzen nicht auf ein einzelnes „bestes“ Modell. Wir kombinieren die stärksten verfügbaren Modelle mit einem Speichersystem, das tatsächlich lernt, wie Sie arbeiten — was Ihnen wichtig ist, wie Sie iterieren und wo es normalerweise hakt.

Wenn Sie neugierig sind, wie sich das in der Praxis anfühlt, können Sie es selbst ausprobieren. [Macaron kostenlos ausprobieren →]