AI Lab

Fünf visuelle Metaphern für das Portfolio-Redesign ausprobiert: Vintage-Transit-Poster, Mission-Control-Panel, Bibliothek, Abfahrtstafel / U-Bahn-Plan und minimalistisches Swiss Design. Jede hatte einen Aufhänger. Vier sind in der Umsetzung auseinandergefallen. Die Abfahrtstafel / U-Bahn ist geblieben, weil die Metapher über die Bildmarke hinaus bis in die Datenstrukturen gereicht hat: Linien wurden Fall-Kategorien (CS1 = KI, CS2 = Enterprise, P = Persönlich), Stationen wurden einzelne Fälle, Ziel wurde der Fall-Name, Lesezeit wurde die Lesedauer, und die aktuelle Scroll-Position wurde der aktuelle Halt.

Eine durchgehaltene Metapher ist schwerer als eine starke auszuwählen. Die ersten drei, die ich ausprobiert habe, waren visuell markant, aber sind an der Bildmarke stehen geblieben. Die Abfahrtstafel hat funktioniert, weil jede Ebene des Designsystems einen Platz im Vokabular der Metapher hatte. Wenn die Metapher in die Daten reicht, hört sie auf, Dekoration zu sein, und wird zur Navigation.

Vintage-Transit-Poster war schön, las sich aber nostalgisch, nicht professionell. Mission Control war markenkonform für KI, fühlte sich aber wie ein Klischee an. Bibliothek war warm, aber von technischer Arbeit abgekoppelt. Swiss Minimalist ist im Seitenhintergrund verschwunden. Der Test, ob eine Metapher hält: Kann man die Informationsarchitektur einer Fallstudie mit dem Vokabular der Metapher beschreiben, ohne sich zu verbiegen? Abfahrtstafel hat bestanden. Die anderen sind alle an genau diesem Schritt gescheitert.

Visuelle Identität für Portfolios profitiert von einer Metapher, die bis in die Datenstrukturen reicht, nicht nur in das Oberflächen-Styling. Wenn man die wichtigsten Felder seiner Fallstudien nicht in der Sprache der Metapher benennen kann, fällt man auf konventionelle UI-Muster zurück und verliert die Marke.

Eine Abfahrtstafel mit fester Position in der oberen rechten Ecke jeder Seite gebaut. Imitiert die BVG-Abfahrtsanzeige: gelbe Monospace-Schrift im LED-Stil auf Schwarz, deutsche Header-Labels (Linie, Ziel, Lesezeit). Jeder Fall ist ein Halt mit einem Linien-Code, Fall-Namen und Lesezeit. Ein „Aktueller Halt"-Indikator aktualisiert sich dynamisch, während der Besucher scrollt, mittels IntersectionObserver gegen die Fall-Karten auf der Startseite.

Ein Stück UI, das dekorativ aussieht, kann echte Navigationsarbeit leisten, wenn es syntaktisch vertraut ist. Jeder, der mit der U-Bahn gefahren ist, erkennt das Abfahrtstafel-Format sofort. Sie lesen es ohne Anleitung korrekt: Linie, Ziel, Zeit. Die deutschen Labels verwandeln die Metapher von „transit-thematisch" zu „in Berlin verortet". Die Tafel sagt dem Besucher, wo ich bin, ohne „in Berlin ansässig" in den Text zu schreiben.

Die erste Version hat sich bei jedem Scroll-Event aktualisiert, was verschwenderisch und visuell flackerig war. Auf IntersectionObserver gegen die Fall-Karten umgestiegen, was ein sauberes „du bist jetzt bei X"-Signal nur dann erzeugt, wenn eine Karte die Mittellinie des Viewports überquert. Auch versucht, die Tafel mit Bitmap-Pixel-Schrift zu rendern. Sah im Mockup großartig aus, hat aber über Browser hinweg nicht skaliert. Zurück zu einer sauberen Monospace-Webfont mit engem Buchstabenabstand.

