Bildung zu verkaufen hat das beste Kosten-Nutzen-Verhältnis. Es gibt keine Verantwortung, nur Rechnungsstellung. KI wird einen großen Anteil an diesem Geschäft einnehmen.
Punkt 3 (die Trennung der Zuständigkeiten zwischen Agenten) scheint mir der schwierigste Teil zu sein. Ich habe mir einmal einige öffentliche Benchmark-Traces genauer angesehen und möchte ein Muster teilen, das mir dort aufgefallen ist.
Am häufigsten war nicht eine „falsche Entscheidung“, sondern dass dieselbe Aufgabe zweimal ausgeführt wurde. Eine E-Mail wurde mit denselben Parametern erneut versendet oder dieselbe Datei noch einmal geschrieben. Das trat besonders oft im Retry-Bereich nach Timeouts auf. Der erste Aufruf war einfach nur langsam, wurde aber als fehlgeschlagen eingestuft und deshalb noch einmal ausgelöst.
Die Nachverfolgung ist deshalb so knifflig, weil kein Fehler auftritt. Beide Aufrufe liefern 200 zurück, und auch die Logs sind sauber, sodass man das im Nachhinein allein in den Logs nicht erkennt.
Unsere Methode ist, nach (Tool, normalisierte Parameter, Output-Hash) zu gruppieren und mechanisch zu zählen, ob dieselbe Kombination wiederholt auftritt. Da das ohne LLM-Urteil und rein rechnerisch funktioniert, ist es reproduzierbar. Die Grenze ist allerdings klar: Man sieht nur, dass „zweimal aufgerufen wurde“, aber nicht, ob es „tatsächlich zweimal ausgeführt wurde“. Bei Tools, die in der Antwort eine Entity-ID zurückgeben (zum Beispiel eine Dokumenterstellungs-API), kann man das durch Vergleich der IDs prüfen. Bei Tools wie E-Mail, die nur „Versand erfolgreich“ zurückgeben, haben wir dafür jedoch keinen Weg gefunden.
Ich kann auch den von Ihnen genannten Punkt 2 nachvollziehen, das „einfach durchlassen, um schnell zu bleiben“. Wir haben ebenfalls geprüft, das in Echtzeit zu blockieren, aber vor der Ausführung sieht man das Ergebnis nicht und muss daher allein anhand der Parameter entscheiden, und die Genauigkeit war niedrig. Es kam vor, dass sogar legitime Retries blockiert wurden, deshalb haben wir es wieder verworfen.
Auch Bugfixes sind sehr günstig geworden, und die Kosten für Software-Updates nähern sich null. Außer vielleicht im Finanzsektor ist es oft so: Wenn es einen Bug gibt, behebt man ihn eben ...
Aber wenn sich diese Haltung verfestigt, führt das am Ende wohl zu einem großen Zwischenfall.
Wenn ihr es ausprobiert und es Gespräche gibt, bei denen Jumpback ins Leere läuft, oder Stellen, bei denen ihr denkt: „Das ist etwas umständlich“, hinterlasst gern einen Kommentar. Da die Gesprächsstruktur je nach Website unterschiedlich ist, helfen reale Anwendungsfälle am meisten. Als Nächstes schaue ich mir Unterstützung für Perplexity sowie den Export nach Notion/Obsidian an, aber wenn es etwas Dringenderes gibt, würde ich das zuerst angehen haha
Vielen Dank. Probieren Sie es gern aus, und wenn es eine Unterhaltung gibt, bei der Jumpback nicht erkannt wird, sagen Sie mir einfach Bescheid~
Ich nutze es auch selbst, aber es wäre schön, wenn ich zusätzlich auch von den Unannehmlichkeiten echter anderer Nutzer hören könnte haha
Es scheint auch möglich, bei jeder Änderung durch einen Agenten das Diff-Log zu beobachten und, wenn dabei Shotgun Surgery oder massenhafte Änderungen entstehen, dies als SE-Code-Smell zu betrachten und darauf Reinforcement Learning anzuwenden ...
[Damit es leichter zu lesen ist, habe ich euch eine koreanische Übersetzung des README aufgeschrieben!]
Clew
Ein deterministischer Detektor, der verschwendete Arbeit in Agent-Trace-Dateien findet.
Clew liest abgeschlossene Ausführungs-Traces von KI-Agenten und findet Schritte, die bereits erledigte Arbeit wiederholen — denselben Aufruf desselben Tools mit denselben Argumenten, Wiederholungen fehlgeschlagener Aufrufe mit identischen Argumenten oder erneutes Abfragen von Informationen, die bereits im Kontext vorhanden sind. Da es ohne LLM-Bewertung arbeitet, liefert derselbe Trace immer dasselbe Ergebnis.
estimated cost impact: $0.026340 ~ $0.263400 (cache-hit to cache-miss)
Warum das wichtig ist
Bei KI-Coding-Agent-Sessions wird Verschwendung nur auf der Rechnung sichtbar. Alle Tool-Aufrufe liefern 200 zurück und nichts wirft einen Fehler, deshalb ist die Verschwendung nicht direkt erkennbar. Im Trace sieht man aber, dass der Agent dieselbe Datei zweimal liest, fehlgeschlagene Aufrufe mit denselben Argumenten erneut versucht und dasselbe Tool mit derselben Payload noch einmal aufruft.
Da Lesevorgänge in Coding-Agent-Sessions 65–90 % der Tokens ausmachen, summiert sich solche Verschwendung unauffällig. Observability-Tools zeigen zwar den Trace, sagen aber nicht, welche Schritte dupliziert waren.
Was erkannt wird
Clew sucht nach drei Redundanzmustern:
repeat — dasselbe Tool/derselbe Node wird wiederholt aufgerufen
requery — dasselbe Tool wird mit derselben Eingabe erneut aufgerufen (Ausgabe identisch)
pingpong — zwei Agenten tauschen inhaltlich praktisch dasselbe aus (Multi-Agent)
Jeder Fund wird in vier Kategorien eingeordnet:
error_repeat — die Ausgabe ist ein Fehler und derselbe Aufruf wird wiederholt
side_effect — ein zustandsveränderndes Tool (Senden/Schreiben/Erzeugen usw.) wird erneut ausgeführt
idempotent — ein schreibgeschütztes/deklaratives Tool wird wiederholt (keine Nebenwirkungen, aber Token-Verbrauch)
unclassified — Tool nicht im Mapping. Die Wirkung hängt von der Payload ab, daher wird nicht allein aus dem Tool-Namen geschlossen (Bash/PowerShell usw.)
[Wie es funktioniert]
Es ist eine zweistufige Kaskade:
strukturelles Gate — gruppiert Aufrufe desselben Tools mit denselben (normalisierten) Argumenten
Identitäts-Gate — prüft, ob die sha256 der Ausgabe exakt übereinstimmt. Falls nicht, hat sich der Zustand geändert und es wird nichts markiert
Die günstige Strukturprüfung filtert zuerst Kandidaten heraus, und die teure semantische Prüfung (Embeddings + Cosine) wird nur bei Bedarf ausgeführt. Da es keine LLM-Bewertung gibt, sind die Ergebnisse deterministisch — wichtig, wenn man es in CI einsetzen will.
[Eingabeformate]
Claude Code — analysiert Session-JSONL direkt
LangGraph — erkennt Ketten-Redundanz im Trace
LangChain·CrewAI·AutoGen·LlamaIndex usw. — parst instrumentierte Traces im OpenTelemetry/OpenInference-Standardformat (Format wird unterstützt, framework-spezifische Validierung anhand realer Messungen läuft noch)
öffentliche Benchmark-Traces (Toolathlon, RedundancyBench)
Cursor- und Codex-Sessions werden noch nicht unterstützt — lokale Formate werden derzeit geprüft.
[Validierungsergebnisse]
Öffentliche Benchmarks (Toolathlon, 6.780 Traces, 176.270 Tool-Spans):
8.042 redundante Aufrufe erkannt. Davon sind 47 % Grauzone (idempotente Operationen, Abschlusserklärungen); ohne diese bleiben 4.251 Fälle (2,41 % bezogen auf Tool-Spans). Das ist etwa dreimal so viel wie bei Claude-Code-Sessions (0,80 %).
1.343 doppelte Ausführungen zustandsverändernder Tools, darunter 459 wiederholte E-Mail-Sendungen mit denselben Argumenten. Dabei wurde allerdings nur erkannt, dass dasselbe Tool mit denselben Argumenten doppelt aufgerufen wurde; ob tatsächlich Nebenwirkungen auftraten, wurde nicht bestätigt.
Labeling-Benchmark (RedundancyBench):
Precision 0.826 (untere Schätzung für Redundanz innerhalb einer Datei). Ein erheblicher Teil der RB-Labels betrifft dateiübergreifende Redundanz und liegt damit außerhalb des Geltungsbereichs eines auf Sessions ausgelegten Designs. Recall ist mit 0.157 niedrig.
[Ehrliche Grenzen]
Es gibt noch keine gemessenen Einsparungsfälle. Erkennen und schätzen kann man es, aber es gibt 0 Before/After-Datenpunkte von echten Nutzern, die etwas geändert und dadurch ihre Rechnung tatsächlich gesenkt haben.
47 % der auf Benchmarks markierten Fälle sind Grauzone (idempotente Wiederholungsausführungen). Es wird nicht herausgefiltert, sondern nur klassifiziert — denn ob eine schreibgeschützte Wiederholung Verschwendung war, hängt vom nicht sichtbaren Kontext ab.
Da eine exakte sha256-Übereinstimmung verlangt wird, wird schon bei kleinen Unterschieden in der Ausgabe nichts markiert. Daher ist der Recall niedrig; das Design priorisiert Präzision.
Claude Code ist ungewöhnlich gut optimiert. In realen CC-Sessions wurden sechs potenzielle Verschwendungsmuster gemessen, aber fünf davon existierten dort nicht. Interessante Verschwendung zeigte sich nicht in CC selbst, sondern in Multi-Tool-MCP-Umgebungen.
Die Kostenschätzung (amplification) ist keine Messung, sondern eine Schätzung und nur im Claude-Code-Format möglich.
Was nicht validiert ist, wird verworfen
Ich habe einmal einen Detektor für erneutes Dateilesen gebaut, ihn dann aber verworfen, weil die Precision in einer Stichprobe von 30 manuell annotierten Fällen deutlich unter dem vorab registrierten Schwellenwert (70 %) lag (großzügig gerechnet 3,3 %, streng gerechnet 0 %). Vorhersagen und Ergebnisse habe ich zusammen im Vorregistrierungsdokument festgehalten.
Update vom Autor. Ich habe einen separaten Beitrag zu dem MCP-Server veröffentlicht, der im Text nur in einer Zeile erwähnt wurde — es geht um eine Struktur, die das Problem löst, dass Agents beim Schreiben von Migrationen Spaltennamen willkürlich vergeben, indem der physische Name nicht „eingegeben“, sondern auf Basis eines Wörterbuchs „berechnet“ wird: https://sqemo.com/blog/erd-mcp-server
(Noch nur lokal über stdio, daher keine Unterstützung für Remote-MCP; die App selbst ist nicht öffentlich, nur der MCP-Server ist offen).
Man kann es ohne Registrierung direkt ausprobieren (app.sqemo.com). Wenn euch etwas auffällt, schreibt bitte einen Kommentar — es ist noch früh, daher wird Feedback direkt berücksichtigt.
Seit dem ersten Beitrag habe ich Repolis weiter von einem einfachen 3D-Repo-Browser zu einem kleinen Dorf ausgebaut, zu dem man einen Grund hat, wiederzukommen.
GitHub Traffic und öffentliche Repo-Informationen fließen täglich in Gebäude und nächtliche Beleuchtung ein.
Starlight Row mit 8 Bewohnern und ihren jeweiligen Häusern wurde ergänzt, dazu Tag-/Nacht-Routinen sowie kurze Spaziergänge und Interaktionen der Bewohner.
Mit Explorer Passport, Village Chronicle und Town Gazette lassen sich Besuchsverläufe sowie neue Repos, Releases, Pushes und Metrikänderungen fortlaufend verfolgen.
Der mit dem threejs-sculpt-dna Copilot plugin erzeugte prozedurale World Tree wurde in der tatsächlichen Repolis-Stadt platziert.
Standardmäßig ist es weiterhin eine zero-build static app ohne Backend- und Key-Pflicht; nur die grounded AI taxi/scholar-Funktionen sind optional.
Statt einen neuen Beitrag zu erstellen, werde ich auch spätere Änderungen weiter in den Kommentaren dieses Originalbeitrags festhalten.
Auf der koreanischen Mac-Tastatur lässt er sich nicht eingeben. Claude verwendet ihn in seinen Antworten ziemlich oft, aber für koreanische Nutzer ist er ungewohnt ...
Ich bin der Autor. Ein paar Ergänzungen, die ich im Haupttext nicht unterbringen konnte —
· Das Demo-Video (Freigabe-Flow auf dem Smartphone, dreigeteilte Command-Center-Ansicht auf dem Desktop) gibt es als echte Bildschirmaufzeichnung auf der Landingpage: adhf.dev
· Self-Hosting ist mit einer einzigen Zeile erledigt: npm i -g adhdev, danach erscheint das Dashboard unter localhost:3847 (kein Account erforderlich)
· Fragen zum Design sind willkommen, etwa zur ff-only-Merge-Architektur oder dazu, was die MAGI-Kreuzvalidierung in der Praxis tatsächlich erkennt
Heutzutage spricht man nicht mehr von technischer Schuld, sondern von kognitiver Schuld.
Wenn ich mich gelegentlich mit Kollegen unterhalte, sehe ich oft, dass sie selbst bei Dingen, die sie gebaut haben, nicht richtig verstehen, wie sie funktionieren – das ist schon ein wenig gruselig.
Wenn mit der Zeit niemand mehr versteht, wie etwas funktioniert, könnte man es ja von einer KI analysieren lassen und sie fragen; vielleicht ist das dann gar kein Problem.
Bildung zu verkaufen hat das beste Kosten-Nutzen-Verhältnis. Es gibt keine Verantwortung, nur Rechnungsstellung. KI wird einen großen Anteil an diesem Geschäft einnehmen.
Ich glaube, ich habe das vor ein paar Jahren gesehen.
Wenn man auf die Originalseite geht, wird es dort mit Bildern erklärt, sodass es intuitiv leicht zu verstehen ist.
Es wird besser, wenn man mehr Offline-Aktivitäten wie Spazierengehen oder Lesen einbaut. Haha
Punkt 3 (die Trennung der Zuständigkeiten zwischen Agenten) scheint mir der schwierigste Teil zu sein. Ich habe mir einmal einige öffentliche Benchmark-Traces genauer angesehen und möchte ein Muster teilen, das mir dort aufgefallen ist.
Am häufigsten war nicht eine „falsche Entscheidung“, sondern dass dieselbe Aufgabe zweimal ausgeführt wurde. Eine E-Mail wurde mit denselben Parametern erneut versendet oder dieselbe Datei noch einmal geschrieben. Das trat besonders oft im Retry-Bereich nach Timeouts auf. Der erste Aufruf war einfach nur langsam, wurde aber als fehlgeschlagen eingestuft und deshalb noch einmal ausgelöst.
Die Nachverfolgung ist deshalb so knifflig, weil kein Fehler auftritt. Beide Aufrufe liefern 200 zurück, und auch die Logs sind sauber, sodass man das im Nachhinein allein in den Logs nicht erkennt.
Unsere Methode ist, nach (Tool, normalisierte Parameter, Output-Hash) zu gruppieren und mechanisch zu zählen, ob dieselbe Kombination wiederholt auftritt. Da das ohne LLM-Urteil und rein rechnerisch funktioniert, ist es reproduzierbar. Die Grenze ist allerdings klar: Man sieht nur, dass „zweimal aufgerufen wurde“, aber nicht, ob es „tatsächlich zweimal ausgeführt wurde“. Bei Tools, die in der Antwort eine Entity-ID zurückgeben (zum Beispiel eine Dokumenterstellungs-API), kann man das durch Vergleich der IDs prüfen. Bei Tools wie E-Mail, die nur „Versand erfolgreich“ zurückgeben, haben wir dafür jedoch keinen Weg gefunden.
Ich kann auch den von Ihnen genannten Punkt 2 nachvollziehen, das „einfach durchlassen, um schnell zu bleiben“. Wir haben ebenfalls geprüft, das in Echtzeit zu blockieren, aber vor der Ausführung sieht man das Ergebnis nicht und muss daher allein anhand der Parameter entscheiden, und die Genauigkeit war niedrig. Es kam vor, dass sogar legitime Retries blockiert wurden, deshalb haben wir es wieder verworfen.
Auch Bugfixes sind sehr günstig geworden, und die Kosten für Software-Updates nähern sich null. Außer vielleicht im Finanzsektor ist es oft so: Wenn es einen Bug gibt, behebt man ihn eben ...
Aber wenn sich diese Haltung verfestigt, führt das am Ende wohl zu einem großen Zwischenfall.
Wenn ihr es ausprobiert und es Gespräche gibt, bei denen Jumpback ins Leere läuft, oder Stellen, bei denen ihr denkt: „Das ist etwas umständlich“, hinterlasst gern einen Kommentar. Da die Gesprächsstruktur je nach Website unterschiedlich ist, helfen reale Anwendungsfälle am meisten. Als Nächstes schaue ich mir Unterstützung für Perplexity sowie den Export nach Notion/Obsidian an, aber wenn es etwas Dringenderes gibt, würde ich das zuerst angehen haha
Vielen Dank. Probieren Sie es gern aus, und wenn es eine Unterhaltung gibt, bei der Jumpback nicht erkannt wird, sagen Sie mir einfach Bescheid~
Ich nutze es auch selbst, aber es wäre schön, wenn ich zusätzlich auch von den Unannehmlichkeiten echter anderer Nutzer hören könnte haha
Es scheint auch möglich, bei jeder Änderung durch einen Agenten das Diff-Log zu beobachten und, wenn dabei Shotgun Surgery oder massenhafte Änderungen entstehen, dies als SE-Code-Smell zu betrachten und darauf Reinforcement Learning anzuwenden ...
[Damit es leichter zu lesen ist, habe ich euch eine koreanische Übersetzung des README aufgeschrieben!]
Clew
Ein deterministischer Detektor, der verschwendete Arbeit in Agent-Trace-Dateien findet.
Clew liest abgeschlossene Ausführungs-Traces von KI-Agenten und findet Schritte, die bereits erledigte Arbeit wiederholen — denselben Aufruf desselben Tools mit denselben Argumenten, Wiederholungen fehlgeschlagener Aufrufe mit identischen Argumenten oder erneutes Abfragen von Informationen, die bereits im Kontext vorhanden sind. Da es ohne LLM-Bewertung arbeitet, liefert derselbe Trace immer dasselbe Ergebnis.
pip install "clew-custos[detect]"python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.mdBeispiel einer tatsächlichen Ausgabe aus einer öffentlichen Claude-Code-Session:
Result: WASTE DETECTED
1. requery — Read on
.../boot.tsWarum das wichtig ist
Bei KI-Coding-Agent-Sessions wird Verschwendung nur auf der Rechnung sichtbar. Alle Tool-Aufrufe liefern 200 zurück und nichts wirft einen Fehler, deshalb ist die Verschwendung nicht direkt erkennbar. Im Trace sieht man aber, dass der Agent dieselbe Datei zweimal liest, fehlgeschlagene Aufrufe mit denselben Argumenten erneut versucht und dasselbe Tool mit derselben Payload noch einmal aufruft.
Da Lesevorgänge in Coding-Agent-Sessions 65–90 % der Tokens ausmachen, summiert sich solche Verschwendung unauffällig. Observability-Tools zeigen zwar den Trace, sagen aber nicht, welche Schritte dupliziert waren.
Was erkannt wird
Clew sucht nach drei Redundanzmustern:
repeat — dasselbe Tool/derselbe Node wird wiederholt aufgerufen
requery — dasselbe Tool wird mit derselben Eingabe erneut aufgerufen (Ausgabe identisch)
pingpong — zwei Agenten tauschen inhaltlich praktisch dasselbe aus (Multi-Agent)
Jeder Fund wird in vier Kategorien eingeordnet:
error_repeat — die Ausgabe ist ein Fehler und derselbe Aufruf wird wiederholt
side_effect — ein zustandsveränderndes Tool (Senden/Schreiben/Erzeugen usw.) wird erneut ausgeführt
idempotent — ein schreibgeschütztes/deklaratives Tool wird wiederholt (keine Nebenwirkungen, aber Token-Verbrauch)
unclassified — Tool nicht im Mapping. Die Wirkung hängt von der Payload ab, daher wird nicht allein aus dem Tool-Namen geschlossen (Bash/PowerShell usw.)
[Wie es funktioniert]
Es ist eine zweistufige Kaskade:
strukturelles Gate — gruppiert Aufrufe desselben Tools mit denselben (normalisierten) Argumenten
Identitäts-Gate — prüft, ob die sha256 der Ausgabe exakt übereinstimmt. Falls nicht, hat sich der Zustand geändert und es wird nichts markiert
Die günstige Strukturprüfung filtert zuerst Kandidaten heraus, und die teure semantische Prüfung (Embeddings + Cosine) wird nur bei Bedarf ausgeführt. Da es keine LLM-Bewertung gibt, sind die Ergebnisse deterministisch — wichtig, wenn man es in CI einsetzen will.
[Eingabeformate]
Claude Code — analysiert Session-JSONL direkt
LangGraph — erkennt Ketten-Redundanz im Trace
LangChain·CrewAI·AutoGen·LlamaIndex usw. — parst instrumentierte Traces im OpenTelemetry/OpenInference-Standardformat (Format wird unterstützt, framework-spezifische Validierung anhand realer Messungen läuft noch)
öffentliche Benchmark-Traces (Toolathlon, RedundancyBench)
Cursor- und Codex-Sessions werden noch nicht unterstützt — lokale Formate werden derzeit geprüft.
[Validierungsergebnisse]
Öffentliche Benchmarks (Toolathlon, 6.780 Traces, 176.270 Tool-Spans):
8.042 redundante Aufrufe erkannt. Davon sind 47 % Grauzone (idempotente Operationen, Abschlusserklärungen); ohne diese bleiben 4.251 Fälle (2,41 % bezogen auf Tool-Spans). Das ist etwa dreimal so viel wie bei Claude-Code-Sessions (0,80 %).
1.343 doppelte Ausführungen zustandsverändernder Tools, darunter 459 wiederholte E-Mail-Sendungen mit denselben Argumenten. Dabei wurde allerdings nur erkannt, dass dasselbe Tool mit denselben Argumenten doppelt aufgerufen wurde; ob tatsächlich Nebenwirkungen auftraten, wurde nicht bestätigt.
Labeling-Benchmark (RedundancyBench):
Precision 0.826 (untere Schätzung für Redundanz innerhalb einer Datei). Ein erheblicher Teil der RB-Labels betrifft dateiübergreifende Redundanz und liegt damit außerhalb des Geltungsbereichs eines auf Sessions ausgelegten Designs. Recall ist mit 0.157 niedrig.
[Ehrliche Grenzen]
Es gibt noch keine gemessenen Einsparungsfälle. Erkennen und schätzen kann man es, aber es gibt 0 Before/After-Datenpunkte von echten Nutzern, die etwas geändert und dadurch ihre Rechnung tatsächlich gesenkt haben.
47 % der auf Benchmarks markierten Fälle sind Grauzone (idempotente Wiederholungsausführungen). Es wird nicht herausgefiltert, sondern nur klassifiziert — denn ob eine schreibgeschützte Wiederholung Verschwendung war, hängt vom nicht sichtbaren Kontext ab.
Da eine exakte sha256-Übereinstimmung verlangt wird, wird schon bei kleinen Unterschieden in der Ausgabe nichts markiert. Daher ist der Recall niedrig; das Design priorisiert Präzision.
Claude Code ist ungewöhnlich gut optimiert. In realen CC-Sessions wurden sechs potenzielle Verschwendungsmuster gemessen, aber fünf davon existierten dort nicht. Interessante Verschwendung zeigte sich nicht in CC selbst, sondern in Multi-Tool-MCP-Umgebungen.
Die Kostenschätzung (amplification) ist keine Messung, sondern eine Schätzung und nur im Claude-Code-Format möglich.
Was nicht validiert ist, wird verworfen
Ich habe einmal einen Detektor für erneutes Dateilesen gebaut, ihn dann aber verworfen, weil die Precision in einer Stichprobe von 30 manuell annotierten Fällen deutlich unter dem vorab registrierten Schwellenwert (70 %) lag (großzügig gerechnet 3,3 %, streng gerechnet 0 %). Vorhersagen und Ergebnisse habe ich zusammen im Vorregistrierungsdokument festgehalten.
Update vom Autor. Ich habe einen separaten Beitrag zu dem MCP-Server veröffentlicht, der im Text nur in einer Zeile erwähnt wurde — es geht um eine Struktur, die das Problem löst, dass Agents beim Schreiben von Migrationen Spaltennamen willkürlich vergeben, indem der physische Name nicht „eingegeben“, sondern auf Basis eines Wörterbuchs „berechnet“ wird:
https://sqemo.com/blog/erd-mcp-server
(Noch nur lokal über stdio, daher keine Unterstützung für Remote-MCP; die App selbst ist nicht öffentlich, nur der MCP-Server ist offen).
Man kann es ohne Registrierung direkt ausprobieren (app.sqemo.com). Wenn euch etwas auffällt, schreibt bitte einen Kommentar — es ist noch früh, daher wird Feedback direkt berücksichtigt.
Update-Verlauf (2026-07-25)
Seit dem ersten Beitrag habe ich Repolis weiter von einem einfachen 3D-Repo-Browser zu einem kleinen Dorf ausgebaut, zu dem man einen Grund hat, wiederzukommen.
Statt einen neuen Beitrag zu erstellen, werde ich auch spätere Änderungen weiter in den Kommentaren dieses Originalbeitrags festhalten.
Live: https://hyeonsangjeon.github.io/Repolis/
Source: https://github.com/hyeonsangjeon/Repolis
Auf der koreanischen Mac-Tastatur lässt er sich nicht eingeben. Claude verwendet ihn in seinen Antworten ziemlich oft, aber für koreanische Nutzer ist er ungewohnt ...
Bei mir wurde es auch ausgerollt, also habe ich es ausprobiert … hm, Koreanisch wird aber leider noch nicht unterstützt :(
Ich bin der Autor. Ein paar Ergänzungen, die ich im Haupttext nicht unterbringen konnte —
· Das Demo-Video (Freigabe-Flow auf dem Smartphone, dreigeteilte Command-Center-Ansicht auf dem Desktop) gibt es als echte Bildschirmaufzeichnung auf der Landingpage: adhf.dev
· Self-Hosting ist mit einer einzigen Zeile erledigt:
npm i -g adhdev, danach erscheint das Dashboard unter localhost:3847 (kein Account erforderlich)· Fragen zum Design sind willkommen, etwa zur ff-only-Merge-Architektur oder dazu, was die MAGI-Kreuzvalidierung in der Praxis tatsächlich erkennt
Wenn Sie Feedback haben, setze ich es direkt um.
Ich hatte eigentlich auf GPT-6 gehofft … nachdem Opus 5 erschienen ist, sollte da nicht ein neues Modell kommen?
Heutzutage spricht man nicht mehr von technischer Schuld, sondern von kognitiver Schuld.
Wenn ich mich gelegentlich mit Kollegen unterhalte, sehe ich oft, dass sie selbst bei Dingen, die sie gebaut haben, nicht richtig verstehen, wie sie funktionieren – das ist schon ein wenig gruselig.
Wenn mit der Zeit niemand mehr versteht, wie etwas funktioniert, könnte man es ja von einer KI analysieren lassen und sie fragen; vielleicht ist das dann gar kein Problem.
Solche Artikel mag ich sehr.
Für Inferenz ist das ein absoluter Jackpot.
Interessante Idee. Danke für die Antwort.