Gregor Woitczyk · Popetto
Ich will verstehen, wie Dinge funktionieren. Ihre Teile, ihre Regeln, ihr Zusammenspiel.
Daraus entwickle ich Software, Systeme und Abläufe, die verlässlich funktionieren und Zeit für Neues lassen.
Software & Systeme AI & Automation Kreativität & Verantwortung
01 / Arbeitsweise
Gestern, heute, morgen, übermorgen. Vier Perspektiven aus meiner Praxis: verstehen, stabilisieren, transformieren und automatisieren.
Verlässliche Abläufe / Zwei Beispiele
Eine Geschichte spielbar machen oder einen Server betreiben: Ich kläre die Regeln und Zusammenhänge, bis daraus ein verlässlicher Ablauf wird. Harpin und Ansible zeigen diesen Weg vom Verstehen zur wiederholbaren Ausführung.
Harpin ist mein TypeScript-Interpreter für Geschichten aus Twine im Harlowe-Format, entstanden für ein narratives Spiel mit Phaser. Er verbindet Text, Entscheidungen und Spielaktionen – und lässt die Darstellung beim Spiel.
Wähle einen Punkt. Die Bewegung hält an. Schritt lesen ↓
Strahl = ProjektfortschrittDer Strahl zeigt den Projektfortschritt, die Spirale meine iterative Arbeit darum herum. Nach jeder Windung entsteht eine neue Ausgangslage. Auch bei klaren Regeln können neue Erkenntnisse weitere Runden nötig machen. PDCA gliedert die Stationen innerhalb der vier Perspektiven. Zum PDCA-Zyklus ↗
Bestandteile, Regeln und Zusammenhänge erkennen.
Für ein Spiel ist eine Geschichte mehr als eine Folge von Sätzen. Sie enthält Abschnitte, Verweise, Bedingungen und Anweisungen. Harpin setzt genau bei dieser Struktur an.
Im Projekt: Der Parser unterscheidet Text, Verweise, Sprünge, Variablen und weitere Anweisungen.
Ein Blick auf die Bauteile hinter dem Erzähltext.
Der Parser liest die Quelldatei und ordnet ihre Elemente den Abschnitten zu. Eine Textzeile bleibt Text, ein Verweis bekommt ein Ziel und eine Steueranweisung einen eigenen Typ.
Im Projekt: Eigene Elementmodelle bilden die verschiedenen Bestandteile ab.
Eine Geschichte, deren Ablauf sich programmatisch untersuchen lässt.
Was ein Parser verstanden hat, muss ich ansehen können. Harpin kann die eingelesene Geschichte als strukturierte JSON-Daten ausgeben; Quelldatei und Ergebnis lassen sich gegenüberstellen.
Im Projekt: Der vorhandene Beispielablauf liest eine Quelldatei und schreibt die verarbeitete Struktur.
Eine überprüfbare Übersetzung vom Text ins Datenmodell.
Geschichte, Abschnitt und Element bekommen klare Schnittstellen. Damit muss die spätere Ablaufsteuerung die Bedeutung der ursprünglichen Textzeilen nicht immer wieder neu erraten.
Im Projekt: Parser und Ablaufsteuerung arbeiten mit denselben Typen für Geschichte und Elemente.
Ein gemeinsames Verständnis für die nächsten Verarbeitungsschritte.
Eine verlässliche Grundlage schaffen.
Ein Dialog darf nicht durchlaufen, bevor er gelesen wurde. Harpin behandelt Unterbrechungen ausdrücklich: Bestimmte Elementtypen halten den Ablauf an, bis das Spiel ihn weiterführt.
Im Projekt: Die unterbrechenden Elementtypen sind konfigurierbar.
Eine Regel dafür, wann das Werkzeug wartet.
Der Interpreter verwaltet den aktuellen Abschnitt und das nächste Element. Eine Unterbrechung wird gezielt aufgelöst; anschließend kann die Verarbeitung fortgesetzt werden.
Im Projekt: Abschnitt, Elementposition und Unterbrechungszustand sind Teil der Ablaufsteuerung.
Ein bestimmbarer Anschluss nach jeder Pause.
Für die Untersuchung eines Ablaufs ist ein einzelner Schritt oft hilfreicher als die ganze Geschichte. Harpin unterstützt die Verarbeitung einzelner Elemente und das Weiterlaufen bis zur nächsten Unterbrechung.
Im Projekt: Einzelschritt und fortlaufende Verarbeitung sind eigene Aufrufmöglichkeiten.
Der Verlauf lässt sich an konkreten Stellen untersuchen.
Der Interpreter muss melden, was gerade passiert. Harpin stellt dafür definierte Rückrufe bereit, unter anderem für Text, Verweise, Unterbrechungen und das Ende der Geschichte.
Im Projekt: Die TypeScript-Schnittstelle beschreibt die Ereignisse und ihre Daten.
Eine verbindende Schnittstelle zwischen Ablauf und Spiel.
Zusammenführen, neu zusammensetzen und transparent machen.
Die Geschichte soll in ihrem Schreibformat entstehen können, während das Spiel seine eigene Darstellung behält. Harpin schafft dafür eine Zwischenschicht zwischen Harlowe-Quelltext und Spielablauf.
Im Projekt: Das Projekt wurde für die Einbindung interaktiver Geschichten in eine eigene Laufzeit entwickelt.
Zwei Werkzeuge können ihre jeweiligen Stärken behalten.
Die gelesene Geschichte wird zu einer gemeinsamen Datenstruktur. Darauf arbeitet die Ablaufsteuerung; wie ein Satz aussieht oder eine Auswahl dargestellt wird, entscheidet die angeschlossene Anwendung.
Im Projekt: Parser, Datenmodell und Verarbeitung sind getrennte Bausteine.
Erzählung und Darstellung lassen sich gezielter verändern.
Eine kleine Beispielgeschichte macht die Verbindung greifbar. Der vorhandene Beispiellauf zeigt Textausgabe, Sprecherwechsel und Hintergrundwechsel in ihrer Reihenfolge.
Im Projekt: Beispielcode und protokollierter Ablauf zeigen die Verarbeitung derselben Geschichte.
Ein überschaubarer Ablauf, an dem sich die Verbindung beurteilen lässt.
Nicht jede Spielaktion steckt bereits im Erzählformat. Harpin erkennt deshalb auch eigene Metadaten und reicht sie an die Anwendung weiter, etwa für Sprecher oder Hintergrundbilder.
Im Projekt: Eigene Makros und ihr Rückruf ergänzen die Verarbeitung der Standardbestandteile.
Ein gemeinsamer Ablauf mit Platz für die Besonderheiten des Spiels.
Bewährte Routine an Werkzeuge übergeben.
Texte nacheinander ausgeben, Abschnitte wechseln, anhalten und fortsetzen: Solche Aufgaben kehren in narrativen Spielen wieder. Diese Routine bündele ich im Interpreter.
Im Projekt: Harpin bietet eine gemeinsame Verarbeitung für unterschiedliche Erzählabschnitte.
Ein technischer Ablauf muss nicht für jede Szene neu entstehen.
Der Interpreter liest das nächste Element, verarbeitet es und ruft den passenden Anschluss der Anwendung auf. Die Geschichte liefert die Reihenfolge, das Spiel übernimmt die konkrete Darstellung.
Im Projekt: Die Verarbeitung verteilt Text, Verweise und Anweisungen an ihre jeweiligen Rückrufe.
Wiederkehrende Verkabelung wird zu einem gemeinsamen Werkzeug.
Auch automatisch verarbeitete Geschichten brauchen erkennbare Haltepunkte. Im Beispiel lässt sich eine Pause auflösen und der Verlauf bis zum gemeldeten Ende der Geschichte verfolgen.
Im Projekt: Der Beispiellauf verbindet Unterbrechung, Fortsetzung und Abschlussmeldungen.
Der automatische Ablauf bleibt beobachtbar.
Harpin liegt als eigene TypeScript-Bibliothek vor. Die wiederverwendbare Ablauftechnik soll den Kopf für Dialoge, Entscheidungen und die Wirkung einer Szene freimachen.
Im Projekt: Das Paket stellt den Interpreter und seine Typen zur Einbindung bereit.
Ein eigenes Werkzeug im Dienst einer kreativen Idee.
Arbeiten mit AI / Aven
Bei der Arbeit mit KI entstehen Vorschläge, deren Ergebnis sich nicht vollständig vorwegnehmen lässt. Ich prüfe sie, gewinne neue Erkenntnisse und passe den nächsten Schritt an. Das Ziel kann bleiben, während sich der Weg verändert.
Mit Aven entwickle ich Werkzeuge für die Zusammenarbeit von Menschen und AI-Agenten. Ziele und Grenzen klären, Ergebnisse prüfen, Entscheidungen festhalten: So entsteht ein verlässlicher Rahmen für Arbeit, deren nächster Schritt sich mit neuen Erkenntnissen verändern kann.
Wähle einen Punkt. Die Bewegung hält an. Schritt lesen ↓
Umlaufbahn = ProjektfortschrittDie Umlaufbahn zeigt einen Weg, dessen Richtung sich verändert. Die kleine Spirale steht für meine Arbeit daran: beobachten, handeln, prüfen und neu ausrichten. Neue Erkenntnisse fließen in die nächste Entscheidung ein. Die räumliche Wiederkehr bedeutet keinen Neustart bei null. PDCA gliedert die Stationen innerhalb der vier Perspektiven. Zum PDCA-Zyklus ↗
Bestandteile, Regeln und Zusammenhänge erkennen.
Bei der Arbeit mit AI kann sich ein anderer Lösungsweg ergeben als erwartet. Deshalb kläre ich zuerst, was erreicht werden soll und woran wir ein brauchbares Ergebnis erkennen. In Aven gehören Ziel, Rahmenbedingungen, Arbeitsbereich und Prüfung zum Auftrag.
Im Projekt: Die Aufgabenbeschreibung umfasst auch Risiken, erwartetes Ergebnis und Prüfmethode.
Eine Orientierung, die auch bei einem veränderten Lösungsweg trägt.
Bevor ein Werkzeug eingreift, braucht es Kontext. Aven CLI macht den Zustand des lokalen Projekts, vorhandene Arbeitsobjekte und einzelne Aufgaben über gezielte Abfragen zugänglich.
Im Projekt: Übersicht, Auflistung und Detailansicht sind eigene CLI-Funktionen.
Aus verstreuten Informationen wird ein untersuchbarer Arbeitsbereich.
AI erzeugt Vorschläge auf Basis von Wahrscheinlichkeiten. Ob sie zur Aufgabe und zum Projektzustand passen, muss geprüft werden. Aven unterstützt dabei mit Prüfungen für die Struktur der Arbeitsobjekte und ihre dokumentierten Beziehungen; die fachliche Bewertung gehört weiterhin dazu.
Im Projekt: Workspace-Validierung und Konsistenzprüfung liefern konkrete Befunde.
Offene Punkte bleiben erkennbar und bearbeitbar.
Arbeit mit AI soll nicht jedes Mal bei null anfangen. Aven hält lokale Sitzungen und ihren Verlauf fest; eine begonnene Sitzung lässt sich gezielt fortsetzen.
Im Projekt: Sitzungsverlauf, Einzelansicht und Fortsetzung sind Teil der lokalen Laufzeit.
Ein nachvollziehbarer Anschluss für die nächste Arbeitseinheit.
Eine verlässliche Grundlage schaffen.
Ein Agent kann einen Befehl ausführen, ohne zur Entscheidung darüber berechtigt zu sein. In Aven trenne ich Werkzeugfähigkeit, erlaubten Handlungsspielraum und verantwortliche Freigabe.
Im Projekt: Die Laufzeit führt Werkzeugzugriff und Berechtigungsprüfung als eigene Aufgaben.
Ein definierter Rahmen für lokale Änderungen.
Die lokale Laufzeit verbindet Werkzeugaktionen mit Zugriffsregeln und Änderungsansichten. So gehört die Frage, was angefasst werden darf, zum Ablauf selbst.
Im Projekt: Lokale Werkzeuge, Berechtigungen und Diffs liegen in Aven CLI.
Eingriffe, deren Umfang vor einer Freigabe sichtbar werden kann.
Nach einer Handlung prüfe ich, was im Projekt tatsächlich anders ist. Der Befund fließt in meine nächste Entscheidung ein: weitergehen, nachbessern oder den Lösungsweg anpassen. Die Workspace-Validierung unterstützt diese Rückkopplung mit einer Prüfung des entstandenen Zustands.
Im Projekt: Die öffentliche CLI-Abfolge führt von Übersicht und Änderung zurück zur Validierung.
Ein geprüfter Zwischenstand, von dem aus sich der nächste Schritt bestimmen lässt.
Eine bestandene technische Prüfung ersetzt keine fachliche Abnahme. Aven unterscheidet die Übergabe getesteter Arbeit von der Entscheidung, sie anzunehmen.
Im Projekt: Einreichen und Owner-Abnahme sind getrennte Vorgänge.
Verantwortung bleibt auch bei Werkzeugunterstützung zugeordnet.
Zusammenführen, neu zusammensetzen und transparent machen.
Anforderungen, Umsetzung, Prüfung und Entscheidung sind Teile derselben Arbeit. Aven bringt sie in einen gemeinsamen Projektrahmen, statt nur einzelne Agentenaufträge zu verwalten.
Im Projekt: Planung, Rückverfolgbarkeit, Validierung und Auslieferungsentscheidungen gehören zum Produktkern.
Ein Zusammenhang zwischen dem Warum, der Arbeit und ihrer Prüfung.
Die Projektstruktur liegt im Arbeitsbereich selbst. Aven CLI kann diese Arbeitsobjekte anlegen, anzeigen und durch unterstützte Statuswechsel führen.
Im Projekt: Die lokale CLI bietet Einrichtung, Anlage und Statuswechsel für Workspace-Objekte.
Prozesssteuerung wird zu einem bedienbaren Teil der Entwicklungsarbeit.
Ein gemeinsames System braucht weiterhin klare Zuständigkeiten. Die CLI bearbeitet lokale Werkzeuge und Dateien; Modellzugang und weitergehende Agentenautomation haben eigene Systemgrenzen.
Im Projekt: CLI, Inference Gateway und Aven Backend sind ausdrücklich getrennt beschrieben.
Eine Architektur, deren Teile sich gezielt weiterentwickeln lassen.
Mit Penbleth kommt eine spielerische Darstellung auf Aven CLI hinzu: Projektboard und Rollenspielmodell machen Rollen, Entscheidungen und nächste Züge anschaulich.
Im Projekt: Penbleth baut als Gamification-Schicht auf der lokalen Laufzeit auf.
Ein weiterer Zugang zur selben Arbeit und ihren Zusammenhängen.
Bewährte Routine an Werkzeuge übergeben.
Strukturen, Pflichtangaben und Beziehungen jedes Mal von Hand zu prüfen bindet Aufmerksamkeit. In Aven bekommen solche wiederkehrenden Prüfungen einen ausführbaren Ablauf.
Im Projekt: Validierung und Konsistenzprüfung sind wiederholbar aufrufbare Befehle.
Menschen können sich auf die Bedeutung eines Befunds konzentrieren.
Aven CLI macht Projektaktionen explizit ausführbar. Arbeitsobjekte anlegen, ihren Zustand prüfen oder Arbeit zur Abnahme einreichen werden gezielte Operationen.
Im Projekt: Die Befehle verbinden lokale Ausführung mit dem dokumentierten Projektrahmen.
Weniger wiederkehrende Handgriffe beim Pflegen der Projektstruktur.
Für mich zählt, ob eine Prüfung verwertbare Abweichungen sichtbar macht. Eine Validierung kann die Struktur prüfen; ob eine Lösung fachlich gut ist, bleibt eine weitergehende Frage.
Im Projekt: Strukturprüfung und verantwortliche Abnahme bleiben getrennt.
Eine hilfreiche Prüfung mit einem klaren Geltungsbereich.
Aven ist meine Arbeit an einem Rahmen, der Routine trägt und Entscheidungen nachvollziehbar hält. Die lokale Laufzeit ist vorhanden; weitergehende Agentenautomation gehört in die Entwicklung des Gesamtsystems.
Im Projekt: Lokale CLI-Funktionen und Backend-gestützte Automation haben getrennte Produktumfänge.
Freiraum für Lösungen statt ständiger Pflege ihres Arbeitsrahmens.
02 / Praxis
Ich bin Gregor Woitczyk. Ich entwickle Software, betreibe Systeme und erfinde Welten. Mich interessiert, wie Dinge zusammenhängen – und was sich mit diesem Verständnis anfangen lässt.
Software · Infrastruktur · Betrieb
Ich entwickle Anwendungen, Schnittstellen und die Infrastruktur dahinter. Mit Linux, Containern und Ansible mache ich wiederkehrende Betriebsabläufe ausführbar und ihre Ergebnisse überprüfbar. Entwicklung, Tests und Betrieb gehören für mich zusammen.
AI · Automation · Prozesssteuerung
Mit Aven entwickle ich eine Steuerung für die Zusammenarbeit von Menschen, AI-Agenten und Werkzeugen. Aven CLI ist die lokale Laufzeit; Penbleth baut darauf auf. Im ALINA-Umfeld beschäftige ich mich außerdem mit der Anbindung und dem Betrieb lokaler AI-Modelle.
Aven kennenlernenCIRCUMRADIUS · Medizinprodukte
Ich bin Mitgründer und technischer Leiter des Medizinproduktherstellers CIRCUMRADIUS, früher Die Hobrechts. Meine Arbeit an RADIUS und die Erfahrung aus mehreren Audits verbinden Softwareentwicklung mit nachvollziehbaren Entscheidungen und Prozessen, die im Alltag funktionieren müssen.
Spiele · Regeln · Interaktion
Spieleentwicklung gehört zu meiner Praxis: vom Motorsportmanager bis zu Die Wimmelburg HD, an der ich als Mitgründer von Die Hobrechts gearbeitet habe. Mit Harpin entwickle ich außerdem ein eigenes Werkzeug, das geschriebene Geschichten mit steuerbaren Spielabläufen verbindet.
Schreiben · Worldbuilding · Conlanging
Mit Gelariad entwickle ich eine eigene erzählerische Welt. Im Conlanging beschäftige ich mich mit Lauten, Wortbildung und Schriftsystemen. Regeln, Geschichte und Sprache sollen zusammenpassen – auch dort, wo alles mit einer erfundenen Idee beginnt.
Anerkennung
03 / Haltung
Ich arbeite mit belastbaren Zwischenständen. Wie geprüfte Sicherungshaken beim Klettern geben sie Halt für den nächsten Schritt. Eine geklärte Ursache, ein funktionierender Prototyp, ein verlässlicher Ablauf: Jeder dieser Anker erlaubt, weiterzugehen und die Route bei neuen Erkenntnissen anzupassen, ohne bereits geleistete Arbeit unnötig zu wiederholen.
Ich möchte Dinge schaffen, die funktionieren, ohne unsere Zeit dauerhaft an sich zu binden. Damit Raum für das Nächste entsteht.
04 / Kontakt
Erzähl mir, was dich beschäftigt: ein System, das ständig Aufmerksamkeit braucht, ein unklarer Ablauf oder eine Idee, die Gestalt annehmen soll.