Navigationselemente, die dekorativ aussehen, können trotzdem tragend sein. Wenn ein UI-Element vertrauter Infrastruktur ähnelt (ein Thermometer, eine Uhr, eine Abfahrtstafel, ein Wetter-Widget), lesen Nutzer es ohne Anleitung korrekt. Das ist ein Design-Budget, das nichts kostet, sobald man sich auf die Metapher festlegt.

Das alte Portfolio hatte drei Muster, von denen ich annahm, dass ich sie behalten würde. Eine Passwort-Sperre auf Enterprise-Fallstudien (Begründung: NDA-Inhalts-Schutz). Modal-Interaktionen zum Hervorbringen von Service-Kategorien beim Hover (Begründung: die Startseite sauber halten). Eine philosophische Hero-Überschrift „Das Schwerste an Software war schon immer, zu wissen, was zu bauen ist" (Begründung: Tiefe signalisieren). Jedes hatte einen verteidigbaren Fall. Jedes hat schlecht gegen die Redesign-Rubrik abgeschnitten.

Alle drei sind auf dieselbe Weise gescheitert: Sie haben den Besucher zusätzliche Arbeit machen lassen, um herauszufinden, was ich mache. Hiring Manager geben dreißig Sekunden, bevor sie entscheiden, ob sie weiterscrollen. Alles, was in diesem Fenster Reibung einbringt, bezahlt sich mit ihrer Zeit. Das ordnende Prinzip des Redesigns wurde: Die Seite sollte einem Recruiter die Antwort geben, bevor er die Frage stellen muss. Jede Entfernung folgte daraus.

Passwort-Sperren signalisieren „vertrau mir", lesen sich aber als „zeige ich dir nicht". Modals erfordern eine Verpflichtung vor der Enthüllung; Besucher kamen skeptisch an, und Verpflichtung war die falsche Richtung. Philosophische Überschriften schmeicheln dem Autor, zwingen aber den Leser in einem Fünf-Sekunden-Fenster zur Interpretation, in dem er einen Anspruch entgegennehmen sollte. Drei verschiedene Begründungen, derselbe Fehlermodus.

Die Portfolio-Muster, die rausgekürzt werden, sind oft die, die sich klug angefühlt haben. „Klug" heißt meist, dass es Interpretation erfordert, was meist heißt, dass man den beiläufigen Leser verliert. Portfolios sind Artefakte für beiläufige Leser. Spar dir die Interpretationsdichte für die Fallstudien-Bodies, nicht für die Navigation.

Bin einem Obsidian-Vault entwachsen und habe die Pipeline als Next.js-App auf Neon Postgres neu gebaut. Scout scannt Gmail alle 15 Minuten, klassifiziert E-Mails und nutzt Claude Haiku, um Stellenanzeigen gegen mein Profil zu bewerten. Starke Treffer werden automatisch zu Leads. Die Web-App handhabt die visuelle Pipeline mit Unternehmensdetails, Kontakten, Verlauf und einem eingebauten Assistenten namens Jeremy. Ein Erinnerungssystem schickt WhatsApp-Anstöße für überfällige Aktionen.

Der Wechsel zu einer echten Datenbank hat alles freigeschaltet. Sobald die Daten strukturiert waren, konnte jede Automatisierung (Scout, Erinnerungen, Jeremy, Anreicherung) unabhängig andocken. Claude taucht an fünf Stellen in diesem System auf, jede mit einem anderen Modell und einem anderen Zweck. Jeden KI-Touchpoint als eigenes Designproblem zu behandeln, statt als einzelnes „KI hinzufügen"-Feature, ist das, was sie verlässlich gemacht hat.

Bildet jeden KI-Touchpoint als separates Designartefakt ab, mit eigener Modellauswahl, eigenem Prompt und eigenen Bewertungskriterien. E-Mail-Klassifizierung, Job-Bewertung und konversationelle Q&A sind grundlegend unterschiedliche Interaktionsmuster, die zufällig denselben Anbieter teilen.

