Wie Beyond Tabs zu Guida führte
Beyond Tabs gab es vor Guida.
Es ist eine handkuratierte Website für Jobs, Events und Ressourcen rund um Nischen-Programmiersprachen. Von außen klingt das einfach: relevante Seiten finden, lesen, entscheiden, was dazugehört, nützliche Teile behalten und den Rest verwerfen. In der Praxis liegt die Arbeit in einem unbequemen Zwischenbereich.
Sie ist zu repetitiv, um als rein manuelles Browsen angenehm zu sein. Sie ist zu stark von Urteil abhängig, um sie vollständig an einen Scraper abzugeben. Und sie ist zu vielfältig, um sie auf ein sprödes Skript zu reduzieren, das annimmt, jede nützliche Seite sehe gleich aus.
In diesem Zwischenbereich begann Guida.
Die Arbeit zwischen Browsen und Scraping
Eine kuratierte Website zu pflegen bedeutet viele kleine Webaufgaben, die einzeln einfach und zusammen ermüdend sind.
Eine Seite öffnen. Entscheiden, ob sie relevant ist. Titel, Link, Datum, Firma, Sprache oder Kurzbeschreibung extrahieren. Prüfen, ob die Quelle noch lebt. Duplikate erkennen. Einem weiteren Link folgen. Gegen vorhandene Daten vergleichen. Genug Kontext behalten, damit das Ergebnis für Leser nützlich ist und nicht nur technisch extrahiert.
Klassische Browserautomatisierung hilft bei Teilen davon. Ein Skript kann Seiten öffnen, den DOM abfragen und Daten speichern. Aber ein Kurationsworkflow ist nicht nur “diese Elemente auswählen und speichern”. Der nützliche Teil hängt oft von Urteil ab:
- Geht es wirklich um die Sprache, die mich interessiert, oder nur um Keyword-Rauschen?
- Ist die Seite noch aktuell?
- Ist das ein echter Job, ein echtes Event oder eine echte Ressource?
- Hat sich das Layout geändert?
- Ist das Ergebnis veröffentlichungswürdig?
Reines Scraping ist gut, wenn Seitenstruktur stabil und die Frage eng ist. Beyond Tabs erzeugte immer wieder Aufgaben, die anders waren: halb Browsen, halb Extraktion, halb Review. Das sind zu viele Hälften, und genau darum ging es.
Warum einzelne Skripte nicht reichten
Die naheliegende erste Antwort war: Skripte schreiben.
Das half. Es zeigte aber auch das nächste Problem. Sobald ein Skript nützlich ist, braucht es ein kleines Ökosystem:
- einen Ort für extrahierte Daten,
- Batch-Verarbeitung,
- eine Queue für Seiten, die Review brauchen,
- lokalen Zustand über Sitzungen hinweg,
- Werkzeuge zum Prüfen, was passiert ist,
- Änderungen am Skript ohne Neubau einer App,
- und eine Möglichkeit, sensible Zugangsdaten aus dem Skript herauszuhalten.
Dann lautet die Frage nicht mehr: “Kann ich diese Seite scrapen?” Sondern: “Welche Art Browser würde diese Arbeit normal machen?”
Diese Frage ist Guida.
Warum KI Kontrolle nicht ersetzt
Große Sprachmodelle machten das Problem interessanter, nicht kleiner.
Eine KI kann helfen, unordentliche Seiten zu interpretieren. Sie kann zusammenfassen, klassifizieren, Selektoren vorschlagen, Relevanz einschätzen und Klebecode schneller schreiben, als ich ihn tippen möchte. Aber eine KI einen Browser bedienen zu lassen, erzeugt ein anderes Problem: Sie braucht Grenzen.
Ich wollte keinen unsichtbaren Agenten, der im Web herumläuft, Dinge anklickt, Zugangsdaten liest oder Daten verschickt, nur weil ein Prompt es plausibel klingen lässt. Für Beyond-Tabs-artige Arbeit ist das nützliche Modell nicht “vollautonomes Browsen”, sondern beaufsichtigte Automatisierung:
- der Browser ist sichtbar,
- Aktionen sind prüfbar,
- Navigation kann begrenzt werden,
- sensible Operationen brauchen Freigabe,
- Werkzeugaufrufe werden protokolliert,
- Zugangsdaten bleiben lokal,
- und der Mensch bleibt im Regelkreis.
Deshalb ist Guidas MCP-Arbeit nicht nur ein dünner “KI kann klicken”-Adapter. Freigabe, Nachverfolgung, Domains, Herkunft und Zugangsdaten-Isolation gehören zum Kern des Produkts.
Das Werkzeug wurde allgemeiner
Wäre Guida nur ein Helfer für Beyond Tabs geblieben, hätte es bei ein paar Skripten und einer Tabelle enden können.
Das tat es nicht.
Die Arbeit wuchs zu einem programmierbaren Windows-Browser mit mehr als 160 Scripting-API-Methoden, JavaScript/Lua/Janet-Runtimes, lokalen Arbeitsbereichen, Warteschlangen, Workern, Speicher, Suche, Netzwerkerfassung, MCP-Integration, Freigabeabläufen, Nachverfolgungsprotokoll und Zugangsdaten-Isolation.
Einige unterstützende Infrastruktur wurde eigenständig. JanetSharp entstand aus der Einbindung von Janet in eine .NET-Desktopanwendung. StratQueue entstand aus dem Bedarf an SQLite-gestützten Arbeitswarteschlangen mit austauschbaren Entnahmestrategien.
Diese Pakete sind öffentlich, weil sie wiederverwendbare Infrastruktur sind. Guida selbst wird derzeit als Closed-Source-Windows-App ausgeliefert; die produktspezifische Schicht für Browserautomatisierung und Web Scraping bleibt geschlossen. Diese Grenze ist wichtig: Die wiederverwendbare Basis ist außerhalb von Guida nützlich, die Produktschicht enthält die riskanteste Fähigkeit und die dazugehörigen Schutzmechanismen.
Der Browser, den ich haben wollte
Je mehr ich an Beyond Tabs arbeitete, desto stärker wollte ich einen Browser, der Automatisierung als erste Bürgerin behandelt, nicht als Stapel externer Skripte rund um einen Tab.
Ich wollte ein Skript schreiben, es gegen eine sichtbare Seite ausführen, eine URL-Liste in eine Queue legen, Ergebnisse lokal speichern, ein LLM bei der Interpretation helfen lassen, prüfen, was passiert ist, und alles unter meiner Kontrolle behalten.
Kein headless Scraper.
Kein gemieteter Cloud-Browser.
Kein KI-Agent mit vagen Berechtigungen.
Ein lokaler, programmierbarer Browser für Workflows, in denen das Web unordentlich ist und menschliches Urteil zählt.
Das wurde Guida.
Beyond Tabs definierte nicht den vollständigen Produktumfang. Es zeigte die Form des fehlenden Werkzeugs. Guida entstand, als ich aufhörte, dieses Werkzeug als Klebecode zu behandeln, und begann, es richtig zu bauen.