DevOps · Technical Project Management · AI tooling · Automation
I build tools, workflows, and experiments at the edge of software engineering, AI agents, and real-world project constraints.
I am the creator of M8Shift, a repository-first coordination layer for AI agents working in shifts, with explicit roles, handoffs, and human validation.
M8Shift is not the whole story. It is one visible project among a broader path through software delivery, DevOps, production systems, technical coordination, writing, music, and AI-assisted workflows.
What I do
I work across software delivery, systems, automation, and project coordination.
My background combines hands-on engineering with technical project management, product ownership, requirements work, delivery coordination, incident management, and operational reliability.
That mix matters. Real software work is not only code. It is also constraints, documentation, validation, delivery pressure, legacy systems, and humans trying to understand why the process exists.
Current focus
My current focus is AI-assisted work and multi-agent coordination.
The core question behind M8Shift is simple:
How can different AI agents collaborate on the same project without turning the human into a copy-paste middleware layer?
Different agents have different strengths. One may be better at implementation, another at critique, another at writing, another at structure. Their disagreement can be useful when it surfaces real choices.
M8Shift keeps that process explicit, repository-first, and human-controlled.
Background
I have spent more than 19 years working across software development, DevOps, middleware, production systems, incident management, project coordination, requirements, and technical delivery.
I have worked in environments including:
- aerospace and air traffic management;
- banking IT;
- telecom and networks;
- energy;
- enterprise software platforms;
- internal engineering systems;
- web and e-learning platforms.
How I work
I like tools that are:
- explicit rather than mystical;
- boring where they should be boring;
- inspectable;
- scriptable;
- documented;
- easy to run locally;
- hard to abuse accidentally;
- useful before they become elegant.
I do not believe every problem needs a platform. Some problems need a file, a command, a convention, and fewer meetings.