Einen Wissens-Vault in Obsidian gebaut, speziell für die KI-Zusammenarbeit entworfen. Kernmechanik: ein /wrap-Slash-Command, der am Ende jeder Arbeits-Session ein strukturiertes Debrief fährt, nach Absicht, Entscheidungen und offenen Fragen fragt, dann den Eintrag in ein Session-Log schreibt und automatisch in Git committet. Die Logs sind so strukturiert, dass sie in zukünftigen Sessions von KI synthetisiert werden, nicht nur von Menschen gelesen. Der Vault ist seitdem zur Wissensebene für ein größeres System geworden: Unternehmens- und Kontaktnotizen fließen in die Web-App, Session-Logs erhalten Design-Begründungen über Tools hinweg, und ein WhatsApp-Assistent kann Vault-Dateien über Google Drive lesen und schreiben.

Das Wertvollste zum Festhalten ist nicht, was du gebaut hast; es ist, warum du es gebaut hast und worüber du dir unsicher warst. Git verfolgt das Was. Das Session-Log verfolgt das Warum. Beides im selben System zu halten, gemeinsam versioniert, heißt, dass man die Begründung hinter jeder Entscheidung Wochen später rekonstruieren kann. Struktur reduziert Reibung: Das Debrief zu einem Slash-Command zu machen heißt, dass es tatsächlich passiert. Der Vault hat sich auch als Fundament-Ebene bewährt. Als die Pipeline in eine Datenbank umgezogen ist, ist der Vault nicht obsolet geworden. Er wurde zum unstrukturierten Komplement zu strukturierten Daten, das den Kontext hält, der nicht in Zeilen und Spalten passt.

Das System ist nur so gut wie die Gewohnheit. Frühe Einträge brauchten Anstöße, um spezifisch genug zu sein, um nützlich zu sein. Das Frageformat in /wrap wurde bereits zweimal verfeinert, um Designentscheidungen herauszuholen statt nur Aktivitätszusammenfassungen.

Dasselbe Muster (strukturierter Kontext, in der Versionskontrolle committet, von KI abfragbar) gilt auf Team-Ebene. Produktteams, die ihren KI-Kontext bewusst entwerfen (was reingeht, in welchem Format, mit welcher Struktur), werden dramatisch konsistentere Ergebnisse bekommen als Teams, die KI als zustandsloses Q&A-Tool behandeln. Das ist ein Infrastruktur-Problem, das als Workflow-Problem getarnt ist.

Einen serverless Agenten auf Vercel gebaut, der WhatsApp-Nachrichten über einen Twilio-Webhook empfängt, eine agentische Tool-Use-Schleife mit Claude Sonnet fährt und Vault-Dateien über die Google-Drive-API liest und schreibt. Der Agent hat drei Tools: Ordner auflisten, Dateien lesen und Dateien schreiben. Er kann Unternehmens-Pipeline-Status nachschlagen, Kontaktnotizen aktualisieren, Ideen festhalten und prüfen, was diese Woche ansteht, alles aus einer Textnachricht heraus. Der Gesprächsverlauf wird in Drive persistiert, damit der Assistent den Kontext über Nachrichten hinweg in einem 24-Stunden-Fenster behält, mit einem rollenden Puffer der letzten 10 Austausche.

Das Schwerste am Bauen eines WhatsApp-Agenten ist nicht die KI. Es sind die Rohre. Twilio-Webhooks laufen nach 15 Sekunden aus, also muss der Handler sofort zurückkehren und im Hintergrund über Vercels waitUntil weiterverarbeiten. Das Google-Drive-Service-Account braucht explizites Ordner-Sharing, um den Vault zu lesen, und eine separate Speicher-Strategie für Dateien, die der Agent selbst erzeugt. Gesprächspersistenz klingt einfach, bis der Schreibvorgang still scheitert und der Agent allen Kontext verliert. Jedes davon ist ein 30-Minuten-Fix, sobald diagnostiziert, aber die Diagnoseschleife ist langsam, wenn dein einziges Debugging-Interface eine Textnachricht auf dem Telefon ist.

