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.
Im Ansible-Hub verbinde ich Serverkonfiguration, kontrollierte Änderungen und die Prüfung des tatsächlichen Zustands. Die Firewall ist ein konkretes Beispiel: Eine Regel im Repository und eine wirksame Regel auf dem Server sind zwei verschiedene Dinge.
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.
Bei einer Firewall interessiert mich mehr als die abgelegte Konfigurationsdatei. Ich unterscheide den gewünschten Zustand, die ausgerollte Konfiguration und die Regeln, die tatsächlich aktiv sind.
Im Projekt: Der Prüfpfad vergleicht Sollvorgaben, Konfiguration und aktiven Zustand.
Eine konkrete Frage statt der bloßen Annahme, dass alles passt.
Der Ansible-Hub hat einen eigenen Prüfablauf, der die verwalteten Firewall-Regeln nicht verändert. Er sammelt die Zustände, bevor aus einem Befund eine Änderung wird.
Im Projekt: Prüfen und Anwenden sind getrennte Aufrufarten.
Eine Bestandsaufnahme, auf die sich weitere Entscheidungen stützen können.
Ein Unterschied ist nicht automatisch derselbe Fehler. Der Vergleich unterscheidet eine genaue Übereinstimmung, zusätzliche Regeln und fehlenden vorgeschriebenen Zustand.
Im Projekt: Die Ergebnisstufen unterscheiden diese Fälle und halten zusätzliche Regeln sichtbar.
Ein Befund, den ich gezielt einordnen kann.
Eine Prüfung gilt für die ausgewählten und eingebundenen Systeme. Im Ansible-Hub werden Server bewusst in den Prüfumfang aufgenommen; ein Aufruf ohne passende Ziele bestätigt keinen Serverzustand.
Im Projekt: Die Zielgruppe und eine zusätzliche Host-Auswahl begrenzen den Lauf.
Klarheit darüber, worauf sich ein Ergebnis bezieht.
Eine verlässliche Grundlage schaffen.
Gerade bei Zugangsregeln darf eine Änderung nicht versehentlich alle Systeme treffen. Für SSH-Änderungen verlangt der Aufruf eine ausdrückliche Zielauswahl und lehnt unbeschränkte Auswahlmuster ab.
Im Projekt: Die SSH-Auswahl wird vor der Ausführung geprüft.
Ein bestimmter Eingriff mit einem bestimmten Ziel.
Vorbereitung, Erreichbarkeit und Änderung haben eigene Schritte. Der Ansible-Hub bietet Vorschau und gezieltes Anwenden; lokale Änderungen müssen ausdrücklich freigeschaltet werden.
Im Projekt: Der lokale Änderungsweg ist standardmäßig gesperrt, reine Prüfungen bleiben möglich.
Ein bewusster Übergang von Untersuchung zu Eingriff.
Die SSH-Rolle prüft vor der Umstellung, ob der vorgesehene Betriebsnutzer und ein gültiger öffentlicher Schlüssel vorhanden sind. Fehlt diese Grundlage, verweigert sie die Änderung.
Im Projekt: Nutzer- und Schlüsselprüfung stehen vor dem Anwenden der SSH-Konfiguration.
Eine überprüfte Voraussetzung statt eines blinden Konfigurationswechsels.
Auch ein fehlgeschlagener Lauf gehört zur Betriebsgeschichte. Der gemeinsame Aufruf protokolliert Ausführung, Ausgabe, Abschluss und Rückgabewert.
Im Projekt: Laufprotokolle sind Bestandteil des Wrappers; CI-Läufe liefern zusätzlich ihren Jobkontext.
Eine Grundlage für Übergabe und Fehlersuche.
Zusammenführen, neu zusammensetzen und transparent machen.
Nicht jeder Server braucht dieselbe Konfiguration. Ich bündele gemeinsame Aufgaben in Rollen und bilde Unterschiede über Gruppen- und Hostvorgaben ab.
Im Projekt: Rollen für Grundsystem, Docker, SSH und Firewall haben konfigurierbare Vorgaben.
Ein gemeinsamer Aufbau mit ausdrücklich beschriebenen Unterschieden.
Zwei getrennte Listen gewünschter Firewall-Regeln könnten auseinanderlaufen. Deshalb leitet der Prüfpfad den erwarteten Zustand aus denselben Vorlagen und Vorgaben ab wie das Ausrollen.
Im Projekt: Ausbringen und Vergleich verwenden dieselben Rollen-Vorlagen und Variablen.
Eine konsolidierte Definition dessen, was gelten soll.
Eine Ausnahme muss beim Einrichten und beim Prüfen gleich verstanden werden. Im Ansible-Hub gehören solche Vorgaben in die gemeinsame Gruppen- oder Hostkonfiguration.
Im Projekt: Die Firewall-Dokumentation hält die gemeinsame Herkunft des Sollzustands fest.
Weniger widersprüchliche Definitionen derselben Betriebsregel.
Ein ausführbarer Ablauf braucht auch eine verständliche Erklärung. Im Repository stehen Betriebsanleitungen neben den Rollen und beschreiben Aufruf, Voraussetzungen und Grenzen.
Im Projekt: Für Firewall und SSH sind Ablauf und aktueller Implementierungsumfang dokumentiert.
Betriebswissen lässt sich lesen, prüfen und weiterentwickeln.
Bewährte Routine an Werkzeuge übergeben.
Konfiguration einsammeln, Regeln vergleichen und den Befund notieren: Diese wiederkehrenden Schritte lassen sich präzise beschreiben. Sie bilden einen guten begrenzten Automationsauftrag.
Im Projekt: Die Firewall-Prüfung ist als eigener Ansible-Ablauf verfügbar.
Ein klarer Umfang für wiederholbare Entlastung.
Der Prüfablauf erzeugt den Sollzustand, liest Konfiguration und aktive Regeln und führt den Vergleich aus. Ein gezielter Aufruf übernimmt die technischen Einzelschritte.
Im Projekt: Derselbe Ablauf ist lokal und als manuell gestarteter CI-Job vorgesehen und dokumentiert.
Die Prüfung wird wiederholbar, ohne jeden Einzelschritt neu zusammenzustellen.
Eine erfolgreiche Gesamtpipeline beantwortet nicht jede Betriebsfrage. Die manuellen Prüfjobs und ihre Ergebnisse müssen einzeln betrachtet werden; der Befund bleibt ein eigenes Arbeitsergebnis.
Im Projekt: Kurzer Befund und vollständiges Laufprotokoll werden getrennt aufbewahrt.
Technische Wiederholung mit einem auswertbaren Ergebnis.
Das Werkzeug übernimmt Sammeln und Vergleichen. Welche Abweichung eine Änderung verlangt und wann ein Eingriff sinnvoll ist, bleibt eine bewusste Betriebsentscheidung.
Im Projekt: Prüfumfang und Änderungsweg bleiben ausdrücklich wählbar; die Prüfung repariert nicht selbst.
Mehr Aufmerksamkeit für Ursachen, Entscheidungen und die nächste Verbesserung.
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.
