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.
One approach. Three projects of my own.
With Aven, I am developing tools for people and AI agents to work together. My concern goes beyond the next answer: what is the task, what may change, and how do we know whether the work holds up?
Select a point. Motion pauses. Read the step ↓
Beam = project progressFour perspectives on the same project. These steps make tasks and decisions from my work concrete; PDCA helps organise them. In practice, each step can take several rounds. About the PDCA cycle ↗
Identify the parts, rules and connections.
An instruction alone does not make a workable brief. In Aven, the goal, constraints, affected workspace and way to verify the result belong together.
In the project: The task description also includes risks, expected output and a verification method.
A brief that gives the next action a direction.
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.
Plausible prose does not make a project state consistent. Aven includes checks for the structure of work items and discrepancies in their documented relationships.
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 want to know what has actually changed in the project. Workspace validation adds a check of the resulting state to the technical history.
In the project: The public CLI workflow goes from inspection and change back to validation.
An intermediate state that can be checked before moving on.
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.
Another perspective
Problems do not stand still. While I work on a task, the situation changes. Like a solar system in motion, the helix shows both: the path of the task and my work around it.
Select a point. Motion pauses. Read the step ↓
Orbit = project progressFour perspectives on the same project. These steps make tasks and decisions from my work concrete; PDCA helps organise them. In practice, each step can take several rounds. About the PDCA cycle ↗
Identify the parts, rules and connections.
An instruction alone does not make a workable brief. In Aven, the goal, constraints, affected workspace and way to verify the result belong together.
In the project: The task description also includes risks, expected output and a verification method.
A brief that gives the next action a direction.
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.
Plausible prose does not make a project state consistent. Aven includes checks for the structure of work items and discrepancies in their documented relationships.
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 want to know what has actually changed in the project. Workspace validation adds a check of the resulting state to the technical history.
In the project: The public CLI workflow goes from inspection and change back to validation.
An intermediate state that can be checked before moving on.
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.