Der Gesprächsverlauf wurde anfangs im geteilten Vault-Ordner gespeichert, in den das Service-Account nicht schreiben konnte. Jede Nachricht schien zu funktionieren (der Agent hat korrekt geantwortet), aber der Verlauf ging still verloren, sodass der Assistent amnesisch wirkte. Der Fix war, den Verlauf im eigenen Drive-Root des Service-Accounts zu speichern, wo Schreibzugriff garantiert ist. Der Fehler war in der Antwort unsichtbar und tauchte nur als zweite „etwas ist schiefgelaufen"-Nachricht auf, nachdem die eigentliche Antwort bereits gesendet war.

Messaging-basierte KI-Agenten haben eine grundlegend andere Fehleroberfläche als Web-Apps. Es gibt keinen Network-Tab, keine Konsole, keinen visuellen Zustand zum Inspizieren. Jeder Fehlermodus muss über denselben Textkanal sichtbar gemacht werden, über den der Nutzer kommuniziert, was heißt, dass Fehlerbehandlung nicht nur Engineering-Hygiene ist, sondern Teil der UX. Wenn dein Team konversationelle Agenten baut, investiert vom ersten Tag an in Observability. Die Feedback-Schleife zwischen „etwas ist kaputt" und „ich kann sehen, was kaputt ist" sollte in Sekunden gemessen werden, nicht in Sessions.

Claude Cowork (ein Mitarbeiter für Dateien, Strategie und Texte) für die inhaltliche Designarbeit genutzt: Fallstudien-Reviews, Copy-Entscheidungen, strukturelle Entscheidungen, Quellmaterial und Notizen lesen, die Bewertungsrubrik entwerfen und Content-Daten in TypeScript pflegen. Parallel Claude in Warp (terminal-basierter Coding-Mitarbeiter) als Umsetzungsarm: Build-Verifikation, Komponenten-Layout-Arbeit, Integrationsänderungen, Bildasset-Handhabung. Ich saß zwischen ihnen als Redakteur und Entscheider und habe Zustand über strukturierte Übergabe-Prompts weitergereicht.

Unterschiedliche KI-Mitarbeiter sind gut in unterschiedlichen Dingen, und einen zu zwingen, die Arbeit des anderen zu machen, fühlt sich immer suboptimal an. Cowork glänzt bei inhaltlichem Urteil: Quellmaterial lesen, gegen Benchmarks bewerten, Copy mit spezifischen Voice-Regeln entwerfen, entscheiden, was sich ändern soll. Warp glänzt bei der Umsetzung: Builds laufen lassen, systematisches Find-and-Replace, Layout-Arbeit ausführen, Diffs prüfen. Ihre Rollen zu trennen und Übergabe-Prompts zu schreiben, um sie zu überbrücken, hat sowohl die Geschwindigkeit als auch das Ergebnis verbessert.

Angefangen, beide Claudes als austauschbar zu behandeln. Das Ergebnis war, dass Cowork Umsetzungsarbeit gemacht hat, die er machen konnte, aber langsamer als Warp, und Warp Copy-Arbeit gemacht hat, die er machen konnte, aber mit weniger Urteilsvermögen als Cowork. Beides hat funktioniert. Beides war suboptimal. Der Fix war eine bewusste Arbeitsteilung und eine Disziplin rund um das Schreiben selbsterklärender Übergabe-Prompts zwischen Sessions.

