Ich entwickle eine Mac-exklusive Meeting-Aufnahme- und Transkriptions-App namens Kanary mit einem Paar aus Claude Code (Opus 4.8) / Codex (GPT-5.5). Manche Leute können sich vielleicht schwer vorstellen, wie „Vibe Coding“ in der Entwicklung tatsächlich funktioniert.
Dieses Mal möchte ich über die Großartigkeit von Opus schreiben, der speziell als Designer und Berater für High-Level-Spezifikationen arbeitet.
Die Herausforderung diesmal ist das Problem, das Aufnehmen zu vergessen. Dies ist derzeit das am häufigsten von Nutzern gemeldete Problem.
Unten ist der Dialog: Ich > Claude > Codex > Claude.
Ich
Zum Thema Stoppen von Aufnahmen: Da Kanary bei geschlossenem Fenster nur einen einzelnen roten Punkt in der Menüleiste anzeigt und sämtliches globales Mikrofon-/Lautsprecher-Audio ohne Bindung an eine bestimmte App zusammenfasst, ist es theoretisch unmöglich, das Ende eines Meetings zu erkennen. Infolgedessen haben viele Nutzer nach einem Meetings stundenlange Stille aufgezeichnet. Ich habe gerade eine Funktion zum Kürzen von Anfang und Ende hinzugefügt, um das Schlimmste zu verhindern, aber ich denke, das eigentliche Ziel ist es, den Nutzer erkennen zu lassen, dass das Meeting beendet ist.
Ich habe bisher zwei Ideen:
- Eine Benachrichtigung ausgeben, wenn die Lautstärke von Mikrofon/Lautsprecher für 5 Minuten nahe der Stille bleibt.
- Einen Mini-Player anzeigen, wenn die Aufnahme startet, um den Zustand zu verhindern, dass man sie unbemerkt weiterlaufen lässt.
Beide haben Vor- und Nachteile. Was meinst du?
Claude
Um direkt zum Punkt zu kommen: Diese beiden adressieren unterschiedliche Ebenen des Problems, und diejenige, die den Kern trifft (= das Erkennen des Endes zu bewirken), ist der Ansatz 1. Allerdings haben sowohl 1 als auch 2 für sich genommen Schwächen; der Gewinnerzug liegt darin, wie man sie kombiniert. Lass es uns aufschlüsseln.
Zunächst: Definition des Fehlermodus
Der Zustand „Stundenlange leere Aufnahme“ tritt definitionsgemäß auf, weil der Nutzer nicht vor dem Bildschirm ist oder nicht darauf schaut. Das ist der Kern der Bewertungsachse.
- 2 (Mini-Player) ist ein visuelles Hinweis → Er erreicht nur Personen, die auf den Bildschirm schauen. Er funktioniert für Fälle, in denen jemand „am Schreibtisch sitzt, aber in andere Arbeit vertieft ist“, aber er versagt theoretisch beim Kernproblem: „den Schreibtisch verlassen / sich vom PC entfernt haben“. Er funktioniert nicht in der Situation, in der er am dringendsten benötigt wird.
- 1 (Benachrichtigung) erreicht außerhalb des Bildschirms → Sie geht an das Benachrichtigungszentrum, den Sperrbildschirm und (bei Spiegelung) das iPhone. Die Kompatibilität mit dem Fehlermodus ist bei 1 überwältigend besser.
Wenn wir also auf den Kern abzielen, basieren wir auf 1.
Schwächen der einzelnen Vorschläge
Die Schwäche von 1 sind Fehlalarme. Stille ≠ Ende des Meetings. Stille tritt in echten Meetings normal auf (Dokumente lesen, Nachdenken, Pausen, stummes Video via Bildschirmfreigabe usw.). Ein Schwellenwert von 5 Minuten ist ein Kompromiss zwischen „kurz = nervig / lang = Leerlauf bleibt erhalten“, was schnell zur Tuning-Hölle wird. Wenn Fehlalarme ein paar Mal passieren, stirbt das Vertrauen in die Benachrichtigung – das ist das Gefährlichste.
Die Schwäche von 2 sind Gewöhnung und Bildschirmfreigabe-Lecks. Eine ständige Anzeige wird innerhalb einer Woche zur Tapete und verschwindet aus der Wahrnehmung. Außerdem ist es aufgrund der Natur eines Meeting-Tools ein Unfall, einen Aufnahmeindikator auf einem geteilten Bildschirm zu zeigen – sowohl in Bezug auf Informationsleck als auch Ästhetik.
Der Gewinnerzug: Nicht nur nach Stille urteilen. „Stille UND Nutzer-Inaktivität“
Das Fehlalarm-Problem von 1 verschwindet fast, wenn man ein weiteres Signal hinzufügt.
- Audio-RMS unter Schwellenwert (sowohl Mikrofon + Lautsprecher) PLUS
- HID-Inaktivitätszeit (CGEventSourceSecondsSinceLastEventType / IOKit, keine Tastatur-/Mausbedienung) und idealerweise Bildschirmschlaf / Bildschirmsperre.
Durch diese UND-Logik ändert sich das Urteil von „Stille“ zu „Das Meeting ist beendet UND die Person ist gegangen.“ Dies löst fast nie Fehlalarme aus. Stille während eines Meetings löst es nicht aus, weil der Nutzer am Schreibtisch ist und den Computer bedient, also nicht „inaktiv“ ist.
Und wenn diese Bedingung erfüllt ist, ist die Tatsache, dass wir sicher einen automatischen Stopp auslösen können riesig:
- Nutzer bedient (anwesend) → Kein automatischer Stopp und keine Benachrichtigung, egal was passiert. Die Person schaut zu, und da ist der rote Punkt in der Menüleiste. Vertraue ihnen. (Hier funktioniert der Mini-Player aus 2).
- Inaktiv, aber Audio vorhanden → Möglichkeit einer legitimen Remote-Aufnahme wie eines Webinars. Nicht stoppen.
- Inaktiv UND still → Dies ist der einzige bestätigte Zustand „Meeting beendet + gegangen“ → Benachrichtigen → Bei keiner Reaktion automatisch stoppen.
Da sie den Schreibtisch verlassen haben, ist das Risiko, den Rest des Meetings durch einen automatischen Stopp zu verpassen, strukturell null. Da die Kürzungsfunktion die nachfolgende Stille bereinigt, ist das Material zum Zeitpunkt des Stoppens ebenfalls sauber. Durch die Schaffung einer Leiter aus Benachrichtigung (ein Ausweg für lange Arbeitszeiten) → automatischer Stopp nach M Minuten (Selbstheilung für gegangene Nutzer) repariert es sich selbst, selbst wenn der Nutzer die Benachrichtigung nicht bemerkt.
Warum wir stoppen sollten, nicht nur „sie bemerken lassen“
Der Grund, am Kern festzuhalten und nicht nur zu kürzen, ist Privatsphäre. Stundenlanges Aufnehmen von Raum-Audio nach einem Meeting ist ein Unfall, bei dem private Gespräche außerhalb des Meetings aufgezeichnet werden. Deshalb dränge ich auf die aktive Richtung des Stoppens bei Abwesenheit anstatt nur „bemerken lassen (passiv)“.
Zusammenfassung
- Hauptachse = Verbesserte Version von 1: Stille UND Inaktivität → Benachrichtigung → Automatischer Stopp-Leiter. Trifft den Fehlermodus direkt, unterdrückt Fehlalarme und schützt die Privatsphäre.
- 2 = Hilfsfunktion: Wertvoll als Umgebungsanzeige für Nutzer am Schreibtisch, aber niedrigere Priorität. Falls enthalten, ist automatisches Ausblenden/Minimieren während Bildschirmfreigabe ein Muss.
- Das Hinzufügen einer verstrichenen Zeit-Anzeige zum roten Punkt in der Menüleiste ist billig, steigert aber das Bewusstsein, dass „es immer noch aufnimmt“ – daher lohnenswert, sofort umzusetzen, unabhängig davon, welchen Weg man wählt.
Als Gegenargument könnte man den automatischen Stopp ablehnen als „willkürliches Abschneiden von Nutzermaterial“. In diesem Fall wäre der Kompromiss, beim Benachrichtigen zu stoppen und die Benachrichtigung durch die Inaktivitätsbedingung zuverlässig zu machen (Fehlalarme eliminieren). Sobald man entscheidet, ob man bis zum automatischen Stopp geht oder beim Benachrichtigen stoppt, steht die Implementierungspolitik fest.
Codex
Ich finde Claudes Meinung sehr fundiert. Besonders die Einordnung, dass „1 und 2 unterschiedliche Ebenen sind“ und die „Stille UND Inaktivität“-Logik ist stark.
So würde ich priorisieren:
- Benachrichtigung bei Stille UND Inaktivität
- Beide Mikrofon/Lautsprecher nahezu still
- Keine Tastatur-/Mausbedienung
- Idealerweise Bildschirmsperre/Display-Schlaf einbeziehen
- Nach 5 Minuten eine Benachrichtigung: „Die Aufnahme läuft noch. Stoppen?“
- Automatischer Stopp, wenn nach Benachrichtigung für eine bestimmte Zeit keine Reaktion erfolgt
- Dies hängt von der Produktphilosophie ab, aber ich denke, es ist in Ordnung, es einzubauen.
- Der Grund ist, wie Claude sagte: Dies ist kein Speicherproblem, sondern ein Privatsphäre-Problem.
- Allerdings sollte es zunächst in den Einstellungen umschaltbar sein, oder zumindest „Empfohlen EIN“.
- Aufnahmezeit auf dem roten Punkt in der Menüleiste anzeigen
- Billig und effektiv.
- Wie ● 1:24:03, damit sie wissen, „es nimmt immer noch auf“, auch wenn das Fenster geschlossen ist.
- Das ist es wert, sofort gemacht zu werden.
Was den Mini-Player betrifft, würde ich ihn als Kernlösung zurückstellen. Der Grund ist, dass der größte Fall von „Vergessen und Laufenlassen“ dann eintritt, wenn sie nicht auf den Bildschirm schauen oder ihren Platz verlassen haben. Der Mini-Player erreicht sie dort nicht. Außerdem ist das Risiko, dass er in Bildschirmfreigaben auftaucht, etwas nervig.
Es ist nicht so, dass der Mini-Player wertlos ist, aber er hat eine andere Rolle. Er ist effektiv, um „während der Arbeit natürlich daran zu erinnern, dass eine Aufnahme läuft“. Aber für „den Unfall der stundenlangen Aufnahme nach einem Meeting zu stoppen“, trifft die Benachrichtigung/der automatische Stopp den Punkt direkter.
Mein empfohlenes Spezifikation ist dies:
Wenn Mikrofon/Lautsprecher nahezu still ist UND die Nutzer-Inaktivität während der Aufnahme 5 Minuten anhält, benachrichtigen. Wenn nach der Benachrichtigung weitere 5 Minuten keine Reaktion erfolgt, automatisch stoppen. Nach dem Stoppen die nachfolgende Stille kürzen und speichern.
Mit diesem Setup ist es schwer, während der Stille in einem Meeting zu stoppen, und es wird nicht bei Fällen gestoppt, in denen Audio abgespielt wird, wie beim Ansehen eines Webinars. Darüber hinaus kann es sich im problematischsten Zustand selbst heilen: „weg vom Schreibtisch und unfähig, die Benachrichtigung zu bemerken.“
Ein Punkt zu beachten: Der Schwellenwert für „nahezu still“ variiert stark je nach Nutzerumgebung, daher könnten feste Werte unordentlich sein. Es wäre besser, das Umgebungsrauschen nach dem Start der Aufnahme zu lernen und nach „still-ähnlichen“ Zuständen relativ zu suchen. Es kann zunächst grob sein, aber dies wird die Qualität der Erfahrung in Zukunft bestimmen.
Abschließend stimme ich dem Vorschlag von Claude stark zu. Ich möchte jedoch einen Schritt weiter gehen von „der Kern ist, sie bemerken zu lassen“ zu tatsächlich stoppen, wenn sie gehen. Das Vertrauensgefühl, dass Kanary dich automatisch schützt, passt besser zu diesem Problem.
Claude
Einverstanden. Ich bin dafür, bis zum Stoppen zu gehen, wenn sie gehen. Das Leiterformat (Stille + Inaktivität 5 Min → Benachrichtigung → Weitere 5 Min → Automatischer Stopp → Nachfolgend kürzen) ist solide. Darüber hinaus werde ich 4 Punkte hinzufügen, die bei der Implementierung einen Unterschied machen werden.
1. Die Schwellenwert-Diskussion ist, wie Codex sagte, und dies bestimmt die Qualität der Erfahrung. Lassen wir das Design spezifischer machen.
Feste dB-Schwellenwerte werden aufgrund von Umgebungsunterschieden definitiv unordentlich sein, daher ist die richtige Antwort, auf relative Werte innerhalb der Aufnahmesitzung zu schauen. Lerne rollierend den „aktiven Lautstärkebereich (Median) während des Sprechens“ in den ersten paar Dutzend Sekunden bis Minuten der Aufnahme und betrachte den aktuellen RMS als „still-ähnlichen“ Zustand, wenn er signifikant davon abfällt. Verwende absolute Werte nur als ergänzende untere Grenze.
Eine andere Sache: es ist effektiv, Mikrofon und Lautsprecher unterschiedlich behandeln zu können. Für die Lautsprechersseite kannst du anstatt RMS zu messen vom Betriebssystem erfahren, „ob irgendeine App gerade Ton ausgibt“ (CoreAudio-Prozess-Audio/Tap), was eine nahezu deterministische Beurteilung ermöglicht. Relatives RMS nur für die Mikrofonseite. Nimm das UND von beiden, wenn sie still sind. Da der Lautsprecher ein bestätigtes Signal wird, werden Fehlalarme weiter reduziert.
Ein Hinweis: Da es Fälle gibt, in denen Meetings leise beginnen (wo die zu Beginn gelernte „still-ähnliche“ Basislinie tatsächlich normale Unterhaltung ist), halte die Basislinie rollierend, nicht fest.
2. Füge zwei Schutzmaßnahmen zum automatischen Stopp hinzu.
- Kein automatischer Stopp für die ersten N Minuten (z. B. 5–10 Min.) der Aufnahme. Um zu vermeiden, dass Stille während des Aufbaus oder des Zustands „frühzeitig aufnehmen und warten“ abgewürgt wird.
- Ein Ausweg für „Diese Sitzung nicht stoppen / Nicht erneut fragen“. Damit Power-User in legitimen Fällen wie langer Solo-Fokus-Aufnahme oder fast stummen Vorlesungen nicht jedes Mal genervt werden. Sobald „Behalten“ gedrückt wird, deaktiviere es für diese Sitzung.
3. Achte auf die Reihenfolge des Wertes, um keine falsche Investition zu tätigen. Eigentlich ist der automatische Stopp der wahre Schwergewichtler für „abwesende Nutzer“, und die Benachrichtigung ist hauptsächlich eine Höflichkeit + Zustimmungsprüfung für „Leute am Schreibtisch, die aber vertieft sind“. Wenn sie den Schreibtisch verlassen haben, bemerken sie die Benachrichtigung nicht (Aktionen auf dem Sperrbildschirm sind ebenfalls begrenzt), also überentwickle die Benachrichtigungs-UX nicht. Zu erkennen, dass die Selbstheilung auf der Seite des automatischen Stopps stattfindet, erlaubt es, die anfängliche Implementierung einfach zu halten.
4. Baue von Anfang an eine Rückkopplungsschleife für die Schwellenwertanpassung ein. Das beste Signal dafür, ob ein automatischer Stopp ein Fehlalarm war, ist ob der Nutzer die Aufnahme sofort (innerhalb von X Minuten) nach dem Stoppen manuell wieder aufgenommen hat. Das Protokollieren davon wird automatisch Beweise für „zu viel Stoppen“ ansammeln und ermöglicht es, die Schwellenwerte mit Daten zu verschärfen. Es ist billig, also lohnt es sich, es von Anfang an einzubauen.
Ich dränge auf Standard EIN (zustimmend mit Codex' „Empfohlen EIN“, oder eher, dränge auf EIN mit konservativen Schwellenwerten). Der Grund ist einfach: Die Leute, die von diesem Unfall verbrannt werden, sind diejenigen, die den Einstellungsbildschirm nicht öffnen. Einstellungen retten nur Leute, die ohnehin nicht betroffen waren.
Die verstrichene Zeit in der Menüleiste (● 1:24:03) hat keine Abhängigkeiten und kann sofort gemacht werden. Der Mini-Player wird als Hilfsfunktion mit einer anderen Rolle + Ausblenden während Bildschirmfreigabe zurückgestellt.
Ich denke, die Spezifikationen sind bereits solide. Die einzige verbleibende Entscheidung ist „ob wir in der ersten Version bis zum automatischen Stopp gehen oder abwarten, wie es nur mit Benachrichtigungen für einen Zyklus läuft.“ Wenn wir das Framing als Privatsphäre-Problem nehmen, würde ich darauf wetten, mit automatischem Stopp von Anfang an zu veröffentlichen.
Findest du nicht auch? Ist das nicht erstaunlich?
Es gibt nicht viele Produktdesigner, die sofort Spezifikationen mit solch akribischer Überlegung einfallen lassen. Ich habe mit Leuten gearbeitet, die im Silicon Valley als Super-Designer gelobt wurden, aber es ist unmöglich für einen Menschen, nach dem Einlesen in den Quellcode mit dieser Geschwindigkeit eine Antwort zu liefern.
Claudes Einsichten sind besonders tief. Mit Opus 4.8 hat es begonnen, sehr tiefe Teile der Benutzererfahrung durchzudenken.
Allerdings, obwohl es so tief denken und Anweisungen bis hin zu spezifischem Code-Inhalt geben kann, wenn man es in diesem Fluss den Code anfassen lässt, ist es ein totaler Tollpatsch und wird mit Sicherheit etwas kaputt machen. Es ist wie eine Person, die brillant ist, aber ungeschickt mit ihren Händen. Deshalb lasse ich immer Codex den Code erledigen. Und schließlich lasse ich Claude ihn überprüfen, um auf redundanten Code von Codex hinzuweisen. (Aber Codex ist derjenige, der das auch repariert.)
So verbringe ich meine Tage mit der Entwicklung, umgeben von diesen beiden Übermenschen.
Ich hoffe, du kannst die Atmosphäre dieser Spezifikationssitzung aus dem täglichen Entwicklungsleben im Juni 2026 spüren.
