Gregor Woitczyk · Popetto
I want to understand how things work. Their parts, their rules, how they fit together.
From that understanding, I build software, systems and workflows that work reliably and leave time for new ideas.
Software & systems AI & automation Creativity & responsibility
01 / Approach
Yesterday, today, tomorrow and beyond. Four perspectives from my practice: understand, stabilise, transform and automate.
Reliable workflows / Two examples
Making a story playable or running a server: I work out the rules and connections until they form a reliable workflow. Harpin and Ansible show this path from understanding to repeatable execution.
In Ansible-Hub, I connect server configuration, controlled changes and checks of the actual state. The firewall is a concrete example: a rule in a repository and an effective rule on a server are two different things.
Select a point. Motion pauses. Read the step ↓
Beam = project progressThe beam shows project progress, the helix my iterative work around it. Each turn creates a new starting point. Even with clear rules, new findings may call for further rounds. PDCA organises the steps within the four perspectives. About the PDCA cycle ↗
Identify the parts, rules and connections.
For a firewall, I need to know more than what is in its configuration file. I distinguish the intended state, the deployed configuration and the rules that are actually active.
In the project: The checking workflow compares intended rules, configuration and active state.
A concrete question instead of an assumption that everything matches.
Ansible-Hub has a separate checking workflow that leaves managed firewall rules unchanged. It gathers the different states before a finding becomes a change.
In the project: Checking and applying changes are separate operations.
An inventory of the state that can support further decisions.
Not every difference means the same failure. The comparison distinguishes an exact match, additional rules and missing required state.
In the project: The result categories distinguish these cases and keep extra rules visible.
A finding that I can interpret deliberately.
A check applies to the selected systems that are included in its scope. Servers are deliberately enrolled in Ansible-Hub’s checks; a run with no matching targets confirms no server state.
In the project: The target group and an additional host selection bound each run.
Clarity about what a result applies to.
Build a dependable foundation.
Changes to access rules must not accidentally affect every system. SSH changes require an explicit target selection, and the command rejects unrestricted selection patterns.
In the project: The SSH target selection is checked before execution.
A specific intervention aimed at a specific target.
Preparation, connectivity and changes have separate steps. Ansible-Hub provides previews and deliberate application; local changes require explicit enablement.
In the project: Local changes are disabled by default while inspection remains available.
A deliberate transition from inspection to intervention.
Before changing SSH configuration, the role checks for the intended operations account and a valid public key. It refuses the change if that foundation is missing.
In the project: Account and key checks precede application of the SSH configuration.
A checked prerequisite instead of a blind configuration change.
A failed run is part of the operational history too. The shared command records execution, output, completion and exit status.
In the project: Run logs are part of the wrapper; CI runs also carry their job context.
A basis for handover and diagnosis.
Bring things together, reshape them and make them understandable.
Not every server needs the same configuration. I group shared tasks into roles and express differences through group and host settings.
In the project: Roles for the base system, Docker, SSH and the firewall have configurable defaults.
A shared structure with explicitly described differences.
Two separate lists of intended firewall rules could drift apart. The checking workflow therefore derives the expected state from the same templates and settings used for deployment.
In the project: Deployment and comparison use the same role templates and variables.
A consolidated definition of the intended state.
An exception must mean the same thing during setup and inspection. In Ansible-Hub, these settings belong in the shared group or host configuration.
In the project: The firewall documentation identifies the shared source of the expected state.
Fewer conflicting definitions of the same operational rule.
An executable workflow also needs a clear explanation. Operational guides sit alongside the roles and describe commands, prerequisites and limitations.
In the project: Firewall and SSH documentation describe their workflows and current implementation scope.
Operational knowledge can be read, checked and developed further.
Hand proven routines over to tools.
Collect configuration, compare rules and record the finding: these recurring steps can be described precisely. They form a useful, bounded automation task.
In the project: The firewall check is available as a dedicated Ansible workflow.
A clear scope for reducing repeated manual work.
The checking workflow generates the expected state, reads configuration and active rules, and performs the comparison. One deliberate command handles the individual technical steps.
In the project: The same workflow is documented for local use and a manually triggered CI job.
The check can be repeated without assembling each step again.
A successful overall pipeline does not answer every operational question. Manual checking jobs and their results must be reviewed individually; the finding remains an output in its own right.
In the project: A concise finding and the full execution log are kept separately.
Repeatable technical work with a result that can be assessed.
The tool handles collection and comparison. Which discrepancy calls for a change, and when to intervene, remain deliberate operational decisions.
In the project: Check scope and the change path remain explicit choices; inspection does not repair automatically.
More attention for causes, decisions and the next improvement.
Working with AI / Aven
Working with AI produces proposals whose outcome cannot be fully anticipated. I check them, learn from the results and adjust the next step. The goal can stay the same while the path changes.
With Aven, I am developing tools for people and AI agents to work together. Clarifying goals and boundaries, checking results and recording decisions creates a dependable framework for work whose next step can change as we learn.
Select a point. Motion pauses. Read the step ↓
Orbit = project progressThe orbit shows a path whose direction changes. The smaller helix represents my work around it: observe, act, check and adjust. New findings inform the next decision. Returning to the same place in the drawing does not mean starting from scratch. PDCA organises the steps within the four perspectives. About the PDCA cycle ↗
Identify the parts, rules and connections.
Working with AI can reveal a different route to a solution than expected. I first clarify what we want to achieve and how we will recognise a useful result. In Aven, the goal, constraints, workspace and verification belong to the brief.
In the project: The task description also includes risks, expected output and a verification method.
A point of reference that holds when the route to a solution changes.
A tool needs context before it intervenes. Aven CLI exposes the local project state, existing work items and individual tasks through focused queries.
In the project: Overview, listing and detail inspection are separate CLI functions.
Scattered information becomes a workspace that can be examined.
AI generates proposals based on probabilities. Their fit with the task and project state needs to be checked. Aven supports this with checks of work-item structure and documented relationships; assessing the substance remains part of the work.
In the project: Workspace validation and consistency checks produce specific findings.
Open issues remain visible and actionable.
Working with AI should not mean starting from scratch every time. Aven retains local sessions and their history, so a session can be deliberately continued.
In the project: Session history, inspection and continuation are part of the local runtime.
A traceable starting point for the next piece of work.
Build a dependable foundation.
An agent may be capable of running a command without having authority to decide that it should. In Aven, I separate tool capability, permitted scope and responsible approval.
In the project: The runtime treats tool access and permission checks as distinct responsibilities.
A defined scope for local changes.
The local runtime connects tool actions with access rules and change previews. The question of what may be touched becomes part of the workflow itself.
In the project: Local tools, permissions and diffs belong to Aven CLI.
Interventions whose scope can be inspected before approval.
After an action, I check what has actually changed in the project. The findings inform my next decision: continue, revise or adjust the route to a solution. Workspace validation supports this feedback by checking the resulting state.
In the project: The public CLI workflow goes from inspection and change back to validation.
A checked intermediate state from which to decide the next step.
Passing a technical check does not replace acceptance by the responsible person. Aven distinguishes submitting tested work from the decision to accept it.
In the project: Submission and Owner acceptance are separate operations.
Responsibility remains assigned when tools support the work.
Bring things together, reshape them and make them understandable.
Requirements, implementation, verification and decisions are parts of the same work. Aven brings them into a shared project structure rather than managing only isolated agent requests.
In the project: Planning, traceability, validation and delivery decisions are part of the product core.
A connection between the reason for the work, its execution and its verification.
The project structure lives in the workspace itself. Aven CLI can create and inspect work items and carry out supported status transitions.
In the project: The local CLI provides setup, creation and transitions for workspace items.
Process control becomes an operable part of development work.
A shared system still needs clear responsibilities. The CLI handles local tools and files; model access and broader agent automation have their own system boundaries.
In the project: The CLI, Inference Gateway and Aven Backend have explicitly distinct roles.
An architecture whose parts can be developed deliberately.
Penbleth adds a playful representation on top of Aven CLI: a project board and role-playing model make roles, decisions and possible next moves tangible.
In the project: Penbleth is a gamification layer built on the local runtime.
Another way to understand the same work and its connections.
Hand proven routines over to tools.
Checking structures, required information and relationships by hand every time consumes attention. In Aven, these recurring checks become executable operations.
In the project: Validation and consistency checks are commands that can be run repeatedly.
People can focus on what a finding means.
Aven CLI makes project actions explicitly executable. Creating work items, checking their state and submitting work for acceptance become deliberate operations.
In the project: The commands connect local execution with the documented project structure.
Fewer repeated manual steps when maintaining the project structure.
What matters to me is whether a check reveals useful discrepancies. Validation can examine structure; whether a solution is good in its domain remains a broader question.
In the project: Structural validation and responsible acceptance remain separate.
A useful check with a clear scope.
Aven is my work on a framework that handles routine and keeps decisions traceable. The local runtime exists; broader agent automation is part of the system’s continuing development.
In the project: Local CLI functions and backend-supported automation have distinct product scopes.
Room to work on solutions instead of continually maintaining the structure around them.
02 / Work
I am Gregor Woitczyk. I develop software, run systems and invent worlds. I want to understand how things connect – and what that understanding makes possible.
Software · Infrastructure · Operations
I develop applications, interfaces and the infrastructure behind them. With Linux, containers and Ansible, I turn recurring operational work into executable steps with results we can check. Development, testing and operations belong together.
AI · Automation · Process control
With Aven, I am developing tools to coordinate people, AI agents and their work. Aven CLI is the local runtime; Penbleth builds on it. Within ALINA, I also work on connecting and running local AI models.
Explore AvenCIRCUMRADIUS · Medical devices
I am co-founder and technical director of CIRCUMRADIUS, the medical device manufacturer formerly known as Die Hobrechts. My work on RADIUS and experience from several audits connect software development with traceable decisions and processes that have to work in everyday practice.
Games · Rules · Interaction
Game development is part of my work, from Motorsportmanager to Die Wimmelburg HD, which I worked on as a co-founder of Die Hobrechts. With Harpin, I also develop a tool of my own that connects written stories to controllable game progression.
Writing · Worldbuilding · Conlanging
With Gelariad, I am developing an imagined world for stories. Through conlanging, I explore sounds, word formation and writing systems. Rules, history and language need to fit together, even when it all starts with an invented idea.
Recognition
03 / Perspective
I work with dependable intermediate results. Like tested climbing anchors, they support the next move. A cause I understand, a working prototype, a reliable process: each makes it possible to move on and adjust the route as I learn, without unnecessary rework.
I want to build things that work without continually demanding our time. That leaves room for what comes next.
04 / Contact
Tell me what you are working on: a system that keeps needing attention, an unclear process or an idea you want to bring to life.