KI-Mitarbeiter haben Spezialisierungen. Ein Team, das KI adoptiert, sollte nicht ein Tool nehmen und es auf jeden Job zwingen. Verschiedene Teile der Arbeit profitieren von verschiedenen KI-Affordances. Baut den Workflow rund um die Affordances, nicht rund um die Marke.

Eine Sim-Racing-Telemetrie-Fallstudie vom tatsächlichen Produktnamen auf ein beschreibendes Label umbenannt. Spezifische Feature-Namen (der Name der KI-Oberfläche, der Name des Chat-Agenten) entfernt und durch generische Beschreibungen ersetzt. Die vier ausgearbeiteten Archetypen generisch nach Fragenform (räumlich, zeitlich, verteilungsbezogen, Zustand-entlang-Linie) statt nach produkt-internen Begriffen benannt. Die architektonische Neurahmung und die Designzüge sichtbar gehalten. Der Fall ist immer noch als er selbst erkennbar, aber lässt keine Spezifika mehr durch, die den Kunden gegenüber einem Wettbewerber identifizieren würden.

Eine Fallstudie zu anonymisieren ist eine Einschränkung, die einen zur verteidigbarsten Version des Design-Anspruchs drängt. Ohne den Produktnamen, auf den man sich stützen kann, muss der Fall allein auf dem Designurteil stehen. Die Neurahmung („der Agent und die Arbeitsfläche sind architektonisch getrennt") ist haltbarer, wenn sie nicht an die spezifischen Features eines spezifischen Produkts gebunden ist, weil dieselbe Neurahmung auf andere Produkte im selben Raum angewendet werden könnte. Diese Allgemeinheit ist ein Feature, kein Bug.

Der erste Entwurf hat direkte Zitate vom Gründer verwendet. Selbst paraphrasiert riskieren zugeschriebene Zitate eine Identifizierung. Überarbeitet, um die Ansprüche selbst zu vertreten, statt sie zuzuschreiben. Das Ergebnis ist enger und weniger von der Stimme einer dritten Partei abhängig. Wenn der Fall ohne dieses Zitat nicht stehen kann, lehnt er sich an die falsche Sache an.

Ein Portfolio zu bauen, das aktive Kunden-Engagements einschließt, erfordert vorab zu entscheiden, welches Maß an Zuschreibung angenehm ist. Die stärksten Fallstudien schreiben Designzüge dem Designer zu, nicht überhörten Kundengesprächen. Wenn man es nicht als das eigene sagen kann, sollte es wahrscheinlich nicht im Portfolio sein.

Demo-Mode-Deployments von Cal und Epilog als separate Vercel-Projekte mit bereinigten Daten und isoliertem Zustand gebaut. In jeder erweiterten Fallstudie ist das Desktop-Layout eine CSS-Grid-Split-Ansicht: links eine scrollende Sechs-Abschnitt-Erzählung, rechts ein klebriger Telefon-Rahmen mit einem Live-Iframe der Demo-App darin. Der Rahmen ist ein hochauflösendes iPhone-15-Pro-Max-PNG, über den Iframe gelegt mit einem transparenten Bildschirm-Ausschnitt, plus eine dünne Rahmenring-Maske zwischen Iframe und PNG, um den Eck-Überlauf zu verstecken, wo die Full-Width-Header und die Bottom-Nav der App über die abgerundeten Bildschirm-Ecken des Telefons hinaus gemalt haben. Mobile lässt den Iframe vollständig fallen und nutzt Inline-Screenshots an wichtigen Erzähl-Schlägen plus einen „Die App erkunden"-CTA, der die Demo in einem neuen Tab öffnet, weil ein Telefon im Telefon nicht funktioniert.

Für KI-Produkte lügt ein Screenshot durch Auslassung. Das, was ein KI-Feature gut oder schlecht macht, ist, wie es sich verhält: wie der Plan unter deinen Eingaben generiert, wie Sprachbefehle danebengehen, wie sich ein Ablauf nach einer verpassten Dosis am Ende eines langen Tages unter den Fingern anfühlt. Statische Bilder lassen dich die Oberfläche zeigen und das Verhalten verbergen, was genau der Teil ist, den ein Hiring Manager bewerten muss. Die Live-App einzubetten erzwingt Ehrlichkeit und lässt den Leser das Ding direkt befragen, während er das Argument liest, warum es so gebaut wurde. Die Erzählung sagt dir, worauf zu achten ist; die Demo lässt dich verifizieren.

Die ersten drei Telefon-Rahmen-Versuche waren nur CSS (Lünetten, Border-Radius, Titanverläufe) und lasen sich alle als flach und offensichtlich gefälscht. Auf ein fotografisches Rahmen-PNG umzusteigen, hat den Realismus gelöst, aber das Eck-Überlauf-Problem erzeugt: Die klebrigen Header und die Bottom-Nav der App haben über die abgerundeten Bildschirm-Ecken hinaus gemalt, und keine Menge an Iframe-Border-Radius oder Inset-Tuning konnte eine pixelgenaue Ausrichtung mit dem PNG erreichen. Der Fix war ein leeres div mit einem dicken Rand in der Karten-Hintergrundfarbe, das zwischen Iframe und PNG sitzt und die innere Kante des Rahmens um ein paar Pixel überlappt, um den Überlauf unsichtbar zu maskieren. Im Nachhinein offensichtlich, beim Iterieren nicht.

Portfolio- und Marketing-Seiten für KI-Produkte sollten standardmäßig auf eingebettete Live-Demos statt auf Screenshot-Galerien setzen. Wenn das Verhalten das Produkt ist, muss das Präsentationsmedium dem Bewertungsmedium entsprechen. Ein Team, das nur Screenshot-Fallstudien für KI-Arbeit akzeptiert, bittet die Reviewer implizit, der Zusammenfassung mehr zu vertrauen als dem Artefakt, was das Gegenteil davon ist, wie gutes Design-Review funktioniert. Der Folgesatz: Entwirf für ein Demo-Mode-Deployment vom ersten Tag an (bereinigte Seed-Daten, isolierter Zustand, als Iframe einbettbar), statt es später nachzurüsten.

Sechs gefeierte Designer-Portfolios als Benchmark-Referenzen identifiziert: Simon Pan, Robin Noguier, Adham Dannaway, Buzz Usborne, Alin Buda und James Foo. Eine 9-Kategorien-Rubrik abgeleitet, die ersten Eindruck, visuelles Handwerk, Inhalts-Hierarchie, Fallstudien-Qualität, Stimme, technische Umsetzung, strategische Positionierung, Konversion und Originalität abdeckt. Mein altes Portfolio gegen jede auf einer 1-bis-5-Skala bewertet. Gesamt: 27 von 45, also 60 %. Verglichen mit Alin Budas 42 von 45 (93 %), der Top-Referenz. Die 15-Punkte-Lücke wurde zum Redesign-Briefing.

Aus einer Rubrik zu arbeiten statt aus einem stimmungs-basierten „Redesign meine Seite"-Briefing hat der Arbeit einen objektiven Kompass gegeben. Jede Änderung konnte gegen den Score einer bestimmten Kategorie bewertet werden. Der größte Einzelkategorie-Sprung war Inhalts-Hierarchie (2 auf 5), erreicht durch das Entfernen von Passwort-Sperren, das Verwerfen von Modals und die Annahme der Single-Page-Scroll-Through-Struktur. Der kleinste Zugewinn war Fallstudien-Qualität (bei 4 gehalten), weil die vorherigen Fälle bereits stark waren; der Zugewinn kam aus der Breite (fünf Detail-Seiten statt einer) statt aus der Tiefe pro Fall.

Die Rubrik hat eine Meinung. Sie privilegiert Überfliegbarkeit, Evidenz-Dichte und unverwechselbare Identität. Sie unterbewertet Tiefe-beim-Klick für technische Leser und Barrierefreiheit-als-Design-Aussage. Der geschätzte 93 %-Score auf der neuen Seite ist Selbstbewertung gegen dieselbe meinungs-tragende Linse. Jeder, der eine andere Rubrik nutzt, würde es anders bewerten.

Selbstbewertung gegen eine Rubrik, die man selbst geschrieben hat, ist befangen. Die Abmilderung ist, die Rubrik vor dem Redesign zu schreiben und gegen externe Referenzen zu benchmarken. Das entfernt die Befangenheit nicht vollständig, hält die Arbeit aber ehrlich. Ohne Rubrik ist „das sieht besser aus" der einzige verfügbare Maßstab; mit einer verschiebt sich das Gespräch dorthin, welche Kategorie sich um wie viele Punkte verschoben hat und warum.

Cals Plan-Generierung auf Gemini 1.5 Flash begonnen. Auf anhaltende Zuverlässigkeitsprobleme gestoßen: API-Instabilität, inkonsistente Ausgabestruktur und Qualität, die sich von Session zu Session zu stark unterschied, um ihr als Rückgrat eines nutzerseitigen Features zu vertrauen. Auf Claude Sonnet 4.6 gewechselt nach einem strukturierten Vergleich gegen denselben Prompt.

LLM-Bewertung ist ein UX-Research-Problem. Die Kriterien, die zählen, sind keine Benchmark-Scores; es sind Ausgabe-Konsistenz (produziert es zuverlässig dieselbe Struktur?), Ton-Treue (hält es die definierte Persona durch?), Einschränkungs-Befolgung (respektiert es die Regeln?) und Fehlermodus-Charakter (wenn es scheitert, wie scheitert es?). Claude ist eleganter und vorhersehbarer gescheitert. Diese Vorhersehbarkeit ist es, was es in Produktion nutzbar macht.

Der Bewertungsprozess war informell: prompten, vergleichen, entscheiden. Eine strengere, früher angewandte Rubrik hätte den Anbieter-Fehlpass schneller erwischt. Die LLM-Auswahl als Engineering-Entscheidung statt als Designentscheidung zu behandeln, hat ein paar Tage gekostet.

Teams, die KI-Anbieter oder -Modelle bewerten, sollten UX-Research-Methodik anwenden: Bewertungskriterien vor dem Testen definieren, gegen echte Anwendungsfälle testen, nicht gegen Benchmarks, und Fehlermodi genauso schwer gewichten wie Erfolgsraten. „Es funktioniert meistens" ist kein Produktions-Standard für irgendetwas Nutzerseitiges.

Ein Übungs-System entworfen, in dem jede Session zielgerichtet sein würde statt offen, mit einem kuratierten Satz von Lektionen, die Theorie, Technik und musikalische Konzepte abdecken, die alle auf einen Ziel-Song hinauflaufen. Die Idee war, Spielern einen klaren Roten Faden zu geben: nicht nur „üb 30 Minuten Gitarre", sondern „hier ist, woran du heute arbeitest, und warum es für das zählt, was du zu lernen versuchst".

Das Konzept hat gehalten. Die technische Realität nicht. Audio-Verarbeitung hat sich als viel tieferes Problem als die Übungsstruktur selbst herausgestellt, und die Lücke zwischen einer guten Idee und einem funktionalen musikalischen Werkzeug war breiter, als das Projekt zu der Zeit absorbieren konnte. Zugunsten dringenderer Arbeit auf Eis gelegt, aber das Kernproblem ist immer noch lösenswert.

Audio-Verarbeitung für Tonhöhen-Erkennung und Feedback ist eine spezialisierte Domäne mit echten Einschränkungen: Latenz, Rauschen und Geräte-Variation. Unterschätzt, wie viel des Produkts davon abhing, das zu lösen, bevor irgendetwas anderes validiert werden konnte.