Ein Agent schneidet meine Talks
Claude schneidet meine YouTube-Talks im Terminal: Der Agent schlägt jeden Schnitt vor, ich gebe frei, dann rendert und lädt er hoch. 100 Prozent lokal.

TL;DR
- Ich schneide meine YouTube-Talks nicht mehr allein, sondern zusammen mit einem Agenten im Terminal.
- Die Schleife: Rohclip, wortgenaues Transkript, Cut-Vorschlag als Edit Decision List, meine Freigabe, frame-genauer Render, Eval, Upload.
- Der Agent schlägt jede Keep- und Cut-Spanne autonom vor, die Freigabe bleibt bei mir, mechanisch kann er sich nie selbst durchwinken.
- Alles läuft zu hundert Prozent lokal, das Sprachmodell sieht die Cloud nie.
- Live im Einsatz bei der echten "Vibecode together"-Serie auf meinem YouTube-Kanal, keine Demo.
Der Schmerz: Schnitt frisst die Zeit, die fürs Bauen da sein sollte
Wenn ich einen Talk aufnehme oder eine Vibecode-Session live mitschneide, entsteht am Ende ein Rohclip von oft über einer Stunde Länge. Bis daraus ein veröffentlichungsfähiges YouTube-Video wird, muss jemand jede Pause raus schneiden, jeden Versprecher rauswerfen, den Anfang und das Ende sauber setzen. Genau diese Arbeit hat mich am meisten von dem abgehalten, wofür ich die Aufnahme überhaupt gemacht habe: bauen.
Schnitt in einem klassischen Editor ist Frame-für-Frame-Arbeit. Man scrubbt durch eine Wellenform, markiert In- und Out-Punkte, schaut sich denselben Abschnitt drei- oder viermal an, bevor man sich sicher ist. Bei einem einstündigen Rohclip sind das leicht zwei, drei Stunden reine Sitzarbeit, die nichts mit dem eigentlichen Produkt zu tun hat, das ich zeigen will. Ich baue Agenten, die anderen Menschen mechanische Arbeit abnehmen. Es wäre seltsam, ausgerechnet bei meinem eigenen Content auf die mechanische Variante zu bestehen und sie mir selbst nicht abzunehmen.
Also habe ich die gleiche Frage gestellt, die ich mir bei jedem wiederkehrenden Arbeitsschritt stelle: Was davon ist Urteil, und was davon ist reine Ausführung? Die Antwort war eindeutig. Erkennen, wo eine Pause anfängt und aufhört, ist Mustererkennung auf einem Transkript, das kann eine Maschine erschöpfend und ohne Ermüdung. Entscheiden, ob ein Take insgesamt drinbleibt, ob ein Gedanke trägt oder ob er im Schnitt fehlt, ist ein Urteil, das ich treffen muss, weil ich für das Ergebnis stehe. Genau an dieser Trennlinie setzt AgenticCutter an.
Die Loop: von Transkript zu Upload
Der Ablauf ist eine geschlossene Schleife mit sechs Stationen, und jede davon hat eine klare Aufgabe.
Am Anfang steht der ungeschnittene Clip. Der Agent lässt ihn durch mlx-whisper laufen und bekommt ein wortgenaues Transkript zurück, jedes gesprochene Wort mit Zeitstempel. Damit hat er eine textuelle Landkarte des gesamten Materials, durchsuchbar und maschinenlesbar, lange bevor ein einziges Bild geschnitten wird.
Auf Basis dieses Transkripts schlägt der Agent eine Cut-Entscheidung vor: eine Edit Decision List, kurz EDL. Das ist keine fertige Videodatei, sondern eine strukturierte Liste von Zeitbereichen mit der Markierung Keep oder Cut. Lange Pausen, abgebrochene Sätze, doppelte Anläufe zum gleichen Gedanken, all das schlägt der Agent zum Rausschneiden vor. Was inhaltlich trägt, schlägt er zum Behalten vor. Diese Vorschläge trifft er autonom, für die gesamte Länge des Clips, ohne dass ich einzelne Abschnitte einzeln anstoßen muss.
Diese EDL lege ich mir vor, Zeile für Zeile. Ich lese die vorgeschlagenen Cuts gegen das Transkript und entscheide: passt, oder passt nicht. Erst wenn ich freigebe, geht es weiter zum nächsten Schritt.
Nach der Freigabe rendert der Agent frame-genau. Das heißt, die Schnittpunkte liegen exakt auf den Frame-Grenzen, die die EDL vorgibt, kein Nachschieben von Hand, kein nachträgliches Antasten der Timeline.
Danach kommt ein Schritt, den man in einem klassischen Editor gar nicht kennt: die Eval. Der Render läuft gegen eine Reihe von committeten Fixtures, an denen Precision und Recall des Schnitts gemessen werden. Erst wenn die Eval besteht, gilt der Render als abgenommen, nicht schon, weil er fertig gerendert ist.
Am Ende steht der Upload zu YouTube. Das ist der einzige Schritt, der die Verarbeitung überhaupt in Richtung einer externen Plattform verlässt. Alles davor, Transkript, Cut-Vorschlag, Render, Eval, passiert auf meiner eigenen Maschine.
Warum das Freigabe-Gate ein Feature ist
Der Agent schlägt jede Keep- und Cut-Spanne vor. Er tut das autonom, ohne dass ich vorher jeden Abschnitt einzeln anstoße. Aber er kann sich mechanisch nie selbst freigeben. Die Freigabe ist ein eigener Schritt in der Kette, kein Häkchen, das der Agent nebenbei mit erledigt.
Das ist keine Sicherheitsauflage, die ich nachträglich draufgesetzt habe, weil ich dem Modell nicht traue. Es ist eine bewusste Architekturentscheidung, aus demselben Grund, aus dem BuilderBob bei Geld, Rechtsfragen und Beschwerden immer zu mir eskaliert: manche Entscheidungen gehören einem Menschen, nicht weil die Maschine sie schlecht treffen würde, sondern weil die Verantwortung dafür nicht delegierbar ist. Wenn ein Take in einem Video landet, in dem ich vor einem Publikum etwas sage, trage ich das. Nicht der Agent.
In der Praxis heißt das: Ich lese jede EDL vollständig, bevor der Render startet. Manchmal korrigiere ich einzelne Zeilen, weil eine Pause inhaltlich wichtig war, ein bewusstes Innehalten, kein Fehler. Der Agent kann das aus dem Transkript allein nicht immer unterscheiden, ich kann es, weil ich beim Dreh dabei war. Genau diese Ergänzung macht aus einer automatisierten Schleife einen Arbeitsablauf, dem ich vertraue: der Agent macht die Vorarbeit maschinell erschöpfend, ich treffe die Entscheidung, die ein Urteil braucht.
Hundert Prozent lokal: das Modell sieht die Cloud nie
Der gesamte Ablauf läuft lokal auf meiner Maschine. Transkription über mlx-whisper, Cut-Entscheidung, Render über ffmpeg, Eval: nichts davon verlässt meinen Rechner in Richtung eines fremden Servers.
Technisch abgesichert ist das über einen Egress-Guard, den ich intern --zero-cloud nenne. Er unterbindet jeden ausgehenden Netzwerkzugriff während der Verarbeitung. Das Sprachmodell, das die Schnittentscheidungen trifft, sieht die Cloud zu keinem Zeitpunkt. Es arbeitet ausschließlich mit dem, was lokal auf der Maschine liegt: dem Rohclip, dem Transkript, den Fixtures für die Eval.
Der Grund dafür ist nicht in erster Linie Datenschutz, obwohl das ein angenehmer Nebeneffekt ist, wenn in einem Rohclip auch unveröffentlichte Gedanken oder Namen von Gesprächspartnern vorkommen, die noch nicht für die Öffentlichkeit bestimmt sind. Der Hauptgrund ist Kontrolle über die Angriffsfläche. Wenn ein Schritt in der Kette keine Netzwerkverbindung aufbauen kann, muss ich mir über diesen Schritt keine Gedanken machen, wenn ich über Datenabfluss oder externe Abhängigkeiten nachdenke. Ein Prozess, der lokal bleibt, kann per Definition nicht versehentlich etwas nach draußen schicken, weil ihm dafür schlicht der Weg fehlt.
Das ist derselbe Instinkt, den ich auch anderswo in meiner Agenten-Flotte verfolge: möglichst viel Verarbeitung dort behalten, wo ich sie direkt beobachten und im Zweifel sofort abschalten kann. Bei einem Video-Schnittprozess, der mit meiner eigenen Stimme und meinem eigenen Gesicht arbeitet, ist mir das besonders wichtig, mehr als bei den meisten anderen Agenten in meiner Flotte.
Der Beweis: die "Vibecode together"-Serie entsteht so
Das ist kein Werkzeug, das ich einmal gebaut und dann in einer Schublade liegen gelassen habe. Jede Folge meiner YouTube-Serie "Vibecode together" läuft heute durch genau diese Schleife: Rohclip rein, Transkript, Cut-Vorschlag, meine Freigabe, Render, Eval, Upload.
Das ist der Unterschied zwischen einem Proof of Concept und einem Werkzeug, das ich tatsächlich benutze. Ein Demo-Video, das einmal auf einer Bühne funktioniert, sagt wenig darüber, ob ein System im Alltag trägt. Was zählt, ist, ob ich es Woche für Woche wieder anfasse, ohne mir jedes Mal neu die Frage zu stellen, ob es sich lohnt.
Bei "Vibecode together" lohnt es sich, weil die Alternative bekannt ist: Ich habe vorher manuell geschnitten, und ich weiß genau, wie viele Stunden reiner Sitzarbeit das pro Folge gekostet hat. Die Zeit, die ich dadurch zurückbekomme, fließt in genau das, worüber die Serie eigentlich handelt: gemeinsam mit Agenten bauen, statt danach stundenlang am Schnittplatz zu sitzen und das Ergebnis Frame für Frame nachzuziehen.
Ausblick: Cutter und FeedFoundry bleiben zwei getrennte Stufen
AgenticCutter ist bei mir keine Insel. Es ist eine von zwei Content-Stufen in meiner Agenten-Flotte, neben FeedFoundry, das aus Material Kurzform-Content für Instagram rendert. Die beiden sind heute bewusst nicht miteinander verdrahtet. Das ist keine Lücke, die ich übersehen habe, sondern eine Entscheidung: Ich baue die Verbindung erst, wenn ich an echten Nutzungsdaten sehen kann, dass sie einen messbaren Unterschied macht, nicht weil es sich elegant anfühlt, zwei Systeme zu verknüpfen, die bisher unabhängig voneinander gut funktionieren.
Für den Moment reicht mir, dass beide Stufen für sich funktionieren. Cutter nimmt mir den Schnitt ab, mit mir als Freigabe-Instanz an der entscheidenden Stelle. FeedFoundry rendert Kurzform-Content nach festen Regeln. Wie diese beiden Stufen irgendwann zusammenspielen, dokumentiere ich, sobald es tatsächlich passiert, und nicht vorher als Ankündigung.
Wenn du wissen willst, wie diese Stufe in die größere Agenten-Flotte passt, also wo Sven, BuilderBob und die anderen Werkzeuge einsortiert sind, habe ich das in einem eigenen Artikel aufgeschrieben: Eine Agenten-Flotte bauen. Und wenn du selbst anfangen willst, mit KI-Agenten zu bauen statt nur darüber zu reden: Ein kostenloses Handout und einen Newsletter dazu gibt es auf agenticbuilders.at. Kein Pitch, einfach ein Einstieg für alle, die ähnlich ticken.